From XiphWiki
Revision as of 00:15, 30 December 2009 by Rillian (talk | contribs) (RFC 3803 defines an integer version of this header)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

We've been using the Content-Duration message header with http servers to provide the length (in time) of a particular Ogg physical bitstream. This speeds up ui display and, if Content-Length is also set, allows faster seeking dispatch over remote protocols by priming the binary search with an initial average bitrate.

The header specifies the duration of a temporal-tracked media resource in decimal seconds, e.g.

  Content-Duration: 2189.242

This is intended to be the playback duration of the resource, regardless of any time offset in internal timestamps.

This header is already documented for MIME, with integer instead of fractional decimal seconds, in RFC 3803.

Older applications used X-Content-Duration instead. This SHOULD be supported by user agents for backwards compatibility with older server implementations, but new servers should use Content-Duration. This page is a draft spec for registering that message header.

Question: should we allow the [[[DDD]:HH]:MM]:SS.sss format as well? It's more work to parse, but seems more natural for a message header.


  Header field name: Content-Duration
     The name proposed for the new header field.  This SHOULD conform
     to the field name specification details noted in Section 4.1.
  Applicable protocol: http (applicable to mime in general?)
     Specify "mail" (RFC 2822), "mime" (RFC 2045), "http" (RFC 2616),
     "netnews" (RFC 1036), or cite any other standards-track RFC
     defining the protocol with which the header is intended to be
  Status: provisional
     Specify: "provisional".  This will be updated if and when the
     header registration is subsequently moved to the permanent
  Author/Change controller: Ralph Giles <> Foundation
     The name, email address, and organization name of the submission
     author, who may authorize changes to or retraction of the
     repository entry.  A postal address, home page URI, telephone and
     fax numbers may also be included.
     If the proposal comes from a standards body working group, give
     the name and home page URI of the working group, and an email
     address for discussion of or comments on the specification.
  Specification document(s):
     Reference to document that specifies the header for use with the
     indicated protocol.  The document MUST be an RFC, a current
     Internet-draft or the URL of a publicly accessible document (so
     IANA can verify availability of the specification).  An indication
     of the relevant sections MAY also be included, but is not
  Related information:
     Optionally, citations to additional documents containing further
     relevant information.