Network Working Group S. Pfeiffer Internet-Draft C. Parker Expires: June 30, 2004 A. Pang CSIRO December 31, 2003 Specifying time intervals in URI queries and fragments of time-based Web resources (BCP) draft-pfeiffer-temporal-fragments-02 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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 June 30, 2004. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document specifies a syntax for addressing time intervals within time-based Web resources through URI queries and fragments. It suggests a Best Current Practice (BCP) for any time-based Web resource for which temporal subparts may be requested and retrieved. This enables, e.g., direct access to a clip of 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, but covers all kinds of Web resources that contain time-continuous information. Pfeiffer, et al. Expires June 30, 2004 [Page 1] Internet-Draft Time intervals in URIs December 2003 The URI query specification of this syntax implies that a Web server is capable to extract the given time subsections from the Web resource and serve that as another complete Web resource of the same type. Specifying a time point or interval through a URI fragment in contrast does not deliver a subpart of the Web resource - instead it is up to the application 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. This document is a proposal for a Best Current Practice. The authors strongly encourage anybody interested to explore the implementation of the syntax on different types of Web resources and contribute any findings. Current implementations work with Annodex [6] and CMML [7] format Web resources over HTTP. An implementation over e.g. RTP/RTSP for Internet streaming and for other protocols has not been explored yet. The syntax is also being explored within the ISO/MPEG standardisation body for addressing into MPEG-4 or MPEG-7 format resources. Also note that RealNetworks is using an different syntax for the query case for RealMedia over RTP/RTSP. 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 [1]. Pfeiffer, et al. Expires June 30, 2004 [Page 2] Internet-Draft Time intervals in URIs December 2003 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 . . . . . . . . . . 7 5. Time schemes . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. Intended usage . . . . . . . . . . . . . . . . . . . . . . . . 11 6.1 Rollout with HTTP . . . . . . . . . . . . . . . . . . . . . . 11 6.2 Rollout with RTP/RTSP . . . . . . . . . . . . . . . . . . . . 11 7. Security considerations . . . . . . . . . . . . . . . . . . . 12 8. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 13 References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 14 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 Intellectual Property and Copyright Statements . . . . . . . . 17 Pfeiffer, et al. Expires June 30, 2004 [Page 3] Internet-Draft Time intervals in URIs December 2003 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 Web/ Internet which supports the addressing and retrieval of temporal subparts of time-based Web resources, as well as the automated processing of such subparts e.g. for reusing them. 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 information that relates to a single timeline and can be addressed with the manner described in this specification. Pfeiffer, et al. Expires June 30, 2004 [Page 4] Internet-Draft Time intervals in URIs December 2003 2. Incorporating temporal addressing into the Generic URI Scheme The Generic URI Scheme [2] 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 2396 [2] specifies that URI queries identify a resource and thus a Web server has to 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 standard 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 2396 [2] also specifies that URI fragments identify a secondary resource by reference to a primary resource and that fragments get 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 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 gets 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 however not defined in this document - when a media type gets registered for the Web/Internet, the authors must explicitly define if a Web resource of that media type can be addressed through the time-interval URI addressing scheme defined here. Pfeiffer, et al. Expires June 30, 2004 [Page 5] Internet-Draft Time intervals in URIs December 2003 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: temporal-parameter = "t" "=" [ timescheme ":" ] temporal-intervalspec temporal-intervalspec = temporal-interval ["," temporal-intervalspec] temporal-interval = timespec ["-" timespec] timescheme = *unreserved timespec = *uric All temporal 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 temporal intervals MUST be interpreted by merging the intervals into one. It is not valid to give several temporal URI query parameters. They all need to be wrapped into a single specification. Examples are: o http://www.foo.bar/video.anx?t=15.2 --- video.anx is transferred from 15.2 seconds into video.anx to the end of the file/stream. o http://www.foo.bar/video.anx?t=15.2-18.7 --- video .anx is transferred from 15.2 seconds into video.anx to 18.7 seconds. o http://www.foo.bar/video.anx?t=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://www.foo.bar/video.anx?t=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://www.foo.bar/video.anx?t=15.2-18.7&t=23 --- invalid query parameters - MUST create an error message. Pfeiffer, et al. Expires June 30, 2004 [Page 6] Internet-Draft Time intervals in URIs December 2003 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. Again, the default is "npt". The BNF for a temporal URI fragment identifier is (reusing the temporal-intervalspec of the URI query section above): temporal-fragment = [ timescheme ":" ] temporal-intervalspec 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. Examples are: o http://www.foo.bar/video.anx#15.2 --- specifies a view on the section between 15.2 seconds into video.anx and the end of the file/stream. o http://www.foo.bar/video.anx#15.2-18.7 --- specifies a view on the section between 15.2s and 18.7s of video.anx. o http://www.foo.bar/video.anx#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://www.foo.bar/video.anx#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 June 30, 2004 [Page 7] Internet-Draft Time intervals in URIs December 2003 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 RTSTP standard [3]) o "smpte" (Society of Motion Picture and Television Engineers time codes as specified in the SMPTE time and control code standard [4]) o "utc" (Universal Time Code giving wall-clock time as specified in the ISO 8601 standard [5]). Specification as BNF: timescheme = npt-timescheme | smpte-timescheme | utc-timescheme timespec = npt-timespec | smpte-timespec | utc-timespec Thus, the available time schemes are: 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 npt-mm = 1*2DIGIT npt-ss = 1*2DIGIT SMPTE time codes [4] 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 Pfeiffer, et al. Expires June 30, 2004 [Page 8] Internet-Draft Time intervals in URIs December 2003 "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 [ ":" *2DIGIT ] smpte-hh = 1*2DIGIT smpte-mm = 1*2DIGIT smpte-ss = 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 utc-hhmmss = 6DIGIT [ "." *DIGIT ] Examples for time-interval URI specifications with different time schemes are: http://www.foo.bar/audio.anx?t=smpte-25:10:07:33:06-10:07:55:00 (for a temporal interval between 36453.25s - 36475s) http://www.foo.bar/audio.anx#npt:10:7:33.25 (for a temporal interval between 36453.25s and the end of the file/stream) http://www.foo.bar/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 timebases: a UTC timebase which may e.g. specify the creation time of the resource, and a playback timebase used for display in a user agent while viewing the resource. Pfeiffer, et al. Expires June 30, 2004 [Page 9] Internet-Draft Time intervals in URIs December 2003 The playback timebase of a resource defaults to 0 seconds if the resource has no other timebase associated with it. For example, with professional video production, the first frame of video of a program normally refers to a SMPTE timebase 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 timebase with the resource, which may or may not be possible, depending on the content type of the resource. Examples: If a resource has an associated timebase of 3600 seconds, and the given temporal fragment offset is 4000 sec, a seek time 400 sec into the resource is requested. If the timebase is given as clock time 20001010T142211.23Z and the temporal offset specified is 20001010T145511.23Z, the time 33 minutes into the resource is requested. The UTC timebase of a resource defaults to non-specified. Associating such a UTC timebase with a resource requires a way to store that timebase 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. The semantic interpretation of temporal intervals depends on the time scheme. Unless specified differently, the temporal intervals given are closed intervals, i.e. they start at the first time point and finish at the second time point: [time_from;time_to]. For SMPTE timecodes, however, it is conventional to express such temporal intervals as IN and OUT times for editing. Thus, the IN time specifies the first frame that is included in the interval and the OUT time specifies the first frame that is not included in the interval. Therefore, a SMPTE interval is specified as [time_from;time_to[, which explains the additional frame in the above example. Pfeiffer, et al. Expires June 30, 2004 [Page 10] Internet-Draft Time intervals in URIs December 2003 6. Intended usage The temporal URI interval specifications are intended to be used on resources that represent a specific timeline. An example of such resources are most resources of MIME types "audio/*" and "video/*". A retrieval action on a URI that includes a temporal URI query parameter MUST result in a time-continuous resource that is reduced to the given temporal intervals. As per HTTP standard, if the URI including the temporal query parameter cannot be resolved by the server, the server has to return a "404" error message. Time-continuous resources often come with high bandwidth requirements, so serving out only the queried time interval avoids unnecessary network load. For example, a 1 hour Digital Video (DV format) requires about 25 GB (MPEG-2 reduces that to about 3 GB). It also ignificantly reduces the delay for the user agent for receiving relevant data. 6.1 Rollout with HTTP Servers that support the temporal query format MUST implement a retrieval action of time-continuous resources with such query specifications by serving the requested resource from the temporal offset onwards. For many time-continuous resources - especially when in compressed format - this means that the server has to parse the structure of the resource and construct another valid resource from the original resource's header information and data frames. If a server cannot perform the fragment offset, it MUST return an error as otherwise the user agent cannot identify if the offset action was performed or not. It is expected that over time more servers and client applications understand and handle the temporal URI query parameters and thus enable direct networked access to content in time-continuous resources. Also Web proxies may begin to understand such temporal offsets and can exploit them for caching. 6.2 Rollout with RTP/RTSP [TBD] Pfeiffer, et al. Expires June 30, 2004 [Page 11] Internet-Draft Time intervals in URIs December 2003 7. Security considerations This specification does not create any new security issues beyond the ones already specified for URIs in RFC 2396 [2]. Pfeiffer, et al. Expires June 30, 2004 [Page 12] Internet-Draft Time intervals in URIs December 2003 8. ChangeLog draft-pfeiffer-temporal-fragments-01: 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. Deleted "start" and "now" as time specification values. Extension of the temporal fragment addressing to also address temporal intervals, not only time points. 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: Full compatibility with existing URI standard specification is achieved by using both, query and fragment specifications for addressing. Restriction of specification to http scheme (Web) only, as usage on other protocols (such as rtp/rtsp) still needs to be explored. All addressing is interval based because an offset really implies a view onto the document from that point onwards. Pfeiffer, et al. Expires June 30, 2004 [Page 13] Internet-Draft Time intervals in URIs December 2003 References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirements Levels", RFC 2119, BCP 14, March 1997. [2] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [3] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998. [4] The Society of Motion Picture and Television Engineers, "SMPTE STANDARD for Television, Audio and Film - Time and Control Code", ANSI 12M-1999, September 1999. [5] ISO, TC154., "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO 8601, 2000. [6] Pfeiffer, S., Parker, C. and A. Pang, "The Annodex annotation and indexing format for time-continuous data files, Version 2.0 (work in progress)", I-D draft-pfeiffer-annodex-01.txt, December 2003, . [7] Pfeiffer, S., Parker, C. and A. Pang, "The Continuous Media Markup Language (CMML), Version 2.0 (work in progress)", I-D draft-pfeiffer-cmml-01.txt, December 2003, . Authors' Addresses Silvia Pfeiffer Commonwealth Scientific and Industrial Research Organisation CSIRO, Australia Locked Bag 17 North Ryde, NSW 2113 Australia Phone: +61 2 9325 3141 EMail: Silvia.Pfeiffer@csiro.au URI: http://www.cmis.csiro.au/Silvia.Pfeiffer/ Pfeiffer, et al. Expires June 30, 2004 [Page 14] Internet-Draft Time intervals in URIs December 2003 Conrad D. Parker Commonwealth Scientific and Industrial Research Organisation CSIRO, Australia Locked Bag 17 North Ryde, NSW 2113 Australia Phone: +61 2 9325 3133 EMail: Conrad.Parker@csiro.au URI: http://www.cmis.csiro.au/Conrad.Parker/ Andre T. Pang Commonwealth Scientific and Industrial Research Organisation CSIRO, Australia Locked Bag 17 North Ryde, NSW 2113 Australia Phone: +61 2 9325 3156 EMail: Andre.Pang@csiro.au URI: http://www.ict.csiro.au/ Pfeiffer, et al. Expires June 30, 2004 [Page 15] Internet-Draft Time intervals in URIs December 2003 Appendix A. Acknowledgements The authors greatly acknowledge the contributions of Andre Pang and Andrew Nesbit in developing this syntax. We also thank Bill Miller and Oliver Morgan of the SMPTE for their contributions and Dave Singer from Apple Computer Inc. for his. 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 picking up the discussion around how to use the scheme on RTP/RTSP. This is now not covered in this document, but should be explored in the future, possibly in a different document. 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 June 30, 2004 [Page 16] Internet-Draft Time intervals in URIs December 2003 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any intellectual property 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; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication 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 implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. Full Copyright Statement Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assignees. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION Pfeiffer, et al. Expires June 30, 2004 [Page 17] Internet-Draft Time intervals in URIs December 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Pfeiffer, et al. Expires June 30, 2004 [Page 18]