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

Saúl Ibarra Corretgé <saul@ag-projects.com> Thu, 20 October 2011 09:28 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 7477C21F8A71 for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 02:28:50 -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=[AWL=-0.000, 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 ynJqQdkUmAKc for <rtcweb@ietfa.amsl.com>; Thu, 20 Oct 2011 02:28:50 -0700 (PDT)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id B9DA621F8A6F for <rtcweb@ietf.org>; Thu, 20 Oct 2011 02:28:49 -0700 (PDT)
Received: by mail.sipthor.net (Postfix, from userid 5001) id 39077B01A4; Thu, 20 Oct 2011 11:28:48 +0200 (CEST)
Received: from [192.168.99.36] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 224E5B017D; Thu, 20 Oct 2011 11:28:47 +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: <4E9FD9DB.2040203@alvestrand.no>
Date: Thu, 20 Oct 2011 11:28:45 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <19858834-5692-4816-9CC8-1350D5627DAC@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> <23CC8E74-8C17-4484-998B-2A7B66358B81@ag-projects.com> <4E9FD9DB.2040203@alvestrand.no>
To: Harald Alvestrand <harald@alvestrand.no>
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: Thu, 20 Oct 2011 09:28:50 -0000

Hi Harald,

On Oct 20, 2011, at 10:20 AM, Harald Alvestrand wrote:

> On 10/19/11 23:54, Saúl Ibarra Corretgé wrote:
>> 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.
> I've lost count of the number of times you've said it, but I still don't agree.
> 
> I think we need ROAP as part of our API spec. That, too, has been repeated any number of times.
> 

Maybe I'm missing something here, but I didn't say we don't need ROAP as part of the API spec. I always spoke about the signaling plane, lets say the call control, not the media control. 

--
Saúl Ibarra Corretgé
AG Projects