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

Hi all,

On Tue, Mar 9, 2010 at 10:59 AM, Conrad Parker <conrad@metadecks.org> wrote:
> 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.


While I do not quite understand Conrad's use case, I agree partially
(and maybe fully) with the objection to that resolution.

I think we can continue using "Range" as the request header from the
client for all of the dimensions we are talking about (Range on bytes,
t, track and id).

But, I do not believe we can use "Content-Range" as the reply header
for any of the dimensions bar bytes. This is why we introduced
"Content-Range-Equivalent".

Incidentally, I have a few more questions on that resolution:
* why are we using comma as a separator for track HTTP headers?
* also note that the spatial dimension can be resolved on the client
as in Davy's demo rather than sending anything to the server.

Cheers,
Silvia.

Received on Tuesday, 9 March 2010 00:28:16 UTC