Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing

Hadriel Kaplan <> Thu, 20 October 2011 04:43 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9B70311E8088 for <>; Wed, 19 Oct 2011 21:43:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.178
X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=-0.179, BAYES_00=-2.599, J_CHICKENPOX_53=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YyTtO7Zx6QOg for <>; Wed, 19 Oct 2011 21:43:25 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id BD90611E8082 for <>; Wed, 19 Oct 2011 21:43:25 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Thu, 20 Oct 2011 00:43:23 -0400
Received: from ([]) by ([]) with mapi id 14.01.0270.001; Thu, 20 Oct 2011 00:43:24 -0400
From: Hadriel Kaplan <>
To: Cullen Jennings <>
Thread-Topic: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing
Thread-Index: AQHMjuLM6kdbKMH90Eeuh1H9I7A1XA==
Date: Thu, 20 Oct 2011 04:43:22 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "<>" <>
Subject: Re: [rtcweb] My Opinion: Why I think a negotiating protocol is a Good Thing
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 20 Oct 2011 04:43:26 -0000

On Oct 19, 2011, at 8:46 PM, Cullen Jennings wrote:

> A third level of api that one could do - and I think Dan York, may have been arguing for this but I'm not sure - is and API where there is an DOM object that represent all the communications and in the implies case you just tell it who to connect to and it is done. Imagine if the HTML5 Video tag has something like rtc attribute of someone you wanted to communicate with and the browser set up a video session with them. For example: <video  rtc="" />. WIth this sort of API, JS could still be used to manipulate the dom object , add streams, pause them, get attributes etc. My read of folks involved was this sort of approach had been pretty much rejected this. 

Well I don't reject that - I reject that the browser has it hard-coded in.  I hope that some smart Javascript developer will create a library that enables something like what you describe.  But I think it's a role for a JS library.  Because in my opinion one of the enablers to success of the web as an application platform has been that the Browsers are relatively dumb really, and all the logic/smarts is in the code they execute from JS/Flash/whatever, because only the web-app knows what the web-app wants.  If we could have the Browser not involved in RTCWeb at all including not even doing media, I would argue in favor of that... and arguably RTCWeb would have never been created because there'd be nothing for us to have to standardize.  Obviously we have to involve the Browser for media+RTP, so now we're on our slippery-slope to standardized signaling.

> Like you, I care more about we have something that works and does not limit innovation.
> I don't really care about how we do it but I want it done soon not 5 years from now. I wrote up ROAP with JDR because I think that it splits the middle ground as is by far the most acceptable thing to people.

But clearly you do care how we do it - I mean we all care one way or another. :)
There's nothing wrong with that. None of us have a crystal ball about the right answer for this thing, and it's clearly not obvious or else we'd have broader agreement one way or another by now.

> Largely that is based on my feelings from the room after the last IETF. 

I get the feeling that this may be one of those rare (and exciting!) times in the IETF when the people who physically attend the IETF meetings are neither a majority of, nor a representative sample of, the people active on the mailing list.