Request for Comments: 3920 Jabber Software Foundation
Category: Standards Track October 2004
Extensible Messaging and Presence Protocol (XMPP): Core
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This memo defines the core features of the Extensible Messaging and
Presence Protocol (XMPP), a protocol for streaming Extensible Markup
Language (XML) elements in order to exchange structured information
in close to real time between any two network endpoints. While XMPP
provides a generalized, extensible framework for exchanging XML data,
it is used mainly for the purpose of building instant messaging and
presence applications that meet the requirements of RFC 2779.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Generalized Architecture . . . . . . . . . . . . . . . . . . 3
3. Addressing Scheme . . . . . . . . . . . . . . . . . . . . . 5
4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Use of TLS . . . . . . . . . . . . . . . . . . . . . . . . . 19
6. Use of SASL . . . . . . . . . . . . . . . . . . . . . . . . 27
7. Resource Binding . . . . . . . . . . . . . . . . . . . . . . 37
8. Server Dialback . . . . . . . . . . . . . . . . . . . . . . 41
9. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . 48
10. Server Rules for Handling XML Stanzas . . . . . . . . . . . 58
11. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 60
12. Core Compliance Requirements . . . . . . . . . . . . . . . . 62
13. Internationalization Considerations . . . . . . . . . . . . 64
14. Security Considerations . . . . . . . . . . . . . . . . . . 64
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 69
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 71
A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . . . . . 75
B. Resourceprep . . . . . . . . . . . . . . . . . . . . . . . . 76
C. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . 78
D. Differences Between Core Jabber Protocols and XMPP . . . . . 87
Contributors. . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . . . 89
Author’s Address. . . . . . . . . . . . . . . . . . . . . . . . . 89
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 90
1. Introduction
1.1. Overview
The Extensible Messaging and Presence Protocol (XMPP) is an open
Extensible Markup Language [XML] protocol for near-real-time
messaging, presence, and request-response services. The basic syntax
and semantics were developed originally within the Jabber open-source
community, mainly in 1999. In 2002, the XMPP WG was chartered with
developing an adaptation of the Jabber protocol that would be
suitable as an IETF instant messaging (IM) and presence technology.
As a result of work by the XMPP WG, the current memo defines the core
features of XMPP 1.0; the extensions required to provide the instant
messaging and presence functionality defined in RFC 2779 [IMP-REQS]
are specified in the Extensible Messaging and Presence Protocol
(XMPP): Instant Messaging and Presence [XMPP-IM].
1.2. Terminology
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14, RFC 2119 [TERMS].
2. Generalized Architecture
2.1. Overview
Although XMPP is not wedded to any specific network architecture, to
date it usually has been implemented via a client-server architecture
wherein a client utilizing XMPP accesses a server over a [TCP]
connection, and servers also communicate with each other over TCP
connections.
The following diagram provides a high-level overview of this
architecture (where "-" represents communications that use XMPP and
"=" represents communications that use any other protocol).
C1----S1---S2---C3
|
C2----+--G1===FN1===FC1
The symbols are as follows:
o C1, C2, C3 = XMPP clients
o S1, S2 = XMPP servers
o G1 = A gateway that translates between XMPP and the protocol(s)
used on a foreign (non-XMPP) messaging network
o FN1 = A foreign messaging network
o FC1 = A client on a foreign messaging network
2.2. Server
A server acts as an intelligent abstraction layer for XMPP
communications. Its primary responsibilities are:
o to manage connections from or sessions for other entities, in the
form of XML streams (Section 4) to and from authorized clients,
servers, and other entities
o to route appropriately-addressed XML stanzas (Section 9) among
such entities over XML streams
Most XMPP-compliant servers also assume responsibility for the
storage of data that is used by clients (e.g., contact lists for
users of XMPP-based instant messaging and presence applications); in
this case, the XML data is processed directly by the server itself on
behalf of the client and is not routed to another entity.
2.3. Client
Most clients connect directly to a server over a [TCP] connection and
use XMPP to take full advantage of the functionality provided by a
server and any associated services. Multiple resources (e.g.,
devices or locations) MAY connect simultaneously to a server on
behalf of each authorized client, with each resource differentiated
by the resource identifier of an XMPP address (e.g., <node@domain/
home> vs. <node@domain/work>) as defined under Addressing Scheme
(Section 3). The RECOMMENDED port for connections between a client
and a server is 5222, as registered with the IANA (see Port Numbers
(Section 15.9)).
2.4. Gateway
A gateway is a special-purpose server-side service whose primary
function is to translate XMPP into the protocol used by a foreign
(non-XMPP) messaging system, as well as to translate the return data
back into XMPP. Examples are gateways to email (see [SMTP]),
Internet Relay Chat (see [IRC]), SIMPLE (see [SIMPLE]), Short Message
Service (SMS), and legacy instant messaging services such as AIM,
ICQ, MSN Messenger, and Yahoo! Instant Messenger. Communications
between gateways and servers, and between gateways and the foreign
messaging system, are not defined in this document.
2.5. Network
Because each server is identified by a network address and because
server-to-server communications are a straightforward extension of
the client-to-server protocol, in practice, the system consists of a
network of servers that inter-communicate. Thus, for example,
<juliet@example.com> is able to exchange messages, presence, and
other information with <romeo@example.net>. This pattern is familiar
from messaging protocols (such as [SMTP]) that make use of network
addressing standards. Communications between any two servers are
OPTIONAL. If enabled, such communications SHOULD occur over XML
streams that are bound to [TCP] connections. The RECOMMENDED port
for connections between servers is 5269, as registered with the IANA
(see Port Numbers (Section 15.9)).
3. Addressing Scheme
3.1. Overview
An entity is anything that can be considered a network endpoint
(i.e., an ID on the network) and that can communicate using XMPP.
All such entities are uniquely addressable in a form that is
consistent with RFC 2396 [URI]. For historical reasons, the address
of an XMPP entity is called a Jabber Identifier or JID. A valid JID
contains a set of ordered elements formed of a domain identifier,
node identifier, and resource identifier.
The syntax for a JID is defined below using the Augmented Backus-Naur
Form as defined in [ABNF]. (The IPv4address and IPv6address rules
are defined in Appendix B of [IPv6]; the allowable character
sequences that conform to the node rule are defined by the Nodeprep
profile of [STRINGPREP] as documented in Appendix A of this memo; the
allowable character sequences that conform to the resource rule are
defined by the Resourceprep profile of [STRINGPREP] as documented in
Appendix B of this memo; and the sub-domain rule makes reference to
the concept of an internationalized domain label as described in
[IDNA].)
jid = [ node "@" ] domain [ "/" resource ]
domain = fqdn / address-literal
fqdn = (sub-domain 1*("." sub-domain))
sub-domain = (internationalized domain label)
address-literal = IPv4address / IPv6address
All JIDs are based on the foregoing structure. The most common use
of this structure is to identify an instant messaging user, the
server to which the user connects, and the user’s connected resource
(e.g., a specific client) in the form of <user@host/resource>.
However, node types other than clients are possible; for example, a
specific chat room offered by a multi-user chat service could be
addressed as <room@service> (where "room" is the name of the chat
room and "service" is the hostname of the multi-user chat service)
and a specific occupant of such a room could be addressed as
<room@service/nick> (where "nick" is the occupant’s room nickname).
Many other JID types are possible (e.g., <domain/resource> could be a
server-side script or service).
Each allowable portion of a JID (node identifier, domain identifier,
and resource identifier) MUST NOT be more than 1023 bytes in length,
resulting in a maximum total size (including the ’@’ and ’/’
separators) of 3071 bytes.
3.2. Domain Identifier
The domain identifier is the primary identifier and is the only
REQUIRED element of a JID (a mere domain identifier is a valid JID).
It usually represents the network gateway or "primary" server to
which other entities connect for XML routing and data management
capabilities. However, the entity referenced by a domain identifier
is not always a server, and may be a service that is addressed as a
subdomain of a server that provides functionality above and beyond
the capabilities of a server (e.g., a multi-user chat service, a user
directory, or a gateway to a foreign messaging system).
The domain identifier for every server or service that will
communicate over a network MAY be an IP address but SHOULD be a fully
qualified domain name (see [DNS]). A domain identifier MUST be an
"internationalized domain name" as defined in [IDNA], to which the
Nameprep [NAMEPREP] profile of stringprep [STRINGPREP] can be applied
without failing. Before comparing two domain identifiers, a server
MUST (and a client SHOULD) first apply the Nameprep profile to the
labels (as defined in [IDNA]) that make up each identifier.
3.3. Node Identifier
The node identifier is an optional secondary identifier placed before
the domain identifier and separated from the latter by the ’@’
character. It usually represents the entity requesting and using
network access provided by the server or gateway (i.e., a client),
although it can also represent other kinds of entities (e.g., a chat
room associated with a multi-user chat service). The entity
represented by a node identifier is addressed within the context of a
specific domain; within instant messaging and presence applications
of XMPP, this address is called a "bare JID" and is of the form
<node@domain>.
A node identifier MUST be formatted such that the Nodeprep profile of
[STRINGPREP] can be applied to it without failing. Before comparing
two node identifiers, a server MUST (and a client SHOULD) first apply
the Nodeprep profile to each identifier.
3.4. Resource Identifier
The resource identifier is an optional tertiary identifier placed
after the domain identifier and separated from the latter by the ’/’
character. A resource identifier may modify either a <node@domain>
or a mere <domain> address. It usually represents a specific
session, connection (e.g., a device or location), or object (e.g., a
participant in a multi-user chat room) belonging to the entity
associated with a node identifier. A resource identifier is opaque
to both servers and other clients, and is typically defined by a
client implementation when it provides the information necessary to
complete Resource Binding (Section 7) (although it may be generated
by a server on behalf of a client), after which it is referred to as
a "connected resource". An entity MAY maintain multiple connected
resources simultaneously, with each connected resource differentiated
by a distinct resource identifier.
A resource identifier MUST be formatted such that the Resourceprep
profile of [STRINGPREP] can be applied without failing. Before
comparing two resource identifiers, a server MUST (and a client
SHOULD) first apply the Resourceprep profile to each identifier.
3.5. Determination of Addresses
After SASL negotiation (Section 6) and, if appropriate, Resource
Binding (Section 7), the receiving entity for a stream MUST determine
the initiating entity’s JID.
For server-to-server communications, the initiating entity’s JID
SHOULD be the authorization identity, derived from the authentication
identity, as defined by the Simple Authentication and Security Layer
(SASL) specification [SASL], if no authorization identity was
specified during SASL negotiation (Section 6).
For client-to-server communications, the "bare JID" (<node@domain>)
SHOULD be the authorization identity, derived from the authentication
identity, as defined in [SASL], if no authorization identity was
specified during SASL negotiation (Section 6); the resource
identifier portion of the "full JID" (<node@domain/resource>) SHOULD
be the resource identifier negotiated by the client and server during
Resource Binding (Section 7).
The receiving entity MUST ensure that the resulting JID (including
node identifier, domain identifier, resource identifier, and
separator characters) conforms to the rules and formats defined
earlier in this section; to meet this restriction, the receiving
entity may need to replace the JID sent by the initiating entity with
the canonicalized JID as determined by the receiving entity.
4. XML Streams
4.1. Overview
Two fundamental concepts make possible the rapid, asynchronous
exchange of relatively small payloads of structured information
between presence-aware entities: XML streams and XML stanzas. These
terms are defined as follows:
Definition of XML Stream: An XML stream is a container for the
exchange of XML elements between any two entities over a network.
The start of an XML stream is denoted unambiguously by an opening
XML <stream> tag (with appropriate attributes and namespace
declarations), while the end of the XML stream is denoted
unambiguously by a closing XML </stream> tag. During the life of
the stream, the entity that initiated it can send an unbounded
number of XML elements over the stream, either elements used to
negotiate the stream (e.g., to negotiate Use of TLS (Section 5) or
use of SASL (Section 6)) or XML stanzas (as defined herein,
<message/>, <presence/>, or <iq/> elements qualified by the
default namespace). The "initial stream" is negotiated from the
initiating entity (usually a client or server) to the receiving
entity (usually a server), and can be seen as corresponding to the
initiating entity’s "session" with the receiving entity. The
initial stream enables unidirectional communication from the
initiating entity to the receiving entity; in order to enable
information exchange from the receiving entity to the initiating
entity, the receiving entity MUST negotiate a stream in the
opposite direction (the "response stream").
Definition of XML Stanza: An XML stanza is a discrete semantic unit
of structured information that is sent from one entity to another
over an XML stream. An XML stanza exists at the direct child
level of the root <stream/> element and is said to be
well-balanced if it matches the production [43] content of [XML].
The start of any XML stanza is denoted unambiguously by the
element start tag at depth=1 of the XML stream (e.g., <presence>),
and the end of any XML stanza is denoted unambiguously by the
corresponding close tag at depth=1 (e.g., </presence>). An XML
stanza MAY contain child elements (with accompanying attributes,
elements, and XML character data) as necessary in order to convey
the desired information. The only XML stanzas defined herein are
the <message/>, <presence/>, and <iq/> elements qualified by the
default namespace for the stream, as described under XML Stanzas
(Section 9); an XML element sent for the purpose of Transport
Layer Security (TLS) negotiation (Section 5), Simple
Authentication and Security Layer (SASL) negotiation (Section 6),
or server dialback (Section 8) is not considered to be an XML
stanza.
Consider the example of a client’s session with a server. In order
to connect to a server, a client MUST initiate an XML stream by
sending an opening <stream> tag to the server, optionally preceded by
a text declaration specifying the XML version and the character
encoding supported (see Inclusion of Text Declaration (Section 11.4);
see also Character Encoding (Section 11.5)). Subject to local
policies and service provisioning, the server SHOULD then reply with
a second XML stream back to the client, again optionally preceded by
a text declaration. Once the client has completed SASL negotiation
(Section 6), the client MAY send an unbounded number of XML stanzas
over the stream to any recipient on the network. When the client
desires to close the stream, it simply sends a closing </stream> tag
to the server (alternatively, the stream may be closed by the
server), after which both the client and server SHOULD terminate the
underlying connection (usually a TCP connection) as well.
Those who are accustomed to thinking of XML in a document-centric
manner may wish to view a client’s session with a server as
consisting of two open-ended XML documents: one from the client to
the server and one from the server to the client. From this
perspective, the root <stream/> element can be considered the
document entity for each "document", and the two "documents" are
built up through the accumulation of XML stanzas sent over the two
XML streams. However, this perspective is a convenience only; XMPP
does not deal in documents but in XML streams and XML stanzas.
In essence, then, an XML stream acts as an envelope for all the XML
stanzas sent during a session. We can represent this in a simplistic
fashion as follows:
|--------------------|
| <stream> |
|--------------------|
| <presence> |
| <show/> |
| </presence> |
|--------------------|
| <message to=’foo’> |
| <body/> |
| </message> |
|--------------------|
| <iq to=’bar’> |
| <query/> |
| </iq> |
|--------------------|
| ... |
|--------------------|
| </stream> |
|--------------------|
4.2. Binding to TCP
Although there is no necessary coupling of an XML stream to a [TCP]
connection (e.g., two entities could connect to each other via
another mechanism such as polling over [HTTP]), this specification
defines a binding of XMPP to TCP only. In the context of
client-to-server communications, a server MUST allow a client to
share a single TCP connection for XML stanzas sent from client to
server and from server to client. In the context of server-to-server
communications, a server MUST use one TCP connection for XML stanzas
sent from the server to the peer and another TCP connection
(initiated by the peer) for stanzas from the peer to the server, for
a total of two TCP connections.
4.3. Stream Security
When negotiating XML streams in XMPP 1.0, TLS SHOULD be used as
defined under Use of TLS (Section 5) and SASL MUST be used as defined
under Use of SASL (Section 6). The "initial stream" (i.e., the
stream from the initiating entity to the receiving entity) and the
"response stream" (i.e., the stream from the receiving entity to the
initiating entity) MUST be secured separately, although security in
both directions MAY be established via mechanisms that provide mutual
authentication. An entity SHOULD NOT attempt to send XML Stanzas
(Section 9) over the stream before the stream has been authenticated,
but if it does, then the other entity MUST NOT accept such stanzas
and SHOULD return a <not-authorized/> stream error and then terminate
both the XML stream and the underlying TCP connection; note well that
this applies to XML stanzas only (i.e., <message/>, <presence/>, and
<iq/> elements scoped by the default namespace) and not to XML
elements used for stream negotiation (e.g., elements used to
negotiate Use of TLS (Section 5) or Use of SASL (Section 6)).
4.4. Stream Attributes
The attributes of the stream element are as follows:
o to -- The ’to’ attribute SHOULD be used only in the XML stream
header from the initiating entity to the receiving entity, and
MUST be set to a hostname serviced by the receiving entity. There
SHOULD NOT be a ’to’ attribute set in the XML stream header by
which the receiving entity replies to the initiating entity;
however, if a ’to’ attribute is included, it SHOULD be silently
ignored by the initiating entity.
o from -- The ’from’ attribute SHOULD be used only in the XML stream
header from the receiving entity to the initiating entity, and
MUST be set to a hostname serviced by the receiving entity that is
granting access to the initiating entity. There SHOULD NOT be a
’from’ attribute on the XML stream header sent from the initiating
entity to the receiving entity; however, if a ’from’ attribute is
included, it SHOULD be silently ignored by the receiving entity.
o id -- The ’id’ attribute SHOULD be used only in the XML stream
header from the receiving entity to the initiating entity. This
attribute is a unique identifier created by the receiving entity
to function as a session key for the initiating entity’s streams
with the receiving entity, and MUST be unique within the receiving
application (normally a server). Note well that the stream ID may
be security-critical and therefore MUST be both unpredictable and