This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 20, 2005.
Copyright (C) The Internet Society (2005).
This document specifies a syntax for addressing time intervals within time-based Web resources through URI queries and fragments. This scheme is particularly used for AnnodexPfeiffer, S., Parker, C. and A. Pang, The Annodex exchange format for time-continuous data files, Version 3.0 (work in progress), March 2005. and CMMLPfeiffer, S., Parker, C. and A. Pang, The Continuous Media Markup Language (CMML), Version 2.0 (work in progress), March 2005. Web resources, though it could be picked up by any other time-based Web resource format. Temporal addressing enables, e.g., direct access to a clip inside a video stored on a Web Server, or direct jumps to a specific event within a piece of music. The syntax is not restricted to audio or video Web resources though, but covers all kinds of Web resources that contain time-continuous information.
When a server (e.g. a Web Server) supports the URI query syntax, it is able to extract the given time subsections from the base resource and serve them as another resource of the same type. Specifying a time point or interval through a URI fragment in contrast does not deliver a subpart of the resource - instead it is up to the user agent and the resource type as to what action is invoked. Examples are a fast forward to a time point, or a zoom into a time interval.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119Bradner, S., Key words for use in RFCs to Indicate Requirements Levels, March 1997..
2. Incorporating temporal addressing into the Generic URI Scheme
3. Temporal addressing through URI queries
4. Temporal addressing through URI fragments
5. Time schemes
6. Implementation with HTTP
6.1 Identifying enabled HTTP servers
6.2 Caching URIs with temporal queries in HTTP proxy servers
6.3 Overview of added HTTP message headers
7. Implementation with RTP/RTSP
8. Security considerations
§ Authors' Addresses
§ Intellectual Property and Copyright Statements
Many resources on the World Wide Web represent information that relate to a timeline of events. Time-sampled recordings of sound, temporally interleaved audio-visual streams, or data files containing time series data are examples. This document describes a syntax for addressing temporal offsets and time intervals in such resources. The aim is to make it simple to incorporate infrastructure into the Internet which supports the addressing and retrieval of temporal subparts of time-based Web resources, as well as the automated processing of such subparts for reuse.
The temporal URI interval specifications are to be used on resources that represent a specific timeline. An example of such resources are most resources of MIME types "audio/*" and "video/*". Files containing commands for creating time-continuous experiences (such as SMIL files for authoring interactive multimedia, or VRML files for authoring 3D worlds) cannot be addressed in this manner. However, if one particular user interaction (i.e. one experience) is recorded, the recording contains data that relates to a single timeline and can be addressed with the manner described in this specification.
The temporal URI queries and fragments specified in this document have been implemented and demonstrated to work with AnnodexPfeiffer, S., Parker, C. and A. Pang, The Annodex exchange format for time-continuous data files, Version 3.0 (work in progress), March 2005. and CMMLPfeiffer, S., Parker, C. and A. Pang, The Continuous Media Markup Language (CMML), Version 2.0 (work in progress), March 2005. format Web resources over HTTPFielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, Hypertext Transfer Protocol -- HTTP/1.1, June 1999.. A possible implementation over RTP/RTSPSchulzrinne, H., Rao, A. and R. Lanphier, Real Time Streaming Protocol (RTSP), April 1998. for Internet streaming is being specified. Usage with other protocols is possible, but has not been explored yet.
The Generic URI SchemeBerners-Lee, T., Fielding, R. and L. Masinter, Uniform Resource Identifiers (URI): Generic Syntax, January 2005. defines two manners in which subparts of Web resources can be addressed: queries and fragments. Queries are given through extending the Web resource's address by a string that is separated through the special character "?". Fragments are given through extending the Web resource's address by a string that is separated through the special character "#".
RFC 3986Berners-Lee, T., Fielding, R. and L. Masinter, Uniform Resource Identifiers (URI): Generic Syntax, January 2005. specifies that URI queries identify a resource and thus a Web server MUST process the query returning a fully defined resource. There is no generically defined structure to URI queries. However, the format of a CGI query string where name-value pairs are separated by the special character "&" is a commonly used format. The Common Gateway Interface, or CGI, is a convention for external gateway programs to interface with information servers such as HTTP servers (see http://hoohoo.ncsa.uiuc.edu/cgi/). When defining a common manner in which temporal subparts of a Web resource can be addressed, it is important to be compatible with this common CGI format.
RFC 3986Berners-Lee, T., Fielding, R. and L. Masinter, Uniform Resource Identifiers (URI): Generic Syntax, January 2005. also specifies that URI fragments identify a secondary resource by reference to a primary resource and that fragments are interpreted client side, i.e. the Web infrastructure consisting of Web servers and Web proxies will generally ignore the "#" extension of URIs. This basically implies that a fragment provides a particular view on a resource and the view is defined through the type of resource and through the client side application.
Both, URI query and URI fragment identifiers have traditionally been defined for specific media types or even specific services. This is especially true for URI queries where the query string may consist of name-value pairs that contain the particular fields and field entries of a particular form that resides on a particular server and is processed by a particular server extension. For the temporal addressing that is proposed in this document, it is important that every Web server that interpretes the query parameter reacts uniformly to it. The particular resources which are covered in this manner are the AnnodexPfeiffer, S., Parker, C. and A. Pang, The Annodex exchange format for time-continuous data files, Version 3.0 (work in progress), March 2005. and CMMLPfeiffer, S., Parker, C. and A. Pang, The Continuous Media Markup Language (CMML), Version 2.0 (work in progress), March 2005. media types. This scheme can be adopted for other media types, by including it in the media type registration for that format.
URI query strings are specified after the special character "?". A temporal query parameter defines one or more intervals of time. Time is given with respect to specific time schemes. The default time scheme is "npt" (normal play time), in which a time point is specified in seconds through a floating point number with an arbitrary temporal resolution. The available time schemes and their specifications are described further down in this document.
The BNF for a temporal URI query parameter is:
time-parameter = "t" "=" [ timescheme ":" ] time-intervalspec time-intervalspec = time-interval ["," time-intervalspec] time-interval = timespec ["/" timespec] timescheme = *( unreserved / pct-encoded / sub-delims / "/" / "?" / "#" / "[" / "]" / "@" ) timespec = *( unreserved / pct-encoded / "?" / "#" / "[" / "]" / "@" / "!" / "$" / "&" / "'" / "(" / ")" / "*" / "+" / ";" / "=" )
All time intervals actually specify start and end times. If no end timespec is given, it defaults to "infinity", which for a file means the end of the file or for a stream the end of the stream. Overlapping time intervals MUST be interpreted by merging the intervals into one.
It is not valid to give several temporal URI query parameters in one URI query. They all need to be wrapped into a single specification.
A URI with a query for several intervals may be split by the user agent into several queries for a single interval each and then sent to the server in consecutive requests, which in the case of HTTP/1.1 would e.g. be pipelined. This is of particular interest to user clients that can not handle resources that consist of temporally non-consecutive data, e.g. chained Annodex bitstreams.
Examples for URIs containing temporal queries are:
URI fragment specifiers are given after the special character crosshatch ("#"). A temporal URI fragment defines a specific temporal view onto a Web resource consisting of one or more intervals of time. Again, time is given with respect to specific time schemes as defined below, "npt" being the default.
The BNF for a temporal URI fragment identifier is (reusing the time-intervalspec of the URI query section above):
temporal-fragment = time-parameter
As with temporal URI query parameters, all temporal intervals are specified through start and end times, the default end time being infinity, which may map to the end of a file or stream. Also, several temporal URI fragment identifiers are not allowed.
What a user agent does with a temporal URI fragment is up to itself. As a result of the request being sent to the server, the user agent receives the complete resource. If the user agent is a Web browser and the resource is a video, the user agent MAY play back only the specified time section(s). If the user agent is a sound editor and the resource a sound file, the user agent MAY select the disjoint time intervals in the sound file as a first step to applying some filter to them.
Examples for URIs with temporal fragment specifications are:
A time scheme is a short identifier for a type of time specification. The following general time schemes are specified in this document. Further time schemes are expected to emerge and should probably be registered through IANA.
Specification as BNF:
timescheme = npt-timescheme | smpte-timescheme | utc-timescheme | *unreserved timespec = npt-timespec | smpte-timespec | utc-timespec | *uric
These time schemes are specified as follows:
NPT time has a second or subsecond resolution. It is specified as H:M:S.h (npt-hhmmss) or S.h (npt-sec), where H=hours, M=minutes, S=second and h=fractions of a second. Negative values are not allowed.
Specification as BNF:npt-timescheme = "npt" npt-timespec = npt-sec | npt-hhmmss npt-sec = 1*DIGIT [ "." *DIGIT ] npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT ] npt-hh = 1*DIGIT ; any positive number npt-mm = 1*2DIGIT ; 0-59 npt-ss = 1*2DIGIT ; 0-59
SMPTE time codesThe Society of Motion Picture and Television Engineers, SMPTE STANDARD for Television, Audio and Film - Time and Control Code, September 1999. are optimized for frame level accuracy. SMPTE is specified as HH:MM:SS:FF, where HH=hours, MM=minutes, SS=second, FF=frames. The drop-frame algorithms for calculating the exact times can be found in the references SMPTE standard. Negative values are not allowed.
"smpte-24=" SMPTE time with a 24 fps basis
"smpte-24-drop=" SMPTE time with a 24/1.001 fps basis
"smpte-25=" SMPTE time with a 25 fps basis
"smpte-30=" SMPTE time with a 30 fps basis
"smpte-30-drop=" SMPTE time with a 30/1.001 fps basis
"smpte-50=" SMPTE time with a 50 fps basis
"smpte-60=" SMPTE time with a 60 fps basis
"smpte-60-drop=" SMPTE time with a 60/1.001 fps basis
Specification as BNF:smpte-timescheme = "smpte-24" | "smpte-24-drop" | "smpte-25" | "smpte-30" | "smpte-30-drop" | "smpte-50" | "smpte-60" | "smpte-60-drop" smpte-timespec = smpte-hh ":" smpte-mm ":" smpte-ss [ ":" smpte-ff ] smpte-hh = 1*2DIGIT smpte-mm = 1*2DIGIT smpte-ss = 1*2DIGIT smpte-ff = 1*2DIGIT
UTC time has a second or subsecond resolution. It is given as YYYYMMDDTHHmmss.hhZ, where Y=year, M=month, D=day, H=hour, m=minute, s=second, h=subseconds (one-hundredth of a second).
Specification as BNF:utc-timescheme = "clock" utc-timespec = utc-date "T" utc-hhmmss "Z" utc-date = 8DIGIT ; < YYYYMMDD > utc-hhmmss = 6DIGIT [ "." 1*DIGIT ] ; < HHMMSS.fraction >
Examples for time-interval URI specifications with different time schemes are:
http://example.com/audio.anx?t=smpte-25:10:07:33:06/10:07:55:00 (for a temporal interval between 36453.25s - 36475s) http://example.com/audio.anx#t=npt:10:07:33.25 (for a temporal interval between 36453.25s and the end of the file/stream) http://example.com/audio.anx?t=clock:20021107T173045.25Z (for Thu Jul 11 05:30:45 UTC 2002 and a quarter seconds)
The semantic interpretation of time specifications given with any of the schemes depends on the resource. With every resource there are two associated basetimes: a UTC basetime which may e.g. specify the creation time of the resource, and a playback basetime used for display in a user agent while presenting the resource.
The playback basetime of a resource defaults to 0 seconds unless the resource has a different basetime associated with it. A contrasting example: in professional video production, the first frame of video of a program normally refers to a SMPTE basetime of 01:00:00:00, not 00:00:00:00. This practice arose from the requirements of program production and analog videotape recording technology, and it has subsequently become a uniform, almost ironclad practice worldwide. Associating such a practice to a digital video resource requires a way to store that basetime with the resource and interpreting it correctly when addressing via temporal URIs. Annodex provides such a mapping through a field in its headers that stores the playback basetime. CMML has a tag in its stream element for it.
Examples: If a resource has an associated basetime of 3600 seconds, and the given temporal fragment offset is 4000 sec, only a seek of 400 sec into the resource is required. If the basetime is given as clock time 20001010T142211.23Z and the temporal offset specified is 20001010T145511.23Z, an offset of 33 minutes into the resource is requested.
The UTC basetime of a resource defaults to being non-specified. Associating such a UTC basetime with a resource requires a way to store that basetime with the resource. For example, for a resource that is a file on a server, it may be chosen to be the time of storage of that resource. Annodex also provides a field in its headers to store the UTC basetime, and CMML has a tag for it.
The semantic interpretation of temporal intervals is as IN and OUT times like the conventions in use for editing media content: [time_from;time_to[ . This means that the interval stops just at the end time. The reasoning is that it just works when concatenating two intervals that follow directly upon each other.
Time-continuous resources often come with high bandwidth requirements, so a HTTPFielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, Hypertext Transfer Protocol -- HTTP/1.1, June 1999. server SHOULD serve out only the queried time interval of a base resource to avoid unnecessary network load. For example, a 1 hour Digital Video (DV format) requires about 25 GB (MPEG-2 reduces that to about 3 GB). This also significantly reduces the delay for the user agent for receiving relevant data.
A user agent that sends a URI that includes a temporal query to a HTTP server expects the server to return just the subparts of the base resource that it is querying for. It expects to be notified by the server if the server cannot resolve the query such that it may take appropriate action.
The HTTP protocol specifies that a server MUST return a "404 Not Found" error message on URI requests which cannot be resolved. A URI with a query component is a different URI than the same URI without a query component, so if it cannot be resolved, a "404 Not Found" is expected . However, most current implementations of HTTP servers regard the query component as a relative to the same URI without the query component and therefore support a somewhat non-conformant resolution of such a URI request: if they cannot resolve the query component, they will try to resolve the same URI without the query component. This makes it difficult for a user agent to find out whether a temporal query component was actually resolved or not.
To address this issue, a HTTP server that is capable of resolving temporal URI requests on a specified resource MUST return an additional accept header field that indicates that it can handle the temporal URI addressing and for which time schemes it can handle it. The header field is called "X-Accept-TimeURI" and the value is a list of time schemes, e.g. "X-Accept-TimeURI: npt, smpte-24, smpte-25, smpte-30, smpte-50, smpte-60". This request header is included for all URI requests to resources on which the HTTP server can resolve a temporal URI request. A user agent SHOULD check the "X-Accept-TimeURI" field to decide whether its temporal URI request has been honoured and thus the results can be displayed accurately.
Caching HTTP/1.1Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, Hypertext Transfer Protocol -- HTTP/1.1, June 1999. proxy servers allow storage of requested Web resources closer to the requesting user agent and reuse by other close-by user agents, reducing bandwidth usage and access time. The HTTP/1.1 caching mechanisms also works for time-based Web resources. However, complete time-based Web resources, such as Annodex resources, are often memory-intensive. User agents may more frequently request URIs with temporal queries than the full resource. Therefore, a larger impact on bandwidth usage is expected from caching the temporal URI queries as they are independent resources.
The defined caching mechanism in HTTP/1.1 for subranges of a resource is based on storage of byte subranges. For time-based Web resources for which it is possible to map a temporal URI query to a set of byte subranges on the base resource, URIs with time-queries can also be stored in a proxy's cache. To this end, the HTTP server MUST ensure that the core data that relates to the temporal subpart is bitwise identical to the original data - otherwise a byte range cannot be defined. This is achieved for Annodex subresources by changing only the control section but not the data section on remuxing, as described in the Annodex specifiationPfeiffer, S., Parker, C. and A. Pang, The Annodex exchange format for time-continuous data files, Version 3.0 (work in progress), March 2005..
Mapping of temporal URI queries to byte ranges can only happen on the origin server, being the only component that holds the base resource and can thus understand the relationship between time and bytes. The caching mechanism in HTTP/1.1 for byte ranges is based on the user agent requesting a URI with a "Range" request header that specifies the byte ranges. Thus, an additional agent-driven negotiation for delivery of the byte range mapping prior to the "Range" request is introduced to enable support of temporal URI queries.
A request header of "X-Accept-Range-Redirect" is required to indicate to the server that a mapping of the temporal URI query parameters to a byte range is requested rather than delivery of the query-part of the resource straight away. As this field initiates the server to provide a different response than if this field was not available, the server MUST include into its response a message header of "Vary: X-Accept-Range-Redirect". It MAY also indicate with "Accept-Ranges: bytes" that it is able to accept byte range requests. And it MAY indicate with "X-Accept-TimeURI" that it has processed the temporal URI query request.
The server will return a list of the byte ranges that the user agent should ask for in another additional response header field: "X-Range-Redirect". It will also need to redirect the user agent to another resource, namely the base resource, which it provides in the "Location" header field. Data that is specific to the URI request with the given time-query MUST then be returned to the user agent in the message body, such as for example an adapted control section of an Annodex file. The response is a "200 OK" as the request was satisfied with this response.
After this, the user agent has all the information it requires to post another GET request, this time for the base resource only and including a "Range" request header field.
In its response, the server includes the requested one or several byte ranges. If several byte ranges are required, the response will be a multipart message as defined in the HTTP/1.1 specificationFielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, Hypertext Transfer Protocol -- HTTP/1.1, June 1999.. The response message headers include the "Accept-Ranges: bytes" header, and the "Vary: Range" header, and provides the byte range(s) in the "Content-Range" header.
This is an example HTTP message exchange:
GET http://example.com/video.anx?t=npt:15.2 HTTP/1.1 Accept: application/x-annodex X-Accept-Range-Redirect: bytes
HTTP/1.1 200 OK Date: Fri Feb 11 14:47:12 EST 2005 Server: Apache/2.0(Unix) Content-Type: application/x-annodex X-Range-Redirect: bytes=777- Vary: X-Accept-Range-Redirect Accept-Ranges: bytes Location: http://example.com/video.anx X-Accept-TimeURI: npt, smpte-25 Message body: control section of video.anx?t=npt:15.2
GET http://example.com/video.anx HTTP/1.1 Accept: application/x-annodex Range: bytes=777-
HTTP/1.1 200 OK Date: Fri Feb 11 14:49:08 EST 2005 Server: Apache/2.0(Unix) Content-Type: application/x-annodex Content-Range: bytes 777- Vary: Range Accept-Ranges: bytes X-Accept-TimeURI: npt, smpte-25 Message body: video.anx from byte position 777 onwards
The X-Accept-Range-Redirect request header field prompts the server to reply with a byte range specification that maps the queried time ranges of a URI.
X-Accept-Range-Redirect = "X-Accept-Range-Redirect" ":" "bytes"
The X-Range-Redirect response header field provides a list of byte ranges to which the server redirects a user agent for finding the rest of the data that was requested.
X-Range-Redirect = "X-Range-Redirect" ":" ranges-specifier
An example of this field is:
The X-Accept-TimeURI response header field returns for a timed URI query what time schemes it can resolve and thus implicitly also whether it has resolved it.
X-Accept-TimeURI = "X-Accept-TimeURI" ":" 1#timescheme )
An example of this field is:
X-Accept-TimeURI: npt, smpte-24, smpte-25, smpte-30-drop, smpte-30
Initial discussions within the AV Transport Working Goup have started about how to use temporal URI addressing over RTP/RTSP. It doesn't seem to make sense to distinguish between fragments and queries as in the streaming scenario everything is focused on being performed on the server. Therefore the idea is not to bother with query specifications and only focus on fragment specifications.
When interpreting temporal fragment offsets in RTP/RTSP, the user agent transforms it into a Range specification in the PLAY request header field. Multiple time ranges are easily queued by several PLAY requests.
For example, a requested URI of rtsp://foo.bar/nemo#t=npt:10 will e.g. result in the following PLAY request:
PLAY rtsp://foo.bar/nemo RTSP 1.0 CSeq: 2 Session: 12345678 Range: npt=10-
An implementation of this specification has not been put forward yet.
Also note that RealNetworks is using a different syntax for querying temporal intervals of RealMedia over RTP/RTSP.
This specification does not create any new security issues beyond the ones already specified for URIs in RFC 3986Berners-Lee, T., Fielding, R. and L. Masinter, Uniform Resource Identifiers (URI): Generic Syntax, January 2005..
|||Pfeiffer, S., Parker, C. and A. Pang, "The Annodex exchange format for time-continuous data files, Version 3.0 (work in progress)", I-D draft-pfeiffer-annodex-02.txt, March 2005.|
|||Pfeiffer, S., Parker, C. and A. Pang, "The Continuous Media Markup Language (CMML), Version 2.0 (work in progress)", I-D draft-pfeiffer-cmml-02.txt, March 2005.|
|||Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", RFC 2119, BCP 14, March 1997.|
|||Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.|
|||Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.|
|||Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 3986, January 2005.|
|||The Society of Motion Picture and Television Engineers, "SMPTE STANDARD for Television, Audio and Film - Time and Control Code", ANSI 12M-1999, September 1999.|
|||ISO, TC154., "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO 8601, 2000.|
|Commonwealth Scientific and Industrial Research Organisation CSIRO, Australia|
|PO Box 76|
|Epping, NSW 1710|
|Phone:||+61 2 9372 4180|
|Conrad D. Parker|
|Commonwealth Scientific and Industrial Research Organisation CSIRO, Australia|
|PO Box 76|
|Epping, NSW 1710|
|Phone:||+61 2 9372 4222|
|Andre T. Pang|
|Commonwealth Scientific and Industrial Research Organisation CSIRO, Australia|
|PO Box 76|
|Epping, NSW 1710|
|Phone:||+61 2 9372 4222|
The authors greatly acknowledge the contributions of Rob Collins, Zen Kavanagh, and Andrew Nesbit in developing this specification. We also thank Bill Miller and Oliver Morgan of the SMPTE, Dave Singer from Apple Computer Inc., and Dean Blackketter for their contributions.
The many comments on this document from the URI discussion group at the W3C (firstname.lastname@example.org), especially the comments from Larry Masinter, Al Gilman and Martin Duerst and others have strongly shaped the current format.
Many thanks also to the Audio/Video Transport working group at the IETF (email@example.com), foremost to Magnus Westerlund, for giving valuable feedback on how to improve the specification and picking up the discussion around how to use the scheme on RTP/RTSP.
Last but not least thanks go to the ISO/MPEG working group with whom harmonisation in addressing formats is still pursued - thanks to Ian Burnett, Myriam Amielh, Ernest Wan, and Gerrard Drury.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at firstname.lastname@example.org.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
Funding for the RFC Editor function is currently provided by the Internet Society.