Re: Backwards compatibility and the use cases and requirements draft

On Wed, Dec 17, 2008 at 8:24 PM, Yves Lafon <ylafon@w3.org> wrote:
> On Wed, 17 Dec 2008, Silvia Pfeiffer wrote:
>
>>
>> Ah yes, that's just the wiki page, but we will indeed put a version of
>> this into the use cases and requirements section of the specification.
>>
>> I've added a blurb at the end of the "side conditions" section on that
>> wiki page about fallback solutions. After having thought about it a
>> bit more, it is probably not a good idea to do the full media resource
>> download by default. For example, think about a media fragment URI to
>> an offset of 15 hours into a 20 hour long video for a 2 min long
>> fragment. Think about such a request on a mobile phone. With almost
>> certainty, you do not want your phone to just go off and download the
>> full resource instead of the 2 min excerpt.
>>
>> So, I think the user agent should inform the user of the failed
>> fragment URI and give the user the option to get the full resource,
>> but not do it by default.
>
> No, it would be against the "ignore what you don't know" rule. The client
> will see an incoming file with a _big_ Content-Length, that let the client
> decide to drop the connection to abort the transaction, but it has to be a
> client-side behaviour, not a server-side one.

I think that's what I said (i.e. it's dealt with client-side). Except,
it was my assumption that the server will 404 a media fragment request
where it doesn't understand a few extra message headers. That's
probably wrong and the server would by default reply with the full
resource if it cannot resolve the fragment (at least in the HTTP case
- not sure what happens in the RTP/RTSP case).

So, I have adapted the statement on the wiki. :)

Cheers,
Silvia.

Received on Wednesday, 17 December 2008 10:05:07 UTC