Re: [Stox] Extended WGLC for draft-ietf-stox-groupchat-04 [was: WGLC for draft-ietf-stox-groupchat-04]

Peter Saint-Andre <stpeter@stpeter.im> Tue, 27 May 2014 23:47 UTC

Return-Path: <stpeter@stpeter.im>
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 E76091A07C7 for <stox@ietfa.amsl.com>; Tue, 27 May 2014 16:47:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.953
X-Spam-Level:
X-Spam-Status: No, score=-1.953 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_18=0.6, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, 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 Q5Ovp2GWCPFS for <stox@ietfa.amsl.com>; Tue, 27 May 2014 16:47:20 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id B6A931A0309 for <stox@ietf.org>; Tue, 27 May 2014 16:47:20 -0700 (PDT)
Received: from aither.local (unknown [24.8.184.175]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 447B740C58; Tue, 27 May 2014 17:47:13 -0600 (MDT)
Message-ID: <53852400.2070704@stpeter.im>
Date: Tue, 27 May 2014 17:47:12 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.5.0
MIME-Version: 1.0
To: Ben Campbell <ben@nostrum.com>, Yana Stamcheva <yana@jitsi.org>, draft-ietf-stox-groupchat.all@tools.ietf.org
References: <0E1BD27E-E0B5-4B61-8451-5B3ED8B649A2@jitsi.org> <DA536B73-D11A-40AD-901B-1428BC7376E1@jitsi.org> <5C094162-79EC-47AA-8861-1DC2F19E96E8@nostrum.com>
In-Reply-To: <5C094162-79EC-47AA-8861-1DC2F19E96E8@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/lg4RfrhWZlBWEmYwkTpviM-ITbQ
Cc: stox@ietf.org
Subject: Re: [Stox] Extended WGLC for draft-ietf-stox-groupchat-04 [was: WGLC for draft-ietf-stox-groupchat-04]
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, 27 May 2014 23:47:23 -0000

Hi Ben, thanks for the feedback! Comments inline.

On 5/2/14, 2:44 PM, Ben Campbell wrote:
> Hi,
>
> Here's some belated comments:
>
> General:
>
> I strongly suggest this be reviewed by one or both of the authors of
> draft-ietf-simple-chat, if it hasn't been already.

Agreed. I've asked both Geir and Aki to take a look, and I've pinged Sal 
about asking Miguel since they work together.

> Conceptually it looks good. But I see some issues with the SIP
> interaction. It may be that I am confused by the two-gateway model,
> but you have a number of transactions where the SIP responses do not
> go back to the same entity that sent the SIP request. I suspect the
> intent was that one gateway or the other would handle things
> depending on which side initiated communication, but you've got
> dialogs (even individual transactions) split across them. If this is
> intended, then they would need to share SIP dialog and transaction
> state somehow.

Hmmmmmm.

You make a good point. The diagrams here are not consistent with the 
architectural assumptions we described in the stox-core spec (now RFC 
7247)...

         #########################################################
         #                                                       #
         #                 +-----+                               #
         #                 | S2X |                               #
         #   +-------------+ GW  |<...........>+-------------+   #
         #   | SIP Server  +-----+             | XMPP Server |   #
         #   | example.net |             +-----+ example.com |   #
         #   +-------------+<***********>| X2S +-------------+   #
         #         *                     | GW  |  :              #
         #         *                     +-----+  :              #
         #         *                              :              #
         #    romeo@example.net             juliet@example.com   #
         #                                                       #
         #########################################################

             Legend:
               XMPP = ... or :
                SIP = *

             Figure 1: Possible Gateway Deployment Architecture

    Note that bidirectional communication between the SIP server and the
    XMPP server can be established over either SIP or XMPP.  If the XMPP
    user initiates the interaction, then the XMPP server would invoke its
    XMPP-to-SIP gateway; thus, the communication would occur over SIP.
    If the SIP user initiates the interaction, then the SIP server would
    invoke its SIP-to-XMPP gateway; thus, the communication would occur
    over XMPP.

That is, the MSRP-to-XMPP gateway doesn't belong as an entity in the 
protocol flow for XMPP MUC to MSRP Multi-party Messaging Session 
(Section 4), and the XMPP-to-MSRP gateway doesn't belong in the protocol 
flow for MSRP Multi-party Messaging Session to XMPP MUC (Section 5). If 
we correct this error, I think most of the feedback you provide below 
can be easily addressed. For ease of reference, I refer to it from here 
on as the Fundamental Architectural Inconsistency Lameness, a.k.a. "FAIL".

Unfortunately, the diagrams in the stox-presence spec (now RFC 7248) 
make the FAIL, too! How I hate submitting errata on brand-new RFCs. :(

> Details:
>
> -- Section 4:
>
> It would be helpful to show a network diagram before jumping directly
> into the call flows.  (Same for the later scenario where the
> conference is an XMPP MUC).

Something like figure 1 in RFC 7247? We probably need a separate one 
here, because the entities are different.

> - F3 is left hanging. If the xmpp-msrp gateway sends the INVITE, it
> needs to receive the response and also send an ACK.  Also, it appears
> to skip the MSRP-XMPP gateway, but the rest of the transaction
> terminates there.  Effectively, the MSRP-XMPP gateway receives an
> unsolicited SIP response. This won't work.

Yes, the responses need to be sent back to the XMPP-to-MSRP gateway.

> - F4 and F5 appear to be duplicates.

Correct.

> - F7 indicates the MSRP session is between the MSRP-to-XMPP gateway
> and the conference server. But the MSRP-XMPP gateway never saw the
> XMPP user enter the room.

Right. This will get fixed by addressing the FAIL.

> Also, there should be a initial MSRP SEND
> request prior to the nick.

OK.

> F8: Technically, the "OK" in the MSRP response is just a comment. I
> suggest showing MSRP responses by just the response code in the
> diagram. The comment has no semantic effect (and is even optional).

Would you recommend removing such things for SIP responses, too?

> F18: This assumes the MSRP default reporting model was selected. This
> draft should probably consider how the MSRP REPORT method fits into
> the picture. (Along those lines, does anything change if MSRP relays
> are present?)

Agreed, we need to make it clear that we're using the default reporting 
model.

As I understand it, the MSRP REPORT method provides functionality 
similar to Message Delivery Receipts (XEP-0184) in XMPP. This is 
discussed in the stox-im spec:

http://tools.ietf.org/html/draft-ietf-stox-chat-06#section-7

I haven't thought much about how (or if) that applies to groupchat 
scenarios (in XMPP it's used mainly for one-to-one chat sessions, 
although it could be used for groupchat, too).

> Also, F19 needs to land on the same device that sent F18.

FAIL.

> F20: What triggered the msrp-xmpp gateway to send the XMPP groupchat
> message?

FAIL.

> -- Section 4.1, example 2:
>
> The a=chatroom attribute does not include support for private
> messaging or nicknames. Since the flow uses these later, they should
> probably be included. (Repeats in 5.1)

Good catch.

> -- Section 4.2, Example 6:
>
> I suggest putting something more informative than "OK" in the MSRP
> 200 response. (e.g. "Nickname-Accepted").

WFM.

> -- Section 5:

The FAIL applies here, too (i.e., remove the XMPP-to-MSRP gateway from 
the picture).

> What is the SIP Server? Is this a SIP Proxy, or something else? What
> value does it add to the flow?

I've assumed that a SIP client wouldn't send data directly to a gateway, 
but that a SIP Proxy would likely act as an intermediary and initial router.

> F46: Need an initial MSRP SEND prior to the nickname request.

Yes, as above.

> Also,
> MSRP requests should not traverse a SIP server (unless it is also an
> MSRP relay.)

I am not familiar enough with typical MSRP deployments to know if this 
is usually the case.

> F47: I suggest moving F47 to after F45. As is, it looks like it take
> the SIP server a long time to proxy the ACK.

Sure.

> F56 and F57:
>
> This shows the XMPP-MSRP gateway receiving the XMPP presence message,
> and sending the SIP NOTIFY. But that device never saw the SIP
> SUBSCRIBE. Either the SUBSCRIBE should have gone to it, or F56 and
> F57 should have crossed the other gateway.

The FAIL strikes again.

> Thanks!

No, thank you for the feedback!

Peter