CUSAX: Combined Use of the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP)

Note: This ballot was opened for revision 07 and is now closed.

(Richard Barnes) Yes

Comment (2013-09-11 for -07)
No email
send info
References to SIMPLE (say, [RFC6914]) and Jingle [XEP-0166] would be helpful.

(Gonzalo Camarillo) Yes

(Pete Resnick) (was Discuss) Yes

Comment (2013-10-03)
No email
send info
Thanks for addressing all of my comments.

(Jari Arkko) No Objection

(Stewart Bryant) No Objection

(Benoît Claise) No Objection

Comment (2013-09-12 for -07)
No email
send info
Thanks for addressing Benson's OPS DIR review.

One open question for section 3.2. Service Management: Any impact on the network operations when you switch between SIP/XMPP. Do you foresee the case where the end user could select SIP/XMPP for different features?
In this case, there is an impact on the network operation. For example: QoS, security?
Ex: the suggestion is to prefer SIP for audio and video. So QoS would be set up for SIP in the network.
If the end user now selects XMPP, the network operations must take this into account, to have the same QoS.
Ex: in an enterprise, a file transfer within a chat window, might have to checked for document leakage issues.
If the end user changes the XMPP <-> SIP, network operations must take this into account.
So basically my message is that changing the SIP/XMPP feature options in the client might has some impact: QoS, security, ... basically the flow treatment. In other words, the network operations must foresee, in advance, all the potential combinations of features between XMPP and SIP
Should we say a few words about this?

"Despite these advances, SIP remains the protocol of choice for telephony-like services, especially in enterprises where users are accustomed to features such as voice mail, call park, call queues, conference bridges and many others that are rarely (if at all) available in Jingle-based software. "

I don't understand "Despite these advances, SIP remains the protocol of choice"
Which advances? XMPP?

(Spencer Dawkins) No Objection

(Adrian Farrel) No Objection

Comment (2013-09-12 for -07)
No email
send info
The Abstract says...
   This specification
   does not define any new protocols or syntax 
...but it is not a specification!

(Stephen Farrell) No Objection

(Joel Jaeggli) No Objection

Comment (2013-09-11 for -07)
No email
send info
This looks a lot like work that someone already did e.g. at jitsi. I am curious if they could reference that work. becuase that takes it from the realm of "here's what you can do", to "here's what we did"

Barry Leiba No Objection

Comment (2013-09-12 for -07)
No email
send info
I have to say that in this case I do not share the concerns of my distinguished colleague from Urbana.  I find this document mostly reasonable, by way of considered advice to those trying to deployed a mixed SIP/XMPP application environment.  I do agree that saying more strongly that this is just that -- considered advice -- and no more, would be good.

You missed an opportunity to give examples using John, Joan, Bill, and Susie (a bunch of CUSAX).  Pity.

Three non-blocking comments; feel free to chat with me about them if you please:

-- Section 2 --

   Because many of the features that a CUSAX client would prefer in one
   protocol would also be available in the other, clients should make it
   possible for such features to be disabled for a specific account.  In
   particular, it is suggested that clients allow for audio and video
   calling features to be disabled for XMPP accounts, and that instant
   messaging and presence features should also be made optional for SIP

This document is talking about how to use SIP and XMPP alongside each other, not at different ends of the same pipe.  So, isn't it likely that, say, John might want to make voice calls to both Joan and Susie, where he needs SIP to talk with Joan and XMPP to talk with Susie (and similarly for IM services)?  Wouldn't it, therefore, be better to allow preference settings for calling features, which might be customizable by user or overridable by instance?

-- Section 6 --
I agree with the idea that the document should be clearer about these recommendations being very soft, and the first paragraph of Section 6 would be one good place to say that.  As it is, the two non-bullet paragraphs make it sound pretty close to BCP advice.

-- References --
I'm a believer that Informational documents do merit normative references, and for this document I think SIP and XMPP are normative references.  I'm not putting this at DISCUSS level, so it's non-blocking, but I strongly urge you to make that change.

(Ted Lemon) No Objection

Comment (2013-09-09 for -07)
No email
send info
Did this document get a secdir review?

(Martin Stiemerling) No Objection

(Sean Turner) No Objection