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