IETF Logo Mail Archive

Re: [rtcweb] Alternative decision process in RTCWeb

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

Return-Path: <dhc@dcrocker.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B730D1ADBCD for <rtcweb@ietfa.amsl.com>; Mon, 2 Dec 2013 11:41:35 -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 D6ClMkP63ap2 for <rtcweb@ietfa.amsl.com>; Mon, 2 Dec 2013 11:41:34 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id A49361AD72A for <rtcweb@ietf.org>; Mon, 2 Dec 2013 11:41:34 -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 rB2JfS6m018318 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 2 Dec 2013 11:41:31 -0800
Message-ID: <529CE233.5000002@dcrocker.net>
Date: Mon, 02 Dec 2013 11:40:35 -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>
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 11:41:31 -0800 (PST)
X-Mailman-Approved-At: Tue, 03 Dec 2013 08:35:01 -0800
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>, "rtcweb-chairs@tools.ietf.org" <rtcweb-chairs@tools.ietf.org>
Subject: Re: [rtcweb] Alternative decision process in RTCWeb
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: dcrocker@bbiw.net
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, 02 Dec 2013 19:41:35 -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

v2.27.8 | Report a Bug | By Email | System Status