[Stox] AD evaluation: draft-ietf-stox-chat-08

Alissa Cooper <alissa@cooperw.in> Sun, 01 February 2015 00:09 UTC

Return-Path: <alissa@cooperw.in>
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 CF4251A6FDB for <stox@ietfa.amsl.com>; Sat, 31 Jan 2015 16:09:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
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 YscYxrsPYin5 for <stox@ietfa.amsl.com>; Sat, 31 Jan 2015 16:09:29 -0800 (PST)
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4305F1A1BE0 for <stox@ietf.org>; Sat, 31 Jan 2015 16:09:29 -0800 (PST)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id AB1B720746 for <stox@ietf.org>; Sat, 31 Jan 2015 19:09:28 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute5.internal (MEProxy); Sat, 31 Jan 2015 19:09:28 -0500
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=cooperw.in; h= x-sasl-enc:from:content-type:content-transfer-encoding:subject :message-id:date:to:mime-version; s=mesmtp; bh=3KWpQBDb1KPKBOwKG IiFgRTUX3o=; b=tEU3KNJ4Go8qbg/0cR64UQpJ0Mw5ogHFarrf+AhKiQ9pFsCez PmAiEy5tiD0p9Hhv+0f1Rfybrfsi+CCdHLKQxVJ4MFfwHBsvsZ37FXUIfnXPO9Ps UEnX8LLf2/9z7xk1XIbd78SfqaP+FLhJoKnHMEQ2X7tOYxD2FPqhkb6r1w=
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=x-sasl-enc:from:content-type :content-transfer-encoding:subject:message-id:date:to :mime-version; s=smtpout; bh=3KWpQBDb1KPKBOwKGIiFgRTUX3o=; b=Z4H FkLvVanfg3me51Dy/AoVT4s3aNffRmva4zM5rELe7Xvxemb/DDohKBHS9aGzFnMH 2XuiCcU6EZrWiwlhDEctUGg4cq4OQssNXlco4C0epLy6eKcIOkeoevUc48yPNWnL SjoXrTxhH1oOOmK/oWUy47VPX5TwJwj8mDoH4tYw=
X-Sasl-enc: RT30y7CyFj3N31TV4SBJj0Q1MKxkO4oVXXDPPtkNm/Xh 1422749368
Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.239.233]) by mail.messagingengine.com (Postfix) with ESMTPA id 1EC7AC0028C for <stox@ietf.org>; Sat, 31 Jan 2015 19:09:27 -0500 (EST)
From: Alissa Cooper <alissa@cooperw.in>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: quoted-printable
Message-Id: <0C205FB7-2C6B-4773-830F-B8354CC65A75@cooperw.in>
Date: Sat, 31 Jan 2015 16:09:28 -0800
To: stox@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
X-Mailer: Apple Mail (2.1878.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/UBVx5gPsQXxtr--ffc2MlxInWQE>
Subject: [Stox] AD evaluation: draft-ietf-stox-chat-08
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: Sun, 01 Feb 2015 00:09:31 -0000

I have reviewed this draft in preparation for IETF LC. Overall the document appears in good shape. I have a couple of comments/questions regarding normative requirements that I’d like to discuss before issuing the LC. I’ve also included some editorial nits that should be addressed together with any LC comments.

Comments/questions:

= Sections 4 and 5 =
Same comment as on the -im document: To achieve minimal interoperability, I think the syntax mappings in these sections need to be MUST-level requirements rather than SHOULD. Or, if there are cases envisioned in which different implementations might map the elements differently, those should be explained. But I assume there are not.

= Section 7 =
Is all of the delivery report behavior meant to be entirely optional to support, or should there be some normative requirements listed in this section?


Editorial nits:

= General =
If GRUUs are generally not human-readable in use, I would suggest changing them to random identifiers throughout the examples in this document.

= Section 4 =
"The XMPP-to-SIP gateway at the XMPP server would then initiate an
   MSRP session with Romeo on Juliet's behalf (since there is no
   reliable way for the gateway to determine if Romeo's client supports
   MSRP, it simply needs to guess).”

“Guessing” makes it sound like the gateway might use heuristics or some such to determine whether to initiate an MSRP session, and that in some cases it might not initiate a session. Would it be more accurate to say that MSRP session initiation may yield an error since there is no reliable way for the gateway to determine if Romeo's client supports MSRP?

= Section 6.1 =
s/can server/can serve/