Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt

Ron <ron@debian.org> Wed, 11 July 2012 04:48 UTC

Return-Path: <ron@debian.org>
X-Original-To: codec@ietfa.amsl.com
Delivered-To: codec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 626D021F8552 for <codec@ietfa.amsl.com>; Tue, 10 Jul 2012 21:48:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.423
X-Spam-Level:
X-Spam-Status: No, score=-1.423 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_HOST_EQ_D_D_D_D=0.765, HOST_MISMATCH_NET=0.311, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ht+ZH8O3nx3M for <codec@ietfa.amsl.com>; Tue, 10 Jul 2012 21:48:51 -0700 (PDT)
Received: from ipmail06.adl2.internode.on.net (ipmail06.adl2.internode.on.net [IPv6:2001:44b8:8060:ff02:300:1:2:6]) by ietfa.amsl.com (Postfix) with ESMTP id 3C0BF21F8541 for <codec@ietf.org>; Tue, 10 Jul 2012 21:48:50 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: Av0EAH4F/U95LQwo/2dsb2JhbABFt36BCIIgAQEFOhwhAhALGC4UGA0kiB+9SYtAhW4DiEeFHodQAZAFgm+BSCM
Received: from ppp121-45-12-40.lns20.adl2.internode.on.net (HELO audi.shelbyville.oz) ([121.45.12.40]) by ipmail06.adl2.internode.on.net with ESMTP; 11 Jul 2012 14:19:05 +0930
Received: from localhost (localhost [127.0.0.1]) by audi.shelbyville.oz (Postfix) with ESMTP id 3B7784F8F3; Wed, 11 Jul 2012 14:19:04 +0930 (CST)
X-Virus-Scanned: Debian amavisd-new at audi.shelbyville.oz
Received: from audi.shelbyville.oz ([127.0.0.1]) by localhost (audi.shelbyville.oz [127.0.0.1]) (amavisd-new, port 10024) with LMTP id oKdbnMWqYBRg; Wed, 11 Jul 2012 14:19:03 +0930 (CST)
Received: by audi.shelbyville.oz (Postfix, from userid 1000) id 48FF94F8FE; Wed, 11 Jul 2012 14:19:03 +0930 (CST)
Date: Wed, 11 Jul 2012 14:19:03 +0930
From: Ron <ron@debian.org>
To: Jean-Marc Valin <jmvalin@mozilla.com>
Message-ID: <20120711044903.GK18009@audi.shelbyville.oz>
References: <20120705150704.14085.7364.idtracker@ietfa.amsl.com> <4FF5AEED.8080300@xiph.org> <4FFB851E.7040906@mozilla.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4FFB851E.7040906@mozilla.com>
User-Agent: Mutt/1.5.20 (2009-06-14)
Cc: codec@ietf.org
Subject: Re: [codec] Fwd: New Version Notification for draft-terriberry-oggopus-00.txt
X-BeenThere: codec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Codec WG <codec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/codec>, <mailto:codec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/codec>
List-Post: <mailto:codec@ietf.org>
List-Help: <mailto:codec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/codec>, <mailto:codec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 11 Jul 2012 04:48:52 -0000

On Mon, Jul 09, 2012 at 09:27:58PM -0400, Jean-Marc Valin wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> One thing we should explicitly mention in the draft is that a decoder
> MUST NOT reject a file because the header is longer than expected.
> This makes it possible to have a minor revision to the format that
> adds a field to the header. As an exception, if the decoder knows the
> exact length of header for the minor revision that the file uses, then
> it MAY reject it. Any thoughts?

I'm a bit uncomfortable with the idea of this header being "arbitrarily"
extensible without any clearly defined mechanism for encapsulating further
'backward compatible' extensions that allows at least some measure of
basic validation to be performed.

If my code recognises version 1 headers, and I get a version 2 header
that is several MB in size, should I really just blindly accept that
Nothing Is Wrong?

It also doesn't really seem ideal to be appending extra fields after
the variable length mapping table data anyway.


Since any extra fields added with a minor version change must necessarily
be optional, with correct decoder behaviour still occurring if they are
ignored, I see two possible angles we could look at this from.  One is
that such things be added to the comment header - which already defines
a mechanism for arbitrary additional fields.  The other would be to
define some more formal extension mechanism, and perhaps put the channel
mapping table into it as well.

I'm not really sure what things you envisage may be added in a minor
version bump though, which are important enough to add a field to the
header, but incidental enough that decoders might ignore them with no
ill effects.  So it's not quite clear to me yet what the best way to
go for this would be either.

We already have one mechanism for extra data that is optional, do we
actually need to have a second one?

 Cheers,
 Ron