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

From: Ben Campbell <[email-masked]>
Date: Fri, 2 May 2014 15:44:23 -0500

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.

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.

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

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

- F4 and F5 appear to be duplicates.

- 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. Also, there should be a initial MSRP SEND request prior to the nick.

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

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

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

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

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

-- Section 4.2, Example 6:

I suggest putting something more informative than "OK" in the MSRP 200 response. (e.g. "Nickname-Accepted").

-- Section 5:

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

F46: Need an initial MSRP SEND prior to the nickname request. Also, MSRP requests should not traverse a SIP server (unless it is also an MSRP relay.)

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.

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.

Thanks!

/Ben

On Apr 24, 2014, at 11:12 AM, Yana Stamcheva <[email-masked]> wrote:

> Hello all,
> 
> Only one review has been received on this list during the WGLC (Thanks Philipp!) and in order to be able to proceed we would need more people to express their support for this document!
> 
> Therefore, we hereby would like to extend the WGLC period with 2 more weeks and end it on May 5, 2014.
> 
> Please, if you'd like this document to go forward, send your reviews, comments or support notes to the list before May 5, 2014!
> 
> If you're willing to review the document but for some reason you won't be able to do it before the above deadline, please contact the chairs.
> 
> Thanks!
> Yana Stamcheva & Markus Isomaki
> 
> On 06 Apr 2014, at 20:20, Yana Stamcheva <[email-masked]> wrote:
> 
>> The editors and the chairs believe that the following draft is now ready and hereby start a 2-week Working Group Last Call for:
>> 
>> draft-ietf-stox-groupchat-04 : http://tools.ietf.org/html/draft-ietf-stox-groupchat-04 (Last updated on 2014-03-25)
>> 
>> The WGLC ends on April 21, 2014.
>> 
>> Please review the document and bring any remaining issues, or issues whose resolution is not satisfactory, to the attention of the Working Group on this list before April 21.
>> 
>> If after reviewing the document you find it complete and do not have any comments, please send a note to that effect as well!
>> 
>> Regards,
>> Yana Stamcheva & Markus Isomaki
> 
> _______________________________________________
> stox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stox

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 27 May 2014 17:47:12 -0600

Hi Ben, thanks for the feedback! Comments inline.

On 5/2/14, 2:44 PM, Ben Campbell wrote:
> 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  |  :              #
         #         *                     +-----+  :              #
         #         *                              :              #
         #    [email-masked]             [email-masked]   #
         #                                                       #
         #########################################################

             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

FAIL.

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

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

> 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

---

From: Matt Ryan <[email-masked]>
Date: Fri, 30 May 2014 14:38:19 -0600

Comments below.

>> Here's some belated comments:
(snip)
>> 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  |  :
> # #         *                     +-----+  :              # #
> *                              :              # #
> [email-masked]             [email-masked]   # #
> # #########################################################
> 
> Legend: XMPP = ... or : SIP = *
> 
> 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.

This is one of the concerns I also raised in my review of
draft-ietf-stox-chat-06 on 5/12/14, and why I raised my subsequent
question about communication between STOX-capable and non-STOX-capable
entities.

The situation is actually a bit worse:  If the XMPP-to-SIP gateway
sends a SIP invite to the SIP server (or MSRP conference in the
groupchat case) on the receiving end, the SIP session will not get
established until the XMPP-to-SIP gateway receives a 200 OK from the
SIP server, and it will continue to retry this INVITE until the
session is established.

Keeping state on the XMPP side might help (other than you still have
the unnecessary retransmits), but as Peter pointed out, simply
removing the MSRP-to-XMPP gateway in this protocol flow would then
result in the 200 OK returning to the XMPP-to-SIP gateway, which would
complete the establishment of the session also.

- -- 
Matt Ryan
Code Slinger  |  Jive Communications, Inc.
Jive.com  |  [email-masked]

---

From: Matt Ryan <[email-masked]>
Date: Fri, 30 May 2014 18:00:46 -0600

On 5/27/14, 5:47 PM, Peter Saint-Andre wrote:
> 
> Unfortunately, the diagrams in the stox-presence spec (now RFC
> 7248) make the FAIL, too! How I hate submitting errata on brand-new
> RFCs. :(
> 

Unfortunately, this is true - and also true for draft-ietf-stox-chat
and draft-ietf-stox-media.

If it pleases the group, I would be happy to volunteer to rework some
of the examples based on the discussion and submit them via the list
for further discussion.  I'll assume this is okay and try to get
started this weekend. :)

- -- 
Matt Ryan
Code Slinger  |  Jive Communications, Inc.
Jive.com  |  mryan at getjive dot com

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 30 May 2014 18:09:36 -0600

On 5/30/14, 6:00 PM, Matt Ryan wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
>
>

Yeah it's all the specs. I wouldn't wish ASCII art editing on anyone, 
and I think it's mostly that, so I'm happy to do that for the next 
revision. But patches are always welcome. :-)

Peter