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

Peter Saint-Andre - &yet <peter@andyet.net> Sat, 15 November 2014 02:20 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 C8A4E1A0687 for <stox@ietfa.amsl.com>; Fri, 14 Nov 2014 18:20:36 -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 zOJ3URHPQJiP for <stox@ietfa.amsl.com>; Fri, 14 Nov 2014 18:20:32 -0800 (PST)
Received: from mail-ig0-f180.google.com (mail-ig0-f180.google.com [209.85.213.180]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E272A1A03B3 for <stox@ietf.org>; Fri, 14 Nov 2014 18:20:31 -0800 (PST)
Received: by mail-ig0-f180.google.com with SMTP id h15so2544070igd.7 for <stox@ietf.org>; Fri, 14 Nov 2014 18:20:31 -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=l2Vkg0n6giagQRAj2Ei15huMiFN0etvKZfpnaBtduKQ=; b=L3jZTxyg9UOzAVHrZ2XQcYEUZZS6Ff8bQfxrqtB9G6NTecfb5mqV4vsoFU1deXlz9N auOhI+QfWWBFpnbv7ZeQjU1Wokdsk/YG0UeXXGIXC2w3Zqb4i71U/soczXI67dfz0g5w dLVtXD7MXD+HfcCUsxa68JqOD7xYvJBlX3PDpJ1p2yhx042px7J7Llj4Lzu62+3EsGuv NhRGhSOHHkhAjxpBArHMtTRVm2I7k2al9B26pUswns9aRerVZ4B74F9tUwKx/S5bZKwl +VfpXsWK6T2pMFJyDbZ/we4T7uKUpZovEAj+6HXi4uPRNsNUom7VE+bzJ2PopOZfA4XR hpxg==
X-Gm-Message-State: ALoCoQkYSRHs89wfAJn1TsM+ZwdOGtZv7q5gpl0oO1OnyILrsZQQNGifQBe1VY3nakcAeQ2bkYES
X-Received: by 10.107.28.131 with SMTP id c125mr14240465ioc.29.1416018031261; Fri, 14 Nov 2014 18:20:31 -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 au2sm2233708igc.4.2014.11.14.18.20.29 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 14 Nov 2014 18:20:30 -0800 (PST)
Message-ID: <5466B86C.5090004@andyet.net>
Date: Fri, 14 Nov 2014 19:20:28 -0700
From: Peter Saint-Andre - &yet <peter@andyet.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>, draft-ietf-stox-groupchat.all@tools.ietf.org, stox@ietf.org
References: <BD96791B-10FC-46BC-822C-AA978D95FF17@nostrum.com>
In-Reply-To: <BD96791B-10FC-46BC-822C-AA978D95FF17@nostrum.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: http://mailarchive.ietf.org/arch/msg/stox/kVRxtd9bJrDFqfWOwZ6BN6SQdJU
Subject: Re: [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: Sat, 15 Nov 2014 02:20:37 -0000

Hi Ben, thanks for the review. Comments inline.

On 11/4/14, 4:53 PM, Ben Campbell wrote:
> Hi,
>
> First, let me say that groupchat-07 is a far better document than
> when I last reviewed it

I'm happy to hear 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 ;-)

It happens. :-)

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

Yes, I can see that. (This document clearly reflects the fact that I 
don't know SIP as well as I know XMPP.)

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

I think it's really just a simplifying assumption for this document 
(e.g., it's not easy to illustrate every possible deployment 
architecture or communication path). But I agree with you that we need 
to make this explicit.

> and perhaps mention that if SIP clients do not use
> outbound SIP services, this approach may not work.

Good point.

> (Or alternately,
> the client itself needs to know to route things through gateways...)

That seems unlikely in practice, especially if an end user would need to 
configure the SIP UA with a gateway address.

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

Again as a simplifying assumption, we've described the gateways as 
components that are associated with the sending domain (thus a SIP 
service would have a SIP-to-XMPP gateway for outbound traffic, and an 
XMPP service would have an XMPP-to-SIP gateway for outbound traffic). 
But nothing prevents services from having inbound gateways and in 
practice some services do host such gateways. As you say, this is really 
an RFC 7247 issue. (Sometimes I want to go back and revise both RFC 7247 
and RFC 7248!)

However, it does seem that we might want to make this crystal clear in 
this document.

> If so, that would not seem to need the assumption that a SIP client
> always uses an outbound proxy.

Right.

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

Hmm, this is a bit of a conundrum.

I had indeed noticed the "typically" language in simple-chat. And I 
certainly don't want to place a normative requirement on simple-chat 
implementations. On the other hand, in XMPP multi-user chat what the 
client does is best mapped to a subscription construct. The mapping 
document under consideration could be worded better, but the way I see 
it the XMPP-to-SIP gateway needs to send a conference event package 
subscription only if it wants to receive presence notifications back 
from the MSRP switch (Sections 5.3 & 5.4). And similarly in the other 
direction (Sections 6.1 & 6.2).

It's not clear to me how either side would be able to receive presence 
notifications without such a subscription, and those notifications are 
quite helpful in the context of a groupchat channel. But I don't think 
they are absolutely required.

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

Would you mind expanding on those points a bit more deeply?

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

Good point, we'll scrub the text in that regard.

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

Agreed.

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

In the diagrams we use separate conventions:

       Legend:
           . = XMPP
           % = MSRP
           * = SIP
           & = app-specific

So we'll fix that text.

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

True. Will adjust.

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

I suppose that by "app-specific" we meant that it's not standardized 
(any particular implementation could use whatever method it deems best).

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

Ah, I thought we'd added that. Will fix.

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

Will fix.

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

Noted.

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

In XMPP we've moved away from these human-readable identiers, too. Will 
adjust or at least add a note.

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

In practice, the <thread/> element is not used heavily in XMPP 
groupchat, mostly because no one has ever figured out a good user 
experience for multiple threads in a conference. However, that doesn't 
change the fact that the current text is misleading. Will fix.

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

Probably a generalized misunderstanding or copy-and-paste error. Will fix.

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

It seems OK to remove them.

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

Probably, yes.

> -- 5.5.2: Second Paragraph:
>
> Maybe this paragraph should belong in the section about the original
> INVITE?

This seems like a fine place for it, but I'll take a second look.

> -- section 6, F42-44?
>
> If the initial SEND in F42 was empty, would F44 and 45 still happen?
> Can F44 and F45 fail?

What do you mean by "empty"? Is this a bodiless request, or a request 
with an empty body?

> -- 6.1, paragraph before example 28:
>
> What if the MSRP user never sets a nick at all?

Hmm, good point. Instituting a timeout doesn't seem optimal. Will 
reconsider.

> 6.3.1, last paragraph:
>
> How do you determine "sameness" between stanzas in this context?

Good question! I would say that, in this context, the stanza is "the 
same" if the XML elements in the payload match those from the outbound 
stanza that the MSRP-to-XMPP gateway generated from the MSRP SEND 
request. (There might be more elements, such as delayed delivery 
elements added by the MUC service, but matching the elements from the 
outbound stanza might work well, as long as the gateway matches only on 
stanzas received from the MSRP user's occupant JID.) I think we can 
describe this in a helpful manner (alternatively we could drop this 
behavior).

> -- 7, 3rd paragraph: "In SIP, the nickname..."
>
> s/SIP/" the SIP conference event package"

Correct.

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

Right, the text should say "if present" in both cases.

Thanks again for the helpful and thorough review!

Peter

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