Re: [codec] draft-ietf-codec-oggopus: attached pictures

[Mark Harris <[e-mail]>]

Timothy B. Terriberry wrote:
> To resolve this, I'm proposing (as an individual) the following text, to be
> added in a new paragraph at the end of Section 4.2:

Probably 5.2.

>
> "The comment header MAY contain additional binary data which is not
> specified here. If the least-significant bit of the first byte of this data
> is 1, then editors SHOULD attempt to preserve the contents of this data when
> updating the tags, but if this bit is 0, all such data MAY be treated as
> padding, and be truncated or discarded as desired."
>
> Any binary extension for album art, etc., is going to have to be compatible
> with the Vorbis framing bit if we're going to use it for Vorbis as well, so
> I think this gives us a good extension mechanism with minimal restrictions
> while still allowing people to pad the comment header for in-place editing
> (so you can, e.g., update the comments without rewriting the whole file).
> Current tools use all-zero bytes for this padding, so they wouldn't have to
> change.

I support this change, as it at least allows for later extensions
(including binary picture attachments) with less risk that files
making use of such extensions will be mishandled by conforming tools.

The first sentence is a bit unclear about the location of the binary
data; for example, it might be interpreted to mean that a comment may
contain additional binary data after the text.  It would also be nice
to keep zero-padding outside of the category of what is not specified
here, as it is currently in use.  I propose that the first sentence be
worded as:

"Immediately following the user comment list, the comment header MAY
contain zero-padding or other binary data which is not specified
here."

 - Mark