Re: [rtcweb] Regarding Federation Arguments

Iñaki Baz Castillo <> Fri, 11 November 2011 16:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C2F3621F8A35 for <>; Fri, 11 Nov 2011 08:41:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.637
X-Spam-Status: No, score=-2.637 tagged_above=-999 required=5 tests=[AWL=0.039, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id kI0MlXxnv+VX for <>; Fri, 11 Nov 2011 08:41:12 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2FD5521F87FA for <>; Fri, 11 Nov 2011 08:41:12 -0800 (PST)
Received: by vcbfk1 with SMTP id fk1so4148202vcb.31 for <>; Fri, 11 Nov 2011 08:41:11 -0800 (PST)
MIME-Version: 1.0
Received: by with SMTP id ew10mr22162793vdb.7.1321029671622; Fri, 11 Nov 2011 08:41:11 -0800 (PST)
Received: by with HTTP; Fri, 11 Nov 2011 08:41:10 -0800 (PST)
Received: by with HTTP; Fri, 11 Nov 2011 08:41:10 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <>
Date: Fri, 11 Nov 2011 17:41:10 +0100
Message-ID: <>
From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= <>
To: "Ravindran, Parthasarathi" <>
Content-Type: multipart/alternative; boundary=20cf3071c69450981104b1783099
Cc: "" <>
Subject: Re: [rtcweb] Regarding Federation Arguments
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: Fri, 11 Nov 2011 16:41:12 -0000

El 11/11/2011 06:23, "Ravindran, Parthasarathi" <>
>  IMO, your Low (freedom) based level API

I've never proposed an API.

> and standard on-wire
> protocol are complementary because both serve two different purpose.
> Freedom based API helps to build SIP over websocket kind of application or
> Proprietary Facebook or Google based WebRTC mechanism.
> But standard on-wire (say ROAP over JSON) helps folks not to look into
> Protocol intricacies in the browser. It is very much possible to co-exist.
> I really don't where is your concern

This is the very same argument again. IMHO it is time for you to assume
that this WG has decided by consensus that there will be no standard
in-the-wire protocol in WebRTC, nor a suggested proposal by this WG.

IMHO the only reason for having a "standard" WebrTC signaling protocol is
to make a business for gateway vendors building "standard WebRTC-to-SIP
gateways". I cannot imagine other reasons. That is not a legitime argument
in a IETF specification.

Anyhow I will not discuss again about this subject. There is consensus.
Time to move on. Please spend your time in helping with open subjects
rather than trying to reopen the discussion about the standard protocol.