Re: Review of section 7

On Mon, 13 Apr 2009, Conrad Parker wrote:

>>> specified in an established standard. This WG has already determined
>>> that format-specific media proxy caching is not necessary for at least
>>> Ogg and MP4. If it is necessary for any other formats, we need to
>>> specify in detail what the format developers need to implement.
>>
>> Oh, did I miss that byte range was in rfc2616 and httpbis drafts?
>
> The request/response format for byte-ranges is specified, and rfc2616
> includes text like "HTTP/1.1 origin servers and intermediate caches
> ought to support byte ranges when possible." (14.35.2 Range Retrieval
> Requests). The way a cache does that, ie. whether or not it does
> byte-range recombining, is an implementation detail.
>
> By specifying methods that make use of the existing byte-range
> features, we do not add any new requirements for cache implementation;
> new implementation is restricted to the user agent and the origin
> server.

[..]
>>> I haven't yet seen a use for Range units other than bytes that does
>>> not cause complications :-)
>>
>> You think that the use of byte unit is without complications? :)
>
> Well, the mechanisms for handling byte ranges in HTTP are already well
> specified. If we make use of those then we don't add any new
> complications.

Ok, so first byte ranges are not without complications, including security 
issues (dos, not intrusions).

So your point is "caches are supporting byte ranges, so let's not 
introduce any new unit", right?
Like "let's not introduce video/* mime type, as application/octet-stream 
is well handled", or "let's not introduce new HTTP headers, as there are 
many already existing, and adding more will add complications"

> Byte and time units are not independent: in particular the use of time
> units may require modifying/inserting data, in a format-dependent
> manner. So by allowing both, we suddenly need to specify how to handle
> the presence of both. And we can't simply get rid of byte units, as
> they are already part of the protocol :-)

Of course byte and time are not independent, but when you are at the URI 
level, pointing to a fragment, you can't know directly the values on the 
byte axis, while it is easy to locate points in the time axis. And nobody 
said that byte unit would be ditched (should we ditch audio/wav?).

My original noodling was: what happens if the erquest is sent using a 
range request using 'seconds' as the unit, and the server reply with both 
a second range and a byte range? It might be that it's not even legal ;)
but if it works, it could give enough information for a cache and the 
client (to do the mapping between seconds and bytes, giving the right 
offset to start playing the video), and it's just a noodling, not even a
proposition.

-- 
Baroula que barouleras, au tiéu toujou t'entourneras.

         ~~Yves

Received on Tuesday, 14 April 2009 09:18:50 UTC