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

Iñaki Baz Castillo <ibc@aliax.net> Tue, 18 October 2011 12:03 UTC

Return-Path: <ibc@aliax.net>
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 1C5E821F8B82 for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 05:03:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.633
X-Spam-Level:
X-Spam-Status: No, score=-2.633 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
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 VB4QfwZxApYL for <rtcweb@ietfa.amsl.com>; Tue, 18 Oct 2011 05:03:12 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id 7E89421F8B39 for <rtcweb@ietf.org>; Tue, 18 Oct 2011 05:03:12 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so494574vcb.31 for <rtcweb@ietf.org>; Tue, 18 Oct 2011 05:03:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.52.73.166 with SMTP id m6mr2047907vdv.18.1318939391908; Tue, 18 Oct 2011 05:03:11 -0700 (PDT)
Received: by 10.220.118.143 with HTTP; Tue, 18 Oct 2011 05:03:11 -0700 (PDT)
In-Reply-To: <4E9D667A.2040703@alvestrand.no>
References: <4E9D667A.2040703@alvestrand.no>
Date: Tue, 18 Oct 2011 14:03:11 +0200
Message-ID: <CALiegfmSR-_-swh_YiV9jH9V2iOpkjwhoJAdVwT0phkWbnCHZg@mail.gmail.com>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <ibc@aliax.net>
To: Harald Alvestrand <harald@alvestrand.no>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 12:03:13 -0000

2011/10/18 Harald Alvestrand <harald@alvestrand.no>;:
> There’s the need for one browser to communicate with the other browser, and
> if the intermediate components are to have the ability to ignore the
> details, what’s communicated has to be treated like a blob - something
> passed out of one browser’s API and into another browser’s API, unchanged by
> the application - because the application must be able to ignore the
> details.
>
> OK, now we have the API with blobs. We also have to make some assumptions
> about how those blobs are transported, who’s responsible for acting on them,
> and so on. And we have to make sure different browsers implement the blob
> the same way - that is, it has to be standardized.

Is not that covered win ROAP draft? AFAIK ROAP defines how the SDP are
communicated from the JS to the RTCweb stack and viceversa.


> What’s more - we DO want to enable applications that are NOT simple.
> Including gateways, which are not browsers. So applications must be free to
> look inside the blob - break the blob boundary - when they need to. So this
> pulls in the same direction as the need for interoperability - the format,
> semantics and handling rules for these blobs has to be specified.

Of course they must be specificied, but do you mean that such
specification must be a single one?



In order to understand what you are proposing let me ask a question:

I use SIP over WebSocket, I just need RTCweb API's to be defined. Does
your proposal mean that I won't be able to use SIP over WebSocket and
instead I must use some specific protocol between the JS client and
the server? I hope the answer is not...



Regards.


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