Re: [rtcweb] Alternative decision process in RTCWeb

Dave Crocker <dhc@dcrocker.net> Mon, 02 December 2013 21:05 UTC

Return-Path: <dhc@dcrocker.net>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF9B91ADF6B for <ietf@ietfa.amsl.com>; Mon, 2 Dec 2013 13:05:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sB9qrXPc0Umt for <ietf@ietfa.amsl.com>; Mon, 2 Dec 2013 13:05:49 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id 55F4A1ADF68 for <ietf@ietf.org>; Mon, 2 Dec 2013 13:05:49 -0800 (PST)
Received: from [192.168.1.66] (76-218-9-215.lightspeed.sntcca.sbcglobal.net [76.218.9.215]) (authenticated bits=0) by sbh17.songbird.com (8.13.8/8.13.8) with ESMTP id rB2L5gPK020957 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Dec 2013 13:05:46 -0800
Message-ID: <529CF5F1.9000106@dcrocker.net>
Date: Mon, 02 Dec 2013 13:04:49 -0800
From: Dave Crocker <dhc@dcrocker.net>
Organization: Brandenburg InternetWorking
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Roberto Peon <grmocg@gmail.com>
Subject: Re: [rtcweb] Alternative decision process in RTCWeb
References: <DUB127-W23531D0E8B15570331DB51E0EE0@phx.gbl> <52974AA8.6080702@cisco.com> <1F79045E-8CD0-4C5D-9090-3E82853E62E9@nominum.com> <52976F56.4020706@dcrocker.net> <3CD78695-47AD-4CDF-B486-3949FFDC107B@nominum.com> <949EF20990823C4C85C18D59AA11AD8B0EF1B8@FR712WXCHMBA11.zeu.alcatel-lucent.com> <D45703FF-109A-4FFF-92E9-1CC7767C52F7@nominum.com> <CAP+FsNc=cGhOJNTwXY1z-5ZjisOOvX=EOYEf3htGXGcWRKBf6g@mail.gmail.com>
In-Reply-To: <CAP+FsNc=cGhOJNTwXY1z-5ZjisOOvX=EOYEf3htGXGcWRKBf6g@mail.gmail.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.0 (sbh17.songbird.com [72.52.113.66]); Mon, 02 Dec 2013 13:05:46 -0800 (PST)
Cc: IETF Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 02 Dec 2013 21:05:51 -0000

On 11/29/2013 12:22 AM, Roberto Peon wrote:
> The only reason to specify a must-implement is to increase interop; if
> mandating a codec does not increase the amount of interop, why do it?


If the base specification does not provide enough information for basic 
interoperability, what is the benefit in standardizing it?

An alternative that I believe has already been mentioned is to 
standardize /both/, but separately.

Under two different names, which then lets the market decide on whether 
either will succeed.

Letting the market decide amongst competing choices used to be something 
the IETF did more commonly.  One of the more colorful examples was SNMP 
vs. CMOT.

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net