From Jabber to XMPP: a symbol for IM standard and convergence

The Jabber Software Foundation has changed its name and become the XMPP Standards Foundation. This is an important step in increase the business convergence around the XMPP protocol.

A major step for Standard-based Instant Messaging

The Jabber Software Foundation is now named the XMPP Standards Foundation (XSF). The official press release is available on: Jabber Software Foundation Renamed to XMPP Standards Foundation. From the announcement:

“The membership’s decision to rename the organization truly reflects our continued development of open XMPP extensions and the increasing commercial interest in XMPP technologies,” said Peter Saint-Andre, executive director of the XSF. “While we will never forget our origins in the open-source community, the name XMPP Standards Foundation captures our mission of producing the best open protocols for real-time communication over the Internet.”

This is a major step in the life of Open Instant Messaging standards: Whereas other Instant Messaging providers are putting an emphasis on the “Network” of Instant Messaging users, the XMPP Standard Foundation is putting an emphasis on standards, interoperability and beyond that, federation of different servers using various instant messaging implementations.

Vendors from around the world are embracing the XMPP standard. Google is using XMPP for its instant messaging system Google Talk. Adobe is rumoured to enter the XMPP playground. The number of implementation of both servers and clients is promised to increase. 2006 has been a very good year for XMPP, probably the best so far. This is very encouraging and probably a sign that XMPP is taking the lead over SIMPLE, the SIP derivate protocol for Instant Messaging and presence.

Convergence effort must be sustained

This increasing adoption of the XMPP protocol comes with the necessity to strengthen the standard as this adoption also contains its own threat of fragmentation.

This is where the XMPP community veterans must gather, be strong to push the original principles behind the XMPP standards and collaborate to stand as a united community. The temptation to fragment the XMPP community already exists. A long time ago, a standard protocol to allow developers to write components have been invented.  It was a very good idea, promoting the idea that many XMPP server implementations could coexist, but that they should share a common component base. A component developer should be able to deploy a component on all existing server implementations.

This is what should happen in an ideal world. In the real world this protocol has not changed since a long time. Its status is unsure and the number of possible interactions with the server is limited. The protocol defines communication and not integration programming interfaces. As a result, server developers have started implementing their own internal module protocol to leverage all the features of the server. This approach is fragmenting the XMPP community: An extension developer has to choose for which server he wants to develop an extension. For example, we are now seeing a trend where gateway developers are targeting a specific implementation. This is something we would not like to see, but instead we should have different gateway implementation that can be compared, replaced and used on a broad range of XMPP servers. Py* gateways are still there fortunately and should be promoted. The same approach is valid for ejabberd too. We have a pubsub module that can only be used on our server and this is not the way to go. Our pubsub module should be usable on any server.

To avoid this fragmentation and boost convergence, we need to revive the XEP-0114 component protocol, definind are launching an initiative to make the XEP-0114 more general. Our target is to define a formal development API that gradually increase what an external component developer can do with any XMPP server. The best is probably to use a new namespace and to define a new XEP (XMPP Extensions Protocol) that will improve the current API without taking the risk of breaking existing components.

There have already been several proposals to enhance this protocol. Jérôme Sautret, from ProcessOne, has started studying all of them. He needs use cases to be sure that the most important part will be added first. You can add your feedback as a comment of this post. The discussion will be brought to the XSF wiki.

References:

 


Let us know what you think 💬


Leave a Comment


This site uses Akismet to reduce spam. Learn how your comment data is processed.