index.html 89.8 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; }


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}</style>
  <link rel="stylesheet" type="text/css"
  href="http://www.w3.org/StyleSheets/TR/W3C-WD.css" />
</head>

<body>

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

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

<h2><a name="w3c-doctype" id="w3c-doctype"></a>W3C Working Draft 17 December
2009</h2>
<dl>
  <dt>This version:</dt>
    <dd><a
      href="http://www.w3.org/TR/2009/WD-media-frags-20091217">http://www.w3.org/TR/2009/WD-media-frags-20091217</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>Editors:</dt>
    <dd><a href="http://www.eurecom.fr/~troncy/">Raphaël Troncy </a>, Center
      for Mathematics and Computer Science (CWI Amsterdam)</dd>
    <dd><a href="mailto:erik.mannens@ugent.be">Erik Mannens </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="http://www.cwi.nl/~jack/">Jack Jansen </a>, Center for
      Mathematics and Computer Science (CWI Amsterdam)</dd>
    <dd><a href="http://www.w3.org/People/Lafon/">Yves Lafon </a>, W3C</dd>
    <dd><a href="http://blog.gingertech.net/">Silvia Pfeiffer </a>, W3C Invited
      Expert</dd>
    <dd><a href="mailto:davy.vandeursen@ugent.be">Davy van Deursen </a>, IBBT
      Multimedia Lab, University of Ghent</dd>
</dl>

<p class="copyright"><a
href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2009 <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 name="abstract" id="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 field-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 name="status" id="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 <a
href="http://www.w3.org/2005/10/Process-20051014/tr.html#first-wd">First Public
Working Draft</a> 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>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 rel="disclosure"
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 name="contents" id="contents"></a>Table of Contents</h2>

<p class="toc">1 <a href="#introduction">Introduction</a><br />
2 <a href="#terminology">Terminology</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="#fragment-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.3 <a href="#naming-syntax">ABNF Syntax</a><br />
5 <a href="#processing">Interpreting and Processing Media Fragments</a><br />
    5.1 <a href="#processing-overview">Overview</a><br />
        5.1.1 <a href="#processing-overview-standardisation">Media
Fragments Standardisation</a><br />
        5.1.2 <a href="#processing-overview-interpretation">General
Interpretation</a><br />
        5.1.3 <a href="#processing-overview-errors">Error
Handling</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.3 <a href="#processing-protocol-proxy">Proxy cacheable
Server mapped byte ranges</a><br />
    5.3 <a href="#processing-protocol-query">Protocol for URI query
Resolution in HTTP</a><br />
6 <a href="#Conclusions">Conclusions</a><br />
    6.1 <a href="#qualification-resources">Qualification of Media
Resources</a><br />
</p>

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

<p class="toc">A <a href="#references-normative">References</a><br />
B <a href="#acknowledgments">Acknowledgements</a> (Non-Normative)<br />
C <a href="#change-log">Change Log</a> (Non-Normative)<br />
</p>
</div>
<hr />

<div class="body">

<div class="div1">
<h2><a name="introduction" id="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 <a href="#mf-req">[Use
cases and requirements for Media Fragments]</a> 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 and RTP/RTSP protocols.
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 name="terminology" id="terminology"></a>2 Terminology</h2>

<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 <a href="#rfc2119">[RFC 2119]</a>. </p>

<p>According to <a href="#rfc3986">[RFC 3986]</a>, URIs that contain a fragment
are actually not URIs, but URI references relative to the namespace of another
URI. In this document, when the term 'media fragment URIs' is used, it actually
means 'media fragment URI references'. </p>
</div>

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

<p>To address a media fragment, one needs to find ways to convey the fragment
information. This specification builds on URIs <a href="#rfc3986">[RFC
3986]</a>. 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 name="URIquery-vs-fragments" id="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 <a href="#mf-req">[Use cases and requirements
for Media Fragments]</a> 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>

<table border="1" summary="Editorial note: Raphael">
  <tbody>
    <tr>
      <td align="left" valign="top" width="50%"><b>Editorial note:
      Raphael</b></td>
      <td align="right" valign="top" width="50%"> </td>
    </tr>
    <tr>
      <td colspan="2" align="left" valign="top">I wonder if we should not paste
        here the table in the Annexe B of the requirement document with the
        various container formats and their "fit" value for the media fragment
        dimensions considered</td>
    </tr>
  </tbody>
</table>

<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 name="URIfragment-user-agent" id="URIfragment-user-agent"></a>3.2
Resolving URI fragments within the user agent</h3>

<p>The most optimal means of using media fragments in an application is through
the use of URI fragments which the application resolves from the resource it
already holds. This is desirable since it does not require further downloads
and the user agent has the full context of the primary resource at hand. </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. Since media resources are typically very large, user
agents do not typically retrieve the complete media resource in one go, but
rather request byte ranges as required. This is a more economical use of
retrieval bandwidth. 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. </p>

<p>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>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 name="URIfragment-server" id="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 name="URIfragment-proxies" id="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 align="left" valign="top" width="50%"><b>Editorial note:
      Raphael</b></td>
      <td align="right" valign="top" width="50%"> </td>
    </tr>
    <tr>
      <td colspan="2" align="left" valign="top">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 name="URIquery-media-fragments" id="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>

<table border="1" summary="Editorial note: Raphael">
  <tbody>
    <tr>
      <td align="left" valign="top" width="50%"><b>Editorial note:
      Raphael</b></td>
      <td align="right" valign="top" width="50%"> </td>
    </tr>
    <tr>
      <td colspan="2" align="left" valign="top">Weak argument? I would rather
        argue that if we cannot maintain byte-identity, then the fragment part
        of a URI is simply not suitable per TAG finding that we would need to
        request. The argument that the server has to do some complex processing
        seems to me weaker. </td>
    </tr>
  </tbody>
</table>

<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 name="URIquery-URIfragment" id="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 <a
href="#rfc3986">[RFC 3986]</a>. </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 align="left" valign="top" width="50%"><b>Editorial note:
      Silvia</b></td>
      <td align="right" valign="top" width="50%"> </td>
    </tr>
    <tr>
      <td colspan="2" align="left" valign="top">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 name="media-fragment-syntax" id="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. The first two subsections are a
semi-informal introduction, with the formal grammar being specified in the last
subsection. </p>

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

<p>The fragment identifier consists of a list of name/value pairs, the
dimension specifiers, separated by the primary separator <code>&amp;</code>.
Name and value are separated by an equal sign (<code>=</code>). In case value
is structured, colon (<code>:</code>) and comma (<code>,</code>) are used as
secondary separators. No whitespace is allowed (except inside strings).</p>

<p>Some examples of URIs with a media fragment, to show the general
structure:</p>

<div class="exampleInner">
<pre>http://www.example.com/example.ogv#t=10s,20s
http://www.example.com/example.ogv#track='audio'
http://www.example.com/example.ogv#track='audio'&amp;t=10s,20s</pre>
</div>

<p>Media fragments support fragmenting 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 track (media type) in the original media,
      such as "the english audio 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>Note that the track dimension refers to one of a set of parallel media
streams ("the english audio track for a video"), not to a, possibly
self-contained, section of the source media ("Audio track 2 of a CD"). The
self-contained section is handled by the name dimension. </p>

<p>The name dimension cannot be combined with other dimensions for this version
of the media fragments specification. Projection along the other three
dimensions is logically commutative, therefore they can be combined, and the
outcome is independent of the order of the dimensions. Each dimension can be
specified at most once. 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="#processing-overview-errors"><b>5.1.3 Error Handling</b></a>. </p>
</div>

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

<div class="div3">
<h4><a name="naming-time" id="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>

<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) <a
href="#rtsp">[RFC 2326]</a>, as SMPTE timecodes, <a href="#smpte">[SMPTE]</a>,
or as real-world clock time (clock) <a href="#rtsp">[RFC 2326]</a>. 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>

<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 name="npt-time" id="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 and an optional <code>s</code> to indicate seconds, 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. </p>

<div class="exampleInner">
<pre>t=npt:10s,20        # =&gt; results in the time interval [10,20)
t=npt:120s,         # =&gt; results in the time interval [120,end)
t=npt:,121.5s       # =&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>

<table border="1" summary="Editorial note: Jack">
  <tbody>
    <tr>
      <td align="left" valign="top" width="50%"><b>Editorial note: Jack</b></td>
      <td align="right" valign="top" width="50%"> </td>
    </tr>
    <tr>
      <td colspan="2" align="left" valign="top"><p>Do we need a rationale, to
        explain that we picked this syntax for timecodes up from rtsp and
        smil?</p>
      </td>
    </tr>
  </tbody>
</table>
</div>

<div class="div4">
<h5><a name="smpte-time" id="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">
<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.1 # =&gt; results in the time interval [120,121.5)</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 name="clock-time" id="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 with a typically live video stream. These are the same time codes
that are being used by RTSP <a href="#rtsp">[RFC 2326]</a>, by SMIL <a
href="#smil30">[SMIL]</a>, and by HTML5 <a href="#html5">[HTML 5]</a>. 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" in the SMIL 3.0
way, which includes time zone capabilities. The time scheme identifier is
"clock". </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 name="naming-space" id="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>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">
<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 name="naming-track" id="naming-track"></a>4.2.3 Track Dimension</h4>

<p>Track selection allows the extraction of a single track (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
enclosed in single quotes. Percent-escaping can be used in the string to
specify unsafe characters, see the grammar below for details. 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">
<pre>track='1'                      # =&gt; results in only extracting track 1
track='video'                  # =&gt; results in only extracting track 'video'
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. </p>

<table border="1" summary="Editorial note: Jack">
  <tbody>
    <tr>
      <td align="left" valign="top" width="50%"><b>Editorial note: Jack</b></td>
      <td align="right" valign="top" width="50%"> </td>
    </tr>
    <tr>
      <td colspan="2" align="left" valign="top"><p>The issue of generic track
        names is still under discussion, <a
        href="http://www.w3.org/2008/WebVideo/Fragments/tracker/issues/4">ISSUE-4</a>
        in the tracker has the details. </p>
      </td>
    </tr>
  </tbody>
</table>
</div>

<div class="div3">
<h4><a name="naming-name" id="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 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">
<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>

<div class="div2">
<h3><a name="naming-syntax" id="naming-syntax"></a>4.3 ABNF Syntax</h3>

<p>The composition of a URI fragment or query string for a media resource
relies on a series of field-value pairs to be added behind the URI fragment
('#') or query ('?') identifier. The field-value pairs are each separated by an
equal sign. The series of pairs is separated by an ampersand, '&amp;' or
semicolon, ';'.</p>

<p>A general URI fragment or query string specified on a media resource may
contain several field-value pairs. They are not restricted to the ones
specified here, since applications may want to use additional other parameters
to communicate further requests to custom servers. A conformant server or user
agent will need to be able to parse a random URI query or fragment string for a
media resource and identify the relevant parts. E.g. the relevant field-value
pair out of a media fragment URI like this
<code>http://www.example.com/video.ogv#&amp;&amp;=&amp;=tom;jerry=&amp;t=34&amp;t=meow:0#</code>
is <code>t=34</code>.</p>

<p>In this section we present the ABNF (<a href="#abnf">[ABNF]</a>) syntax for
the field-value pairs that relate to a media fragment URI. The names for the
non-terminals more-or-less follow the names used in the previous subsections,
with one clear difference: the start symbol is called
<code>mediasegment</code>, because we want to allow application of it to both
URI fragment and URI query strings.</p>

<div class="exampleInner">
<pre>segment       = mediasegment / *( pchar / "/" / "?" ) ; augmented fragment
                                                     ; definition taken from
                                                     ; rfc3986
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Media Segment ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
mediasegment  = namesegment / axissegment
axissegment   = ( timesegment / spacesegment / tracksegment )
               *( "&amp;" ( timesegment / spacesegment / tracksegment )
;
; note that this does not capture the restriction to one kind of fragment
; in the axisfragment definition, unless we list explicitely the 14 cases.
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Time Segment ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
timesegment   = timeprefix "=" timeparam
timeprefix    = %x74                                      ; "t"
timeparam     = npttimedef / smptetimedef / clocktimedef
npttimedef    = [ deftimeformat ":"] ( npttime  [ "," npttime ] ) / ( "," npttime )
smptetimedef  = smpteformat ":"( frametime [ "," frametime ] ) / ( "," frametime )
clocktimedef  = clockformat ":"( clocktimetime [ "," clocktime ] ) / ( "," clocktime )
deftimeformat = %x6E.70.74                                ; "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"
clockformat   = %x63.6C.6F.63.6B                          ; "clock"
timeunit      = %x73                                      ; "s"
npttime       = ( 1*DIGIT [ "." 1*DIGIT ] [timeunit] ) /
               ( 1*DIGIT ":" 2DIGIT ":" 2DIGIT [ "." 1*DIGIT] )
frametime     = 1*DIGIT ":" 2DIGIT ":" 2DIGIT [ ":" 2DIGIT [ "." 2DIGIT ] ]
clocktime     = (datetime / walltime / date)
datetime      = date "T" walltime
date          = years "-" months "-" days
walltime      = (HHMM / HHMMSS) tzd
HHMM          = hours24 ":" minutes
HHMMSS        = hours24 ":" minutes ":" seconds ["." fraction]
years         = 4DIGIT
months        = 2DIGIT   ; range from 01 to 12
days          = 2DIGIT   ; range from 01 to 31
hours24       = 2DIGIT   ; range from 00 to 23
minutes       = 2DIGIT   ; range from 00 to 59
seconds       = 2DIGIT   ; range from 00 to 59
fraction      = DIGIT+
tzd           = "Z" / (("+" / "-") hours24 ":" minutes )
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Space Segment ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
spacesegment  = xywhdef
xywhdef       = 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"
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Track Segment ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
tracksegment  = trackprefix "=" trackparam
trackprefix   = %x74.72.61.63.6B                          ; "track"
trackparam    = utf8string
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;; Name Segment ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
namesegment   = nameprefix "=" nameparam
nameprefix    = %x69.64                                   ; "id"
nameparam     = utf8string
;
;;;;;;;;;;;;;;;;;;;;;;;;;;;; Imported definitions ;;;;;;;;;;;;;;;;;;;;;;;;;;;;
;
DIGIT         = &lt;DIGIT, defined in rfc4234#3.4&gt;
pchar         = &lt;pchar, defined in rfc3986&gt;
unreserved    = &lt;unreserved, defined in rfc3986&gt;
pct-encoded   = &lt;pct-encoded, defined in rfc3986&gt;
utf8string    = "'" *( unreserved / pct-encoded ) "'"     ; utf-8 character
                                                          ; encoded URI-style</pre>
</div>
</div>
</div>

<div class="div1">
<h2><a name="processing" id="processing"></a>5 Interpreting and Processing
Media Fragments</h2>

<p>There are many open questions about how to resolve a media fragment URI that
are not being answered simply from the specification of the syntax. An
implementer will need to know all of these. This starts with issues around
standardisation and uptake, followed by issues of interpretation of the syntax,
followed by concrete protocol exchange scenarios for the different situations
explained above in section <a href="#fragment-query"><b>3 URI fragment and URI
query</b></a>. </p>

<table border="1" summary="Editorial note: Silvia">
  <tbody>
    <tr>
      <td align="left" valign="top" width="50%"><b>Editorial note:
      Silvia</b></td>
      <td align="right" valign="top" width="50%"> </td>
    </tr>
    <tr>
      <td colspan="2" align="left" valign="top"><p>NOTE to implementers: if you
        come across some not yet mentioned here, please email to
        public-media-fragment@w3.org. </p>
      </td>
    </tr>
  </tbody>
</table>

<div class="div2">
<h3><a name="processing-overview" id="processing-overview"></a>5.1 Overview</h3>

<div class="div3">
<h4><a name="processing-overview-standardisation"
id="processing-overview-standardisation"></a>5.1.1 Media Fragments
Standardisation</h4>

<p>When we talk about semantics of fragment identifiers in URIs, we need to
start with RFC3986, section <a href="#URIquery-media-fragments"><b>3.5
Resolving URI queries</b></a> . We note that, wherever fragments are not
defined in the respective media type registration, the general rule from
RFC3986, as stated above, applies. For the current IETF/IANA registration
process and requirements see RFC4288. Note that regarding fragments, as stated
in sec 4.11 of RFC4288, there is only a SHOULD-requirement. Most media types
are expected not to specify fragments and their semantics, see also review of
media types regarding fragment identifiers. </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 few media types that
actually have a registered fragment specification, including Ogg, MPEG-4, and
MPEG-21. For all others, the semantics of the fragment are considered to be
unknown. The media fragment specification to be defined through the Media
Fragment WG will be a recommendation to media type owners. We recommend to
update or add the fragment semantics specification to their media type
registration once a generic scheme has been determined. At minimum, those
schemes that have an existing, diverging fragment specification should be
harmonized. To achieve uptake of the scheme, updates to the server and client
software for the different media types will be required. </p>

<table border="1" summary="Editorial note: Silvia">
  <tbody>
    <tr>
      <td align="left" valign="top" width="50%"><b>Editorial note:
      Silvia</b></td>
      <td align="right" valign="top" width="50%"> </td>
    </tr>
    <tr>
      <td colspan="2" align="left" valign="top"><p>See also the <a
        href="http://www.w3.org/2008/WebVideo/Fragments/wiki/MediaTypeReview">review</a>.
        </p>
      </td>
    </tr>
  </tbody>
</table>
</div>

<div class="div3">
<h4><a name="processing-overview-interpretation"
id="processing-overview-interpretation"></a>5.1.2 General Interpretation</h4>

<p>This is a list of hints to implementers on how to interpret media fragment
URIs. There is no particular order to them.</p>

<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>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>Reasonable Byte Clipping:</em> A media fragment that is retrieved using
URI fragment requests needs to be implementable without transcoding solely
based on byte ranges. Temporal or spatial clipping needs to be as close as
reasonably possible to what the media fragment specified. "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. Similarly for spatial ranges. 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>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>
</div>

<div class="div3">
<h4><a name="processing-overview-errors"
id="processing-overview-errors"></a>5.1.3 Error Handling</h4>

<p>There are a large number of error situations possible. This section
describes what to do in each case.</p>

<p><em>Non-existent dimension:</em> 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>

<p><em>Over-specified Dimension:</em> If a dimension (temporal, spatial, track)
is used multiple times, only the last occurrence is considered. For example,
<code>http://www.example.com/video.orgv#t=10&amp;t=20</code> will lead to the
same result as <code>http://www.example.com/video.orgv#t=20</code>. </p>

<table border="1" summary="Editorial note: Jack">
  <tbody>
    <tr>
      <td align="left" valign="top" width="50%"><b>Editorial note: Jack</b></td>
      <td align="right" valign="top" width="50%"> </td>
    </tr>
    <tr>
      <td colspan="2" align="left" valign="top"><p>It is still a contentious
        issue whether an over-specified dimension should be an error or not in
        the group. Feedback is requested. </p>
      </td>
    </tr>
  </tbody>
</table>

<p><em>Under-specified Dimension:</em> The result of doing spatial clipping on
a media resource that has multiple video tracks is undefined if no track
selection is also applied.</p>

<table border="1" summary="Editorial note: Michael">
  <tbody>
    <tr>
      <td align="left" valign="top" width="50%"><b>Editorial note:
      Michael</b></td>
      <td align="right" valign="top" width="50%"> </td>
    </tr>
    <tr>
      <td colspan="2" align="left" valign="top"><p>We need to define more error
        semantics. Some areas:</p>
        <ol class="enumar">
          <li><p>Nonexistent (t= with begin and end past end-of-media, unknown
            id, unknown track)</p>
          </li>
          <li><p>Partially existent (t= with end past EOM, xywh spec that
            extends past bounds): could be clipped to the actual size of the
            resource</p>
          </li>
          <li><p>Non-existent that can be determined statically, for example
            t=20,10</p>
          </li>
          <li><p>Incompatible: if the named dimension is used, all the other
            dimensions are ignored. Alternatively: this is an error.</p>
          </li>
        </ol>
      </td>
    </tr>
  </tbody>
</table>
</div>
</div>

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

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

<table border="1" summary="Editorial note: Silvia">
  <tbody>
    <tr>
      <td align="left" valign="top" width="50%"><b>Editorial note:
      Silvia</b></td>
      <td align="right" valign="top" width="50%"> </td>
    </tr>
    <tr>
      <td colspan="2" align="left" valign="top"><p>We could do RTSP as well, as
        mentioned earlier.</p>
      </td>
    </tr>
  </tbody>
</table>

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

<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. In this case, the
HTTP exchanges are exactly the same as for any other Web resource where byte
ranges are requested <a href="#rfc2616">[RFC 2616]</a>. </p>

<p>For completeness reasons, here are the three cases a media fragment enabled
UA and a media Server will encounter:</p>

<div class="div4">
<h5><a name="processing-protocol-UA-mapped-new"
id="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>
</div>

<div class="div4">
<h5><a name="processing-protocol-UA-mapped-unchanged"
id="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>
</div>

<div class="div4">
<h5><a name="processing-protocol-UA-mapped-changed"
id="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>
</div>

<table border="1" summary="Editorial note: Silvia">
  <tbody>
    <tr>
      <td align="left" valign="top" width="50%"><b>Editorial note:
      Silvia</b></td>
      <td align="right" valign="top" width="50%"> </td>
    </tr>
    <tr>
      <td colspan="2" align="left" valign="top"><p>Somebody could create
        time-sequence diagrams for the protocol action. </p>
      </td>
    </tr>
  </tbody>
</table>
</div>

<div class="div3">
<h4><a name="processing-protocol-Server-mapped"
id="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
framgent-to-byte mapping themselves, because the mapping is not obvious. In
this case, the HTTP request of the User Agent will include the fragment hoping
that the server can do the byte range mapping itself and send back the
appropriate byte ranges.</p>

<p>We'll go through the protocol exchange action step by step. It starts with a
user's request for 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. 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.</p>

<p>When the UA doesn't know how to map time to bytes, it tries requesting this
time range 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: t:npt=10-20</pre>
    </div>
  </li>
</ul>

<p>The example shows a temporal Range request, which introduces the "t"
dimension and the "npt" unit. The specification for all new Range dimensions is
given through:</p>
<ul>
  <li><p><em>temporal:</em> t:&lt;unit&gt;=&lt;start&gt; - &lt;end&gt;</p>
  </li>
  <li><p><em>spatial:</em>
    xywh:&lt;unit&gt;=&lt;topleftx&gt;,&lt;toplefty&gt;,&lt;width&gt;,&lt;height&gt;</p>
  </li>
  <li><p><em>track:</em> track=&lt;trackname&gt;</p>
  </li>
  <li><p><em>name:</em> id=&lt;name&gt;</p>
  </li>
</ul>

<p>The unit is not optional. It can be "npt", "smpte", "smpte-25", "smpte-30",
"smpte-30-drop" or "clock" for temporal and "pixel" or "percent" for spatial.
Where "ntp" is used for a temporal Range, only specification in seconds is
possible without the "s". 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 become required in the Range header.</p>

<table border="1" summary="Editorial note: Silvia">
  <tbody>
    <tr>
      <td align="left" valign="top" width="50%"><b>Editorial note:
      Silvia</b></td>
      <td align="right" valign="top" width="50%"> </td>
    </tr>
    <tr>
      <td colspan="2" align="left" valign="top"><p>Somebody should create an
        ABNF for these new Range dimensions. </p>
      </td>
    </tr>
  </tbody>
</table>

<p>If the server doesn't understand a Range header, it MUST ignore the header
field that includes that range-set. This is in sync to the HTTP RFC <a
href="#rfc2616">[RFC 2616]</a>. This means that where a server doesn't 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 <a href="#rfc2616">[RFC 2616]</a>.</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, xywh, track, id
Content-Length: 3743
Content-Type: video/ogg
Content-Range: bytes 19147-22880/35614993
Content-Range: t:npt 11.85-21.16/653.791
Etag: "b7a60-21f7111-46f3219476580"

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

<p>Note that in comparison to the specification in the request Range header,
the reply Content-Range header also adds the instance-length after a slash "/"
character. Also note that through the extended list in the Accept-Ranges it is
possible to identify which fragment schemes a server supports.</p>
<ul>
  <li><p><em>temporal:</em> t:&lt;unit&gt;=&lt;start&gt; -
    &lt;end&gt;/&lt;duration&gt;</p>
  </li>
  <li><p><em>spatial:</em>
    xywh:&lt;unit&gt;=&lt;topleftx&gt;,&lt;toplefty&gt;,&lt;width&gt;,&lt;height&gt;/&lt;total_width&gt;,&lt;total_height&gt;</p>
  </li>
  <li><p><em>track:</em>
    track=&lt;trackname1&gt;[,&lt;trackname2&gt;]*/&lt;duration&gt;</p>
  </li>
  <li><p><em>name:</em> id=&lt;name&gt;/*</p>
  </li>
</ul>

<p>For temporal it is the total duration in seconds, for spatial the total
width and height dimension, for track again the total duration in seconds, for
id just "*" since it could be any of the other dimensions.</p>

<p>Also note that, 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.</p>

<p>In the case where a media fragment results in a multipart message-body, the
bytes Content-Range headers will be spread throughout the binary data ranges,
but the Content-Range of the media fragment will only be with the main header.
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, xywh, track, id
Content-Length: 3743
Content-Type: video/ogg
Content-Range: track audio1,video1/653.791
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 <a href="#rfc2616">[RFC
2616]</a>. Thus, the new Range requests won't be cached by legacy Web
proxies.</p>

<table border="1" summary="Editorial note: Silvia">
  <tbody>
    <tr>
      <td align="left" valign="top" width="50%"><b>Editorial note:
      Silvia</b></td>
      <td align="right" valign="top" width="50%"> </td>
    </tr>
    <tr>
      <td colspan="2" align="left" valign="top"><p>Need to discuss if two
        Content-Range headers are ok and solve our cacheability problems. Or if
        we need to invent a new header name (Conrad's "Fragment:") for
        delivering the mapping. It is important for the UA, but also for the
        caching proxy, that may be media enabled and thus know what to do with
        it.</p>

        <p>Further, there is discussion in the group still whether "track" and
        "id" dimension can actually be handled in the same way as temporal and
        spatial, see <a
        href="http://www.w3.org/2008/WebVideo/Fragments/wiki/Server-parsed_Fragments">Conrad's
        Fragment proposal</a>.</p>

        <p>Also should specify the ABNF for the Content-Range header.</p>

        <p>And somebody should paint time-sequence diagrams for the protocol
        action - or update the existing ones to match with the description
        here.</p>

        <p>Further note that we may want to specify a list of track names and
        not just one - isn't yet done in the ABNF for the media fragment URIs
        above.</p>
      </td>
    </tr>
  </tbody>
</table>
</div>

<div class="div3">
<h4><a name="processing-protocol-proxy"
id="processing-protocol-proxy"></a>5.2.3 Proxy cacheable Server mapped byte
ranges</h4>

<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
cachable, we introduce some extra HTTP headers, which will help tell the server
and the proxy what to do.</p>

<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.
The message body of this answer contains the control section of
fragf2f.mp4#12,21 (if required). </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, xywh, track, id
Content-Length: 0
Content-Type: video/ogg
Content-Range: t:npt 11.85-21.16/653.791
Range-Redirect: 19147-22880
Vary: Accept-Range-Redirect</pre>
    </div>
  </li>
</ul>

<table border="1" summary="Editorial note: Silvia">
  <tbody>
    <tr>
      <td align="left" valign="top" width="50%"><b>Editorial note:
      Silvia</b></td>
      <td align="right" valign="top" width="50%"> </td>
    </tr>
    <tr>
      <td colspan="2" align="left" valign="top"><p>I have removed
        X-Accept-Range-Redirect - the X-Range-Redirect header already indicates
        that a mapping to byte ranges has been undertaken and the Accept-Ranges
        header shows which fragment addressing types the server can resolve.
        Need to discuss.</p>

        <p>I have also removed the delivery of header information - for a URI
        fragment resolution, that's not necessary. When applying this to a URI
        query, however, it will be necessary, since the URI query delivers a
        completely new resource.</p>

        <p>I further added the Content-Range header, because it will tell the
        client what actual fragment data is being delivered, so this is
        required for the UA to get the actual mapping between fragment and byte
        ranges.</p>

        <p>I am using "307 Temporary Redirect" and thus Range-Redirect (rather
        than Range-Refer) to return the reply without data in the reply.</p>

        <p>We need an ABNF specification for Range-Redirect, which could
        contain a large number of ranges, then to be separated by comma.</p>
      </td>
    </tr>
  </tbody>
</table>

<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, xywh, track, id
Content-Length: 3743
Content-Type: video/ogg
Content-Range: bytes 19147-22880/35614993
Content-Range: t:npt 11.85-21.16/653.791
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>

<table border="1" summary="Editorial note: Silvia">
  <tbody>
    <tr>
      <td align="left" valign="top" width="50%"><b>Editorial note:
      Silvia</b></td>
      <td align="right" valign="top" width="50%"> </td>
    </tr>
    <tr>
      <td colspan="2" align="left" valign="top"><p>somebody should paint
        time-sequence diagrams for the protocol action - or update the existing
        one to match with the description here.</p>
      </td>
    </tr>
  </tbody>
</table>
</div>
</div>

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

<p>This section describes the protocol steps used in HTTP <a
href="#rfc2616">[RFC 2616]</a> 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"

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

<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>It is possible to add an additional HTTP response header called "Link" that
refers the new resource back to the original resource and 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 one created by the query.</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-proxy"><b>5.2.3 Proxy
cacheable Server mapped byte ranges</b></a>.</p>

<p>Not that a server that doesn't 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>

<table border="1" summary="Editorial note: Silvia">
  <tbody>
    <tr>
      <td align="left" valign="top" width="50%"><b>Editorial note:
      Silvia</b></td>
      <td align="right" valign="top" width="50%"> </td>
    </tr>
    <tr>
      <td colspan="2" align="left" valign="top"><p>somebody should paint
        time-sequence diagrams for the protocol action.</p>
      </td>
    </tr>
  </tbody>
</table>
</div>
</div>

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

<div class="div2">
<h3><a name="qualification-resources" id="qualification-resources"></a>6.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 name="references-normative" id="references-normative"></a>A
References</h2>
<dl>
  <dt class="label"><a name="rfc2119" id="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" id="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="rfc2616" id="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="ogg" id="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" id="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="rfc5147" id="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" id="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" id="html5"></a>HTML 5</dt>
    <dd>Ian Hickson, Google (ed).<a
      href="http://www.whatwg.org/specs/web-apps/current-work/"><cite>HTML5</cite></a>.
      WHATWG Draft Standard, 25th August 2009. Available at <a
      href="http://www.whatwg.org/specs/web-apps/current-work/">http://www.whatwg.org/specs/web-apps/current-work/</a>.
    </dd>
  <dt class="label"><a name="svg" id="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" id="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" id="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" id="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" id="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" id="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" id="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" id="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" id="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" id="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="abnf" id="abnf"></a>ABNF</dt>
    <dd><cite>Augmented BNF for Syntax Specifications: ABNF</cite>, Internet
      STD 68 (as of April 2009: <a
      href="http://tools.ietf.org/html/rfc5234">RFC 5234</a>). </dd>
  <dt class="label"><a name="isoBaseMediaFF" id="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" id="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>
</dl>
</div>

<div class="div1">
<h2><a name="acknowledgments" id="acknowledgments"></a>B 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), Jack Jansen
(CWI), Yves Lafon (W3C/ERCIM), 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 (CWI),
Vassilis Tzouvaras (K-Space), 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, Philip Jägenstedt, Ryo Kawaguchi, Véronique
Malaisé, Henrik Nordstrom, Yannick Prié, Yves Raimond, Julian Reschke,
Geoffrey Sneddon, Felix Sasaki, Philip Taylor, Christian Timmerer, Jorrit
Vermeiren and Munjo Yu. </p>
</div>

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

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