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.
XMPP CoreRFC 6120: Extensible Messaging and Presence Protocol (XMPP): Core <http://tools.ietf.org/html/rfc6120>. 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 RFC 1950RFC 1950: ZLIB Compressed Data Format Specification version 3.3 <http://tools.ietf.org/html/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 RFC 2782RFC 2782: A DNS RR for specifying the location of services (DNS SRV) <http://tools.ietf.org/html/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 RFC 4251RFC 4251: The Secure Shell (SSH) Protocol Architecture <http://tools.ietf.org/html/rfc4251>.).
The XMPP RegistrarThe XMPP Registrar maintains a list of reserved protocol namespaces as well as registries of parameters used in the context of XMPP extension protocols approved by the XMPP Standards Foundation. For further information, see <https://xmpp.org/registrar/>. shall work with the Internet Assigned Numbers Authority (IANA)The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>. to register "bxmpp" as a keyword for port 10111.
The XMPP Registrar shall include 'urn:xmpp:bxmpp' in its registry of protocol namespaces (see <https://xmpp.org/registrar/namespaces.html>).