Re: [rtcweb] Comment on Straw Poll replies

Dave Crocker <dhc@dcrocker.net> Fri, 10 January 2014 19:20 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 A82471AE1B5 for <rtcweb@ietfa.amsl.com>; Fri, 10 Jan 2014 11:20:21 -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 7HoHr6FfH7Xe for <rtcweb@ietfa.amsl.com>; Fri, 10 Jan 2014 11:20:19 -0800 (PST)
Received: from sbh17.songbird.com (sbh17.songbird.com [72.52.113.17]) by ietfa.amsl.com (Postfix) with ESMTP id B69C61AE1BC for <rtcweb@ietf.org>; Fri, 10 Jan 2014 11:20:19 -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 s0AJK6SI016978 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rtcweb@ietf.org>; Fri, 10 Jan 2014 11:20:09 -0800
Message-ID: <52D04781.2030504@dcrocker.net>
Date: Fri, 10 Jan 2014 11:18:25 -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.2.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
References: <CAHp8n2kq+_uG=9XwoAGtRgqYU2Asc2Fv6RZ0aCW6cJi-LnhD+A@mail.gmail.com>
In-Reply-To: <CAHp8n2kq+_uG=9XwoAGtRgqYU2Asc2Fv6RZ0aCW6cJi-LnhD+A@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]); Fri, 10 Jan 2014 11:20:10 -0800 (PST)
Subject: Re: [rtcweb] Comment on Straw Poll replies
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: Fri, 10 Jan 2014 19:20:21 -0000

> if you want to restrict
> WebRTC to interoperability with old systems only and therefore to old
> features only?


My impression is that the above point could indicate a very basic  point 
of confusion amongst a number of participants.

The issue is the difference between minimal, guaranteed 
interoperability, versus maximum possible capabilities.

The statement seems to be concerned about permitting maximum 
capabilities, whereas Mandatory to Implement is usually for ensuring the 
first goal of basic interoperability.

That is, it seeks to ensure that any two participants can achieve basic, 
useful interoperation.  When there is a negotiation mechanism, that is 
the way to then get mutual agreement to do something more capable.

Whether to interoperate with legacy systems is a common, strategic 
decisions.  It is hugely important and often affects success of an effort.

On the average, Internet protocols have tended to try quite hard to 
permit interoperation with legacy systems, where possible.  This has 
often been a challenge, and often has slowed down adoption of newer 
features.  These hassles are balanced against getting a larger base of 
initial users more easily.

The problem with ignoring the installed base of legacy users is the 
danger that they will continue using their legacy services and not 
switch to the wonderful new service.  Creators of wonderful new services 
often underestimate the switching barrier that impedes those legacy users.

By contrast, defining things in a way that is friendly to legacy users, 
while permitting a negotiation path to higher capabilities, is often 
successful at seducing those users, over time, to try out the more 
capable features.

Unless I've entirely misunderstood the design of webRTC, the intent is 
(or can be and should be) to support basic, legacy interoperation, while 
permitting negotiation up to newer and more wonderful capabilities.

For that model, what's most important about the core MTI requirements is 
that they permit maximum degree of interoperability; where possible that 
should include legacy systems.

d/
-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net