bandwidth conservation use case, objection to use of Range for non-byte sections

Hi,

I would like to introduce a use cases that is not covered by the
existing specification: that a user agent may wish to retrieve a media
resource in chunks, so that the amount of content buffered ahead of
the user's current play position does not grow too large.

In order to handle this use case, i propose to introduce a new HTTP
Request and Response header pair. Following the naming of yesterday's
F2F discussions, these could be Range-Equivalent and
Content-Range-Equivalent; they could similarly be part of whatever
Fragment and Content-Fragment are now being called. Let's call it Foo.
The syntax would be as has been suggested for non-byte dimensions of
Range/Content-Range.

Then, a user agent wishing to retrieve the first 10kB of the resource
http://example.com/video.ogv#t=10,20 would translate this into:

Range: bytes=0-10000
Foo: t:npt=10-20

An origin server would respond with:

Content-Range: bytes 0-10000/*
Content-Foo: t:npt 10-20/0-75
Vary: Content-Foo


The use of a header other than Range for non-byte sections has various
advantages:

1. As a consequence, an existing, HTTP/1.1 compliant intermediate
caching proxy would cache this response and could re-use it when
providing all or part of a subsequent request for
http://example.com/video.ogv#t=10,20. For example, the response
containing only the first 5kB of the resource would be:

Content-Range: bytes 0-5000/*
Content-Foo: t:npt 10-20/0-75
Vary: Content-Foo

Such a caching proxy would separately cache parts of the response
generated by the origin server for
http://example.com/video.ogv#t=30,40 as indicated by the Vary header.

2. This mechanism can be used in cases where the client specifies only
"Accept-Ranges: bytes" (ie. all current browsers and proxies)

3. Only the media-related URL translation parts of user agents and web
servers would require modification to support this mechanism; whereas
if a new Range dimension is introduced, the transport portions of web
servers, the caching portion of user agents, and the caching portion
(ie. all) of caching proxies and content distribution networks would
need to be re-implemented to allow such ranges to be cached.

Semantically, I see the Foo header as describing a desired
representation (much like language handling), but Range has a
lower-level function related to transport and caching. I think it is
useful to allow both concerns to be handled by HTTP, which is
difficult if Range is overloaded.

I think it is useful to agree on a specification that meets the aims
of this working group without requiring all WWW implementations to be
rewritten. Hence I object strongly to
http://www.w3.org/2008/WebVideo/Fragments/wiki/WG_Resolutions#Media_Fragment_Headers
and instead suggest the use of this minor variation that does not
overload the existing Range/Content-Range transport mechanism.

Concerning the process of resolutions: I was not present for that
resolution as it was after midnight here, and had already raised this
objection and suggestion during the teleconf prior to its discussion.

cheers,

Conrad.

Received on Monday, 8 March 2010 23:59:43 UTC