Microsoft Enables XMPP in Windows Live Messenger, but Questions Remain

P. J. Connolly began writing for IT publications in 1997 and has a lengthy track record in both news and reviews. Since then, he's built two test labs from scratch and earned a reputation as the nicest skeptic you'll ever meet. Before taking up journalism, P. J. was an IT manager and consultant in San Francisco with a knack for networking the Apple Macintosh, and his love for technology is exceeded only by his contempt for the flavor of the month. Speaking of which, you can follow P. J. on Twitter at pjc415, or drop him an email at
By P. J. Connolly  |  Posted 2011-12-30 Email Print this article Print

A lot of things happened this year to make me wonder if it isn't time to stop covering technology for a living, but a couple of weeks ago, I was given a ray of hope, in the form of Microsoft's exposure of an XMPP interface for the Windows Live Messenger network.


Microsoft has cracked the door on XMPP support in Windows Live Messenger; 2012 is the time for the company to kick it open.

People who know me might be a little surprised by that, because if there's one technology that I simply cannot abide, it's instant messaging. As I've said elsewhere, it combines the worst features of telephone and e-mail by mixing synchronous conversations (e.g., the telephone) with asynchronous ones, and gives the user a third tool that has to be monitored throughout the work day, if not 24x7. In my experience, "instant pestering" is a tool beloved by bosses who don't trust their employees to work without constant supervision.Nevertheless, I recognize that a lot of work gets done over IM, and generally, end-users seem to like having it at their disposal. The problem is that historically, IM clouds developed as relatively closed systems; although tools such as Trillian sprang up to bridge the competing clouds offered by AOL, Microsoft, Yahoo and others, at first these were fairly kludgy, breaking every time the provider made a change to the back end of the IM service. What was needed was a universal protocol for IM, and XMPP was the answer.

XMPP - the eXtensible Messaging and Presence Protocol - began its life in 1999 as the Jabber project, and is now a de facto standard for communication among the various IM clouds. How far each IM service goes in utilizing XMPP is a complicated story, however; GoogleTalk may be the closest thing to a major service using XMPP whole-hog, but services such as AOL Instant Messenger (and Apple iChat, which piggybacks on AOL's implementation) Facebook Chat and Meebo all implement XMPP to one degree or another. Even corporate IM standbys such as IBM Lotus Sametime can take advantage of XMPP through a gateway service.

So what Microsoft's done is open up the Messenger network, allowing developers to write their own client software that authenticates using OAuth 2.0. For now, the XMPP support is limited to the core specification (RFC 6120), most of the instant messaging and presence specs (RFC 6121, except for roster management), fetching of vCards (but not updating them), chat state notifications, and delivery delay; nevertheless, that's more than enough to get the ball rolling.

Although some observers have argued that the most important thing for Microsoft to do with XMPP at this time is to incorporate federation, which would allow the service to interoperate with services such as Google Talk, I see a bigger opportunity that would actually improve the usefulness of XMPP community-wide, and that's in the way certain XMPP traffic is handled. Currently, an XMPP message is sent as an XML document, which is fine for ordinary text, but horrible for binary attachments. The latter have to be encoded as a Base64 file, as is done with e-mail attachments that use MIME; until an truly efficient binary XML scheme is developed - and Efficient XML Interchange (EXI) isn't it - XMPP will just have to make do.

But if Microsoft really wanted to give something back to the community, it could do a lot worse than to put some of its best brains on the chore of making binary XML work well, without requiring the recipient to have a copy of the data schema, as is the case with EXI. |

Submit a Comment

Loading Comments...

Manage your Newsletters: Login   Register My Newsletters

Rocket Fuel