- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Fri, 2 Jul 2010 23:27:40 +1000
- To: Raphaël Troncy <raphael.troncy@eurecom.fr>
- Cc: Yves Lafon <ylafon@w3.org>, Philip Jägenstedt <philipj@opera.com>, Jack Jansen <Jack.Jansen@cwi.nl>, Media Fragment <public-media-fragment@w3.org>
On Fri, Jul 2, 2010 at 8:32 PM, Raphaël Troncy <raphael.troncy@eurecom.fr> wrote: > Hi Silvia, > >> So, now I am completely confused. I don't understand any more which >> case Philip is arguing and which Yves. I thought Yves argued that they >> are valid media fragments, while Yves that they are not. >> >> I personally believe they should be valid, since our discussion was >> always that we would ignore name-value parameters that the UA (or the >> server) doesn't understand. > > http://www.example.com/football.movie#t=10,20&action=track is NOT valid > according to the ABNF syntax, i.e. the syntax does to allow to produce such > a media fragment. > > I understand than Philip is arguing for more than just the ABNF grammar in > the normative part for handling such cases in an interoperable way while I > understand that Yves is stating that the ABNF syntax and a non-dummy > implementation for parsing it will be enough. If that is the case, our spec is inconsistent. We have a section that states: "Note that a general URI fragment or query string specified on a media resource may contain several field-value pairs. They are not restricted to the ones specified here, since applications may want to use additional other parameters to communicate further requests to custom servers." The idea behind this was to allow applications to add further name-value pairs which will be executed on top of the ones we already have defined. I was always under the impression that we had agreed that additional name-value pairs are allowed and don't make the ones that we define invalid. I was also under the impression that our ABNF allowed for this. If this is not the case, I am strongly for changing that. Cheers, Silvia.
Received on Friday, 2 July 2010 13:28:34 UTC