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

Matt Ryan <> Mon, 02 June 2014 17:06 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 6E13A1A024D for <>; Mon, 2 Jun 2014 10:06:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rKoMUBiOxZJv for <>; Mon, 2 Jun 2014 10:05:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c03::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8BE4D1A023A for <>; Mon, 2 Jun 2014 10:05:59 -0700 (PDT)
Received: by with SMTP id tp5so4743014ieb.17 for <>; Mon, 02 Jun 2014 10:05:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=mail; h=message-id:date:from:organization:user-agent:mime-version:to:cc :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=paVYerg5pw7VolUFTPJ9ntq6RqAp33L6fxF/gZ8yD7o=; b=Vu4CG+VciIR7BryQq0GOSm0qdHO5g0HN9/4Yj0m/Aq0DInR5Pw+65fvWXWD2ExjtwU P/f19UlpnIlU/sxLPc5fLMzDK/xmBftf3xGlKH86yrouFo1/ChUmuiw61uaEk2r2lAgH g3KVeu2O8gP08y0yevp5vqtPj8eTaoHmPVnI4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:message-id:date:from:organization:user-agent :mime-version:to:cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=paVYerg5pw7VolUFTPJ9ntq6RqAp33L6fxF/gZ8yD7o=; b=GfAZUiJbP3MblReKZ4m+dPmCRSvkYnPkSNsa7VX45XYHlqQQS5+G36wV3lPH+OD70k ym8989h9aI8i5hE2dMXhXJ/cvLT9+wrSzM/AdlNuO53lJKCcnQiz2wZf4r9BX7IZDlpH 8QdwLzRfdAUQ74QiBnd28fgaxOfohrJ+U00T427pXA7+JiH0mqeZ3axQWupKlHbehrtM XGT6TXI+8qQboPi3pNuOCqqS1YFxB5oNN+ik70O75e90ApOBYRVm348KGMrYFRnF+E0Q i6t60vBwd/cYDHThrAxTgJzoitKbma4pJLQdyfIPKrP3RbOWulWZ3hM0sJpR4wAPqBqA 2xMQ==
X-Gm-Message-State: ALoCoQljzS7JVEY6Xuoh2HSC84/BH9IzIpQohJ0sxFbQK+rOUp2wEVgzGrSOb1WZZqjNEINfk3sS
X-Received: by with SMTP id om8mr9675163igb.49.1401728753943; Mon, 02 Jun 2014 10:05:53 -0700 (PDT)
Received: from [] ([]) by with ESMTPSA id q2sm6887143ign.2.2014. for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 02 Jun 2014 10:05:53 -0700 (PDT)
Message-ID: <>
Date: Mon, 02 Jun 2014 11:05:52 -0600
From: Matt Ryan <>
Organization: Jive Communications, Inc.
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
Cc: =?ISO-8859-1?Q?Sa=FAl_Ibarr?= =?ISO-8859-1?Q?a_Corretg=E9?= <>, Peter Saint-Andre <>
Subject: Re: [Stox] Communication between STOX-capable and non-STOX-capable entities
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: Mon, 02 Jun 2014 17:06:03 -0000

Hash: SHA512

Further comments in line.

On 5/29/14, 8:48 AM, Matt Ryan wrote:
> 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.

For simplicity's sake let me just enumerate my general suggestion
instead of separate review emails for each pertinent draft.  My
apologies for being indecisive.

I suggest the drafts contain some formal language indicating the
assumptions that should be followed on each side in order to emphasize
the interoperability point.

For example:
- - Given a server sending a message to another server with a different
protocol, the sending server doesn't know whether the receiving server
supports STOX, and interoperability is a goal, so there should be
language indicating that the server SHOULD (MUST?) support sender-side
translation of messages from one protocol to the other.
- - Because a receiving server might be receiving messages from a sender
that does not support STOX, the receiving server SHOULD support
destination-side translation of messages from one protocol to the other.

I believe this is in harmony both with RFC 7247 and the clarification
I received in answer to my question, and that such language would both
support and emphasize these two important points.

> 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.

I believe the discussion in a separate thread addresses this concern
for me, wherein we've talked about reworking the examples in the
drafts to not show the receiving-side gateway in the diagrams.

> 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
>>> 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.  |  mryan at getjive dot com
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools -
Comment: Using GnuPG with Thunderbird -