Network Working Group P. Saint-Andre, Ed. Internet-Draft XMPP Standards Foundation Obsoletes: 3920 (if approved) July 17, 2007 Intended status: Standards Track Expires: January 18, 2008 Extensible Messaging and Presence Protocol (XMPP): Core draft-saintandre-rfc3920bis-03 Status of this Memo 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 Notice Copyright (C) The IETF Trust (2007). Abstract 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 Saint-Andre Expires January 18, 2008 [Page 1] Internet-Draft XMPP Core July 2007 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Functional Summary . . . . . . . . . . . . . . . . . . . 5 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . 7 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 2.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Client . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.4. Network . . . . . . . . . . . . . . . . . . . . . . . . 9 3. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 3.2. Domain Identifier . . . . . . . . . . . . . . . . . . . 10 3.3. Node Identifier . . . . . . . . . . . . . . . . . . . . 11 3.4. Resource Identifier . . . . . . . . . . . . . . . . . . 11 3.5. Determination of Addresses . . . . . . . . . . . . . . . 12 4. TCP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . . 13 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 13 5.2. Stream Security . . . . . . . . . . . . . . . . . . . . 15 5.3. Stream Attributes . . . . . . . . . . . . . . . . . . . 16 5.4. Namespace Declarations . . . . . . . . . . . . . . . . . 22 5.5. Stream Features . . . . . . . . . . . . . . . . . . . . 22 5.6. Closing Streams . . . . . . . . . . . . . . . . . . . . 23 5.7. Reconnection . . . . . . . . . . . . . . . . . . . . . . 24 5.8. Stream Errors . . . . . . . . . . . . . . . . . . . . . 24 5.9. Simplified Stream Examples . . . . . . . . . . . . . . . 41 6. STARTTLS Negotiation . . . . . . . . . . . . . . . . . . . . 43 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 43 6.2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . 44 6.3. Process . . . . . . . . . . . . . . . . . . . . . . . . 44 6.4. Representation of JIDs in Certificates . . . . . . . . . 48 7. SASL Negotiation . . . . . . . . . . . . . . . . . . . . . . 49 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 49 7.2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . 49 7.3. Process . . . . . . . . . . . . . . . . . . . . . . . . 51 7.4. SASL Definition . . . . . . . . . . . . . . . . . . . . 56 Saint-Andre Expires January 18, 2008 [Page 2] Internet-Draft XMPP Core July 2007 7.5. SASL Errors . . . . . . . . . . . . . . . . . . . . . . 57 8. Resource Binding . . . . . . . . . . . . . . . . . . . . . . 60 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 60 8.2. Advertising Support . . . . . . . . . . . . . . . . . . 60 8.3. Server-Generated Resource Identifier . . . . . . . . . . 61 8.4. Client-Generated Resource Identifier . . . . . . . . . . 62 8.5. Binding Multiple Resources . . . . . . . . . . . . . . . 64 9. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 67 9.1. Common Attributes . . . . . . . . . . . . . . . . . . . 67 9.2. Basic Semantics . . . . . . . . . . . . . . . . . . . . 71 9.3. Stanza Errors . . . . . . . . . . . . . . . . . . . . . 73 9.4. Extended Content . . . . . . . . . . . . . . . . . . . . 88 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 89 10.1. Client-to-Server . . . . . . . . . . . . . . . . . . . . 89 10.2. Server-to-Server Examples . . . . . . . . . . . . . . . 95 11. Server Rules for Processing XML Stanzas . . . . . . . . . . . 99 11.1. No 'to' Address . . . . . . . . . . . . . . . . . . . . 99 11.2. Local Domain . . . . . . . . . . . . . . . . . . . . . . 100 11.3. Resource at Local Domain . . . . . . . . . . . . . . . . 100 11.4. Node at Local Domain . . . . . . . . . . . . . . . . . . 101 11.5. Foreign Domain . . . . . . . . . . . . . . . . . . . . . 101 12. XML Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 102 12.1. Restrictions . . . . . . . . . . . . . . . . . . . . . . 102 12.2. XML Namespace Names and Prefixes . . . . . . . . . . . . 103 12.3. Validation . . . . . . . . . . . . . . . . . . . . . . . 105 12.4. Inclusion of Text Declaration . . . . . . . . . . . . . 106 12.5. Character Encoding . . . . . . . . . . . . . . . . . . . 106 12.6. White Space . . . . . . . . . . . . . . . . . . . . . . 106 13. Compliance Requirements . . . . . . . . . . . . . . . . . . . 106 13.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . 107 13.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . 107 14. Internationalization Considerations . . . . . . . . . . . . . 107 15. Security Considerations . . . . . . . . . . . . . . . . . . . 108 15.1. High Security . . . . . . . . . . . . . . . . . . . . . 108 15.2. Certificate Validation . . . . . . . . . . . . . . . . . 108 15.3. Client-to-Server Communication . . . . . . . . . . . . . 109 15.4. Server-to-Server Communication . . . . . . . . . . . . . 110 15.5. Order of Layers . . . . . . . . . . . . . . . . . . . . 110 15.6. Lack of SASL Channel Binding to TLS . . . . . . . . . . 110 15.7. Mandatory-to-Implement Technologies . . . . . . . . . . 111 15.8. Firewalls . . . . . . . . . . . . . . . . . . . . . . . 111 15.9. Use of base64 in SASL . . . . . . . . . . . . . . . . . 111 15.10. Stringprep Profiles . . . . . . . . . . . . . . . . . . 111 15.11. Address Spoofing . . . . . . . . . . . . . . . . . . . . 112 15.12. Denial of Service . . . . . . . . . . . . . . . . . . . 114 15.13. Presence Leaks . . . . . . . . . . . . . . . . . . . . . 115 15.14. Directory Harvesting . . . . . . . . . . . . . . . . . . 116 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 116 Saint-Andre Expires January 18, 2008 [Page 3] Internet-Draft XMPP Core July 2007 16.1. XML Namespace Name for TLS Data . . . . . . . . . . . . 116 16.2. XML Namespace Name for SASL Data . . . . . . . . . . . . 116 16.3. XML Namespace Name for Stream Errors . . . . . . . . . . 116 16.4. XML Namespace Name for Resource Binding . . . . . . . . 117 16.5. XML Namespace Name for Stanza Errors . . . . . . . . . . 117 16.6. Nodeprep Profile of Stringprep . . . . . . . . . . . . . 117 16.7. Resourceprep Profile of Stringprep . . . . . . . . . . . 118 16.8. GSSAPI Service Name . . . . . . . . . . . . . . . . . . 118 16.9. Port Numbers . . . . . . . . . . . . . . . . . . . . . . 118 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 118 17.1. Normative References . . . . . . . . . . . . . . . . . . 118 17.2. Informative References . . . . . . . . . . . . . . . . . 120 Appendix A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . 124 A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 124 A.2. Character Repertoire . . . . . . . . . . . . . . . . . . 124 A.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . 124 A.4. Normalization . . . . . . . . . . . . . . . . . . . . . 124 A.5. Prohibited Output . . . . . . . . . . . . . . . . . . . 125 A.6. Bidirectional Characters . . . . . . . . . . . . . . . . 125 Appendix B. Resourceprep . . . . . . . . . . . . . . . . . . . . 125 B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 125 B.2. Character Repertoire . . . . . . . . . . . . . . . . . . 126 B.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . 126 B.4. Normalization . . . . . . . . . . . . . . . . . . . . . 126 B.5. Prohibited Output . . . . . . . . . . . . . . . . . . . 126 B.6. Bidirectional Characters . . . . . . . . . . . . . . . . 127 Appendix C. XML Schemas . . . . . . . . . . . . . . . . . . . . 127 C.1. Streams namespace . . . . . . . . . . . . . . . . . . . 127 C.2. Stream error namespace . . . . . . . . . . . . . . . . . 128 C.3. TLS namespace . . . . . . . . . . . . . . . . . . . . . 131 C.4. SASL namespace . . . . . . . . . . . . . . . . . . . . . 131 C.5. Resource binding namespace . . . . . . . . . . . . . . . 133 C.6. Stanza error namespace . . . . . . . . . . . . . . . . . 135 Appendix D. Contact Addresses . . . . . . . . . . . . . . . . . 136 Appendix E. Account Provisioning . . . . . . . . . . . . . . . . 137 Appendix F. Differences From RFC 3920 . . . . . . . . . . . . . 137 Appendix G. Copying Conditions . . . . . . . . . . . . . . . . . 138 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 139 Intellectual Property and Copyright Statements . . . . . . . . . 140 Saint-Andre Expires January 18, 2008 [Page 4] Internet-Draft XMPP Core July 2007 1. Introduction 1.1. Overview The Extensible Messaging and Presence Protocol (XMPP) is an Extensible Markup Language [XML] 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] 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: o Corrections and errata o Additional examples throughout o Clarifications and more complete specification of matters that were underspecified o Modifications to reflect updated technologies for which XMPP is a using protocol (e.g., Transport Layer Security and the Simple Authentication and Security Layer) o Definition of several additional error conditions o Addition of TLS plus SASL PLAIN as a mandatory-to-implement technology o Definition of optional support for multiple resources over the same connection o Removal of historical documentation for the server dialback protocol from this specification to a separate specification 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] are specified in [XMPP-IM]. 1.2. Functional Summary This non-normative section provides a developer-friendly, functional summary of XMPP; refer to the sections that follow for a normative definition of XMPP. Saint-Andre Expires January 18, 2008 [Page 5] Internet-Draft XMPP Core July 2007 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: 1. Determine the hostname and port at which to connect 2. Open a TCP connection 3. Open an XML stream 4. Complete TLS negotiation for channel encryption (recommended) 5. Complete SASL negotiation for authentication 6. Bind a resource to the stream 7. Exchange an unbounded number of XML stanzas with other entities on the network 8. Close the XML stream 9. Close the TCP connection 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] 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: 1. Determine the hostname and port at which to connect 2. Open a TCP connection 3. Open an XML stream 4. Complete TLS negotiation for channel encryption (recommended) 5. Complete SASL negotiation for authentication 6. Exchange an unbounded number of XML stanzas both directly for the servers and indirectly on behalf of entities associated with each server (e.g., connected clients) 7. Close the XML stream Saint-Andre Expires January 18, 2008 [Page 6] Internet-Draft XMPP Core July 2007 8. Close the TCP connection 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]. 1.3. Conventions The following keywords are to be interpreted as described in [TERMS]: "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: o C: = client o E: = any XMPP entity o I: = initiating entity o P: = peer server o R: = receiving entity o S: = server o S1: = server1 o S2: = server2 2. Architecture 2.1. Overview XMPP assumes a client-server architecture, wherein a client utilizing XMPP accesses a server (normally over a [TCP] 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: o romeo@example.net -- an XMPP user. o example.net -- an XMPP server. o example.com -- an XMPP server. o juliet@example.com -- an XMPP user. example.net -------------------- example.com | | | | romeo@example.net juliet@example.com Saint-Andre Expires January 18, 2008 [Page 7] Internet-Draft XMPP Core July 2007 Note: Architectures that employ the syntax of XML stanzas (Section 9) but that establish peer-to-peer connections directly between clients using technologies based on [LINKLOCAL] have been deployed, but such architectures are not XMPP and are best described as "XMPP-like"; for details, see [XEP-0174]. 2.2. Server A SERVER is an entity whose primary responsibilities are to: o Manage XML streams (Section 5) with local clients and deliver XML stanzas (Section 9) to those clients over the negotiated XML streams. o Subject to local service policies on server-to-server communication, manage XML streams (Section 5) with foreign servers and route XML stanzas (Section 9) to those servers over the negotiated XML streams. Depending on the application, the secondary responsibilities of an XMPP server may include: o Storing XML data that is used by clients (e.g., contact lists for users of XMPP-based instant messaging and presence applications); in this case, the relevant XML stanza is handled directly by the server itself on behalf of the client and is not routed to a foreign server or delivered to a local entity. o Hosting local services that also use XMPP as the basis for communication but that provide additional functionality beyond that defined in this document or in [XMPP-IM]; examples include multi-user conferencing services as specified in [XEP-0045] and publish-subscribe services as specified in [XEP-0060]. 2.3. Client 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 (Section 8) 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., vs. ), as defined under Section 3 and Section 8. The RECOMMENDED port for TCP connections between a client and a server is 5222, as registered with the IANA (see Section 16.9). Saint-Andre Expires January 18, 2008 [Page 8] Internet-Draft XMPP Core July 2007 2.4. Network 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, is able to exchange messages, presence, and other information with . This pattern is familiar from messaging protocols (such as [SMTP]) 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] connections. The RECOMMENDED port for tCP connections between servers is 5269, as registered with the IANA (see Section 16.9. 3. Addresses 3.1. Overview 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]. 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 Saint-Andre Expires January 18, 2008 [Page 9] Internet-Draft XMPP Core July 2007 server that hosts the account, and a connected resource (e.g., a specific device) in the form of . However, node types other than clients are possible; for example, a specific chat room offered by a multi-user conference service (see [XEP-0045]) could be addressed as (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 (where "nick" is the occupant's room nickname). Many other JID types are possible (e.g., 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], an entity's address on an XMPP network MUST be a JID (without a URI scheme) and not a [URI] or [IRI] as specified in [XMPP-URI]; the latter specification is provided only for use by non-XMPP applications. 3.2. Domain Identifier 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]) 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] or [STD13], 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]; in particular, the character should be stripped before any other canonicalization steps are taken (such as application of the [NAMEPREP] profile of [STRINGPREP] or completion of the ToASCII operation as described in [IDNA]). Saint-Andre Expires January 18, 2008 [Page 10] Internet-Draft XMPP Core July 2007 A domain identifier MUST be an "internationalized domain name" as defined in [IDNA], 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] 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]. (Note: The ToASCII operation includes application of the [NAMEPREP] profile of [STRINGPREP] and encoding using the algorithm specified in [PUNYCODE]; for details, see [IDNA].) 3.3. Node Identifier 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 ) is called a BARE JID. A node identifier MUST be formatted such that the Nodeprep profile of [STRINGPREP] can be applied without failing (see Appendix A). Before comparing two node identifiers, an application MUST first apply the Nodeprep profile to each identifier. 3.4. Resource Identifier 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 address or a mere 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 Saint-Andre Expires January 18, 2008 [Page 11] Internet-Draft XMPP Core July 2007 identifier is negotiated between a client and a server during resource binding (Section 8), after which the entity is referred to as a CONNECTED RESOURCE and its address (of the form ) 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] can be applied without failing (see Appendix B). Before comparing two resource identifiers, an application MUST first apply the Resourceprep profile to each identifier. 3.5. Determination of Addresses After SASL negotiation (Section 7) and, if appropriate, resource binding (Section 8), 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]), if no authorization identity was specified during SASL negotiation (Section 7). For client-to-server communication, the bare JID () SHOULD be the authorization identity, derived from the authentication identity (as defined by [SASL]), if no authorization identity was specified during SASL negotiation (Section 7); the resource identifier portion of the full JID () SHOULD be the resource identifier negotiated by the client and server during resource binding (Section 8). 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. TCP Binding 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 Saint-Andre Expires January 18, 2008 [Page 12] Internet-Draft XMPP Core July 2007 the receiving entity. The process is: 1. Attempt to resolve the hostname using a [DNS-SRV] Service of "xmpp-client" (for client-to-server connections) or "xmpp-server" (for server-to-server connections) and Proto of "tcp", resulting in resource records such as "_xmpp-client._tcp.example.com." or "_xmpp-server._tcp.example.com."; the IP address and port at which the initiating entity attempts to connect to the receiving entity shall be those specified in the SRV lookup result. 2. If the SRV lookup fails, the fallback SHOULD be a normal IPv4 or [IPv6] address record resolution to determine the IP address, where the port used is the "xmpp-client" port of 5222 for client- to-server connections or the "xmpp-server" port 5269 for server- to-server connections. 3. For client-to-server connections, the fallback MAY be a [DNS-TXT] lookup for alternative connection methods, for example as described in [XEP-0156]. TCP connections are handled differently in client-to-server communication and server-to-server ommunication. Specifically: o Because a client is subordinate to a server and therefore a client authenticates to the server but the server does not authenticate to the client, it is necessary to have only one TCP connection between client and server. Thus the server MUST allow the client to share a single TCP connection for XML stanzas sent from client to server and from server to client (i.e., the inital stream and response stream as specified under Section 5). o Because two servers are peers and therefore each peer must authenticate with the other, the servers MUST use two TCP connections: one for XML stanzas sent from the first server to the second server and another (initiated by the second server) for stanzas from the second server to the first server. Note: There is no necessary coupling of an XML stream to a [TCP] connection. For example, two entities could connect to each other via another transport, such as [HTTP] as specified in [XEP-0124] and [XEP-0206]. However, this specification defines a binding of XMPP to TCP only. 5. XML Streams 5.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 Saint-Andre Expires January 18, 2008 [Page 13] Internet-Draft XMPP Core July 2007 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 tag (with appropriate attributes and namespace declarations), while the end of the XML stream is denoted unambiguously by a closing XML 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 (Section 6) or SASL negotiation (Section 7)) 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 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., ), and the end of any XML stanza is denoted unambiguously by the corresponding close tag at depth=1 (e.g., ); 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 , , and elements qualified by the default namespace for the stream, as described under Section 9; an XML element sent for the purpose of TLS negotiation (Section 6) or SASL negotiation (Section 7) 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] as well as Section 9.4 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 tag to the server, optionally preceded by a text declaration specifying the XML version and the character encoding supported (see Section 12.4 and Section 12.5). Subject to Saint-Andre Expires January 18, 2008 [Page 14] Internet-Draft XMPP Core July 2007 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 7) and resource binding (Section 8), 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 tag to the server (see Section 5.6). 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. +--------------------+ | | |--------------------| | | | | | | |--------------------| | | | | | | |--------------------| | | | | | | |--------------------| | [ ... ] | |--------------------| | | +--------------------+ 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 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. 5.2. Stream Security For the purpose of stream security, both Transport Layer Security (see Section 6) and the Simple Authentication and Security Layer (see Section 7) are mandatory to implement. Saint-Andre Expires January 18, 2008 [Page 15] Internet-Draft XMPP Core July 2007 When negotiating XML streams in XMPP 1.0, TLS SHOULD be used as defined under Section 6 and SASL MUST be used as defined under Section 7. 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 (Section 9) 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 stream error and then terminate both the XML stream and the underlying TCP connection. Note: This applies to XML stanzas only (i.e., , , and elements qualified by the default namespace) and not to XML elements used for stream negotiation (e.g., elements used to complete TLS negotiation (Section 6) or SASL negotiation (Section 7)). 5.3. Stream Attributes The attributes of the root element are as follows. 5.3.1. from 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 = ) of the entity controlling the client. C: 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. Saint-Andre Expires January 18, 2008 [Page 16] Internet-Draft XMPP Core July 2007 P: 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: Note: Each entity MUST verify the identity of the other entity before exchanging XML stanzas with it (see Section 15.3 and Section 15.4). 5.3.2. to 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: 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 Saint-Andre Expires January 18, 2008 [Page 17] Internet-Draft XMPP Core July 2007 specified in the 'from' attribute of the XML stream header sent from the initiating entity to the receiving entity. S: 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: Note: Each entity MUST verify the identity of the other entity before exchanging XML stanzas with it (see Section 15.3 and Section 15.4). 5.3.3. id 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: 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: Note: The stream ID may be security-critical and therefore MUST be both unpredictable and nonrepeating (see [RANDOM] for recommendations regarding randomness for security purposes). 5.3.4. xml:lang An 'xml:lang' attribute (as defined in Section 2.12 of [XML]) 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: 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. Saint-Andre Expires January 18, 2008 [Page 19] Internet-Draft XMPP Core July 2007 S: 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). The value of the 'xml:lang' attribute MUST conform to the NMTOKEN datatype (as defined in Section 2.3 of [XML]) and MUST conform to the format defined in [LANGTAGS]. 5.3.5. version 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 (Section 6), SASL negotiation (Section 7), and stream errors (Section 5.8)), as well as the semantics of the three defined XML stanza types (, , and ). The numbering scheme for XMPP versions is ".". 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 Saint-Andre Expires January 18, 2008 [Page 20] Internet-Draft XMPP Core July 2007 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: 1. The initiating entity MUST set the value of the 'version' attribute on the initial stream header to the highest version number it supports (e.g., if the highest version number it supports is that defined in this specification, it MUST set the value to "1.0"). 2. The receiving entity MUST set the value of the 'version' attribute on the response stream header to either the value supplied by the initiating entity or the highest version number supported by the receiving entity, whichever is lower. The receiving entity MUST perform a numeric comparison on the major and minor version numbers, not a string match on ".". 3. If the version number included in the response stream header is at least one major version lower than the version number included in the initial stream header and newer version entities cannot interoperate with older version entities as described, the initiating entity SHOULD generate an stream error and terminate the XML stream and underlying TCP connection. 4. If either entity receives a stream header with no 'version' attribute, the entity MUST consider the version supported by the other entity to be "0.9" and SHOULD NOT include a 'version' attribute in the stream header it sends in reply. 5.3.6. Summary We can summarize the attributes of the root 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 | +----------+--------------------------+-------------------------+ Saint-Andre Expires January 18, 2008 [Page 21] Internet-Draft XMPP Core July 2007 Note: The attributes of the root element are not prepended by a 'stream:' prefix because, in accordance with Section 5.3 of [XML-NAMES], the default namespace does not apply to attribute names. 5.4. Namespace Declarations The stream element MUST possess both a streams namespace declaration and a default namespace declaration (as "namespace declaration" is defined in [XML-NAMES]). For detailed information regarding the streams namespace and default namespace, see Section 12.2. 5.5. Stream Features 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 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: S: Stream features are used mainly to advertise TLS negotiation (Section 6), SASL negotiation (Section 7), and resource binding (Section 8); 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. Saint-Andre Expires January 18, 2008 [Page 22] Internet-Draft XMPP Core July 2007 If a feature must be negotiated before the initiating entity may proceed, that feature SHOULD include a 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 element after sending a stream header to the initiating entity. S: S: 5.6. Closing Streams 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: The entity that sends the closing stream tag SHOULD wait for the other entity to also close its stream: S: 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 Saint-Andre Expires January 18, 2008 [Page 23] Internet-Draft XMPP Core July 2007 there are two TCP connections for server-to-server streams. 5.7. Reconnection 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: o The time to live (TTL) specified in Domain Name System records SHOULD be honored, even if DNS results are cached; if the TTL has not expired, an entity that seeks to reconnect SHOULD NOT re- resolve the server hostname before reconnecting. o The time that expires before an entity first seeks to reconnect SHOULD be randomized (e.g., so that all clients do not attempt to reconnect 30 seconds after being disconnected). o If the first reconnection attempt does not succeed, an entity SHOULD back off exponentially on the time between subsequent reconnection attempts. 5.8. Stream Errors The root stream element MAY contain an 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. 5.8.1. Rules The following rules apply to stream-level errors. 5.8.1.1. Stream Errors Are Unrecoverable 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 tag, and terminate the underlying TCP connection. C: S: Saint-Andre Expires January 18, 2008 [Page 24] Internet-Draft XMPP Core July 2007 5.8.1.2. Stream Errors Can Occur During Setup If the error occurs while the stream is being set up, the receiving entity MUST still send the opening tag, include the element as a child of the stream element, send the closing tag, and terminate the underlying TCP connection. C: S: 5.8.1.3. Stream Errors When the Host is Unspecified 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. Saint-Andre Expires January 18, 2008 [Page 25] Internet-Draft XMPP Core July 2007 C: S: 5.8.2. Syntax 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. [ descriptive text ] [application-specific condition element] The element: o MUST contain a child element corresponding to one of the defined stream error conditions (Section 5.8.3); this element MUST be qualified by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace. o MAY contain a child element containing XML character data that describes the error in more detail; this element MUST be qualified by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace and SHOULD possess an 'xml:lang' attribute specifying the natural language of the XML character data. Saint-Andre Expires January 18, 2008 [Page 26] Internet-Draft XMPP Core July 2007 o MAY contain a child element for an application-specific error condition; this element MUST be qualified by an application- defined namespace, and its structure is defined by that namespace (see Section 5.8.4). The 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). 5.8.3. Defined Stream Error Conditions The following stream-level error conditions are defined. 5.8.3.1. bad-format The entity has sent XML that cannot be processed. C: S: This error MAY be used instead of the more specific XML-related errors, such as , , , , and . However, the more specific errors are preferred. 5.8.3.2. bad-namespace-prefix 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). Saint-Andre Expires January 18, 2008 [Page 27] Internet-Draft XMPP Core July 2007 C: S: 5.8.3.3. conflict 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). Saint-Andre Expires January 18, 2008 [Page 28] Internet-Draft XMPP Core July 2007 C: S: 5.8.3.4. connection-timeout 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: 5.8.3.5. host-gone 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. Saint-Andre Expires January 18, 2008 [Page 29] Internet-Draft XMPP Core July 2007 P: S: 5.8.3.6. host-unknown 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. Saint-Andre Expires January 18, 2008 [Page 30] Internet-Draft XMPP Core July 2007 P: S: 5.8.3.7. improper-addressing A stanza sent between two servers lacks a 'to' or 'from' attribute (or the attribute has no value). P: Wherefore art thou? S: 5.8.3.8. internal-server-error The server has experienced a misconfiguration or an otherwise- undefined internal error that prevents it from servicing the stream. S: Saint-Andre Expires January 18, 2008 [Page 31] Internet-Draft XMPP Core July 2007 5.8.3.9. invalid-from 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: Neither, fair saint, if either thee dislike. S: 5.8.3.10. invalid-id 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]). P: S: 5.8.3.11. invalid-namespace The streams namespace name is something other than "http://etherx.jabber.org/streams" (see Section 12.2). Saint-Andre Expires January 18, 2008 [Page 32] Internet-Draft XMPP Core July 2007 C: S: 5.8.3.12. invalid-xml The entity has sent invalid XML over the stream to a server that performs validation (see Section 12.3). (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: S: 5.8.3.13. not-authorized 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 Saint-Andre Expires January 18, 2008 [Page 33] Internet-Draft XMPP Core July 2007 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: S: Wherefore art thou? S: 5.8.3.14. policy-violation 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 element or an application-specific condition element. C: [ ... the-emacs-manual ... ] S: Saint-Andre Expires January 18, 2008 [Page 34] Internet-Draft XMPP Core July 2007 S: 5.8.3.15. remote-connection-failed The server is unable to properly connect to a remote entity that is required for authentication or authorization. C: S: 5.8.3.16. resource-constraint The server lacks the system resources necessary to service the stream. Saint-Andre Expires January 18, 2008 [Page 35] Internet-Draft XMPP Core July 2007 C: S: 5.8.3.17. restricted-xml 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). C: S: 5.8.3.18. see-other-host The server will not provide service to the initiating entity but is redirecting traffic to another host; the XML character data of the 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] lookup on the provided domain identifier but MAY assume that it can Saint-Andre Expires January 18, 2008 [Page 36] Internet-Draft XMPP Core July 2007 connect to that domain identifier at the standard XMPP ports (5222 for client-to-server connections and 5269 for server-to-server connections). C: S: xmpp.example.com:9090 5.8.3.19. system-shutdown The server is being shut down and all active streams are being closed. S: 5.8.3.20. undefined-condition 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. Saint-Andre Expires January 18, 2008 [Page 37] Internet-Draft XMPP Core July 2007 S: 5.8.3.21. unsupported-encoding The initiating entity has encoded the stream in an encoding that is not supported by the server (see Section 12.5). C: S: 5.8.3.22. unsupported-stanza-type The initiating entity has sent a first-level child of the stream that is not supported by the server. Saint-Andre Expires January 18, 2008 [Page 38] Internet-Draft XMPP Core July 2007 C: Soliloquy 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? tag:denmark.lit,2003:entry-32397 2003-12-13T18:30:02Z 2003-12-13T18:30:02Z S: 5.8.3.23. unsupported-version 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 element. Saint-Andre Expires January 18, 2008 [Page 39] Internet-Draft XMPP Core July 2007 C: S: 5.8.3.24. xml-not-well-formed -- the initiating entity has sent XML that is not well-formed as defined by [XML]. C: S: 5.8.4. Application-Specific Conditions 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 element will contain two or three child elements: Saint-Andre Expires January 18, 2008 [Page 40] Internet-Draft XMPP Core July 2007 C: My keyboard layout is: QWERTYUIOP{}| ASDFGHJKL:" ZXCVBNM<>? S: Some special application diagnostic information! 5.9. Simplified Stream Examples 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. Saint-Andre Expires January 18, 2008 [Page 41] Internet-Draft XMPP Core July 2007 A basic connection: C: [ ... encryption, authentication, and resource binding ... ] C: Art thou not Romeo, and a Montague? S: Neither, fair saint, if either thee dislike. C: S: Saint-Andre Expires January 18, 2008 [Page 42] Internet-Draft XMPP Core July 2007 A connection gone bad: C: S: [ ... encryption, authentication, and resource binding ... ] C: Bad XML, no closing body tag! S: More detailed examples are provided under Section 10. 6. STARTTLS Negotiation 6.1. Overview 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]), specifically a "STARTTLS" extension that is modelled after similar extensions for the [IMAP], [POP3], and [ACAP] protocols as described in [USINGTLS]. Saint-Andre Expires January 18, 2008 [Page 43] Internet-Draft XMPP Core July 2007 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 (Section 7), and deployed servers should use TLS between two domains for the purpose of securing server-to-server communication. 6.2. Rules 6.2.1. Data Formatting The entities MUST NOT send any white space characters (matching production [3] content of [XML]) within the root stream element as separators between elements (any white space characters shown in the STARTTLS examples provided in this document are included for the sake of readability only); this prohibition helps to ensure proper security layer byte precision. 6.2.2. Order of Negotiation If the initiating entity chooses to use TLS, STARTTLS negotiation MUST be completed before proceeding to SASL negotiation (Section 7); this order of negotiation is required to help safeguard authentication information sent during SASL negotiation, as well as to make it possible to base the use of the SASL EXTERNAL mechanism on a certificate (or other credentials) provided during prior TLS negotiation. 6.3. Process 6.3.1. Exchange of Stream Headers and Stream Features The initiating entity resolves the hostname of the receiving entity as specified under Section 4, opens a TCP connection to the advertised port at the resolved IP address, and sends an initial stream header to the receiving entity; if the initiating entity is capable of STARTTLS negotiation, it MUST include the 'version' attribute set to a value of at least "1.0" in the initial stream header. Saint-Andre Expires January 18, 2008 [Page 44] Internet-Draft XMPP Core July 2007 I: The receiving entity MUST send a response stream header to the initiating entity over the TCP connection opened by the initiating entity (for client-to-server streams) or over a new TCP connection (for server-to-server streams); if the receiving entity is capable of STARTTLS negotiation, it MUST include the 'version' attribute set to a value of at least "1.0" in the response stream header. R: element (qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace) to indicate that the receiving entity supports STARTTLS negotiation. R: If the receiving entity requires the use of STARTTLS, it SHOULD include an empty element as a child of the element. R: 6.3.2. Initiation of STARTTLS Negotiation In order to begin the STARTTLS negotiation, the initiating entity issues the STARTTLS command (i.e., a element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace) to instruct the Saint-Andre Expires January 18, 2008 [Page 45] Internet-Draft XMPP Core July 2007 receiving entity that it wishes to begin a STARTTLS negotiation to secure the stream. I: The receiving entity MUST reply with either a element (proceed case) or a element (failure case) qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace. If the failure case occurs, the receiving entity MUST return a element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace, terminate the XML stream, and terminate the underlying TCP connection. Causes for the failure case include but are not limited to: 1. The initiating entity has sent a malformed STARTTLS command. 2. The receiving entity does not offer STARTTLS negotiation either temporarily or permanently. 3. The receiving entity cannot complete STARTTLS negotiation because of an internal error. R: R: If the proceed case occurs, the receiving entity MUST return a element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace. R: Note: The receiving entity MUST consider the TLS negotiation to have begun immediately after sending the closing '>' character of the element to the initiating entity. The initiating entity MUST consider the TLS negotiation to have begun immediately after receiving the closing '>' character of the element from the receiving entity. 6.3.3. TLS Negotiation The entities MUST now attempt to complete TLS negotiation over the TCP connection by following the process defined in [TLS]. Note: The entities MUST NOT send any further XML data until the TLS negotiation has either failed or succeeded. If the receiving entity presents a certificate during TLS negotiation, the initiating entity MUST validate the certificate in Saint-Andre Expires January 18, 2008 [Page 46] Internet-Draft XMPP Core July 2007 order to determine if the TLS negotiation shall succeed (see Section 15.2 regarding certificate validation procedures). Specifically, the certificate MUST be checked against the hostname as provided by the initiating entity (e.g., a user), not the hostname as resolved via the Domain Name System; e.g., if the user specifies a hostname of "example.net" but a [DNS-SRV] lookup returns "xmpp.example.net", the certificate MUST be checked as "example.net". See Section 6.4 for information about the representation of XMPP addresses in certificates. Note: See Section 15.7 regarding ciphers that MUST be supported for TLS; naturally, other ciphers MAY be supported as well. 6.3.4. Failure If the TLS negotiation results in failure, the receiving entity MUST terminate the TCP connection. Note: It is not necessary to send a closing tag before terminating the TCP connection, since the receiving entity and initiating entity MUST consider the original stream to be closed upon failure of the TLS negotiation. 6.3.5. Success If the TLS negotiation is successful, then the entities MUST proceed as follows. The receiving entity MUST discard any knowledge obtained in an insecure manner from the initiating entity before TLS took effect. The initiating entity MUST discard any knowledge obtained in an insecure manner from the receiving entity before TLS took effect. The initiating entity MUST send a new stream header to the receiving entity over the secured TCP connection. I: Note: It is not necessary to send a closing tag before sending the initial stream header, since the receiving entity and initiating entity MUST consider the original stream to be closed upon Saint-Andre Expires January 18, 2008 [Page 47] Internet-Draft XMPP Core July 2007 success of the TLS negotiation. The receiving entity MUST respond with a response stream header. R: EXTERNAL DIGEST-MD5 PLAIN 6.4. Representation of JIDs in Certificates TLS negotiation is commonly based on a digital certificate presented by the receiving entity (or in the case of mutual authentication both the receiving entity and the initiating entity). If a JID for an XMPP user account is represented in a certificate, it MUST be represented as a UTF8String within an otherName entity inside the subjectAltName, using the [ASN.1] Object Identifier "id-on- xmppAddr" specified in this section. If a JID for an XMPP server is represented in a certificate, it SHOULD be represented as a UTF8String within an otherName entity inside the subjectAltName, using the [ASN.1] Object Identifier "id- on-xmppAddr" specified in this section. However, in addition to or instead of the "id-on-xmppAddr" representation, it MAY be represented as a subjectAltName extension of type dNSName; this dNSName MAY contain the wildcard character '*', which applies only to the left- most domain name component or component fragment and is considered to match any single component or component fragment (e.g., *.example.com matches foo.example.com but not bar.foo.example.com, and im*.example.net matches im1.example.net and im2.example.net but not Saint-Andre Expires January 18, 2008 [Page 48] Internet-Draft XMPP Core July 2007 chat.example.net). The [ASN.1] Object Identifier "id-on-xmppAddr" is defined as follows. id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) } id-on OBJECT IDENTIFIER ::= { id-pkix 8 } -- other name forms id-on-xmppAddr OBJECT IDENTIFIER ::= { id-on 5 } XmppAddr ::= UTF8String This Object Identifier MAY be represented in dotted display format (i.e., "1.3.6.1.5.5.7.8.5") or in the Uniform Resource Name notation specified in [URN-OID] (i.e., "urn:oid:1.3.6.1.5.5.7.8.5"). Thus for example the JID "juliet@example.com" as included in a certificate could be formatted in any of the following three ways: o subjectAltName=otherName:id-on-xmppAddr;UTF8:juliet@example.com o subjectAltName=otherName:1.3.6.1.5.5.7.8.5;UTF8:juliet@example.com o subjectAltName=otherName:urn:oid:1.3.6.1.5.5.7.8.5;UTF8:juliet@ example.com 7. SASL Negotiation 7.1. Overview XMPP includes a method for authenticating a stream by means of an XMPP-specific profile of the Simple Authentication and Security Layer protocol (see [SASL]). SASL provides a generalized method for adding authentication support to connection-based protocols, and XMPP uses an XML namespace profile of SASL that conforms to the profiling requirements of [SASL]. Support for SASL is REQUIRED in XMPP client and server implementations. 7.2. Rules 7.2.1. Data Formatting The following formatting rules apply to the data sent during SASL negotiation: Saint-Andre Expires January 18, 2008 [Page 49] Internet-Draft XMPP Core July 2007 1. The entities MUST NOT send any white space characters (matching production [3] content of [XML]) within the root stream element as separators between elements (any white space characters shown in the SASL examples provided in this document are included for the sake of readability only); this prohibition helps to ensure proper security layer byte precision. 2. Any XML character data contained within the XML elements MUST be encoded using base64, where the encoding adheres to the definition in Section 4 of [BASE64] and where the padding bits are set to zero. 7.2.2. Security Layers Upon successful SASL negotiation that involves negotiation of a security layer, the initiating entity MUST discard any knowledge obtained from the receiving entity which was not obtained from the SASL negotiation itself. Upon successful SASL negotiation that involves negotiation of a security layer, the receiving entity MUST discard any knowledge obtained from the initiating entity which was not obtained from the SASL negotiation itself. The receiving entity SHOULD also include an updated list of SASL mechanisms with the stream features so that the initiating entity is able to detect any changes to the list of mechanisms supported by the receiving entity. 7.2.3. Simple Usernames If provision of a "simple username" is supported by the selected SASL mechanism (e.g., this is supported by the DIGEST-MD5 and CRAM-MD5 mechanisms but not by the EXTERNAL and GSSAPI mechanisms), during authentication the initiating entity SHOULD provide as the simple username its sending domain (IP address or fully qualified domain name as contained in an XMPP domain identifier) in the case of server-to-server communication or its registered account name (user or node name as contained in an XMPP node identifier) in the case of client-to-server communication. In either case, the initiating entity MUST ensure that the username adheres to the [NAMEPREP] or Nodeprep (Appendix A) profile of [STRINGPREP] (as appropriate) before sending it to the receiving entity. 7.2.4. Authorization Identities If the initiating entity wishes to act on behalf of another entity and the selected SASL mechanism supports transmission of an authorization identity, the initiating entity MUST provide an authorization identity during SASL negotiation. If the initiating entity does not wish to act on behalf of another entity, it MUST NOT Saint-Andre Expires January 18, 2008 [Page 50] Internet-Draft XMPP Core July 2007 provide an authorization identity. As specified in [SASL], the initiating entity MUST NOT provide an authorization identity unless the authorization identity is different from the default authorization identity derived from the authentication identity. If provided, the value of the authorization identity MUST be of the form (i.e., an XMPP domain identifier only) for servers and of the form (i.e., node identifier and domain identifier) for clients. 7.3. Process The process for SASL negotiation is as follows. 7.3.1. Exchange of Stream Headers and Stream Features If SASL negotiation follows successful STARTTLS negotation (Section 6), then the SASL negotiation occurs over the existing stream. If not, the initiating entity resolves the hostname of the receiving entity as specified under Section 4, opens a TCP connection to the advertised port at the resolved IP address, and sends an initial stream header to the receiving entity; if the initiating entity is capable of STARTTLS negotiation, it MUST include the 'version' attribute set to a value of at least "1.0" in the initial stream header. I: The receiving entity MUST send a response stream header to the initiating entity; if the receiving entity is capable of SASL negotiation, it MUST include the 'version' attribute set to a value of at least "1.0" in the response stream header. R: element (qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace) that contains one child element for each authentication mechanism the receiving entity offers to the initiating entity. The order of elements in the XML indicates the preference order of the SASL mechanisms according to the receiving entity. R: EXTERNAL DIGEST-MD5 PLAIN Note: If the initiating entity presents a valid certificate during prior TLS negotiation, the receiving entity SHOULD offer the SASL EXTERNAL mechanism to the initiating entity during SASL negotiation (refer to [SASL]), although the EXTERNAL mechanism MAY be offered under other circumstances as well. Note: If TLS negotiation (Section 6) needs to be completed before a particular authentication mechanism may be used, the receiving entity MUST NOT provide that mechanism in the list of available SASL authentication mechanisms prior to TLS negotiation. Note: See Section 15.7 regarding mechanisms that MUST be supported; naturally, other SASL mechanisms MAY be supported as well (best practices for the use of several SASL mechanisms in the context of XMPP are described in [XEP-0175] and [XEP-0178]). If successful SASL negotiation is required for interaction with the receiving entity, it SHOULD signal that fact by including a element as a child of the element. R: EXTERNAL DIGEST-MD5 PLAIN Note: The receiving entity MAY include an application-specific child element inside the element in order to provide information that may be needed by the initiating in order to complete Saint-Andre Expires January 18, 2008 [Page 52] Internet-Draft XMPP Core July 2007 successful SASL negotiation using one or more of the offered mechanisms; however, the syntax and semantics of any such element are out of scope for this specification. 7.3.2. Initiation In order to begin the SASL negotiation, the initiating entity sends an element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace and includes an appropriate value for the 'mechanism' attribute. This element MAY contain XML character data (in SASL terminology, the "initial response") if the mechanism supports or requires it; if the initiating entity needs to send a zero-length initial response, it MUST transmit the response as a single equals sign ("="), which indicates that the response is present but contains no data. I: = 7.3.3. Challenge-Response Sequence If necessary, the receiving entity challenges the initiating entity by sending a element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace; this element MAY contain XML character data (which MUST be generated in accordance with the definition of the SASL mechanism chosen by the initiating entity). R: cmVhbG09ImV4YW1wbGUuY29tIixub25jZT0iT0E2TUc5dEVRR20yaGgiLHFvcD0i YXV0aCIsY2hhcnNldD11dGYtOCxhbGdvcml0aG09bWQ1LXNlc3MK The decoded challenge is: realm="example.com",nonce="OA6MG9tEQGm2hh", qop="auth",charset=utf-8,algorithm=md5-sess Note: If the receiving entity does not specify a 'realm' value, the initiating entity MUST default it to the domain identifier portion of the receiving entity's JID. The initiating entity responds to the challenge by sending a element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace; this element MAY contain XML character data (which MUST be generated in accordance with the definition of the SASL mechanism chosen by the initiating entity). Saint-Andre Expires January 18, 2008 [Page 53] Internet-Draft XMPP Core July 2007 I: dXNlcm5hbWU9Imp1bGlldCIscmVhbG09ImV4YW1wbGUuY29tIixub25jZT0iT0E2 TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAwMDAwMDAx LHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20iLHJlc3BvbnNl PWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNoYXJzZXQ9dXRmLTgK The decoded response is: username="juliet",realm="example.com", nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk", nc=00000001,qop=auth,digest-uri="xmpp/example.com", response=d388dad90d4bbd760a152321f2143af7,charset=utf-8 If necessary, the receiving entity sends more challenges and the initiating entity sends more responses. This series of challenge/response pairs continues until one of three things happens: o The initiating entity aborts the handshake. o The receiving entity reports failure of the handshake. o The receiving entity reports success of the handshake. These scenarios are described in the following sections. 7.3.4. Abort The initiating entity aborts the handshake by sending an element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace. I: Upon receiving an element, the receiving entity MUST return an element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace. R: The receiving entity SHOULD allow a configurable but reasonable number of retries (at least 2 and no more than 5); this enables the initiating entity (e.g., an end-user client) to tolerate incorrectly- provided credentials (e.g., a mistyped password) without being forced to reconnect. If the initiating entity exceeds the number of retries, the receiving entity MUST terminate the TCP connection. Saint-Andre Expires January 18, 2008 [Page 54] Internet-Draft XMPP Core July 2007 7.3.5. Failure The receiving entity reports failure of the handshake by sending a element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace (the particular cause of failure SHOULD be communicated in an appropriate child element of the element as defined under Section 7.5). R: If the failure case occurs, the receiving entity SHOULD allow a configurable but reasonable number of retries (at least 2 and no more than 5); this enables the initiating entity (e.g., an end-user client) to tolerate incorrectly-provided credentials (e.g., a mistyped password) without being forced to reconnect. If the initiating entity exceeds the number of retries, the receiving entity MUST terminate the TCP connection. 7.3.6. Success The receiving entity reports success of the handshake by sending a element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace; this element MAY contain XML character data (in SASL terminology, "additional data with success") if required by the chosen SASL mechanism; if the receiving entity needs to send additional data of zero length, it MUST transmit the data as a single equals sign ("="). R: cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo= The decoded value for subsequent authentication is: rspauth=ea40f60335c427b5527b84dbabcdfffd Upon receiving the element, the initiating entity MUST initiate a new stream over the existing TCP connection by sending an initial stream header to the receiving entity. Saint-Andre Expires January 18, 2008 [Page 55] Internet-Draft XMPP Core July 2007 I: tag before sending the initial stream header, since the receiving entity and initiating entity MUST consider the original stream to be closed upon sending or receiving the element. Upon receiving the initial stream header from the initiating entity, the receiving entity MUST respond by sending a new XML stream header to the initiating entity. R: The receiving entity MUST also send stream features, containing any further available features or containing no features (via an empty element); any such additional features not defined herein MUST be defined by the relevant extension to XMPP. R: 7.4. SASL Definition The profiling requirements of [SASL] require that the following information be supplied by a protocol definition: service name: "xmpp" initiation sequence: After the initiating entity provides an opening XML stream header and the receiving entity replies in kind, the receiving entity provides a list of acceptable authentication methods. The initiating entity chooses one method from the list and sends it to the receiving entity as the value of the Saint-Andre Expires January 18, 2008 [Page 56] Internet-Draft XMPP Core July 2007 'mechanism' attribute possessed by an element, optionally including an initial response to avoid a round trip. exchange sequence: Challenges and responses are carried through the exchange of elements from receiving entity to initiating entity and elements from initiating entity to receiving entity. The receiving entity reports failure by sending a element and success by sending a element; the initiating entity aborts the exchange by sending an element. Upon successful negotiation, both sides consider the original XML stream to be closed and new stream headers are sent by both entities. security layer negotiation: The security layer takes effect immediately after sending the closing '>' character of the element for the receiving entity, and immediately after receiving the closing '>' character of the element for the initiating entity. The order of layers is first [TCP], then [TLS], then [SASL], then XMPP. use of the authorization identity: The authorization identity may be used by XMPP to denote the non-default of a client or the sending of a server; an empty string is equivalent to an absent authorization identity. 7.5. SASL Errors The following SASL-related error conditions are defined. 7.5.1. aborted The receiving entity acknowledges an element sent by the initiating entity; sent in reply to the element. I: R: 7.5.2. incorrect-encoding The data provided by the initiating entity could not be processed because the [BASE64] encoding is incorrect (e.g., because the encoding does not adhere to the definition in Section 4 of [BASE64]); sent in reply to a element or an element with initial response data. Saint-Andre Expires January 18, 2008 [Page 57] Internet-Draft XMPP Core July 2007 I: [ ... ] R: 7.5.3. invalid-authzid The authzid provided by the initiating entity is invalid, either because it is incorrectly formatted or because the initiating entity does not have permissions to authorize that ID; sent in reply to a element or an element with initial response data. I: [ ... ] R: 7.5.4. invalid-mechanism The initiating entity did not provide a mechanism or requested a mechanism that is not supported by the receiving entity; sent in reply to an element. I: R: 7.5.5. malformed-request The request is malformed (e.g., the element includes an initial response but the mechanism does not allow that); sent in reply to an , , , or element. I: [ ... ] R: Saint-Andre Expires January 18, 2008 [Page 58] Internet-Draft XMPP Core July 2007 7.5.6. mechanism-too-weak The mechanism requested by the initiating entity is weaker than server policy permits for that initiating entity; sent in reply to an element (with or without initial response data) or a element. I: R: 7.5.7. not-authorized The authentication failed because the initiating entity did not provide proper credentials; sent in reply to a element or an element with initial response data. I: [ ... ] R: Note: This error condition includes but is not limited to the case of incorrect credentials or an unknown username. In order to discourage directory harvest attacks, no differentiation is made between incorrect credentials and an unknown username. 7.5.8. temporary-auth-failure The authentication failed because of a temporary error condition within the receiving entity, and the initiating entity should try again later; sent in reply to an element or element. I: [ ... ] R: Saint-Andre Expires January 18, 2008 [Page 59] Internet-Draft XMPP Core July 2007 8. Resource Binding 8.1. Overview After a client authenticates with a server, it MUST bind a specific resource to the stream so that the server can properly address the client (see Section 3), i.e., there MUST be an XMPP resource identifier associated with the bare JID () of the client with the result that the address for use over that stream is a full JID of the form . This ensures that the server can deliver XML stanzas to and receive XML stanzas from the client (see Section 11). After binding a resource to the stream, the client is referred to as a connected resource. If, before completing the resource binding step, the client attempts to send an outbound XML stanza (i.e., a stanza not directed to the server itself or to the client's own account), the server MUST NOT process the stanza and SHOULD return a stream error to the client. Support for resource binding is REQUIRED in XMPP client and server implementations. 8.2. Advertising Support Upon receiving a success indication within the SASL negotiation, the client MUST send a new stream header to the server, to which the server MUST respond with a stream header as well as a list of available stream features. Specifically, for client-to-server streams the server MUST include a element qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace in the stream features it presents to the client; this element SHOULD include an empty element to explicitly indicate that resource binding must be completed at this stage of the stream negotiation process. (Note: The server SHOULD NOT include the stream feature until after successful SASL negotiation.) Saint-Andre Expires January 18, 2008 [Page 60] Internet-Draft XMPP Core July 2007 S: S: Upon being so informed that resource binding is required, the client MUST bind a resource to the stream as described in the following sections. 8.3. Server-Generated Resource Identifier A server that supports resource binding MUST be able to generate an XMPP resource identifier on behalf of a client. The resource identifier generated by the server MUST at a minimum be unique among the connected resources for that and SHOULD be random since the resource identifier may be security-critical. It is RECOMMENDED that the server-generated resource identifier be a Universally Unique Identifier (UUID), for which the format specified in [UUID] is RECOMMENDED. It is RECOMMENDED for the client to ask its server to generate an appropriate resource identifier on its behalf, rather than generating a resource on its own and requesting that the server accept the client-generated resource identifer. 8.3.1. Success Case A client requests a server-generated resource identifier by sending an IQ stanza of type "set" (see Section 9.2.3) containing an empty element qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' namespace. C: Once the server has generated an XMPP resource identifier for the client, it MUST return an IQ stanza of type "result" to the client, Saint-Andre Expires January 18, 2008 [Page 61] Internet-Draft XMPP Core July 2007 which MUST include a child element that specifies the full JID for the connected resource as determined by the server. S: juliet@example.com/4db06f06-1ea4-11dc-aca3-000bcd821bfb 8.3.2. Error Case It is possible that the client is not allowed to bind a resource to the stream (e.g., because the node or user has reached a limit on the number of connected resources allowed). In this case, the server MUST return a stanza error to the client. S: 8.4. Client-Generated Resource Identifier A client MAY attempt to specify the resource identifier on its own rather than asking the server to generate a resource identifier on its behalf. 8.4.1. Success Case A client asks its server to accept a client-generated resource identifier by sending an IQ stanza of type "set" containing a element with a child element containing non-zero-length XML character data. C: balcony The server MAY accept the resource identifier provided by the client, in which case it returns an IQ stanza of type "result" to the client, including a child element that specifies the full JID for the connected resource. Saint-Andre Expires January 18, 2008 [Page 62] Internet-Draft XMPP Core July 2007 S: juliet@example.com/balcony However, the server MAY instead override the client-generated resource identifier and generate a resource identifier on behalf of the client, as shown in the previous section. 8.4.2. Error Cases When a client attempts to set its own XMPP resource identifier during resource binding, the following stanza error conditions are possible: o The client is not allowed to bind a resource to the stream (e.g., because the node or user has reached a limit on the number of connected resources allowed). o The provided resource identifier cannot be processed by the server, e.g. because it is not in accordance with the Resourceprep (Appendix B) profile of [STRINGPREP]). o The provided resource identifier is already in use but the server does not allow binding of multiple connected resources with the same identifier. 8.4.2.1. Not Allowed If the client is not allowed to bind a resource to the stream, the server MUST return a error. S: 8.4.2.2. Bad Request If the provided resource identifier cannot be processed by the server, the server SHOULD return a error (but MAY instead apply the Resourceprep (Appendix B) profile of [STRINGPREP] or otherwise process the resource identifier so that it is in conformance). S: Saint-Andre Expires January 18, 2008 [Page 63] Internet-Draft XMPP Core July 2007 8.4.2.3. Conflict If there is already a connected resource of the same name, the server MUST do one of the following: 1. Not accept the resource identifier provided by the client but instead override it with an XMPP resource identifier that the server generates. 2. Terminate the current resource and allow the newly-requested resource. 3. Disallow the newly-requested resource and maintain the current resource. Which of these the server does is up to the implementation, although it is RECOMMENDED to implement case #1. In case #2, the server MUST send a stream error to the current resource, terminate the XML stream and underlying TCP connection for the current resource, and return an IQ stanza of type "result" (indicating success) to the newly-requested resource. In case #3, the server MUST send a stanza error to the newly-requested resource but maintain the XML stream for that connection so that the newly-requested resource has an opportunity to negotiate a non-conflicting resource identifier before sending another request for resource binding. 8.5. Binding Multiple Resources A server MAY support binding of multiple resources to the same stream. This functionality is desirable in certain environments (e.g., for devices that are unable to open more than one TCP connection or when a machine runs a local XMPP client daemon that is used by multiple applications). 8.5.1. Support If a server supports binding of multiple resources to a stream, it MUST enable a client to unbind resources. A server that supports unbinding MUST also support binding of multiple resources. Thus a client can discover whether a server supports binding of multiple resources by determining if the server advertises a stream feature of , as follows. Saint-Andre Expires January 18, 2008 [Page 64] Internet-Draft XMPP Core July 2007 S: