W3C home > Mailing lists > Public > public-media-fragment@w3.org > May 2010

Re: Test Cases: moving forward

From: RaphaŽl Troncy <raphael.troncy@eurecom.fr>
Date: Tue, 25 May 2010 14:21:47 +0200
Message-ID: <4BFBC0DB.7070605@eurecom.fr>
To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
CC: Media Fragment <public-media-fragment@w3.org>
Hi Silvia, all,

> How a UA transforms a media fragment URI into HTTP requests ultimately
> is up to the UA.
> I have right now left the replies all as 206 Partial Content in the
> spec, but I have added the following paragraph:
>
> Note: If the UA needs to retrieve a large part of the resource or even
> the full resource, it will probably decide to make multiple range
> requests rather than a single one. If the resource is, however, small,
> it may decide to just retrieve the full resource without a range
> request. The UA should make this choice given context information,
> e.g. if it knows that it will be a lot of data, it will retrieve it in
> smaller chunks. If it chooses to request the full resource in one go
> and not make use of a Range request, the result will be a 200 rather
> than a 206.

I have flagged this note as controversial in the WD and I suggest we 
discuss it with more attention (and people) during one of the next 
telecon (at the latest during the F2F meeting). I see here a serious 
risk of interoperability between systems because of un-specification.

I understand your arguments, and there are very good in the context of 
an optimization of the communication between a UA and a server, which is 
one of the main motivation for the Media Fragment URI specification ... 
BUT, we might end up with an implementation A that will always send 
Range Requests and get 206 responses and an implementation B, that, for 
the same fragment request, will decide it is too large as a fragment 
(without specifying what is "too" large) and do a normal request for the 
full resource and get a 200 response.

> I believe this holds up for all the situations where a retrieval
> action will successfully retrieve content from the server.

If we go this way, then how will we assess which implementations are 
conform to the test suite, and which ones are not?
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 Tuesday, 25 May 2010 12:23:27 GMT

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