Author: Peter Saint-Andre
Date: 2002-10-02
For some time now, the term XMPP (Extensible Messaging and Presence Protocol) has been used as a synonym for Jabber. To my knowledge, this usage began with Andre Durand (founder of Jabber, Inc.) and has continued within some elements of the Jabber community. More recently, the term has gained greater visibility through its association with the proposed IETF Working Group.
Unfortunately, having two terms for the same thing introduces the potential for a great deal of confusion. As a starting point for discussion, this document proposes a much clearer separation between XMPP and Jabber. The proposed distinction is a radical break with some received wisdom (or unquestioned assumptions) in the Jabber community, so hold onto your hat!
The way things stand today, XMPP and Jabber are synonymous. But are they? Given the likely existence of an XMPP working group within the IETF, it's possible that XMPP may diverge from the Jabber protocol. This is unlikely, since many core Jabber contributors will be active participants within the IETF WG, but it is possible. Even if total protocol synchronization is achieved, we're still left with two names for the same thing. Some people will use the term XMPP and some people will use the term Jabber, diluting the significance of both. I submit that this is a Bad Thing [tm].
Simply put, I propose that XMPP be defined as the core "transport" specification and that Jabber be defined as all the JSF-approved, application-specific namespaces for use on top of the core. XMPP would consist of streams (including associated security and authentication mechanisms, such as SASL and TLS) as well as the core data elements of <message/> (for "push" communication), <presence/> (for receiving information one has subscribed to), and <iq/> (for request-response functionality). All application-specific information would be removed from the core, such as <show/> and <status/> for presence chunks -- message and presence would be "stripped down" in much the same way that IQ is now (it may contain extended content in any namespace but has no defined children). XML streams and the associated core data elements would be scoped by XMPP namespaces, not by Jabber namespaces (no more jabber:client and jabber:server and such), with all Jabber-related content being contained in children of message, presence, and IQ that are scoped by JSF-approved namespaces.
The following table summarizes my thoughts:
| XMPP | Jabber |
|---|---|
| Transport / infrastructure | Applications (not just IM) |
| Streams + core data elements | Extensions by namespace |
| Identity, security, authentication | Application-specific functionality |
| XMPP namespaces | Jabber (and other) namespaces |
| Managed by IETF | Managed by JSF |
In essence, I am proposing that XMPP is to Jabber as HTTP is to the Web. And I mean that in all seriousness: I think that Jabber could be a real-time alternative to the World Wide Web, a thriving network of servers and clients for asynchronous communication that offers an experience that is not possible on the Web today (or anytime soon). And the JSF would play a role similar to that of the W3C, guiding the standards for building out such a network.
How would we implement such a radical change? I suggest that the XMPP working group gives us a perfect opportunity for doing so. Let the WG focus on cleaning up and securing XML streams (including i18n issues and perhaps some nice header data for more intelligent delivery) in an XMPP namespace, keeping it simple (perhaps a la XATP) and closely coordinating with the JSF to ensure that the resulting core spec can provide a basis for Jabber communications on top of the core. Since the resulting XMPP spec would be importantly different from current XML streams + Jabber in regard to connections, security, and authentication, it would use a different port (perhaps 9677) and existing Jabber implementations would deprecate the old 5222 and 5269 ports for use by legacy clients and servers. SASL and TLS would be implemented on the new protocol/port only (existing XML streams over 5222 and 5269 would be purely for legacy applications). The JSF would work on the Jabber specs to extract some existing message and presence functionality (e.g., subject and body for messages, show and status for presence) into standalone child elements as is done with IQ now. The result would be a separation of transport and applications.
One result of separating transport and applications is that it provides a clear division of labor between the IETF and the JSF. No more worries about diverging protocols: the IETF WG (with strong involvement from the Jabber technical community) defines the core transport layer and the JSF can happily proceed with all the application-specific namespaces (for IM, whiteboarding, calendaring, and so on) that the IETF probably doesn't want or need to get involved in anyway.
Some would suggest that separating the XMPP transport from the Jabber applications is unnecessary. I would reply that we are so close to such a separation right now that it makes sense to "go all the way" by enabling any properly-namespaced children to be sent over XML streams and by pulling out the few remaining IM-specific bits from message and presence. The result will be a stronger transport infrastructure, a more flexible application space (opening up doors beyond IM), and a clear division of labor between the IETF and JSF.
Let the flames begin!