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, 6 Jun 2014 15:23:22 -0500

Hi,

Apologies for the delay--I just got back from vacation. Comments inline. I deleted sections that did not seem to need further comment.

On May 27, 2014, at 6:47 PM, Peter Saint-Andre <[email-masked]> wrote:

> Hi Ben, thanks for the feedback! Comments inline.
> 
> On 5/2/14, 2:44 PM, Ben Campbell wrote:
> 

[...]

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

[...]

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

My apologies for not catching it there :-(

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

Yes. I don't think this is a show stopper, but I think it would make the draft easier to digest for a new reader.

[...]

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

You had to go there, didn't you :-)

No, I don't recommend that for SIP. It's become conventional to leave them in for SIP. I realize that is inconsistent. The only reason I mention it is that inconsistent reason phrases have historically been a source of interop issues in SIP. We tried to make it better in MSRP by emphasizing that only the   error number matters, and anything that looks like a reason phrase is strictly a comment for humans.  But MSRP looks enough like SIP that the effort might have been futile.

In retrospect, I withdraw the comment. The call flows _are_ for human consumption, and the comments probably make them easier to understand.

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

With the MSRP defaults, we can probably get by without showing REPORTs if all endpoints are one hop from the switch. (That is, there are no MSRP relays.)

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

It gets more complicated if someone requests success reports. You don't really get end-to-end success reports with simple-chat, because a typical MSRP client wouldn't understand getting multiple success reports for the same message (or message chunk) from different message recipients. If we need end-to-end acknowledgements, we might need something like RFC5438 extended for MSRP. But I doubt that's something STOX would want to take on.

[...]

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

That's probably true for real world flows. I suggest relabeling it to proxy (and making sure it behaves like one.) OTOH, you can illustrate the flow without one if that would make things neater.

[...]

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

While someone might co-locate them, they are separate logical functions. From an architectural perspective we should probably not mix SIP and MSRP across the same "box".

[...]

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Jun 2014 19:47:50 -0600

Honing in on one point for the moment...

>> On 5/2/14, 2:44 PM, Ben Campbell wrote:

<snip/>

> While someone might co-locate them, they are separate logical functions. From an architectural perspective we should probably not mix SIP and MSRP across the same "box".

So the MSRP messages would be routed directly from the XMPP-to-MSRP 
gateway to the SIP user agent, right? And I take it that would apply to 
draft-ietf-stox-chat, too...

Peter

---

From: Ben Campbell <[email-masked]>
Date: Mon, 9 Jun 2014 21:52:15 -0500

On Jun 9, 2014, at 8:47 PM, Peter Saint-Andre <[email-masked]> wrote:

> So the MSRP messages would be routed directly from the XMPP-to-MSRP gateway to the SIP user agent, right?

Assuming no MSRP relays are in play, yes. (And I think it's reasonable to leave them out unless you need to illustrate some MSRP relay specific interaction. I don't _think_ you do.)

Think of MSRP as a media session, with SIP signaling. Like RTP, but different :-)

> And I take it that would apply to draft-ietf-stox-chat, too...

Answering off the top of my head (as in not having stox-chat open in front of me), I think it probably applies there as well.

Thanks!

Ben.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 09 Jun 2014 20:53:47 -0600

On 6/9/14, 8:52 PM, Ben Campbell wrote:
>>>>> Also, MSRP requests should not traverse a SIP server (unless
>>>>> it is also an MSRP relay.)
>>>>
>>> While someone might co-locate them, they are separate logical
>>> functions. From an architectural perspective we should probably
>>> not mix SIP and MSRP across the same "box".
>>
>> gateway to the SIP user agent, right?
>
> Assuming no MSRP relays are in play, yes. (And I think it's
> reasonable to leave them out unless you need to illustrate some MSRP
> relay specific interaction. I don't _think_ you do.)

Agreed.

> Think of MSRP as a media session, with SIP signaling. Like RTP, but

Heh, yes.

> Answering off the top of my head (as in not having stox-chat open in
> front of me), I think it probably applies there as well.

Well I assumed as much since it seemed sensible, so the latest version
(just posted) fixes that for 1:1 chat, too.

Thanks!

Peter