Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for?

Iñaki Baz Castillo <> Fri, 21 October 2011 12:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 7FEAB21F8C45 for <>; Fri, 21 Oct 2011 05:41:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.633
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 3HNa8xRNf2P3 for <>; Fri, 21 Oct 2011 05:41:19 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E066921F8C3C for <>; Fri, 21 Oct 2011 05:41:18 -0700 (PDT)
Received: by vcbfo1 with SMTP id fo1so3942406vcb.31 for <>; Fri, 21 Oct 2011 05:41:18 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id a11mr14200655vdg.1.1319200878292; Fri, 21 Oct 2011 05:41:18 -0700 (PDT)
Received: by with HTTP; Fri, 21 Oct 2011 05:41:18 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Fri, 21 Oct 2011 14:41:18 +0200
Message-ID: <>
From: Iñaki Baz Castillo <>
To: Wolfgang Beck <>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [rtcweb] A plea for simplicity, marketability - and... who are we designing RTCWEB for?
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, 21 Oct 2011 12:41:19 -0000

2011/10/21 Wolfgang Beck <>:
> But as browsers can load JS on the fly,  user A could simply point her
> browser to Server B and use the same client as user B. Now all
> components at the signaling layer are provided by a single vendor and
> no standardized protocol is required. There is no loss of information
> as there are no protocol translators.

I agree with this approach, but it also leaves the door open (that's
important) to two different websites A and B implementing different
client-server protocols to interoperate in case they agree on another
protocol X between their servers and they build a protocol translator
in each side. That's up to them (like a custom federation).

This will be always possible but we cannot mandate or influence on it.
WWW will decide (as it always does). Time to time. The important point
here (IMHO) is to leave the door open for innovation, as much as
possible. WWW is untamable.

Iñaki Baz Castillo