Re: [rtcweb] Review request for RTCWeb standard signaling protocol

"Ravindran Parthasarathi" <pravindran@sonusnet.com> Wed, 19 October 2011 01:12 UTC

Return-Path: <pravindran@sonusnet.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 03A8021F869E for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 18:12:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.744
X-Spam-Level:
X-Spam-Status: No, score=-2.744 tagged_above=-999 required=5 tests=[AWL=-0.446, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ggMwOS-B4F-B for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 18:12:21 -0700 (PDT)
Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by ietfa.amsl.com (Postfix) with ESMTP id E36E321F84C1 for <rtcweb@ietf.org>; Tue, 18 Oct 2011 18:12:20 -0700 (PDT)
Received: from sonusmail07.sonusnet.com (sonusmail07.sonusnet.com [10.128.32.157]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id p9J1Cpjs005231; Tue, 18 Oct 2011 21:12:51 -0400
Received: from sonusinmail02.sonusnet.com ([10.70.51.30]) by sonusmail07.sonusnet.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 18 Oct 2011 21:12:14 -0400
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CC8DFC.1F79A1C0"
Date: Wed, 19 Oct 2011 06:42:07 +0530
Message-ID: <2E239D6FCD033C4BAF15F386A979BF511599FD@sonusinmail02.sonusnet.com>
In-Reply-To: <033458F56EC2A64E8D2D7B759FA3E7E703DBF6D4@sonusmail04.sonusnet.com>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [rtcweb] Review request for RTCWeb standard signaling protocol
Thread-Index: AcyN0FNRa8PK4bssTZKb604uAWGvqgAAmDyQAAa+WLA=
References: <2E239D6FCD033C4BAF15F386A979BF510F1367@sonusinmail02.sonusnet.com><4E8AC222.4050308@alvestrand.no><2E239D6FCD033C4BAF15F386A979BF510F14CE@sonusinmail02.sonusnet.com><CALiegf=ejF2kUC1m=74o9eprF1M8wYtgE-Crwa1x14rzDOf+gQ@mail.gmail.com><2E239D6FCD033C4BAF15F386A979BF510F14FD@sonusinmail02.sonusnet.com><393F1888-F834-4DAE-B6B1-1C5D35EE3292@phonefromhere.com><CAOg=WDcC9t2KhQUg0gDJ60gO_2mNyMv9HKt=otCdPDfj4TnoTg@mail.gmail.com><2E239D6FCD033C4BAF15F386A979BF510F152B@sonusinmail02.sonusnet.com><CABRok6mM7TfbLgGhoQvdRh1Kwoi5BhRweLcqWg7VZOFnaa8VOw@mail.gmail.com><2E239D6FCD033C4BAF15F386A979BF510F1532@sonusinmail02.sonusnet.com><CABRok6n33QK0Si1Y0kT7+U0zgAWsJ4d5GENK_KL-JPx5a4erYg@mail.gmail.com><2E239D6FCD033C4BAF15F386A979BF511598EE@sonusinmail02.sonusnet.com><665A16AB-AAD8-42B3-AC17-7E629EA2DE35@phonefromhere.com><2E239D6FCD033C4BAF15F386A979BF5115992E@sonusinmail02.sonusnet.com><CALiegfmrncjsLVSiWk0tEgzwB00YaBGiqj0SDf9JTm9p1ZNoVA@mail.gmail.com><0950F0E1-6E4B-407F-9563- 654AFE79 F64B@ag-pro jects.com><2E239D6FCD033C4BAF15F386A979BF51159994@sonusinmail02.sonusnet.com><1F2A2C70609D9E41844A2126145FC09804004302@HKGMBOXPRD22.polycom.com><033458F56EC2A64E8D2D7B759FA3E7E703DBF614@sonusmail04.sonusnet.com><8486C8728176924BAF5BDB2F7D7EEDDF3E091D13@ucolhp4d.easf.csd.disa.mil><2E239D6FCD033C4BAF15F386A979BF511599F3@sonusinmail02.sonusnet.com><CALiegfnyfrBHATQ3WThT7F_fpXePN8PFYW_MJMwK-6QUjzkknA@mail.gmail.com><CA+9kkMBa7RNzT3y_s+PgHZr9DTz-49WC8aEqmmZLt-eEYkBFnQ@mail.gmail.com> <033458F56EC2A64E8D2D7B759FA3E7E703DBF6D4@sonusmail04.sonusnet.com>
From: Ravindran Parthasarathi <pravindran@sonusnet.com>
To: "Asveren, Tolga" <tasveren@sonusnet.com>, Ted Hardie <ted.ietf@gmail.com>, Iñaki Baz Castillo <ibc@aliax.net>
X-OriginalArrivalTime: 19 Oct 2011 01:12:14.0951 (UTC) FILETIME=[233F0770:01CC8DFC]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol
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 01:12:28 -0000

Hi Tolga,

 

My basic doubt is how to you ensure jquery library does not have malware without understanding its detail functionality. AFAIK, Small Web developer test cycle is very different from exhaustive testing by OEM. 

 

In case your concern is related to browser compatibility for the specific service or RTCWeb compliant, it is unavoidable and it is based on my end-user browser experience. IETF-81 meetecho conference tool supports HTML5 which is not working in my browsers (IE8 in windows XP) and I forced to download Chrome to attend IETF RTCWeb session from remote. In fact I'm asking for standard because with having HTML5 sort of standard itself, I'm not getting update with few browsers and without any standard, none of the browsers (Chrome, Firefox) will support.

 

Based on the above, if you conclude that it is better for everybody to write signaling protocol and then it may apply to RTCWeb media protocol as well because it is not guaranteed that browser-x will be RTCWeb compliant at which release-y. I doubt whether I will get IE update for HTML5 or RTCWeb anytime soon without OS upgrade ;-). Of course, lot of Real-time web application is possible without RTCWeb browser using Jquery and plugins. Your proposal is to avoid plugin only and keep jquery as such but plugin may be preferred in case of custom build application wherein compressed RTP/RTCP is the focus.

 

 So, IMO standards may not help for the above scenarios. Wherein IETF standards helps for 

 

1)      Ensuring interop between RTCWeb client (browser which are compatible) and RTCWeb server for signaling,  RTCWeb client to RTCWeb client for media

2)      Comparatively easy RTCWeb application development in case framework of the standard signaling protocol exists in the RTCWeb client and RTCWeb server.

3)      I'm worried for the delay because every conference session from 512 kbps internet connection may take nearly 2 min to join the conference after I login.  The setup time matters because for every meeting, I have to login before 2 min :-(. 

4)      In case RTCWeb signaling is defined, RTCWeb signaling to legacy signaling  gateway will be available for low cost in terms of $ compare to the gateway which has to convert custom build.

5)      Also ensure that Novice RTCWeb developer does not use intellectual property of others (jquery library) without knowing in detail.

 

Also, Some of the usecase which are not well discussed in this forum is about RTCWeb usage with Enterprise, call center. I'm seeing RTCWeb as a next generation collaborative mechanism (web + VoIP) rather than just plugin removal WG.

 

Please note that I'm not talking about API because it is the programming environment and W3C stuff.

 

Thanks

Partha

 

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Asveren, Tolga
Sent: Wednesday, October 19, 2011 2:01 AM
To: Ted Hardie; Iñaki Baz Castillo
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol

 

Some opinions about the topics under discussion:

 

i- One difference between JS library and browser support is that service developer can choose the JS library they want to use (or develop their own). It is up to them to make sure that it works fine, does not have malicious behavior etc... If they don't do their homework, their service will fail. OTOH, service developer has no control over what is/will be supported in the browser, e.g. browser-X supporting forking only after release-Y. I also would expect that security requirement is more on the browser so that it does not let potentially malicious things to be done and this would be controlled by the enduser by its choice of browser.

 

ii- How big do we expect JS libraries to be? I think we assume that battery/bandwidth is not a showstopper for realtime communication so I would think JS library size would be a factor only if its ratio v.s. media is non-negligible.

 

Thanks,

Tolga

 

________________________________

From: rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] On Behalf Of Ted Hardie
Sent: Tuesday, October 18, 2011 3:59 PM
To: Iñaki Baz Castillo
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Review request for RTCWeb standard signaling protocol

 

On Tue, Oct 18, 2011 at 11:34 AM, Iñaki Baz Castillo <ibc@aliax.net> wrote:

	
	When RTCweb becomes a reality there will appear thousands of
	JavaScript libraries implementing different RTCweb signaling
	protocols, each one with its own features and capabilities. Do you
	understand that a website admin will be able to choose the one he
	prefers?


You make this sound like you believe this to be an advantage.  Having seen the bit-rot in quite a few libraries,  I'm less included to assume that every library created will be feature complete and well-maintained.  I'm equally leery of presuming that it is easy to chose among them.  Checking for embedded malware, to take a simple example, makes the task longer and more fraught with issues than you might suppose.
 

	Visit 100 random cool websites. Probably 50% of them use JQuery JS
	library. Does it mean that each web developer had to build his own JS
	library? not at all, they use JQuery.
	
	Now your reply will be "downloading the JS library everytime is not
	efficient". Ok, visit 100 random cool websites. Probably 50% of them
	use JQuery JS library. How many times have you downloaded the JQuery
	library (assuming that every site has its own copy of the .js)? ... 50
	times. Is that a problem? not for the rest of the humans in the world.


It's certainly less efficient and, given the majority of users now accessing the Internet via mobile devices which are power and bandwidth constrained, that sort of wastefulness should not be trivially dismissed.  I
 

	So please stop making up issues that don't exist. The WWW world does
	not work as you propose, and anyhow it has succeeded.

	 


You set up a strawman that you attempted to knock down.  He did not propose it, you did.  I also don't think you scored even a TKO on the strawman.  Again, please focus on your own points, 

thanks,

Ted Hardie
 

	
	
	--
	Iñaki Baz Castillo
	<ibc@aliax.net>

	_______________________________________________
	rtcweb mailing list
	rtcweb@ietf.org
	https://www.ietf.org/mailman/listinfo/rtcweb