Re: ACTION-178: Review the complete document, remove unnecessary editorial notes before publication (Media Fragments Working Group)

On 22 jun 2010, at 08:04, Silvia Pfeiffer wrote:
>> Currently, we indeed represent multiple tracks through one track param, both
>> at server-side through query parameters and at client-side (i.e, the Media
>> Fragments Player) through URI fragments. Note that representing multiple
>> tracks through multiple track params introduces difficulties when we use
>> query parameters, since the server will only interpret the first occurrence
>> of a track param ... So I would vote for combining multiple tracks into one
>> track param.
> Yes, I prefer that, too. It's also how it is in the HTTP headers and
> makes things more compact and easier to parse.

Now I am confused.

My personal preference is also for multiple track names specified in a single track= parameter (and similar for during http protocol handling), but what I remember is that this was considered to be impossible (or difficult?), because of the lack of a decent grammatical construct for the separator. This was the whole discussion about when percent-escaping is done.

As far as I remember things, this is why we opted for multiple track= parameters (even though this has the disadvantage of treating the track= parameter differently than the spatial and temporal parameters.

Does anyone remember why we ended up with multiple track= parameters?
Jack Jansen, <>,
If I can't dance I don't want to be part of your revolution -- Emma Goldman

Received on Tuesday, 22 June 2010 19:39:38 UTC