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

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 10 Feb 2014 15:08:48 -0700

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.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 10 Feb 2014 17:11:20 -0700

> 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

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 11 Feb 2014 08:51:35 -0700

>     communication technology).

Pete, that text is now in draft-ietf-stox-core-10.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Pete Resnick <[email-masked]>
Date: Tue, 11 Feb 2014 10:44:02 -0600

That's fine.

pr

-- 
Pete Resnick<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - +1 (858)651-4478