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

Peter Saint-Andre - &yet <peter@andyet.net> Thu, 06 November 2014 03:38 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 3A5CC1A02F1 for <stox@ietfa.amsl.com>; Wed, 5 Nov 2014 19:38:57 -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 P_cwLzqqouFu for <stox@ietfa.amsl.com>; Wed, 5 Nov 2014 19:38:54 -0800 (PST)
Received: from mail-ie0-f174.google.com (mail-ie0-f174.google.com [209.85.223.174]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A38851A0248 for <stox@ietf.org>; Wed, 5 Nov 2014 19:38:54 -0800 (PST)
Received: by mail-ie0-f174.google.com with SMTP id x19so2155545ier.33 for <stox@ietf.org>; Wed, 05 Nov 2014 19:38:54 -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 :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=oDc6BIlq9gFi4wBxcIsSYIU0bpJUOz/KfebIUKDOHMw=; b=S+O/HIPnDy16yvOeFkVsBOOiHLxxSmGo8KRu5YZ6uvhDefTtKff4M4qbLm409BbPVG W72Bl13TJN4pvBNKawHfpn09JSX1qfpGCRqVZWxSOoPjyX9l2NaFmx7osIHH/m3IqoDn t6Gvao8D9dekaVurUy2CPPWONzC4Z961vI0oVNT/leaa2C4tFPll2YJkSrDvRLAvsChG StgEnovTEKOiKffXWZd7YN5nFcJGXMCqqpACRygao6HZA/zvqJfhHEDjgyumY3xHslzZ OglDpl/8gLGerxF8/CbST6/9bKXsbz3UyLgZey4ge1sczjkLnIdEBefv1YtCYO4T7U9U YKHg==
X-Gm-Message-State: ALoCoQlRFNhPKFdO6aM3Uq6PgLc1wRftw8peMK3JDWNT81XQyv7z/sTGtuUt+G/ZJlJlvKmZA3Qf
X-Received: by 10.107.157.11 with SMTP id g11mr1642318ioe.5.1415245134050; Wed, 05 Nov 2014 19:38:54 -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 dy3sm2138048igb.1.2014.11.05.19.38.53 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 05 Nov 2014 19:38:53 -0800 (PST)
Message-ID: <545AED4C.8060503@andyet.net>
Date: Wed, 05 Nov 2014 20:38:52 -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>
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/777EfLVHLxb5vZLeEhltluGHDoY
Cc: stox@ietf.org
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: Thu, 06 Nov 2014 03:38:57 -0000

Hi Ben,

Thank you very much for the in-depth feedback. I'll carve out some time 
soon to review and reply (probably next week).

Peter

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