Re: Media Fragments URI parsing: pseudo algorithm code

On Sat, Jul 3, 2010 at 12:49 AM, Raphaël Troncy
<raphael.troncy@eurecom.fr> wrote:
> Hi Silvia,
>
>> 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."
>
> And I remember that this is clearly what the group wants.
>
>> 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.
>
> Indeed, and I step back since I overlook the ABNF syntax.
>  - a mediasegment can ONLY be namesegment OR a axissegment (time, space,
> track)
>  - BUT a segment can be a mediasegment OR a set of pchar
> I used to only look at the production rule of the mediasegment, thus my
> wrong interpretation. Therefore, our syntax clearly allows to have new
> name-value pairs.
> The fact that this bit of syntax is only specified in a non-normative
> appendix is still a problem. It should also be in the section 4.3.5.
>
> I don't see anymore what are the remaining problems posed by Philip and
> Yves. Please, could you please both clarify?


Only just to explicitly express the intent and to move the syntax into
the normative section.

As Philip said: "All dimensions so far are orthogonal. It would be
pretty bad language design to allow a new property to change the
semantics of an old one to the point that it is better that both are
ignored than only the old one being recognized."

I think we need to capture this.

Cheers,
Silvia.