- From: Conrad Parker <conrad@metadecks.org>
- Date: Fri, 5 Mar 2010 09:36:40 +0900
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: raphael.troncy@eurecom.fr, Media Fragment <public-media-fragment@w3.org>
On 5 March 2010 06:07, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > On Fri, Mar 5, 2010 at 12:11 AM, Conrad Parker <conrad@metadecks.org> wrote: >> On 4 March 2010 17:14, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: >>> On Thu, Mar 4, 2010 at 4:59 PM, Conrad Parker <conrad@metadecks.org> wrote: >>>> On 4 March 2010 11:55, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: >>>>> On Thu, Mar 4, 2010 at 1:14 PM, Conrad Parker <conrad@metadecks.org> wrote: >>>>>> On 4 March 2010 10:25, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: >>>>>>> On Thu, Mar 4, 2010 at 12:00 AM, Silvia Pfeiffer >>>>>>> <silviapfeiffer1@gmail.com> wrote: >>>>>>>> 2010/3/3 Raphaël Troncy <raphael.troncy@cwi.nl>: >>>>>>>> >>>>>>>>> Another problem is how should we express that when 2 tracks have been >>>>>>>>> requested? >>>>>>>> >>>>>>>> The background here is that using a comma as in track=audio,subtitle >>>>>>>> will not work in the HTTP headers, since the comma is used to separate >>>>>>>> headers from each other. As such, something like: >>>>>>>> Content-Range: track audio,subtitle/653.791 >>>>>>>> would be parsed to >>>>>>>> Content-Range: track audio >>>>>>>> Content-Range: subtitle/653.791 >>>>>>>> which is obviously incorrect. >>>>>> >>>>>> why? >>>>>> >>>>>> the comma thing is not about "will be parsed to", but "is equivalent >>>>>> to". So, an application could add the two headers in order: >>>>>> >>>>>> Content-Range: track audio >>>>>> Content-Range: subtitle/653.791 >>>>>> >>>>>> and this pair would be equivalent to, and could be merged by an >>>>>> intermediary proxy into,: >>>>>> >>>>>> Content-Range: track audio, subtitle/653.791 >>>>>> >>>>>> So the comma thing is more about allowing the infrastructure to be >>>>>> more flexible (ie. different parts of an application stack can append >>>>>> headers without rewriting existing ones) while still being cacheable >>>>>> (the two header representations are equivalent). >>>>>> >>>>>> Conrad. >>>>>> >>>>> >>>>> I am not even sure that comma thing actually works in this way. >>>>> >>>> >>>> RFC2616, Section 4.2 Message Headers: >>>> >>>> Multiple message-header fields with the same field-name MAY be present >>>> in a message if and only if the entire field-value for that header >>>> field is defined as a comma-separated list [i.e., #(values)]. It MUST >>>> be possible to combine the multiple header fields into one >>>> "field-name: field-value" pair, without changing the semantics of the >>>> message, by appending each subsequent field-value to the first, each >>>> separated by a comma. The order in which header fields with the same >>>> field-name are received is therefore significant to the interpretation >>>> of the combined field value, and thus a proxy MUST NOT change the >>>> order of these field values when a message is forwarded. >>> >>> Ah thanks. I wasn't able to find this. I wonder if this implies that a >>> proxy can split a field-value at a comma as it likes. >> >> no, as far as I understand it only the other way (combining) can be >> done automatically. >> >> This is becaues it's possible to define a header that does use comma >> for something else, but in that case it's not allowed to have more >> than one instance of that field -- ie. if you violate the "if and only >> if" requirement of the paragraph I posted above. I think it's best to >> avoid that when defining new headers, so that we allow the combining >> behavior etc. In particular for our case we are defining a kind of >> list, and the standard comma mechanism is useful. >> > > So if I understand you correctly, you'd also suggest using something > else than a comma to separate the list of tracks in a track fragment > URI? If you want to express that the content contains tracks A and C, using header Foo, then you could say: Foo: track A, track C but not: Foo: tracks A,C If you really wanted that form then you would have to replace the comma with something else. On the other hand, perhaps the first form is more flexible; an application (say. some simple CGI script) that adds subtitle track C could simply add the "Foo: track C" header. Conrad. > > Thanks for clarifying - it's good to read and understand these things > thoroughly. I was indeed wondering how Microsoft's scheme could work > when they in fact used commas. > > Cheers, > Silvia. > >
Received on Friday, 5 March 2010 00:37:17 UTC