Subject: [Stox] I-D Action: draft-ietf-stox-groupchat-05.txt

From: [email-masked]
Date: Tue, 10 Jun 2014 20:44:49 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the SIP-TO-XMPP Working Group of the IETF.

        Title           : Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Groupchat
        Authors         : Peter Saint-Andre
                          Saul Ibarra
                          Salvatore Loreto
	Filename        : draft-ietf-stox-groupchat-05.txt
	Pages           : 40
	Date            : 2014-06-10

Abstract:
   This document defines a bidirectional protocol mapping for the
   exchange of instant messages in the context of a multiparty chat
   session among users of the Session Initiation Protocol (SIP) and
   users of the Extensible Messaging and Presence Protocol (XMPP).
   Specifically, this document defines a mapping between the SIP-based
   Message Session Relay Protocol (MSRP) and the XMPP Multi-User Chat
   (MUC) extension.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-stox-groupchat/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-stox-groupchat-05

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-stox-groupchat-05

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Peter Saint-Andre <[email-masked]>
Date: Tue, 10 Jun 2014 21:46:19 -0600

An attempt to address feedback received recently, as well as the "FAIL" 
issue...

On 6/10/14, 9:44 PM, [email-masked] wrote:
> _______________________________________________
> stox mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/stox
>

---

From: Ben Campbell <[email-masked]>
Date: Thu, 19 Jun 2014 16:49:31 -0500

Hi Peter,

[Disclaimer: this was a higher level review than for the previous version--I mainly looked to see how the previous discussions about the architecture rendered into the draft. ]

This version is much improved. I think you've gotten the "FAIL" off of it. But of course, cleaning up the architecture reveals a few things :-)

Section 4:

I think the addition of section 4 helps a lot in general.

The architecture treats the MSRP Conference server to be a monolithic thing. The result of this is, in the examples, all the SIP and MSRP traffic go to the sample place. That doesn't match the architecture from RFC 4975 and simple-chat, where the signaling (SIP) is separate from media (MSRP).  simple-chat talks in terms of a conference focus that handles the signaling side, and an MSRP switch that handles the media (MSRP) side.

Now, it's perfectly okay to collocate those services into an MSRP Conference Server in real deployments, and okay to show it that way in this draft for the sake of simplicity. But it would be worth mentioning that in section 4, and maybe also mentioning that any interaction between the conference focus and MSRP switch are out of scope (and irrelevant) for this draft.

Along the same line, I assume the public "SIP side" interface of the X2M gateway looks like a conference focus plus an MSRP switch to the outside world. Again, these could be logically separate, but co-located.

Section 5 (and subsections)

The diagram does not show the transport (e.g. TCP) connection establishment for MSRP. I think it would be useful to do so. Also, the active endpoint (the one opening the transport connection) has to send an immediate MSRP SEND request once the connection is established. (I don't _think_ simple-chat extended that to allow an initial NICKNAME to replace that--but I may have missed it.)

Section 6 (and subsections)

The diagram in section 6 still has a "SIP Server". It's still not clear to me what that represents. It _could_ be a SIP Proxy, in which the MSRP session would skip it. I guess it could be an MSRP aware b2bua, in which case the MSRP session might also traverse it. It could be a combo of a SIP proxy and an RFC 4976 MSRP relay, but that would require additional MSRP signaling.

I would suggest promoting it to some sort of SIP "service" or "service provider", which is more of a cloud than a box, and having the MSRP traffic skip it entirely. Or removing it entirely--there's no _protocol_ reason that a SIP user needs an outbound service provider (even though there might be perfectly good _deployment_ reasons.)

I also think section 6 needs to show the same sort of MSRP connection establishment and initial SEND request as mentioned for 5.

Thanks!

Ben.

On Jun 10, 2014, at 10:46 PM, Peter Saint-Andre <[email-masked]> wrote:

> An attempt to address feedback received recently, as well as the "FAIL" issue...
>

---

From: [email-masked]
Date: Thu, 19 Jun 2014 19:01:18 -0300

> The architecture treats the MSRP Conference server to be a monolithic thing. The result of this is, in the examples, all the SIP and MSRP traffic go to the sample place. That doesn't match the arch…

For all practical reasons, they do end up in the same place. Otherwise, how would the MSRP switch communicate with the SIP server in order to share the information it knows about the participants or add/remove the media plane slots? Do we need another protocol or mechanism between the two? Even speculating about this possibility would introduce some unnecessary uncertainty for those contemplating implementing this specification.

> Now, it's perfectly okay to collocate those services into an MSRP Conference Server in real deployments, and okay to show it that way in this draft for the sake of simplicity.
> But it would be worth mentioning that in section 4, and maybe also mentioning that any interaction between the conference focus and MSRP switch are out of scope (and irrelevant) for this draft.

I would skip mentioning this this, based on the argument I made above. It sounds as scary as "there is something we don’t know how it has to be done but is not our problem”.

---

From: Ben Campbell <[email-masked]>
Date: Thu, 19 Jun 2014 17:25:03 -0500

> For all practical reasons, they do end up in the same place. Otherwise, how would the MSRP switch communicate with the SIP server in order to share the information it knows about the participants o…

MSRP and simple-chat allow them to be separate. If people implement stox-groupchat to assume that the focus and switch are always co-located, then they could not interop with a decomposed MSRP conference service. If you think that MSRP conference services should not be decomposed in practice, that might be worth a separate draft :-) (Note that "should not be decomposed in practice" is a very different thing than "have not been decomposed in currently available services.)

As far "unnecessary uncertainty" goes, all it needs is guidance to avoid any assumption that the focus and switch are at the same address. Implementing stox-groupchat with a non-monolithic msrp conference service does not require solving the "how does the focus talk to the switch" problem. I'm not suggesting anything more complex than saying "We are showing these co-located to keep the diagrams simple--but remember that the SDP may point to a different location for the MSRP service."

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 19 Jun 2014 21:52:54 -0600

On 6/19/14, 3:49 PM, Ben Campbell wrote:
> Hi Peter,
>
> [Disclaimer: this was a higher level review than for the previous
> version--I mainly looked to see how the previous discussions about
> the architecture rendered into the draft. ]
>
> This version is much improved. I think you've gotten the "FAIL" off
> of it. But of course, cleaning up the architecture reveals a few
> things :-)
>
> Section 4:
>
> The architecture treats the MSRP Conference server to be a monolithic
> thing.

As you pointed out later in this thread, this is a simplifying 
assumption to make the diagrams and explanations easier to follow.

> The result of this is, in the examples, all the SIP and MSRP
> traffic go to the sample place. That doesn't match the architecture
> from RFC 4975 and simple-chat, where the signaling (SIP) is separate
> from media (MSRP).  simple-chat talks in terms of a conference focus
> that handles the signaling side, and an MSRP switch that handles the
> media (MSRP) side.
>
> Now, it's perfectly okay to collocate those services into an MSRP
> Conference Server in real deployments, and okay to show it that way
> in this draft for the sake of simplicity. But it would be worth
> mentioning that in section 4, and maybe also mentioning that any
> interaction between the conference focus and MSRP switch are out of
> scope (and irrelevant) for this draft.
>
> Along the same line, I assume the public "SIP side" interface of the
> X2M gateway looks like a conference focus plus an MSRP switch to the
> outside world. Again, these could be logically separate, but
> co-located.

Exactly.

> The diagram does not show the transport (e.g. TCP) connection
> establishment for MSRP. I think it would be useful to do so.

Agreed.

(It would also be useful to mention that we're assuming that an MSRP 
client uses the SIP "binding" to communicate with the MSRP conference 
server, see Section 6...)

> Also,
> the active endpoint (the one opening the transport connection) has to
> send an immediate MSRP SEND request once the connection is
> established. (I don't _think_ simple-chat extended that to allow an
> initial NICKNAME to replace that--but I may have missed it.)

Good catch.

> The diagram in section 6 still has a "SIP Server".

I have to admit that I was pretty sleepy when I was editing that part of 
the document. :-)

> It's still not
> clear to me what that represents. It _could_ be a SIP Proxy, in which
> the MSRP session would skip it. I guess it could be an MSRP aware
> b2bua, in which case the MSRP session might also traverse it. It
> could be a combo of a SIP proxy and an RFC 4976 MSRP relay, but that
> would require additional MSRP signaling.
>
> I would suggest promoting it to some sort of SIP "service" or
> "service provider", which is more of a cloud than a box, and having
> the MSRP traffic skip it entirely. Or removing it entirely--there's
> no _protocol_ reason that a SIP user needs an outbound service
> provider (even though there might be perfectly good _deployment_
> reasons.)

If we remove it entirely (and I'm not opposed to that), is it safe to 
say that an MSRP client would connect directly to an MSRP-to-XMPP 
gateway? With my XMPP glasses on that doesn't make sense because in that 
world we always think of something (a "service" or "service provider" as 
you call it) acting as a network gatekeeper. However, I know that's not 
something we assume in SIP/MSRP architectures, so for our purposes here 
it's probably fine to delete the service provider from the diagrams in 
Section 6.

> I also think section 6 needs to show the same sort of MSRP connection
> establishment and initial SEND request as mentioned for 5.

Noted!

> Ben.

Thanks for your continued reviews!

Peter

---

From: Ben Campbell <[email-masked]>
Date: Fri, 20 Jun 2014 15:31:21 -0500

On Jun 19, 2014, at 10:52 PM, Peter Saint-Andre <[email-masked]> wrote:

> As you pointed out later in this thread, this is a simplifying assumption to make the diagrams and explanations easier to follow.

Do you concur that that assumption should be pointed out? (Or did I miss some place where it is already?)

On a tangentially related note, I recall another reviewer complained about the lack of SIP provisional responses. It might be worth also putting in a disclaimer that provisional responses have been left out to simplify things.

[...]

> (It would also be useful to mention that we're assuming that an MSRP client uses the SIP "binding" to communicate with the MSRP conference server, see Section 6...)

Agreed.

[...]

> I have to admit that I was pretty sleepy when I was editing that part of the document. :-)
> 
>> It's still not
> If we remove it entirely (and I'm not opposed to that), is it safe to say that an MSRP client would connect directly to an MSRP-to-XMPP gateway? With my XMPP glasses on that doesn't make sense because in that world we always think of something (a "service" or "service provider" as you call it) acting as a network gatekeeper. However, I know that's not something we assume in SIP/MSRP architectures, so for our purposes here it's probably fine to delete the service provider from the diagrams in Section 6.
> 

In the SIP/MSRP world, this is sort of fuzzy. 

There's no  SIP architectural requirement for clients to send their signaling through some service between themselves and the destinations. But in practice, they commonly do for various reasons ( NAT traversal, authentication, policy enforcement, control-oriented service providers, etc). And what sits in that box may be different for different deployments. 

Similarly, MSRP might have an MSRP relay there, or you might have some SBC-like device that handles both signaling and media (the case that would look the most like the diagram.)

I would personally lean towards taking it out, perhaps with a disclaimer that there might be any number of SIP and/or MSRP devices between the client and the gateway (which btw is acting both as a SIP to XMPP and MSRP to XMPP gateway, even if only for chat purposes), but that they are not important for understanding the flow.

---

From: Saúl Ibarra Corretgé <[email-masked]>
Date: Mon, 23 Jun 2014 09:30:24 +0200

>> initial NICKNAME to replace that--but I may have missed it.)

While you are right, Ben, isn't that implied? I mean, obviously there needs to be a TCP connection, which needs to be bound and so on, but if we go down that rabbit-hole we would need to also say that it could happen if reverse if ACM is being used... so, perhaps we can assume (or add a note about it) that a working MSRP connection established using standard mechanisms and then we send the NICKNAME over it?

Cheers,

--
Saúl Ibarra Corretgé
AG Projects

---

From: Ben Campbell <[email-masked]>
Date: Mon, 23 Jun 2014 09:15:23 -0500

> While you are right, Ben, isn't that implied? I mean, obviously there needs to be a TCP connection, which needs to be bound and so on, but if we go down that rabbit-hole we would need to also say t…

Explicit is better than implicit. I don't think we have to show every possible variation in setting up an MSRP session, just like we don't show every SIP variation (but a note to that effect could be helpful.) I think the fact that the connection setup for MSRP is handled differently than that for XMPP is an important concept for this draft.

Which of course makes me wonder if connection management on the XMPP side should be mentioned.

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 23 Jun 2014 19:36:07 -0600

>> establishment for MSRP. I think it would be useful to do so.

BTW, RFC 7247 does say:

    Because [RFC6120] specifies a binding of XMPP to TCP, a gateway from
    SIP to XMPP will need to support TCP as the underlying transport
    protocol.  By contrast, as specified in [RFC3261], either TCP or UDP
    can be used as the underlying transport for SIP messages, and a given
    SIP deployment might support only UDP; therefore, a gateway from XMPP
    to SIP might need to communicate with a SIP server using either TCP
    or UDP.

But here we're talking about MSRP, so we might need similar text.

Peter

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 23 Jun 2014 19:39:21 -0600

> Explicit is better than implicit. I don't think we have to show every possible variation in setting up an MSRP session, just like we don't show every SIP variation (but a note to that effect could…

I do think it would be good to have a note somewhere to the effect that 
not every protocol interaction is mentioned here.

> Which of course makes me wonder if connection management on the XMPP side should be mentioned.

What did you have in mind for connection management? Something like 
XEP-0198?

Peter

---

From: Ben Campbell <[email-masked]>
Date: Mon, 23 Jun 2014 20:42:26 -0500

> But here we're talking about MSRP, so we might need similar text.

I think it's more than a matter of just supporting TCP, it's a matter of when connections are opened and closed, and which party is responsible.

(Do we need to worry about other transports, i.e. WebSocket?)

---

From: Ben Campbell <[email-masked]>
Date: Mon, 23 Jun 2014 20:45:06 -0500

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

> I do think it would be good to have a note somewhere to the effect that not every protocol interaction is mentioned here.
> 
> What did you have in mind for connection management? Something like XEP-0198?

You give me too much credit. I had nothing in particular in mind--just whether it was a subject that needed discussion.

I lean towards "no", since I assume that the connections for XMPP will have been opened well before the flow started, and closed well afterwards. But in constrast, a connection for MSRP is opened as a _result_ of the SIP (or equivalent) messages that are part of the flow.