W3C home > Mailing lists > Public > public-media-fragment@w3.org > February 2010

Re: dropping 's' and quoting of strings

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Tue, 23 Feb 2010 15:38:14 +1100
Message-ID: <2c0e02831002222038y5e02c4c3m3c6ff6501ba97b41@mail.gmail.com>
To: Philip Jägenstedt <philipj@opera.com>
Cc: Jack Jansen <Jack.Jansen@cwi.nl>, Media Fragment <public-media-fragment@w3.org>
On Tue, Feb 23, 2010 at 11:46 AM, Philip Jägenstedt <philipj@opera.com> wrote:
> On Tue, 23 Feb 2010 04:36:03 +0800, Jack Jansen <Jack.Jansen@cwi.nl> wrote:
>
>>
>> On 22 feb 2010, at 05:10, Philip Jägenstedt wrote:
>>
>>> There are two changes I would like to make, previously mentioned deep in
>>> some thread:
>>>
>>> 1. Drop the trailing s from the npt syntax, which seems not to serve any
>>> real purpose as it only adds (a little) complexity but doesn't help
>>> disambiguate from any other form. It also isn't what is used in RTSP, if we
>>> want to align.
>>>
>>> 2. Drop the 'quotes' around strings, which are completely unnecessary
>>> when spaces have to be percent-encoded anyway. Simply following the rules
>>> for splitting name-value pairs yields a string with any special characters
>>> decoded.
>>
>>
>> Would this work if I had, say, an ampersand (or any other special
>> character) in my track name?
>>
>> I think it may work: IIRC the quotes were added before we referenced
>> rfc3986 for the string parameters, and I think the "unreserved" character
>> set is restricted enough.
>>
>> But: someone with a strong ABNF background needs to check. We want to make
>> sure that "http://www.example.com/id=my%26name&t=5" actually splits on &
>> before turning the %26 into an ampersand.
>
> The splitting is defined our own spec, in
> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#processing-name-value-components
>
> In short it first splits the fragment component by &, then by = and only
> after that performs percent decoding and UTF-8 decoding. So string can
> contain any code points that can be expressed as UTF-8, including spaces and
> any reserved characters in the URI spec.

Given this, I'm happy with dropping the quotes. They've been annoying
me a bit, too, but I thought they were necessary from a parsing
viewpoint. Now that Philip specified parsing with percent decoding, I
agree that it's possible to drop them.

Regards,
Silvia.
Received on Tuesday, 23 February 2010 04:39:11 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 21 September 2011 12:13:38 GMT