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

Saúl Ibarra Corretgé <saul@ag-projects.com> Mon, 23 June 2014 07:21 UTC

Return-Path: <saul@ag-projects.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 896B41A0564 for <stox@ietfa.amsl.com>; Mon, 23 Jun 2014 00:21:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.711
X-Spam-Level: *
X-Spam-Status: No, score=1.711 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZKay_CsGngR5 for <stox@ietfa.amsl.com>; Mon, 23 Jun 2014 00:21:39 -0700 (PDT)
Received: from mail.sipthor.net (node16.dns-hosting.info [81.23.228.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6E79E1B29CB for <stox@ietf.org>; Mon, 23 Jun 2014 00:21:38 -0700 (PDT)
Received: from imac.saghul.lan (g154115.upc-g.chello.nl [80.57.154.115]) by mail.sipthor.net (Postfix) with ESMTPSA id 150D016DC6DE; Mon, 23 Jun 2014 09:21:35 +0200 (CEST)
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=iso-8859-1
From: =?iso-8859-1?Q?Sa=FAl_Ibarra_Corretg=E9?= <saul@ag-projects.com>
In-Reply-To: <538CAEF0.8060305@getjive.com>
Date: Mon, 23 Jun 2014 09:21:35 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <533D00BC-0988-4430-96ED-028381A951DF@ag-projects.com>
References: <537ABFA1.2080606@getjive.com> <CDAE759A-8174-46E6-8610-A37E554AB3FD@ag-projects.com> <53872C3C.7000007@stpeter.im> <538748BE.1050608@getjive.com> <538CAEF0.8060305@getjive.com>
To: Matt Ryan <mryan@getjive.com>
X-Mailer: Apple Mail (2.1085)
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/GDoST1r9fX3yqE5YkhknONmWIOU
Cc: stox@ietf.org, Peter Saint-Andre <stpeter@stpeter.im>
Subject: Re: [Stox] Communication between STOX-capable and non-STOX-capable entities
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, 23 Jun 2014 07:21:40 -0000

Hi Matt,

Sorry for the belated response.

On Jun 2, 2014, at 7:05 PM, Matt Ryan wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> 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.
> 

I need to go through the rest of the emails, but given that the heart of STOX is actual translation, I'm not sure if we need more working on that. It should be obvious since *that* is exactly what we are describing.


Cheers,

--
Saúl Ibarra Corretgé
AG Projects