[Stox] review: stox-im-03

Salvatore Loreto <salvatore.loreto@ericsson.com> Fri, 20 September 2013 10:42 UTC

Return-Path: <salvatore.loreto@ericsson.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id CF52A21F92DA for <stox@ietfa.amsl.com>; Fri, 20 Sep 2013 03:42:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.626
X-Spam-Status: No, score=-102.626 tagged_above=-999 required=5 tests=[AWL=-0.898, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_MLH_Stock1=0.87, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id poguzo-+Tu-F for <stox@ietfa.amsl.com>; Fri, 20 Sep 2013 03:42:27 -0700 (PDT)
Received: from sesbmg20.ericsson.net (sesbmg20.ericsson.net []) by ietfa.amsl.com (Postfix) with ESMTP id CEEA621F92CD for <stox@ietf.org>; Fri, 20 Sep 2013 03:42:26 -0700 (PDT)
X-AuditID: c1b4fb38-b7fcf8e0000062b8-4d-523c26918e51
Received: from ESESSHC006.ericsson.se (Unknown_Domain []) by sesbmg20.ericsson.net (Symantec Mail Security) with SMTP id C3.6C.25272.1962C325; Fri, 20 Sep 2013 12:42:25 +0200 (CEST)
Received: from mail.lmf.ericsson.se ( by smtp.internal.ericsson.com ( with Microsoft SMTP Server id 14.2.328.9; Fri, 20 Sep 2013 12:42:25 +0200
Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se []) by mail.lmf.ericsson.se (Postfix) with ESMTP id 3E8D81102E6 for <stox@ietf.org>; Fri, 20 Sep 2013 13:42:25 +0300 (EEST)
Received: from nomadiclab.lmf.ericsson.se (localhost []) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 2191F55D8C for <stox@ietf.org>; Fri, 20 Sep 2013 13:42:18 +0300 (EEST)
Received: from Salvatore-Loretos-MacBook-Pro.local (localhost []) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D451255B07 for <stox@ietf.org>; Fri, 20 Sep 2013 13:42:17 +0300 (EEST)
Message-ID: <523C2690.6090306@ericsson.com>
Date: Fri, 20 Sep 2013 13:42:24 +0300
From: Salvatore Loreto <salvatore.loreto@ericsson.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: <stox@ietf.org>
References: <523C17B9.2070408@ericsson.com>
In-Reply-To: <523C17B9.2070408@ericsson.com>
Content-Type: multipart/alternative; boundary="------------080702040708090707010406"
X-Virus-Scanned: ClamAV using ClamSMTP
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrJLMWRmVeSWpSXmKPExsUyM+Jvje5ENZsgg5sLTSz+72hidWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRsMa04K9UhVPj61hb2BcJdLFyMkhIWAiMWvzFnYIW0ziwr31 bF2MXBxCAkcZJQ5d3wLlbGCUWLFpBTuEc5FR4t2WZUwQziFGiVldb1khnNOMEic3LmMFGcYr oC1x4eptZhCbRUBVom/yNbA4m4CZxPOHW8DiogLJEk2X77NA1AtKnJz5BMwWERCWaD7/jhHE FhaQlljzZxJYrxDQzHVfTwHZHBycAjoSHxdEg4SZBcIkTv09ywTxg5rE1XObmCHKtSR6z3Yy TWAUnoVkwywkLRC2rcSFOdeh4vIS29/OYYawdSUu/J+CIr6AkW0VI0dxanFSbrqRwSZGYPAf 3PLbYgfj5b82hxilOViUxHm36J0JFBJITyxJzU5NLUgtii8qzUktPsTIxMEp1cCY8ia/MqjE dj/TRVYuua+7Yl6xhTuxJtyfmB1jf0FAJdOr0lVdrePp8y42T80oJTejGd7rDIM2Mv0MvPuu 1vXulOt3m4vWbZ5xa3tK4rMQHelnrhxyZrN3zLstP/XUwcwD2w31ZPu3tJXd8dfde/zb5rkn onQsjGxm7xXzYQmXfDDDeaHHrB4lluKMREMt5qLiRABGXutmTAIAAA==
Subject: [Stox] review: stox-im-03
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.12
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: Fri, 20 Sep 2013 10:42:32 -0000

I have reviewed the core-04 draft, and I think that is almost ready for 
the WGLC

my only comments is about the fact that section 3. XMPP to SIP
implies that the MESSAGE is always (and maybe can only be) delivered 
over a TCP connection;
RFC3428 states

    Whenever possible, MESSAGE requests SHOULD be sent over transports
    that implement end-to-end congestion control, such as TCP or SCTP.
    However, SIP does not provide a mechanism to prevent a downstream hop
    from sending a request over UDP.

so you can delivery it over UDP as well and that has also being raised 
in a previous thread
while talking on the Call-ID mapping to <thread/>.
Actually you will be forced to deliver over UDP if the SIMPLE server 
only supports UDP.

So I would suggest to change

    Here we assume that the XMPP server has
    determined the foreign domain is serviced by a SIMPLE server,


    Here we assume that the XMPP server has
    determined the foreign domain is serviced by a SIMPLE TCP server,

best regards

Salvatore Loreto, PhD