Re: meta-data in the VTT file header, a strawman proposal

On Apr 20, 2012, at 11:04 , Silvia Pfeiffer wrote:

> On Thu, Apr 19, 2012 at 6:29 PM, David Singer <singer@apple.com> wrote:
>> 
>> On Apr 11, 2012, at 10:10 , Silvia Pfeiffer wrote:
>> 
>>>> RFC 822 generally considers values as "one long line that can be folded if it's too long", and I am not sure that's right for us.   I think that line-breaks can be significant in some of the values we cant, no?  (Such as CSS).
>>> 
>>> Do we need empty lines?
>> 
>> it makes style-sheets readable, and aren't line-breaks significant in style-sheets?
> 
> No, line breaks are not significant in style sheets. You can specify a
> CSS file in a single line. In fact, all web page compression programs
> do this. Semicolons are significant though.
> 
> As for line breaks in RFC822 header syntax: as long as you put a blank
> or other whitespace character at the beginning of the line, RFC822
> header syntax allows it to be a continuation line and folds it in. We
> would just need to make sure WebVTT doesn't recognize that as the end
> of the header section and starts trying to parse cues.
> 
> 
>> And we don't *want* actual empty lines, as simple parsers will think the cue-text is coming next.
> 
> OK, then RFC822 header syntax seems adequate.


Yes, but the transformation you have to exercise to make something into the format is quite significant;  and it's non-reversable.  What I suggested was a need to escape blank lines and one character sequence (]]).  For 822, you have to remove all blank lines and indent all other lines.  Basically, we're gambling that those changes are not significant for anything we want to embed. We think it's OK for CSS, but our use case is very different from 822.  In mail headers, the design of the headers themselves is controlled.  We, on the other hand, don't really want to restrict what *could* be an attribute-value.

So, 822 may look OK now, but it represents non-reversable transformation, changes every line of a multi-line attribute value by requiring all text be indented, and assumes all multi-line values are logically a single line with insignificant breaks.  That worries me.

David Singer
Multimedia and Software Standards, Apple Inc.

Received on Friday, 20 April 2012 03:45:47 UTC