Re: WebVTT signature

I think the only versioning that we want is some kind of standard set of 'CSS' rules. For example the BBC may always want a specific font and a certain set of colors that would be used for a .red .green .blue class markup etc. However, we do not need versions for that. It can be achieved through name-value pairs at the start of the file (header-style metadata), which I'd really like to see introduced for other use cases, too. These include adding the main language used by the file (I.e. what the browser uses @srclang for), adding the kind, and adding the label. All of these may be ignored be browsers, but are really important for stand-alone players.

As for the signature: I always thought that 'WEBVTT' plus potential BOM would be sufficient to recognize it. It's not sufficient to parse it successfully but that doesn't matter to IANA.

Cheers,
Silvia.

Sent from my iPhone

On 03/12/2011, at 12:34 AM, David Singer <singer@apple.com> wrote:

> I also wonder whether it would be prudent to put a marker on this line, for a version, in case we ever need to do something where the author needs a v2 or greater implementation (and prefers nothing on a v1 implementation)
> 
> On Dec 2, 2011, at 14:02 , Simon Pieters wrote:
> 
>> IANA considerations says:
>> 
>> Magic number(s):
>> WebVTT files all begin with one of the following byte sequences:
>> 
>> EF BB BF 57 45 42 56 54 54 0A
>> EF BB BF 57 45 42 56 54 54 0D
>> EF BB BF 57 45 42 56 54 54 20
>> EF BB BF 57 45 42 56 54 54 09
>> 57 45 42 56 54 54 0A
>> 57 45 42 56 54 54 0D
>> 57 45 42 56 54 54 20
>> 57 45 42 56 54 54 09
>> (An optional UTF-8 BOM, the ASCII string "WEBVTT", and finally a space, tab, or line break.)
>> 
>> However, the parser accepts files that contain only "WEBVTT" (or BOM followed by "WEBVTT"), without a newline. The syntax requires two newlines, though.
>> 
>> Is the above intended to match what the parser accepts? Or what the syntax allows?
>> 
>> -- 
>> Simon Pieters
>> Opera Software
>> 
> 
> David Singer
> Multimedia and Software Standards, Apple Inc.
> 
> 

Received on Saturday, 3 December 2011 21:45:45 UTC