[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

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,
        <http://www.annodex.net/TR/annodex.txt>.

   [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,
        <http://www.annodex.net/TR/cmml.txt>.

   [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,
        <http://www.ietf.org/rfc/rfc2616.txt>.

   [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,
        <http://www.ietf.org/rfc/rfc3986.txt>.

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


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/