That's right DIGEST-MD5, your job is done here. Now it's time for the new kid to take up your place.

Those of you who ever tried to actually implement the DIGEST-MD5 SASL mechanism for authentication know that it suffers from quite a few problems, including but not limited to a variety of different implementations with a variable level of compliance to the DIGEST-MD5 RFC 2831. These interoperability problems make it quite hard to get a new implementation working with most of the already existing implementations.

SASL mechanisms are designed to be protocol-independent. That's basically the whole idea about SASL; to abstract the authentication part out of the application protocols, and standardize it. However DIGEST-MD5 already started off on the wrong foot.

Due to Waqas's asking for months now I've finally got around and made some benchmarks on two string prepping libraries. The one being libidn, as far as I know most XMPP servers use this and the other being ICU by IBM.

While libidn is LGPL licensed with ICU you have nearly all freedom with the choice of license for your project, due to MIT license.

Current XMPP standard says that every JID must be string prepped so if you don't want to cache because of memory reasons your string prepping routines are called quite often. It turns out ICU is much faster than libidn. For this benchmark I tested a couple of strings and let them go through nameprep, resourceprep and nodeprep profiles via string prepping.

Since quite a month there is a new XMPP server on the market, called Prosody. Today version 0.2.0 has been released with some new features which you can all read up in the release notes.

Version 0.2.0 has been released just one month after version 0.1.0 and four months after development began. With currently nearly one month between a release and the next we have a good release frequency which is fairly important for a project, especially for one which focuses on ease of prototyping new features in and a protocol around it like XMPP with is evolving pretty fast.

Since XMPP is (becomming) the biggest player from all the instant messaging protocols out there, there are a lot Google Summer of Code™ projects in the XMPP field this year. BOSH, the highly discussed dream team for connecting to XMPP from mobile or other limited network environments, is covered by a lot projects this year.
My GSoC project is, not only, about adding BOSH support to libpurple, the C instant messaging library which powers desktop clients like Pidgin and Adium and web clients like Meebo. libpurple doesn't only cover nearly any proprietary instant messaging protocol but also some open protocols like IRC, SILC and of course XMPP. For XMPP, as the (future) major instant messaging protocol, it's most important that XEPs get implemented, coded and used in real life. There is a huge number of XEPs which aren't implemented and may never be, who knows.

Here I present some charts on XEPs, XMPP Enhancement Proposals, and their development. You can see, most XEPs are either in Experimental or Draft status. The one and only final XEPs are currently:

• XEP-0077: In-Band Registration
• XEP-0030: Service Discovery
• XEP-0009: Jabber-RPC
• XEP-0004: Data Forms

There have been two XEP source files unprocessable in XMPP's repository because of invalid XML and since the reposity only exists since end 2006 no longer history was accessable.

These charts have been generated by OpenOffice.org and some custom python script which worked on XSF's svn repository.