Network Working GroupS. Pfeiffer
Internet-DraftC. Parker
Expires: June 30, 2004A. Pang
 December 31, 2003

Specifying time intervals in URI queries and fragments of time-based Web resources (BCP)


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

The list of Internet-Draft Shadow Directories can be accessed at

This Internet-Draft will expire on June 30, 2004.

Copyright Notice

Copyright (C) The Internet Society (2003). All Rights Reserved.


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.

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].

Table of Contents

1.  Introduction
2.  Incorporating temporal addressing into the Generic URI Scheme
3.  Temporal addressing through URI queries
4.  Temporal addressing through URI fragments
5.  Time schemes
6.  Intended usage
6.1  Rollout with HTTP
6.2  Rollout with RTP/RTSP
7.  Security considerations
8.  ChangeLog
§  References
§  Authors' Addresses
A.  Acknowledgements
§  Intellectual Property and Copyright Statements


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.


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 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.


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:


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:


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.

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

"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:
  (for a temporal interval between 36453.25s - 36475s)
  (for a temporal interval between 36453.25s and the end of the file/stream)
  (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 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.


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



7. Security considerations

This specification does not create any new security issues beyond the ones already specified for URIs in RFC 2396[2].


8. ChangeLog


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.


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.



[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
Phone:  +61 2 9325 3141
  Conrad D. Parker
  Commonwealth Scientific and Industrial Research Organisation CSIRO, Australia
  Locked Bag 17
  North Ryde, NSW 2113
Phone:  +61 2 9325 3133
  Andre T. Pang
  Commonwealth Scientific and Industrial Research Organisation CSIRO, Australia
  Locked Bag 17
  North Ryde, NSW 2113
Phone:  +61 2 9325 3156


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 (, 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 (, 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.


Intellectual Property Statement

Full Copyright Statement