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

Harald Alvestrand <harald@alvestrand.no> Tue, 18 October 2011 18:29 UTC

Return-Path: <harald@alvestrand.no>
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 1BD2821F8BDB for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 11:29:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.419
X-Spam-Level:
X-Spam-Status: No, score=-110.419 tagged_above=-999 required=5 tests=[AWL=-0.120, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 yN83RSv6QOwS for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 11:29:20 -0700 (PDT)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 70D0621F8BBA for <rtcweb@ietf.org>; Tue, 18 Oct 2011 11:29:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id B842A39E151; Tue, 18 Oct 2011 20:29:19 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KT+IMS3JInwT; Tue, 18 Oct 2011 20:29:18 +0200 (CEST)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 841CE39E082; Tue, 18 Oct 2011 20:29:18 +0200 (CEST)
Message-ID: <4E9DC57E.3070102@alvestrand.no>
Date: Tue, 18 Oct 2011 20:29:18 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: Iñaki Baz Castillo <ibc@aliax.net>
References: <4E9D667A.2040703@alvestrand.no> <CAAJUQMhUh5XiFh8rpg=Xag_F_Vm5tuVE5yRnArxzcd6sXb-=Kw@mail.gmail.com> <4E9DBECC.6000206@alvestrand.no> <CALiegfmhbNh1cVYty7wsnWLd2ChZ5zm2JF8moKmSf7aRsKFRXg@mail.gmail.com>
In-Reply-To: <CALiegfmhbNh1cVYty7wsnWLd2ChZ5zm2JF8moKmSf7aRsKFRXg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
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: Tue, 18 Oct 2011 18:29:21 -0000

On 10/18/11 20:16, Iñaki Baz Castillo wrote:
> 2011/10/18 Harald Alvestrand<harald@alvestrand.no>:
>> 2) when there is only one web server, one of the browsers is Firefox and the
>> other one is Chrome, the JS needs to have a standard means of communication
>> with the browser. This means a standard.
>> I have explained in my long note why I think it makes sense to describe this
>> as a protocol.
> If that just involves communication between the JS and the browser
> than IMHO that's an API rather than a protocol.
> However, if such signaling between JS and the browser (the RTCweb
> stack) mantains state, then I could agree on naming it "protocol".
ROAP does.
> Anyhow, the point here is: are you advocating for having a default
> signaling protocol in-the-wire or not? It's a bit unclear from your
> first mail given the ammount of signaling fragments in the whole
> RTCweb picture.
>
I'm advocating a single protocol between the Javascript and the Web browser.

It's a viable option for some applications to run that protocol from one 
browser to the other browser over a mechanism of their choice; many 
applications will make other choices, including those who choose to 
implement SIP in Javascript.