Network Working Group S. Pfeiffer Internet-Draft C. Parker Expires: September 20, 2005 A. Pang CSIRO March 19, 2005 Specifying time intervals in URI queries and fragments of time-based Web resources draft-pfeiffer-temporal-fragments-03 Status of this Memo 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 Notice Copyright (C) The Internet Society (2005). Abstract 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 Annodex [1] and CMML [2] Web resources, though it could be picked up by any other time-based Web Pfeiffer, et al. Expires September 20, 2005 [Page 1] Internet-Draft Time intervals in URIs March 2005 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 2119 [3]. Pfeiffer, et al. Expires September 20, 2005 [Page 2] Internet-Draft Time intervals in URIs March 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Incorporating temporal addressing into the Generic URI Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Temporal addressing through URI queries . . . . . . . . . . . 6 4. Temporal addressing through URI fragments . . . . . . . . . . 8 5. Time schemes . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. Implementation with HTTP . . . . . . . . . . . . . . . . . . . 12 6.1 Identifying enabled HTTP servers . . . . . . . . . . . . . 12 6.2 Caching URIs with temporal queries in HTTP proxy servers . . . . . . . . . . . . . . . . . . . . . . . . . 12 6.3 Overview of added HTTP message headers . . . . . . . . . . 15 6.3.1 X-Accept-Range-Redirect . . . . . . . . . . . . . . . 15 6.3.2 X-Range-Redirect . . . . . . . . . . . . . . . . . . . 15 6.3.3 X-Accept-TimeURI . . . . . . . . . . . . . . . . . . . 15 7. Implementation with RTP/RTSP . . . . . . . . . . . . . . . . . 16 8. Security considerations . . . . . . . . . . . . . . . . . . . 17 9. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 18 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 19 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 Intellectual Property and Copyright Statements . . . . . . . . 22 Pfeiffer, et al. Expires September 20, 2005 [Page 3] Internet-Draft Time intervals in URIs March 2005 1. Introduction 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 Annodex [1] and CMML [2] format Web resources over HTTP [4]. A possible implementation over RTP/RTSP [5] for Internet streaming is being specified. Usage with other protocols is possible, but has not been explored yet. Pfeiffer, et al. Expires September 20, 2005 [Page 4] Internet-Draft Time intervals in URIs March 2005 2. Incorporating temporal addressing into the Generic URI Scheme The Generic URI Scheme [6] 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 3986 [6] 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 3986 [6] 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 Annodex [1] and CMML [2] media types. This scheme can be adopted for other media types, by including it in the media type registration for that format. Pfeiffer, et al. Expires September 20, 2005 [Page 5] Internet-Draft Time intervals in URIs March 2005 3. Temporal addressing through URI queries 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: o http://example.com/video.anx?t=npt:15.2 --- video.anx is transferred from 15.2 seconds into video.anx to the end of the file/stream. o http://example.com/video.anx?t=15.2/18.7 --- video .anx is transferred from 15.2 seconds into video.anx to 18.7 seconds; the default time scheme "npt" is used. Pfeiffer, et al. Expires September 20, 2005 [Page 6] Internet-Draft Time intervals in URIs March 2005 o http://example.com/video.anx?t=npt:15.2/18.7,23 --- video.anx is transferred from 15.2s to 18.7s and from 23s to the end of the file/stream. o http://example.com/video.anx?t=npt:15.2/18.7,17.4/30.1 -- video.anx is transferred from 15.2 seconds into video.anx to 30.1 seconds. o http://example.com/video.anx?t=npt:15.2/18.7&t=23 --- invalid query parameters - MUST create an error message. Pfeiffer, et al. Expires September 20, 2005 [Page 7] Internet-Draft Time intervals in URIs March 2005 4. Temporal addressing through URI fragments 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: o http://example.com/video.anx#t=npt:15.2 --- specifies a view on the section between 15.2 seconds into video.anx and the end of the file/stream. o http://example.com/video.anx#t=15.2/18.7 --- specifies a view on the section between 15.2s and 18.7s of video.anx, with a default time scheme of "npt". o http://example.com/video.anx#t=npt:15.2/18.7,23 --- specifies a view on the section between 15.2s and 18.7s, as well as 23s to the end of the file/stream. o http://example.com/video.anx#t=npt:15.2/18.7,17.4/30.1 -- specifies a view on the section between 15.2s and 30.1s of video.anx. Pfeiffer, et al. Expires September 20, 2005 [Page 8] Internet-Draft Time intervals in URIs March 2005 5. Time schemes 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. o "npt" Normal Play Time; base of seconds as used in the RTSP standard [5] o "smpte" Society of Motion Picture and Television Engineers time codes as specified in the SMPTE time and control code standard [7] o "utc" Universal Time Code giving wall-clock time as specified in the ISO 8601 standard [8]. 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 codes [7] 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: Pfeiffer, et al. Expires September 20, 2005 [Page 9] Internet-Draft Time intervals in URIs March 2005 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. Pfeiffer, et al. Expires September 20, 2005 [Page 10] Internet-Draft Time intervals in URIs March 2005 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. Pfeiffer, et al. Expires September 20, 2005 [Page 11] Internet-Draft Time intervals in URIs March 2005 6. Implementation with HTTP 6.1 Identifying enabled HTTP servers Time-continuous resources often come with high bandwidth requirements, so a HTTP [4] 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. 6.2 Caching URIs with temporal queries in HTTP proxy servers Caching HTTP/1.1 [4] 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 Pfeiffer, et al. Expires September 20, 2005 [Page 12] Internet-Draft Time intervals in URIs March 2005 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 specifiation [1]. 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 Pfeiffer, et al. Expires September 20, 2005 [Page 13] Internet-Draft Time intervals in URIs March 2005 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 specification [4]. 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: 1. User Agent HTTP request: GET http://example.com/video.anx?t=npt:15.2 HTTP/1.1 Accept: application/x-annodex X-Accept-Range-Redirect: bytes 2. Server HTTP response: 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 3. User Agent HTTP request: GET http://example.com/video.anx HTTP/1.1 Accept: application/x-annodex Range: bytes=777- 4. Server HTTP response: 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 Pfeiffer, et al. Expires September 20, 2005 [Page 14] Internet-Draft Time intervals in URIs March 2005 6.3 Overview of added HTTP message headers 6.3.1 X-Accept-Range-Redirect 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" 6.3.2 X-Range-Redirect 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: X-Range-Redirect: bytes=500-600,1000- 6.3.3 X-Accept-TimeURI 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 Pfeiffer, et al. Expires September 20, 2005 [Page 15] Internet-Draft Time intervals in URIs March 2005 7. Implementation with RTP/RTSP 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. Pfeiffer, et al. Expires September 20, 2005 [Page 16] Internet-Draft Time intervals in URIs March 2005 8. Security considerations This specification does not create any new security issues beyond the ones already specified for URIs in RFC 3986 [6]. Pfeiffer, et al. Expires September 20, 2005 [Page 17] Internet-Draft Time intervals in URIs March 2005 9. ChangeLog draft-pfeiffer-temporal-fragments-01: o Extension of the number of available SMPTE time-schemes. Many thanks to Bill Miller and Oliver Morgan of the SMPTE for their input on these changes. o Deleted "start" and "now" as time specification values. o Extension of the temporal fragment addressing to also address temporal intervals, not only time points. o Added section that includes some key points of discussion where the existing URI standard contradicts the use of fragments for time-continuous data. draft-pfeiffer-temporal-fragments-02: o Full compatibility with existing URI standard specification is achieved by using both, query and fragment specifications for addressing. o Restriction of specification to http scheme (Web) only, as usage on other protocols (such as rtp/rtsp) still needs to be explored. o All addressing is interval based because an offset really implies a view onto the document from that point onwards. draft-pfeiffer-temporal-fragments-03: o Restricted the specification for Annodex and CMML currently with only a suggestion to adopt it for other formats. o Changed the specification of periods of time to be compatible with ISO 8601, i.e. replaced "-" with "/". This is also very useful for time specs that contain a "-" like most of the ISO 8601 specs. Thanks to Dean Blackketter for pointing it out. o Replaced the word "timebase" with the word "basetime" as that seems to be the more commonly used one to specify a timestamp for the start of a stream of time-sampled data. o Added a section on how to use timed URIs with HTTP. This includes caching Web proxies and added HTTP message headers. o Started a section on how to use timed URIs with RTP/RTSP. Some initial feedback from the AVT Working Group at IETF seems to indicate not to bother with rtsp queries and just to focus on fragments. This may not be quite conformant to the URI RFC because these RTP/RTSP fragments would be handled on the server - yet this has not been resolved for any use of fragments over RTP/RTSP. draft-pfeiffer-temporal-fragments-04: o Fixed some of the examples for the specification of samples with times, which should now include "t=". Pfeiffer, et al. Expires September 20, 2005 [Page 18] Internet-Draft Time intervals in URIs March 2005 10. References [1] 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, . [2] 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, . [3] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", RFC 2119, BCP 14, March 1997. [4] 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, . [5] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [6] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 3986, January 2005, . [7] The Society of Motion Picture and Television Engineers, "SMPTE STANDARD for Television, Audio and Film - Time and Control Code", ANSI 12M-1999, September 1999. [8] ISO, TC154., "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO 8601, 2000. Authors' Addresses Silvia Pfeiffer Commonwealth Scientific and Industrial Research Organisation CSIRO, Australia PO Box 76 Epping, NSW 1710 Australia Phone: +61 2 9372 4180 Email: Silvia.Pfeiffer@csiro.au URI: http://www.ict.csiro.au/Silvia.Pfeiffer/ Pfeiffer, et al. Expires September 20, 2005 [Page 19] Internet-Draft Time intervals in URIs March 2005 Conrad D. Parker Commonwealth Scientific and Industrial Research Organisation CSIRO, Australia PO Box 76 Epping, NSW 1710 Australia Phone: +61 2 9372 4222 Email: Conrad.Parker@csiro.au URI: http://www.ict.csiro.au/Conrad.Parker/ Andre T. Pang Commonwealth Scientific and Industrial Research Organisation CSIRO, Australia PO Box 76 Epping, NSW 1710 Australia Phone: +61 2 9372 4222 Email: Andre.Pang@csiro.au URI: http://www.ict.csiro.au/ Pfeiffer, et al. Expires September 20, 2005 [Page 20] Internet-Draft Time intervals in URIs March 2005 Appendix A. Acknowledgements 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 (uri@w3.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 (avt@ietf.org), 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. Pfeiffer, et al. Expires September 20, 2005 [Page 21] Internet-Draft Time intervals in URIs March 2005 Intellectual Property Statement 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 ietf-ipr@ietf.org. Disclaimer of Validity 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 Statement 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Pfeiffer, et al. Expires September 20, 2005 [Page 22]