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

Pete Resnick <> Tue, 11 February 2014 16:43 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 798CE1A0548; Tue, 11 Feb 2014 08:43:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.549
X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id o1ke0qzmWLcB; Tue, 11 Feb 2014 08:43:39 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 2639C1A01FD; Tue, 11 Feb 2014 08:43:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;;; q=dns/txt; s=qcdkim; t=1392137018; x=1423673018; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=XQnfIx/nJXe6PDjLb+SYZmpsCPymfxAcbEjWwruJEW8=; b=N7WX1FAcDn+XEOPZZSN70Cy7RBtjloWv+ZmOEYle7I4eXuPYlSaoU/OC hLZ3pFgT2v1cUIwmCaZExkpfiI8EKm5LFanJA8+MZ6EEz7qZQpIPYpjWv edRvUtuKBwOHCKDgMGHVqgsT8EN13budzu9jtv186na9PE+OCsS8HbCwl Y=;
X-IronPort-AV: E=McAfee;i="5400,1158,7345"; a="59222728"
Received: from unknown (HELO ([]) by with ESMTP; 11 Feb 2014 08:43:38 -0800
X-IronPort-AV: E=McAfee;i="5400,1158,7345"; a="616324885"
Received: from ([]) by with ESMTP/TLS/RC4-SHA; 11 Feb 2014 08:43:38 -0800
Received: from presnick-mac.local ( by ( with Microsoft SMTP Server (TLS) id; Tue, 11 Feb 2014 08:43:38 -0800
Message-ID: <>
Date: Tue, 11 Feb 2014 10:44:02 -0600
From: Pete Resnick <>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.7; en-US; rv: Gecko/20100630 Eudora/3.0.4
MIME-Version: 1.0
To: Peter Saint-Andre <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: []
Cc:, The IESG <>
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 16:43:41 -0000

That's fine.


On 2/11/14 9:51 AM, Peter Saint-Andre wrote:
> On 2/10/14, 5:11 PM, Peter Saint-Andre wrote:
>> 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).
> Pete, that text is now in draft-ietf-stox-core-10.
> Peter

Pete Resnick<>
Qualcomm Technologies, Inc. - +1 (858)651-4478