Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging

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

(Richard Barnes) Yes

(Jari Arkko) No Objection

(Alia Atlas) No Objection

(Benoît Claise) No Objection

(Spencer Dawkins) No Objection

Comment (2015-03-04 for -12)
No email
send info
I'm glad to see these specifications moving forward. Thanks for that.

I have a couple of you-need-smarter-ADs questions. As prologue, please remember I have a decent understanding of SIP, an indecent understanding of SIMPLE, and mostly, I just stare uncomprehendingly when I see raw XMPP.

It did not jump out at me when reading this specification, whether there is any assurance to a sender on one side of the gateway that a message was delivered successfully to a receiver on the other side of the gateway. If there's not, that might be worth pointing out a bit earlier than a Note: halfway through page 5.

Is there a possible mismatch between what a sender thinks is happening, TLS-wise, on one side of the gateway, and what a receiver actually receives, TLS-wise, on the other side? I'm not smart enough to ask the right question, but if an XMPP sender knows she's sending over TLS, but the XMPP-to-SIP gateway maps that into a non-TLS SIP transaction on the other side, is the kind of scenario I'm thinking of. If so, perhaps it's worth pointing that out someplace (the Security Considerations section would be fine).

(Adrian Farrel) No Objection

(Stephen Farrell) No Objection

Comment (2015-03-03 for -12)
No email
send info

- I'm surprised it's so easy to be honest;-)

- The reference to rfc 3923 isn't that useful is it? I mean
because nobody really does that afaik. If someone does do it
(I could imagine an enterprise scale thing working), then
maybe better to say that while it'd work, it's really
uncommon, or some such.

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

Barry Leiba No Objection

Comment (2015-03-02 for -12)
No email
send info
-- Section 4 --

   stanza, including required and optional elements and attributes, is
   defined in [RFC6121] (for single instant messages, the value of the
   'to' address SHOULD be a "bare JID" of the form
   "localpart@domainpart", as per [RFC6121]).

I gather that this is adding a new SHOULD that isn't in 6121; you should probably make that clear, because this looks to me as a restatement of something from 6121.

-- Section 8 --
Other sections talk about how you MUST map this into that.  This section say, basically, "Both XMPP and SIP support language tagging," but does not say anything about whether you MAY, SHOULD, or MUST map the language tagging from one into the other.  Is that intentional?

My sense (and I just asked Joe, who agrees) is that this ought to say that you SHOULD map between SIP and XMPP language tagging.

(Ted Lemon) No Objection

(Kathleen Moriarty) No Objection

Comment (2015-03-04 for -12)
No email
send info
Thanks for your work on this series!

(Pete Resnick) No Objection

(Martin Stiemerling) No Objection