Re: [rtcweb] Regarding Federation Arguments
Harald Alvestrand <harald@alvestrand.no> Wed, 09 November 2011 12:37 UTC
Return-Path: <harald@alvestrand.no>
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 C94D821F8C75 for <rtcweb@ietfa.amsl.com>; Wed, 9 Nov 2011 04:37:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.553
X-Spam-Level:
X-Spam-Status: No, score=-110.553 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, 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 YxqteBfE2FyE for <rtcweb@ietfa.amsl.com>; Wed, 9 Nov 2011 04:37:48 -0800 (PST)
Received: from eikenes.alvestrand.no (eikenes.alvestrand.no [158.38.152.233]) by ietfa.amsl.com (Postfix) with ESMTP id 9603021F8B50 for <rtcweb@ietf.org>; Wed, 9 Nov 2011 04:37:48 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by eikenes.alvestrand.no (Postfix) with ESMTP id E822639E12B for <rtcweb@ietf.org>; Wed, 9 Nov 2011 13:37:47 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at eikenes.alvestrand.no
Received: from eikenes.alvestrand.no ([127.0.0.1]) by localhost (eikenes.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7MSGeftoVGOK for <rtcweb@ietf.org>; Wed, 9 Nov 2011 13:37:47 +0100 (CET)
Received: from hta-dell.lul.corp.google.com (62-20-124-50.customer.telia.com [62.20.124.50]) by eikenes.alvestrand.no (Postfix) with ESMTPS id 0134A39E04C for <rtcweb@ietf.org>; Wed, 9 Nov 2011 13:37:46 +0100 (CET)
Message-ID: <4EBA741A.1010307@alvestrand.no>
Date: Wed, 09 Nov 2011 13:37:46 +0100
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.23) Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <4EB26D22.5090000@ericsson.com>, <FA65A239-CC86-4AC3-8A5A-91B7701C3FB5@cisco.com> <BLU152-W488BAA56546BEA4D42B4C893DF0@phx.gbl>
In-Reply-To: <BLU152-W488BAA56546BEA4D42B4C893DF0@phx.gbl>
Content-Type: multipart/alternative; boundary="------------050800080602010106050203"
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 12:37:49 -0000
On 11/09/2011 01:28 AM, Bernard Aboba wrote: > [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 can we avoid using the term "domain" here? It's not used before this point. "inter-server" or "inter-entity" would do, since those words are already present. > protocols that support federation (SIP or XMPP) could be used to > enable inter-domain federation That needs to be "for example SIP or XMPP" - if people want to use something else, that's up to them. "Federation" is another term with lots of implied meanings that isn't otherwise used in the document. can we simply say "Existing protocols (for example SIP or XMPP) could be used between the servers"? > 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." Combined rephrase of the new language: "If the two Web servers are operated by different entities, the inter-server signalling mechanism needs to be agreed upon, either by standardization or by other means of agreement. Existing protocols (for example SIP or XMPP) could be used 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 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 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." I'm happy to use the longer paragraph if we can remove the words "domain" and "federation" from it; I think it says the same thing as what's already there, but if Cullen agrees with Bernard that the words are more easily interpreted than mine, let's switch. > > > > 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 might > implement SIP, and the servers would talk SIP to each other, and each > would 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." > > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb
- [rtcweb] Regarding Federation Arguments Magnus Westerlund
- Re: [rtcweb] Regarding Federation Arguments Iñaki Baz Castillo
- Re: [rtcweb] Regarding Federation Arguments Ravindran Parthasarathi
- Re: [rtcweb] Regarding Federation Arguments Iñaki Baz Castillo
- Re: [rtcweb] Regarding Federation Arguments Wolfgang Beck
- Re: [rtcweb] Regarding Federation Arguments Cullen Jennings
- Re: [rtcweb] Regarding Federation Arguments Bernard Aboba
- Re: [rtcweb] Regarding Federation Arguments Iñaki Baz Castillo
- Re: [rtcweb] RTCWEB is not SIP Erik Lagerway
- Re: [rtcweb] Regarding Federation Arguments Harald Alvestrand
- Re: [rtcweb] Regarding Federation Arguments Harald Alvestrand
- Re: [rtcweb] Regarding Federation Arguments Wolfgang Beck
- Re: [rtcweb] Regarding Federation Arguments Harald Alvestrand
- Re: [rtcweb] Regarding Federation Arguments Iñaki Baz Castillo
- Re: [rtcweb] Regarding Federation Arguments Ted Hardie
- Re: [rtcweb] Regarding Federation Arguments Ravindran, Parthasarathi
- Re: [rtcweb] Regarding Federation Arguments Iñaki Baz Castillo
- Re: [rtcweb] Regarding Federation Arguments Ravindran, Parthasarathi
- Re: [rtcweb] Regarding Federation Arguments Christer Holmberg
- Re: [rtcweb] RTCWEB is not SIP Bernard Aboba
- Re: [rtcweb] RTCWEB is not SIP Neil Stratford
- Re: [rtcweb] Regarding Federation Arguments Iñaki Baz Castillo
- Re: [rtcweb] Regarding Federation Arguments Iñaki Baz Castillo
- Re: [rtcweb] RTCWEB is not SIP Dan York
- Re: [rtcweb] Regarding Federation Arguments Christer Holmberg
- Re: [rtcweb] RTCWEB is not SIP Tim Panton