Network Working Group S. Pfeiffer Internet-Draft C. Parker Expires: December 6, 2003 CSIRO June 7, 2003 Syntax of temporal URI fragment specifications draft-pfeiffer-temporal-fragments-01 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 December 6, 2003. Copyright Notice Copyright (C) The Internet Society (2003). All Rights Reserved. Abstract This document specifies a syntax for temporal offsets and intervals as URI fragments. Such fragment identifiers are useful to directly access temporal offset points and intervals in time-continuous resources such as audio and video. The URI fragment syntax specified in this document is comformant to the Generic URI Syntax as specified in RFC 2396 [2]. 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 & Parker Expires December 6, 2003 [Page 1] Internet-Draft Temporal URI Fragments June 2003 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Temporal fragment specification . . . . . . . . . . . . . . . 4 3. Time schemes . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Intended usage . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Security considerations . . . . . . . . . . . . . . . . . . . 9 6. Disucssion points to be resolved . . . . . . . . . . . . . . . 10 6.1 Interpretation of temporal fragments on server . . . . . . . . 10 7. ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . 11 References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 12 A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Pfeiffer & Parker Expires December 6, 2003 [Page 2] Internet-Draft Temporal URI Fragments June 2003 1. Introduction Many resources on the Internet are time-continuous data such as audio or video files or streams. This document describes a standard way of addressing temporal offsets into and temporal intervals of such resources through a temporal URI fragment syntax. In this way, points of interest and intervals in time-continuous files or streams can be directly accessed. The aim is to make it simple to incorporate infrastructure into the Web which supports the browsing and searching of time-continuous media. The interpretation of the temporal fragment is however dependent on the URI scheme in use and the content type of the resource referenced. Pfeiffer & Parker Expires December 6, 2003 [Page 3] Internet-Draft Temporal URI Fragments June 2003 2. Temporal fragment specification Fragments are generally specified in a URI after the crosshatch ("#") character. The format of fragment identifiers specified in this document is conformant to the URI RFC 2396 [2] for fragment identifiers, but retricts their use to an interpretation on the user agent only. See section 5 for a proposed alternative usage. Temporal fragments start with the reserved character "@", representing the time-continuous resource "at" a certain temporal offset. The "@" character is reserved and this specification is giving it a reserved purpose. Having the "@" character at the start simplifies parsing of a temporal fragment specification, helping to e.g. distinguish between a fragment given by name as "#smpte-25" and a fragment given as a temporal offset as "#@smpte-25=01:01:01:01". The specification of a temporal fragment offset itself is given as a name-value pair, where the name specifies a time scheme to use and the value is the time specification itself. The syntax is closely related to the specification of relative timestamps of the RTSP protocol parameters as given in RFC 2326 [3]. Temporal intervals can be specified as well. This is achieved by adding the reserved character "-" and another time specification that adheres to the time scheme used for the specification of the first time point. The BNF for temporal fragment offsets and temporal intervals is: temporal-fragment = "@" [ timescheme "=" ] timespec ["-" timespec] timescheme = *unreserved timespec = *uric There are several time schemes that can be used. The default time scheme is "npt" (normal play time). The available time schemes and their specifications are described in the next section. Pfeiffer & Parker Expires December 6, 2003 [Page 4] Internet-Draft Temporal URI Fragments June 2003 3. 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 (XXX this needs to be discussed XXX). 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]). 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-spec = "npt=" npt-time npt-time = 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 "smpte-25=" SMPTE time with a 25 fps basis "smpte-30=" SMPTE time with a 30 fps basis Pfeiffer & Parker Expires December 6, 2003 [Page 5] Internet-Draft Temporal URI Fragments June 2003 "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-spec = smpte-type "=" smpte-time smpte-type = "smpte-24" | "smpte-24-drop" | "smpte-25" | "smpte-30" | "smpte-30-drop" | "smpte-50" | "smpte-60" | "smpte-60-drop" smpte-time = 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-spec = "clock=" utc-time utc-time = utc-date "T" utc-hhmmss "Z" utc-date = 8DIGIT utc-hhmmss = 6DIGIT [ "." *DIGIT ] Examples for specifications of temporal fragment offsets are: http://www.foo.bar/matrix.au#@smpte-25=10:07:33:06 http://www.foo.bar/matrix.au#@npt=10:7:33.25 http://www.foo.bar/matrix.au#@10:7:33.25 http://www.foo.bar/matrix.au#@npt=36453.25 (all four specify the same time point) rtp://www.foo.bar/matrix.mpg#@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. The playback timebase of a resource defaults to 0 seconds if the Pfeiffer & Parker Expires December 6, 2003 [Page 6] Internet-Draft Temporal URI Fragments June 2003 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. Examples for specifications of temporal intervals are: http://www.foo.bar/matrix.au#@smpte-25=10:07:33:05-10:07:37:21 http://www.foo.bar/matrix.au#@npt=10:7:33.25-10:7:37.8 http://www.foo.bar/matrix.au#@10:7:33.25-10:7:37.8 http://www.foo.bar/matrix.au#@npt=36453.25-36457.8 (all four specify the same temporal interval) rtp://www.foo.bar/matrix.mpg#@clock=20021107T173045.25Z-20021107T173049.80Z The semantic interpretation of these 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 & Parker Expires December 6, 2003 [Page 7] Internet-Draft Temporal URI Fragments June 2003 4. Intended usage The temporal fragment specification scheme is intended to be used on time-continuous resources. An example of such resources are all resources of MIME types "audio/*" and "video/*". The protocol through which these resources are accessed are expected to be mainly http or rtp/rtsp, which are especially suited for such resources. It is RECOMMENDED that user agents do not strip off the temporal fragment from a given URI before forwarding it to a server. [XXX: This is contrary to the current prescription in the URI standard and needs to get resolved -> see Section 6.] A retrieval action on a URI that includes a temporal fragment SHOULD result in a time-continuous resource that starts at the given temporal offset. As time-continuous resources often come with high bandwidth requirements, this 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, but this format must be prepared for addressing high-quality, high-resolution time-continuous bitstreams of the future). Serving out only the requested interval of a resource also significantly reduces the delay for the user agent for receiving relevant data. Alternatively, the user agent MAY wait until the retrieval action has failed, then resend the URI with the fragment stripped off and perform the offset action locally on the retrieved resource. Servers that support the temporal fragment offset MUST implement a retrieval action of time-continuous resources with such fragment 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 fragment offset and thus enable direct networked access to content in time-continuous resources. Also network proxies may begin to understand such temporal offsets and can exploit them for caching. Pfeiffer & Parker Expires December 6, 2003 [Page 8] Internet-Draft Temporal URI Fragments June 2003 5. Security considerations This specification does not create any new security issues beyond the ones already specified for URIs in RFC 2396 [2]. Pfeiffer & Parker Expires December 6, 2003 [Page 9] Internet-Draft Temporal URI Fragments June 2003 6. Disucssion points to be resolved 6.1 Interpretation of temporal fragments on server In the current version of the URI standard [2], it is prescribed that fragment specifications get interpreted by the user agent. Therefore, the intended use of fragments to retrieve only a temporal interval of the time-continuous data or the data from a certain offset point onwards is not generally allowed. However, there are ways to effectively get around this restriction by using (mis-using?) communication protocols. When using http, we can invent a new protocol parameter that gets filled by the user agent with the temporal fragment specification and that gets interpreted by the server. If we don't do that, we seriously defect http from being usable for time-continuous media in the future. When using rtp/rtsp, a client can strip off the fragment specification and map it onto the Range header field of the rtsp protocol, which will then tell the server which subpart of the time-continuous data bistream to serve out. A much cleaner way to resolve this problem would be to change the URI standard to allow for a server-side interpretation of fragment offsets after all other actions have been performed on the resource. This will make it independent of the protocol in use and it will enable intermediate proxies to store and forward parts of a media resource. It is then the user agent's choice whether or not to strip off the fragment offset and interpret it locally after the retrieval action or to forward it to the server with an expectation to receive only that subpart of the resource. Servers are not forced to implement that specification. It is however necessary to return an error if they cannot handle temporal fragment specifications to avoid a double offset action by both server and client. Pfeiffer & Parker Expires December 6, 2003 [Page 10] Internet-Draft Temporal URI Fragments June 2003 7. 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. Pfeiffer & Parker Expires December 6, 2003 [Page 11] Internet-Draft Temporal URI Fragments June 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. 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/ 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/ Pfeiffer & Parker Expires December 6, 2003 [Page 12] Internet-Draft Temporal URI Fragments June 2003 Appendix A. Acknowledgements The authors greatly acknowledge the contributions of Andre Pang and Andrew Nesbit in developing this syntax. We also thank the SMPTE for their contributions and the URI discussion group at the W3C (uri@w3.org) for their many comments on this document. Pfeiffer & Parker Expires December 6, 2003 [Page 13] Internet-Draft Temporal URI Fragments June 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 & Parker Expires December 6, 2003 [Page 14] Internet-Draft Temporal URI Fragments June 2003 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Pfeiffer & Parker Expires December 6, 2003 [Page 15]