Jump to content

XMPP: Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
Maggu (talk | contribs)
505 edits
Use full XEP title in footnotes
Line 86: Line 86:
== XMPP and HTTP ==
== XMPP and HTTP ==


Another aspect of XMPP is the [[Hypertext Transfer Protocol|HTTP]] binding for users behind restricted [[firewall (networking)|firewalls]]. In the original specification, XMPP could use HTTP in two ways: ''polling''<ref>[http://www.xmpp.org/extensions/xep-0025.html XEP-0025]</ref> and ''binding''.<ref>[http://www.xmpp.org/extensions/xep-0124.html XEP-0124]</ref> Polling is now deprecated, but HTTP polling essentially implies messages stored on a server-side database are being fetched (and posted) regularly by an XMPP client by way of HTTP 'GET' and 'POST' requests. With binding, the client uses longer-lived HTTP connections to receive messages 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.
Another aspect of XMPP is the [[Hypertext Transfer Protocol|HTTP]] binding for users behind restricted [[firewall (networking)|firewalls]]. In the original specification, XMPP could use HTTP in two ways: ''polling''<ref>[http://www.xmpp.org/extensions/xep-0025.html XEP-0025: Jabber HTTP Polling]</ref> and ''binding''.<ref>[http://www.xmpp.org/extensions/xep-0124.html XEP-0124: Bidirectional-streams Over Synchronous HTTP (BOSH)]</ref> Polling is now deprecated, but HTTP polling essentially implies messages stored on a server-side database are being fetched (and posted) regularly by an XMPP client by way of HTTP 'GET' and 'POST' requests. With binding, the client uses longer-lived HTTP connections to receive messages 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 would allow the client to fetch and post messages without any hindrance. Thus, in scenarios where the [[Transmission Control Protocol|TCP]] port used by XMPP is blocked, a server can listen on the normal HTTP port and the traffic should pass without problems. There also are various websites which allow people to sign in to Jabber via their browser. Also, there are some open public servers, like [http://www.jabber80.com/ www.jabber80.com] that listen on standard http (port 80) and https (port 443) ports and hence allow connections from behind most firewalls.
Because the client uses HTTP, most firewalls would allow the client to fetch and post messages without any hindrance. Thus, in scenarios where the [[Transmission Control Protocol|TCP]] port used by XMPP is blocked, a server can listen on the normal HTTP port and the traffic should pass without problems. There also are various websites which allow people to sign in to Jabber via their browser. Also, there are some open public servers, like [http://www.jabber80.com/ www.jabber80.com] that listen on standard http (port 80) and https (port 443) ports and hence allow connections from behind most firewalls.
Line 121: Line 121:
* RFC 3921, ''Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence'' describes [[instant messaging]] (IM), the most common application of XMPP.
* RFC 3921, ''Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence'' describes [[instant messaging]] (IM), the most common application of XMPP.
* RFC 3922, ''Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)'' relates XMPP and the Common Presence and Instant Messaging (CPIM) specifications.
* RFC 3922, ''Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM)'' relates XMPP and the Common Presence and Instant Messaging (CPIM) specifications.
* RFC 3923, ''End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)'' describes end to end [[encryption]] of XMPP messages using [[S/MIME]]. Conflicting this proposal, many clients currently use [[GNU Privacy Guard|GPG]] for encrypting messages.<ref>[http://www.xmpp.org/extensions/xep-0027.html XEP-0027]</ref>
* RFC 3923, ''End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP)'' describes end to end [[encryption]] of XMPP messages using [[S/MIME]]. Conflicting this proposal, many clients currently use [[GNU Privacy Guard|GPG]] for encrypting messages.<ref>[http://www.xmpp.org/extensions/xep-0027.html XEP-0027: Current Jabber OpenPGP Usage]</ref>


The XMPP Standards Foundation (XSF) develops and publishes extensions to XMPP through a standards process centered around ''XMPP Extension Protocols'' (XEPs, previously known as Jabber Enhancement Proposals - JEPs). The following extensions are in especially wide use:
The XMPP Standards Foundation (XSF) develops and publishes extensions to XMPP through a standards process centered around ''XMPP Extension Protocols'' (XEPs, previously known as Jabber Enhancement Proposals - JEPs). The following extensions are in especially wide use:


* Data Forms<ref>[http://www.xmpp.org/extensions/xep-0004.html XEP-0004]</ref>
* Data Forms<ref>[http://www.xmpp.org/extensions/xep-0004.html XEP-0004: Data Forms]</ref>
* Service Discovery<ref>[http://www.xmpp.org/extensions/xep-0030.html XEP-0030]</ref>
* Service Discovery<ref>[http://www.xmpp.org/extensions/xep-0030.html XEP-0030: Service Discovery]</ref>
* Multi-User Chat<ref>[http://www.xmpp.org/extensions/xep-0045.html XEP-0045]</ref>
* Multi-User Chat<ref>[http://www.xmpp.org/extensions/xep-0045.html XEP-0045: Multi-User Chat]</ref>
* XHTML-IM<ref>[http://www.xmpp.org/extensions/xep-0071.html XEP-0071]</ref>
* XHTML-IM<ref>[http://www.xmpp.org/extensions/xep-0071.html XEP-0071: XHTML-IM]</ref>
* File Transfer<ref>[http://www.xmpp.org/extensions/xep-0096.html XEP-0096]</ref>
* File Transfer<ref>[http://www.xmpp.org/extensions/xep-0096.html XEP-0096: File Transfer]</ref>
* Entity Capabilities<ref>[http://www.xmpp.org/extensions/xep-0115.html XEP-0115]</ref>
* Entity Capabilities<ref>[http://www.xmpp.org/extensions/xep-0115.html XEP-0115: Entity Capabilities]</ref>
* HTTP Binding<ref>[http://www.xmpp.org/extensions/xep-0124.html XEP-0124]</ref>
* HTTP Binding<ref>[http://www.xmpp.org/extensions/xep-0124.html XEP-0124: Bidirectional-streams Over Synchronous HTTP (BOSH)]</ref>


XMPP is also currently being extended to handle signalling / negotiation for [[Voice over Internet protocol]] (VoIP) and other media sessions. This signalling protocol is called [[Jingle (protocol)|Jingle]]. Jingle is designed to be consistent with the [[Google Talk]] service and interoperable with the [[Session Initiation Protocol]].
XMPP is also currently being extended to handle signalling / negotiation for [[Voice over Internet protocol]] (VoIP) and other media sessions. This signalling protocol is called [[Jingle (protocol)|Jingle]]. Jingle is designed to be consistent with the [[Google Talk]] service and interoperable with the [[Session Initiation Protocol]].

Revision as of 14:12, 28 March 2008

"Jabber" redirects here. For computer network overloading, see maximum transmission unit.
File:XMPP Logo.svg
Official logo of the XMPP Standards Foundation
Internet protocol suite
Application layer
Transport layer
Internet layer
Link layer

eXtensible Messaging and Presence Protocol (XMPP) (formerly known as Jabber) is an open, XML-inspired protocol for near real time, extensible instant messaging (IM) and presence information (a.k.a. buddy lists). The protocol is built to be extensible and other features such as Voice over IP and file transfer signaling have been added.

Unlike most instant messaging protocols, XMPP is based on open standards [1]. Like e-mail, it is an open system where anyone who has a domain name and a suitable Internet connection can run their own Jabber server and talk to users on other servers. The standard server implementations and many clients are also free and open source software.

The Internet Engineering Task Force (IETF) formed an XMPP Working Group in 2002 [2] to formalize the core protocols as an IETF Instant Messaging and presence technology. The four specifications produced by the XMPP WG were approved by the IESG as Proposed Standards in 2004. RFC 3920 and RFC 3921 are currently undergoing revisions (see Development) in preparation for advancing them to Draft Standard within the Internet Standards Process. The XMPP Standards Foundation (formerly the Jabber Software Foundation) is active in developing open XMPP extensions[3]. Unfortunately no Jabber technology correctly implements the RFCs in full.[citation needed]

XMPP-based software is deployed on thousands of servers across the Internet and by 2003 was used by over ten million people worldwide, according to the XMPP Standards Foundation.[1] Popular commercial servers include the Gizmo Project and Google Talk. Popular client applications include the freeware clients offered by Google and the Gizmo Project, multi-protocol instant messengers such as iChat and Pidgin (formerly Gaim), and free dedicated clients such as Psi.

History

Jeremie Miller began the Jabber project in 1998. Its first major public release occurred in May 2000. The project's main product was jabberd, a Jabber server.

This early Jabber protocol formed the basis for XMPP, published as RFC 3920. It has often been regarded as being in competition with SIMPLE, based on the SIP protocol, as the standard protocol for instant messaging and presence notification.
Jabber Software Foundation Renamed to XMPP Standards Foundation January 16, 2007 [4]
jabber.org is still maintained (March 2008)


As of 2005, about half a dozen XMPP server software implementations written in different programming languages and targeting different use cases existed.[citation needed]

In August 2005, Google introduced Google Talk, a combination VoIP and IM system which uses XMPP for its instant messaging function as well as a base for their voice and file transfer signalling protocol. The initial launch did not include server-to-server communications, but as of January 17, 2006, it has server-to-server communications enabled.[2]

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 has formalized XMPP as an approved instant messaging and presence technology under the name of XMPP, and the XMPP specifications have been published as RFC 3920 and RFC 3921. No royalties are required to implement support of these specifications and their development is not tied to a single vendor.
History
XMPP technologies have been in use since 1998. Multiple implementations of the XMPP standards exist for clients, servers, components, and code libraries, with the backing of large companies such as Sun Microsystems and Google.
Security
XMPP servers may be isolated from the public Jabber network (e.g., on a company intranet), and robust security (via SASL and TLS) has been built into the core XMPP specifications. To encourage use of channel encryption, the XMPP Standards Foundation also runs an intermediate certification authority at xmpp.net offering free digital certificates to XMPP server administrators under the auspices of the StartCom Certification Authority (which is the root CA for the intermediate CA).
Flexibility
Custom functionality can be built on top of XMPP; to maintain interoperability, common extensions are managed by the XMPP Software Foundation. XMPP applications beyond IM include network management, content syndication, collaboration tools, file sharing, gaming, and remote systems monitoring.

Weaknesses

Presence data overhead
With typically over 70% of XMPP inter-server traffic being presence data[3], and close to 60% of it being redundantly transmitted[4], XMPP currently has a large overhead in delivering presence data to multiple recipients. New protocols are being researched to alleviate this problem.
Scalability
XMPP currently suffers from essentially the same redundancy problem also concerning multi-user chat and publish/subscribe services.[5] These too are to be addressed by new protocol extensions. Until deployed, large chatrooms produce a very large amount of overhead.
No binary data
The way XMPP is encoded as a single long XML document makes it impossible to deliver unmodified binary data. File transfers are therefore arranged to happen using external protocols like HTTP. If unavoidable, XMPP also provides in-band file transfers by encoding all data using base64. Other binary data like encrypted conversations or graphic icons are embedded using the same method.

Decentralisation and addressing

The Jabber network is server-based (i.e. clients do not talk directly to one another) but decentralized; by design there is no central authoritative server, as there is with services such as AOL Instant Messenger or MSN Messenger. Some confusion often arises on this point as there is a public XMPP server being run at "Jabber.org", to which a large number of users subscribe. However, anyone may run their own XMPP server on their own domain.

Every user on the network has a unique Jabber ID (usually abbreviated as JID). To avoid the need for a central server with a list of IDs, the JID is structured like an e-mail address with a username and a DNS address for the server where that user resides separated by an at sign (@), such as username@domain.com.

Since a user may wish to log in from multiple locations, the server allows the client to specify a further string known as a resource, which identifies which of the user's clients it is (for example home, work and mobile). This may then be included in the JID by adding a forward slash followed by the name of the resource. Each resource may have specified a numerical value called priority. For example the full JID of a user's mobile account would be username@domain.com/mobile. Messages that are simply sent to username@domain.com will go to the client with highest priority, but those sent to username@domain.com/mobile will only go to the mobile client.

JIDs without a username part are also valid and may be used (with or without a resource part) for system messages and control of special features on the server.

Message delivery process

Suppose juliet@capulet.com wants to chat with romeo@montague.net. Juliet and Romeo each respectively have accounts on the capulet.com and montague.net servers. When Juliet types in and sends her message, a sequence of events is set in action:

  1. Juliet's client sends her message to the capulet.com server
    • If montague.net is blocked on capulet.com the message is dropped.
  2. The capulet.com server opens a connection to the montague.net server.
  3. The montague.net server delivers the message to Romeo
    • If capulet.com is blocked on montague.net, the message is dropped.
    • If Romeo is not currently connected, the message is stored for later delivery.
Juliet ↔ capulet.com → montague.net ↔ Romeo

Connecting to other protocols

Alice sends a message through the Jabber net to the ICQ transport. The message next is routed to Bobs by the ICQ network.

Another useful feature of the XMPP system is that of transports, also known as gateways, which allow users to access networks using other protocols. This can be other instant messaging protocols, but also protocols such as SMS or E-mail. Unlike multi-protocol clients, XMPP provides this access at the server level by communicating via special gateway services running on a remote computer. 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 Jabber users. This means that any client which fully supports XMPP can be used to access any network to which a gateway exists, without the need for any extra code in the client and without the need for the client to have direct access to the Internet. This may violate terms of service on the protocol used; however, such terms of service are not legally enforceable in several countries.

XMPP and HTTP

Another aspect of XMPP is the HTTP binding for users behind restricted firewalls. In the original specification, XMPP could use HTTP in two ways: polling[6] and binding.[7] Polling is now deprecated, but HTTP polling essentially implies messages stored on a server-side database are being fetched (and posted) regularly by an XMPP client by way of HTTP 'GET' and 'POST' requests. With binding, the client uses longer-lived HTTP connections to receive messages 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 would allow the client to fetch and post messages without any hindrance. 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. There also are various websites which allow people to sign in to Jabber via their browser. Also, there are some open public servers, like www.jabber80.com that listen on standard http (port 80) and https (port 443) ports and hence allow connections from behind most firewalls.

Uptake and clients

Main article: List of Jabber client software

XMPP is implemented by a large number of XMPP clients, servers, and code libraries. These include:

Development

The IETF XMPP working group has produced a number of RFC protocol documents:

RFC 3920, RFC 3921, RFC 3922, RFC 3923, RFC 4622, RFC 4854, RFC 4979

  • RFC 3920, Extensible Messaging and Presence Protocol (XMPP): Core which describes client-server messaging using two open ended XML streams. XML streams consist of <presence/>, <message/> and <iq/> (info/query). A connection is authenticated with Simple Authentication and Security Layer (SASL) and encrypted with Transport Layer Security (TLS).
  • RFC 3921, Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence describes instant messaging (IM), the most common application of XMPP.
  • RFC 3922, Mapping the Extensible Messaging and Presence Protocol (XMPP) to Common Presence and Instant Messaging (CPIM) relates XMPP and the Common Presence and Instant Messaging (CPIM) specifications.
  • RFC 3923, End-to-End Signing and Object Encryption for the Extensible Messaging and Presence Protocol (XMPP) describes end to end encryption of XMPP messages using S/MIME. Conflicting this proposal, many clients currently use GPG for encrypting messages.[8]

The XMPP Standards Foundation (XSF) develops and publishes extensions to XMPP through a standards process centered around XMPP Extension Protocols (XEPs, previously known as Jabber Enhancement Proposals - JEPs). The following extensions are in especially wide use:

XMPP is also currently being extended to handle signalling / negotiation for Voice over Internet protocol (VoIP) and other media sessions. This signalling protocol is called Jingle. Jingle is designed to be consistent with the Google Talk service and interoperable with the Session Initiation Protocol.

References

  1. ^ "Jabber Instant Messaging User Base Surpasses ICQ" (Press release). XMPP Standards Foundation. 2003-09-22. Retrieved 2007-11-30.
  2. ^ Burd, Gary. "XMPP Federation". Retrieved 2007-11-30.
  3. ^ http://mail.jabber.org/pipermail/standards/2006-May/011158.html
  4. ^ http://mail.jabber.org/pipermail/standards/2006-May/011182.html
  5. ^ http://mail.jabber.org/pipermail/standards/2006-February/010028.html
  6. ^ XEP-0025: Jabber HTTP Polling
  7. ^ XEP-0124: Bidirectional-streams Over Synchronous HTTP (BOSH)
  8. ^ XEP-0027: Current Jabber OpenPGP Usage
  9. ^ XEP-0004: Data Forms
  10. ^ XEP-0030: Service Discovery
  11. ^ XEP-0045: Multi-User Chat
  12. ^ XEP-0071: XHTML-IM
  13. ^ XEP-0096: File Transfer
  14. ^ XEP-0115: Entity Capabilities
  15. ^ XEP-0124: Bidirectional-streams Over Synchronous HTTP (BOSH)

See also

Retrieved from "https://en.wikipedia.org/w/index.php?title=XMPP&oldid=201577568"