[Stox] Very belated review of draft-ietf-stox-groupchat-07

Ben Campbell <ben@nostrum.com> Tue, 04 November 2014 23:53 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 01E071A1A83 for <stox@ietfa.amsl.com>; Tue, 4 Nov 2014 15:53:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.494
X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.594] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Ad1XNNv63Gm3 for <stox@ietfa.amsl.com>; Tue, 4 Nov 2014 15:53:36 -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 57DC01A0394 for <stox@ietf.org>; Tue, 4 Nov 2014 15:53:36 -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 sA4NrYan006817 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 4 Nov 2014 17:53:35 -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 []
From: Ben Campbell <ben@nostrum.com>
Content-Type: text/plain; charset=us-ascii
X-Mao-Original-Outgoing-Id: 436838014.408434-038e0f674af6164c9f169a2798e772de
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 8.0 \(1990.1\))
Message-Id: <BD96791B-10FC-46BC-822C-AA978D95FF17@nostrum.com>
Date: Tue, 4 Nov 2014 17:53:34 -0600
To: draft-ietf-stox-groupchat.all@tools.ietf.org, stox@ietf.org
X-Mailer: Apple Mail (2.1990.1)
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/1SABTm0JzGLIP_Y833WOqCfhejU
Subject: [Stox] Very belated review of draft-ietf-stox-groupchat-07
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: Tue, 04 Nov 2014 23:53:39 -0000


First, let me say that groupchat-07 is a far better document than when I last reviewed it (I think that was 07.) This version cleans up most of the architectural confusion from the older version. It's so much more understandable, that I found some new (to me) issues ;-)  I apologize in advance if any of these have already been discussed and I missed it:

*** Major Issues:

-- Section 6: 

When Romeo (a SIP user) joins the capulet chatroom (an XMPP group chat), what prevents Romeo's client from bypassing his own SIP proxy and trying to directly find a SIP service at example.com? This is to some degree an RFC7247 issue, where we assume that a SIP server knows to send stuff through a SIP-XMPP gateway. The problem is, SIP doesn't actually require a UAC to route requests through it's own proxy.

Now, I recognize that in _practice_, the UAC will almost only route outbound requests through its own server for NAT traversal and/or authentication reasons(perhaps using the SIP outbound mechanism). But that's not a 3261 requirement. If this draft wants to assume that this will always happen, that's probably ok--but it should mention that explicitly, and perhaps mention that if SIP clients do not use outbound SIP services, this approach may not work. (Or alternately, the client itself needs to know to route things through gateways...)

Related Question: Is there a use case for when a SIP service does not have a gateway, and just sends SIP to a gateway at the XMPP domain? If so, that would not seem to need the assumption that a SIP client always uses an outbound proxy.

-- Also Section 6:

If I read things correctly, the actual joining of the MUC is a consequence of the SIP user subscribing to the conference event package. But that subscription is not normatively required for simple-chat implementations. The simple-chat draft only says that clients "typically" will do so. So unless you want to make a normative requirement for simple-chat clients to do so in order to work with stox-groupchat, you cannot depend on that subscription to trigger the presence interchange.

-- Section 9:

The draft says that it that it introduces no new security considerations. But there must be some assumptions about user identities, authentication and trust. These probably should have been in RFC7247, but I don't find them there on a quick scan.

*** Minor Issues:

-- general:

There's a fair amount of 2119 normative language that really repeats statements from the other protocols (SIP, MSRP, XMPP, etc.). Please consider avoiding 2119 language when talking about how one of those protocols works, unless you are creating some new requirement that doesn't already exist for that protocol.

-- section 2:

The draft lists MSPR (RFC 4975) as a groupchat related spec. It's really not; that should probably reference simple-chat. (It would make sense to add RFC4975 to the "We assume readers are familiar..." list.)

-- section 3 (and the flow diagrams)

You indicate that you will use the same diagram convention for SIP and MSRP traffic. I suggest you distinguish between the two; they are completely separate (if loosely related) protocols.

-- section 4, "... MSRP groupchat sessions are considered to be a type of media ..."

That's true for MSRP in _general_, not just for group chat.

-- Figure 1: I would not assume a direct app-specific connection or flow between the SIP proxy and the MSRP switch. It may exist, but it's equally valid that all such interactions would be intermediated by the focus.  (And it doesn't seem to be needed by anything else in this draft.)

-- Section 5:

It's worth mentioning that any SIP provisional responses have been left off for the sake of simplicity.

In F6, there should really be an MSRP SEND request that happens before the nickname request. RFC4975 requires an immediate SEND request by the active party. It can be empty if you aren't ready to send a real message yet.  (There might should be some guidance about not accidentally creating a privacy leak by sending a real message prior to setting a nickname.)

F28: There's work going on in SIPCORE to change the way REFER requests handle notifies (See draft-sparks-sipcore-refere-clarifications and draft-sparks-sipcore-refer-explicit-subscription). There probably don't need to block anything here, but it might be worth a footnote to say that, at the time of this writing, work is happening that might change this part of the flow.)

-- section 5.1, example 2:

It's unlikely that a SIP UAC is going to generate a gruu tag with a value as neat as "balcony". Unlike XMPP, SIP doesn't typically use human readable identifiers to distinguish devices (analogous to XMPP resources.) More likely that will be random string assigned by the registrar.  (It's not _wrong_ as stated, but it might mislead implementors.)

-- section 5.1, table 1:

Do I understand correctly that you could have more than one <thread/> element over the course of a MUC? For the SIP/MSRP user, the Call-ID will stay the same for the life of the session. Also, the call-id will be unique for each SIP participant; I assume that's not true for <thread/>.

-- Example 3:

The 200 has the From and To wrong. Responses do not swap the from and to from the original request. They should be identical to the original, with the possible exception of the "to" tag.  (I think this repeats throughout the draft.)

-- Example 8:

Inconsistent use of Allow header fields. I would probably leave them out except where required, but others may have other opinions.

-- section 5.4: first paragraph

First part of the paragraph seems to belong in 5.3. It might make sense to combined 5.3 and 5.4 into one section.

-- 5.5.2: Second Paragraph:

Maybe this paragraph should belong in the section about the original INVITE?

-- section 6, F42-44?

If the initial SEND in F42 was empty, would F44 and 45 still happen? Can F44 and F45 fail?

-- 6.1, paragraph before example 28:

What if the MSRP user never sets a nick at all?

6.3.1, last paragraph:

How do you determine "sameness" between stanzas in this context?

-- 7, 3rd paragraph: "In SIP, the nickname..."

s/SIP/" the SIP conference event package"

-- 7, 2nd to last paragraph:

I'm confused by this--I can see saying to display the contents of <display-text/> or the JID resource part if the respective xcon element or <nick/> element are not present, but this seems to suggest one should ignore them if they are present. Is that the intent?