XMPP


Extensible Messaging and Presence Protocol is a communication protocol for message-oriented middleware based on XML. It enables the near-real-time exchange of structured yet extensible data between any two or more network entities. Originally named Jabber, the protocol was developed by the eponymous open-source community in 1999 for near real-time instant messaging, presence information, and contact list maintenance. Designed to be extensible, the protocol has been used also for publish-subscribe systems, signalling for VoIP, video, file transfer, gaming, the Internet of Things applications such as the smart grid, and social networking services.
Unlike most instant messaging protocols, XMPP is defined in an open standard and uses an open systems approach of development and application, by which anyone may implement an XMPP service and interoperate with other organizations' implementations. Because XMPP is an open protocol, implementations can be developed using any software license and many server, client, and library implementations are distributed as free and open-source software. Numerous freeware and commercial software implementations also exist.
The Internet Engineering Task Force formed an XMPP working group in 2002 to formalize the core protocols as an IETF instant messaging and presence technology. The XMPP Working group produced four specifications, which were approved as Proposed Standards in 2004. In 2011, RFC 3920 and RFC 3921 were superseded by RFC 6120 and RFC 6121 respectively, with RFC 6122 specifying the XMPP address format. In 2015, RFC 6122 was superseded by RFC 7622. In addition to these core protocols standardized at the IETF, the XMPP Standards Foundation is active in developing open XMPP extensions.
XMPP-based software is deployed widely across the Internet, and by 2003, was used by over ten million people worldwide, according to the XMPP Standards Foundation.

History

began working on the Jabber technology in 1998 and released the first version of the jabberd server on January 4, 1999. The early Jabber community focused on open-source software, mainly the jabberd server, but its major outcome proved to be the development of the XMPP protocol.
The early Jabber protocol, as developed in 1999 and 2000, formed the basis for XMPP as published in RFC 3920 and RFC 3921 in October 2004. Note that RFC 3920 and RFC 3921 have been superseded by RFC 6120 and RFC 6121, published in 2011.
The first IM service based on XMPP was Jabber.org, which has operated continuously and offered free accounts since 1999. From 1999 until February 2006, the service used jabberd as its server software, at which time it migrated to ejabberd. In January 2010, the service migrated to the proprietary M-Link server software produced by Isode Ltd.
In August 2005, Google introduced Google Talk, a combination VoIP and IM system that uses XMPP for instant messaging and as a base for a voice and file transfer signaling protocol called Jingle. The initial launch did not include server-to-server communications; Google enabled that feature on January 17, 2006. Google has since added video functionality to Google Talk, also using the Jingle protocol for signaling. In May 2013, Google announced XMPP compatibility would be dropped from Google Talk for server-to-server federation, although it would retain client-to-server support.
In January 2008, AOL introduced experimental XMPP support for its AOL Instant Messenger service, allowing AIM users to communicate using XMPP. However, in March 2008, this service was discontinued. As of May 2011, AOL offers limited XMPP support.
In September 2008, Cisco Systems acquired Jabber, Inc., the creators of the commercial product Jabber XCP.
In February 2010, the social-networking site Facebook opened up its chat feature to third-party applications via XMPP. Some functionality was unavailable through XMPP, and support was dropped in April 2014.
Similarly, in December 2011, Microsoft released an XMPP interface to its Microsoft Messenger service. Skype, its de facto successor, also provides limited XMPP support. However, these are not native XMPP implementations.

Federation

Decentralization and addressing

The XMPP network uses a client–server architecture; clients do not talk directly to one another. The model is decentralized - anyone can run a server. By design, there is no central authoritative server as there is with services such as AOL Instant Messenger or Windows Live Messenger. Some confusion often arises on this point as there is a public XMPP server being run at jabber.org, to which many users subscribe. However, anyone may run their own XMPP server on their own domain.
Every user on the network has a unique XMPP address, called JID. The JID is structured like an email address with a username and a domain name for the server where that user resides, separated by an at sign, such as [email protected].
Since a user may wish to log in from multiple locations, they may specify a resource. A resource identifies a particular client belonging to the user. This may be included in the JID by appending a slash followed by the name of the resource. For example, the full JID of a user's mobile account could be [email protected]/mobile.
Each resource may have specified a numerical value called priority. Messages simply sent to [email protected] will go to the client with highest priority, but those sent to [email protected]/mobile will go only to the mobile client. The highest priority is the one with largest numerical value.
JIDs without a username part are also valid, and may be used for system messages and control of special features on the server. A resource remains optional for these JIDs as well.
The means to route messages based on a logical endpoint identifier - the JID, instead of by an explicit IP Address present opportunities to use XMPP as an Overlay network implementation on top of different underlay networks.

Connecting to other protocols

One of the original design goals of the early Jabber open-source community was enabling users to connect to multiple instant messaging systems through a single client application. This was done through entities called transports or gateways to other instant messaging protocols, but also to protocols such as SMS or email. Unlike multi-protocol clients, XMPP provides this access at the server level by communicating via special gateway services running alongside an XMPP server. Any user can "register" with one of these gateways by providing the information needed to log on to that network, and can then communicate with users of that network as though they were XMPP users. Thus, such gateways function as client proxies. As a result, any client that fully supports XMPP can access any network with a gateway without extra code in the client, and without the need for the client to have direct access to the Internet. However, the client proxy model may violate terms of service on the protocol used and also requires the user to send their IM username and password to the third-party site that operates the transport.
Another type of gateway is a server-to-server gateway, which enables a non-XMPP server deployment to connect to native XMPP servers using the built in interdomain federation features of XMPP. Such server-to-server gateways are offered by several enterprise IM software products, including:
XMPP provides a general framework for messaging across a network, which offers a multitude of applications beyond traditional Instant Messaging and the distribution of Presence data. While several service discovery protocols exist today, XMPP provides a solid base for the discovery of services residing locally or across a network, and the availability of these services, as specified by XEP-0030 DISCO.
Building on its capability to support discovery across local network domains, XMPP is well-suited for cloud computing where virtual machines, networks, and firewalls would otherwise present obstacles to alternative service discovery and presence-based solutions. Cloud computing and storage systems rely on various forms of communication over multiple levels, including not only messaging between systems to relay state but also the migration or distribution of larger objects, such as storage or virtual machines. Along with authentication and in-transit data protection, XMPP can be applied at a variety of levels and may prove ideal as an extensible middleware or Message-oriented middleware protocol. Widely known for its ability to exchange XML-based content natively, it has become an open platform for the exchange of other forms of content including proprietary binary streams, full motion video content, and the transport of file-based content, via for example the Jingle series of extensions. Here the majority of the applications have nothing to do with human communications but instead provide an open means to support machine-to-machine or peer-to-peer communications across a diverse set of networks.

Implementations

XMPP is implemented by many clients, servers, and code libraries. These implementations are provided under a variety of software licenses.

XMPP via HTTP

The original and "native" transport protocol for XMPP is Transmission Control Protocol, using open-ended XML streams over long-lived TCP connections.
As an alternative to the TCP transport, the XMPP community has also developed an HTTP transport for web clients as well as users behind restricted firewalls. In the original specification, XMPP could use HTTP in two ways: polling and binding. The polling method, now deprecated, essentially implies messages stored on a server-side database are being fetched regularly by an XMPP client by way of HTTP 'GET' and 'POST' requests. The binding method, implemented using Bidirectional-streams Over Synchronous HTTP, allows servers to push messages to clients as soon as they are sent. This push model of notification is more efficient than polling, where many of the polls return no new data.
Because the client uses HTTP, most firewalls allow clients to fetch and post messages without any hindrances. Thus, in scenarios where the TCP port used by XMPP is blocked, a server can listen on the normal HTTP port and the traffic should pass without problems. Various websites let people sign into XMPP via a browser. Furthermore, there are open public servers that listen on standard http and https ports, and hence allow connections from behind most firewalls. However, the IANA-registered port for BOSH is actually 5280, not 80.

Deployments

Several large public IM services natively use XMPP, including LiveJournal's "LJ Talk", Nimbuzz, and HipChat. Various hosting services, such as DreamHost, enable hosting customers to choose XMPP services alongside more traditional web and email services. Specialized XMPP hosting services also exist in form of cloud so that domain owners need not directly run their own XMPP servers, including Cisco Webex Connect, Chrome.pl, , i-pobox.net, and hosted.im.
Some of the largest messaging providers use, or have been using, various forms of XMPP based protocols in their backend systems without necessarily exposing this fact to their end users. This includes WhatsApp, Google Talk and Facebook Chat. Most of these deployments are built on the free-software, Erlang-based XMPP server called ejabberd.
XMPP is also used in deployments of non-IM services, including smart grid systems such as demand response applications, message-oriented middleware, and as a replacement for SMS to provide text messaging on many smartphone clients.
XMPP is the de facto standard for private chat in gaming related platforms such as Origin, Raptr, PlayStation, and the now discontinued Xfire. Two notable exceptions are Steam and Xbox LIVE; both use their own proprietary messaging protocols.

Development

XSF

The XMPP Standards Foundation develops and publishes extensions to XMPP through a standards process centered on XMPP Extension Protocols. The following extensions are in especially wide use:
XMPP features such as federation across domains, publish/subscribe, authentication and its security even for mobile endpoints are being used to implement the Internet of Things. Several XMPP extensions are part of the experimental implementation: Efficient XML Interchange Format; Sensor Data; Provisioning; Control; Concentrators; Discovery.
These efforts are documented on a page in the XMPP wiki dedicated to Internet of Things and the XMPP IoT mailing list.

Specifications and standards

The IETF XMPP working group has produced a series of Request for Comments documents:
The most important and most widely implemented of these specifications are:
XMPP has often been regarded as a competitor to SIMPLE, based on Session Initiation Protocol, as the standard protocol for instant messaging and presence notification.
The XMPP extension for multi-user chat can be seen as a competitor to Internet Relay Chat, although IRC is far simpler, has far fewer features, and is far more widely used.
The XMPP extensions for publish-subscribe provide many of the same features as the Advanced Message Queuing Protocol.

Features

Strengths

;Decentralization: The architecture of the XMPP network is similar to email; anyone can run their own XMPP server and there is no central master server.
;Open standards: The Internet Engineering Task Force formalized XMPP as an approved instant messaging and presence technology under the name of XMPP. No royalties or granted permissions are required to implement these specifications.
;History: XMPP technologies have been in use since 1999. Many implementations of the XMPP standards exist for clients, servers, components, and code libraries.
;Security: XMPP servers can be isolated, and secure authentication and point-to-point encryption have been built into the core XMPP specifications, as well as multi-end-to-multi-end encryption.
;Flexibility: Custom functionality can be built on top of XMPP. To maintain interoperability, common extensions are managed by the XMPP Standards Foundation. XMPP applications beyond IM include chat rooms, network management, content syndication, collaboration tools, file sharing, gaming, remote systems control and monitoring, geolocation, middleware and cloud computing, VoIP, and identity services.

Weaknesses

;Does not support Quality of Service : Assured delivery of messages has to be built on-top of the XMPP layer. There are two XEPs proposed to deal with this issue, which is a draft standard, and which is considered experimental.
;Text-based communication: Since XML is text based, normal XMPP has a higher network overhead compared to purely binary solutions. This issue is being addressed by the experimental , where XML is serialized in a very efficient binary manner, especially in schema-informed mode.
;In-band binary data transfer is limited: Binary data must be first base64 encoded before it can be transmitted in-band. Therefore, any significant amount of binary data is best transmitted out-of-band, using in-band messages to coordinate. The best example of this is the Jingle XMPP Extension Protocol, .

Extensions

The XMPP Standards Foundation or XSF is active in developing open XMPP extensions, so called XEP. However, extensions can also be defined by any individual, software project, or organization. Another example is the federation protocol in Apache Wave, which is based on XMPP.