Re: ACTION-112 follow-up: Conrad's vs current's proposal for Media Fragment Processing

Hi Conrad,

>> As you will read in the minutes of today's telecon, we distinguish two
>> (ideal) cases (ignoring the fallback plans):
>>  - case 1: the URI fragment can be resolved directly with the server help
>> and only one roundtrip (HTTP request / HTTP response) takes place
>>  - case 2: we introduce a hack so that the URI fragment can be cached in
>> current proxies, two roundtrips take place
> 
> what hack?

We mainly introduce the 4-ways handshake (aka two roundtrips) in the 
spec so that current caches deployed on the web can actually cache 
fragments since they understand only byte ranges so far. We could 
speculate in the future that caches will understand ranges in other 
units and therefore be also able to cache a HTTP range request directly 
expressed in seconds. In this later case, the 4-ways handshake is no 
longer necessary ... thus the hack.

>> For the case 1, it seems that your proposal and the current's proposal are
>> similar except that:
>>  . you introduce two new headers ('Fragment' and 'Content-Fragment')
>>  . your HTTP response is a 200 (and not a 206) and Yves argues that the
>>  chances that a cached fragment will be reused and served from the cache is
>> pretty low [3].
>>
>> *Question:* could you please argue and explain what advantages the
>> introduction of these two new headers bring?
> 
> To argue advantages, please tell me what to compare against. As I
> understand, no other mechanism has been proposed for dealing with
> textual media fragments (track, id etc.) via HTTP.

We are trying to compare your approach that introduces the headers 
'Fragment' and 'Content-Fragment' and the one written in the spec. 
Indeed, the 'track' and 'id' dimensions are tricky and badly described 
so far. What makes you think that we will not be able to 'invent' units 
to address 'track' or even 'id' directly in a HTTP range request?

>> For the case 2, both approaches require two round-trips:
>>  . Yves argues that we should use a 307 response code for the first
>> roundtrip (instead of a 200)
>>  . The current proposal misses the information about the real time range it
>> identifies when the bytes range request is issued. Should we simply fix it
>> by adding 2 Range headers: one in bytes and one in e.g. time:npt?
> 
> The byte-range request is a mechanism for retrieving some data. The UA
> knows why it is retrieving that data, ie. it is the data corresponding
> to an earlier request for a URI including a time range.

Yes, but there are damned caches in the middle which might be interested 
in storing more information about the request in order to optimize the 
next similar one.

>> *Question:* is the role of the new headers introduced by Conrad
>> ('Range-Refer' and 'Accept-Range-Refer') similar to the new headers
>> introduced in the current proposal ('Range-Redirect' and
>> 'Accept-Range-Redirect')?
> 
> I renamed my Range-Redirect proposal to Range-Refer after some
> feedback from this WG. It was modelled on a simpler Range-Redirect
> mechanism from Annodex, which only handled changes of header data.

OK, so I understand from your reply that:
   - conrad:Range-Refer = spec:Range-Redirect
   - conrad:Accept-Range-Refer = spec:Accept-Range-Redirect
I don't really care at the moment as how we will finally name the 
headers, I'm just trying to spot the similarities and differences of 
both approaches.
Cheers.

   Raphaël

-- 
Raphaël Troncy
EURECOM, Multimedia Communications Department
2229, route des Crêtes, 06560 Sophia Antipolis, France.
e-mail: raphael.troncy@eurecom.fr & raphael.troncy@gmail.com
Tel: +33 (0)4 - 9300 8242
Fax: +33 (0)4 - 9000 8200
Web: http://www.eurecom.fr/~troncy/

Received on Monday, 7 December 2009 10:34:20 UTC