Open alternatives to XMPP?

Open alternatives to XMPP?

Posted Jun 29, 2013 14:59 UTC (Sat) by(subscriber, #79651)Parent article: Nemeth: How Google pulled the plug on the public Jabber Network

Has there ever been any serious examination of, say, SIMPLE as an alternative open IM protocol, instead of defaulting to XMPP? Or is SIMPLE a design-by-committee boondoggle created in the interests of placing a "standards-compliant" bullet point on VoIP equipment marketing glossies?

Honestly I've never been a great fan of XMPP. Its entire design just smells wrong. It's not a presence system or an IM system, it's an "XML message switch", which just screams architecture astronauts to me, and it was created at the peak of the industry's drunken XML-everywhere frenzy. Human-to-human and computer-to-computer realtime messaging share some superficial similarities, but not enough that lumping them into some universal message routing protocol is worthwhile.

There are valid technical criticisms of the protocol as well, nicely summarised in [1] [2] (cited from here). Bear in mind that an XMPP session is one big long unbroken XML document, the intent being that the peers on each end of this conversation use an event-driven XML parser connected that drives an XMPP protocol state machine. One of the biggest criticisms is that it looks somewhat like XML, but it isn't quite XML, or even a subset of XML; certain XML constructions are not valid in XMPP sessions, and an in-session switch to a compressed or encrypted transport results in an aborted XML document whose context is resumed mid-document within a different transport layer. As a result, the XML parser has to be specially adapted to accommodate XMPP's quirks, or the server has to implement its own XMPP-flavoured XML parser instead of re-using an existing one.

XML is also a lousy fit for this particular use case as well; we'll ignore the fact that most of the protocol content isn't a heterogeneous mix of text and markup, because this is true of virtually every application XML is (ab)used for. Binary content such as end-to-end encrypted messages must be base64 escaped, which adds processing and transmission overhead. There is no payload length encoding in the message headers, so the message content has to be parsed by the server, and a complete XML DOM fragment must be re-constituted and serialised out to the destination. Also, though I have no basis for making this claim, I imagine that XML namespaces must complicate all of this processing tremendously, so again, the protocol has high overheads. The fact that not a single major IM network with an external XMPP interface uses XMPP internally for server-to-server routing is also particularly telling. Nor does Google consider XMPP to be practical for mobile clients, which I think is the point where they decided that XMPP wasn't going to work as an interface to Google Talk.

XMPP, by all indications, is a fundamentally bad protocol that is over-designed and over-ambitious, and is a poor fit for the Internet today. It does not do one specific thing, and what it does attempt to do it does not do well. As a community we need to learn from its mistakes and move on, instead of trying to keep pushing this overburdened and impractical standard. Given its provenance I seriously doubt that SIMPLE is a better solution in any way, but we should probably at least look beyond XMPP to begin with.