Re: Test Cases: moving forward

Hi Raphael,

2010/5/20 Raphaël Troncy <raphael.troncy@eurecom.fr>:
> Hi Silvia,
>
>>>  - For #11, #12, #14 and #16: I suggest we force a 206 answer, with the
>>> rationale that a fragment has been requested (that might be equal to the
>>> entire resource but this is similar to case #01!).
>>
>> It's not really up to us, but it's up to the UA. As the UA will have
>> to retrieve the full resource, the question is whether it wants to
>> retrieve the resource in byte ranges or in one go. I have formulated
>> this better in the spec actually.
>
> We have further discussed this during today's telecon, but for the record:
> my rationale is that as soon as a Range request is issued, a 206 Partial
> Content should be returned. Therefore, the problem amounts to whether the UA
> should issue a Range request at all when it notices the fragment will be
> equal to the entire resource.
>
> I understand the good will of optimizing the communication between the UA
> and the server but I think we should not put too far away the intelligence
> that the UA should have.

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 believe this holds up for all the situations where a retrieval
action will successfully retrieve content from the server.

Cheers,
Silvia.

Received on Thursday, 20 May 2010 00:55:15 UTC