Re: [rtcweb] Regarding Federation Arguments

Bernard Aboba <bernard_aboba@hotmail.com> Wed, 09 November 2011 00:28 UTC

Return-Path: <bernard_aboba@hotmail.com>
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 BD8D221F8770 for <rtcweb@ietfa.amsl.com>; Tue, 8 Nov 2011 16:28:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.548
X-Spam-Level:
X-Spam-Status: No, score=-102.548 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
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 4a74O5GjAWST for <rtcweb@ietfa.amsl.com>; Tue, 8 Nov 2011 16:28:11 -0800 (PST)
Received: from blu0-omc4-s9.blu0.hotmail.com (blu0-omc4-s9.blu0.hotmail.com [65.55.111.148]) by ietfa.amsl.com (Postfix) with ESMTP id F298921F86C3 for <rtcweb@ietf.org>; Tue, 8 Nov 2011 16:28:10 -0800 (PST)
Received: from BLU152-W48 ([65.55.111.135]) by blu0-omc4-s9.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 8 Nov 2011 16:28:07 -0800
Message-ID: <BLU152-W488BAA56546BEA4D42B4C893DF0@phx.gbl>
Content-Type: multipart/alternative; boundary="_53d1fa37-6c09-465c-bf27-306fd7397392_"
X-Originating-IP: [131.107.0.94]
From: Bernard Aboba <bernard_aboba@hotmail.com>
To: fluffy@cisco.com, Magnus Westerlund <magnus.westerlund@ericsson.com>
Date: Tue, 08 Nov 2011 16:28:06 -0800
Importance: Normal
In-Reply-To: <FA65A239-CC86-4AC3-8A5A-91B7701C3FB5@cisco.com>
References: <4EB26D22.5090000@ericsson.com>, <FA65A239-CC86-4AC3-8A5A-91B7701C3FB5@cisco.com>
MIME-Version: 1.0
X-OriginalArrivalTime: 09 Nov 2011 00:28:07.0306 (UTC) FILETIME=[73CD36A0:01CC9E76]
Cc: rtcweb@ietf.org
Subject: Re: [rtcweb] Regarding Federation Arguments
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: Wed, 09 Nov 2011 00:28:11 -0000

[BA]  I don't understand that sentence either, partly because it's not clear to me what "this" refers to.  The previous sentence talks about "the signaling path needs to be agreed upon, either by standardization or by other means of agreement", but also talks about "their proprietary representation".  Is "this" referring to the former or the latter?   Here's a rewrite that makes more sense (at least to me):  "If the two Web servers are operated by different entities, the inter-domain signalling mechanism needs to be agreed upon, either by standardization or by other means of agreement.  Existing protocols that support federation (SIP or XMPP) could be used to enable inter-domain federation between servers, while either a standards-based or proprietary protocol could be used between the browser and the web server.  For example, if both domains implement SIP,  SIP could be used for inter-domain communication between servers, along with either a standardized signaling mechanism (e.g. SIP over Websockets) or a a proprietary signaling mechanism used between the application running in the browser and the web server.   Similarly, if both domains implement XMPP, XMPP couild be used for inter-domain communication between XMPP servers, with either a standardized signaling mechanism (e.g. XMPP over Websockets or BOSH) or a proprietary signaling mechanism used between the application running in the browser and the web server."   Cullen said: "I don't understand the meaning of the sentence 
 
This part is outside the scope of the RTCWEB standards suite.

I think we need to construct a solution that can work if domains want to federate with SIP - therefore this should be one our use cases. However, I think domain should be free to choose whatever they want to federate - it just needs to be possible to federate. I'd like to see this clarified."
  ============================================================== "If the two Web servers are operated by different entities, the
signalling path needs to be agreed upon, either by standardization or
by other means of agreement; for example, both servers mightimplement SIP, and the servers would talk SIP to each other, and eachwould translate between the SIP protocol and their proprietary
representation for sending to their application running in the
browser.This part is outside the scope of the RTCWEB standars
suite."