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

[Ben Campbell <[e-mail]>]

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 <[e-mail]> 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".

[...]