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>
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Comment on draft-ietf-rtcweb-overview-02 (Browser RTC
 trapezoid)
Precedence: list

Hi,

On Oct 19, 2011, at 11:39 PM, Ravindran Parthasarathi wrote:

> Inaki,
>=20
> There are fundamentally two aspects in RTCWeb:
>=20
> 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.
>=20
> 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.=20
>=20

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.
>=20

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=FAl Ibarra Corretg=E9
AG Projects