Interworking between the Session Initiation Protocol (SIP) and the Extensible Messaging and Presence Protocol (XMPP): Architecture, Addresses, and Error Handling
RFC 7247

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

(Richard Barnes) Yes

Comment (2014-02-05 for -09)
No email
send info
Need to change affiliation for Peter Saint-Andre?

(Gonzalo Camarillo) Yes

Spencer Dawkins Yes

(Jari Arkko) No Objection

(Stewart Bryant) No Objection

(Benoît Claise) No Objection

(Adrian Farrel) No Objection

(Stephen Farrell) (was Discuss, No Objection) No Objection

Comment (2014-02-11 for -10)
No email
send info
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.

(Brian Haberman) No Objection

(Joel Jaeggli) No Objection

(Barry Leiba) No Objection

(Ted Lemon) (was Discuss) No Objection

Comment (2014-02-06 for -09)
No email
send info
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.

(Pete Resnick) No Objection

Comment (2014-02-05 for -09)
No email
send info
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.

(Martin Stiemerling) No Objection

(Sean Turner) No Objection

Comment (2014-02-05 for -09)
No email
send info
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.