Return-Path: <HKaplan@acmepacket.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 9B70311E8088 for <rtcweb@ietfa.amsl.com>;
 Wed, 19 Oct 2011 21:43:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.178
X-Spam-Level: 
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com
 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyTtO7Zx6QOg for
 <rtcweb@ietfa.amsl.com>; Wed, 19 Oct 2011 21:43:25 -0700 (PDT)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by
 ietfa.amsl.com (Postfix) with ESMTP id BD90611E8082 for <rtcweb@ietf.org>;
 Wed, 19 Oct 2011 21:43:25 -0700 (PDT)
Received: from MAIL2.acmepacket.com (10.0.0.22) by etmail.acmepacket.com
 (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0;
 Thu, 20 Oct 2011 00:43:23 -0400
Received: from MAIL1.acmepacket.com ([169.254.1.230]) by Mail2.acmepacket.com
 ([169.254.2.157]) with mapi id 14.01.0270.001; Thu, 20 Oct 2011 00:43:24 -0400
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Cullen Jennings <fluffy@cisco.com>
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: <0665820D-D5CC-424C-A6D4-7ACA59783509@acmepacket.com>
References: <4E9D667A.2040703@alvestrand.no>
 <9B03E9E2-4376-465E-84F5-EDAC51390408@phonefromhere.com>
 <B5F4C6D1-3F54-4242-A89C-C2FC66AF8E7D@cisco.com>
 <570BDE5E-6EDC-4094-8DC0-094CEC3F12DF@acmepacket.com>
 <E44893DD4E290745BB608EB23FDDB7620DE659@008-AM1MPN1-043.mgdnok.nokia.com>
 <773FB266-721F-4C51-81A6-C01778BB68DF@cisco.com>
In-Reply-To: <773FB266-721F-4C51-81A6-C01778BB68DF@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [216.41.24.34]
Content-Type: text/plain; charset="us-ascii"
Content-ID: <2B7F66E6909E9C459E16C2D2A8337AFF@acmepacket.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
Cc: "<rtcweb@ietf.org>" <rtcweb@ietf.org>
Subject: Re: [rtcweb] My Opinion: Why I think a negotiating protocol is	a	Good
 Thing
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 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 b=
een arguing for this but I'm not sure - is and API where there is an DOM ob=
ject 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 h=
as something like rtc attribute of someone you wanted to communicate with a=
nd the browser set up a video session with them. For example: <video  rtc=
=3D"jingle:alice@example.com" />. 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 m=
uch rejected this.=20

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 ena=
bles something like what you describe.  But I think it's a role for a JS li=
brary.  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 real=
ly, and all the logic/smarts is in the code they execute from JS/Flash/what=
ever, because only the web-app knows what the web-app wants.  If we could h=
ave the Browser not involved in RTCWeb at all including not even doing medi=
a, I would argue in favor of that... and arguably RTCWeb would have never b=
een created because there'd be nothing for us to have to standardize.  Obvi=
ously we have to involve the Browser for media+RTP, so now we're on our sli=
ppery-slope to standardized signaling.


> Like you, I care more about we have something that works and does not lim=
it innovation.
> I don't really care about how we do it but I want it done soon not 5 year=
s from now. I wrote up ROAP with JDR because I think that it splits the mid=
dle 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 anothe=
r. :)
There's nothing wrong with that. None of us have a crystal ball about the r=
ight 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.=20

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 nei=
ther a majority of, nor a representative sample of, the people active on th=
e mailing list.

-hadriel