[cvs-annodex] commit (/annodex):
standards/draft-pfeiffer-temporal-fragments-current.xml
silvia
nobody at lists.annodex.net
Fri Feb 11 14:52:58 EST 2005
Update of /annodex (new revision 877)
Modified files:
standards/draft-pfeiffer-temporal-fragments-current.xml
Log Message:
Added description of caching support for URIs with time-queries.
Also re-arranged the sections slightly.
Modified: standards/draft-pfeiffer-temporal-fragments-current.xml
===================================================================
--- standards/draft-pfeiffer-temporal-fragments-current.xml 2005-02-11 03:44:28 UTC (rev 876)
+++ standards/draft-pfeiffer-temporal-fragments-current.xml 2005-02-11 03:52:56 UTC (rev 877)
@@ -91,7 +91,8 @@
document have been implemented and proven to work with
<xref target="ANX">Annodex</xref> and <xref
target="CMML">CMML</xref> format Web resources over
- HTTP. A possible implementation over RTP/RTSP for Internet
+ <xref target="HTTP">HTTP</xref>. A possible implementation
+ over <xref target="RTSP">RTP/RTSP</xref> for Internet
streaming is being specified. Usage with other protocols
is possible, but has not been explored yet.
Also note that RealNetworks is using an different syntax
@@ -136,6 +137,12 @@
be addressed with the manner described in this specification.
</t>
+ <t>The temporal URI interval specifications are to be
+ used on resources that represent a specific timeline. An example
+ of such resources are most resources of MIME types "audio/*" and
+ "video/*".
+ </t>
+
</section>
@@ -234,16 +241,19 @@
<t>It is not valid to give several temporal URI query
parameters. They all need to be wrapped into a single
- specification. A URI with a query for several intervals may
+ specification.
+ </t>
+
+ <t>A URI with a query for several intervals may
be split by the user agent into several queries for a single
interval each and then sent to the server in consecutive
- requests, which in the case of HTTP 1.1 would e.g. be pipelined.
+ requests, which in the case of HTTP/1.1 would e.g. be pipelined.
This is of particular interest to user clients that can not
handle resources that consist of temporally non-consecutive
data, e.g. chained Annodex bitstreams.
</t>
- <t>Examples for temporal URI queries are:
+ <t>Examples for URIs containing temporal queries are:
</t>
<list style="symbols">
@@ -311,7 +321,7 @@
the sound file as a first step to applying some filter to them.
</t>
- <t>Examples for temporal URI fragment specifications are:
+ <t>Examples for URIs with temporal fragment specifications are:
</t>
<list style="symbols">
@@ -503,22 +513,17 @@
</section>
- <!--*******-->
- <!-- Usage -->
- <!--*******-->
- <section title="Usage over network protocols">
+ <!--**************************-->
+ <!-- Implementation with HTTP -->
+ <!--**************************-->
+ <section title="Implementation with HTTP">
- <t>The temporal URI interval specifications are to be
- used on resources that represent a specific timeline. An example
- of such resources are most resources of MIME types "audio/*" and
- "video/*".
- </t>
+ <section title="Identifying enabled HTTP servers">
- <section title="Implementation with HTTP">
-
<t>Time-continuous resources often come with high bandwidth
- requirements, so serving out only the queried time interval of
- a resource avoids unnecessary network load.
+ requirements, so a <xref target="HTTP">HTTP</xref> server
+ should serve out only the queried time interval of a
+ resource to avoid unnecessary network load.
For example, a 1 hour Digital Video (DV format) requires about
25 GB (MPEG-2 reduces that to about 3 GB). It also significantly
reduces the delay for the user agent for receiving relevant data.
@@ -539,7 +544,7 @@
a somewhat non-conformant resolution of a URI request that
contains a query component: if they cannot resolve the query,
but the base URI can be resolved, they simply return the base
- resource. The defeats all possibilities of a user agent to find
+ resource. This defeats all possibilities of a user agent to find
out whether a temporal query component was actually resolved or not.
</t>
@@ -547,7 +552,7 @@
temporal URI requests on a base resource MUST return an additional
accept header field that indicates that it can handle the temporal
URI addressing and for which resources it can handle it. The header
- field is called "X-Accept-TimeURI" and the value is a list of mime
+ field is called "X-Accept-TimeURI" and the value is a list of MIME
types, e.g. "X-Accept-TimeURI: application/x-annodex,text/x-cmml".
This request header is included for all URI requests to resources
on which the HTTP server can resolve a temporal URI request. A user
@@ -556,46 +561,226 @@
display the results.
</t>
- <t>It is expected that over time more servers and client
- applications understand and handle the temporal URI query
- parameters and thus enable direct networked access to content in
- time-continuous resources. Also Web proxies may begin to
- understand such temporal offsets and can exploit them for
- caching.
- </t>
</section>
- <section title="Implementation with RTP/RTSP">
- <t>Initial discussions within the AV Transport Working Goup
- have started about how to use temporal URI addressing over
- RTP/RTSP. It doesn't seem to make sense to distinguish between
- fragments and queries as in the streaming scenario everything
- is focused on being performed on the server. Therefore the idea
- is not to bother with query specifications and only focus on
- fragment specifications.
- </t>
+ <section title="Caching URIs with temporal queries in HTTP proxy servers">
- <t>When interpreting temporal fragment offsets in RTP/RTSP,
- the user agent transforms it into a Range specification in
- the PLAY request header field. Multiple time ranges are easily
- queued by several PLAY requests.
+ <t>Caching <xref target="HTTP">HTTP/1.1</xref> proxy servers
+ allow storage of requested Web resources closer to the requesting
+ user agent and reuse by other close-by user agents, reducing
+ bandwidth usage and access time. The HTTP/1.1 caching mechanisms
+ also works for time-based Web resources. However, complete
+ time-based Web resources, such as Annodex resources, are often
+ memory-intensive. User agents may more frequently request URIs
+ with temporal queries than the full resource. Therefore, a larger
+ impact on bandwidth usage comes from caching the temporal URI queries.
</t>
- <t>For example, a requested URI of rtsp://foo.bar/nemo#t=npt:10
- will e.g. result in the following PLAY request:</t>
+ <t>The caching mechanism in HTTP/1.1 for subranges of a resource is
+ based on storage of byte subranges. For time-based Web resources for
+ which it is possible to map a temporal URI query to a set of byte
+ subranges on the base resource, URIs with time-queries can also
+ be stored in a proxy's cache. To this end, the HTTP server MUST
+ ensure that the core data that relates to the temporal subpart is
+ bitwise identical to the original data - otherwise a byte range
+ cannot be defined. This is achieved for Annodex subresources by
+ changing only the control section but not the data section on
+ remuxing, as described in <xref target="ANX">the Annodex
+ specifiation</xref>.
+ </t>
+
+ <t>Mapping of temporal URI queries to byte ranges can only happen
+ on the origin server, being the only component that understands the
+ relationship between time and bytes. The caching mechanism in
+ HTTP/1.1 for byte ranges is based on the user agent requesting a
+ URI with a "Range" request header that specifies the byte ranges.
+ Thus, an additional agent-driven negotiation for delivery of the
+ byte range mapping is introduced to support temporal URI queries.
+ </t>
+
+ <t>A request header of "X-Accept-Range-Redirect" is required to
+ indicate to the server that a mapping of the temporal URI query
+ parameters to a byte range is requested rather than deliver of
+ the complete resource. As this field initiates the server to
+ provide a different response than if this field was not available,
+ the server has to include into its response a message header of
+ "Vary: X-Accept-Range-Redirect". It will also indicate with
+ "Accept-Ranges: bytes" that it is able to accept byte range
+ requests. And it will indicate with "X-Accept-TimeURI" that it
+ has processed the temporal URI query request.
+ </t>
+
+ <t>The server will return the byte ranges that the user agent
+ should ask for in another additional response header field:
+ "X-Range-Redirect". It will also need to redirect the user agent
+ to another resource, which it provides in the "Location" header
+ field. Data that is specific to the URI request with the given
+ time-query will then be returned to the user agent in the
+ message body, such as for example an adapted control section
+ of an Annodex file. The response is a 200 OK as the request
+ was satisfied with this response.
+ </t>
+
+ <t>After this, the user agent has all the information it requires
+ to post another GET request, this time for the base URI only and
+ including a "Range" request header field.
+ </t>
+
+ <t>In its response, the server includes the requested one or several
+ byte ranges. If several byte ranges are required, the response will
+ be a multipart message as defined in <xref target="HTTP">the HTTP/1.1
+ specification</xref>. The response message headers include the
+ "X-Accept-TimeURI" header, the "Accept-Ranges: bytes" header, and
+ the "Vary: Range" header, and provides the byte range(s) in the
+ "Content-Range" header.
+ </t>
+
+ <t>This is an example HTTP message exchange:
+ <list style="numbers">
+ <t>User Agent HTTP request:
+ <artwork><![CDATA[
+GET http://www.foo.bar/video.anx?t=npt:15.2 HTTP/1.1
+Accept: application/x-annodex
+X-Accept-Range-Redirect: please
+ ]]></artwork>
+ </t>
+ <t>Server HTTP response:
+ <artwork><![CDATA[
+HTTP/1.1 200 OK
+Date: Fri Feb 11 14:47:12 EST 2005
+Server: Apache/2.0(Unix)
+Content-Type: application/x-annodex
+X-Range-Redirect: 777-
+Vary: X-Accept-Range-Redirect
+Accept-Range: bytes
+Location: http://www.foo.bar/video.anx
+X-Accept-TimeURI: application/x-annodex, text/x-cmml
+
+Message body: control section of video.anx
+ ]]></artwork>
+ </t>
+ <t>User Agent HTTP request:
+ <artwork><![CDATA[
+GET http://www.foo.bar/video.anx HTTP/1.1
+Accept: application/x-annodex
+Range: bytes=777-
+ ]]></artwork>
+ </t>
+ <t>User Agent HTTP request:
+ <artwork><![CDATA[
+HTTP/1.1 200 OK
+Date: Fri Feb 11 14:49:08 EST 2005
+Server: Apache/2.0(Unix)
+Content-Type: application/x-annodex
+Content-Range: bytes 777-
+Vary: Range
+Accept-Range: bytes
+X-Accept-TimeURI: application/x-annodex, text/x-cmml
+
+Message body: video.anx from byte position 777 onwards
+ ]]></artwork>
+ </t>
+
+ </list>
+ </t>
+ </section>
+
+ <section title="Overview of added HTTP message headers">
+
+ <section title="X-Accept-Range-Redirect">
+
+ <t>The X-Accept-Range-Redirect request header field prompts
+ the server to reply with a byte range specification that
+ maps the queried time ranges of a URI.
+ </t>
+
+ <artwork><![CDATA[
+X-Accept-Range-Redirect = "X-Accept-Range-Redirect" ":" "please"
+ ]]></artwork>
+
+ </section>
+
+ <section title="X-Range-Redirect">
+
+ <t>The X-Range-Redirect response header field provides
+ a list of byte ranges to which the server redirects
+ a user agent for finding the rest of the data that
+ was requested.
+ </t>
+
+ <artwork><![CDATA[
+X-Range-Redirect = "X-Range-Redirect" ":" ranges-specifier
+ ]]></artwork>
+
+ <t>An example of this field is:
+ <artwork><![CDATA[
+X-Range-Redirect: bytes=500-600,1000-
+ ]]></artwork>
+ </t>
+
+ </section>
+
+ <section title="X-Accept-TimeURI">
+
+ <t>The X-Accept-TimeURI response header field provides
+ a list of media types for which the server is capable
+ of satisfying temporal URI query parameters.
+ </t>
+
+ <artwork><![CDATA[
+X-Accept-TimeURI = "X-Accept-TimeURI" ":" #( media-range )
+media-range = ( "*/*"
+ | ( type "/" "*" )
+ | ( type "/" subtype )
+ )
+ ]]></artwork>
+
+ <t>An example of this field is:
+ <artwork><![CDATA[
+X-Accept-TimeURI: application/x-annodex, text/x-cmml
+ ]]></artwork>
+ </t>
+
+ </section>
+
+ </section>
+
+ </section>
+
+
+ <!--******************************-->
+ <!-- Implementation with RTP/RTSP -->
+ <!--******************************-->
+ <section title="Implementation with RTP/RTSP">
+
+ <t>Initial discussions within the AV Transport Working Goup
+ have started about how to use temporal URI addressing over
+ RTP/RTSP. It doesn't seem to make sense to distinguish between
+ fragments and queries as in the streaming scenario everything
+ is focused on being performed on the server. Therefore the idea
+ is not to bother with query specifications and only focus on
+ fragment specifications.
+ </t>
+
+ <t>When interpreting temporal fragment offsets in RTP/RTSP,
+ the user agent transforms it into a Range specification in
+ the PLAY request header field. Multiple time ranges are easily
+ queued by several PLAY requests.
+ </t>
+
+ <t>For example, a requested URI of rtsp://foo.bar/nemo#t=npt:10
+ will e.g. result in the following PLAY request:</t>
<artwork><![CDATA[
PLAY rtsp://foo.bar/nemo RTSP 1.0
CSeq: 2
Session: 12345678
Range: npt=10-
- ]]></artwork>
+ ]]></artwork>
- <t>An implementation of this specification has not been
- put forward yet.
- </t>
+ <t>An implementation of this specification has not been
+ put forward yet.
+ </t>
- </section>
-
</section>
@@ -668,18 +853,15 @@
formats.
</t>
-<!--
- <t>Deleted the default time scheme according to a recommendation
- by Magnus Westerlund, Audio/Video Transport Working Group at
- IETF. Put it back in because it's such a pain to always specify.
- </t>
--->
-
<t>Replaced the word "timebase" with the word "basetime" as that
seems to be the more commonly used one to specify a timestamp
for the start of a stream of time-sampled data.
</t>
+ <t>Added a section on how to use timed URIs with HTTP.
+ This includes caching Web proxies and added HTTP message headers.
+ </t>
+
<t>Started a section on how to use timed URIs with RTP/RTSP.
Some initial feedback from the AVT Working Group at IETF seems
to indicate not to bother with rtsp queries and just to focus
@@ -954,14 +1136,113 @@
<seriesInfo name="I-D" value="draft-pfeiffer-cmml-01.txt" />
</reference>
+ <reference anchor="HTTP" target="http://www.ietf.org/rfc/rfc2616.txt">
+ <front>
+ <title>Hypertext Transfer Protocol -- HTTP/1.1</title>
+ <author initials="R.T." surname="Fielding" fullname="Roy T. Fielding">
+ <organization abbrev="UCI">University of California, Irvine</organization>
+ <address>
+ <postal>
+ <street>Department of Information and Computer Science</street>
+ <street>University of California, Irvine</street>
+ <city>Irvine</city> <region>CA</region> <code>92697-3425</code>
+ <country>US</country>
+ </postal>
+ <phone>+1 949 824 7403</phone>
+ <facsimile>+1 949 824 1715</facsimile>
+ <email>fielding at ics.uci.edu</email>
+ </address>
+ </author>
+ <author initials="J." surname="Gettys" fullname="James Gettys">
+ <organization abbrev="W3C">World Wide Web Consortium</organization>
+ <address>
+ <postal>
+ <street>MIT Laboratory for Computer Science</street>
+ <street>545 Technology Square</street>
+ <city>Cambridge</city> <region>MA</region> <code>02139</code>
+ <country>US</country>
+ </postal>
+ <facsimile>+1 617 258 8682</facsimile>
+ <email>jg at w3.org</email>
+ </address>
+ </author>
+ <author initials="J.C." surname="Mogul" fullname="Jeffrey C. Mogul">
+ <organization abbrev="WRL">Western Research Laboratory</organization>
+ <address>
+ <postal>
+ <street>Compaq Computer Corporation</street>
+ <street>250 University Avenue</street>
+ <city>Palo Alto</city> <region>CA</region> <code>94305</code>
+ <country>US</country>
+ </postal>
+ <email>mogul at wrl.dec.com</email>
+ </address>
+ </author>
+ <author initials="H.F." surname="Nielsen" fullname="Henrik Frystyk Nielsen">
+ <organization abbrev="W3C">World Wide Web Consortium</organization>
+ <address>
+ <postal>
+ <street>MIT Laboratory for Computer Science</street>
+ <street>545 Technology Square</street>
+ <city>Cambridge</city> <region>MA</region> <code>02139</code>
+ <country>US</country>
+ </postal>
+ <facsimile>+1 617 258 8682</facsimile>
+ <email>frystyk at w3.org</email>
+ </address>
+ </author>
+ <author initials="L." surname="Masinter" fullname="Larry Masinter">
+ <organization>Xerox Corporation</organization>
+ <address>
+ <postal>
+ <street>3333 Coyote Hill Road</street>
+ <city>Palo Alto</city> <region>CA</region> <code>94034</code>
+ <country>US</country>
+ </postal>
+ <phone>+1 650 812 4365</phone>
+ <facsimile>+1 650 812 4333</facsimile>
+ <email>masinter at parc.xerox.com</email>
+ </address>
+ </author>
+ <author initials="P.J." surname="Leach" fullname="Paul J. Leach">
+ <organization>Microsoft Corporation</organization>
+ <address>
+ <postal>
+ <street>1 Microsoft Way</street>
+ <city>Redmond</city> <region>WA</region> <code>98052</code>
+ <country>US</country>
+ </postal>
+ <email>paulle at microsoft.com</email>
+ </address>
+ </author>
+ <author initials="T." surname="Berners-Lee" fullname="Tim Berners-Lee">
+ <organization abbrev="W3C">World Wide Web Consortium</organization>
+ <address>
+ <postal>
+ <street>MIT Laboratory for Computer Science</street>
+ <street>545 Technology Square</street>
+ <city>Cambridge</city> <region>MA</region> <code>02139</code>
+ <country>US</country>
+ </postal>
+ <phone>+1 617 253 5702</phone>
+ <facsimile>+1 617 258 8682</facsimile>
+ <email>timbl at w3.org</email>
+ </address>
+ </author>
+ <date month="June" year="1999" />
+ </front>
+ <seriesInfo name="RFC" value="2616" />
+ </reference>
+
</references>
<section title="Acknowledgements">
- <t>The authors greatly acknowledge the contributions of Andre
- Pang and Andrew Nesbit in developing this syntax. We also thank
- Bill Miller and Oliver Morgan of the SMPTE for their
- contributions and Dave Singer from Apple Computer Inc. for his.
+ <t>The authors greatly acknowledge the contributions of Rob
+ Collins, Zen Kavanagh, and Andrew Nesbit in developing this
+ specification. We also thank Bill Miller and Oliver Morgan
+ of the SMPTE for their contributions and Dave Singer from
+ Apple Computer Inc. for his.
</t>
<t>The many comments on this document from the URI discussion
--
silvia
More information about the cvs-annodex
mailing list