[Stox] Comments on stox-chat-09

Ben Campbell <ben@nostrum.com> Mon, 09 February 2015 23:00 UTC

Return-Path: <ben@nostrum.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 320BF1A8A52 for <stox@ietfa.amsl.com>; Mon, 9 Feb 2015 15:00:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id rH9gzOYBD7-e for <stox@ietfa.amsl.com>; Mon, 9 Feb 2015 14:59:56 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EB4951A8A62 for <stox@ietf.org>; Mon, 9 Feb 2015 14:59:55 -0800 (PST)
Received: from [] (cpe-173-172-146-58.tx.res.rr.com []) (authenticated bits=0) by nostrum.com (8.14.9/8.14.7) with ESMTP id t19Mxp31012193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 9 Feb 2015 16:59:52 -0600 (CST) (envelope-from ben@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host cpe-173-172-146-58.tx.res.rr.com [] claimed to be []
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: Ben Campbell <ben@nostrum.com>
Date: Mon, 9 Feb 2015 16:59:51 -0600
X-Mao-Original-Outgoing-Id: 445215591.266508-f0a7063290d4221cd99565945634a552
Content-Transfer-Encoding: quoted-printable
Message-Id: <10EF4B6B-A78E-4714-8E0F-84B985456266@nostrum.com>
To: Peter Saint-Andre - &yet <peter@andyet.net>, Alissa Cooper <alissa@cooperw.in>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/DombDMrsq2AsBUVJeXHrQgeEsoY>
Cc: stox@ietf.org
Subject: [Stox] Comments on stox-chat-09
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, 09 Feb 2015 23:00:03 -0000

(Resending to include STOX list)
(No hats yet)

Hi Peter and Alissa,

I've looked over draft-ietf-stox-chat-09. It looks mostly good, but there are still a few issues.




MSRP Failure-Report headers:

The examples assume the MSRP Failure-Report header field is set to no. It's missing from the first SEND, but explicitly set to no in the rest. The responses to SEND requests are left off throughout. This is allowed, but non-default behavior for MSRP. If the intent is to set Failure-Report: no, it would be good to say a few words about it. If the intent is to leave that to the implementation, then I would expect the examples to follow the defaults.

SIP Response From/To:

The SIP responses swap the From and To from the associated requests. This is not correct, To and From of a SIP response matches the To and From of the original request. (More to the point, the To and From in a response do not change to indicate the direction of the response message.) I note that the groupchat draft had this issue at one point, but it's been fixed.

Session Termination

I would like to see a little more prominent discussion about when the XMPP side might terminate a session. It's mentioned in the "Composing" section, but that seems to bury an important concept. I note both primary examples show the SIP side terminating the session--it would be nice to see one of those examples let the XMPP side do it.  (Is the "gone" composing state the only way this would happen?)


CSeq is missing from most SIP requests, except oddly for BYE requests. (And note that the CSeq of a BYE, sent by the peer that initiated the INVITE, would never be "1")

Security Considerations, last sentence:

The text non-normatively "suggests" the use of RFC3862 for end-to-end protection. That seems to want to have it both ways (non-normative and recommended) . I suggest either making that normative, or reducing the strength to say RFC3862 could be used for this purpose. (I realize we do this all the time with "ought to", but it seems like we need a sharper line for something like e2e crypto.)