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

Peter Saint-Andre - &yet <peter@andyet.net> Mon, 02 February 2015 16:59 UTC

Return-Path: <peter@andyet.net>
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 4B5EA1A8727 for <stox@ietfa.amsl.com>; Mon, 2 Feb 2015 08:59:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 5jdDyhQA_Yga for <stox@ietfa.amsl.com>; Mon, 2 Feb 2015 08:59:26 -0800 (PST)
Received: from mail-ig0-f174.google.com (mail-ig0-f174.google.com [209.85.213.174]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10B401A8724 for <stox@ietf.org>; Mon, 2 Feb 2015 08:59:26 -0800 (PST)
Received: by mail-ig0-f174.google.com with SMTP id b16so19756558igk.1 for <stox@ietf.org>; Mon, 02 Feb 2015 08:59:25 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=C2Q14A9E0rcB/uzPuqR/+gvelYzVZaRfzzN6H3QranM=; b=G63Il83+B06fXJmRAr+IRcOOqcVyWADK451QNDn5c8lElieyvf6wwCNQYFI8s/c69f bOApwEAaIguujPPzGYvB39y2y9vBJnwQAP4yu+usnQsGm96KFMHIMIiycNcaPvkh6iRs Gp5s3eaVuRhguID3LRZK06o2eAJx0jYob/evHcJu7+HEx40nRgk4z1D7ZfhWJfLdowWz D6pS++FihKbLRYro1dwnzM+82clNHpXO+LKXpm7RRwkZpRMHz2DfpY9kb4RdOOoxN7vl jisQ6uB9AwL/B4sefeWvKVn/xgKcqbtJjqKclRsAuv8WS1wnOK7QH+U4zArqohKz3P/U fedQ==
X-Gm-Message-State: ALoCoQk5FK8KG6dG6qimP+vZyGVEF4xGxR46Uw389BcRNXUmLIqQa57tPundWeNDt/B1AxZ/jd4T
X-Received: by 10.42.207.129 with SMTP id fy1mr19538013icb.17.1422896365458; Mon, 02 Feb 2015 08:59:25 -0800 (PST)
Received: from aither.local (c-73-34-202-214.hsd1.co.comcast.net. [73.34.202.214]) by mx.google.com with ESMTPSA id l15sm6124913iod.33.2015.02.02.08.59.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 02 Feb 2015 08:59:24 -0800 (PST)
Message-ID: <54CFACEA.1040304@andyet.net>
Date: Mon, 02 Feb 2015 09:59:22 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: Alissa Cooper <alissa@cooperw.in>, stox@ietf.org
References: <71D99F08-87C8-4E4A-9DC3-2DC3C2991B1B@cooperw.in>
In-Reply-To: <71D99F08-87C8-4E4A-9DC3-2DC3C2991B1B@cooperw.in>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/stox/s_teHyXeVSInD3-ZcPqtUH1mVlk>
Subject: Re: [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: Mon, 02 Feb 2015 16:59:28 -0000

On 1/31/15 5:10 PM, Alissa Cooper wrote:
> 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.

Yes, we changed them all around based on Ben Campbell's review and I 
recall making the modifications late at night, so it doesn't surprise me 
greatly that there are errors. Will review again.

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

+1

> = 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.

Great, thanks.

> = 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.

WFM.

> = 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.

Yes, we'll check all of these.

> = 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.

Yes.

> = 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”?

Perhaps that was a poor choice of words. In MSRP, the switch doesn't 
reflect the message because it is explicitly acknowledged (200 OK). In 
XMPP, the MUC room doesn't explicitly acknowledge receipt of groupchat 
messages.

I think it would be better for the switch + gateway to not generate the 
MSRP 200 OK until it receives the reflected message back from the MUC 
room. That is, move F45 after F47 and remove F48 & F49.

> Why does the MSRP gateway send it (F48 in the diagram)?

I suggest we remove F48 and F49.

> = 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?

Probably.

If we can ever finish the PRECIS work...

> "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?

I don't think that display name mappings are critical for interoperability.

> = 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.

Good catch.

>  Same goes for end-to-end security protections — some discussion is needed.

To my knowledge, end-to-end security protections do not exist for 
multiparty text chat in MSRP or XMPP MUC. It's a hard problem (even 
harder than the 1:1 cases for IM and chat).

> 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.

Yes, we'll note that.

Thanks again,

Peter

-- 
Peter Saint-Andre
https://andyet.com/