- 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
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 UTC