- From: Conrad Parker <conrad@metadecks.org>
- Date: Fri, 5 Mar 2010 12:30:06 +0900
- To: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Cc: raphael.troncy@eurecom.fr, Media Fragment <public-media-fragment@w3.org>
On 5 March 2010 12:27, Silvia Pfeiffer <silviapfeiffer1@gmail.com> wrote: > On Fri, Mar 5, 2010 at 11:36 AM, Conrad Parker <conrad@metadecks.org> wrote: >> 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. >> > > So it would be > > http://www.example.com/video.ogv#track=A,C > > converted to > > Foo: track A, track C ? yup, something like that :) Conrad.
Received on Friday, 5 March 2010 03:30:43 UTC