Re: [Stox] Communication between STOX-capable and non-STOX-capable entities

[Matt Ryan <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Saúl and Peter, thanks for your input on my question.

I agree that this is the approach we should take.  This direction is
supported by RFC 7427 (previously draft-ietf-stox-core) where the
responsibility for determining the format for communication and
translating if required is put upon the sending server and it's
accompanying gateway, and not upon the receiving server.

Because of this, I have further concerns with draft-ietf-stox-chat-06
as well as with draft-ietf-stox-groupchat-04.  I will enumerate these
each separately in their own review emails.  But in summary, the
concerns are that the examples given in these drafts show the gateways
on both sides of communication as being involved in exchanges where
they should not be required, and that showing the involvement of both
gateways gives the impression that both ARE required.

In other words, it does not emphasize the point that STOX-capable
servers must be able to communicate effectively with non-STOX-capable
servers, which it seems we agree is important.


On 5/29/14, 6:46 AM, Peter Saint-Andre wrote:
> On 5/28/14, 6:37 AM, Saúl Ibarra Corretgé wrote:
>> Hi Matt,
>> 
>> On May 20, 2014, at 4:36 AM, Matt Ryan wrote:
>> 
>>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512
>>> 
>>> Should a STOX-capable server be able to communicate with a 
>>> non-STOX-capable server, so long as the communication is 
>>> started by the STOX-capable server?  Is this among the current
>>>  goals of the WG?
>>> 
>>> Sorry if this has been covered - but this particular point 
>>> remains unclear to me despite numerous readings through 
>>> draft-ietf-stox-core and some of the other supporting drafts.
>>> 
>>> 
>>> Let me provide a simple example to explain what I mean.
>>> 
>>> Suppose an XMPP client initiates a chat to a user that happens
>>>  to be a SIP client user.  Per draft-ietf-stox-chat, this 
>>> request flows through the XMPP Server which determines that the
>>> message is targeted to a SIP user, and then invokes its own
>>> XMPP-to-SIP Gateway to translate the request to a SIP request
>>> and send that request on to the appropriate SIP server.
>>> 
>>> So far, the XMPP Server knows that the target user is a SIP 
>>> user, but does not know anything about the SIP Server 
>>> capabilities other than that it is (presumably) a SIP server. 
>>> Importantly, the XMPP Server does not know whether the SIP 
>>> Server also supports a SIP-to-XMPP gateway.
>>> 
>>> 
>>> This is where my question comes.  Given the described XMPP 
>>> Server with a corresponding XMPP-to-SIP gateway, is it meant to
>>> be the case that this XMPP Server should be able to communicate
>>> with any valid SIP server, so long as the conversation is
>>> initiated by the XMPP Server?
>>> 
>>> 
>>> This is an important point because it has direct impact on 
>>> several of our current drafts.
>>> 
>> 
>> The idea is that a STOX capable infrastructure is transparent to 
>> others. To the eyes of the world,  given domain, say example.com
>> has SRV records for SIP and XMPP. The fact that there is an
>> actual gateway handling the traffic and doing some translations
>> is a detail of that infrastructure. So a non-STOX server should
>> be able to communicate with a STOX server just fine.
> 
> +1
> 
> Peter
> 
> 

- -- 
Matt Ryan
Code Slinger  |  Jive Communications, Inc.
Jive.com  |  [e-mail]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - https://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQEcBAEBCgAGBQJTh0i5AAoJEPyFiw1u4O0cEKEIAIwOqkOX1Rv2OmYkPlaR1+iY
aX6I8FNVifLvLH8ejei0hSTZoPqLFIbuZwkrJCnNyBo2bV4xMFoL91nQnKNe4dFX
xbKzLEPuV++A2YswEA6kklpJOlxHvqJEaAaiixci4Z24ZYR1deyW0ZQzXGKvE8Kr
Fycvqyz/eGPEM+FuY4UQSRnqnjVVHXAGvUvl86C+XEqNdxY68EYBDSHf6VTxGczI
MdVRErTmgYgGB2vQvouALrq6DB6JccWEz8cVf1QAFkXwYe4yH/Z7Rz1l/dkgUXrb
5Mfn7MCIKFAFHNGJQPPNLp1wJziGZonMMYpaDC/dFiHVy+qRSD5dNLFajtgbzUE=
=fi5u
-----END PGP SIGNATURE-----