W3C home > Mailing lists > Public > public-media-fragment@w3.org > April 2009

Re: Review of section 7

From: Conrad Parker <conrad@metadecks.org>
Date: Mon, 13 Apr 2009 14:12:06 +0900
Message-ID: <dba6c0830904122212r6eed6a6dq3a10c4f6f89670d9@mail.gmail.com>
To: Yves Lafon <ylafon@w3.org>
Cc: Media Fragment <public-media-fragment@w3.org>
Hi Yves,

2009/4/13 Yves Lafon <ylafon@w3.org>:
> On Mon, 13 Apr 2009, Conrad Parker wrote:
>> 2009/4/13 Yves Lafon <ylafon@w3.org>:
>>> On Sun, 12 Apr 2009, Silvia Pfeiffer wrote:
>>>> * we need to mention that the replies are not cachable for the full
>>>> resource, but cache only the fragmented resource, which can result in
>>>> n copies of some subset of the resource in caching web proxies. Since
>>>> it is typically expected that a fragment request will be used
>>>> repeatedly (e.g. a fragment URI being shared around), this is
>>>> potentially acceptable. But we have no experimental data to confirm or
>>>> deny that this may pose a challenge to caching web proxies.
>>> Why? it is the case only if the cache can't handle merging timed
>>> fragment,
>>> which is the case of general purposes caches (they will handle only
>>> bytes),
>>> but media procies might be able to do so. Once again, it is not sure that
>>> they will do that as requesting the whole resource and serve fragments
>>> from
>>> the cache might be more efficient for such caches anyway :)
>> HTTP/1.1 byte-range caching is a format-agnostic method, and already
>> 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

> Can you point me to the decision saying that format-specific caches were not
> wanted?

No I can't! apparently it was decided in earlier meetings that
format-specific caches would be fun to implement :-)

> The merging algorithm depends on the format, and it is not this WG's task to
> specify the algorithm. It is up to implementers and format specifications.

yes :-)

>> 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

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 :-)

For example, if we wanted to deal with the presence of both units on
the HTTP response side: the returned data may vary in a different way
than for a normal partial GET, as it is no longer a bytewise subset of
the original resource. The data effectively becomes uncacheable: it
makes no sense to add a Vary header for Content-Range!

Received on Monday, 13 April 2009 05:12:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:52:42 UTC