- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Fri, 5 Mar 2010 14:27:49 +1100
- To: Conrad Parker <conrad@metadecks.org>
- Cc: raphael.troncy@eurecom.fr, Media Fragment <public-media-fragment@w3.org>
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 ? S.
Received on Friday, 5 March 2010 03:28:44 UTC