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

[Pete Resnick <[e-mail]>]

That's fine.

pr

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<http://www.qualcomm.com/~presnick/>
Qualcomm Technologies, Inc. - [phone]