Skip to main content

Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging
draft-ietf-stox-im-13

Yes

(Richard Barnes)

No Objection

(Adrian Farrel)
(Alia Atlas)
(Benoît Claise)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Pete Resnick)
(Ted Lemon)

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

Richard Barnes Former IESG member
Yes
Yes (for -12) Unknown

                            
Adrian Farrel Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (2015-03-02 for -12) Unknown
-- 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.
Benoît Claise Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Joel Jaeggli Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2015-03-04 for -12) Unknown
Thanks for your work on this series!
Martin Stiemerling Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (for -12) Unknown

                            
Spencer Dawkins Former IESG member
No Objection
No Objection (2015-03-04 for -12) Unknown
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).
Stephen Farrell Former IESG member
No Objection
No Objection (2015-03-03 for -12) Unknown

- 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.
Ted Lemon Former IESG member
No Objection
No Objection (for -12) Unknown