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

Alissa Cooper <alissa@cooperw.in> Sun, 01 February 2015 00:10 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 C95F81A1B65 for <stox@ietfa.amsl.com>; Sat, 31 Jan 2015 16:10:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level:
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[BAYES_50=0.8, 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 xx3WsR1a_TnP for <stox@ietfa.amsl.com>; Sat, 31 Jan 2015 16:10:08 -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 9BA0E1A1B14 for <stox@ietf.org>; Sat, 31 Jan 2015 16:10:08 -0800 (PST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 15A55202A2 for <stox@ietf.org>; Sat, 31 Jan 2015 19:10:08 -0500 (EST)
Received: from frontend1 ([10.202.2.160]) by compute1.internal (MEProxy); Sat, 31 Jan 2015 19:10:08 -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=UUKhE+EBk42e6rnct W9Q0NlQt4s=; b=QRzQF9UmL8Gi0Fl6Mpwd1dGDNcgpFYv1WJmPMKPX+8u6URWZe zC3XnpCsiXipuiSwHQa6rYJ8PPBtFkztWR5Dj12ANeLTCAFcXMy+nhM2xH/ei1+k c1qzTIZorkirQ428XzPJElxN5A0piwrwciY6U+JT7//wyKeK+zl/bvGZLU=
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=UUKhE+EBk42e6rnctW9Q0NlQt4s=; b=Btv X4Qsic6D4DgMT29e9MraQxwP6uxOq7L7LtYjlJzD26+MV53YtAyrCYEuNqvxjidG /prPAGuZHfhL6NHdJKrdQCkpmhYmIVmKjhOIM81dXRRTpdasfkHJIjkBo/4gncsx j92M9Dn3NBF8K2Wldl4XXWW3f9LWI/FIBEMCmr5c=
X-Sasl-enc: eDpM7iW4cjAONpvkorUNz/IkGRIgzdoCJD5W6Er99Di/ 1422749407
Received: from sjc-alcoop-8817.cisco.com (unknown [128.107.239.233]) by mail.messagingengine.com (Postfix) with ESMTPA id 64C46C0028C for <stox@ietf.org>; Sat, 31 Jan 2015 19:10:07 -0500 (EST)
From: Alissa Cooper <alissa@cooperw.in>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
Message-Id: <71D99F08-87C8-4E4A-9DC3-2DC3C2991B1B@cooperw.in>
Date: Sat, 31 Jan 2015 16:10:07 -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/pxiDc9qJhGGsV5ducb3kvjJGQa8>
Subject: [Stox] AD evaluation: draft-ietf-stox-groupchat-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:10:11 -0000

I have reviewed this draft in preparation for IETF LC. I have a couple of comments/questions 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.

= Section 5 =
All of the flow labels as used in the text and the examples need to be checked against the labels in the diagram. I found a bunch of inconsistencies where the labels used in the text are not describing the right flows in the diagram (e.g., Example 20, all the labels in Section 5.8). This is sort of editorial but given that the spec is basically defined by the diagrams and examples, I think it needs to be fixed before IETF LC. It confused me quite a bit.

In fact, I would suggest checking every label in the document to make sure it corresponds to the appropriate diagramed flow.

= Section 5.1 =
"As specified in [RFC7247], the mapping of XMPP syntax elements to SIP
   and [RFC4566] syntax elements is as shown in the following table.”

This doesn’t seem quite right since RFC 7247 doesn’t actually provide the mapping of from->From and to->To — that’s what the table right here is doing. I would suggest that the text here follow the same pattern used in the -im draft, namely:

"The mapping of XMPP syntax to SIP syntax [MUST] be as shown in the following table.

Table 1: Message syntax mapping from XMPP to SIP/SDP

       +-----------------------------+-----------------------------+
       |  XMPP Element or Attribute  |  SIP Header or SDP Contents |
       +-----------------------------+-----------------------------+
       |  from                       |  From                       |
       |  to (without the /nick)     |  To                         |
       +-----------------------------+——————————————+

As shown in the foregoing example and described in [RFC7247], the
       XMPP-to-SIP gateway [MUST] map the bare JID
       ("localpart@domainpart") of the XMPP sender to the SIP From
       header and include the resourcepart of the full JID as the GRUU
       portion [RFC5627] of the SIP URI.”

Note that I’ve replaced the SHOULDs with MUSTs as explained in my comments on the -im draft.

= Section 5.4 =
OLD
The following table shows the syntax mapping from the RFC 4575
   payload to the XMPP participant list.

NEW
The syntax mappings from the RFC 4575
   payload to the XMPP participant list MUST be as shown in the following table.

OLD
The mapping of SIP and [RFC4575] payload syntax elements to XMPP
   syntax elements is as shown in the following table.

NEW
The mapping of SIP and [RFC4575] payload syntax elements to XMPP
   syntax elements MUST be as shown in the following table.

= Section 5.5 =
OLD
The mapping of XMPP syntax elements to MSRP syntax elements is as
   shown in the following table.

NEW
The mapping of XMPP syntax elements to MSRP syntax elements MUST be as
   shown in the following table.

= Section 6 =
As in Section 5, something is awry with the labels of the protocol flows in this section, both in the diagram and the examples that follow. I believe the first flow in the diagram, SIP INVITE from the SIP user to the SIP proxy, should be F35, not F33.

Then in 6.1 the SUBSCRIBE flow is listed in Example 29 as F40, but it should be F38 as in the diagram. From there, the flow numbers listed in the examples are all off by 1 or 2.

= Section 6.3 =
OLD
The mapping of MSRP syntax elements to XMPP syntax elements is as
   shown in the following table.

NEW
The mapping of MSRP syntax elements to XMPP syntax elements MUST be as
   shown in the following table.

= Section 6.3.1 =
Why does the SIP-to-XMPP gateway send an MSRP 200 OK back to the sender before seeing that the groupchat message has been reflected back? Doesn’t this give the sender the wrong impression in the event that a transport error causes the groupchat message to fail to reach the XMPP MUC?

"In MSRP this reflected message is unnecessary."

What does it mean for it to be “unnecessary”? Why does the MSRP gateway send it (F48 in the diagram)?

= Section 7 =
"Implementations are strongly encouraged to apply the
   rules for preparation and comparison of nicknames specified in
   [I-D.ietf-precis-nickname].”

draft-ietf-precis-nickname is listed as a normative reference. Should its use be a normative requirement?

"Therefore, for display purposes SIP implementations
   ought to use the <display-text/> element if the XCON 'nickname'
   attribute is not present, and XMPP implementations ought to use the
   resourcepart of the occupant JID if the <nick/> element is not
   present.”

Should these be normative requirements?

= Section 9 =

I don’t think it’s sufficient to refer to the security considerations of the underlying specifications.

This section omits discussion about whether the gateways needed for groupchat are expected to support the security requirements of the protocols they are gatewaying. The other two drafts address this point and it needs to be addressed here as well. Same goes for end-to-end security protections — some discussion is needed.

Also, many of the groupchat features that are left unspecified in this draft could be considered to be application security features: room administration, moderation, semi-anonymous rooms/anonymous participation, kicking and banning, etc. It seems at least worth mentioning that implementations supporting the feature set specified here cannot afford users with those features as they may be accustomed.


Editorial nits:

= Section 4 =
s/By contrast, in MSRP sessions/By contrast, in MSRP, sessions/

= Section 5.1 =
s/establising/establishing/

s/the that message (F7)./that message (F7)./

= Section 5.2 =
s/such “JuliC"/such as “JuliC”/

= Section 5.4 =
s/translate the participant list/translates the participant list/

= Section 5.6 =
s/the gateway might generate a new nickname request/the gateway might generate a new nickname request with a different nickname/

= Section 6.3.1 =
s/then generate and send/then generates and sends/