Skip to main content

Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling
draft-ietf-stox-core-11

Yes

(Gonzalo Camarillo)
(Spencer Dawkins)

No Objection

(Adrian Farrel)
(Barry Leiba)
(Benoît Claise)
(Brian Haberman)
(Jari Arkko)
(Joel Jaeggli)
(Martin Stiemerling)
(Stewart Bryant)

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

Gonzalo Camarillo Former IESG member
Yes
Yes (for -09) Unknown

                            
Richard Barnes Former IESG member
Yes
Yes (2014-02-05 for -09) Unknown
Need to change affiliation for Peter Saint-Andre?
Spencer Dawkins Former IESG member
Yes
Yes (for -09) Unknown

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

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (for -09) Unknown

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

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

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

                            
Martin Stiemerling Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Pete Resnick Former IESG member
No Objection
No Objection (2014-02-05 for -09) Unknown
Section 4 is (nicely) clear on the document architecturally describing a gateway. However, traditionally a gateway is transparent to the entity that communicates with it: When we had SMTP-to-X.400 gateways, the gateway appeared as just another SMTP system that noticed special qualities of the address and then routed the messages appropriately. Section 5 describes something a bit different. It's not clear that what section 5 describes actually is part of the gateway, but rather sounds like a combined server which does failover between the protocols. I don't think this is a showstopper, but it might help implementers significantly if you described in section 5 *where* in the model this function occurs. Right now, it sounds like the server itself does the addressing failover, not the gateway.
Sean Turner Former IESG member
No Objection
No Objection (2014-02-05 for -09) Unknown
I assume this is a typo re encrypted/protected:

   Because XMPP lacks a way
   to signal that all hops need to be encrypted,

Https doesn't necessarily imply encryption it depends on the cipher suite chosen.
Stephen Farrell Former IESG member
(was Discuss, No Objection) No Objection
No Objection (2014-02-11 for -10) Unknown
Thanks for handling my discuss point so quickly!

- End of s4: "X2S gw" - on a small screen I nearly jumped
when I thought that said "X25 gw" (I guess I really do need
glasses, sigh:-)

- Labelling the figures might be good.

- Has anyone thought about confusability in the name
mappings? I expected to see a bit of text in the security
considerations but didn't see it.
Stewart Bryant Former IESG member
No Objection
No Objection (for -09) Unknown

                            
Ted Lemon Former IESG member
(was Discuss) No Objection
No Objection (2014-02-06 for -09) Unknown
Oops, I put this in as a DISCUSS because I wanted to DISCUSS it, but it doesn't meet the DISCUSS criteria, so I've cleared.   Sorry for the confusion.   I'd still like you to address this, obviously.

In the architectural diagram on page 5, it appears that the way the protocol flow goes is that romeo's server sends XMPP to juliet's server, and juliet's server responds with SIP.   I don't think this is what you intended—I think that what you intended is that either romeo or juliet could initiate a connection; if romeo initiates, the communication will occur using XMPP, and if juliet initiates, it will occur using SIP.