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

Mark Harris <> Thu, 25 September 2014 05:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 3D41C1A6F32 for <>; Wed, 24 Sep 2014 22:55:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 66R9JPoB_Tpa for <>; Wed, 24 Sep 2014 22:55:15 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c05::235]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9F8201A6F2E for <>; Wed, 24 Sep 2014 22:55:15 -0700 (PDT)
Received: by with SMTP id h18so7830664igc.2 for <>; Wed, 24 Sep 2014 22:55:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:content-type; bh=TBSPQRkGvapK2CqRVJ/t6qWbpW8TaeVL+a4QMKwI0eU=; b=sFZe+3bLtFYwRxBFc7SSADNhrKCndMkSvOn6OClxQTtQiV4mVJPkL6t5KDzcT/jRvm Kf1D5MHeuxHuBBz/PI2vMHK1JN5s/f+n2RUL6UJt7lMWNE8gBOyRvmk4wD5LLsRac74S WGUqH/ah9gR/wBDnMP+paUIRqYQ4gK5op1J89rbswiByIBx3N9K9Vl9lhhcmH2mmI1Rp ln0p45ppeI5RQJNNH2R7DWPqHwrZpe5TwadVSmM6EMobpTSWh3T+5cPiQUUd1Jhr6nIu 7HFBVeSguhhp9+7x2VLZUbiJv60Ixti04GEvY1wzcWC4TxMO7xr7EtXnkRIJBdz3DAI4 Rx6Q==
MIME-Version: 1.0
X-Received: by with SMTP id lk20mr16161111icc.17.1411624515046; Wed, 24 Sep 2014 22:55:15 -0700 (PDT)
Received: by with HTTP; Wed, 24 Sep 2014 22:55:14 -0700 (PDT)
In-Reply-To: <>
References: <> <> <> <20140830072745.GF326@hex.shelbyville.oz> <> <> <> <>
Date: Wed, 24 Sep 2014 22:55:14 -0700
X-Google-Sender-Auth: 0ppCao2HXuAzAhnJWzR-QVhvjWk
Message-ID: <>
From: Mark Harris <>
To: "" <>
Content-Type: text/plain; charset="UTF-8"
Subject: Re: [codec] draft-ietf-codec-oggopus: attached pictures
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Codec WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 25 Sep 2014 05:55:17 -0000

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

 - Mark