Re: [rtcweb] How to multiplex between peers

Igor Faynberg <igor.faynberg@alcatel-lucent.com> Thu, 21 July 2011 03:34 UTC

Return-Path: <igor.faynberg@alcatel-lucent.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 530FC21F888A for <rtcweb@ietfa.amsl.com>; Wed, 20 Jul 2011 20:34:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
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 P1MUC+IdiZpw for <rtcweb@ietfa.amsl.com>; Wed, 20 Jul 2011 20:34:10 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id CA1D521F8877 for <rtcweb@ietf.org>; Wed, 20 Jul 2011 20:34:10 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p6L3Y9Sk001500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <rtcweb@ietf.org>; Wed, 20 Jul 2011 22:34:09 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p6L3Y9ip030290 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <rtcweb@ietf.org>; Wed, 20 Jul 2011 22:34:09 -0500
Received: from [135.244.34.25] (faynberg.lra.lucent.com [135.244.34.25]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p6L3Y85H026970; Wed, 20 Jul 2011 22:34:09 -0500 (CDT)
Message-ID: <4E279E30.40604@alcatel-lucent.com>
Date: Wed, 20 Jul 2011 23:34:08 -0400
From: Igor Faynberg <igor.faynberg@alcatel-lucent.com>
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4E259EAD.3060505@ericsson.com> <FAE78F7C-8C51-41C4-B3D7-6497396E12A5@cisco.com> <4E26C5CF.1080007@ericsson.com> <BLU152-W54BE1A03753680FF0094C4934C0@phx.gbl> <CAOJ7v-2kwiCipJSHmNT9GuGJJzEjPV-X00TLnf-LwbsJ1ADwDw@mail.gmail.com> <896BDC4C-849C-4553-89C8-7EFEF9FFEC6B@skype.net> <38DF8F00ABAB77498A75469448CB081B3AE69BEBC4@BE235.mail.lan> <DB9A2414-CE23-4F6E-811D-DEEBAF6E0280@csperkins.org> <03887CB7-98FE-47F0-ACEF-105B3E7917A6@skype.net>
In-Reply-To: <03887CB7-98FE-47F0-ACEF-105B3E7917A6@skype.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
Subject: Re: [rtcweb] How to multiplex between peers
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
Reply-To: igor.faynberg@alcatel-lucent.com
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: Thu, 21 Jul 2011 03:34:11 -0000

Maybe, at some point.

At the moment though I am not convinced that this is the right answer.  
It always looks easier to re-design everything, but this approach more 
often than not ends up in a standard (and implementations) full of 
bugs.  Looking at what has transpired in Transport (now RAI) in the past 
15 years, one would easily find examples.

I think the decision on whether to ignore backward compatibility ought 
to be made when there is an agreement on core use cases and it is 
understood that none of them would be broken by lack of backward 
compatibility.

(It is not at all that I am against re-design on principle.  Quite the 
opposite!  But I believe that re-design is the research issue; here, we 
write a standard, and a standard needs to take into account a plethora 
of issues that the research phase may and should ignore.)

Igor

On 7/20/2011 7:15 PM, Matthew Kaufman wrote:
> ...
>
> Could we confine the claims about breakage to only ones that are NOT backwards compatibility issues?
>
> ...