Network Working Group S. Pfeiffer
Internet-Draft C. Parker
Expires: August 25, 2003 CSIRO
February 24, 2003
Syntax of temporal URI fragment specifications
draft-pfeiffer-temporal-fragments-00
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 August 25, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document specifies a syntax for using time offsets as the
fragment portion of a URI. Such fragment identifiers are useful to
directly access points of interest 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 syntax is closely related to the specification of
relative timestamps of the RTSP protocol parameters as given in RFC
2326 [3].
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Pfeiffer & Parker Expires August 25, 2003 [Page 1]
Internet-Draft Temporal URI Fragments February 2003
document are to be interpreted as described in RFC 2119 [1].
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Temporal fragment specification . . . . . . . . . . . . . . . 4
3. Time schemes . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1 NPT time codes . . . . . . . . . . . . . . . . . . . . . . . . 6
3.2 SMPTE time codes . . . . . . . . . . . . . . . . . . . . . . . 6
3.3 UTC time codes . . . . . . . . . . . . . . . . . . . . . . . . 7
3.4 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.5 Time interpretation . . . . . . . . . . . . . . . . . . . . . 8
4. Intended usage . . . . . . . . . . . . . . . . . . . . . . . . 9
5. Security considerations . . . . . . . . . . . . . . . . . . . 10
References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 11
A. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 13
Pfeiffer & Parker Expires August 25, 2003 [Page 2]
Internet-Draft Temporal URI Fragments February 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 such resources through a temporal
URI fragment syntax. In this way, points of interest 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 browsing and searching of time-continuous media. The
interpretation of the temporal fragment is however dependent on the
URI scheme in use and the type of resource referenced.
Pfeiffer & Parker Expires August 25, 2003 [Page 3]
Internet-Draft Temporal URI Fragments February 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. This is the relevant extract of RFC 2396's URI
description in BNF:
URI-reference = [ absoluteURI | relativeURI ] [ "#" fragment ]
fragment = *uric
uric = reserved | unreserved | escaped
reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |
"$" | ","
unreserved = alphanum | mark
mark = "-" | "_" | "." | "!" | "~" | "*" | "'" |
"(" | ")"
escaped = "%" hex hex
hex = digit | "A" | "B" | "C" | "D" | "E" | "F" |
"a" | "b" | "c" | "d" | "e" | "f"
alphanum = alpha | digit
alpha = lowalpha | upalpha
lowalpha = "a" | "b" | "c" | "d" | "e" | "f" | "g" | "h" | "i" |
"j" | "k" | "l" | "m" | "n" | "o" | "p" | "q" | "r" |
"s" | "t" | "u" | "v" | "w" | "x" | "y" | "z"
upalpha = "A" | "B" | "C" | "D" | "E" | "F" | "G" | "H" | "I" |
"J" | "K" | "L" | "M" | "N" | "O" | "P" | "Q" | "R" |
"S" | "T" | "U" | "V" | "W" | "X" | "Y" | "Z"
digit = "0" | "1" | "2" | "3" | "4" | "5" | "6" | "7" |
"8" | "9"
Temporal fragments start with the reserved character "@",
representing the time-continuous resource "at" a certain temporal
offset. As it is a reserved character, it can only be used for
delimiting the structure of a URI component. No other specification
of the use of the "@" character in URI fragments is published.
Therefore, reserving the "@" character for temporal URI fragments is
possible without breaking interoperability with existing URI
implementations.
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
Pfeiffer & Parker Expires August 25, 2003 [Page 4]
Internet-Draft Temporal URI Fragments February 2003
protocol parameters as given in RFC 2326 [3]. The BNF for temporal
URI fragments is:
temporal-fragment = "@" [ timescheme "=" ] 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 are
described in the next section.
The specification format of the timespec value is dependent on the
timescheme and therefore also given in the next section. There are
however some special values that are available for every timescheme.
Their interpretation is dependent on the retrieval context. The
special values are:
o start - specifying the beginning of a file/stream.
o now - specifying the current stream offset.
Pfeiffer & Parker Expires August 25, 2003 [Page 5]
Internet-Draft Temporal URI Fragments February 2003
3. Time schemes
A time scheme is a short identifier for a type of time specification.
The following time schemes are available:
o npt (Normal Play Time; base of seconds)
o smpte (Society of Motion Picture and Television Engineers time
code; base of 30 fps)
o smpte-30-drop (SMPTE with base of 29.97 fps)
o smpte-25 (SMPTE with base of 25 fps)
o clock (Universal Time Code UTC base of clock time)
3.1 NPT time codes
Normal Play Time (NPT) is the time a user agent displays for a time-
continuous resource. NPT 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. The BNF for these
timespecs is:
npt-time = npt-sec | npt-hhmmss
npt-sec = *digit [ "." *digit ]
npt-hhmmss = npt-hh ":" npt-mm ":" npt-ss [ "." *digit ]
npt-hh = *digit
npt-mm = 2digit
npt-ss = 2digit
2digit = ["0" | "1" | "2" | "3" | "4" | "5"] digit
3.2 SMPTE time codes
The Society of Motion Picture and Television Engineers time code
(SMPTE) is also the time a user agent displays for a time-continuous
resource. This time code is optimized for frame level access
accuracy. SMPTE is specified as HH:MM:SS:FF.sf, where HH=hours,
MM=minutes, SS=second, FF=frames, and sf=subframes (one-hundredth of
a frame). Negative values are not allowed. There are three
different SMPTE timecode specifications depending on the framerate:
"smpte-time" with a framerate of 30 fps, "smpte-25-time" with a
Pfeiffer & Parker Expires August 25, 2003 [Page 6]
Internet-Draft Temporal URI Fragments February 2003
framerate of 25 fps, and "smpte-drop-30-time" with a framerate of
29.97 fps. The BNF for the timespec is:
smpte-time = smpte-hh ":" smpte-mm ":" smpte-ss [ ":" smpte-ff ]
[ "." smpte-sf ]
smpte-hh = *digit
smpte-mm = 2DIGIT
smpte-ss = 2DIGIT
smpte-ff = "0" | "1" | "2" digit
smpte-sf = digit digit
2DIGIT = "0" | "1" | "2" | "3" | "4" | "5" digit
3.3 UTC time codes
Universal Time Codes (UTC) are specified in GMT format according to
ISO 8601 [4], compressed form. This absolute time builds a
relationship to a real-world clock time for a given resource, e.g.
the creation or storage time of the resource. 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). The BNF for the
clock specification is:
utc-time = utc-date "T" utc-hhmmss "Z"
utc-date = utc-year utc-month utc-day
utc-hhmmss = utc-hh utc-mm utc-ss ["." utc-fraction]
utc-year = digit digit digit digit
utc-month = "01" | "02" | "03" | "04" | "05" | "06" |
"07" | "08" | "09" | "10" | "11" | "12"
utc-day = "01" | "02" | ... | "29" | "30" | "31"
utc-hh = "00" | "01" | ... | "21" | "22" | "23"
utc-mm = 2DIGIT
utc-ss = 2DIGIT
utc-fraction = *digit
2DIGIT = "0" | "1" | "2" | "3" | "4" | "5" digit
3.4 Examples
Examples for these formats are:
Pfeiffer & Parker Expires August 25, 2003 [Page 7]
Internet-Draft Temporal URI Fragments February 2003
http://www.foo.bar/matrix.au#@smpte=10:07:33:24
http://www.foo.bar/matrix.au#@npt=10:7:33.8
http://www.foo.bar/matrix.au#@10:7:33.8
http://www.foo.bar/matrix.au#@npt=36453.8
(all four specify the same time)
rtp://www.foo.bar/archive.mpg#@clock=20021107T173045.25Z
(for Thu Jul 11 05:30:45 UTC 2002 and a quarter seconds)
rtp://www.foo.bar/news.mpg#@now
3.5 Time interpretation
The semantic interpretation of time specifications given with any of
the schemes depends on the resource. It is RECOMMENDED that servers
support all of the above time schemes and time specifications.
The temporal offset given in npt or smpte* is by default calculated
relative to a start time of 0 at the beginning of the resource.
Therefore, a user agent MUST take into account the temporal fragment
offset when displaying the playback time.
The UTC time specification is a real world date and time associated
with the resource. This may e.g. be the broadcast time, the
creation time or the archival time of the resource. The context
determines the meaning.
Examples: If a resource is requested with a temporal fragment offset
of 400 sec and is served out from that offset point, the user agent
MUST start the display of that resource with a "400 sec" playtime. A
resource that has a clock time of 20001010T142211.23Z and the
requested temporal offset is 20001010T145511.23Z, then the time 33
minutes into the resource is requested.
Pfeiffer & Parker Expires August 25, 2003 [Page 8]
Internet-Draft Temporal URI Fragments February 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 with
which temporal offsets are used is not restricted, though the http or
rtp protocols are especially suited. Protocol-specific error codes
MUST be used on URIs with temporal fragments where retrieval is
impossible (such as "fragment time is beyond end of file").
As time-continuous resources often have high bandwidth requirements,
it is advantageous to avoid the unnecessary network load associated
with delivering the portion of a resource prior to the desired
temporal offset. Hence it is RECOMMENDED that user agents do not
strip off the temporal fragment from a given URI before forwarding it
to a server.
Servers that receive a request for a resource with a temporal URI
fragment MUST provide the requested resource from the temporal offset
onwards, in a manner appropriate to the data format of the resource.
For example, when serving a request for a compressed media file at a
temporal offset, the file's initial headers may need to be repeated
verbatim, followed by the media data from a calculated byte offset.
If a server does not support temporal URI fragments, it MUST return a
protocol-specific error code. It especially MUST NOT serve out the
complete document as otherwise the user agent cannot distinguish
between an offset and a non-offset document. If unable to retrieve a
resource including a temporal URI fragment, user agents SHOULD retry
the request with the URI stripped off by the fragment and perform the
offset action locally.
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 August 25, 2003 [Page 9]
Internet-Draft Temporal URI Fragments February 2003
5. Security considerations
This specification does not create any new security issues beyond
those already specified for URIs in RFC 2396 [2].
Pfeiffer & Parker Expires August 25, 2003 [Page 10]
Internet-Draft Temporal URI Fragments February 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] 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, 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, 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 August 25, 2003 [Page 11]
Internet-Draft Temporal URI Fragments February 2003
Appendix A. Acknowledgements
The authors greatly acknowledge the contributions of Andre Pang and
Andrew Nesbit in developing this syntax.
Pfeiffer & Parker Expires August 25, 2003 [Page 12]
Internet-Draft Temporal URI Fragments February 2003
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 assigns.
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
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 August 25, 2003 [Page 13]