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

Peter Saint-Andre <stpeter@stpeter.im> Mon, 10 February 2014 22:08 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 3C10E1A0447; Mon, 10 Feb 2014 14:08:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
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 mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8oEImfb2ND7C; Mon, 10 Feb 2014 14:08:49 -0800 (PST)
Received: from stpeter.im (mailhost.stpeter.im []) by ietfa.amsl.com (Postfix) with ESMTP id 77CA91A089E; Mon, 10 Feb 2014 14:08:49 -0800 (PST)
Received: from aither.local (unknown []) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id DD2E3403BB; Mon, 10 Feb 2014 15:08:48 -0700 (MST)
Message-ID: <52F94DF0.1030505@stpeter.im>
Date: Mon, 10 Feb 2014 15:08:48 -0700
From: Peter Saint-Andre <stpeter@stpeter.im>
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 <iesg@ietf.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: stox@ietf.org
Subject: [Stox] Pete Resnick's IESG feedback on draft-ietf-stox-core
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox/>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 Feb 2014 22:08:52 -0000

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 Saint-Andre