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

Re: Aligning NPT syntax with RTSP

From: Philip Jägenstedt <philipj@opera.com>
Date: Wed, 27 Jan 2010 13:45:37 +0100
To: "Silvia Pfeiffer" <silviapfeiffer1@gmail.com>
Cc: public-media-fragment@w3.org
Message-ID: <op.u66y2bs6atwj1d@sisko.linkoping.osa>
On Wed, 27 Jan 2010 13:32:11 +0100, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> On Wed, Jan 27, 2010 at 10:33 PM, Philip Jägenstedt <philipj@opera.com>  
> wrote:
>> On Wed, 27 Jan 2010 12:23:25 +0100, Silvia Pfeiffer
>> <silviapfeiffer1@gmail.com> wrote:
>>
>>> On Wed, Jan 27, 2010 at 10:09 PM, Philip Jägenstedt <philipj@opera.com>
>>> wrote:
>>>>
>>>>
>>>> http://www.w3.org/2008/WebVideo/Fragments/WD-media-fragments-spec/#npttime
>>>>
>>>> This is what I mentioned in the teleconf. As it is, '0.' would not be  
>>>> a
>>>> valid production of npttime but it is a valid production of npt-sec  
>>>> from
>>>> RTSP [1]. The same is true of '00:00:00.'. The difference is in digits
>>>> after
>>>> the decimal point.
>>>
>>> We currently have:
>>>
>>> npttime    ::=          ( 1*DIGIT [ "." 1*DIGIT ] [ timeunit ] ) |
>>>                        ( 1*DIGIT ":" 2DIGIT ":" 2DIGIT [ "." 1*DIGIT] )
>>>
>>> which I think you are proposing to change to
>>>
>>> npttime    ::=          ( 1*DIGIT [ "." *DIGIT ] [ timeunit ] ) |
>>>                        ( 1*DIGIT ":" 2DIGIT ":" 2DIGIT [ "." *DIGIT] )
>>>
>>> Correct?
>>
>> To be precise, I'm suggesting referring to the definition in RFC2326,  
>> noy
>> copying it. The effect is the same of course.
>
> Could do ...  otoh if the RTP spec changes this, we are not
> dependent... and it's really short.

RFCs can never change, but I have no objections to copying as long as  
there is a (normative?) reference to RFC2326 for readers to follow.

>>>> I would suggest simply importing npt-sec and npt-hhmmss from RFC2326,
>>>> dropping the 's' completely for simplicity. Since it isn't needed to
>>>> disambiguate and any existing software should tolerate omitting the s,
>>>> removing it shouldn't be a problem, right?
>>>
>>> IIRC, we added the "s" to be more compatible with some existing
>>> implementations such as the YouTube spec.
>>>
>>> I'm not sure if we have a record of that decision though.
>>
>> Given that YouTube uses the media fragment on the HTML document (right?)
>> that doesn't sound like it matters.
>
> I guess ... though we still used it as motivation.
>
>
>> When there are browsers that support
>> media fragments on the media resource URL, web authors (including  
>> YouTube)
>> will use whatever syntax browsers support. Since the trailing s only  
>> seems
>> to add (a little) complexity I'd rather not have it.
>
> Hmm .. as Conrad say: we're not fully following their syntax anyway,
> so I'd be happy to drop the "s", too. That also makes it fully
> compatible with RFC2326.

OK, if no one objects soonish I'll go ahead and make this change.

-- 
Philip Jägenstedt
Core Developer
Opera Software
Received on Wednesday, 27 January 2010 12:46:14 GMT

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