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

2009/12/3 Raphaël Troncy <Raphael.Troncy@cwi.nl>:
> Hi Conrad,
>
> Following the ACTION-112 thread on the mailing list [1], and today's telecon
> [2], I try to summarize the remaining questions and issues we have in order
> to get a clear picture and converge towards a common solution.
>
> 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?

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

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

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

cheers,

Conrad.

>
> [1]
> http://lists.w3.org/Archives/Public/public-media-fragment/2009Dec/0008.html
> [2] http://www.w3.org/2009/12/02-mediafrag-minutes.html
> [3]
> http://lists.w3.org/Archives/Public/public-media-fragment/2009Dec/0014.html
>
> --
> 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 09:12:19 UTC