Re: [rtcweb] Why are we asking the wrong questions?

Hadriel Kaplan <HKaplan@acmepacket.com> Thu, 20 October 2011 17:03 UTC

Return-Path: <HKaplan@acmepacket.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 C869A21F8BFE for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 10:03:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.472
X-Spam-Level:
X-Spam-Status: No, score=-2.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599]
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 f6cUQtm9VhaA for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 10:03:11 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by ietfa.amsl.com (Postfix) with ESMTP id 293FA21F8BBA for <rtcweb@ietf.org>; Thu, 20 Oct 2011 10:03:11 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 20 Oct 2011 13:03:02 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 20 Oct 2011 13:03:02 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Roman Shpount <roman@telurix.com>
Thread-Topic: [rtcweb] Why are we asking the wrong questions?
Thread-Index: AQHMj0ogLgat7UQ4sE6A6BZTtTU/lQ==
Date: Thu, 20 Oct 2011 17:03:01 +0000
Message-ID: <9794C359-45FC-430D-B2E0-4971441C834A@acmepacket.com>
References: <CAD5OKxvBMt_EDzPprGeFGGTPS0z3DXAz9YJPDqCwF6HKuPrpFg@mail.gmail.com>
In-Reply-To: <CAD5OKxvBMt_EDzPprGeFGGTPS0z3DXAz9YJPDqCwF6HKuPrpFg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.0.0.30]
Content-Type: text/plain; charset="iso-8859-1"
Content-ID: <DC4A3F4BD0C1954D99FA81316A63F942@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Why are we asking the wrong questions?
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 17:03:11 -0000

+1
Or rather, in memory of Dennis Ritchie: agree++

-hadriel


On Oct 20, 2011, at 11:16 AM, Roman Shpount wrote:

> I am sorry for another rant, but it is painful to watch the discussion on this list. We have a chance to create something great, but instead wasting our time discussing irrelevant topics.
> 
> First irrelevant topic is "We want something that will allow to setup a media call in 20 lines of JavaScript". If we are looking for something that will to do this using the right JavaScript library and web server components, then we will probably achieve this goal. If someone expects to create something that by adding code at the browser level and no web server cooperation will setup a call between two arbitrary browsers, then this is a fool's quest. To setup a call browsers will need a meet point on the public IP. On one hand we have hundred different ways to implement this using current technology using a JavaScript library and one or the other server component. On the other hand we have no standard protocol to implement a meet point (some might argue for SIP or XMPP) but they do too much and do not implement meet point functionality too well. If you want something extremely simple just put a tel (or sip where supported) URL in your HTML.
> 
> Second irrelevant topic is PSTN vs some future web technology. We should stop arguing about supporting or not supporting PSTN connectivity and tailoring to the needs of some future start up. It is not about PSTN. It is about supporting currently used call negotiation scenarios. RTC will need to support all the scenarios actively used right now. Ideally, it should be able to support future scenarios that we cannot support now due to offer/answer limitations. Deliberately disabling support for current applications is misguided not only from the point of view of interoperability, but from the point of view of disabling future applications.
> 
> As it was said numerous times on this list, there are quite a few examples of RTC applications currently being used on the web. Their main limitation is that they are using some sort of proprietary plugin to implement real time media connections. The goal of this group is to create a set of recommendations for standard implementation of this functionality. So the right question would be what is the minimal feature set that needs to be added to the browser which will allow web developers to create such applications. Adding convenience APIs or optional functionality can be done later. 
> _____________
> Roman Shpount
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb