| TOC |
|
By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as “work in progress.”
The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 18, 2008.
Copyright © The IETF Trust (2007).
This document defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a technology for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network-aware entities. XMPP provides a generalized, extensible framework for incrementally exchanging XML data, upon which a variety of applications can be built. The framework includes methods for stream setup and teardown, channel encryption, authentication of a client to a server and of one server to another server, and primitives for push-style messages, publication of network availability information ("presence"), and request-response interactions between any two XMPP entities. This document also specifies the format for XMPP addresses, which are fully internationalizable.
This document obsoletes RFC 3920.
1.
Introduction
1.1.
Overview
1.2.
Functional Summary
1.3.
Conventions
2.
Architecture
2.1.
Overview
2.2.
Server
2.3.
Client
2.4.
Network
3.
Addresses
3.1.
Overview
3.2.
Domain Identifier
3.3.
Node Identifier
3.4.
Resource Identifier
3.5.
Determination of Addresses
4.
TCP Binding
5.
XML Streams
5.1.
Overview
5.2.
Stream Security
5.3.
Stream Attributes
5.4.
Namespace Declarations
5.5.
Stream Features
5.6.
Closing Streams
5.7.
Reconnection
5.8.
Stream Errors
5.9.
Simplified Stream Examples
6.
STARTTLS Negotiation
6.1.
Overview
6.2.
Rules
6.3.
Process
6.4.
Representation of JIDs in Certificates
7.
SASL Negotiation
7.1.
Overview
7.2.
Rules
7.3.
Process
7.4.
SASL Definition
7.5.
SASL Errors
8.
Resource Binding
8.1.
Overview
8.2.
Advertising Support
8.3.
Server-Generated Resource Identifier
8.4.
Client-Generated Resource Identifier
8.5.
Binding Multiple Resources
9.
XML Stanzas
9.1.
Common Attributes
9.2.
Basic Semantics
9.3.
Stanza Errors
9.4.
Extended Content
10.
Examples
10.1.
Client-to-Server
10.2.
Server-to-Server Examples
11.
Server Rules for Processing XML Stanzas
11.1.
No 'to' Address
11.2.
Local Domain
11.3.
Resource at Local Domain
11.4.
Node at Local Domain
11.5.
Foreign Domain
12.
XML Usage
12.1.
Restrictions
12.2.
XML Namespace Names and Prefixes
12.3.
Validation
12.4.
Inclusion of Text Declaration
12.5.
Character Encoding
12.6.
White Space
13.
Compliance Requirements
13.1.
Servers
13.2.
Clients
14.
Internationalization Considerations
15.
Security Considerations
15.1.
High Security
15.2.
Certificate Validation
15.3.
Client-to-Server Communication
15.4.
Server-to-Server Communication
15.5.
Order of Layers
15.6.
Lack of SASL Channel Binding to TLS
15.7.
Mandatory-to-Implement Technologies
15.8.
Firewalls
15.9.
Use of base64 in SASL
15.10.
Stringprep Profiles
15.11.
Address Spoofing
15.12.
Denial of Service
15.13.
Presence Leaks
15.14.
Directory Harvesting
16.
IANA Considerations
16.1.
XML Namespace Name for TLS Data
16.2.
XML Namespace Name for SASL Data
16.3.
XML Namespace Name for Stream Errors
16.4.
XML Namespace Name for Resource Binding
16.5.
XML Namespace Name for Stanza Errors
16.6.
Nodeprep Profile of Stringprep
16.7.
Resourceprep Profile of Stringprep
16.8.
GSSAPI Service Name
16.9.
Port Numbers
17.
References
17.1.
Normative References
17.2.
Informative References
Appendix A.
Nodeprep
A.1.
Introduction
A.2.
Character Repertoire
A.3.
Mapping
A.4.
Normalization
A.5.
Prohibited Output
A.6.
Bidirectional Characters
Appendix B.
Resourceprep
B.1.
Introduction
B.2.
Character Repertoire
B.3.
Mapping
B.4.
Normalization
B.5.
Prohibited Output
B.6.
Bidirectional Characters
Appendix C.
XML Schemas
C.1.
Streams namespace
C.2.
Stream error namespace
C.3.
TLS namespace
C.4.
SASL namespace
C.5.
Resource binding namespace
C.6.
Stanza error namespace
Appendix D.
Contact Addresses
Appendix E.
Account Provisioning
Appendix F.
Differences From RFC 3920
Appendix G.
Copying Conditions
§
Index
§
Author's Address
§
Intellectual Property and Copyright Statements
| TOC |
| TOC |
The Extensible Messaging and Presence Protocol (XMPP) is an Extensible Markup Language [XML] (Paoli, J., Maler, E., Sperberg-McQueen, C., Yergeau, F., and T. Bray, “Extensible Markup Language (XML) 1.0 (Fourth Edition),” August 2006.) technology 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 late 2002, the XMPP Working Group was chartered with developing an adaptation of the core Jabber protocol that would be suitable as an IETF instant messaging (IM) and presence technology. As a result of work by the XMPP WG, [RFC3920] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Core,” October 2004.) was published in October 2004.
As a result of extensive implementation and deployment experience with XMPP since that time, as well as more formal interoperability testing, this document reflects consensus from the XMPP developer community regarding XMPP's core XML streaming technology. In particular, this document incorporates the following backward-compatible changes from RFC 3920:
Therefore, this document defines the core features of XMPP 1.0 and obsoletes RFC 3920.
Note: The XMPP extensions required to provide the basic instant messaging and presence functionality defined in [IMP‑REQS] (Day, M., Aggarwal, S., and J. Vincent, “Instant Messaging / Presence Protocol Requirements,” February 2000.) are specified in [XMPP‑IM] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence,” July 2007.).
| TOC |
This non-normative section provides a developer-friendly, functional summary of XMPP; refer to the sections that follow for a normative definition of XMPP.
The purpose of XMPP is to enable the exchange of relatively small pieces of structured data (called "XML stanzas") over a network between any two (or more) entities. XMPP is implemented using a client-server architecture, wherein a client must connect to a server in order to gain access to the network and thus be allowed to exchange XML stanzas with other entities. The process whereby a client connects to a server, exchanges XML stanzas, and ends the connection is:
In the sections following discussion of XMPP architecture and XMPP addresses, this document specifies how clients connect to servers and specifies the basic semantics of XML stanzas. However, this document does not define the "payloads" of the XML stanzas that might be exchanged once a connection is successfully established; instead, definition of such semantics is provided by XMPP extensions (e.g., [XMPP‑IM] (Saint-Andre, P., “Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence,” July 2007.) defines extensions for basic instant messaging and presence functionality, and various specifications produced in the XMPP Standards Foundation's XEP series define extensions for a wide range of more advanced functionality).
Within the client-server architecture used by XMPP, one server may optionally connect to another server to enable inter-domain or inter-server communication. For this to happen, the two servers must negotiate a connection between themselves and then exchange XML stanzas; the process for doing so is:
Note: Depending on local service policies, a service may wish to use the older server dialback protocol to provide weak identity verification in cases where SASL negotiation would not result in strong authentication (e.g., because the certificate presented by the peer service during TLS negotiation is self-signed and thus provides only weak identity); for details, see [XEP‑0220] (Saint-Andre, P. and J. Miller, “Server Dialback,” June 2007.).
| TOC |
The following keywords are to be interpreted as described in [TERMS] (Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels,” March 1997.): "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
In examples, lines have been wrapped for improved readability, "[...]" means elision, and the following prepended strings are used:
| TOC |
| TOC |
XMPP assumes a client-server architecture, wherein a client utilizing XMPP accesses a server (normally over a [TCP] (Postel, J., “Transmission Control Protocol,” September 1981.) connection) and servers can also communicate with each other over TCP connections.
A simplified architectural diagram for a typical deployment is shown here, where the entities have the following significance:
example.net -------------------- example.com
| |
| |
romeo@example.net juliet@example.com
Note: Architectures that employ the syntax of XML stanzas (XML Stanzas) but that establish peer-to-peer connections directly between clients using technologies based on [LINKLOCAL] (Cheshire, S., Aboba, B., and E. Guttman, “Dynamic Configuration of IPv4 Link-Local Addresses,” May 2005.) have been deployed, but such architectures are not XMPP and are best described as "XMPP-like"; for details, see [XEP‑0174] (Saint-Andre, P., “Link-Local Messaging,” March 2007.).
| TOC |
A SERVER is an entity whose primary responsibilities are to:
Depending on the application, the secondary responsibilities of an XMPP server may include:
| TOC |
A CLIENT is an entity that establiishes an XML stream with a server by authenticating using the credentials of a local account and that then completes resource binding (Resource Binding) in order to enable delivery of XML stanzas via the server to the client. A client then uses XMPP to communicate with its server, other clients, and any other accessible entities on a network. Multiple clients may connect simultaneously to a server on behalf of a local account, with each client differentiated by the resource identifier portion of an XMPP address (e.g., <node@domain/home> vs. <node@domain/work>), as defined under Section 3 (Addresses) and Section 8 (Resource Binding). The RECOMMENDED port for TCP connections between a client and a server is 5222, as registered with the IANA (see Section 16.9 (Port Numbers)).
| TOC |
Because each server is identified by a network address and because server-to-server communication is 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] (Klensin, J., “Simple Mail Transfer Protocol,” April 2001.)) that make use of network addressing standards. Communication between any two servers is OPTIONAL. If enabled, such communication SHOULD occur over XML streams that are bound to [TCP] (Postel, J., “Transmission Control Protocol,” September 1981.) connections. The RECOMMENDED port for tCP connections between servers is 5269, as registered with the IANA (see Section 16.9 (Port Numbers).
| TOC |
| TOC |
An ENTITY is anything that is network-addressable and that can communicate using XMPP. For historical reasons, the native address of an XMPP entity is called a JABBER IDENTIFIER or JID. A valid JID contains a set of ordered elements formed of an XMPP domain identifier, node identifier, and resource identifier.
The syntax for a JID is defined as follows using the Augmented Backus-Naur Form as specified in [ABNF] (Crocker, D. and P. Overell, “Augmented BNF for Syntax Specifications: ABNF,” October 2005.).
jid = [ node "@" ] domain [ "/" resource ]
node = 1*(nodepoint)
; a "nodepoint" is a UTF-8 encoded Unicode code
; point that satisfies the Nodeprep profile of
; stringprep
domain = fqdn / address-literal / idnlabel
fqdn = (idnlabel 1*("." idnlabel))
; an "idnlabel" is an internationalized label
; as described in RFC 3490
address-literal = IPv4address / IPv6address
; the "IPv4address" and "IPv6address" rules are
; defined in Appendix B of RFC 3513
resource = 1*(resourcepoint)
; a "resourcepoint" is a UTF-8 encoded Unicode
; code point that satisfies the Resourceprep
; profile of stringprep
All JIDs are based on the foregoing structure. One common use of this structure is to identify a messaging and presence account, the server that hosts the account, and a connected resource (e.g., a specific device) in the form of <node@domain/resource>. However, node types other than clients are possible; for example, a specific chat room offered by a multi-user conference service (see [XEP‑0045] (Saint-Andre, P., “Multi-User Chat,” April 2007.)) could be addressed as <room@service> (where "room" is the name of the chat room and "service" is the hostname of the multi-user conference 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.
Note: While the format of a JID is consistent with [URI] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.), an entity's address on an XMPP network MUST be a JID (without a URI scheme) and not a [URI] (Berners-Lee, T., Fielding, R., and L. Masinter, “Uniform Resource Identifier (URI): Generic Syntax,” January 2005.) or [IRI] (Duerst, M. and M. Suignard, “Internationalized Resource Identifiers (IRIs),” January 2005.) as specified in [XMPP‑URI] (Saint-Andre, P., “Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP),” June 2007.); the latter specification is provided only for use by non-XMPP applications.
| TOC |
The DOMAIN IDENTIFIER portion of a JID is that portion after the '@' character (if any) and before the '/' character (if any); it is the primary identifier and is the only REQUIRED element of a JID (a mere domain identifier is a valid JID). Typically a domain identifier identifies the "home" server to which clients connect for XML routing and data management functionality. (Note: A single server may host multiple domain identifiers, i.e., multiple local domains.) However, it is not necessary for an XMPP domain identifier to identify an entity that provides core XMPP server functionality (e.g., a domain identifier may identity an entity such as a multi-user conference service, a publish-subscribe service, or a user directory).
The domain identifier for every server or service that will communicate over a network SHOULD be a fully qualified domain name (see [DNS] (Mockapetris, P., “Domain names - implementation and specification,” November 1987.)) but MAY be either an IPv4 or IPv6 address or a text label (commonly called an "unqualified hostname") that is resolvable on a local network. If the domain identifier includes a final character considered to be a label separator (dot) by [IDNA] (Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” March 2003.) or [STD13] (Mockapetris, P., “Domain names - implementation and specification,” November 1987.), this character MUST be stripped from the domain identifier before the JID of which it is a part is used for the purpose of routing an XML stanza, comparing against another JID, or constructing an [XMPP‑URI] (Saint-Andre, P., “Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP),” June 2007.); in particular, the character should be stripped before any other canonicalization steps are taken (such as application of the [NAMEPREP] (Hoffman, P. and M. Blanchet, “Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN),” March 2003.) profile of [STRINGPREP] (Hoffman, P. and M. Blanchet, “Preparation of Internationalized Strings ("stringprep"),” December 2002.) or completion of the ToASCII operation as described in [IDNA] (Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” March 2003.)).
A domain identifier MUST be an "internationalized domain name" as defined in [IDNA] (Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” March 2003.), that is, "a domain name in which every label is an internationalized label". When preparing a text label (consisting of a sequence of Unicode code points) for representation as an internationalized label in the process of constructing an XMPP domain identifier or comparing two XMPP domain identifiers, an application MUST ensure that for each text label it is possible to apply without failing the ToASCII operation specified in [IDNA] (Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” March 2003.) with the UseSTD3ASCIIRules flag set (thus forbidding ASCII code points other than letters, digits, and hyphens). If the ToASCII operation can be applied without failing, then the label is an internationalized label. An internationalized domain name (and therefore an XMPP domain identifier) is constructed from its constituent internationalized labels by following the rules specified in [IDNA] (Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” March 2003.). (Note: The ToASCII operation includes application of the [NAMEPREP] (Hoffman, P. and M. Blanchet, “Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN),” March 2003.) profile of [STRINGPREP] (Hoffman, P. and M. Blanchet, “Preparation of Internationalized Strings ("stringprep"),” December 2002.) and encoding using the algorithm specified in [PUNYCODE] (Costello, A., “Punycode: A Bootstring encoding of Unicode for Internationalized Domain Names in Applications (IDNA),” March 2003.); for details, see [IDNA] (Faltstrom, P., Hoffman, P., and A. Costello, “Internationalizing Domain Names in Applications (IDNA),” March 2003.).)
| TOC |
The NODE IDENTIFIER portion of a JID is an optional secondary identifier placed before the domain identifier and separated from the latter by the '@' character. Typically a node identifier uniquely identifies the entity requesting and using network access provided by a server (i.e., a local account), although it can also represent other kinds of entities (e.g., a chat room associated with a multi-user conference service). The entity represented by an XMPP node identifier is addressed within the context of a specific domain. When the domain is an XMPP server and the entity is a local account on the server, the resulting address (of the form <node@domain>) is called a BARE JID.
A node identifier MUST be formatted such that the Nodeprep profile of [STRINGPREP] (Hoffman, P. and M. Blanchet, “Preparation of Internationalized Strings ("stringprep"),” December 2002.) can be applied without failing (see Appendix A (Nodeprep)). Before comparing two node identifiers, an application MUST first apply the Nodeprep profile to each identifier.
| TOC |
The RESOURCE IDENTIFIER portion of a JID 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> address or a mere <domain> address. Typically a resource identifier uniquely identifies a specific connection (e.g., a device or location) or object (e.g., a participant in a multi-user conference room) belonging to the entity associated with an XMPP node identifier at a local domain. A resource identifier has no semantic meaning and is opaque to both servers and clients. A resource identifier is negotiated between a client and a server during resource binding (Resource Binding), after which the entity is referred to as a CONNECTED RESOURCE and its address (of the form <node@domain/resource>) is referred to as a FULL JID. 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] (Hoffman, P. and M. Blanchet, “Preparation of Internationalized Strings ("stringprep"),” December 2002.) can be applied without failing (see Appendix B (Resourceprep)). Before comparing two resource identifiers, an application MUST first apply the Resourceprep profile to each identifier.
| TOC |
After SASL negotiation (SASL Negotiation) and, if appropriate, resource binding (Resource Binding), the receiving entity for a stream MUST determine the initiating entity's JID.
For server-to-server communication, the initiating entity's JID SHOULD be the authorization identity, derived from the authentication identity (as defined by [SASL] (Melnikov, A. and K. Zeilenga, “Simple Authentication and Security Layer (SASL),” June 2006.)), if no authorization identity was specified during SASL negotiation (SASL Negotiation).
For client-to-server communication, the bare JID (<node@domain>) SHOULD be the authorization identity, derived from the authentication identity (as defined by [SASL] (Melnikov, A. and K. Zeilenga, “Simple Authentication and Security Layer (SASL),” June 2006.)), if no authorization identity was specified during SASL negotiation (SASL Negotiation); 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 (Resource Binding).
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.
| TOC |
As XMPP is defined herein, an initiating entity (client or server) MUST open a TCP connection at the receiving entity (server) before it negotiates XML streams with the receiving entity. However, prior to opening the TCP connection, the initiating entity first MUST resolve the Domain Name System (DNS) hostname associated with the receiving entity and determine the appropriate TCP port for communication with the receiving entity. The process is:
TCP connections are handled differently in client-to-server communication and server-to-server ommunication. Specifically:
Note: There is no necessary coupling of an XML stream to a [TCP] (Postel, J., “Transmission Control Protocol,” September 1981.) connection. For example, two entities could connect to each other via another transport, such as [HTTP] (Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, “Hypertext Transfer Protocol -- HTTP/1.1,” June 1999.) as specified in [XEP‑0124] (Paterson, I., Smith, D., and P. Saint-Andre, “Bidirectional-streams Over Synchronous HTTP (BOSH),” February 2007.) and [XEP‑0206] (Paterson, I., “XMPP Over BOSH,” February 2007.). However, this specification defines a binding of XMPP to TCP only.
| TOC |
| TOC |
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 complete TLS negotiation (STARTTLS Negotiation) or SASL negotiation (SASL Negotiation)) or XML stanzas. The INITIAL STREAM is negotiated from the initiating entity (typically a client or server) to the receiving entity (typically a server), and can be seen as corresponding to the initiating entity's "connection" or "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, and is the basic unit of meaning in XMPP. 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] (Paoli, J., Maler, E., Sperberg-McQueen, C., Yergeau, F., and T. Bray, “Extensible Markup Language (XML) 1.0 (Fourth Edition),” August 2006.). 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>); a server MUST NOT process a partial stanza and MUST NOT attach meaning to the transmission timing of any part of a stanza (before receipt of the close tag). The only XML stanzas defined herein are the <message/>, <presence/>, and <iq/> elements qualified by the default namespace for the stream, as described under Section 9 (XML Stanzas); an XML element sent for the purpose of TLS negotiation (STARTTLS Negotiation) or SASL negotiation (SASL Negotiation) is not considered to be an XML stanza. An XML stanza MAY contain child elements (with accompanying attributes, elements, and XML character data) as necessary in order to convey the desired information, which MAY be qualified by any XML namespace (see [XML‑NAMES] (Bray, T., Hollander, D., and A. Layman, “Namespaces in XML,” January 1999.) as well as Section 9.4 (Extended Content) herein).
Consider the example of a client's connection to 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 Section 12.4 (Inclusion of Text Declaration) and Section 12.5 (Character Encoding)). 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 (SASL Negotiation) and resource binding (Resource Binding), the client MAY send an unbounded number of XML stanzas over the stream to any. When the client desires to close the stream, it simply sends a closing </stream> tag to the server (see Section 5.6 (Closing Streams)).
In essence, then, an XML stream acts as an envelope for all the XML stanzas sent during a connection. 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> | +--------------------+
Note: Those who are accustomed to thinking of XML in a document-centric manner may wish to view a client's connection to 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.
| TOC |
For the purpose of stream security, both Transport Layer Security (see Section 6 (STARTTLS Negotiation)) and the Simple Authentication and Security Layer (see Section 7 (SASL Negotiation)) are mandatory to implement.
When negotiating XML streams in XMPP 1.0, TLS SHOULD be used as defined under Section 6 (STARTTLS Negotiation) and SASL MUST be used as defined under Section 7 (SASL Negotiation). The initial stream and the response stream MUST be secured separately, although security in both directions MAY be established via mechanisms that provide mutual authentication.
The initiating entity SHOULD NOT attempt to send XML stanzas (XML Stanzas) over the stream before the stream has been authenticated. However, if it does attempt to do so, the receiving entity MUST NOT accept such stanzas and MUST return a <not-authorized/> stream error and then terminate both the XML stream and the underlying TCP connection. Note: This applies to XML stanzas only (i.e., <message/>, <presence/>, and <iq/> elements qualified by the default namespace) and not to XML elements used for stream negotiation (e.g., elements used to complete TLS negotiation (STARTTLS Negotiation) or SASL negotiation (SASL Negotiation)).
| TOC |
The attributes of the root <stream/> element are as follows.
| TOC |
In client-to-server communication, the 'from' attribute SHOULD be included in the XML stream header sent from the initiating entity to the receiving entity and (if included) MUST be set to the account name (i.e., bare JID = <node@domain>) of the entity controlling the client.
C: <?xml version='1.0'?>
<stream:stream
from='juliet@example.com'
to='example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
In server-to-server communication, the 'from' attribute SHOULD be included in the XML stream header sent from the initiating entity to the receiving entity and (if included) MUST be set to a hostname serviced by the initiating entity.
P: <?xml version='1.0'?>
<stream:stream
from='example.net'
to='example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'>
In both client-to-server and server-to-server communications, the 'from' attribute MUST be included in the XML stream header by which the receiving entity responds to the initiating entity and MUST be set to a hostname serviced by the receiving entity that is granting access to the initiating entity.
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
Note: Each entity MUST verify the identity of the other entity before exchanging XML stanzas with it (see Section 15.3 (Client-to-Server Communication) and Section 15.4 (Server-to-Server Communication)).
| TOC |
In both client-to-server and server-to-server communications, the 'to' attribute SHOULD be included in the XML stream header sent from the initiating entity to the receiving entity and (if included) MUST be set to a hostname serviced by the receiving entity.
C: <?xml version='1.0'?>
<stream:stream
from='juliet@example.com'
to='example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
In client-to-server communication, if the client included a 'from' address in the initial stream header then the server SHOULD include a 'to' attribute in the XML stream header by which it replies to the client and (if included) MUST set the 'to' attribute to the bare JID specified in the 'from' attribute of the XML stream header sent from the initiating entity to the receiving entity.
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
In server-to-server communication, if the initiating entity included a 'from' address in the initial stream header then the receiving entity SHOULD include a 'to' attribute in the XML stream header by which it replies to the initiating entity and (if included) MUST set the 'to' attribute to the hostname specified in the 'from' attribute of the XML stream header sent from the initiating entity to the receiving entity.
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='g4qSvGvBxJ+xeAd7QKezOQJFFlw='
to='example.net'
version='1.0'
xml:lang='en'
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'>
Note: Each entity MUST verify the identity of the other entity before exchanging XML stanzas with it (see Section 15.3 (Client-to-Server Communication) and Section 15.4 (Server-to-Server Communication)).
| TOC |
There SHOULD NOT be an 'id' attribute on the XML stream header sent from the initiating entity to the receiving entity; however, if an 'id' attribute is included, it SHOULD be silently ignored by the receiving entity.
C: <?xml version='1.0'?>
<stream:stream
from='juliet@example.com'
to='example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
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 identifier for the initiating entity's two streams with the receiving entity, and MUST be unique within the receiving application (normally a server).
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
Note: The stream ID may be security-critical and therefore MUST be both unpredictable and nonrepeating (see [RANDOM] (Eastlake, D., Schiller, J., and S. Crocker, “Randomness Requirements for Security,” June 2005.) for recommendations regarding randomness for security purposes).
| TOC |
An 'xml:lang' attribute (as defined in Section 2.12 of [XML] (Paoli, J., Maler, E., Sperberg-McQueen, C., Yergeau, F., and T. Bray, “Extensible Markup Language (XML) 1.0 (Fourth Edition),” August 2006.)) SHOULD be included by the initiating entity on the header for the initial stream to specify the default language of any human-readable XML character data it sends over that stream.
C: <?xml version='1.0'?>
<stream:stream
from='juliet@example.com'
to='example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
If the attribute is included, the receiving entity SHOULD remember that value as the default for both the initial stream and the response stream; if the attribute is not included, the receiving entity SHOULD use a configurable default value for both streams, which it MUST communicate in the header for the response stream.
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
For all stanzas sent over the initial stream, if the initiating entity does not include an 'xml:lang' attribute, the receiving entity SHOULD apply the default value; if the initiating entity does include an 'xml:lang' attribute, the receiving entity MUST NOT modify or delete it (see also Section 9.1.5 (xml:lang)). The value of the 'xml:lang' attribute MUST conform to the NMTOKEN datatype (as defined in Section 2.3 of [XML] (Paoli, J., Maler, E., Sperberg-McQueen, C., Yergeau, F., and T. Bray, “Extensible Markup Language (XML) 1.0 (Fourth Edition),” August 2006.)) and MUST conform to the format defined in [LANGTAGS] (Phillips, A. and M. Davis, “Tags for Identifying Languages,” September 2006.).
| TOC |
The presence of the version attribute set to a value of at least "1.0" signals support for the stream-related protocols (including stream features) defined in this specification.
The version of XMPP specified herein is "1.0"; in particular, this encapsulates the stream-related protocols (TLS negotiation (STARTTLS Negotiation), SASL negotiation (SASL Negotiation), and stream errors (Stream Errors)), as well as the semantics of the three defined XML stanza types (<message/>, <presence/>, and <iq/>).
The numbering scheme for XMPP versions is "<major>.<minor>". The major and minor numbers MUST be treated as separate integers and each number MAY be incremented higher than a single digit. Thus, "XMPP 2.4" would be a lower version than "XMPP 2.13", which in turn would be lower than "XMPP 12.3". Leading zeros (e.g., "XMPP 6.01") MUST be ignored by recipients and MUST NOT be sent.
The major version number should be incremented only if the stream and stanza formats or required actions have changed so dramatically that an older version entity would not be able to interoperate with a newer version entity if it simply ignored the elements and attributes it did not understand and took the actions specified in the older specification.
The minor version number should be incremented only if significant new capabilities have been added to the core protocol (e.g., a newly defined value of the 'type' attribute for message, presence, or IQ stanzas). The minor version number MUST be ignored by an entity with a smaller minor version number, but used for informational purposes by the entity with the larger minor version number (e.g., the entity with the larger minor version number would simply note that its correspondent would not be able to understand that value of the 'type' attribute and therefore would not send it).
The following rules apply to the generation and handling of the 'version' attribute within stream headers:
| TOC |
We can summarize the attributes of the root <stream/> element as follows.
+----------+--------------------------+-------------------------+ | | initiating to receiving | receiving to initiating | +----------+--------------------------+-------------------------+ | to | JID of receiver | JID of initiator | | from | JID of initiator | JID of receiver | | id | silently ignored | stream identifier | | xml:lang | default language | default language | | version | XMPP 1.0 supported | XMPP 1.0 supported | +----------+--------------------------+-------------------------+
Note: The attributes of the root <stream/> element are not prepended by a 'stream:' prefix because, in accordance with Section 5.3 of [XML‑NAMES] (Bray, T., Hollander, D., and A. Layman, “Namespaces in XML,” January 1999.), the default namespace does not apply to attribute names.
| TOC |
The stream element MUST possess both a streams namespace declaration and a default namespace declaration (as "namespace declaration" is defined in [XML‑NAMES] (Bray, T., Hollander, D., and A. Layman, “Namespaces in XML,” January 1999.)). For detailed information regarding the streams namespace and default namespace, see Section 12.2 (XML Namespace Names and Prefixes).
| TOC |
If the initiating entity includes the 'version' attribute set to a value of at least "1.0" in the initial stream header, after sending the header for the response stream the receiving entity MUST send a <features/> child element (prefixed by the streams namespace prefix) to the initiating entity in order to announce any stream-level features that can be negotiated (or capabilities that otherwise need to be advertised).
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
S: <stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<required/>
</starttls>
</stream:features>
Stream features are used mainly to advertise TLS negotiation (STARTTLS Negotiation), SASL negotiation (SASL Negotiation), and resource binding (Resource Binding); however, stream features also can be used to advertise features associated with various XMPP extensions. If an entity does not understand or support a feature, it SHOULD silently ignore that feature.
If one or more security features (e.g., TLS and SASL) need to be successfully negotiated before a non-security-related feature (e.g., resource binding) can be offered, the non-security-related feature SHOULD NOT be included in the stream features that are advertised before the relevant security features have been negotiated.
If a feature must be negotiated before the initiating entity may proceed, that feature SHOULD include a <required/> child element.
If there are no features to be advertised (e.g., in the stream reset initiated after successful SASL negotiation for a server-to-server connection, or after resource binding for a client-to-server stream) then the receiving entity MUST include an empty <stream:features/> element after sending a stream header to the initiating entity.
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
S: <stream:features/>
| TOC |
At any time after XML streams have been negotiated between two entities, either entity MAY close its stream to the other entity (even in the absence of a stream error) by sending a closing stream tag:
C: </stream:stream>
The entity that sends the closing stream tag SHOULD wait for the other entity to also close its stream:
S: </stream:stream>
However, the entity that sends the first closing stream tag MAY consider both streams to be void if the other entity does not send its closing stream tag within a reasonable amount of time (where the definition of "reasonable" is left up to the implementation or deployment).
After an entity sends a closing stream tag, it MUST NOT send further data over that stream.
After the entity that sent the first closing stream tag receives a reciprocal closing stream tag from the other entity, it MUST terminate the underlying TCP connection.
Note: There is one TCP connection for client-to-server streams, but there are two TCP connections for server-to-server streams.
| TOC |
It can happen that an XMPP server goes offline while servicing connections from clients and from other servers. Because the number of such connections can be quite large, the reconnection algorithm employed by entities that seek to reconnect can have a significant impact on software and network performance. The following guidelines are RECOMMENDED:
| TOC |
The root stream element MAY contain an <error/> child element that is prefixed by the streams namespace prefix. The error child shall be sent by a compliant entity (typically a server rather than a client) if it perceives that a stream-level error has occurred.
| TOC |
The following rules apply to stream-level errors.
| TOC |
Stream-level errors are unrecoverable. Therefore, if an error occurs at the level of the stream, the entity that detects the error MUST send a stream error to the other entity, send a closing </stream> tag, and terminate the underlying TCP connection.
C: <message><body></message>
S: <stream:error>
<xml-not-well-formed
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
| TOC |
If the error occurs while the stream is being set up, the receiving entity MUST still send the opening <stream> tag, include the <error/> element as a child of the stream element, send the closing </stream> tag, and terminate the underlying TCP connection.
C: <?xml version='1.0'?>
<stream:stream
from='juliet@example.com'
to='example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://wrong.ns.example.org/'>
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
<stream:error>
<invalid-namespace
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
| TOC |
If the initiating entity provides no 'to' attribute or provides an unknown host in the 'to' attribute and the error occurs during stream setup, the receiving entity SHOULD provide its authoritative hostname in the 'from' attribute of the stream header sent before termination.
C: <?xml version='1.0'?>
<stream:stream
from='juliet@example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://wrong.ns.example.org/'>
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error>
<invalid-namespace
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
| TOC |
The syntax for stream errors is as follows, where "defined-condition" is a placeholder for one of the conditions defined under Section 5.8.3 (Defined Stream Error Conditions).
<stream:error>
<defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
[<text xmlns='urn:ietf:params:xml:ns:xmpp-streams'
xml:lang='langcode'>
descriptive text
</text>]
[application-specific condition element]
</stream:error>
The <error/> element:
The <text/> element is OPTIONAL. If included, it SHOULD be used only to provide descriptive or diagnostic information that supplements the meaning of a defined condition or application-specific condition. It SHOULD NOT be interpreted programmatically by an application. It SHOULD NOT be used as the error message presented to a human user, but MAY be shown in addition to the error message associated with the included condition element (or elements).
| TOC |
The following stream-level error conditions are defined.
| TOC |
The entity has sent XML that cannot be processed.
C: <message><body></message>
S: <stream:error>
<bad-format
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
This error MAY be used instead of the more specific XML-related errors, such as <bad-namespace-prefix/>, <invalid-xml/>, <restricted-xml/>, <unsupported-encoding/>, and <xml-not-well-formed/>. However, the more specific errors are preferred.
| TOC |
The entity has sent a namespace prefix that is unsupported, or has sent no namespace prefix on an element that requires such a prefix (see Section 12.2 (XML Namespace Names and Prefixes)).
C: <?xml version='1.0'?>
<stream:stream
from='juliet@example.com'
to='example.com'
version='1.0'
xmlns='jabber:client'
xmlns:foobar='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error>
<bad-namespace-prefix
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
| TOC |
The server is either (1) closing the existing stream for this entity because a new stream has been initiated that conflicts with the existing stream (2) is refusing a new stream for this entity because allowing the new stream would conflict with an existing stream (e.g., because the server allows only a certain number of connections for the same IP address).
C: <?xml version='1.0'?>
<stream:stream
from='juliet@example.com'
to='example.com'
version='1.0'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error>
<conflict
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
| TOC |
The entity has not generated any traffic over the stream for some period of time (configurable according to a local service policy) and therefore the connection is being dropped.
S: <stream:error>
<connection-timeout
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
| TOC |
The value of the 'to' attribute provided by the initiating entity in the stream header corresponds to a hostname that is no longer hosted by the server.
P: <?xml version='1.0'?>
<stream:stream
from='example.net'
to='foo.example.org'
version='1.0'
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='g4qSvGvBxJ+xeAd7QKezOQJFFlw='
to='example.net'
version='1.0'
xml:lang='en'
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error>
<host-gone
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
| TOC |
The value of the 'to' attribute provided by the initiating entity in the stream header does not correspond to a hostname that is hosted by the server.
P: <?xml version='1.0'?>
<stream:stream
from='example.net'
to='example.org'
version='1.0'
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='g4qSvGvBxJ+xeAd7QKezOQJFFlw='
to='example.net'
version='1.0'
xml:lang='en'
xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error>
<host-unknown
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
| TOC |
A stanza sent between two servers lacks a 'to' or 'from' attribute (or the attribute has no value).
P: <message from='juliet@example.com'>
<body>Wherefore art thou?</body>
</message>
S: <stream:error>
<improper-addressing
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
| TOC |
The server has experienced a misconfiguration or an otherwise-undefined internal error that prevents it from servicing the stream.
S: <stream:error>
<internal-server-error
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
| TOC |
The JID or hostname provided in a 'from' address does not match an authorized JID or validated domain negotiated between servers via SASL, or between a client and a server via authentication and resource binding.
P: <message from='romeo@example.org' to='juliet@example.com'>
<body>Neither, fair saint, if either thee dislike.</body>
</message>
S: <stream:error>
<improper-addressing
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
| TOC |
The stream ID or server dialback ID is invalid or does not match an ID previously provided (the following example is from server dialback; see [XEP‑0220] (Saint-Andre, P. and J. Miller, “Server Dialback,” June 2007.)).
P: <db:verify
from='example.net'
to='example.com'
id='unknown-id-here'
type='invalid'/>
S: <stream:error>
<invalid-id
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
| TOC |
The streams namespace name is something other than "http://etherx.jabber.org/streams" (see Section 12.2 (XML Namespace Names and Prefixes)).
C: <?xml version='1.0'?>
<stream:stream
from='juliet@example.com'
to='example.com'
version='1.0'
xmlns='jabber:client'
xmlns:stream='http://wrong.ns.example.org/'>
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error>
<invalid-namespace
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
| TOC |
The entity has sent invalid XML over the stream to a server that performs validation (see Section 12.3 (Validation)). (In the following example, a peer attempts to send an IQ stanza of type "subscribe" but there is no such value for the 'type' attribute.)
P: <iq from='example.net'
id='some-id'
to='example.com'
type='subscribe'>
<ping xmlns='urn:xmpp:ping'/>
</iq>
S: <stream:error>
<invalid-xml
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
| TOC |
The entity has attempted to send XML stanzas before the stream has been authenticated, or otherwise is not authorized to perform an action related to stream negotiation; the receiving entity MUST NOT process the offending stanza before sending the stream error. (In the following example, a client attempts to send XML stanzas before authenticating with the server.)
C: <?xml version='1.0'?>
<stream:stream
from='juliet@example.com'
to='example.com'
version='1.0'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
C: <message to='romeo@example.net'>
<body>Wherefore art thou?</body>
</message>
S: <stream:error>
<not-authorized
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
| TOC |
The entity has violated some local service policy (e.g., the stanza exceeds a configured size limit); the server MAY choose to specify the policy in the <text/> element or an application-specific condition element.
C: <message to='juliet@example.com' id='foo'>
<body>[ ... the-emacs-manual ... ]</body>
</message>
S: <stream:error>
<policy-violation
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
S: </stream:stream>
| TOC |
The server is unable to properly connect to a remote entity that is required for authentication or authorization.
C: <?xml version='1.0'?>
<stream:stream
from='juliet@example.com'
to='example.com'
version='1.0'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error>
<remote-connection-failed
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
| TOC |
The server lacks the system resources necessary to service the stream.
C: <?xml version='1.0'?>
<stream:stream
from='juliet@example.com'
to='example.com'
version='1.0'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error>
<resource-constraint
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
| TOC |
The entity has attempted to send restricted XML features such as a comment, processing instruction, DTD, entity reference, or unescaped character (see Section 12.1 (Restrictions)).
C: <message to='juliet@example.com'>
<body><!--just a comment!--></body>
</message>
S: <stream:error>
<restricted-xml
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
| TOC |
The server will not provide service to the initiating entity but is redirecting traffic to another host; the XML character data of the <see-other-host/> element returned by the server SHOULD specify the alternate hostname or IP address at which to connect, which SHOULD be a valid domain identifier but may also include a port number; if no port is specified, the initiating entity SHOULD perform a [DNS‑SRV] (Gulbrandsen, A., Vixie, P., and L. Esibov, “A DNS RR for specifying the location of services (DNS SRV),” February 2000.) lookup on the provided domain identifier but MAY assume that it can connect to that domain identifier at the standard XMPP ports (5222 for client-to-server connections and 5269 for server-to-server connections).
C: <?xml version='1.0'?>
<stream:stream
from='juliet@example.com'
to='example.com'
version='1.0'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error>
<see-other-host
xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
xmpp.example.com:9090
</see-other-host>
</stream:error>
</stream:stream>
| TOC |
The server is being shut down and all active streams are being closed.
S: <stream:error>
<system-shutdown
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
| TOC |
The error condition is not one of those defined by the other conditions in this list; this error condition SHOULD be used only in conjunction with an application-specific condition.
S: <stream:error>
<undefined-condition
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
<app-error xmlns='some-application-ns'/>
</stream:error>
</stream:stream>
| TOC |
The initiating entity has encoded the stream in an encoding that is not supported by the server (see Section 12.5 (Character Encoding)).
C: <?xml version='1.0' encoding='UTF-16'?>
<stream:stream
from='juliet@example.com'
to='example.com'
version='1.0'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
<stream:error>
<unsupported-encoding
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
| TOC |
The initiating entity has sent a first-level child of the stream that is not supported by the server.
C: <pubsub>
<publish node='princely_musings'>
<item id='ae890ac52d0df67ed7cfdf51b644e901'>
<entry xmlns='http://www.w3.org/2005/Atom'>
<title>Soliloquy</title>
<summary>
To be, or not to be: that is the question:
Whether 'tis nobler in the mind to suffer
The slings and arrows of outrageous fortune,
Or to take arms against a sea of troubles,
And by opposing end them?
</summary>
<link rel='alternate' type='text/html'
href='http://denmark.lit/2003/12/13/atom03'/>
<id>tag:denmark.lit,2003:entry-32397</id>
<published>2003-12-13T18:30:02Z</published>
<updated>2003-12-13T18:30:02Z</updated>
</entry>
</item>
</publish>
</pubsub>
S: <stream:error>
<unsupported-stanza-type
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
| TOC |
The value of the 'version' attribute provided by the initiating entity in the stream header specifies a version of XMPP that is not supported by the server; the server MAY specify the version(s) it supports in the <text/> element.
C: <?xml version='1.0'?>
<stream:stream
from='juliet@example.com'
to='example.com'
version='11.0'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
<stream:error>
<unsupported-version
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
| TOC |
<xml-not-well-formed/> -- the initiating entity has sent XML that is not well-formed as defined by [XML] (Paoli, J., Maler, E., Sperberg-McQueen, C., Yergeau, F., and T. Bray, “Extensible Markup Language (XML) 1.0 (Fourth Edition),” August 2006.).
C: <message><body></message>
S: <stream:error>
<xml-not-well-formed
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
| TOC |
As noted, an application MAY provide application-specific stream error information by including a properly-namespaced child in the error element. The application-specific element SHOULD supplement or further qualify a defined element. Thus the <error/> element will contain two or three child elements:
C: <message>
<body>
My keyboard layout is:
QWERTYUIOP{}|
ASDFGHJKL:"
ZXCVBNM<>?
</body>
</message>
S: <stream:error>
<xml-not-well-formed
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
<text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
Some special application diagnostic information!
</text>
<escape-your-data xmlns='application-ns'/>
</stream:error>
</stream:stream>
| TOC |
This section contains two simplified examples of a stream-based connection of a client on a server (where the "C" lines are sent from the client to the server, and the "S" lines are sent from the server to the client); these examples are included for the purpose of illustrating the concepts introduced thus far.
A basic connection:
C: <?xml version='1.0'?>
<stream:stream
from='juliet@example.com'
to='example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
[ ... encryption, authentication, and resource binding ... ]
C: <message from='juliet@example.com/balcony'
to='romeo@example.net'
xml:lang='en'>
<body>Art thou not Romeo, and a Montague?</body>
</message>
S: <message from='romeo@example.net/orchard'
to='juliet@example.com/balcony'
xml:lang='en'>
<body>Neither, fair saint, if either thee dislike.</body>
</message>
C: </stream:stream>
S: </stream:stream>
A connection gone bad:
C: <?xml version='1.0'?>
<stream:stream
from='juliet@example.com'
to='example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?>
<stream:stream
from='example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
[ ... encryption, authentication, and resource binding ... ]
C: <message from='juliet@example.com/balcony'
to='romeo@example.net'
xml:lang='en'>
<body>Bad XML, no closing body tag!
</message>
S: <stream:error>
<xml-not-well-formed
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
More detailed examples are provided under Section 10 (Examples).
| TOC |
| TOC |
XMPP includes a method for securing the stream from tampering and eavesdropping. This channel encryption method makes use of the Transport Layer Security protocol (see [TLS] (Dierks, T. and E. Rescorla, “The Transport Layer Security (TLS) Protocol Version 1.1,” April 2006.)), specifically a "STARTTLS" extension that is modelled after similar extensions for the [IMAP] (Crispin, M., “INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1,” March 2003.), [POP3] (Myers, J. and M. Rose, “Post Office Protocol - Version 3,” May 1996.), and [ACAP] (Newman, C. and J. Myers, “ACAP -- Application Configuration Access Protocol,” November 1997.) protocols as described in [USINGTLS] (Newman, C., “Using TLS with IMAP, POP3 and ACAP,” June 1999.). The XML namespace name for the STARTTLS extension is 'urn:ietf:params:xml:ns:xmpp-tls'.
Support for STARTTLS is REQUIRED in XMPP client and server implementations. An administrator of a given deployment may require the use of TLS for client-to-server communication, server-to-server communication, or both. A deployed client should use TLS to secure its stream with a server prior to attempting the completion of SASL negotiation (SASL Negotiation), and deployed servers should use TLS between two domains for the purpose of securing server-to-server communication.
| TOC |
| TOC |
The entities MUST NOT send any white space characters (matching production [3] content of [XML] (Paoli, J., Maler, E., Sp