Re: [Stox] Pete Resnick's IESG feedback on draft-ietf-stox-core

Peter Saint-Andre <> Tue, 11 February 2014 00:11 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id E9EAB1A060E; Mon, 10 Feb 2014 16:11:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YYWjF2pIzAM4; Mon, 10 Feb 2014 16:11:23 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 29C0C1A0626; Mon, 10 Feb 2014 16:11:22 -0800 (PST)
Received: from aither.local (unknown []) (Authenticated sender: stpeter) by (Postfix) with ESMTPSA id 42ED3403BB; Mon, 10 Feb 2014 17:11:22 -0700 (MST)
Message-ID: <>
Date: Mon, 10 Feb 2014 17:11:20 -0700
From: Peter Saint-Andre <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: The IESG <>
References: <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [Stox] Pete Resnick's IESG feedback on draft-ietf-stox-core
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 11 Feb 2014 00:11:31 -0000

On 2/10/14, 3:08 PM, Peter Saint-Andre wrote:
> Pete, you wrote:
>    Section 4 is (nicely) clear on the document architecturally
>    describing a gateway. However, traditionally a gateway is
>    transparent to the entity that communicates with it: When we
>    had SMTP-to-X.400 gateways, the gateway appeared as just another
>    SMTP system that noticed special qualities of the address and
>    then routed the messages appropriately.
> Your "traditionally" sounds like an SMTP phenomenon. In XMPP, we don't
> have intermediate transfer agents, and XMPP servers are designed to use
> add-on modules for additional functionality. So in the XMPP universe it
> makes sense for the operator of an XMPP service to install a module (in
> addition to the XMPP server) that performs the gateway function (we
> often call this a connection manager).
>    Section 5 describes
>    something a bit different. It's not clear that what section 5
>    describes actually is part of the gateway, but rather sounds
>    like a combined server which does failover between the
>    protocols. I don't think this is a showstopper, but it might
>    help implementers significantly if you described in section 5
>    *where* in the model this function occurs. Right now, it
>    sounds like the server itself does the addressing failover,
>    not the gateway.
> Yes, I see your point. This kind of thing is quite likely implementation
> specific (e.g., when the add-on XMPP-to-SIP gateway module gets
> configured into and trusted by the core XMPP server, it might get added
> into an event listener for core stanza delivery if an XMPP lookup fails
> for the remote domain). Let me look at what text might be useful here.

How is this for proposed text?

    Existing SIP and XMPP server implementations do not typically include
    the ability to communicate using the other technology (XMPP for SIP
    implementations, SIP for XMPP implementations).  One common
    architectural pattern is to associate a gateway with the core server
    implementation (e.g., in XMPP such a gateway might be called a
    "connection manager").  How exactly such a gateway interacts with the
    core server to complete tasks such as address lookups and
    communication with systems that use the other technology is a matter
    of implementation (e.g., the gateway might be an add-on module that
    is trusted by the core server to act as a fallback delivery mechanism
    if the remote domain does not support the server's native
    communication technology).


Peter Saint-Andre