Re: [codec] Last Call: <draft-ietf-codec-opus-12.txt> (Definition of the Opus Audio Codec) to Proposed Standard

Cullen Jennings <fluffy@iii.ca> Sun, 29 April 2012 19:07 UTC

Return-Path: <fluffy@iii.ca>
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 EF5AA21F85A1 for <codec@ietfa.amsl.com>; Sun, 29 Apr 2012 12:07:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.531
X-Spam-Level:
X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599]
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 8b5iIrzdIbBB for <codec@ietfa.amsl.com>; Sun, 29 Apr 2012 12:07:50 -0700 (PDT)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 719C721F8599 for <codec@ietf.org>; Sun, 29 Apr 2012 12:07:50 -0700 (PDT)
Received: from [192.168.4.100] (unknown [128.107.239.233]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id DC89322E253; Sun, 29 Apr 2012 15:07:43 -0400 (EDT)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset="us-ascii"
From: Cullen Jennings <fluffy@iii.ca>
In-Reply-To: <4F9D7073.5050303@xiph.org>
Date: Sun, 29 Apr 2012 13:07:41 -0600
Content-Transfer-Encoding: quoted-printable
Message-Id: <1F97A125-A0D2-4129-8179-30EA9F63588F@iii.ca>
References: <20120426202056.15659.50524.idtracker@ietfa.amsl.com> <4F99B829.8020400@digium.com> <970F145F-628A-43C3-92A4-B6600D0B083D@iii.ca> <4F9D7073.5050303@xiph.org>
To: "Timothy B. Terriberry" <tterribe@xiph.org>
X-Mailer: Apple Mail (2.1084)
Cc: codec@ietf.org
Subject: Re: [codec] Last Call: <draft-ietf-codec-opus-12.txt> (Definition of the Opus Audio Codec) to Proposed Standard
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: Sun, 29 Apr 2012 19:07:51 -0000

On Apr 29, 2012, at 10:46 AM, Timothy B. Terriberry wrote:

> Cullen Jennings wrote:
>> One suggestion on it ... I suspect it would be easier to get both the RTP
> > payload and storage format done quicker if they were separate into two drafts.
> > Clearly the payload needs to be done in PAYLOAD WG but folks might want to
> > ping the RAI and APPS ADs about where it makes sense to do the storage format
> > - might want to consider Apps for that.
> 
> This makes a lot of sense. For the storage format, RFC 3533 (Ogg) was done in transport, IIRC. But Apps might be better. Should we be targeting standards-track or informational for it?


The RTP payload needs to be standards track but for the storage format, I can't see much advantage of PS over Info and Info is typically faster but not a big deal either way. I really don't know where the best place to do it is because I suspect there are multiple places where it could be done. But in cases like this, I like to go ask the ADs what they want and then you don't have any later surprises and when people ask you why you choose X instead of Y, you can just tell them the ADs told you so and not have to spend time debating it.