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

Re: Test Cases: moving forward

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 25 May 2010 22:38:49 +1000
Message-ID: <AANLkTikxsFpdnTQmxL67_8H4HVirw3mr6rkTHnieTxz7@mail.gmail.com>
To: RaphaŽl Troncy <raphael.troncy@eurecom.fr>
Cc: Media Fragment <public-media-fragment@w3.org>
2010/5/25 RaphaŽl Troncy <raphael.troncy@eurecom.fr>:
> 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.

That doesn't destroy interoperability. It is perfectly acceptable for
one browser to retrieve a resource in one go and another to make byte
range requests for it. They still follow the protocol.

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

If it's a 200 or a 206 - they are both successes - that's all that
counts. Not hard to check for these two alternatives. I'm just
flagging what will happen in reality on the 'net.

Received on Tuesday, 25 May 2010 12:39:43 UTC

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