Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for?

Bernard Aboba <bernard_aboba@hotmail.com> Thu, 20 October 2011 14:32 UTC

Return-Path: <bernard_aboba@hotmail.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 E53D321F8B87 for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 07:32:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.995
X-Spam-Level:
X-Spam-Status: No, score=-101.995 tagged_above=-999 required=5 tests=[AWL=0.603, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i8Ax2qufi+Ua for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 07:32:21 -0700 (PDT)
Received: from blu0-omc4-s1.blu0.hotmail.com (blu0-omc4-s1.blu0.hotmail.com [65.55.111.140]) by ietfa.amsl.com (Postfix) with ESMTP id 39BEA21F8B7E for <rtcweb@ietf.org>; Thu, 20 Oct 2011 07:32:21 -0700 (PDT)
Received: from BLU152-W19 ([65.55.111.135]) by blu0-omc4-s1.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 20 Oct 2011 07:32:20 -0700
Message-ID: <BLU152-W19B31DA6C6DB2FE60FC51C93EB0@phx.gbl>
Content-Type: multipart/alternative; boundary="_84a87f6f-37b6-4732-80e5-86ca3b5e2a4d_"
X-Originating-IP: [24.17.217.162]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: <fluffy@cisco.com>
Date: Thu, 20 Oct 2011 07:32:20 -0700
Importance: Normal
In-Reply-To: <E857C96A-0E73-486F-BF23-36BA897B449C@cisco.com>
References: <9C8CA816-65FB-41A0-999C-4C43128CAAB4@danyork.org> <BLU152-W43CB8DACCEA54AA5558B2493EA0@phx.gbl>, <E857C96A-0E73-486F-BF23-36BA897B449C@cisco.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 20 Oct 2011 14:32:20.0798 (UTC) FILETIME=[135FB5E0:01CC8F35]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for?
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: Thu, 20 Oct 2011 14:32:22 -0000

No, I'm saying that *if* a developer remains within the "single origin" model, that a number of requirements for peer-to-peer operation do not apply. 

Also that the APIs should also enable media to be sent over a websocket to the "single origin" as well as a PeerConnection. 


> Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for?
> From: fluffy@cisco.com
> Date: Wed, 19 Oct 2011 20:13:25 -0600
> CC: rtcweb@ietf.org
> To: bernard_aboba@hotmail.com
> 
> 
> On Oct 19, 2011, at 12:39 PM, Bernard Aboba wrote:
> 
> > However, if we are opening the RANT queue, I do have a concern that relates to IETF RTCWEB.  And that is the number of dependencies that are piling up, even for simple scenarios.  Fundamentally, many of the issues we have been talking about arise from the need to support peer-to-peer media.  This is what drives the need for ICE (so recipient can authorize sending of media),  end-to-end security (e.g. to know/authorize where P2P media is going),  and to some extend DoS and congestion control functionality.   While I understand the need for P2P support, we do need to avoid imposing all of these dependencies in simple client/server scenarios.  For example, if all a developer wants to do is send media and signalling down a websocket, many of the concerns arising from P2P media evaporate.  When operating within the "single origin" model, it should be possible to maintain a very high degree of legacy interop, with no requirements for ICE, e2e security, etc.  
> 
> Bernard, let me just make sure I have this right. You are proposing all the voice and video going from browser A to browser B should be sent over TCP (via websockets) through the web server?
> 
>