Everyone knows that binary data encodings are much more efficient than the Extensible Markup Language (XML). Given that XMPP is an application profile of XML, it is a wonder that XMPP works at all! Clearly, XMPP would benefit from a binary representation. Therefore, this specification defines Binary XMPP.

&xmppcore; defines the traditional representation of XMPP. For instance, an empty presence stanza (such as might be provided on login) is as follows:

That string can be represented in binary as follows:

The bit sequence is therefore represented in Binary XMPP as follows (line breaks are provided only for the purpose of readability):

This is an obvious improvement over the traditional representation.

It might be objected that the Binary XMPP representation requires a large number of XML elements. However, because all data is represented using only <zero/> and <one/>, the protocol can be significantly compressed using the standard ZLIB compression algorithm as defined in &rfc1950;, which SHOULD be enabled by default on the bxmpp port. Evidence from preliminary testing indicates that compression of Binary XMPP results in a representation less than 2% of the original size!

As a further simplification, Binary XMPP gets rid of the complicated stream negotiation process defined in RFC 3920. Instead, if a server supports Binary XMPP it advertises a special DNS SRV record _bxmpp._tcp in accordance with &rfc2782;. Furthermore, only one record is needed, thus saving precious port space. The RECOMMENDED port for Binary XMPP communication is 10110, but any port MAY be used.

To start a Binary XMPP stream, the sender simply connects via TCP at the advertised port and starts sending <zero/> and <one/> elements. The lack of a stream header simplifies XML parsing, introducing further performance improvements.

The following examples showcase the tremendous efficiency of Binary XMPP using a complete session between a client and a server.

And so on. Much more efficient, eh?

The <zero/> and <one/> elements use English-language words as the element names. Clearly it would have been preferable to define an i18n-friendly binding, such that German-language applications could encode Binary XMPP using the <null/> and <eins/> elements, Greek-language applications could use the <μηδέν/> and <ἑνα/> elements, etc. Flexibility regarding internationalization of the element names may be added in Binary XMPP 2.0.

Because it is simply an alternative representation of XMPP, Binary XMPP inherits all of the security characteristics of XMPP (the good, the bad, and the ugly).

Use of port 10110 is obviously secure, since 10110 in base 2 is 22 in base 10, the same default port as Secure Shell (see &rfc4251;).

The ®ISTRAR; shall work with &IANA; to register "bxmpp" as a keyword for port 10111.

The XMPP Registrar shall include 'urn:xmpp:bxmpp' in its registry of protocol namespaces (see &NAMESPACES;).

Thanks to Kevin Smith for his feedback.