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

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

From: Conrad Parker <conrad@metadecks.org>
Date: Mon, 7 Dec 2009 18:11:28 +0900
Message-ID: <dba6c0830912070111t2508cf00pcfcac886e6917b8e@mail.gmail.com>
To: RaphaŽl Troncy <Raphael.Troncy@cwi.nl>
Cc: Media Fragment <public-media-fragment@w3.org>
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.



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

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