- From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
- Date: Wed, 27 Jan 2010 23:32:11 +1100
- To: Philip Jägenstedt <philipj@opera.com>
- Cc: public-media-fragment@w3.org
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. >>> 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. Cheers, Silvia.
Received on Wednesday, 27 January 2010 12:33:06 UTC