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

Randell Jesup <> Fri, 21 October 2011 18:33 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9A4F721F8AFE for <>; Fri, 21 Oct 2011 11:33:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.537
X-Spam-Status: No, score=-2.537 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KpQ0dD-6RfxF for <>; Fri, 21 Oct 2011 11:33:38 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 26AD421F8AFC for <>; Fri, 21 Oct 2011 11:33:37 -0700 (PDT)
Received: from ([] helo=[]) by with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <>) id 1RHJuT-0000w0-3C for; Fri, 21 Oct 2011 13:33:37 -0500
Message-ID: <>
Date: Fri, 21 Oct 2011 14:28:53 -0400
From: Randell Jesup <>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
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 18:33:38 -0000

On 10/21/2011 8:25 AM, Wolfgang Beck wrote:
> At the layer of call signaling messages are ultimately exchanged
> between two JS clients running on browsers. If we have different JS
> clients here, we need a standardized protocol between them. With
> trapezoid interconnection, we can hide this to some extent by doing
> protocol translations between JS client A / RTCWEB Server A and Server
> B / JS client B. Some
> information will get lost in translation.
> 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.

This is the rough equivalent to saying "instead of exchanging email in a 
standard format, and letting people use whatever client/webmail-client 
they want to read it; if you want to read an email from a gmail user you 
should log into gmail using their interface; from an aol user log into 
AOL and their interface, etc.  Oh, and history, phonebooks, etc would 
all be separate."  Yes, it avoids standard 'federation' formats and 
conversions, but...

Randell Jesup