Re: ACTION-112 follow-up: Conrad's vs current's proposal for Media Fragment Processing

2009/12/9 Yves Lafon <ylafon@w3.org>:
> On Tue, 8 Dec 2009, Raphaël Troncy wrote:
>
>>> Basically I'm viewing things like "track=audio" the same way that
>>> Language representations are handled. It works and it doesn't
>>> interfere with caching.
>>
>> I like this argument.
>
> Yes, track=audio is not really a fragment, doing conneg on content is more
> in order, in that case sending back a CL with a "?"-grade URI would be in
> order.

A note on the current spec:

Right now I have treated "track=audio" as a range request, because a
audio track is a set of byte ranges in a media file, thus it falls
under the same conditions as other media fragment approaches.

However, there is a big argument to be made for "track=audio" on a
video file resulting not in another video file, but in an audio file
and therefore being a different mime type and therefore needing to be
done through a URI query rather than a URI fragment.

OTOH, there are track-based fragments that do not change the mime
type. Thus, I assume we will need to continue doing it for both URI
fragments and URI queries.

Let's discuss.

Cheers,
Silvia.

Received on Monday, 14 December 2009 03:43:16 UTC