Re: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid)

Saúl Ibarra Corretgé <saul@ag-projects.com> Wed, 19 October 2011 21:54 UTC

Return-Path: <saul@ag-projects.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 5A8EB21F8B0C for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 14:54:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.688
X-Spam-Level:
X-Spam-Status: No, score=-1.688 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3]
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 hW4XipPion2R for <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 14:54:07 -0700 (PDT)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id A71EA21F84FB for <rtcweb@ietf.org>; Wed, 19 Oct 2011 14:54:06 -0700 (PDT)
Received: by mail.sipthor.net (Postfix, from userid 5001) id 3F8A0B01A2; Wed, 19 Oct 2011 23:54:05 +0200 (CEST)
Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 5FFC7B017D; Wed, 19 Oct 2011 23:54:04 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= <saul@ag-projects.com>
In-Reply-To: <2E239D6FCD033C4BAF15F386A979BF51159AA6@sonusinmail02.sonusnet.com>
Date: Wed, 19 Oct 2011 23:54:03 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <23CC8E74-8C17-4484-998B-2A7B66358B81@ag-projects.com>
References: <2E239D6FCD033C4BAF15F386A979BF511599F9@sonusinmail02.sonusnet.com><4E9E5D8D.6030707@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF51159A20@sonusinmail02.sonusnet.com> <CALiegfk+Ezaz2Y4kFkooSozJsDyZZWxqdpX=fec==PYzBHm-bw@mail.gmail.com> <2E239D6FCD033C4BAF15F386A979BF51159AA6@sonusinmail02.sonusnet.com>
To: Ravindran Parthasarathi <pravindran@sonusnet.com>
X-Mailer: Apple Mail (2.1084)
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC trapezoid)
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: Wed, 19 Oct 2011 21:54:07 -0000

Hi,

On Oct 19, 2011, at 11:39 PM, Ravindran Parthasarathi wrote:

> Inaki,
> 
> There are fundamentally two aspects in RTCWeb:
> 
> 1) (on-wire) protocol mechanism - How protocol is designed between RTCWeb client (browser) and RTCWeb server, RTCWeb client and RTCWeb client. The protocol design does not focus on RTCWeb client only but also in RTCWeb server because the protocol has to be implemented in both entities. IOW, it is not 20 lines of JavaScript but impact of RTCWeb server design has to be noted as well. Here IETF has significant role and it has to come up with best protocol design between RTCWeb entities.
> 
> 2) API design (JavaScript in browser) - Browser provides RTCWeb client framework and exposes its API as JavaScript and JavaScript is the language/script of choice for browsers. The interaction is between browser and JavaScript only. IMO, W3C plays the vital role in coming up with best API set and also, there is no on-wire stuff here. Here, the discussion focus is whether low level API or ROAP API or any other high level API. Of course, I have less experience in JavaScript based API design. Please note that I have designed and worked in protocol framework in other languages like C, TCL. 
> 

If point 2, the JS API is flexible enough there is no need for a new protocol design, we can reuse an existing one and use the JS API for the media layer. I've lost count on the number of times this has already been said, lets move on.

> My comment on "SIP over websocket is an overkill" is purely based on (on-wire) protocol mechanism and it is nothing do with API design. Irrespective of whether "SIP over websocket" is implemented in browser or in JavaScript or in other language, it is not the best protocol design. Hope this clarifies my stance.
> 

Nobody is advocating for SIP over WebSocket nor XMPP over PBTL (pigeon based transport layer), what some of us want is to let it up to the developers.

--
Saúl Ibarra Corretgé
AG Projects