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: RaphaŽl Troncy <Raphael.Troncy@cwi.nl>
Date: Mon, 07 Dec 2009 08:09:38 +0100
Message-ID: <4B1CAA32.4030309@cwi.nl>
To: Conrad Parker <conrad@metadecks.org>
CC: Media Fragment <public-media-fragment@w3.org>, Conrad Parker <conrad@metadecks.org>
Hi Conrad,

In preparation of this week telecon and Silvia's update of the section 5 
of our spec document, would you mind answering these questions below? We 
were not able to answer them last week telecon and they will be at the 
core of the discussion for this Wednesday telecon.
Thanks.

   RaphaŽl

> 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
> 
> 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?
> 
> 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?
> 
> *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')?
> 
> Cheers.
> 
>   RaphaŽl
> 
> [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 07:10:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:35 GMT