Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs)

Adam Roach <adam@nostrum.com> Mon, 14 January 2013 17:05 UTC

Return-Path: <adam@nostrum.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C998F21F892C for <rtcweb@ietfa.amsl.com>; Mon, 14 Jan 2013 09:05:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.399
X-Spam-Level:
X-Spam-Status: No, score=-102.399 tagged_above=-999 required=5 tests=[AWL=0.201, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rvYFp3R3WS2c for <rtcweb@ietfa.amsl.com>; Mon, 14 Jan 2013 09:05:15 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3C71A21F8919 for <rtcweb@ietf.org>; Mon, 14 Jan 2013 09:05:15 -0800 (PST)
Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id r0EH5EiH090206 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 14 Jan 2013 11:05:14 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <50F43ACA.80206@nostrum.com>
Date: Mon, 14 Jan 2013 11:05:14 -0600
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: Roman Shpount <roman@telurix.com>
References: <50D2CC6A.4090500@ericsson.com> <6515_1357907583_50F0067F_6515_1738_1_2842AD9A45C83B44B57635FD4831E60A0747CC@PEXCVZYM14.corporate.adroot.infra.ftgroup> <BLU0-SMTP880A602A311CE05C9DC39FD0290@phx.gbl> <A26C56D5-C501-4823-8099-62AF7910B8A4@ntt-at.com> <580BEA5E3B99744AB1F5BFF5E9A3C67D16813E56EC@HE111648.emea1.cds.t-internal.com> <50F41D97.1030508@nostrum.com> <CAD5OKxtsWMfAV=K4sM+zLXoyVCgihwujH2gG9ziA5GuEtsU0sQ@mail.gmail.com>
In-Reply-To: <CAD5OKxtsWMfAV=K4sM+zLXoyVCgihwujH2gG9ziA5GuEtsU0sQ@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Consensus vs. Voting (was Re: Call for Consensus Regarding Selecting Recommended Audio Codecs)
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Jan 2013 17:05:15 -0000

On 1/14/13 09:21, Roman Shpount wrote:
> I know that I would sound like I am repeating myself, but my initial 
> argument was that in order to interoperate with majority of legacy HD 
> Audio deployments without transcoding WebRTC implementations SHOULD 
> support G.722. The main argument that I heard against this was that 
> interoperability with legacy is not a justification enough for a SHOULD.

And I think that's what this question turns on.

> So the only thing that we have to discuss here is if interop deserves 
> a SHOULD or should we just assume that implementers will do the right 
> thing.

I make no assumptions. I propose guidance.

> To be honest all I've heard so far (and unfortunately I realize that 
> this applies to some degree to my own argument) was that people feel 
> one way or the other, which is not very helpful in reaching consensus.

What has been directly posed is the following form: given the RFC 2119 
definition of "SHOULD" below, do you earnestly believe that support of 
G.722 actually warrants this level of specification:

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
    may exist valid reasons in particular circumstances to ignore a
    particular item, but the full implications must be understood and
    carefully weighed before choosing a different course.
...
    Imperatives of the type defined in this memo must be used with care
    and sparingly.  In particular, they MUST only be used where it is
    actually required for interoperation or to limit behavior which has
    potential for causing harm (e.g., limiting retransmisssions)  For
    example, they must not be used to try to impose a particular method
    on implementors where the method is not required for
    interoperability.


So far, no one has come forth and said anything equivalent to "yes, I 
believe that the severity implied by the RFC 2119 definition of 'SHOULD' 
is appropriate for G.722 (or AMR/AMR-WB) support."

I suspect the reason is that anyone who follows the passage I quote 
above with such a claim realizes that they'll look a little out of touch 
with reality by doing so.

/a