It's now clear that both XMPP and SIP are important technologies that will co-exist for a long time. XMPP (see RFC 3920) provides a streaming XML transport that is useful not only in instant messaging but in any application space where it's necessary to move structured data from one point to another (pubsub, SOAP, RPC, Atom, you name it). SIP (see RFC 3261) provides semantics for managing multimedia sessions (or even XMPP sessions) and is the preferred mechanism for negotiating how entities will set up the use of RTP (see RFC 3550) for the multimedia streams themselves.
So how will XMPP, SIP, and RTP work together? (No, it's not just SIP and XMPP.) The developers of Google Talk made their own custom XMPP extension for their voice functionality but say they will be supporting SIP in the future. It's too bad they didn't use TINS, since that would make gatewaying to SIP pretty darn easy. It strikes me that anyone who's serious about XMPP-SIP interop will either use TINS on the XMPP side (with gateways to SIP networks) or develop a dual-headed client that includes both XMPP and SIP support. Either way you slice it, both TINS and SIP enable you to get down to RTP, which is where you really need to be in order to do multimedia.
That's XMPP and SIP. XMPP and SIMPLE is another question. SIP is a rendezvous or negotiation protocol, whereas SIMPLE is a set of extensions that enables applications to send messages and presence information over the channel that's normally used for multimedia negotiations. Work on SIMPLE began in the IETF back in 2001 (after it became clear that the Instant Messaging and Presence Protocol WG would fail in its mission of developing a common protocol) and continues to this day. So far the SIMPLE WG has developed a way to send single messages between SIP users and a way to share presence among SIP users. They don't yet have a settled way to implement basic features like chat sessions rather than single messages (though after several attempts they seem to be settling on MSRP), contact or "buddy" lists (though see the somewhat scary XCAP spec), or groupchat (presumably that will be developed in the XCON WG). There are still many holes in the SIMPLE protocol stack, and companies who've implemented it so far have needed to "embrace and extend" SIMPLE with proprietary extensions in order to offer even a minimally functional IM and presence offering (think LCS). The result is, sadly, a lack of interoperability.
Some claim that SIMPLE is the de-facto standard for IM, but the claim is dubious and we're hearing it less and less these days. SIMPLE is years away from being full-featured or stable. Organizations that want to offer IM and presence solutions today can't wait years for SIMPLE to settle, they need a proven technology that they can deploy today -- as witness the Wall Street investment banks, major portions of the U.S. government, leading-edge companies who want to generate competitive advantage, and a number of large service providers (most recently Google and Wanadoo, but also BellSouth, Portugal Telecom, Sapo, etc.). And organizations that can wait years for SIMPLE to be fully baked are not all that serious about IM and presence -- they're more interested in protocol posturing than in getting the job done or meeting the needs of their customers.
One thing that has always surprised me is IBM's stance in the IM and presence space. You'd think that with their commitment to Linux, open source, and open standards, they would have embraced Jabber/XMPP technologies years ago. Instead, they continue to sell Lotus Sametime, which is based on a completely proprietary technology and protocol. Granted, they are rumored to offer a SIMPLE gateway to their customers, but that's a gateway, not the core technology. And if we can judge by a recent blog entry from IBM Distinguished Engineer Carol Jones, IBM still does not understand Jabber/XMPP technologies. Carol seems to be of the "SIP is the one ring to bind them all" philosophy. She states, inexplicably, that "SIP has backing from most large companies in the IM space" but we certainly haven't seen that in deployments, AOL and Yahoo continue to use their own closed protocols, and only Microsoft (with the aforementioned LCS) has made a half-hearted attempt to use SIMPLE -- with less-than-stellar results in their few major deployment attempts and no ability to federate domains (standard with Jabber/XMPP since 1999!). She thinks that XMPP is dead because it's no longer active in the IETF. Granted the SIMPLE WG continues to soldier on and probably will for years to come, but XMPP is quiet in the IETF because the XMPP WG completed its mission. Are TCP and HTTP dead because there are no active working groups for those technologies? XMPP most certainly is a part of the IETF, but the Jabber/XMPP community develops extensions to XMPP within the standards process of the Jabber Software Foundation rather than burdening the IETF with massive numbers of Internet-Drafts (I sometimes think that the SIP community, with four working groups and endless activity, is effectively a distributed denial of service attack on the Internet Standards Process). As to the relationship between continuing XMPP development and the IETF, think of it this way: W3C is to HTTP as the JSF is to XMPP (except the JSF uses an open standards process, unlike the W3C's closed consortium). In implementation land, Jabber/XMPP servers have been proven to scale to hundreds of thousands of concurrent users, which we have not seen with SIMPLE servers to date. Jabber/XMPP technologies have a well-understood client-server architecture that is easy to deploy, whereas the fundamentally peer-to-peer nature of SIP/SIMPLE services sounds appealing but ends up being a logistical and compliance nightmare for the system administrators who actually have to manage IM and presence services day to day. And the list goes on.
Some years ago, John Sowa formulated The Law of Standards, which is consistent with years of experience among the Internet community. The law states that simple, deployable technologies tend to emerge within a small, dedicated team of practical-minded developers (think C, HTTP/HTML, SMTP, Linux), whereas unwieldy, undeployable technologies tend to emerge from a bureaucratic process within large committees, companies, or consortia (think Ada, SGML, X.400, OS/2). XMPP is a simple technology (originally developed within the Jabber open-source community and formalized within the IETF) that has been and continues to be adopted by serious organizations who want to leverage the power of IM and presence in the real world. SIMPLE is perhaps one of the most tragically misnamed technologies ever created -- and while some large organizations pay lip-service to it, there's a conspicuous lack of deployment. I realize that some organizations may deploy SIMPLE systems (heck, there are probably still some X.400 email services running out there somewhere) and I've even taken the lead in specifying how SIMPLE-to-XMPP gateways can work, but I also think that simple, deployable technologies always win out in the long run. And in the IM and presence space that means XMPP.
It's the law of standards in action...