Re: Test Cases: moving forward

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.


Cheers,
Silvia.

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