Re: [rtcweb] Regarding Federation Arguments

Wolfgang Beck <> Thu, 03 November 2011 15:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A93AF11E80D2 for <>; Thu, 3 Nov 2011 08:38:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.779
X-Spam-Status: No, score=-2.779 tagged_above=-999 required=5 tests=[AWL=-0.102, 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 W+SNOxgJSdAE for <>; Thu, 3 Nov 2011 08:38:31 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8CD1311E80CD for <>; Thu, 3 Nov 2011 08:38:31 -0700 (PDT)
Received: by faas12 with SMTP id s12so2022658faa.31 for <>; Thu, 03 Nov 2011 08:38:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=n2gKFdLXcKy2JHXUOsVV6EgcABM/OalShhMi4ywBmXk=; b=QXnC7g0EuyPwI4zlc92TMUhlDsVBZ0MGZ6FS5fUjRSKSCVu/CKOWEr7sCp7GZw4+oj J4ijOt+57UfkY5wB3fTaBWIJLdL7QiACDbS0Wlvq0BG+FYYqcdRtRgLVKfZEJvDdPNuz 0uB5cTHMEAjNSK7LsjoxYvKNz+lO7rr3upArc=
MIME-Version: 1.0
Received: by with SMTP id c14mr16911014fai.3.1320334528643; Thu, 03 Nov 2011 08:35:28 -0700 (PDT)
Received: by with HTTP; Thu, 3 Nov 2011 08:35:28 -0700 (PDT)
In-Reply-To: <>
References: <> <> <>
Date: Thu, 3 Nov 2011 16:35:28 +0100
Message-ID: <>
From: Wolfgang Beck <>
To: =?ISO-8859-1?Q?I=F1aki_Baz_Castillo?= <>
Content-Type: text/plain; charset=ISO-8859-1
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: Thu, 03 Nov 2011 15:38:32 -0000

The trapezoid federation model has important drawbacks:

- The server-to-server protocol can be too simple: if it doesn't cover
you requirements, you have to wait for standardization. If your
requirement is too specific, it will never be standardized.

- The server-to-server protocol can be too complex: your application
may not need feature x of the protocol (eg forking,
early media), but your software still has to support the complexities
associated with it.

The server-to-server protocol determines the complexity of the server
or JS client. You can let the server translate the server-to-server
protocol into something simpler or let the JS client deal with it. But
you can't escape
the protocol's complexity.

- The server-to-server protocol can even be too simple *and* too
complex at the same time: you don't need feature x's complexities, but
you desperately need feature z. Which is not covered by the standard.

- If there are many providers, the number of server-to-server
relationships -- which are trust relationships -- become unmanageable.
It's quite possible that hubs will emerge to which smaller providers
connect. The hub needs to see all signaling traffic. We're not talking
about a tightly controlled hub in a walled garden, but about Internet
giants who have a commercial interest in profiling user behavior.

Of course, identity providers in the model described in
draft-beck-rtcweb-alt-ic-00 can profile their users, too. They get
less information, though. With client certificates, only the called
RTCWEB provider knows about a call.

Wolfgang Beck