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

Re: Test Cases: moving forward

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Thu, 20 May 2010 10:54:22 +1000
Message-ID: <AANLkTinO8hmbKSANOueg_wPlVRx1SoKOauoq-RUWTD6L@mail.gmail.com>
To: RaphaŽl Troncy <raphael.troncy@eurecom.fr>
Cc: Media Fragment <public-media-fragment@w3.org>
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 GMT

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