index.html 152 KB

Raw Blame History Permalink

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
      "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en-us" lang="en-us">
<head>
  <meta http-equiv="content-type" content="text/html; charset=UTF-8" />
  <title>Media Fragments URI 1.0</title>
  <style type="text/css">
        /**/
code           { font-family: monospace; }

div.constraint,
div.issue,
div.note,
div.notice     { margin-left: 2em; }

ol.enumar      { list-style-type: decimal; }
ol.enumla      { list-style-type: lower-alpha; }
ol.enumlr      { list-style-type: lower-roman; }
ol.enumua      { list-style-type: upper-alpha; }
ol.enumur      { list-style-type: upper-roman; }

dt.label       { display: run-in; }

li, p           { margin-top: 0.3em;
                 margin-bottom: 0.3em; }

 .diff-chg       { background-color: yellow; }
 .diff-del       { background-color: red; text-decoration: line-through;}
 .diff-add       { background-color: lime; }

table          { empty-cells: show; }

table caption {
        font-weight: normal;
        font-style: italic;
        text-align: left;
        margin-bottom: .5em;
}

div.issue {
  color: red;
}
 .rfc2119 {
  font-variant: small-caps;
}

div.exampleInner pre { margin-left: 1em;
                       margin-top: 0em; margin-bottom: 0em}
div.exampleOuter {border: 4px double gray;
                  margin: 0em; padding: 0em}
div.exampleInner { background-color: #d5dee3;
                   border-top-width: 4px;
                   border-top-style: double;
                   border-top-color: #d3d3d3;
                   border-bottom-width: 4px;
                   border-bottom-style: double;
                   border-bottom-color: #d3d3d3;
                   padding: 4px; margin: 0em }
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
                    margin: 4px}

div.boxedtext {
   border: solid #bebebe 1px;
   margin: 2em 1em 1em 2em;
 }

span.practicelab {
   margin: 1.5em 0.5em 1em 1em;
   font-weight: bold;
   font-style: italic;
 }

span.practicelab   { background: #dfffff; }

 span.practicelab {
   position: relative;
   padding: 0 0.5em;
   top: -1.5em;
 }
p.practice
{
   margin: 1.5em 0.5em 1em 1em;
 }

@media screen {
 p.practice {
   position: relative;
   top: -2em;
   padding: 0;
   margin: 1.5em 0.5em -1em 1em;
}
}
/**/ </style>
  <link type="text/css" rel="stylesheet"
  href="http://www.w3.org/StyleSheets/TR/W3C-WD.css" />

</head>

<body>

<div class="head">
<p><a href="http://www.w3.org/"><img width="72" height="48" alt="W3C"
src="http://www.w3.org/Icons/w3c_home" /></a></p>

<h1><a id="title" name="title"></a>Media Fragments URI 1.0</h1>

<h2><a id="w3c-doctype" name="w3c-doctype"></a>W3C Working Draft 17 March
2011</h2>
<dl>
  <dt>This version:</dt>
    <dd><a
      href="http://www.w3.org/TR/2011/WD-media-frags-20110317">http://www.w3.org/TR/2011/WD-media-frags-20110317</a>
    </dd>
  <dt>Latest version:</dt>
    <dd><a
      href="http://www.w3.org/TR/media-frags">http://www.w3.org/TR/media-frags</a>
    </dd>
  <dt>Previous version:</dt>
    <dd><a
      href="http://www.w3.org/TR/2010/WD-media-frags-20100624">http://www.w3.org/TR/2010/WD-media-frags-20100624</a>
    </dd>
  <dt>Editors:</dt>
    <dd><a href="http://www.eurecom.fr/~troncy/">Raphaël Troncy </a>,
    EURECOM</dd>
    <dd><a href="http://multimedialab.elis.ugent.be/emannens">Erik Mannens
      </a>, IBBT Multimedia Lab, University of Ghent</dd>
    <dd><a href="http://blog.gingertech.net/">Silvia Pfeiffer </a>, W3C Invited
      Expert</dd>
    <dd><a href="http://multimedialab.elis.ugent.be/dvdeurse">Davy Van Deursen
      </a>, IBBT Multimedia Lab, University of Ghent</dd>
  <dt>Contributors:</dt>
    <dd><a
      href="http://www.deri.ie/about/team/member/Michael_Hausenblas/">Michael
      Hausenblas </a>, DERI, National University of Ireland, Galway</dd>
    <dd><a href="mailto:philipj@opera.com">Philip Jägenstedt </a>, Opera
      Software</dd>
    <dd><a href="http://www.cwi.nl/~jack/">Jack Jansen </a>, CWI, Centrum
      Wiskunde &amp; Informatica, Amsterdam</dd>
    <dd><a
      href="mailto:ylafon@w3.org">Yves
      Lafon </a>, W3C</dd>
    <dd><a href="http://www.kfish.org/">Conrad Parker </a>, W3C Invited
    Expert</dd>
</dl>

<p class="copyright"><a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2011 <a
href="http://www.w3.org/"><acronym
title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a
href="http://www.csail.mit.edu/"><acronym
title="Massachusetts Institute of Technology">MIT</acronym></a>, <a
href="http://www.ercim.org/"><acronym
title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>,
<a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>,
<a
href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>
and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document
use</a> rules apply.</p>
</div>
<hr />

<div>
<h2><a id="abstract" name="abstract"></a>Abstract</h2>

<p>This document describes the Media Fragments 1.0 specification. It specifies
the syntax for constructing media fragment URIs and explains how to handle them
when used over the HTTP protocol. The syntax is based on the specification of
particular name-value pairs that can be used in URI fragment and URI query
requests to restrict a media resource to a certain fragment. </p>
</div>

<div>
<h2><a id="status" name="status"></a>Status of this Document</h2>

<p><em>This section describes the status of this document at the time of its
publication. Other documents may supersede this document. A list of current W3C
publications and the latest revision of this technical report can be found in
the <a href="http://www.w3.org/TR/">W3C technical reports index</a> at
http://www.w3.org/TR/.</em></p>

<p>This is the Second Last Call Working Draft of the Media Fragments URI 1.0
specification. It has been produced by the <a
href="http://www.w3.org/2008/WebVideo/Fragments/">Media Fragments Working
Group</a>, which is part of the <a href="http://www.w3.org/2008/WebVideo/">W3C
Video on the Web Activity</a>.</p>

<p>This W3C Working Draft version of the Media Fragments URI 1.0 specification
incorporates requests for changes from comments sent during the first Last Call
Review, as agreed with the commenters and changes following implementation
experiences from the Working Group. The Working Group wishes to have these
changes reviewed before proceeding to Candidate Recommendation. </p>

<p>The W3C Membership and other interested parties are invited to review the
document and send comments through 10 April 2011. Please send comments about
this document to <a
href="mailto:public-media-fragment@w3.org">public-media-fragment@w3.org</a>
mailing list (<a
href="http://lists.w3.org/Archives/Public/public-media-fragment/">public
archive</a>).</p>

<p>Publication as a Working Draft does not imply endorsement by the W3C
Membership. This is a draft document and may be updated, replaced or obsoleted
by other documents at any time. It is inappropriate to cite this document as
other than work in progress. </p>

<p>This document was produced by a group operating under the <a
href="http://www.w3.org/Consortium/Patent-Policy-20040205/">5 February 2004 W3C
Patent Policy</a>. W3C maintains a <a
href="http://www.w3.org/2004/01/pp-impl/42785/status">public list of any patent
disclosures</a> made in connection with the deliverables of the group; that
page also includes instructions for disclosing a patent. An individual who has
actual knowledge of a patent which the individual believes contains <a
href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential
Claim(s)</a> must disclose the information in accordance with <a
href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section
6 of the W3C Patent Policy</a>. </p>
</div>

<div class="toc">
<h2><a id="contents" name="contents"></a>Table of Contents</h2>

<p class="toc">1 <a href="#introduction">Introduction</a><br />
2 <a href="#standardisation">Standardisation Issues</a><br />
    2.1 <a href="#standardisation-terminology">Terminology</a><br />
    2.2 <a href="#standardisation-approach">Media Fragments
Standardisation</a><br />
        2.2.1 <a href="#standardisation-URI-fragments">URI
Fragments</a><br />
        2.2.2 <a href="#standardisation-URI-queries">URI Queries</a><br
/>
3 <a href="#fragment-query">URI fragment and URI query</a><br />
    3.1 <a href="#URIquery-vs-fragments">When to choose URI fragments? When
to choose URI queries?</a><br />
    3.2 <a href="#URIfragment-user-agent">Resolving URI fragments within
the user agent</a><br />
    3.3 <a href="#URIfragment-server">Resolving URI fragments with server
help</a><br />
    3.4 <a href="#URIfragment-proxies">Resolving URI fragments in a proxy
cacheable manner</a><br />
    3.5 <a href="#URIquery-media-fragments">Resolving URI queries</a><br />
    3.6 <a href="#URIquery-URIfragment">Combining URI fragments and URI
queries</a><br />
4 <a href="#media-fragment-syntax">Media Fragments Syntax</a><br />
    4.1 <a href="#general-structure">General Structure</a><br />
    4.2 <a href="#fragment-dimensions">Fragment Dimensions</a><br />
        4.2.1 <a href="#naming-time">Temporal Dimension</a><br />
            4.2.1.1 <a href="#npt-time">Normal Play Time
(NPT)</a><br />
            4.2.1.2 <a href="#smpte-time">SMPTE time codes</a><br />
            4.2.1.3 <a href="#clock-time">Wall-clock time
code</a><br />
        4.2.2 <a href="#naming-space">Spatial Dimension</a><br />
        4.2.3 <a href="#naming-track">Track Dimension</a><br />
        4.2.4 <a href="#naming-name">Named Dimension</a><br />
        4.2.5 <a href="#common-syntax">Common Syntax</a><br />
5 <a href="#media-fragment-processing">Media Fragments Processing</a><br />
    5.1 <a href="#processing-media-fragment-uri">Processing Media Fragment
URI</a><br />
        5.1.1 <a href="#processing-name-value-components">Processing
name-value components</a><br />
        5.1.2 <a href="#processing-name-value-lists">Processing
name-value lists</a><br />
    5.2 <a href="#processing-protocol-frag">Protocol for URI fragment
Resolution in HTTP</a><br />
        5.2.1 <a href="#processing-protocol-UA-mapped">UA mapped byte
ranges</a><br />
            5.2.1.1 <a href="#processing-protocol-UA-mapped-new">UA
requests URI fragment for the first time</a><br />
            5.2.1.2 <a
href="#processing-protocol-UA-mapped-unchanged">UA requests URI fragment it
already has buffered</a><br />
            5.2.1.3 <a
href="#processing-protocol-UA-mapped-changed">UA requests URI fragment of a
changed resource</a><br />
        5.2.2 <a href="#processing-protocol-Server-mapped">Server
mapped byte ranges</a><br />
            5.2.2.1 <a
href="#processing-protocol-server-mapped-default">Server mapped byte ranges
with corresponding binary data</a><br />
            5.2.2.2 <a
href="#processing-protocol-server-mapped-setup">Server mapped byte ranges with
corresponding binary data and codec setup data</a><br />
            5.2.2.3 <a
href="#processing-protocol-server-mapped-proxy">Proxy cacheable server mapped
byte ranges</a><br />
        5.2.3 <a href="#server-triggered-redirect">Server triggered
redirect</a><br />
    5.3 <a href="#processing-protocol-query">Protocol for URI query
Resolution in HTTP</a><br />
6 <a href="#media-fragment-semantics">Media Fragments Semantics</a><br />
    6.1 <a href="#error-general">Errors on the General URI level</a><br />
        6.1.1 <a href="#error-general-non-existent">Non-existent
dimension:</a><br />
        6.1.2 <a href="#error-general-underspec">Under-specified
Dimension</a><br />
    6.2 <a href="#error-temporal">Errors on the temporal dimensions</a><br
/>
        6.2.1 <a href="#error-temporal-valid">Valid requests</a><br />
        6.2.2 <a href="#error-temporal-empty">Empty</a><br />
        6.2.3 <a
href="#error-temporal-non-existent">Non-existent</a><br />
        6.2.4 <a href="#error-temporal-validity">Validity error</a><br
/>
        6.2.5 <a href="#error-temporal-smpte-mismatch">SMPTE time code
mismatch</a><br />
    6.3 <a href="#error-spatial">Errors on the spatial dimensions</a><br />
    6.4 <a href="#error-track">Errors on the track dimensions</a><br />
    6.5 <a href="#error-named">Errors on the named dimensions</a><br />
7 <a href="#implementor-notes">Notes to Implementors (non-normative)</a><br />
    7.1 <a href="#media-fragment-browser">Browsers Rendering Media
Fragments</a><br />
    7.2 <a href="#media-fragment-display">Clients Displaying Media
Fragments</a><br />
    7.3 <a href="#media-fragment-clients">All Media Fragment Clients</a><br
/>
    7.4 <a href="#media-fragment-servers">Media Fragment Servers</a><br />
    7.5 <a href="#media-fragment-webapps">Media Fragment Web
Applications</a><br />
8 <a href="#conclusions">Conclusions</a><br />
    8.1 <a href="#qualification-resources">Qualification of Media
Resources</a><br />
</p>

<h3><a id="appendices" name="appendices"></a>Appendices</h3>

<p class="toc">A <a href="#references-normative">References</a><br />
B <a href="#collected-syntax-uri">Collected ABNF Syntax for URI</a>
(Non-Normative)<br />
C <a href="#collected-syntax-http">Collected ABNF Syntax for HTTP Headers</a>
(Non-Normative)<br />
D <a href="#rtsp-media-fragment-processing">Processing media fragment URIs in
RTSP</a> (Non-Normative)<br />
    D.1 <a href="#mapping-mf-to-rtsp-methods">How to map Media Fragment
URIs to RTSP protocol methods</a><br />
        D.1.1 <a href="#rtsp-mf-dimensions">Dealing with the media
fragment URI dimensions in RTSP</a><br />
            D.1.1.1 <a href="#rtsp-temporal">Temporal Media
Fragment URIs</a><br />
            D.1.1.2 <a href="#rtsp-track">Track Media Fragment
URIs</a><br />
            D.1.1.3 <a href="#rtsp-spatial">Spatial Media Fragment
URIs</a><br />
            D.1.1.4 <a href="#rtsp-named">Named Media Fragment
URIs</a><br />
        D.1.2 <a href="#rtsp-combined-mf-dimensions">Putting the media
fragment URI dimensions together in RTSP</a><br />
        D.1.3 <a href="#rtsp-caching">Caching and RTSP for media
fragment URIs</a><br />
E <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br />
F <a href="#change-log">Change Log</a> (Non-Normative)<br />
</p>
</div>
<hr />

<div class="body">

<div class="div1">
<h2><a id="introduction" name="introduction"></a>1 Introduction</h2>

<p>Audio and video resources on the World Wide Web are currently treated as
"foreign" objects, which can only be embedded using a plugin that is capable of
decoding and interacting with the media resource. Specific media servers are
generally required to provide for server-side features such as direct access to
time offsets into a video without the need to retrieve the entire resource.
Support for such media fragment access varies between different media formats
and inhibits standard means of dealing with such content on the Web. </p>

<p>This specification provides for a media-format independent, standard means
of addressing media fragments on the Web using Uniform Resource Identifiers
(URI). In the context of this document, media fragments are regarded along
three different dimensions: temporal, spatial, and tracks. Further, a fragment
can be marked with a name and then addressed through a URI using that name. The
specified addressing schemes apply mainly to audio and video resources - the
spatial fragment addressing may also be used on images. </p>

<p>The aim of this specification is to enhance the Web infrastructure for
supporting the addressing and retrieval of subparts of time-based Web
resources, as well as the automated processing of such subparts for reuse.
Example uses are the sharing of such fragment URIs with friends via email, the
automated creation of such fragment URIs in a search engine interface, or the
annotation of media fragments with RDF. Such use case examples as well as other
side conditions on this specification and a survey of existing media fragment
addressing approaches are provided in the requirements <cite><a
href="#mf-req">Use cases and requirements for Media Fragments</a></cite>
document that accompanies this specification document. </p>

<p>The media fragment URIs specified in this document have been implemented and
demonstrated to work with media resources over the HTTP protocol. This
specification is not defining the protocol aspect of RTSP handling of a media
fragment in the normative sections. We expect the media fragment URI syntax to
be generic and a possible mapping between this syntax and RTSP messages can be
found in an appendix of this specification <a
href="#rtsp-media-fragment-processing"><b>D Processing media fragment URIs in
RTSP</b></a>. Existing media formats in their current representations and
implementations provide varying degrees of support for this specification. It
is expected that over time, media formats, media players, Web Browsers, media
and Web servers, as well as Web proxies will be extended to adhere to the full
specification. This specification will help make video a first-class citizen of
the World Wide Web. </p>
</div>

<div class="div1">
<h2><a id="standardisation" name="standardisation"></a>2 Standardisation
Issues</h2>

<div class="div2">
<h3><a id="standardisation-terminology"
name="standardisation-terminology"></a>2.1 Terminology</h3>

<p>The keywords <strong>MUST</strong>, <strong>MUST NOT</strong>,
<strong>SHOULD</strong> and <strong>SHOULD NOT</strong> are to be interpreted
as defined in <cite><a href="#rfc2119">RFC 2119</a></cite>. </p>

<p>According to <cite><a href="#rfc3986">RFC 3986</a></cite>, the term "URI"
does not include relative references. In this document, we consider both URIs
and relative references. Consequently, we use the term "URI reference" as
defined in <cite><a href="#rfc3986">RFC 3986</a></cite> (section 4.1). For
simplicity reasons, this document, however, only uses the term "media fragment
URI" in place of "media fragment URI reference". </p>

<p>The following terms are used frequently in this document and need to be
clearly understood: </p>
<ul>
  <li>URI fragment = anything behind a "#" in a URI</li>
  <li>URI query = anything behind a "?" and before a "#" in a URI</li>
  <li>media fragment URI = a URI addressing subparts of a media resource - that
    could be through URI queries or URI fragments</li>
</ul>
</div>

<div class="div2">
<h3><a id="standardisation-approach" name="standardisation-approach"></a>2.2
Media Fragments Standardisation</h3>

<p>The basis for the standardisation of media fragment URIs is the URI
specification, <cite><a href="#rfc3986">RFC 3986</a></cite>. Providing media
fragment identification information in URIs refers here to the specification of
the structure of a URI fragment or a URI query. This document will explain how
URI fragments and URI queries are structured to identify media fragments. It
normalises the name-value parameters used in URI fragments and URI queries to
address media fragments. These build on existing CGI parameter conventions. </p>

<p>In this section, we look at implications of standardising the structure of
media fragment URIs. </p>

<div class="div3">
<h4><a id="standardisation-URI-fragments"
name="standardisation-URI-fragments"></a>2.2.1 URI Fragments</h4>

<p>The URI specification <cite><a href="#rfc3986">RFC 3986</a></cite> says
about the format of a URI fragment in Section 3.5: </p>

<p><i>"The fragment's format and resolution is [..] dependent on the media type
[RFC2046] of a potentially retrieved representation. [..] Fragment identifier
semantics are independent of the URI scheme and thus cannot be redefined by
scheme specifications."</i> </p>

<p>This essentially means that only media type definitions (as registered
through the process defined in <cite><a href="#rfc4288">RFC 4288</a></cite>)
are able to introduce a standard structure on URI fragments for that mime type.
One part of the registration process of a media type can include information
about how fragment identifiers in URIs are constructed for use in conjunction
with this media type. </p>

<p>Note that the registration of URI fragment construction rules as expressed
in Section 4.11 of <cite><a href="#rfc4288">RFC 4288</a></cite> is only a
SHOULD-requirement. An analysis of all media type registrations showed that
there is not a single media type registration in the audio/*, image/*, video/*
branches that is currently defining fragments or fragment semantics. </p>

<p>The Media Fragment WG has no authority to update registries of all targeted
media types. To the best of our knowledge there are only <a
href="http://www.w3.org/2008/WebVideo/Fragments/wiki/MediaTypeReview">few media
types that actually have a specified fragment format</a> even if it is not
registered with the media type: these include Ogg, MPEG-4, and MPEG-21.
Further, only a small number of software packages actually supports these
fragment formats. For all others, the semantics of the fragment are considered
to be unknown. </p>

<p>As such, the intention of this document is to propose a specification to all
media type owners in the audio/*, image/*, and video/* branches for a
structured approach to URI fragments and for specification of commonly agreed
dimensions to address media fragments (i.e. subparts of a media resource)
through URI fragments. We recommend media type owners to harmonize their
existing schemes with the ones proposed in this document and update or add the
fragment semantics specification to their media type registration. </p>
</div>

<div class="div3">
<h4><a id="standardisation-URI-queries"
name="standardisation-URI-queries"></a>2.2.2 URI Queries</h4>

<p>The URI specification <cite><a href="#rfc3986">RFC 3986</a></cite> says
about the format of a URI query in Section 3.4: </p>

<p><i>"The query component [..] serves to identify a resource within the scope
of the URI's scheme and naming authority (if any). [..] Query components are
often used to carry identifying information in the form of "key=value" pairs
[..]."</i> </p>

<p>URI query specifications are more closely linked to the URI scheme, some of
which do not even use a query component. We are mostly concerned with the HTTP
<cite><a href="#rfc2616">RFC 2616</a></cite> and the RTP/RTSP <cite><a
href="#">rfc2326</a></cite> protocols here, which both support query
components. HTTP says nothing about how a URI query has to be interpreted. RTSP
explicitly says that fragment and query identifiers do not have a well-defined
meaning at this time, with the interpretation left to the RTSP server. </p>

<p>The URI specification <cite><a href="#rfc3986">RFC 3986</a></cite> says
generally that the data within the URI is often parsed by both the user agent
and one or more servers. It refers in particular to HTTP in Section 7.3: </p>

<p><i>"In HTTP, for example, a typical user agent will parse a URI into its
five major components, access the authority's server, and send it the data
within the authority, path, and query components. A typical server will take
that information, parse the path into segments and the query into key/value
pairs, and then invoke implementation-specific handlers to respond to the
request."</i> </p>

<p>Since the interpretation of query components resides with the functionality
of servers, the intention of this document wrt query components is to recommend
standard name-value pair formats for use in addressing media fragments through
URI queries. We recommend server and server-type software providers to
harmonize their existing schemes in use with media resources to support the
nomenclature proposed in this specification. </p>
</div>
</div>
</div>

<div class="div1">
<h2><a id="fragment-query" name="fragment-query"></a>3 URI fragment and URI
query</h2>

<table border="1" summary="Editorial note">
  <tbody>
    <tr>
      <td width="50%" valign="top" align="left"><b>Editorial note</b></td>
      <td width="50%" valign="top" align="right"> </td>
    </tr>
    <tr>
      <td valign="top" align="left" colspan="2">This section is
      non-normative</td>
    </tr>
  </tbody>
</table>

<p>To address a media fragment, one needs to find ways to convey the fragment
information. This specification builds on URIs <cite><a href="#rfc3986">RFC
3986</a></cite>. Every URI is defined as consisting of four parts, as follows:
</p>

<div class="exampleOuter">
<p>&lt;scheme name&gt; : &lt;hierarchical part&gt; [ ? &lt;query&gt; ] [ #
&lt;fragment&gt; ] </p>
</div>

<p>There are therefore two possibilities for representing the media fragment
addressing in URIs: the <em>URI query part</em> or the <em>URI fragment
part</em>. </p>

<div class="div2">
<h3><a id="URIquery-vs-fragments" name="URIquery-vs-fragments"></a>3.1 When to
choose URI fragments? When to choose URI queries?</h3>

<p>For media fragment addressing, both approaches - URI query and URI fragment
- are useful. </p>

<p>The main difference between a URI query and a URI fragment is that a URI
query produces a new resource, while a URI fragment provides a secondary
resource that has a relationship to the primary resource. URI fragments are
resolved from the primary resource without another retrieval action. This means
that a user agent should be capable to resolve a URI fragment on a resource it
has already received without having to fetch more data from the server. </p>

<p>A further requirement put on a URI fragment is that the media type of the
retrieved fragment should be the same as the media type of the primary
resource. Among other things, this means that a URI fragment that points to a
single video frame out of a longer video results in a one-frame video, not in a
still image. To extract a still image, one would need to create a URI query
scheme - something not envisaged here, but easy to devise. </p>

<p>There are different types of media fragment addressing in this
specification. As noted in the <cite><a href="#mf-req">Use cases and
requirements for Media Fragments</a></cite> document (section "Fitness
Conditions on Media Containers/Resources"): not all container formats and
codecs are "fit" for supporting the different types of fragment URIs. "Fitness"
relates to the fact that a media fragment can be extracted from the primary
resource without syntax element modifications or transcoding of the bitstream.
</p>

<p>Resources that are "fit" can therefore be addressed with a URI fragment.
Resources that are "conditionally fit" can be addressed with a URI fragment
with an additional retrieval action that retrieves the modified syntax elements
but leaves the codec data untouched. Resources that are "unfit" require
transcoding. Such transcoded media fragments cannot be addressed with URI
fragments, but only with URI queries. </p>

<p>Therefore, when addressing a media fragment with the URI mechanism, the
author has to know whether this media fragment can be produced from the
(primary) resource itself without any transcoding activities or whether it
requires transcoding. In the latter case, the only choice is to use a URI query
and to use a server that supports transcoding and delivery of a (primary)
derivative resource to satisfy the query. </p>
</div>

<div class="div2">
<h3><a id="URIfragment-user-agent" name="URIfragment-user-agent"></a>3.2
Resolving URI fragments within the user agent</h3>

<p>A user agent may itself resolve and control the presentation of media
fragment URIs. The simplest case arises where the user agent has already
downloaded the entire resource and can perform the extraction from its locally
cached copy. For some media types, it may also be possible to perform the
extraction over the network without any special protocol assistance. For
temporal fragments this requires a user agent to be able to seek on the media
resource using existing protocol mechanisms. </p>

<p>An example of a URI fragment used to address a media fragment is
<code>http://www.example.org/video.ogv#t=60,100</code>. In this case, the user
agent knows that the primary resource is
<code>http://www.example.org/video.ogv</code> and that it is only expected to
display the portion of the primary resource that relates to the fragment
<code>#t=60,100</code>, i.e. seconds 60-100. Thus, the relationship between the
primary resource and the media fragment is maintained. </p>

<p>In traditional URI fragment retrieval, a user agent requests the complete
primary resource from the server and then applies the fragmentation locally. In
the media fragment case, this would result in a retrieval action on the
complete media resource, on which the user agent would then locally perform its
fragment extraction - something generally unviable for such large resources.
</p>

<p>Therefore, media resources are not always retrieved over HTTP using a single
request. They may be retrieved as a sequence of byte range requests on the
original resource URI, or may be retrieved as a sequence of requests to
different URIs each representing a small part of the media. The reasons for
such mechanisms include bandwidth conservation, where a client chooses to space
requests out over time during playback in order to maximize bandwidth available
for other activities, and bandwidth adaptation, where a client selects among
various representations with varying bitrate depending on the current bandwidth
availability. </p>

<p>A user agent that knows how to map media fragments to byte ranges will be
able to satisfy a URI fragment request such as the above example by itself.
This is typically the case for user agents that know how to seek to media
fragments over the network. For example, a user agent that deals with a media
file that includes an index of its seekable structures can resolve the media
fragment addresses to byte ranges from the index. This is the case e.g. with
seekable QuickTime files. Another example is a user agent that knows how to
seek on a media file through a sequence of byte range requests and eventually
receives the correct media fragment. This is the case e.g. with Ogg files in
Firefox versions above 3.5. </p>

<p>Similarly, a user agent that knows how to map media fragments to a sequence
of URIs can satisfy a URI fragment request by itself. This is typically the
case for user agents that perform adaptive streaming. For example, a user agent
that deals with a media resource that contains a sequence of URIs, each a media
file of a few seconds duration, can resolve the media fragment addresses to a
subsequence of those URIs. This is the case with QuickTime adaptive bitrate
streaming or IIS Smooth Streaming. </p>

<p>If such a user agent natively supports the media fragment syntax as
specified in this document, it is deemed conformant to this specification for
fragments and for the particular dimension. </p>
</div>

<div class="div2">
<h3><a id="URIfragment-server" name="URIfragment-server"></a>3.3 Resolving URI
fragments with server help</h3>

<p>For user agents that natively support the media fragment syntax, but have to
use their own seeking approach, this specification provides an optimisation
that can make the byte offset seeking more efficient. It requires a conformant
server with which the user agent will follow a protocol defined later in this
document. </p>

<p>In this approach, the user agent asks the server to do the byte range
mapping for the media fragment address itself and send back the appropriate
byte ranges. This can not be done through the URI, but has to be done through
adding protocol headers. User agents that interact with a conformant server to
follow this protocol will receive the appropriate byte ranges directly and will
not need to do costly seeking over the network. </p>

<p>Note that it is important that the server also informs the user agent what
actual media fragment range it was able to retrieve. This is important since in
the compressed domain it is not possible to extract data at an arbitrary
resolution, but only at the resolution that the data was packaged in. For
example, even if a user asked for
<code>http://www.example.org/video.ogv#t=60,100</code> and the user agent sent
a range request of <code>t=60,100</code> to the server, the server may only be
able to return the range <code>t=58,103</code> as the closest decodable range
that encapsulates all the required data. </p>

<p>Note that if done right, the native user agent support for media fragments
and the improved server support can be integrated without problems: the user
agent just needs to include the byte range and the media fragment range request
in one request. A server that does not understand the media fragment range
request will only react to the byte ranges, while a server that understands
them will ignore the byte range request and only reply with the correct byte
ranges. The user agent will understand from the response whether it received a
reply to the byte ranges or the media fragment ranges request and can react
accordingly. </p>
</div>

<div class="div2">
<h3><a id="URIfragment-proxies" name="URIfragment-proxies"></a>3.4 Resolving
URI fragments in a proxy cacheable manner</h3>

<p>The current setup of the World Wide Web relies heavily on the use of caching
Web proxies to speed up the delivery of content. In the case of URI fragments
that are resolved by the server as indicated in the previous section, existing
Web proxies have no means of caching these requests since they only understand
byte ranges. </p>

<p>To make use of the existing Web proxy infrastructure of the Web, we need to
make sure that the user agent only asks for byte ranges, so they can be served
from the cache. This is possible if the server - instead of replying with the
actual data - replies with the mapped byte ranges for the requested media
fragment range. Then, the user agent is able to resend his range request this
time with bytes only, which can possibly already be satisfied from the cache.
Details of this will be specified later. </p>

<table border="1" summary="Editorial note: Raphael">
  <tbody>
    <tr>
      <td width="50%" valign="top" align="left"><b>Editorial note:
      Raphael</b></td>
      <td width="50%" valign="top" align="right"> </td>
    </tr>
    <tr>
      <td valign="top" align="left" colspan="2">Should we not foresee future
        "smart" media caches that would be able to actually cache range request
        in other units than bytes? </td>
    </tr>
  </tbody>
</table>
</div>

<div class="div2">
<h3><a id="URIquery-media-fragments" name="URIquery-media-fragments"></a>3.5
Resolving URI queries</h3>

<p>The described URI fragment addressing methods only work for byte-identical
segments of a media resource, since we assume a simple mapping between the
media fragment and bytes that each infrastructure element can deal with. Where
it is impossible to maintain byte-identity and some sort of transcoding of the
resource is necessary, the user agent is not able to resolve the fragmentation
by itself and a server interaction is required. In this case, URI queries have
to be used since they result in a server interaction and can deliver a
transcoded resource. </p>

<p>Another use for URI queries is when a user agent actually wants to receive a
completely new resource instead of just a byte range from an existing (primary)
resource. This is, for example, the case for playlists of media fragment
resources. Even if a media fragment could be resolved through a URI fragment,
the URI query may be more desirable since it does not carry with itself the
burden of the original primary resource - its file headers may be smaller, its
duration may be smaller, and it does not automatically allow access to the
remainder of the original primary resource. </p>

<p>When URI queries are used, the retrieval action has to additionally make
sure to create a fully valid new resource. For example, for the Ogg format,
this implies a reconstruction of Ogg headers to accurately describe the new
resource (e.g. a non-zero start-time or different encoding parameters). Such a
resource will be cached in Web proxies as a different resource to the original
primary resource. </p>

<p>An example URI query that includes a media fragment specification is
<code>http://www.example.org/video.ogv?t=60,100</code>. This results in a video
of duration 40s (assuming the original video was more than 100s long). </p>

<p>Note that this resource has no per-se relationship to the original primary
resource. As a user agent uses such a URI with e.g. a HTML5 video element, the
browser has no knowledge about the original resource and can only display this
video as a 40s long video starting at 0s. The context of the original resource
is lost. </p>

<p>A user agent may want to display the original start time of the resource as
the start time of the video in order to be consistent with the information in
the URI. It is possible to achieve this in one of two ways: either the video
file itself has some knowledge that it is an extract from a different file and
starts at an offset - or the user agent is told through the retrieval action
which original primary resource the retrieved resource relates to and can find
out information about it through another retrieval action. This latter option
will be regarded later in this document. </p>

<p>An example for a media resource that has knowledge about itself of the
required kind are Ogg files. Ogg files that have a skeleton track and were
created correctly from the primary resource will know that their start time is
not 0s but 60s in the above example. The browser can simply parse this
information out of the received bitstream and may display a timeline that
starts at 60s and ends at 100s in the video controls if it so desires. </p>

<p>Another option is that the browser parses the URI and knows about how media
resources have a fragment specification that follows a standard. Then the
browser can interpret the query parameters and extract the correct start and
end times and also the original primary resource. It can then also display a
timeline that starts at 60s and ends at 100s in the video controls. Further it
can allow a right-click menu to click through to the original resource if
required. </p>

<p>A use case where the video controls may neither start at 0s nor at 60s is a
mashed-up video created through a list of media fragment URIs. In such a
playlist, the user agent may prefer to display a single continuous timeline
across all the media fragments rather than a collection of individual timelines
for each fragment. Thus, the 60s to 100s fragment may e.g. be mapped to an
interval at 3min20 to 4min. </p>

<p>No new protocol headers are required to execute a URI query for media
fragment retrieval. Some optional protocol headers that improve the information
exchange will be recommended later in this document. </p>
</div>

<div class="div2">
<h3><a id="URIquery-URIfragment" name="URIquery-URIfragment"></a>3.6 Combining
URI fragments and URI queries</h3>

<p>A combination of a URI query for a media fragment with a URI fragment yields
a URI fragment resolution on top of the newly created resource. Since a URI
with a query part creates a new resource, we have to do the fragment offset on
the new resource. This is simply a conformant behaviour to the URI standard
<cite><a href="#rfc3986">RFC 3986</a></cite>. </p>

<p>For example, <code>http://www.example.org/video.ogv?t=60,100#t=20</code>
will lead to the 20s fragment offset being applied to the new resource starting
at 60 going to 100. Thus, the reply to this is a 40s long resource whose
playback will start at an offset of 20s. </p>

<table border="1" summary="Editorial note: Silvia">
  <tbody>
    <tr>
      <td width="50%" valign="top" align="left"><b>Editorial note:
      Silvia</b></td>
      <td width="50%" valign="top" align="right"> </td>
    </tr>
    <tr>
      <td valign="top" align="left" colspan="2">We should at the end of the
        document set up a table with all the different addressing types and
        http headers and say what we deem is conformant and how to find out
        whether a server or user agent is conformant or not. </td>
    </tr>
  </tbody>
</table>
</div>
</div>

<div class="div1">
<h2><a id="media-fragment-syntax" name="media-fragment-syntax"></a>4 Media
Fragments Syntax</h2>

<p>This section describes the external representation of a media fragment
specifier, and how this should be interpreted. </p>

<p>Guiding principles for the definition of the media fragments syntax were as
follows: </p>
<ul>
  <li>a. The MF syntax for queries and fragments should be identical</li>
  <li>b. The MF syntax should be unambiguous</li>
  <li>c. The MF syntax should allow any UTF-8 character in track or id
  names</li>
  <li>d. The MF syntax should adhere to applicable formal standards</li>
  <li>e. The MF syntax should adhere to de-facto usage of queries and
  fragments</li>
  <li>f. The MF syntax should be as concise as possible, with no unneeded
    grammatical fluff</li>
</ul>

<div class="div2">
<h3><a id="general-structure" name="general-structure"></a>4.1 General
Structure</h3>

<p>A list of name-value pairs is encoded in the query or fragment component of
a URI. The name and value components are separated by an equal sign
(<code>=</code>), while multiple name-value pairs are separated by an ampersand
(<code>&amp;</code>). </p>

<div class="exampleInner">
<a id="namevalues" name="namevalues"></a>
<pre>name = fragment - "&amp;" - "="
value = fragment - "&amp;"
namevalue = name [ "=" value ]
namevalues = namevalue *( "&amp;" namevalue )</pre>
</div>

<p>The names and values can be arbitrary Unicode strings, encoded in <cite><a
href="#utf-8">UTF-8</a></cite> and percent-encoded as per <cite><a
href="#rfc3986">RFC 3986</a></cite>. Here are some examples of URIs with
name-value pairs in the fragment component, to demonstrate the general
structure: </p>

<div class="exampleInner">
<pre>http://www.example.com/example.ogv#a=b&amp;c=d
http://www.example.com/example.ogv#t=10,20
http://www.example.com/example.ogv#track=audio&amp;t=10,20
http://www.example.com/example.ogv#id=Cap%C3%ADtulo%202</pre>
</div>

<p>While arbitrary name-value pairs can be encoded in this manner, this
specification defines a fixed set of dimensions. The dimension keyword name is
encoded in the name component, while dimension-specific syntax is encoded in
the value component. </p>

<p>Section <a href="#processing-name-value-components"><b>5.1.1 Processing
name-value components</b></a> defines in more detail how to process the
name-value pair syntax, arriving at a list of name-value Unicode string pairs.
The syntax definitions in <a href="#fragment-dimensions"><b>4.2 Fragment
Dimensions</b></a> apply to these Unicode strings. </p>
</div>

<div class="div2">
<h3><a id="fragment-dimensions" name="fragment-dimensions"></a>4.2 Fragment
Dimensions</h3>

<p>Media fragments support addressing the media along four dimensions:</p>
<dl>
  <dt class="label">temporal</dt>
    <dd><p>This dimension denotes a specific time range in the original media,
      such as "starting at second 10, continuing until second 20"; </p>
    </dd>
  <dt class="label">spatial</dt>
    <dd><p>this dimension denotes a specific range of pixels in the original
      media, such as "a rectangle with size (100,100) with its top-left at
      coordinate (10,10)"; </p>
    </dd>
  <dt class="label">track</dt>
    <dd><p>this dimension denotes one or more tracks in the original media,
      such as "the english audio and the video track"; </p>
    </dd>
  <dt class="label">named</dt>
    <dd><p>this dimension denotes a named section of the original media, such
      as "chapter 2". </p>
    </dd>
</dl>

<p>The temporal, spatial and track dimensions are logically independent and can
be combined; the outcome is independent of the order of the dimensions. </p>

<p>The track dimension refers to one of a set of parallel media streams (e.g.
"the english audio track for a video"), not to a (possibly self-contained)
section of the source media (e.g. "Audio track 2 of a CD"). </p>

<p>The name dimension cannot be combined with the other dimensions, because the
semantics depend on the underlying source media format: some media formats
support naming of temporal extents, others support naming of groups of tracks,
etc. Error semantics are discussed in <a href="#media-fragment-semantics"><b>6
Media Fragments Semantics</b></a>. </p>

<div class="div3">
<h4><a id="naming-time" name="naming-time"></a>4.2.1 Temporal Dimension</h4>

<p>Temporal clipping is denoted by the name <code>t</code>, and specified as an
interval with a begin time and an end time (or an in-point and an out-point, in
video editing terms). Either or both may be omitted, with the begin time
defaulting to 0 seconds and the end time defaulting to the duration of the
source media. The interval is half-open: the begin time is considered part of
the interval whereas the end time is considered to be the first time point that
is not part of the interval. If a single number only is given, this is the
begin time. </p>

<p>Examples:</p>

<div class="exampleInner">
<pre>t=10,20   # =&gt; results in the time interval [10,20)
t=,20     # =&gt; results in the time interval [0,20)
t=10,     # =&gt; results in the time interval [10,end)
t=10      # =&gt; also results in the time interval [10,end)</pre>
</div>

<p>Temporal clipping can be specified either as Normal Play Time (npt) <cite><a
href="#rtsp">RFC 2326</a></cite>, as SMPTE timecodes, <cite><a
href="#smpte">SMPTE</a></cite>, or as real-world clock time (clock) <cite><a
href="#rtsp">RFC 2326</a></cite>. Begin and end times are always specified in
the same format. The format is specified by name, followed by a colon
(<code>:</code>), with <code>npt:</code> being the default. </p>

<div class="exampleInner">
<a id="timesegment" name="timesegment"></a>
<pre>timeprefix    = %x74                                      ; "t"
timeparam     = <a href="#npttimedef">npttimedef</a> / <a href="#smptetimedef">smptetimedef</a> / <a href="#clocktimedef">clocktimedef</a></pre>
</div>

<p>In this version of the media fragments specification there is no
extensibility mechanism to add time format specifiers. </p>

<div class="div4">
<h5><a id="npt-time" name="npt-time"></a>4.2.1.1 Normal Play Time (NPT)</h5>

<p>Normal Play Time can either be specified as seconds, with an optional
fractional part to indicate miliseconds, or as colon-separated hours, minutes
and seconds (again with an optional fraction). Minutes and seconds must be
specified as exactly two digits, hours and fractional seconds can be any number
of digits. The hours, minutes and seconds specification for NPT is a
convenience only, it does not signal frame accuracy. The specification of the
"npt:" identifier is optional since NPT is the default time scheme. This
specification builds on the RTSP specification of NPT <cite><a href="#rtsp">RFC
2326</a></cite>. </p>

<div class="exampleInner">
<a id="npttimedef" name="npttimedef"></a>
<pre>npt-sec       =  1*DIGIT [ "." *DIGIT ]                     ; definitions taken
npt-hhmmss    =  npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT] ; from <cite><a href="#rtsp">RFC 2326</a></cite>,
npt-mmss      =  npt-mm ":" npt-ss [ "." *DIGIT]
npt-hh        =   1*DIGIT     ; any positive number
npt-mm        =   2DIGIT      ; 0-59
npt-ss        =   2DIGIT      ; 0-59

npttimedef    = [ deftimeformat ":"] ( npttime  [ "," npttime ] ) / ( "," npttime )

deftimeformat = %x6E.70.74                                ; "npt"
npttime       = npt-sec / npt-mmss / npt-hhmmss</pre>
</div>

<p>Examples:</p>

<div class="exampleInner">
<pre>t=npt:10,20         # =&gt; results in the time interval [10,20)
t=npt:120,          # =&gt; results in the time interval [120,end)
t=npt:,121.5        # =&gt; results in the time interval [0,121.5)
t=0:02:00,121.5     # =&gt; results in the time interval [120,121.5)
t=npt:120,0:02:01.5 # =&gt; also results in the time interval [120,121.5)</pre>
</div>
</div>

<div class="div4">
<h5><a id="smpte-time" name="smpte-time"></a>4.2.1.2 SMPTE time codes</h5>

<p>SMPTE time codes are a way to address a specific frame (or field) without
running the risk of rounding errors causing a different frame to be selected.
The format is always colon-separated hours, minutes, seconds and frames. Frames
are optional, defaulting to 00. If the source format has a further subdivison
of frames (such as odd/even fields in interlaced video) these can be specified
further with a number after a dot (<code>.</code>). The SMPTE format name must
always be specified, because the interpretation of the fields depends on the
format. The SMPTE formats supported in this version of the specification are:
</p>
<ul>
  <li><code>smpte</code>,</li>
  <li><code>smpte-25</code>,</li>
  <li><code>smpte-30</code> and </li>
  <li><code>smpte-30-drop</code>.</li>
</ul>

<p><code>smpte</code> is a synonym for <code>smpte-30</code>. </p>

<div class="exampleInner">
<a id="smptetimedef" name="smptetimedef"></a>
<pre>smptetimedef  = smpteformat ":"( frametime [ "," frametime ] ) / ( "," frametime )
smpteformat   = %x73.6D.70.74.65                          ; "smpte"
               / %x73.6D.70.74.65.2D.32.35                ; "smpte-25"
               / %x73.6D.70.74.65.2D.33.30                ; "smpte-30"
               / %x73.6D.70.74.65.2D.33.30.2D.64.72.6F.70 ; "smpte-30-drop"
frametime     = 1*DIGIT ":" 2DIGIT ":" 2DIGIT [ ":" 2DIGIT [ "." 2DIGIT ] ]</pre>
</div>

<p>Examples:</p>

<div class="exampleInner">
<pre>t=smpte-30:0:02:00,0:02:01:15       # =&gt; results in the time interval [120,121.5)
t=smpte-25:0:02:00:00,0:02:01:12.40 # =&gt; results in the time interval [120,121.5)
                                    #    (80 or 100 subframes per frame seem typical)</pre>
</div>

<p>Using SMPTE timecodes may result in frame-accurate begin and end times, but
only if the timecode format used in the media fragment specifier is the same as
that used in the original media item. </p>
</div>

<div class="div4">
<h5><a id="clock-time" name="clock-time"></a>4.2.1.3 Wall-clock time code</h5>

<p>Wall-clock time codes are a way to address real-world clock time that is
associated typically with a live video stream. These are the same time codes
that are being used by RTSP <cite><a href="#rtsp">RFC 2326</a></cite>, by SMIL
<cite><a href="#smil30">SMIL</a></cite>, and by HTML5 <cite><a
href="#html5">HTML 5</a></cite>. The scheme uses ISO 8601 UTC timestamps
(http://www.iso.org/iso/date_and_time_format). The format separates the date
from the time with a "T" character and the string ends with "Z", which includes
time zone capabilities. To that effect, the ABNF grammar is referring to
<cite><a href="#rfc3339">RFC 3339</a></cite>, which include the relevant part
of ISO 8601 in ABNF form. The time scheme identifier is "clock". </p>

<div class="exampleInner">
<a id="clocktimedef" name="clocktimedef"></a>
<pre>datetime      = &lt;date-time, defined in <cite><a href="#rfc3339">RFC 3339</a></cite>&gt;

clocktimedef  = clockformat ":"( clocktime [ "," clocktime ] ) / ( "," clocktime )
clockformat   = %x63.6C.6F.63.6B                          ; "clock"
clocktime     = (datetime / walltime / date)

; WARNING: if your date-time contains '+' (or any other reserved character, per <cite><a href="#rfc3986">RFC 3986</a></cite>),
; it should be percent-encoded when used in a URI.</pre>
</div>

<p>For convenience, the definition is copied here</p>

<div class="exampleInner">
<a id="datetime" name="datetime"></a>
<pre>; defined in <cite><a href="#rfc3339">RFC 3339</a></cite>
;
date-fullyear   = 4DIGIT
date-month      = 2DIGIT  ; 01-12
date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                          ; month/year
time-hour       = 2DIGIT  ; 00-23
time-minute     = 2DIGIT  ; 00-59
time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                          ; rules
time-secfrac    = "." 1*DIGIT
time-numoffset  = ("+" / "-") time-hour ":" time-minute
time-offset     = "Z" / time-numoffset

partial-time    = time-hour ":" time-minute ":" time-second
                  [time-secfrac]
full-date       = date-fullyear "-" date-month "-" date-mday
full-time       = partial-time time-offset

date-time       = full-date "T" full-time</pre>
</div>

<p>Examples:</p>

<div class="exampleInner">
<pre>t=clock:2009-07-26T11:19:01Z,2009-07-26T11:20:01Z   # =&gt; results in a 1 min interval
                                                    # on 26th Jul 2009 from 11hrs, 19min, 1sec
t=clock:2009-07-26T11:19:01Z                        # =&gt; starts on 26th Jul 2009 from 11hrs, 19min, 1sec
t=clock:,2009-07-26T11:20:01Z                       # =&gt; ends on 26th Jul 2009 from 11hrs, 20min, 1sec</pre>
</div>
</div>
</div>

<div class="div3">
<h4><a id="naming-space" name="naming-space"></a>4.2.2 Spatial Dimension</h4>

<p>Spatial clipping selects an area of pixels from visual media streams. For
this release of the media fragment specification, only rectangular selections
are supported. The rectangle can be specified as pixel coordinates or
percentages. </p>

<p>Pixels coordinates are interpreted after taking into account the resource's
dimensions, aspect ratio, clean aperture, resolution, and so forth, as defined
for the format used by the resource. If an anamorphic format does not define
how to apply the aspect ratio to the video data's dimensions to obtain the
"correct" dimensions, then the user agent must apply the ratio by increasing
one dimension and leaving the other unchanged. </p>

<p>Rectangle selection is denoted by the name <code>xywh</code>. The value is
an optional format <code>pixel:</code> or <code>percent:</code> (defaulting to
pixel) and 4 comma-separated integers. The integers denote x, y, width and
height, respectively, with x=0, y=0 being the top left corner of the image. If
percent is used, x and width are interpreted as a percentage of the width of
the original media, and y and height are interpreted as a percentage of the
original height. </p>

<div class="exampleInner">
<a id="spacesegment" name="spacesegment"></a>
<pre>xywhprefix    = %x78.79.77.68                             ; "xywh"
xywhparam     = [ xywhunit ":" ] 1*DIGIT "," 1*DIGIT "," 1*DIGIT "," 1*DIGIT
xywhunit      = %x70.69.78.65.6C                          ; "pixel"
              / %x70.65.72.63.65.6E.74                    ; "percent"</pre>
</div>

<p>Examples:</p>

<div class="exampleInner">
<pre>xywh=160,120,320,240        # =&gt; results in a 320x240 box at x=160 and y=120
xywh=pixel:160,120,320,240  # =&gt; results in a 320x240 box at x=160 and y=120
xywh=percent:25,25,50,50    # =&gt; results in a 50%x50% box at x=25% and y=25%</pre>
</div>
</div>

<div class="div3">
<h4><a id="naming-track" name="naming-track"></a>4.2.3 Track Dimension</h4>

<p>Track selection allows the extraction of tracks (audio, video, subtitles,
etc) from a media container that supports multiple tracks. Track selection is
denoted by the name <code>track</code>. The value is a string. Percent-escaping
can be used in the string to specify unsafe characters (including separators
such as semi-colon), see the grammar below for details. Multiple track
specification is allowed, but requires the specification of multiple track
parameters. Interpretation of the string depends on the container format of the
original media: some formats allow numbers only, some allow full names. </p>

<div class="exampleInner">
<a id="tracksegment" name="tracksegment"></a>
<pre>trackprefix   = %x74.72.61.63.6B                          ; "track"
trackparam    = unistring</pre>
</div>

<p>Examples:</p>

<div class="exampleInner">
<pre>track=1                         # =&gt; results in only extracting track 1
track=video&amp;track=subtitle  # =&gt; results in extracting track 'video' and track 'subtitle'
track=Wide%20Angle%20Video      # =&gt; results in only extracting track 'Wide Angle Video'</pre>
</div>

<p>As the allowed track names are determined by the original source media, this
information has to be known before construction of the media fragment. There is
no support for generic media type names (audio, video) across container
formats: most container formats allow multiple tracks of each media type, which
would lead to ambiguities. Note that there are existing discovery mechanisms
for retrieving the track names of a media resource, such as the Rich Open
multitrack media Exposition format (ROE) <cite><a href="#roe">ROE</a></cite> or
the Media Annotations API <cite><a href="#mediaAnnotations">Media
Annotations</a></cite>. </p>

<table border="1" summary="Editorial note: Davy">
  <tbody>
    <tr>
      <td width="50%" valign="top" align="left"><b>Editorial note: Davy</b></td>
      <td width="50%" valign="top" align="right"> </td>
    </tr>
    <tr>
      <td valign="top" align="left" colspan="2"><p>We can also reference the
        HTML5 Media Multitrack API here, when it's mentioned in the HTML5 spec.
        </p>
      </td>
    </tr>
  </tbody>
</table>
</div>

<div class="div3">
<h4><a id="naming-name" name="naming-name"></a>4.2.4 Named Dimension</h4>

<p>Name-based selection is denoted by the name <code>id</code>, with the value
being a string enclosed in single quotes. Percent-escaping can be used in the
string to include unsafe characters such as a single quote, see the grammer
below for details. Interpretation of the string depends on the underlying
container format: some container formats support named chapters or numbered
chapters (leading to temporal clipping), some may support naming of groups of
tracks or other objects. As with track selection, determining which names are
valid requires knowledge of the original media item. </p>

<div class="exampleInner">
<a id="namesegment" name="namesegment"></a>
<pre>nameprefix    = %x69.64                                   ; "id"
nameparam     = unistring</pre>
</div>

<p>Examples:</p>

<div class="exampleInner">
<pre>id=1               # =&gt; results in only extracting the section called '1'
id=chapter-1       # =&gt; results in only extracting the section called 'chapter-1'
id=Airline%20Edit  # =&gt; results in only extracting the section called 'Airline Edit'</pre>
</div>

<p>Note that, despite the use of the name <code>id</code>, there is no
correspondence to XML <code>id</code>: the values are uninterpreted strings,
from the point of view of media fragment handling. </p>
</div>

<div class="div3">
<h4><a id="common-syntax" name="common-syntax"></a>4.2.5 Common Syntax</h4>

<div class="exampleInner">
<pre>DIGIT         = &lt;DIGIT, defined in <cite><a href="#rfc5234">RFC 5234</a></cite>&gt;
pchar         = &lt;pchar, defined in <cite><a href="#rfc3986">RFC 3986</a></cite>&gt;
unreserved    = &lt;unreserved, defined in <cite><a href="#rfc3986">RFC 3986</a></cite>&gt;
pct-encoded   = &lt;pct-encoded, defined in <cite><a href="#rfc3986">RFC 3986</a></cite>&gt;
fragment      = &lt;pct-encoded, defined in <cite><a href="#rfc3986">RFC 3986</a></cite>&gt;

unichar       = &lt;any Unicode code point&gt;
unistring     = *unichar</pre>
</div>

<p>For convenience, the following definitions are copied here. Only the
definitions in the original documents are considered normative</p>

<div class="exampleInner">
<a id="importeddefs" name="importeddefs"></a>
<pre>; defined in <cite><a href="#rfc5234">RFC 5234</a></cite>
ALPHA         =  %x41-5A / %x61-7A   ; A-Z / a-z
DIGIT         =  %x30-39 ; 0-9
HEXDIG        =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"

; defined in <cite><a href="#rfc3986">RFC 3986</a></cite>
unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded   = "%" HEXDIG HEXDIG
sub-delims    = "!" / "$" / "&amp;" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
fragment      = *( pchar / "/" / "?" )</pre>
</div>
</div>
</div>
</div>

<div class="div1">
<h2><a id="media-fragment-processing" name="media-fragment-processing"></a>5
Media Fragments Processing</h2>

<p>This section defines the different exchange scenarios for the situations
explained in section <a href="#fragment-query"><b>3 URI fragment and URI
query</b></a> over the HTTP protocol. </p>

<p>The formal grammar defined in the section <a
href="#media-fragment-syntax"><b>4 Media Fragments Syntax</b></a> describes
what producers of media fragment should output. It is not taking into account
possible percent-encoding that are valid according to <cite><a
href="#rfc3986">RFC 3986</a></cite> and the grammar is not a specification of
how a media fragment should be parsed. Therefore, section <a
href="#processing-media-fragment-uri"><b>5.1 Processing Media Fragment
URI</b></a> defines how to parse media fragment URIs. </p>

<p>In a well known context where the MIME TYPE of the resource requested is
known, various recipes are proposed depending on the dimension addressed in the
media fragment URI, the container and codec formats used by the media resource,
or some advanced processing features implemented by the User Agent. Hence, if
the container format of the media resource is fully indexable (e.g. MP4, Ogg or
WebM) and if the time dimension is requested in the media fragment URI, the
User Agent MAY priviledge the recipe described in the section <a
href="#processing-protocol-frag"><b>5.2 Protocol for URI fragment Resolution in
HTTP</b></a> since it will be in a position of issuing directly a normal RANGE
request expressed in terms of byte ranges. On the other hand, if the container
format of the media resource is a legacy format such as AVI, the Use Agent MAY
priviledge the recipe described in the section <a
href="#processing-protocol-Server-mapped"><b>5.2.2 Server mapped byte
ranges</b></a>, issuing a RANGE request expressed with a custom unit such as
seconds and waiting for the server to provide the mapping in terms of byte
ranges. Finally, if the track dimension is requested in the media fragment URI,
the User Agent MAY priviledge the recipe described in the section <a
href="#server-triggered-redirect"><b>5.2.3 Server triggered redirect</b></a>.
</p>

<p>The User Agent MAY also implement a so-called optimistic processing of URI
fragments in particular cases where the MIME TYPE of the resource requested is
not yet known. Hence, if a URL fragment occurs within a particular context such
as the value of the @src attribute of a media element (audio, video or source)
and if the time dimension is requested in the media fragment URI, the User
Agent MAY follow the scenario specified in section <a
href="#processing-protocol-Server-mapped"><b>5.2.2 Server mapped byte
ranges</b></a> and issues directly a range request using custom units assuming
that the resource requested is likely to be a media resource. If the MIME-type
of this resource turns out to be a media type, the server SHOULD interpret the
RANGE request as specified in section <a
href="#processing-protocol-Server-mapped"><b>5.2.2 Server mapped byte
ranges</b></a>. Otherwise it SHOULD just ignore the RANGE header. </p>

<div class="div2">
<h3><a id="processing-media-fragment-uri"
name="processing-media-fragment-uri"></a>5.1 Processing Media Fragment URI</h3>

<p>This sections defines how to parse media fragment URIs defined in section <a
href="#media-fragment-syntax"><b>4 Media Fragments Syntax</b></a>, along with
notes on some of the caveats to be aware of. Implementors are free to use any
equivalent technique(s). </p>

<table border="1" summary="Editorial note: Raphael">
  <tbody>
    <tr>
      <td width="50%" valign="top" align="left"><b>Editorial note:
      Raphael</b></td>
      <td width="50%" valign="top" align="right"> </td>
    </tr>
    <tr>
      <td valign="top" align="left" colspan="2">To generate a simple figure
        that shows this processing: URI parsing (percent decoding) =&gt;
        name=value pairs =&gt; (rfc2047encoding) HTTP </td>
    </tr>
  </tbody>
</table>

<div class="div3">
<h4><a id="processing-name-value-components"
name="processing-name-value-components"></a>5.1.1 Processing name-value
components</h4>

<p>This section defines how to convert an octet string (from the query or
fragment component of a URI) into a list of name-value Unicode string pairs.
</p>
<ol class="enumar">
  <li><p>Parse the octet string according to the <a
    href="#namevalues">namevalues</a> syntax, yielding a list of name-value
    pairs, where name and value are both octet string. In accordance with
    <cite><a href="#rfc3986">RFC 3986</a></cite>, the name and value components
    must be parsed and separated before percent-encoded octets are decoded. </p>
  </li>
  <li><p>For each name-value pair: </p>
    <ol class="enumla">
      <li><p>Decode percent-encoded octets in name and value as defined by
        <cite><a href="#rfc3986">RFC 3986</a></cite>. If either name or value
        are not valid percent-encoded strings, then remove the name-value pair
        from the list. </p>
      </li>
      <li><p>Convert name and value to Unicode strings by interpreting them as
        <cite><a href="#utf-8">UTF-8</a></cite>. If either name or value are
        not valid UTF-8 strings, then remove the name-value pair from the list.
        </p>
      </li>
    </ol>
  </li>
</ol>

<p>Note that the output is well defined for any input. </p>

<p>Examples: </p>

<table border="1">
  <tbody>
    <tr>
      <th>Input</th>
      <th>Output</th>
      <th>Notes</th>
    </tr>
    <tr>
      <td>"t=1"</td>
      <td>[("t", "1")]</td>
      <td>simple case</td>
    </tr>
    <tr>
      <td>"t=1&amp;t=2"</td>
      <td>[("t", "1"), ("t", "2")]</td>
      <td>repeated name</td>
    </tr>
    <tr>
      <td>"a=b=c"</td>
      <td>[("a", "b=c")]</td>
      <td>"=" in value</td>
    </tr>
    <tr>
      <td>"a&amp;b=c"</td>
      <td>[("a", ""), ("b", "c")]</td>
      <td>missing value</td>
    </tr>
    <tr>
      <td>"%74=%6ept%3A%310"</td>
      <td>[("t", "npt:10")]</td>
      <td>unnecssary percent-encoding</td>
    </tr>
    <tr>
      <td>"id=%xy&amp;t=1"</td>
      <td>[("t", "1")]</td>
      <td>invalid percent-encoding</td>
    </tr>
    <tr>
      <td>"id=%E4r&amp;t=1"</td>
      <td>[("t", "1")]</td>
      <td>invalid UTF-8</td>
    </tr>
  </tbody>
</table>

<p>While the processing defined in this section is designed to be largely
compatible with the parsing of the URI query component in many HTTP server
environments, there are incompatible differences that implementors should be
aware of: </p>
<ul>
  <li><p>"&amp;" is the only primary separator for name-value pairs, but some
    server-side languages also treat ";" as a separator. </p>
  </li>
  <li><p>name-value pairs with invalid percent-encoding should be ignored, but
    some server-side languages silently mask such errors. </p>
  </li>
  <li><p>The "+" character should not be treated specially, but some
    server-side languages replace it with a space (" ") character. </p>
  </li>
  <li><p>Multiple occurrences of the same name must be preserved, but some
    server-side languages only preserve the last occurrence. </p>
  </li>
</ul>
</div>

<div class="div3">
<h4><a id="processing-name-value-lists"
name="processing-name-value-lists"></a>5.1.2 Processing name-value lists</h4>

<p>This section defines how to convert a list of name-value Unicode string
pairs into the media fragment dimensions. </p>

<p>Given the dimensions defined in section <a
href="#fragment-dimensions"><b>4.2 Fragment Dimensions</b></a>, each has a pair
of production rules that corresponds to the name and value component
respectively: </p>

<table border="1">
  <tbody>
    <tr>
      <th>Keyword</th>
      <th>Dimension</th>
    </tr>
    <tr>
      <td>t</td>
      <td><a href="#naming-time"><b>4.2.1 Temporal Dimension</b></a></td>
    </tr>
    <tr>
      <td>xywh</td>
      <td><a href="#naming-space"><b>4.2.2 Spatial Dimension</b></a></td>
    </tr>
    <tr>
      <td>track</td>
      <td><a href="#naming-track"><b>4.2.3 Track Dimension</b></a></td>
    </tr>
    <tr>
      <td>id</td>
      <td><a href="#naming-name"><b>4.2.4 Named Dimension</b></a></td>
    </tr>
  </tbody>
</table>
<ol class="enumar">
  <li><p>Initially, all dimension are undefined. </p>
  </li>
  <li><p>For each name-value pair: </p>
    <ol class="enumla">
      <li><p>If name matches a keyword in the above table, interpret value as
        per the corresponding section. </p>
      </li>
      <li><p>Otherwise, the name-value pair does not represent a media fragment
        dimension. Validators should emit a warning. User agents must ignore
        the name-value pair. </p>
      </li>
    </ol>
  </li>
</ol>

<p>Note: Because the name-value pairs are processed in order, the last valid
occurence of any dimension is the one that is used. </p>
</div>
</div>

<div class="div2">
<h3><a id="processing-protocol-frag" name="processing-protocol-frag"></a>5.2
Protocol for URI fragment Resolution in HTTP</h3>

<p>This section defines the protocol steps in HTTP <cite><a href="#rfc2616">RFC
2616</a></cite> to resolve and deliver a media fragment specified as a URI
fragment.</p>

<div class="div3">
<h4><a id="processing-protocol-UA-mapped"
name="processing-protocol-UA-mapped"></a>5.2.1 UA mapped byte ranges</h4>

<table border="1" summary="Editorial note">
  <tbody>
    <tr>
      <td width="50%" valign="top" align="left"><b>Editorial note</b></td>
      <td width="50%" valign="top" align="right"> </td>
    </tr>
    <tr>
      <td valign="top" align="left" colspan="2"><p>This section is ready to
        implement.</p>
      </td>
    </tr>
  </tbody>
</table>

<p>As described in section <a href="#URIfragment-user-agent"><b>3.2 Resolving
URI fragments within the user agent</b></a>, the most optimal case is a user
agent that knows how to map media fragments to byte ranges. This is the case
typically where a user agent has already downloaded those parts of a media
resource that allow it to do or guess the mapping, e.g. headers or a resource,
or an index of a resource. </p>

<p>In this case, the HTTP exchanges are exactly the same as for any other Web
resource where byte ranges are requested <cite><a href="#rfc2616">RFC
2616</a></cite>. </p>

<p>How the UA retrieves the byte ranges is dependent on the media type of the
media resource. We here show examples with only one byte range retrieval per
time range, which may in practice turn into several such retrieval actions
necessary to acquire the correct time range. </p>

<p>Here are the three principle cases a media fragment enabled UA and a media
Server will encounter:</p>

<div class="div4">
<h5><a id="processing-protocol-UA-mapped-new"
name="processing-protocol-UA-mapped-new"></a>5.2.1.1 UA requests URI fragment
for the first time</h5>

<p>A user requests a media fragment URI:</p>
<ul>
  <li><p>User → UA (1):</p>

    <div class="exampleInner">
    <pre>http://www.example.com/video.ogv#t=10,20</pre>
    </div>
  </li>
</ul>

<p>The UA has to check if a local copy of the requested fragment is available
in its buffer - not in this case. But it knows how to map the fragment to byte
ranges: 19147 - 22890. So, it requests these byte ranges from the server:</p>
<ul>
  <li><p>UA (1) → Proxy (2) → Origin Server (3):</p>

    <div class="exampleInner">
    <pre>GET /video.ogv HTTP/1.1
Host: www.example.com
Accept: video/*
Range: bytes=19147-22890</pre>
    </div>
  </li>
</ul>

<p>The server extracts the bytes corresponding to the requested range and
replies in a 206 HTTP response:</p>
<ul>
  <li><p>Origin Server (3) → Proxy (4) → UA (5):</p>

    <div class="exampleInner">
    <pre>HTTP/1.1 206 Partial Content
Accept-Ranges: bytes
Content-Length: 3743
Content-Type: video/ogg
Content-Range: bytes 19147-22880/35614993
Etag: "b7a60-21f7111-46f3219476580"

{binary data}</pre>
    </div>
  </li>
</ul>

<p>Assuming the UA has received the byte ranges that it requires to serve
t=10,20, which may well be slightly more, it will serve the decoded content to
the User from the appropriate time offset. Otherwise it may keep requesting
byte ranges to retrieve the required time segments.</p>
<img
src="MF-SD-ClientSide-5.2.1.1.png"
alt="Illustration of a UA requesting a URI fragment for the first time" /></div>

<div class="div4">
<h5><a id="processing-protocol-UA-mapped-unchanged"
name="processing-protocol-UA-mapped-unchanged"></a>5.2.1.2 UA requests URI
fragment it already has buffered</h5>

<p>A user requests a media fragment URI:</p>
<ul>
  <li><p>User → UA (1):</p>

    <div class="exampleInner">
    <pre>http://www.example.com/video.ogv#t=10,20</pre>
    </div>
  </li>
</ul>

<p>The UA has to check if a local copy of the requested fragment is available
in its buffer - it is in this case. But the resource could have changed on the
server, so it needs to send a conditional GET. It knows the byte ranges: 19147
- 22890. So, it requests these byte ranges from the server under condition of
it having changed:</p>
<ul>
  <li><p>UA (1) → Proxy (2) → Origin Server (3):</p>

    <div class="exampleInner">
    <pre>GET /video.ogv HTTP/1.1
Host: www.example.com
Accept: video/*
If-Modified-Since: Sat, 01 Aug 2009 09:34:22 GMT
If-None-Match: "b7a60-21f7111-46f3219476580"
Range: bytes=19147-22890</pre>
    </div>
  </li>
</ul>

<p>The server checks if the resource has changed by checking the date - in this
case, the resource was not modified. So, the server replies with a 304 HTTP
response. (Note that a If-Range header cannot be used, because if the entity
has changed, the entire resource would be sent.)</p>
<ul>
  <li><p>Origin Server (3) → Proxy (4) → UA (5):</p>

    <div class="exampleInner">
    <pre>HTTP/1.1 304 Not Modified
Accept-Ranges: bytes
Content-Length: 3743
Content-Type: video/ogg
Content-Range: bytes 19147-22880/35614993
Etag: "b7a60-21f7111-46f3219476580"</pre>
    </div>
  </li>
</ul>

<p>So, the UA serves the decoded resource to the User our of its existing
buffer.</p>
<img
src="MF-SD-ClientSide-5.2.1.2.png"
alt="Illustration of a UA requesting a URI fragment it already has buffered"
/></div>

<div class="div4">
<h5><a id="processing-protocol-UA-mapped-changed"
name="processing-protocol-UA-mapped-changed"></a>5.2.1.3 UA requests URI
fragment of a changed resource</h5>

<p>A user requests a media fragment URI and the UA sends the exact same GET
request as described in the previous subsection.</p>

<p>This time, the server checks if the resource has changed by checking the
date and it has been modified. Since the byte mapping may not be correct any
longer, the server can only tell the UA that the resource has changed and leave
all further actions to the UA. So, it sends a 412 HTTP response:</p>
<ul>
  <li><p>Origin Server (3) → Proxy (4) → UA (5):</p>

    <div class="exampleInner">
    <pre>HTTP/1.1 412 Precondition Failed
Accept-Ranges: bytes
Content-Length: 3743
Content-Type: video/ogg
Content-Range: bytes 19147-22880/22222222
Etag: "xxxxx-yyyyyyy-zzzzzzzzzzzzz"</pre>
    </div>
  </li>
</ul>

<p>So, the UA can only assume the resource has changed and re-retrieve what it
needs to get back to being able to retrieve fragments. For most resources this
may mean retrieving the header of the file. After this it is possible again to
do a byte range retrieval.</p>
<img
src="MF-SD-ClientSide-5.2.1.3.png"
alt="Illustration of a UA requesting a URI fragment it has buffered, but that changed"
/></div>
</div>

<div class="div3">
<h4><a id="processing-protocol-Server-mapped"
name="processing-protocol-Server-mapped"></a>5.2.2 Server mapped byte
ranges</h4>

<p>As described in section <a href="#URIfragment-server"><b>3.3 Resolving URI
fragments with server help</b></a>, some User Agents cannot undertake the
fragment-to-byte mapping themselves, because the mapping is not obvious. This
typically applies to media formats where the setup of the decoding pipeline
does not imply knowledge of how to map fragments to byte ranges, e.g. Ogg
without OggIndex. Thus, the User Agent would be capable of decoding a
continuous resource, but would not know which bytes to request for a media
fragment. </p>

<p>In this case, the User Agent could either guess what byte ranges it has to
retrieve and the retrieval action would follow the previous case. Or it could
hope that the server provides a special service, which would allow it to
retrieve the byte ranges with a simple request of the media fragment ranges.
Thus, the HTTP request of the User Agent will include a request for the
fragment hoping that the server can do the byte range mapping and send back the
appropriate byte ranges. This is realized by introducing new dimensions for the
HTTP Range header, next to the byte dimension. </p>

<p>The specification for all new Range Request Header dimensions is given
through the following ABNF as an extension to the HTTP Range Request Header
definition (see
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.35.2): </p>

<div class="exampleInner">
<a id="rangerequestheaderdef" name="rangerequestheaderdef"></a>
<pre>Range                  = "Range" ":" ranges-specifier
ranges-specifier       = byte-ranges-specifier | fragment-specifier
;
; note that ranges-specifier is extended from <cite><a href="#rfc2616">RFC 2616</a></cite>
; to cover alternate fragment range specifiers
;
fragment-specifier     = "include-setup" | fragment-range *( "," fragment-range )
                                                           [ ";" "include-setup" ]
fragment-range         = time-ranges-specifier | track-ranges-specifier | name-ranges-specifier
;
; note that this doesn't capture the restriction to one fragment dimension occurring
; maximally once only in the fragment-specifier definition.
;
time-ranges-specifier  = npttimeoption / smptetimeoption / clocktimeoption
npttimeoption          = pfxdeftimeformat "=" npt-sec   "-" [ npt-sec ]
smptetimeoption        = pfxsmpteformat   "=" frametime "-" [ frametime ]
clocktimeoption        = pfxclockformat   "=" datetime  "-" [ datetime ]

track-ranges-specifier = trackprefix "=" trackparam *( ";" trackparam )

name-ranges-specifier  = nameprefix  "=" nameparam</pre>
</div>

<p>This specification is meant to be analogous to the one in URIs, but it is a
bit stricter. The time unit is not optional. For instance, it can be "npt",
"smpte", "smpte-25", "smpte-30", "smpte-30-drop" or "clock" for temporal. Where
"ntp" is used for a temporal range, only specification in seconds is possible.
Where "clocktime" is used for a temporal range, only "datetime" is possible and
"walltime" is fully specified in HHMMSS with fraction and full timezone.
Indeed, all optional elements in the URI specification basically become
required in the Range header. </p>

<p>There is an optional 'include-setup' flag on the fragment range specifier -
this flag signals to the server whether delivery of the decoder setup
information (i.e. typically file header information) is also required as part
of the reply to this request. This can help avoid an extra roundtrip where a
Media Fragment URI is, e.g. directly typed into a Web browser. </p>

<p>If there were multiple track parameters provided in the media fragment URI,
they are all aggregated together here in a single track ranges specifier, where
the track names are separated by semi-colon. Note that if a track name did
include a semi-colon in the media fragment URI, it is now percent escaped. </p>

<p>Note that the specification does not foresee a Range dimension for spatial
media fragments since they are typically resolved and interpreted by the User
Agent (i.e., spatial fragment extraction is not performed on server-side) for
the following reasons: </p>
<ul>
  <li><p>spatial media fragments are typically not expressible in terms of byte
    ranges. Spatial fragment extraction would thus require transcoding
    operations resulting in new resources rather than fragments of the original
    media resource. As described in section <a href="#fragment-query"><b>3 URI
    fragment and URI query</b></a>, spatial fragment extraction is in this case
    better represented by URI queries. </p>
  </li>
  <li><p>When a User Agent receives an extracted spatial media fragment, it is
    not trivial to visualize the context of this fragment (see also section <a
    href="#media-fragment-display"><b>7.2 Clients Displaying Media
    Fragments</b></a>). More specifically, spatial context requires a
    meaningful background, which will not be available at the User Agent when
    the spatial fragment is extracted by the server. </p>
  </li>
</ul>

<table border="1" summary="Editorial note: Davy">
  <tbody>
    <tr>
      <td width="50%" valign="top" align="left"><b>Editorial note: Davy</b></td>
      <td width="50%" valign="top" align="right"> </td>
    </tr>
    <tr>
      <td valign="top" align="left" colspan="2"><p>Special attention should be
        paid for named fragments and more specifically when a named fragment
        represents a spatial fragment. We should clearly describe 1. what named
        fragments are and 2. how they are resolved.</p>
      </td>
    </tr>
  </tbody>
</table>

<p>Next to the introduction of new dimensions for the HTTP Range request
header, we also introduce a new HTTP response header, called
Content-Range-Mapping, which provides the mapping of the retrieved byte range
to the original Range request, which was not in bytes. It serves two
purposes:</p>
<ul>
  <li><p>It Indicates the actual mapped range in terms of fragment dimensions.
    This is necessary since the server might not be able to provide a byte
    range mapping that corresponds exactly to the requested range. Therefore,
    the User Agent needs to be aware of this variance. </p>
  </li>
  <li><p>It provides context information regarding the parent resource in case
    the Range request contained a temporal dimension. More specifically, the
    header contains the start and end time of the parent resource. This way,
    the User Agent is able to understand and visualize the temporal context of
    the media fragment. </p>
  </li>
</ul>

<p>The specification for the Content-Range-Mapping header is based on the
specification of the Content-Range header (see
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.16) and is shown
below. Note that the Content-Range-Mapping header adds in case of the temporal
dimension the instance start and end in terms of seconds after a slash "/"
character in analogy to the Content-Range header. Also, we introduce an
extension to the Accept-Ranges header (see
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.5). </p>

<div class="exampleInner">
<a id="contentrangemappingheaderdef" name="contentrangemappingheaderdef"></a>
<pre>Content-Range-Mapping      = "Content-Range-Mapping" ":" '{'
                             ( content-range-mapping-spec [ ";" def-include-setup ] ) / def-include-setup
                             '}' '=' '{'
                             byte-content-range-mapping-spec '}'

def-include-setup          = %x69.6E.63.6C.75.64.65.2D.73.65.74.75.70  ; "include-setup"

byte-range-mapping-spec    = bytes-unit SP
                             byte-range-resp-spec *( "," byte-range-resp-spec ) "/"
                             ( instance-length / "*" )

content-range-mapping-spec = time-mapping-spec | track-mapping-spec | name-mapping-spec
time-mapping-spec          = timeprefix ":" time-mapping-options
time-mapping-options       = npt-mapping-option / smpte-mapping-option / clock-mapping-option
npt-mapping-option         = deftimeformat SP npt-sec   "-" npt-sec   "/"
                                          [ npt-sec ]   "-" [ npt-sec ]
smpte-mapping-option       = smpteformat   SP frametime "-" frametime "/"
                                          [ frametime ] "-" [ frametime ]
clock-mapping-option       = clockformat   SP datetime  "-" datetime  "/"
                                          [ datetime ]  "-" [ datetime ]

track-mapping-spec         = trackprefix SP trackparam *( ";" trackparam )

name-mapping-spec          = nameprefix  SP nameparam

Accept-Ranges              = "Accept-Ranges" ":" acceptable-ranges
acceptable-ranges          = 1#range-unit *( "," 1#range-unit )| "none"
;
; note this does not represent the restriction that range-units can only appear once at most
;
range-unit                 = bytes-unit | other-range-unit
bytes-unit                 = "bytes"
other-range-unit           = token | timeprefix | trackprefix | nameprefix</pre>
</div>

<p>Three cases can be distinguished when a User Agent needs assistance by a
server to perform the byte range mapping. In the next subsections, we'll go
through the protocol exchange action step by step. </p>

<div class="div4">
<h5><a id="processing-protocol-server-mapped-default"
name="processing-protocol-server-mapped-default"></a>5.2.2.1 Server mapped byte
ranges with corresponding binary data</h5>
<ul>
  <li><p>User → UA (1):</p>

    <div class="exampleInner">
    <pre>http://www.example.com/video.ogv#t=10,20</pre>
    </div>
  </li>
</ul>

<p>The UA has to check if a local copy of the requested fragment is available
in its buffer. If it is, we revert back to the processing described in sections
<a href="#processing-protocol-UA-mapped-unchanged"><b>5.2.1.2 UA requests URI
fragment it already has buffered</b></a> and <a
href="#processing-protocol-UA-mapped-changed"><b>5.2.1.3 UA requests URI
fragment of a changed resource</b></a>, since the UA already knows the mapping
to byte ranges. If the requested fragment is not available in its buffer, the
UA sends an HTTP request to the server, including a Range header with temporal
dimension. The request is shown below: </p>
<ul>
  <li><p>UA (1) → Proxy (2) → Origin Server (3):</p>

    <div class="exampleInner">
    <pre>GET /video.ogv HTTP/1.1
Host: www.example.com
Accept: video/*
Range: t:npt=10-20</pre>
    </div>
  </li>
</ul>

<p>If the server does not understand a Range header, it MUST ignore the header
field that includes that range-set. This is in sync to the HTTP RFC <cite><a
href="#rfc2616">RFC 2616</a></cite>. This means that where a server does not
support media fragments, the complete resource will be delivered. It also means
that we can combine both, byte range and fragment range headers in one request,
since the server will only react to the Range header it understands. </p>

<p>Assuming the server can map the given Range to one or more byte ranges, it
will reply with these in a 206 HTTP response. Where multiple byte ranges are
required to satisfy the Range request, these are transmitted as a multipart
message-body. The media type for this purpose is called "multipart/byteranges".
This is in sync with the HTTP RFC <cite><a href="#rfc2616">RFC 2616</a></cite>.
</p>

<p>Here is the reply to the example above, assuming a single byte range is
sufficient:</p>
<ul>
  <li><p>Origin Server (3) → Proxy (4) → UA (5):</p>

    <div class="exampleInner">
    <pre>HTTP/1.1 206 Partial Content
Accept-Ranges: bytes, t, track, id
Content-Length: 3743
Content-Type: video/ogg
Content-Range: bytes 19147-22880/35614993
Content-Range-Mapping: { t:npt 9.85-21.16/0.0-653.79 } = { bytes 19147-22880/35614993 }
Etag: "b7a60-21f7111-46f3219476580"

{binary data}</pre>
    </div>
  </li>
</ul>

<p>Note the presence of the new reply header called Content-Range-Mapping,
which provides the mapping of the retrieved byte range to the original
Content-Range request, which was not in bytes. As we return both, byte and
temporal ranges, the UA and any intermediate caching proxy is enabled to map
byte positions with time offsets and fall back to byte range request where the
fragment is re-requested. Also note that through the extended list in the
Accept-Ranges it is possible to identify which fragment schemes a server
supports. </p>
<img
src="MF-SD-ServerSide.png"
alt="Illustration of a UA requesting a URI time to byte range mapping from the server "
/>

<p>In the case where a media fragment results in a multipart message-body, the
Content-Range headers will be spread throughout the binary data ranges, but the
Content-Range-Mapping of the media fragment will only be with the main header.
Note that requesting track fragments typically result in multipart
message-bodies, on condition that the parent resource is characterized by
interleaved tracks. For example:</p>
<ul>
  <li><p>Origin Server (3) → Proxy (4) → UA (5):</p>

    <div class="exampleInner">
    <pre>HTTP/1.1 206 Partial Content
Accept-Ranges: bytes, t, track, id
Content-Length: 3743
Content-Type: video/ogg
Content-Range-Mapping: { track audio1;video1 } = { bytes 123-2589, 14560-27891,58909-81230/35614993 }
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
Etag: "b7a60-21f7111-46f3219476580"

--THIS_STRING_SEPARATES
Content-type: video/ogg
Content-Range: bytes 123-2589/35614993
{binary data}
--THIS_STRING_SEPARATES
Content-type: video/ogg
Content-Range: bytes 14560-27891/35614993
{binary data}
--THIS_STRING_SEPARATES
Content-type: video/ogg
Content-Range: bytes 58909-81230/35614993
{binary data}
--THIS_STRING_SEPARATES--</pre>
    </div>
  </li>
</ul>

<p>Note that a caching proxy that does not understand a Range header must not
cache "206 Partial Content" responses as per HTTP RFC <cite><a
href="#rfc2616">RFC 2616</a></cite>. Thus, the new Range requests won't be
cached by legacy Web proxies. </p>
</div>

<div class="div4">
<h5><a id="processing-protocol-server-mapped-setup"
name="processing-protocol-server-mapped-setup"></a>5.2.2.2 Server mapped byte
ranges with corresponding binary data and codec setup data</h5>

<p>When the User Agent needs help from the server to setup the initial decoding
pipeline (i.e., the User Agent has no codec setup information at its disposal),
the User Agent can request, next to the bytes corresponding to the requested
fragment, the bytes necessary to setup its decoder. This is possible by adding
the 'include-setup' flag to the Range header, as illustrated below: </p>
<ul>
  <li><p>UA (1) → Proxy (2) → Origin Server (3):</p>

    <div class="exampleInner">
    <pre>GET /video.ogv HTTP/1.1
Host: www.example.com
Accept: video/*
Range: t:npt=10-20;include-setup</pre>
    </div>
  </li>
</ul>

<p>Analogous to section <a
href="#processing-protocol-server-mapped-default"><b>5.2.2.1 Server mapped byte
ranges with corresponding binary data</b></a>, the server can map the given
Range to one or more byte ranges, it will reply with these in a 206 HTTP
response. Additionally, the server adds the bytes corresponding with the
requested setup information to the response. Since this setup information
usually appears in front of a media resource, the response typically results in
a multipart message-body. The response is shown below: </p>
<ul>
  <li><p>Origin Server (3) → Proxy (4) → UA (5):</p>

    <div class="exampleInner">
    <pre>HTTP/1.1 206 Partial Content
Accept-Ranges: bytes, t, track, id
Content-Length: 3795
Content-Type: video/ogg
Content-Range-Mapping: { t:npt 11.85-21.16/0.0-653.79;include-setup } = { bytes  0-52,19147-22880/35614993 }
Content-type: multipart/byteranges; boundary=THIS_STRING_SEPARATES
Etag: "b7a60-21f7111-46f3219476580"

--THIS_STRING_SEPARATES
Content-type: video/ogg
Content-Range: bytes 0-52/35614993
{binary data}
--THIS_STRING_SEPARATES
Content-type: video/ogg
Content-Range: bytes 19147-22880/35614993
{binary data}
--THIS_STRING_SEPARATES--</pre>
    </div>
  </li>
</ul>

<p>Note that the Content-Range-Mapping header indicates that the codec setup
information is included in the response. In this example, the response consists
of two parts of byte ranges: the first part corresponds to the setup
information, the second part corresponds to the requested fragment. </p>
<img
src="MF-SD-ServerSideSetup.png"
alt="Illustration of a UA requesting a URI time to byte range mapping from the server, including the codec setup information "
/></div>

<div class="div4">
<h5><a id="processing-protocol-server-mapped-proxy"
name="processing-protocol-server-mapped-proxy"></a>5.2.2.3 Proxy cacheable
server mapped byte ranges</h5>

<p>As described in section <a href="#URIfragment-proxies"><b>3.4 Resolving URI
fragments in a proxy cacheable manner</b></a>, the server mapped byte ranges
approach can be extended to play with existing caching Web proxy
infrastructure. This is important, since video is a huge bandwidth eater in the
current Internet and falling back to using existing Web proxy infrastructure is
important, particularly since progressive download and direct access mechanisms
for video rely heavily on this functionality. Over time, the proxy
infrastructure will learn how to cache media fragment URIs directly as
described in the previous section and then will not require this extra effort.
</p>

<p>To enable media-fragment-URI-supporting UAs to make their retrieval
cacheable, we introduce some extra HTTP headers, which will help tell the
server and the proxy what to do. There is an Accept-Range-Redirect request
header which signals to the server that only a redirect to the correct byte
ranges is necessary and the result should be delivered in the Range-Redirect
header. </p>

<p>The ABNF for these additional two HTTP headers is given as follows:</p>

<div class="exampleInner">
<a id="rangeredirectdefs" name="rangeredirectdefs"></a>
<pre>Accept-Range-Redirect      = "Accept-Range-Redirect" ":" bytes-unit

Range-Redirect             = "Range-Redirect" ":" byte-range-resp-spec *( "," byte-range-resp-spec )</pre>
</div>

<p>Let's play it through on an example. A user requests a media fragment URI:
</p>
<ul>
  <li><p>User → UA (1):</p>

    <div class="exampleInner">
    <pre>http://www.example.com/video.ogv#t=10,20</pre>
    </div>
  </li>
</ul>

<p>The UA has to check if a local copy of the requested fragment is available
in its buffer. In our case here, it is not. If it was, we would revert back to
the processing described in sections <a
href="#processing-protocol-UA-mapped-unchanged"><b>5.2.1.2 UA requests URI
fragment it already has buffered</b></a> and <a
href="#processing-protocol-UA-mapped-changed"><b>5.2.1.3 UA requests URI
fragment of a changed resource</b></a>, since the UA already knows the mapping
to byte ranges. The UA issues a HTTP GET request with the fragment and
requesting to retrieve just the mapping to byte ranges: </p>
<ul>
  <li><p>UA (1) → Proxy (2) → Origin Server (3):</p>

    <div class="exampleInner">
    <pre>GET /video.ogv HTTP/1.1
Host: www.example.com
Accept: video/*
Range: t:npt=10-20
Accept-Range-Redirect: bytes</pre>
    </div>
  </li>
</ul>

<p>The server converts the given time range to a byte range and sends an empty
reply that refers the UA to the right byte range for the correct time range.
</p>
<ul>
  <li><p>Origin Server (3) → Proxy (4) → UA (5):</p>

    <div class="exampleInner">
    <pre>HTTP/1.1 307 Temporary Redirect
Location: http://www.example.com/video.ogv
Accept-Ranges: bytes, t, track, id
Content-Length: 0
Content-Type: video/ogg
Content-Range-Mapping: { t:npt 11.85-21.16/0.0-653.79 } = { bytes 19147-22880/* }
Range-Redirect: 19147-22880
Vary: Accept-Range-Redirect</pre>
    </div>
  </li>
</ul>

<p>Note that codec setup information can also be requested in combination with
the Accept-Range-Redirect header, which can be realized by adding the
'include-setup' flag to the Range request header. </p>

<p>The UA proceeds to put the actual fragment request through as a normal byte
range request as in section <a
href="#processing-protocol-UA-mapped-new"><b>5.2.1.1 UA requests URI fragment
for the first time</b></a>: </p>
<ul>
  <li><p>UA (5) → Proxy (6) → Origin Server (7):</p>

    <div class="exampleInner">
    <pre>GET /video.ogv HTTP/1.1
Host: www.example.com
Accept: video/*
Range: 19147-22880</pre>
    </div>
  </li>
</ul>

<p>The Origin Server puts the data together and sends it to the UA:</p>
<ul>
  <li><p>Origin Server (7) → Proxy (8) → UA (9):</p>

    <div class="exampleInner">
    <pre>HTTP/1.1 206 Partial Content
Accept-Ranges: bytes, t, track, id
Content-Length: 3743
Content-Type: video/ogg
Content-Range: bytes 19147-22880/35614993
Etag: "b7a60-21f7111-46f3219476580"

{binary data}</pre>
    </div>
  </li>
</ul>

<p>The UA decodes the data and displays it from the requested offset. The
caching Web proxy in the middle has now cached the byte range, since it adhered
to the normal byte range request protocol. All existing caching proxies will
work with this. New caching Web proxies may learn to interpret media fragments
natively, so won't require the extra packet exchange described in this
section.</p>
<img
src="MF-SD-ProxyCacheable.png"
alt="Illustration of a UA requesting a URI time to byte range mapping from the server with proxy capability of byte ranges"
/></div>
</div>

<div class="div3">
<h4><a id="server-triggered-redirect"
name="server-triggered-redirect"></a>5.2.3 Server triggered redirect</h4>

<p>When a server decides not to serve the requested media fragment in terms of
byte ranges (i.e., serving the requested media fragment as specified in section
<a href="#processing-protocol-Server-mapped"><b>5.2.2 Server mapped byte
ranges</b></a>), it can redirect the UA to a representation of this fragment
(for instance by transforming the media fragment URI into a media fragment
query, as specified in section <a href="#processing-protocol-query"><b>5.3
Protocol for URI query Resolution in HTTP</b></a>). This is particularly useful
in cases where too many byte ranges would need to e extracted to satisfy the
range request. </p>

<p>A user requests a media fragment URI using a URI fragment:</p>
<ul>
  <li><p>User → UA (1):</p>

    <div class="exampleInner">
    <pre>http://www.example.com/video.ogv#track=video1</pre>
    </div>
  </li>
</ul>

<p>Subsequently, the UA requests the media fragment from the server using the
Range header:</p>
<ul>
  <li><p>UA (1) → Proxy (2) → Origin Server (3):</p>

    <div class="exampleInner">
    <pre>GET /video.ogv HTTP/1.1
Host: www.example.com
Accept: video/*
Range: track=video1</pre>
    </div>
  </li>
</ul>

<p>The server decides not to serve the requested media fragment in terms of
byte ranges (for instance, because the track media fragment results in too many
byte ranges). The server redirects the UA to an alternate representation. For
example, the URI fragment can be transformed into a URI query. Further, a Link
header is added stating that the redirected location is a fragment of the
originally requested resource. </p>
<ul>
  <li><p>Origin Server (3) → Proxy (4) → UA (5):</p>

    <div class="exampleInner">
    <pre>HTTP/1.1 307 Temporary Redirect
Location: http://www.example.com/video.ogv?track=video1
Accept-Ranges: bytes, t, track, id
Content-Length: 0
Content-Type: video/ogg
Link: &lt;http://www.example.com/video.ogv#track=video1&gt;; rel="fragment"
Vary: *</pre>
    </div>
  </li>
</ul>

<table border="1" summary="Editorial note: Davy">
  <tbody>
    <tr>
      <td width="50%" valign="top" align="left"><b>Editorial note: Davy</b></td>
      <td width="50%" valign="top" align="right"> </td>
    </tr>
    <tr>
      <td valign="top" align="left" colspan="2"><p>We need to register the
        'fragment' Link Relation <cite><a href="#webLinking">Web
        Linking</a></cite>. </p>
      </td>
    </tr>
  </tbody>
</table>

<p>Finally, the UA follows the redirect, which in this case corresponds to the
process specified in section <a href="#processing-protocol-query"><b>5.3
Protocol for URI query Resolution in HTTP</b></a>.</p>

<p>The server can also decide to combine a redirect and a media fragment
URI:</p>
<ul>
  <li><p>User → UA (1):</p>

    <div class="exampleInner">
    <pre>http://www.example.com/video.ogv#track=video1&amp;t=10,20</pre>
    </div>
  </li>
</ul>

<p>The UA requests the media fragment to the server using the Range header:</p>
<ul>
  <li><p>UA (1) → Proxy (2) → Origin Server (3):</p>

    <div class="exampleInner">
    <pre>GET /video.ogv HTTP/1.1
Host: www.example.com
Accept: video/*
Range: track=video1,t:npt=10-20</pre>
    </div>
  </li>
</ul>

<p>The server decides not to serve the requested media fragment in terms of
byte ranges and redirects the UA to an alternate representation. However, in
this case, the server decides to handle the track fragment through a URI query
and the temporal fragment through a URI fragment: </p>
<ul>
  <li><p>Origin Server (3) → Proxy (4) → UA (5):</p>

    <div class="exampleInner">
    <pre>HTTP/1.1 307 Temporary Redirect
Location: http://www.example.com/video.ogv?track=video1#t=10,20
Accept-Ranges: bytes, t, track, id
Content-Length: 0
Content-Type: video/ogg
Link: &lt;http://www.example.com/video.ogv#track=video1&amp;t=10,20&gt;; rel="fragment"
Vary: *</pre>
    </div>
  </li>
</ul>

<p>Finally, the UA follows the redirect, which in this case corresponds to the
process specified in section <a href="#processing-protocol-query"><b>5.3
Protocol for URI query Resolution in HTTP</b></a> for the track fragment,
combined with the process specified in section <a
href="#processing-protocol-Server-mapped"><b>5.2.2 Server mapped byte
ranges</b></a> for the temporal fragment. </p>
<img
src="MF-SD-ServerTriggeredRedirect.png"
alt="Illustration of a UA requesting a combined track and temporal media fragment URI and a server using a server triggered redirect."
/></div>
</div>

<div class="div2">
<h3><a id="processing-protocol-query" name="processing-protocol-query"></a>5.3
Protocol for URI query Resolution in HTTP</h3>

<p>This section describes the protocol steps used in HTTP <cite><a
href="#rfc2616">RFC 2616</a></cite> to resolve and deliver a media fragment
specified as a URI query.</p>

<p>A user requests a media fragment URI using a URI query:</p>
<ul>
  <li><p>User → UA (1):</p>

    <div class="exampleInner">
    <pre>http://www.example.com/video.ogv?t=10,20</pre>
    </div>
  </li>
</ul>

<p>This is a full resource, so it is a simple HTTP retrieval process. The UA
has to check if a local copy of the requested resource is available in its
buffer. If yes, it does a conditional GET with e.g. an If-Modified-Since and
If-None-Match HTTP header.</p>

<p>Assuming the resource has not been retrieved before, the following is sent
to the server:</p>
<ul>
  <li><p>UA (1) → Proxy (2) → Origin Server (3):</p>

    <div class="exampleInner">
    <pre>GET /video.ogv?t=10,20 HTTP/1.1
Host: www.example.com
Accept: video/*</pre>
    </div>
  </li>
</ul>

<p>If the server doesn't understand these query parameters, it typically
ignores them and returns the complete resource. This is not a requirement by
the URI or the HTTP standard, but the way it is typically implemented in Web
browsers.</p>

<p>A media fragment supporting server has to create a complete media resource
for the URI query, which in the case of Ogg requires creation of a new resource
by adapting the existing Ogg file headers and combining them with the extracted
byte range that relates to the given fragment. Some of the codec data may also
need to be re-encoded since, e.g. t=10 does not fall clearly on a decoding
boundary, but the retrieved resource must match as closely as possible the URI
query. This new resource is sent back as a reply: </p>
<ul>
  <li><p>Origin Server (3) → Proxy (4) → UA (5):</p>

    <div class="exampleInner">
    <pre>HTTP/1.1 200 OK
Content-Length: 3782
Content-Type: video/ogg
Etag: "b7a60-21f7111-46f3219476580"
Link: &lt;http://www.example.com/video.ogv#t=10,20&gt;; rel="alternate"

{binary data}</pre>
    </div>
  </li>
</ul>

<p>Note that a Link header MAY be provided indicating the relationship between
the requested URI query and the original media fragment URI. This enables the
UA to retrieve further information about the original resource, such as its
full length. In this case, the user agent is also enable to choose to display
the dimensions of the primary resource or the ones created by the query.</p>

<p>The UA serves the decoded resource to the user. Caching in Web proxies works
as it has always worked - most modern Web servers and UAs implement a caching
strategy for URIs that contain a query using one of the three methods for
marking freshness: heuristic freshness analysis, the Cache-Control header, or
the Expires header. In this case, many copies of different segments of the
original resource video.ogv may end up in proxy caches. An intelligent media
proxy in future may devise a strategy to buffer such resources in a more
efficient manner, where headers and byte ranges are stored differently.</p>

<p>Further, media fragment URI queries can be extended to enable UAs to use the
Range-Redirect HTTP header to also revert back to a byte range request. This is
analogous to section <a
href="#processing-protocol-server-mapped-proxy"><b>5.2.2.3 Proxy cacheable
server mapped byte ranges</b></a>.</p>

<p>Note that a server that does not support media fragments through either URI
fragment or query addressing will return the full resource in either case. It
is therefore not possible to first try URI fragment addressing and when that
fails to try URI query addressing.</p>
</div>
</div>

<div class="div1">
<h2><a id="media-fragment-semantics" name="media-fragment-semantics"></a>6
Media Fragments Semantics</h2>

<p>Errors can occur at several levels:</p>
<ul>
  <li>the complete URI (e.g. spatial dimension on a audio resource)</li>
  <li>the combination of name-value strings (e.g. name and time dimension
    combined)</li>
  <li>the name-value string (e.g. invalid percent-encoding)</li>
  <li>the name dimension (e.g. undefined dimension)</li>
  <li>the value (e.g. invalid NPT syntax)</li>
</ul>

<p>We will look at errors in the different dimensions and their values in the
subsequent sub-sections and we will start with errors on the more general
levels. </p>

<div class="div2">
<h3><a id="error-general" name="error-general"></a>6.1 Errors on the General
URI level</h3>

<div class="div3">
<h4><a id="error-general-non-existent"
name="error-general-non-existent"></a>6.1.1 Non-existent dimension:</h4>

<p>Attempting to do fragment selection on a dimension that does not exist in
the source media, such as temporal clipping on a still image or spatial
clipping on an audio file, should be considered a no-op and not throw an error.
</p>
</div>

<div class="div3">
<h4><a id="error-general-underspec" name="error-general-underspec"></a>6.1.2
Under-specified Dimension</h4>

<p>The result of doing spatial clipping on a media resource that has multiple
video tracks is that the spatial clipping is applied to all tracks. </p>
</div>
</div>

<div class="div2">
<h3><a id="error-temporal" name="error-temporal"></a>6.2 Errors on the temporal
dimensions</h3>

<p>Assuming a single temporal dimension is present, we now analyse what
fragment values may be specified here and how they should be handled. </p>

<p>For this, we make the following definitions: </p>
<ul>
  <li>s: the start point of the media and s &gt;= 0</li>
  <li>e: the end point of the media (i.e. duration = e - s ) and s &lt; e</li>
  <li>a: a positive integer, a &gt;= 0</li>
  <li>b: a positive integer, b &gt;= 0</li>
</ul>

<div class="div3">
<h4><a id="error-temporal-valid" name="error-temporal-valid"></a>6.2.1 Valid
requests</h4>

<p>For t=a,b with a &lt;= b</p>
<ul>
  <li>t=, results in the HTTP status code 206: deliver from s to e</li>
  <li>t=a, with s &lt;= a, a &lt; e results in the HTTP status code 206:
    deliver from a to e</li>
  <li>t=a, or t=a with a &lt; s results in the HTTP status code 206: deliver
    from s to e</li>
  <li>t=,b with s &lt; b, b &lt;= e results in the HTTP status code 206:
    deliver from s to b</li>
  <li>t=,b with e &lt; b results in the HTTP status code 206: deliver from s to
    e</li>
  <li>t=a,b with s = a, b = e restulst in the HTTP status code 206: deliver
    from s to e</li>
  <li>t=a,b with s &lt;= a, a &lt; b, a &lt; e and b &lt;= e results in the
    HTTP status code 206: deliver from a to b (the normal case)</li>
  <li>t=a,b with s &lt;= a, a &lt; b, a &lt; e and e &lt; b results in the HTTP
    status code 206: deliver from a to e</li>
  <li>t=a,b with a &lt; s, a &lt; b, s &lt; b and b &lt;= e results in the HTTP
    status code 206: deliver from s to b</li>
  <li>t=a,b with a &lt; s, a &lt; b and e &lt; b results in the HTTP status
    code 206: deliver from s to e</li>
  <li>%74=10,20 resolve percent encoding to t=10,20</li>
  <li>t=%31%30 resolve percent encoding to t=10</li>
  <li>t=10%2C20 resolve percent encoding to t=10,20</li>
  <li>t=%6ept:10 resolve percent encoding to t=npt:10</li>
  <li>t=npt%3a10 resolve percent encoding to t=npt:10</li>
</ul>

<table border="1" summary="Editorial note: Raphael">
  <tbody>
    <tr>
      <td width="50%" valign="top" align="left"><b>Editorial note:
      Raphael</b></td>
      <td width="50%" valign="top" align="right"> </td>
    </tr>
    <tr>
      <td valign="top" align="left" colspan="2"><p>The following paragraph is
        controversial since it could lead to non-interoperable
        implementations.</p>
      </td>
    </tr>
  </tbody>
</table>

<table border="1" summary="Editorial note: Silvia">
  <tbody>
    <tr>
      <td width="50%" valign="top" align="left"><b>Editorial note:
      Silvia</b></td>
      <td width="50%" valign="top" align="right"> </td>
    </tr>
    <tr>
      <td valign="top" align="left" colspan="2"><p>If the UA needs to retrieve
        a large part of the resource or even the full resource, it will
        probably decide to make multiple range requests rather than a single
        one. If the resource is, however, small, it may decide to just retrieve
        the full resource without a range request. The UA should make this
        choice given context information, e.g. if it knows that it will be a
        lot of data, it will retrieve it in smaller chunks. If it chooses to
        request the full resource in one go and not make use of a Range
        request, the result will be a 200 rather than a 206. </p>
      </td>
    </tr>
  </tbody>
</table>
</div>

<div class="div3">
<h4><a id="error-temporal-empty" name="error-temporal-empty"></a>6.2.2
Empty</h4>

<p>The resolved time segment is empty.</p>
<ul>
  <li>t=a,a results in a HTTP Range request with 'include-setup' as specified
    in section <a href="#processing-protocol-server-mapped-setup"><b>5.2.2.2
    Server mapped byte ranges with corresponding binary data and codec setup
    data</b></a> unless the UA is already set up for this resource in which
    case it will not undertake an unnecessary retrieval request. Results in 206
    for the setup data.</li>
</ul>

<p>Effect: retrieve whatever the browser needs to set up playback, but
otherwise nothing</p>
</div>

<div class="div3">
<h4><a id="error-temporal-non-existent"
name="error-temporal-non-existent"></a>6.2.3 Non-existent</h4>

<p>The value resolves to a non-existent fragment. </p>

<p>If the UA is already set up for decoding the resource and it can identify
that the fragment is non-existent (i.e. knows about start and end times), it
will avoid undertaking an unnecessary retrieval action. Otherwise it will
undertake the RANGE retrieval request with the 'include-setup' as specified in
section <a href="#processing-protocol-server-mapped-setup"><b>5.2.2.2 Server
mapped byte ranges with corresponding binary data and codec setup data</b></a>
and will receive a 206 with just the setup data. If the UA is set up for
decoding, but cannot identify that the fragment is non-existent and does the
retrieval action without the 'include-setup', it will result in a 416. </p>
<ul>
  <li>t=a,b with s &lt; a, a &lt; b, a &gt;= e and b &gt; e retrieves nothing
    since interval beyond end of the resource</li>
  <li>t=a,b with a &lt; s, a &lt; b, b &lt;= s and b &lt; e retrieves nothing
    since interval ahead of start of the resource</li>
  <li>t=a, with a &gt;= e retrieves nothing since interval beyond end of the
    resource</li>
  <li>t=,a with a &lt;= s retrieves nothing since interval ahead of start of
    the resource</li>
</ul>

<p>Effect: retrieve whatever the browser needs to set up playback, but
otherwise nothing</p>
</div>

<div class="div3">
<h4><a id="error-temporal-validity" name="error-temporal-validity"></a>6.2.4
Validity error</h4>

<p>The value cannot be parsed for the dimension.</p>

<p>If the UA is already set up for decoding the resource, it will identify that
the fragment is invalid and avoid undertaking an unnecessary retrieval action.
Otherwise it will undertake the RANGE retrieval request with the
'include-setup' as specified in section <a
href="#processing-protocol-server-mapped-setup"><b>5.2.2.2 Server mapped byte
ranges with corresponding binary data and codec setup data</b></a> and will
receive a 206 with just the setup data. </p>

<p>Examples:</p>
<ul>
  <li>t=a,b with a &gt; b retrieves nothing since inverted interval</li>
  <li>t=asdf</li>
  <li>t=5,ekj</li>
  <li>t=agk,9</li>
  <li>t='0'</li>
  <li>t=10-20</li>
  <li>t=10:20</li>
  <li>t=10,20,40</li>
  <li>t%3D10 where %3D is equivalent to =; percent encoding does not
  resolve</li>
</ul>

<p>Effect: retrieve whatever the browser needs to set up playback, but
otherwise nothing</p>
</div>

<div class="div3">
<h4><a id="error-temporal-smpte-mismatch"
name="error-temporal-smpte-mismatch"></a>6.2.5 SMPTE time code mismatch</h4>

<p>When there is a mismatch between the SMPTE time code used by the UA and the
encoding settings of the requested media resource (e.g., use of smpte-25 time
code when the media resource is encoded at 30fps), the server MUST ignore the
RANGE header and returns the whole resource (i.e., a 200). </p>
</div>
</div>

<div class="div2">
<h3><a id="error-spatial" name="error-spatial"></a>6.3 Errors on the spatial
dimensions</h3>

<p>Assuming a single spatial dimension is present, we now analyse what content
can appear here and how it should be handled. </p>

<table border="1" summary="Editorial note: Silvia">
  <tbody>
    <tr>
      <td width="50%" valign="top" align="left"><b>Editorial note:
      Silvia</b></td>
      <td width="50%" valign="top" align="right"> </td>
    </tr>
    <tr>
      <td valign="top" align="left" colspan="2"><p>This list still has to be
        provided.</p>
      </td>
    </tr>
  </tbody>
</table>
</div>

<div class="div2">
<h3><a id="error-track" name="error-track"></a>6.4 Errors on the track
dimensions</h3>

<p>Assuming a single track dimension is present, we now analyse what content
can appear here and how it should be handled. </p>

<table border="1" summary="Editorial note: Silvia">
  <tbody>
    <tr>
      <td width="50%" valign="top" align="left"><b>Editorial note:
      Silvia</b></td>
      <td width="50%" valign="top" align="right"> </td>
    </tr>
    <tr>
      <td valign="top" align="left" colspan="2"><p>This list still has to be
        provided.</p>
      </td>
    </tr>
  </tbody>
</table>
</div>

<div class="div2">
<h3><a id="error-named" name="error-named"></a>6.5 Errors on the named
dimensions</h3>

<p>Assuming a single named dimension is present, we now analyse what content
can appear here and how it should be handled. </p>

<table border="1" summary="Editorial note: Silvia">
  <tbody>
    <tr>
      <td width="50%" valign="top" align="left"><b>Editorial note:
      Silvia</b></td>
      <td width="50%" valign="top" align="right"> </td>
    </tr>
    <tr>
      <td valign="top" align="left" colspan="2"><p>This list still has to be
        provided.</p>
      </td>
    </tr>
  </tbody>
</table>
</div>
</div>

<div class="div1">
<h2><a id="implementor-notes" name="implementor-notes"></a>7 Notes to
Implementors (non-normative)</h2>

<p>This section contains notes to implementors. Some of the information here is
already stated formally elsewhere in the document, and the reference here is
mainly a heads-up. Other items are really outside the scope of this
specification, but the notes here reflect what the authors think would be good
practice. </p>

<p>The sub-sections are not mutually exclusive. Hence, an implementer of a web
browser as a media fragment client should read the sections <a
href="#media-fragment-browser"><b>7.1 Browsers Rendering Media
Fragments</b></a>, <a href="#media-fragment-display"><b>7.2 Clients Displaying
Media Fragments</b></a> and <a href="#media-fragment-clients"><b>7.3 All Media
Fragment Clients</b></a>. </p>

<div class="div2">
<h3><a id="media-fragment-browser" name="media-fragment-browser"></a>7.1
Browsers Rendering Media Fragments</h3>

<p>The pixel coordinates defined in the section <a
href="#naming-space"><b>4.2.2 Spatial Dimension</b></a> are intended to be
identical to the <a
href="http://dev.w3.org/html5/spec/video.html#concept-video-intrinsic-width">intrinsic
width and height defined in HTML5</a>. </p>

<p>For spatial URI fragments, the next section describes two distinct use
cases, highlighting and cropping. HTML rendering clients, however, are expected
to implement cropping as the default rendering mechanism. </p>
</div>

<div class="div2">
<h3><a id="media-fragment-display" name="media-fragment-display"></a>7.2
Clients Displaying Media Fragments</h3>

<p>When dealing with media fragments, there is a question whether to display
the media fragment in context or without context. In general, it is recommended
to display a URI fragment in context since it is part of a larger resource. On
the other hand, a URI query results in a new resource, so it is recommended to
display it as a complete resource without context. The next paragraphs discuss
for each axis the context of a media fragment and provides suggestions
regarding the visualization of the URI fragment within its context. </p>

<p>For a temporal URI fragment, it is recommended to start playback at a time
offset that equals to the start of the fragment and pause at the end of the
fragment. When the "play" button is hit again, the resource will continue
loading and play back beyond the end of the fragment. When seeking to specific
offsets, the resource will load and play back from those seek points. It is
also recommended to introduce a "reload" button to replay just the URI
fragment. In this way, a URI fragment basically stands for "focusing
attention". Additionally, temporal URI fragments could be highlighted on the
transport bar. </p>

<p>For a spatial URI fragment, we foresee two distinct use cases: highlighting
the spatial region in-context and cropping to the region. In the first case,
the spatial region could be indicated by means of a bounding box or the
background (i.e., all the pixels that are not contained within the region)
could be blurred or darkened. In the second case, the region alone would be
presented as a cropped area. How a document author specifies which use case is
intended is outside the scope of this specification, we suggest implementors of
the specification provide a means for this, for example through attributes or
stylesheet elements. </p>

<p>Finally, for track URI fragments, it is recommended to play only the tracks
identified by the track URI fragment. If no tracks are specified, the default
tracks should be played. Different tracks could be selected using drop-down
boxes or buttons; the selected tracks are then highlighted during playback. The
way the UA retrieves information regarding the available tracks of a particular
resource is out of scope for this specification. </p>
</div>

<div class="div2">
<h3><a id="media-fragment-clients" name="media-fragment-clients"></a>7.3 All
Media Fragment Clients</h3>

<p><em>Resolution Order:</em> Where multiple dimensions are combined in one URI
fragment request, implementations are expected to first do track and temporal
selection on the container level, and then do spatial clipping on the codec
level. Named selection is done for whatever the name stands for: a track, a
temporal section, or a spatial region. </p>

<p><em>Media Fragment Grammar:</em> Note that the grammar for Media Fragment
URI only specifies the grammar for features standardised by this specification.
If a string does not parse correctly it does not necessarily mean the URI is
wrong, it only means it is not a Media Fragment according to this
specification. It may be correct for some extended form, or for a completely
different fragment specification method. For this reason, error recovery on
syntax errors in media fragment specifiers is unwise. </p>

<p><em>External Clipping:</em> There is no obligatory resolution method for a
situation where a media fragment URI is being used in the context of another
clipping method. Formally, it is up to the context embedding the media fragment
URI to decide whether the outside clipping method overrides the media fragment
URI or cascades, i.e. is defined on the resulting resource. In the absence of
strong reasons to do otherwise we suggest cascading. An example is a SMIL
element as follows: <code>&lt;smil:video clipBegin="5" clipEnd="15"
src="http://www.example.com/example.mp4#t=100,200"/&gt;</code>. This should
start playback of the original media resource at second 105, and stop at 115.
</p>

<p><em>Content-Range-Mapping:</em> The Content-Range-Mapping header returned
sometimes refers to a completely different range than the one that was
specified as the <em>Range:</em> in the request. This can happen if a
byte-based range is requested from a cache server that is not Media Fragment
aware, and that server had previously cached the data as a result of a time
range request. Technically, the information in the Content-Range-Mapping header
is still correct, but it is completely unrelated to the request issued. </p>
</div>

<div class="div2">
<h3><a id="media-fragment-servers" name="media-fragment-servers"></a>7.4 Media
Fragment Servers</h3>

<p><em>Media type:</em> The media type of a resource retrieved through a URI
fragment request is the same as that of the primary resource. Thus, retrieval
of e.g. a single frame from a video will result in a one-frame-long video. Or,
retrieval of all the audio tracks from a video resource will result in a video
and not a audio resource. When using a URI query approach, media type changes
are possible. E.g. a spatial fragment from a video at a certain time offset
could be retrieved as a jpeg using a specific HTTP "Accept" header in the
request. </p>

<p><em>Synchronisation:</em> Synchronisation between different tracks of a
media resource needs to be maintained when retrieving media fragments of that
resource. This is true for both, URI fragment and URI query retrieval. With URI
queries, when transcoding is required, a non-perceivable change in the
synchronisation is acceptable. </p>

<p><em>Embedded Timecodes:</em> When a media resource contains embedded time
codes, these need to be maintained for media fragment retrieval, in particular
when the URI fragment method is used. When URI queries are used and transcoding
takes place, the embedded time codes should remain when they are useful and
required. </p>

<p><em>SMPTE Timecodes:</em> Standardisation of SMPTE timecodes in this
document is primarily intended to allow frame-accurate references to sections
of video files, they can be seen as a form of content-based addressing. </p>

<p><em>Reasonable Clipping:</em> Temporal clipping needs to be as close as
reasonably possible to what the media fragment specified, and not omit any
requested data. "Reasonably close" means the nearest compression entity to the
requested fragment that completely contains the requested fragment. This means,
e.g. for temporal fragments if a request is made for
<code>http://www.example.org/video.ogv#t=60,100</code>, but the closest
decodable range is <code>t=58,102</code> because this is where a packet
boundary lies for audio and video, then it will be this range that is returned.
The UA is then capable of displaying only the requested subpart, and should
also just do that. For some container formats this is a non-issue, because the
container format allows specification of logical begin and end. </p>

<p><em>Reasonable byte ranges:</em> If a single temporal range request would
result in a disproportionally large number of byte ranges it may be better if
the server returns a redirect to the query form of the media fragment. This
situation could happen, for example, if the underlying media file is organized
in a strange way. </p>
</div>

<div class="div2">
<h3><a id="media-fragment-webapps" name="media-fragment-webapps"></a>7.5 Media
Fragment Web Applications</h3>

<p>Media Fragment URIs are only defined on media resources. However, many Web
developers that create Web pages with video or audio want to provide their
users the ability to jump directly to media fragments - in particular to time
offsets in a video - through providing a URI scheme for the Web page. </p>

<p>The way in which to realize this without requiring an extra server
interaction is by using a URI fragment scheme on the Web page which is parsed
by JavaScript and communicates the media fragment to the audio or video
resource loader. In HTML5 it would need to change the @src attribute of the
appropriate &lt;audio&gt; or &lt;video&gt; element with the appropriate URI
fragment and then call the load() function to make the element (re)load the
resource with that URI. </p>

<p>A URI scheme for such a Web page may involve ampersand-separated name-value
pairs as defined in this specification, e.g.
http://example.com/videopage.html#t=60,100 . </p>

<p>However, the Web developer has to create a scheme that works with the
remainder of the Web page fragment addressing functionality. If, for example,
the Web page makes use of the ID attributes of the elements on the page for
scrolling down on the page, adding media fragment URI addressing to the Web
page addressing will fail. For example, if
http://example.com/videopage.html#first works and scrolls to an offset on that
Web page, http://example.com/videopage.html#first&amp;t=60,100 will not do the
same scrolling. The Web developer will then need to parse the fragment
parameter and implement the scrolling functionality in JavaScript manually
using the scrollTo() or scrollTop() functions. </p>
</div>
</div>

<div class="div1">
<h2><a id="conclusions" name="conclusions"></a>8 Conclusions</h2>

<div class="div2">
<h3><a id="qualification-resources" name="qualification-resources"></a>8.1
Qualification of Media Resources</h3>

<p>HTTP byte ranges can only be used to request media fragments if these media
fragments can be expressed in terms of byte ranges. This restriction implies
that media resources should fulfil the following conditions: </p>
<ul>
  <li><p>The media fragments can be extracted in the compressed domain;</p>
  </li>
  <li><p>No syntax element modifications in the bitstream are needed to perform
    the extraction.</p>
  </li>
</ul>

<p>Not all media formats will be compliant with these two conditions. Hence, we
distinguish the following categories: </p>
<ol class="enumar">
  <li><p>The media resource meets the two conditions (i.e., fragments can be
    extracted in the compressed domain and no syntax element modifications are
    necessary). In this case, caching media fragments of such media resources
    is possible using HTTP byte ranges, because their media fragments are
    addressable in terms of byte ranges. </p>
  </li>
  <li><p>Media fragments can be extracted in the compressed domain, but syntax
    element modifications are required. These media fragments are cacheable
    using HTTP byte ranges on condition that the syntax element modifications
    are needed in media-headers applying to the whole media resource/fragment.
    In this case, those media-headers could be sent to the client in the first
    response of the server, which is a response to a request on a specific
    resource different from the byte-range content. </p>
  </li>
  <li><p>Media fragments cannot be extracted in the compressed domain. In this
    case, transcoding operations are necessary to extract media fragments.
    Since these media fragments are not expressible in terms of byte ranges, it
    is not possible to cache these media fragments using HTTP byte ranges. Note
    that media formats which enable extracting fragments in the compressed
    domain, but are not compliant with category 2 (i.e., syntax element
    modifications are not only applicable to the whole media resource), also
    belong to this category. </p>
  </li>
</ol>
</div>
</div>
</div>

<div class="back">

<div class="div1">
<h2><a id="references-normative" name="references-normative"></a>A
References</h2>
<dl>
  <dt class="label"><a name="rfc2119"></a>[RFC 2119] </dt>
    <dd>S. Bradner. <a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key
      Words for use in RFCs to Indicate Requirement Levels</cite></a>. IETF RFC
      2119, March 1997. Available at <a
      href="http://www.ietf.org/rfc/rfc2119.txt">http://www.ietf.org/rfc/rfc2119.txt</a>.
    </dd>
  <dt class="label"><a name="rtsp"></a>[RFC 2326] </dt>
    <dd><cite>Real Time Streaming Protocol (RTSP)</cite>. IETF RFC 2326, April
      1998. Available at <a
      href="http://www.ietf.org/rfc/rfc2326.txt">http://www.ietf.org/rfc/rfc2326.txt</a>.
    </dd>
  <dt class="label"><a name="sdp"></a>[RFC 2327] </dt>
    <dd><cite>Session Description Protocol (SDP)</cite>. IETF RFC 2327, April
      1998. Available at <a
      href="http://www.ietf.org/rfc/rfc2327.txt">http://www.ietf.org/rfc/rfc2327.txt</a>.
    </dd>
  <dt class="label"><a name="rfc2616"></a>[RFC 2616] </dt>
    <dd><cite>Hypertext Transfer Protocol -- HTTP/1.1</cite>. IETF RFC 2616,
      June 1999. Available at <a
      href="http://www.ietf.org/rfc/rfc2616.txt">http://www.ietf.org/rfc/rfc2616.txt</a>.
    </dd>
  <dt class="label"><a name="rfc3339"></a>[RFC 3339] </dt>
    <dd>G. Klyne and C. Newman. <cite>Date and Time on the Internet:
      Timestamps</cite>. IETF RFC 3339, July 2002. Available at <a
      href="http://www.ietf.org/rfc/rfc3339.txt">http://www.ietf.org/rfc/rfc3339.txt</a>.
    </dd>
  <dt class="label"><a name="ogg"></a>[RFC 3533] </dt>
    <dd><cite>The Ogg Encapsulation Format Version 0</cite>. IETF RFC 3533, May
      2003. Available at <a
      href="http://www.ietf.org/rfc/rfc3533.txt">http://www.ietf.org/rfc/rfc3533.txt</a>.
    </dd>
  <dt class="label"><a name="rfc3986"></a>[RFC 3986] </dt>
    <dd>T. Berners-Lee and R. Fielding and L. Masinter. <a
      href="http://www.ietf.org/rfc/rfc3986.txt"><cite>Uniform Resource
      Identifier (URI): Generic Syntax</cite></a>. IETF RFC 3986, January 2005.
      Available at <a
      href="http://www.ietf.org/rfc/rfc3986.txt">http://www.ietf.org/rfc/rfc3986.txt</a>.
    </dd>
  <dt class="label"><a name="rfc5234"></a>[RFC 5234] </dt>
    <dd>D. Crocker, Ed. <a
      href="http://tools.ietf.org/html/rfc5234"><cite>Augmented BNF for Syntax
      Specifications: ABNF</cite></a>. IETF RFC 5234, January 2008. Available
      at <a
      href="http://tools.ietf.org/html/rfc5234">http://tools.ietf.org/html/rfc5234</a>.
    </dd>
  <dt class="label"><a name="rfc4288"></a>[RFC 4288] </dt>
    <dd>N. Freed and J. Klensin <a
      href="http://www.ietf.org/rfc/rfc4288.txt"><cite>Media Type
      Specifications and Registration Procedures</cite></a>. IETF RFC 4288,
      December 2005. Available at <a
      href="http://www.ietf.org/rfc/rfc4288.txt">http://www.ietf.org/rfc/rfc4288.txt</a>.
    </dd>
  <dt class="label"><a name="rfc5147"></a>[RFC 5147] </dt>
    <dd>E. Wilde and M. Duerst.<a
      href="http://tools.ietf.org/html/rfc5147"><cite>URI Fragment Identifiers
      for the text/plain Media Type</cite></a>. IETF RFC 5147, April 2008.
      Available at <a
      href="http://tools.ietf.org/html/rfc5147">http://tools.ietf.org/html/rfc5147</a>.
    </dd>
  <dt class="label"><a name="html40"></a>[HTML 4.0] </dt>
    <dd>D. Ragett and A. Le Hors and I. Jacobs.<a
      href="http://www.w3.org/TR/REC-html40/intro/intro.html#fragment-uri"><cite>HTML
      Fragment identifiers</cite></a>. W3C Rec, December 1999. Available at <a
      href="http://www.w3.org/TR/REC-html40/intro/intro.html#fragment-uri">http://www.w3.org/TR/REC-html40/intro/intro.html#fragment-uri</a>.
    </dd>
  <dt class="label"><a name="html5"></a>[HTML 5] </dt>
    <dd>Ian Hickson, Google (ed).<a
      href="http://www.w3.org/TR/2009/WD-html5-20090825/"><cite>HTML5</cite></a>.
      W3C Working Draft, 25th August 2009. Available at <a
      href="http://www.w3.org/TR/2009/WD-html5-20090825/">http://www.w3.org/TR/2009/WD-html5-20090825/</a>.
    </dd>
  <dt class="label"><a name="svg"></a>[SVG] </dt>
    <dd>J. Ferraiolo.<a
      href="http://www.w3.org/TR/2001/REC-SVG-20010904/linking#FragmentIdentifiersSVG"><cite>SVG
      Fragment identifiers</cite></a>. W3C Rec, September 2001. Available at <a
      href="http://www.w3.org/TR/2001/REC-SVG-20010904/linking#FragmentIdentifiersSVG">http://www.w3.org/TR/2001/REC-SVG-20010904/linking#FragmentIdentifiersSVG</a>.
    </dd>
  <dt class="label"><a name="smil30"></a>[SMIL] </dt>
    <dd>Sjoerd Mullender, CWI (ed).<a
      href="http://www.w3.org/TR/2008/REC-SMIL3-20081201/"><cite>Synchronized
      Multimedia Integration Language (SMIL 3.0)</cite></a>. W3C Recommendation
      01 December 2008. Available at <a
      href="http://www.w3.org/TR/2008/REC-SMIL3-20081201/">http://www.w3.org/TR/2008/REC-SMIL3-20081201/</a>.
    </dd>
  <dt class="label"><a name="xpointer"></a>[xpointer] </dt>
    <dd>P. Grosso and E. Maler and J. Marsh and N. Walsh.<a
      href="http://www.w3.org/TR/xptr-framework/"><cite>XPointer
      Framework</cite></a>. W3C Rec, March 2003. Available at <a
      href="http://www.w3.org/TR/xptr-framework/">http://www.w3.org/TR/xptr-framework/</a>.
    </dd>
  <dt class="label"><a name="mpeg-7"></a>[MPEG-7] </dt>
    <dd><cite>Information Technology - Multimedia Content Description Interface
      (MPEG-7)</cite>. Standard No. ISO/IEC 15938:2001, International
      Organization for Standardization(ISO), 2001. </dd>
  <dt class="label"><a name="temporalURI"></a>[temporal URI] </dt>
    <dd>S. Pfeiffer and C. Parker and A. Pang.<a
      href="http://annodex.net/TR/draft-pfeiffer-temporal-fragments-03.html"><cite>Specifying
      time intervals in URI queries and fragments of time-based Web
      resources</cite></a>. Internet Draft, March 2005. Available at <a
      href="http://annodex.net/TR/draft-pfeiffer-temporal-fragments-03.html">http://annodex.net/TR/draft-pfeiffer-temporal-fragments-03.html</a>.
    </dd>
  <dt class="label"><a name="cmml"></a>[CMML] </dt>
    <dd><cite>Continuous Media Markup Language (CMML), Version 2.1</cite>. IETF
      Internet-Draft 4th March 2006 <a
      href="http://www.annodex.net/TR/draft-pfeiffer-cmml-03.txt">http://www.annodex.net/TR/draft-pfeiffer-cmml-03.txt</a>.
    </dd>
  <dt class="label"><a name="roe"></a>[ROE] </dt>
    <dd><cite>Rich Open multitrack media Exposition (ROE)</cite>. Xiph Wiki.
      Retrieved 13 April 2009 at <a
      href="http://wiki.xiph.org/index.php/ROE">http://wiki.xiph.org/index.php/ROE</a>.
    </dd>
  <dt class="label"><a name="skeleton"></a>[Skeleton] </dt>
    <dd><cite>Ogg Skeleton</cite>. Xiph Wiki. Retrieved 13 April 2009 at <a
      href="http://wiki.xiph.org/OggSkeleton">http://wiki.xiph.org/OggSkeleton</a>.
    </dd>
  <dt class="label"><a name="mpeg21"></a>[MPEG-21] </dt>
    <dd><cite>Information Technology - Multimedia Framework (MPEG-21)</cite>.
      Standard No. ISO/IEC 21000:2002, International Organization for
      Standardization(ISO), 2002. Available at <a
      href="http://www.chiariglione.org/mpeg/working_documents/mpeg-21/fid/fid-is.zip">http://www.chiariglione.org/mpeg/working_documents/mpeg-21/fid/fid-is.zip</a>.
    </dd>
  <dt class="label"><a name="smpte"></a>[SMPTE] </dt>
    <dd><cite>SMPTE RP 136 Time and Control Codes for 24, 25 or 30
      Frame-Per-Second Motion-Picture Systems</cite> </dd>
  <dt class="label"><a name="isoBaseMediaFF"></a>[ISO Base Media File Format]
  </dt>
    <dd><cite>Information technology - Coding of audio-visual objects - Part
      12: ISO base media file format</cite>. Retrieved 13 April 2009 at <a
      href="http://standards.iso.org/ittf/PubliclyAvailableStandards/c051533_ISO_IEC_14496-12_2008.zip">http://standards.iso.org/ittf/PubliclyAvailableStandards/c051533_ISO_IEC_14496-12_2008.zip</a>
    </dd>
  <dt class="label"><a name="mf-req"></a>[Use cases and requirements for Media
  Fragments] </dt>
    <dd><cite>Use cases and requirements for Media Fragments</cite>. W3C
      Working Draft 30 April 2009: <a
      href="http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/">http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-reqs/</a>
    </dd>
  <dt class="label"><a name="utf-8"></a>[UTF-8] </dt>
    <dd><cite>UTF-8, a transformation format of ISO 10646</cite>. <a
      href="http://tools.ietf.org/html/rfc3629">http://tools.ietf.org/html/rfc3629</a>
    </dd>
  <dt class="label"><a name="ecma-262"></a>[ECMA-262 5th edition] </dt>
    <dd><cite>ECMA-262 5th edition</cite>: <a
      href="http://www.ecma-international.org/publications/standards/Ecma-262.htm">http://www.ecma-international.org/publications/standards/Ecma-262.htm</a>
    </dd>
  <dt class="label"><a name="mediaAnnotations"></a>[Media Annotations] </dt>
    <dd><cite>API for Media Resource 1.0</cite>: <a
      href="http://www.w3.org/TR/mediaont-api-1.0/">http://www.w3.org/TR/mediaont-api-1.0/</a>
    </dd>
  <dt class="label"><a name="webLinking"></a>[Web Linking] </dt>
    <dd><cite>Web Linking</cite>: <a
      href="http://tools.ietf.org/html/draft-nottingham-http-link-header-10">http://tools.ietf.org/html/draft-nottingham-http-link-header-10</a>
    </dd>
</dl>
</div>

<div class="div1">
<h2><a id="collected-syntax-uri" name="collected-syntax-uri"></a>B Collected
ABNF Syntax for URI (Non-Normative)</h2>

<div class="exampleInner">
<pre>unichar       = &lt;any Unicode code point&gt;
unistring     = *unichar

; defined in <cite><a href="#rfc5234">RFC 5234</a></cite>
ALPHA         =  %x41-5A / %x61-7A   ; A-Z / a-z
DIGIT         =  %x30-39 ; 0-9
HEXDIG        =  DIGIT / "A" / "B" / "C" / "D" / "E" / "F"

; defined in <cite><a href="#rfc3986">RFC 3986</a></cite>
unreserved    = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded   = "%" HEXDIG HEXDIG
sub-delims    = "!" / "$" / "&amp;" / "'" / "(" / ")" / "*" / "+" / "," / ";" / "="
pchar         = unreserved / pct-encoded / sub-delims / ":" / "@"
fragment      = *( pchar / "/" / "?" )

; defined in <cite><a href="#rtsp">RFC 2326</a></cite>
npt-sec       = 1*DIGIT [ "." *DIGIT ]                     ; definitions taken
npt-hhmmss    = npt-hh ":" npt-mm ":" npt-ss [ "." *DIGIT] ; from <cite><a href="#rtsp">RFC 2326</a></cite>
npt-hh        =   1*DIGIT     ; any positive number
npt-mm        =   2DIGIT      ; 0-59
npt-ss        =   2DIGIT      ; 0-59

; defined in <cite><a href="#rfc3339">RFC 3339</a></cite>
date-fullyear   = 4DIGIT
date-month      = 2DIGIT  ; 01-12
date-mday       = 2DIGIT  ; 01-28, 01-29, 01-30, 01-31 based on
                          ; month/year
time-hour       = 2DIGIT  ; 00-23
time-minute     = 2DIGIT  ; 00-59
time-second     = 2DIGIT  ; 00-58, 00-59, 00-60 based on leap second
                          ; rules
time-secfrac    = "." 1*DIGIT
time-numoffset  = ("+" / "-") time-hour ":" time-minute
time-offset     = "Z" / time-numoffset

partial-time    = time-hour ":" time-minute ":" time-second
                  [time-secfrac]
full-date       = date-fullyear "-" date-month "-" date-mday
full-time       = partial-time time-offset

date-time       = full-date "T" full-time

; Mediafragment definitions
segment       = mediasegment / *( pchar / "/" / "?" )     ; augmented fragment
                                                          ; definition taken from
                                                          ; <cite><a href="#rfc3986">RFC 3986</a></cite>

;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Common Prefixes ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;

deftimeformat    = %x6E.70.74                                      ; "npt"
pfxdeftimeformat = %x74.3A.6E.70.74                                ; "t:npt"
smpteformat      = %x73.6D.70.74.65                                ; "smpte"
                  / %x73.6D.70.74.65.2D.32.35                      ; "smpte-25"
                  / %x73.6D.70.74.65.2D.33.30                      ; "smpte-30"
                  / %x73.6D.70.74.65.2D.33.30.2D.64.72.6F.70       ; "smpte-30-drop"
pfxsmpteformat   = %x74.3A.73.6D.70.74.65                          ; "t:smpte"
                  / %x74.3A.73.6D.70.74.65.2D.32.35                ; "t:smpte-25"
                  / %x74.3A.73.6D.70.74.65.2D.33.30                ; "t:smpte-30"
                  / %x74.3A.73.6D.70.74.65.2D.33.30.2D.64.72.6F.70 ; "t:smpte-30-drop"
clockformat      = %x63.6C.6F.63.6B                                ; "clock"
pfxclockformat   = %x74.3A.63.6C.6F.63.6B                          ; "clock"

;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Media Segment ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
mediasegment     = namesegment / axissegment
axissegment      = ( <a href="#timesegment">timesegment</a> / <a href="#spacesegment">spacesegment</a> / <a href="#tracksegment">tracksegment</a> )
               *( "&amp;" ( <a href="#timesegment">timesegment</a> / <a href="#spacesegment">spacesegment</a> / <a href="#tracksegment">tracksegment</a> )
;
; note that this does not capture the restriction of only one timesegment or spacesegment
; in the axisfragment definition, unless we list explicitely all the cases,
;
timesegment      = timeprefix "=" timeparam
timeprefix       = %x74                                      ; "t"
timeparam        = <a href="#npttimedef">npttimedef</a> / <a href="#smptetimedef">smptetimedef</a> / <a href="#clocktimedef">clocktimedef</a>
npttimedef       = [ deftimeformat ":"] ( npttime  [ "," npttime ] ) / ( "," npttime )

npttime       = npt-sec / npt-hhmmss

smptetimedef  = smpteformat ":"( frametime [ "," frametime ] ) / ( "," frametime )
frametime     = 1*DIGIT ":" 2DIGIT ":" 2DIGIT [ ":" 2DIGIT [ "." 2DIGIT ] ]

clocktimedef  = clockformat ":"( clocktime [ "," clocktime ] ) / ( "," clocktime )
clocktime     = (datetime / walltime / date)
datetime      = date-time                                 ; inclusion of <cite><a href="#rfc3339">RFC 3339</a></cite>

spacesegment  = xywhprefix   "=" xywhparam
xywhprefix    = %x78.79.77.68                             ; "xywh"
xywhparam     = [ xywhunit ":" ] 1*DIGIT "," 1*DIGIT "," 1*DIGIT "," 1*DIGIT
xywhunit      = %x70.69.78.65.6C                          ; "pixel"
              / %x70.65.72.63.65.6E.74                    ; "percent"

tracksegment  = trackprefix "=" trackparam
trackprefix   = %x74.72.61.63.6B                          ; "track"
trackparam    = unistring

namesegment   = nameprefix "=" nameparam
nameprefix    = %x69.64                                   ; "id"
nameparam     = unistring
      </pre>
</div>
</div>

<div class="div1">
<h2><a id="collected-syntax-http" name="collected-syntax-http"></a>C Collected
ABNF Syntax for HTTP Headers (Non-Normative)</h2>

<div class="exampleInner">
<pre>; defined in <cite><a href="#rfc2616">RFC 2616</a></cite>
CHAR                   = [any US-ASCII character (octets 0 - 127)]
token                  = 1*[any CHAR except CTLs or separators]`
first-byte-pos         = 1*DIGIT
last-byte-pos          = 1*DIGIT
bytes-unit             = "bytes"
range-unit             = bytes-unit | other-range-unit
byte-range-resp-spec   = (first-byte-pos "-" last-byte-pos)
Range                  = "Range" ":" ranges-specifier
Accept-Ranges          = "Accept-Ranges" ":" acceptable-ranges

;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; HTTP Request Headers ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;;
ranges-specifier       = byte-ranges-specifier | fragment-specifier
;
; note that ranges-specifier is extended from <cite><a href="#rfc2616">RFC 2616</a></cite>
; to cover alternate fragment range specifiers
;
fragment-specifier     = "include-setup" | fragment-range *( "," fragment-range )
                                                           [ ";" "include-setup" ]
fragment-range         = time-ranges-specifier | track-ranges-specifier | name-ranges-specifier
;
; note that this doesn't capture the restriction to one fragment dimension occurring
; maximally once only in the fragment-specifier definition.
;
time-ranges-specifier  = timeprefix ":" time-ranges-options
time-ranges-options    = npttimeoption / smptetimeoption / clocktimeoption
npttimeoption          = deftimeformat "=" npt-sec   "-" [ npt-sec ]
smptetimeoption        = smpteformat   "=" frametime "-" [ frametime ]
clocktimeoption        = clockformat   "=" datetime  "-" [ datetime ]

track-ranges-specifier = trackprefix "=" trackparam *( ";" trackparam )

name-ranges-specifier  = nameprefix  "=" nameparam

;;
Accept-Range-Redirect  = "Accept-Range-Redirect" ":" bytes-unit
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; HTTP Response Headers ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
Content-Range-Mapping      = "Content-Range-Mapping" ":" '{'
                             ( content-range-mapping-spec [ ";" def-include-setup ] ) / def-include-setup
                             '}' '=' '{'
                             byte-content-range-mapping-spec '}'

def-include-setup          = %x69.6E.63.6C.75.64.65.2D.73.65.74.75.70  ; "include-setup"

byte-range-mapping-spec    = bytes-unit SP
                             byte-range-resp-spec *( "," byte-range-resp-spec ) "/"
                             ( instance-length / "*" )

content-range-mapping-spec = time-mapping-spec | track-mapping-spec | name-mapping-spec
time-mapping-spec          = timeprefix ":" time-mapping-options
time-mapping-options       = npt-mapping-option / smpte-mapping-option / clock-mapping-option
npt-mapping-option         = deftimeformat SP npt-sec   "-" npt-sec   "/"
                                          [ npt-sec ]   "-" [ npt-sec ]
smpte-mapping-option       = smpteformat   SP frametime "-" frametime "/"
                                          [ frametime ] "-" [ frametime ]
clock-mapping-option       = clockformat   SP datetime  "-" datetime  "/"
                                          [ datetime ]  "-" [ datetime ]

track-mapping-spec         = trackprefix SP trackparam *( ";" trackparam )

name-mapping-spec          = nameprefix  SP nameparam

;;
acceptable-ranges          = 1#range-unit *( "," 1#range-unit )| "none"
;
; note this does not represent the restriction that range-units can only appear once at most;
; this has also been adapted from <cite><a href="#rfc2616">RFC 2616</a></cite>
; to allow multiple range units.
;
other-range-unit           = token | timeprefix | trackprefix | nameprefix

;;
Range-Redirect             = "Range-Redirect" ":" byte-range-resp-spec *( "," byte-range-resp-spec )
      </pre>
</div>
</div>

<div class="div1">
<h2><a id="rtsp-media-fragment-processing"
name="rtsp-media-fragment-processing"></a>D Processing media fragment URIs in
RTSP (Non-Normative)</h2>

<p>This appendix explains how the media fragment specification is mapped to an
RTSP protocol activity. We assume here that you have a general understanding of
the RTSP protocol mechanism as defined in <cite><a href="#rtsp">RFC
2326</a></cite>. The general sequence of messages sent between an RTSP UA and
server can be summarized as follows: </p>
<ul>
  <li>from a DESCRIBE activity, in which the UA requests from the server what
    resources it has available,</li>
  <li>through a SETUP activity, which sets up the communication between the UA
    and the server, including the requested tracks,</li>
  <li>to a PLAY activity, where time ranges are requested by the UA from the
    server for playback.</li>
  <li>A PAUSE is always possible in the middle of a RTSP communication, and</li>
  <li>a TEARDOWN closes the communication.</li>
</ul>

<p>Note that the RTSP protocol is intentionally similar in syntax and operation
to HTTP. </p>

<div class="div2">
<h3><a id="mapping-mf-to-rtsp-methods"
name="mapping-mf-to-rtsp-methods"></a>D.1 How to map Media Fragment URIs to
RTSP protocol methods</h3>

<div class="div3">
<h4><a id="rtsp-mf-dimensions" name="rtsp-mf-dimensions"></a>D.1.1 Dealing with
the media fragment URI dimensions in RTSP</h4>

<p>We illustrated for each of the four media fragment dimensions how they can
be mapped onto RTSP commands. The following examples are used to illustrated
each of the dimensions: (1) temporal: #t=10,20 (2) tracks:
#track=audio&amp;track=video (3) spatial: #xywh=160,120,320,24 (4) id:
#id=Airline%20Edit </p>

<div class="div4">
<h5><a id="rtsp-temporal" name="rtsp-temporal"></a>D.1.1.1 Temporal Media
Fragment URIs</h5>

<p>In RTSP, temporal fragment URIs are provided through the PLAY method. A URI
such as</p>

<div class="exampleInner">
<pre>rtsp://example.com/media#t=10,20</pre>
</div>

<p>will be executed as a series of the following methods (all shortened for
readability - full examples can be found in ). </p>
<ul>
  <li>UA-&gt;S: DESCRIBE rtsp://example.com/media</li>
  <li>S-&gt;UA: RTSP/1.0 200 OK (with an SDP description)</li>
  <li>UA-&gt;S: SETUP rtsp://example.com/media/video</li>
  <li>S-&gt;UA: RTSP/1.0 200 OK</li>
  <li>UA-&gt;S: SETUP rtsp://example.com/media/audio</li>
  <li>S-&gt;UA: RTSP/1.0 200 OK</li>
</ul>

<p>The actual temporal selection is provided in the PLAY method: </p>

<div class="exampleInner">
<pre>C-&gt;S: PLAY rtsp://example.com/media
Range: npt=10-20</pre>
</div>

<p>The server tells the UA which temporal range is returned: </p>

<div class="exampleInner">
<pre>S-&gt;C: RTSP/1.0 200 OK
Range: npt=9.5-20.1</pre>
</div>

<p>We can explain this mapping for all of the media fragment defined time
schemes. Also, several temporal media fragment URI requests can be sent as
pipelined commands without having to re-send the DESCRIBE and SETUP commands.
</p>
</div>

<div class="div4">
<h5><a id="rtsp-track" name="rtsp-track"></a>D.1.1.2 Track Media Fragment
URIs</h5>

<p>In RTSP, track fragment URIs are provided through the SETUP method. A URI
such as</p>

<div class="exampleInner">
<pre>rtsp://example.com/media#track=audio&amp;track=video</pre>
</div>

<p>will be executed as a series of the following methods (all shortened for
readability). </p>
<ul>
  <li>UA-&gt;S: DESCRIBE rtsp://example.com/media</li>
  <li>S-&gt;UA: RTSP/1.0 200 OK (with an SDP description)</li>
  <li>UA-&gt;S: SETUP rtsp://example.com/media/video</li>
  <li>S-&gt;UA: RTSP/1.0 200 OK</li>
  <li>UA-&gt;S: SETUP rtsp://example.com/media/audio</li>
  <li>S-&gt;UA: RTSP/1.0 200 OK</li>
</ul>

<p>The discovery of available tracks is provided through the SDP reply to
DESCRIBE, but it could be done through alternative methods, too. Several
consecutive track media fragment URI requests can only be sent with new SETUP
commands and cannot be pipelined. </p>
</div>

<div class="div4">
<h5><a id="rtsp-spatial" name="rtsp-spatial"></a>D.1.1.3 Spatial Media Fragment
URIs</h5>

<p>In RTSP, spatial fragment URIs are not specifically provided for. Just like
in HTTP, spatial fragments are interpreted at the UA and thus not communicated
to the server. A URI such as</p>

<div class="exampleInner">
<pre>rtsp://example.com/media#xywh=160,120,320,24</pre>
</div>

<p>will be executed as the url rtsp://example.com/media. </p>
</div>

<div class="div4">
<h5><a id="rtsp-named" name="rtsp-named"></a>D.1.1.4 Named Media Fragment
URIs</h5>

<p>We see no easy way to support this in RTSP as currently standardised.</p>
</div>
</div>

<div class="div3">
<h4><a id="rtsp-combined-mf-dimensions"
name="rtsp-combined-mf-dimensions"></a>D.1.2 Putting the media fragment URI
dimensions together in RTSP</h4>

<p>A URI such as</p>

<div class="exampleInner">
<pre>rtsp://example.com/media#xywh=160,120,320,24&amp;t=10,20&amp;track=audio&amp;track=video</pre>
</div>

<p>will be executed as a series of the following methods (all shortened for
readability). The data selection is provided both in the SETUP method and the
PLAY method:</p>

<div class="exampleInner">
<pre>UA-&gt;S: DESCRIBE rtsp://example.com/media
S-&gt;UA: RTSP/1.0 200 OK (with an SDP description, see wiki)
UA-&gt;S: SETUP rtsp://example.com/media/video
S-&gt;UA: RTSP/1.0 200 OK
UA-&gt;S: SETUP rtsp://example.com/media/audio
S-&gt;UA: RTSP/1.0 200 OK
UA-&gt;S: PLAY rtsp://example.com/media
       Range: npt=10-20
S-&gt;UA: RTSP/1.0 200 OK
       Range: npt=9.5-20.1</pre>
</div>

<p>It is the UA's task to only display the rectangle xywh=160,120,320,2. It is
true that the resolution of the dimensions is done at different levels of the
protocol, but that does not create a problem.</p>
</div>

<div class="div3">
<h4><a id="rtsp-caching" name="rtsp-caching"></a>D.1.3 Caching and RTSP for
media fragment URIs</h4>

<p>Media fragment URIs rely only on existing protocol negotiations in RTSP.
Therefore any RTSP caching scheme, assuming such a thing exists, will work fine
with media fragments.</p>
</div>
</div>
</div>

<div class="div1">
<h2><a id="acknowledgments" name="acknowledgments"></a>E Acknowledgements
(Non-Normative)</h2>

<p>This document is the work of the <a
href="http://www.w3.org/2008/WebVideo/Fragments/">W3C Media Fragments Working
Group</a>. Members of the Working Group are (at the time of writing, and in
alphabetical order): Eric Carlson (Apple, Inc.), Michael Hausenblas (DERI
Galway at the National University of Ireland, Galway, Ireland), Philip
Jägenstedt (Opera Software), Jack Jansen (CWI), Yves Lafon (W3C), Wonsuk Lee
(Electronics and Telecommunications Research Institute), Erik Mannens (IBBT),
Thierry Michel (W3C/ERCIM), Guillaume (Jean-Louis) Olivrin (Meraka Institute),
Soohong Daniel Park (Samsung Electronics Co., Ltd.), Conrad Parker (W3C Invited
Experts), Silvia Pfeiffer (W3C Invited Experts), David Singer (Apple, Inc.),
Raphaël Troncy (EURECOM), Davy Van Deursen (IBBT), </p>

<p>The people who have contributed to <a
href="http://lists.w3.org/Archives/Public/public-media-fragment/">discussions
on public-media-fragment@w3.org </a> are also gratefully acknowledged. In
particular: Olivier Aubert, Werner Bailer, Pierre-Antoine Champin, Cyril
Concolato, Franck Denoual, Martin J. Dürst, Jean Pierre Evain, Ken
Harrenstien, Kilroy Hughes, Ryo Kawaguchi, Wim Van Lancker, Véronique
Malaisé, Henrik Nordstrom, Yannick Prié, Yves Raimond, Julian Reschke,
Geoffrey Sneddon, Felix Sasaki, Jakub Sendor, Philip Taylor, Christian
Timmerer, Jorrit Vermeiren, Jeroen Wijering and Munjo Yu. </p>
</div>

<div class="div1">
<h2><a id="change-log" name="change-log"></a>F Change Log (Non-Normative)</h2>

<p>@@This paragraph will be replaced by the change log. DO NOT TOUCH@@</p>
</div>
</div>
</body>
</html>