idnits 2.17.1 draft-ietf-xmpp-core-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 28 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1005 has weird spacing: '... it it MU...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 7, 2003) is 7690 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '43' is mentioned on line 372, but not defined -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 2155 -- Possible downref: Non-RFC (?) normative reference: ref. '1' == Outdated reference: A later version (-22) exists of draft-ietf-xmpp-im-08 ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '3') ** Obsolete normative reference: RFC 793 (ref. '5') (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2396 (ref. '7') (Obsoleted by RFC 3986) ** Downref: Normative reference to an Unknown state RFC: RFC 952 (ref. '8') -- Unexpected draft version: The latest known version of draft-ietf-idn-nameprep is -10, but you're referring to -11. ** Obsolete normative reference: RFC 3454 (ref. '11') (Obsoleted by RFC 7564) == Outdated reference: A later version (-03) exists of draft-ietf-xmpp-nodeprep-01 -- Possible downref: Normative reference to a draft: ref. '12' == Outdated reference: A later version (-03) exists of draft-ietf-xmpp-resourceprep-01 -- Possible downref: Normative reference to a draft: ref. '13' -- Possible downref: Non-RFC (?) normative reference: ref. '14' == Outdated reference: A later version (-05) exists of draft-mealling-iana-xmlns-registry-04 ** Obsolete normative reference: RFC 2246 (ref. '16') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2060 (ref. '17') (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 2222 (ref. '21') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 3066 (ref. '22') (Obsoleted by RFC 4646, RFC 4647) ** Obsolete normative reference: RFC 2052 (ref. '23') (Obsoleted by RFC 2782) ** Obsolete normative reference: RFC 2616 (ref. '24') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2279 (ref. '25') (Obsoleted by RFC 3629) ** Downref: Normative reference to an Informational RFC: RFC 2781 (ref. '26') -- Possible downref: Non-RFC (?) normative reference: ref. '27' == Outdated reference: A later version (-09) exists of draft-ietf-xmpp-e2e-00 ** Obsolete normative reference: RFC 2078 (ref. '29') (Obsoleted by RFC 2743) Summary: 17 errors (**), 0 flaws (~~), 11 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft J. Miller 4 Expires: October 6, 2003 Jabber Software Foundation 5 April 7, 2003 7 XMPP Core 8 draft-ietf-xmpp-core-08 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on October 6, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document describes the core features of the Extensible Messaging 39 and Presence Protocol (XMPP), a protocol for streaming XML elements 40 in order to exchange messages and presence information in close to 41 real time. XMPP is used mainly for the purpose of building instant 42 messaging (IM) and presence applications, such as the servers and 43 clients that comprise the Jabber network. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 48 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 49 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 50 1.3 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . 5 51 1.4 Intellectual Property Notice . . . . . . . . . . . . . . . . 5 52 2. Generalized Architecture . . . . . . . . . . . . . . . . . . 6 53 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 2.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 2.3 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 2.4 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 2.5 Network . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 3. Addressing Scheme . . . . . . . . . . . . . . . . . . . . . 8 59 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.2 Domain Identifier . . . . . . . . . . . . . . . . . . . . . 8 61 3.3 Node Identifier . . . . . . . . . . . . . . . . . . . . . . 8 62 3.4 Resource Identifier . . . . . . . . . . . . . . . . . . . . 9 63 4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . 10 64 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.2 Stream Attributes . . . . . . . . . . . . . . . . . . . . . 11 66 4.3 Namespace Declarations . . . . . . . . . . . . . . . . . . . 12 67 4.4 Stream Features . . . . . . . . . . . . . . . . . . . . . . 13 68 4.5 Stream Errors . . . . . . . . . . . . . . . . . . . . . . . 13 69 4.5.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 4.5.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 4.5.3 Conditions . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 4.5.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . . 16 73 4.6 Simple Streams Example . . . . . . . . . . . . . . . . . . . 16 74 5. Stream Encryption . . . . . . . . . . . . . . . . . . . . . 18 75 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 18 76 5.2 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . 19 77 5.3 Client-to-Server Example . . . . . . . . . . . . . . . . . . 20 78 5.4 Server-to-Server Example . . . . . . . . . . . . . . . . . . 21 79 6. Stream Authentication . . . . . . . . . . . . . . . . . . . 24 80 6.1 SASL Authentication . . . . . . . . . . . . . . . . . . . . 24 81 6.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 24 82 6.1.2 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . 25 83 6.1.3 SASL Definition . . . . . . . . . . . . . . . . . . . . . . 26 84 6.1.4 Client-to-Server Example . . . . . . . . . . . . . . . . . . 27 85 6.1.5 Server-to-Server Example . . . . . . . . . . . . . . . . . . 29 86 6.2 Dialback Authentication . . . . . . . . . . . . . . . . . . 31 87 6.2.1 Dialback Protocol . . . . . . . . . . . . . . . . . . . . . 34 88 7. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . 37 89 7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 37 90 7.2 Common Attributes . . . . . . . . . . . . . . . . . . . . . 37 91 7.2.1 to . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 92 7.2.2 from . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 93 7.2.3 id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 94 7.2.4 type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 95 7.2.5 xml:lang . . . . . . . . . . . . . . . . . . . . . . . . . . 38 96 7.3 Message Stanzas . . . . . . . . . . . . . . . . . . . . . . 38 97 7.3.1 Types of Message . . . . . . . . . . . . . . . . . . . . . . 39 98 7.3.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 39 99 7.4 Presence Stanzas . . . . . . . . . . . . . . . . . . . . . . 40 100 7.4.1 Types of Presence . . . . . . . . . . . . . . . . . . . . . 41 101 7.4.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 41 102 7.5 IQ Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 42 103 7.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 43 104 7.5.2 Types of IQ . . . . . . . . . . . . . . . . . . . . . . . . 43 105 7.5.3 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 44 106 7.6 Extended Namespaces . . . . . . . . . . . . . . . . . . . . 44 107 7.7 Stanza Errors . . . . . . . . . . . . . . . . . . . . . . . 45 108 7.7.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 109 7.7.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 110 7.7.3 Conditions . . . . . . . . . . . . . . . . . . . . . . . . . 46 111 7.7.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . . 47 112 8. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 48 113 8.1 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 48 114 8.2 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . 48 115 8.3 Validation . . . . . . . . . . . . . . . . . . . . . . . . . 48 116 8.4 Character Encodings . . . . . . . . . . . . . . . . . . . . 49 117 8.5 Inclusion of Text Declaration . . . . . . . . . . . . . . . 49 118 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 50 119 9.1 XML Namespace Name for Stream Errors . . . . . . . . . . . . 50 120 9.2 XML Namespace Name for Stanza Errors . . . . . . . . . . . . 50 121 9.3 Existing Registrations . . . . . . . . . . . . . . . . . . . 50 122 10. Internationalization Considerations . . . . . . . . . . . . 51 123 11. Security Considerations . . . . . . . . . . . . . . . . . . 52 124 11.1 High Security . . . . . . . . . . . . . . . . . . . . . . . 52 125 11.2 Client-to-Server Communications . . . . . . . . . . . . . . 52 126 11.3 Server-to-Server Communications . . . . . . . . . . . . . . 52 127 11.4 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . 53 128 11.5 Mandatory to Implement Technologies . . . . . . . . . . . . 53 129 References . . . . . . . . . . . . . . . . . . . . . . . . . 54 130 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 56 131 A. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . 57 132 A.1 Streams namespace . . . . . . . . . . . . . . . . . . . . . 57 133 A.2 TLS namespace . . . . . . . . . . . . . . . . . . . . . . . 58 134 A.3 SASL namespace . . . . . . . . . . . . . . . . . . . . . . . 58 135 A.4 Dialback namespace . . . . . . . . . . . . . . . . . . . . . 59 136 A.5 Client namespace . . . . . . . . . . . . . . . . . . . . . . 60 137 A.6 Server namespace . . . . . . . . . . . . . . . . . . . . . . 63 138 A.7 Stream error namespace . . . . . . . . . . . . . . . . . . . 66 139 A.8 Stanza error namespace . . . . . . . . . . . . . . . . . . . 67 140 B. Revision History . . . . . . . . . . . . . . . . . . . . . . 69 141 B.1 Changes from draft-ietf-xmpp-core-07 . . . . . . . . . . . . 69 142 B.2 Changes from draft-ietf-xmpp-core-06 . . . . . . . . . . . . 69 143 B.3 Changes from draft-ietf-xmpp-core-05 . . . . . . . . . . . . 69 144 B.4 Changes from draft-ietf-xmpp-core-04 . . . . . . . . . . . . 69 145 B.5 Changes from draft-ietf-xmpp-core-03 . . . . . . . . . . . . 70 146 B.6 Changes from draft-ietf-xmpp-core-02 . . . . . . . . . . . . 70 147 B.7 Changes from draft-ietf-xmpp-core-01 . . . . . . . . . . . . 70 148 B.8 Changes from draft-ietf-xmpp-core-00 . . . . . . . . . . . . 70 149 B.9 Changes from draft-miller-xmpp-core-02 . . . . . . . . . . . 71 150 Intellectual Property and Copyright Statements . . . . . . . 72 152 1. Introduction 154 1.1 Overview 156 The Extensible Messaging and Presence Protocol (XMPP) is an open XML 157 [1] protocol for near-real-time messaging, presence, and 158 request-response services. The basic syntax and semantics were 159 developed originally within the Jabber open-source community, mainly 160 in 1999. In 2002, the XMPP WG was chartered with developing an 161 adaptation of the Jabber protocol that would be suitable as an IETF 162 instant messaging and presence technology. As a result of work by the 163 XMPP WG, the current document defines the core features of XMPP; XMPP 164 IM [2] defines the extensions required to provide the instant 165 messaging (IM) and presence functionality defined in RFC 2779 [3]. 167 1.2 Terminology 169 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 170 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 171 "OPTIONAL" in this document are to be interpreted as described in RFC 172 2119 [4]. 174 1.3 Discussion Venue 176 The authors welcome discussion and comments related to the topics 177 presented in this document. The preferred forum is the 178 mailing list, for which archives and subscription 179 information are available at . 182 1.4 Intellectual Property Notice 184 This document is in full compliance with all provisions of Section 10 185 of RFC 2026. Parts of this specification use the term "jabber" for 186 identifying namespaces and other protocol syntax. Jabber[tm] is a 187 registered trademark of Jabber, Inc. Jabber, Inc. grants permission 188 to the IETF for use of the Jabber trademark in association with this 189 specification and its successors, if any. 191 2. Generalized Architecture 193 2.1 Overview 195 Although XMPP is not wedded to any specific network architecture, to 196 this point it has usually been implemented via a typical 197 client-server architecture, wherein a client utilizing XMPP accesses 198 a server over a TCP [5] socket. 200 The following diagram provides a high-level overview of this 201 architecture (where "-" represents communications that use XMPP and 202 "=" represents communications that use any other protocol). 204 C1 - S1 - S2 - C3 205 / \ 206 C2 - G1 = FN1 = FC1 208 The symbols are as follows: 210 o C1, C2, C3 -- XMPP clients 212 o S1, S2 -- XMPP servers 214 o G1 -- A gateway that translates between XMPP and the protocol(s) 215 used on a foreign (non-XMPP) messaging network 217 o FN1 -- A foreign messaging network 219 o FC1 -- A client on a foreign messaging network 221 2.2 Server 223 A server acts as an intelligent abstraction layer for XMPP 224 communications. Its primary responsibilities are to manage 225 connections from or sessions for other entities (in the form of XML 226 streams to and from authorized clients, servers, and other entities) 227 and to route appropriately-addressed XML data "stanzas" among such 228 entities over XML streams. Most XMPP-compliant servers also assume 229 responsibility for the storage of data that is used by clients (e.g., 230 contact lists for users of XMPP-based IM applications); in this case, 231 the XML data is processed directly by the server itself on behalf of 232 the client and is not routed to another entity. Compliant server 233 implementations MUST ensure in-order processing of XML stanzas 234 between any two entities. 236 2.3 Client 237 Most clients connect directly to a server over a TCP socket and use 238 XMPP to take full advantage of the functionality provided by a server 239 and any associated services, although it must be noted that there is 240 no necessary coupling of an XML stream to a TCP socket (e.g., a 241 client COULD connect via HTTP polling or some other mechanism). 242 Multiple resources (e.g., devices or locations) MAY connect 243 simultaneously to a server on behalf of each authorized client, with 244 each resource connecting over a discrete TCP socket and 245 differentiated by the resource identifier of a JID (Section 3) (e.g., 246 user@domain/home vs. user@domain/work). The port registered with the 247 IANA [6] for connections between a Jabber client and a Jabber server 248 is 5222. For further details about client-to-server communications 249 expressly for the purpose of instant messaging and presence, refer to 250 XMPP IM [2]. 252 2.4 Gateway 254 A gateway is a special-purpose server-side service whose primary 255 function is to translate XMPP into the protocol(s) of another 256 messaging system, as well as to translate the return data back into 257 XMPP. Examples are gateways to SIMPLE, Internet Relay Chat (IRC), 258 Short Message Service (SMS), SMTP, and foreign instant messaging 259 networks such as Yahoo!, MSN, ICQ, and AIM. Communications between 260 gateways and servers, and between gateways and the foreign messaging 261 system, are not defined in this document. 263 2.5 Network 265 Because each server is identified by a network address (typically a 266 DNS hostname) and because server-to-server communications are a 267 straightforward extension of the client-to-server protocol, in 268 practice the system consists of a network of servers that 269 inter-communicate. Thus user-a@domain1 is able to exchange messages, 270 presence, and other information with user-b@domain2. This pattern is 271 familiar from messaging protocols (such as SMTP) that make use of 272 network addressing standards. Upon opening a TCP socket on the 273 IANA-registered port 5269, there are two methods for negotiating a 274 connection between any two servers: server dialback (Section 6.2) and 275 SASL authentication (Section 6.1). 277 3. Addressing Scheme 279 3.1 Overview 281 An entity is anything that can be considered a network endpoint 282 (i.e., an ID on the network) and that can communicate using XMPP. All 283 such entities are uniquely addressable in a form that is consistent 284 with RFC 2396 [7]. In particular, a valid Jabber Identifier (JID) 285 contains a set of ordered elements formed of a domain identifier, 286 node identifier, and resource identifier in the following format: 287 [node@]domain[/resource]. 289 All JIDs are based on the foregoing structure. The most common use of 290 this structure is to identify an IM user, the server to which the 291 user connects, and the user's active session or connection (e.g., a 292 specific client) in the form of user@domain/resource. However, node 293 types other than clients are possible; for example, a specific chat 294 room offered by a multi-user chat service could be addressed as 295 (where "room" is the name of the chat room and 296 "service" is the hostname of the multi-user chat service) and a 297 specific occupant of such a room could be addressed as (where "nick" is the occupant's room nickname). Many other JID 299 types are possible (e.g., could be a server-side 300 script or service). 302 3.2 Domain Identifier 304 The domain identifier is the primary identifier and is the only 305 REQUIRED element of a JID (a mere domain identifier is a valid JID). 306 It usually represents the network gateway or "primary" server to 307 which other entities connect for XML routing and data management 308 capabilities. However, the entity referenced by a domain identifier 309 is not always a server, and may be a service that is addressed as a 310 subdomain of a server and that provides functionality above and 311 beyond the capabilities of a server (a multi-user chat service, a 312 user directory, a gateway to a foreign messaging system, etc.). 314 The domain identifier for every server or service that will 315 communicate over a network SHOULD resolve to a Fully Qualified Domain 316 Name. A domain identifier MUST conform to RFC 952 [8] and RFC 1123 317 [9]. A domain identifier MUST be no more than 1023 bytes in length 318 and MUST conform to the nameprep [10] profile of stringprep [11]. 320 3.3 Node Identifier 322 The node identifier is an optional secondary identifier. It usually 323 represents the entity requesting and using network access provided by 324 the server or gateway (i.e., a client), although it can also 325 represent other kinds of entities (e.g., a multi-user chat room 326 associated with a multi-user chat service). The entity represented by 327 a node identifier is addressed within the context of a specific 328 domain; within IM applications of XMPP this address is called a "bare 329 JID" and is of the form . 331 A node identifier MUST be no more than 1023 bytes in length and MUST 332 conform to the nodeprep [12] profile of stringprep [11]. 334 3.4 Resource Identifier 336 The resource identifer is an optional tertiary identifier. It usually 337 represents a specific session, connection (e.g., a device or 338 location), or object (e.g., a participant in a multi-user chat room) 339 belonging to the entity associated with a node identifier. An entity 340 may maintain multiple resources simultaneously. 342 A resource identifier MUST be no more than 1023 bytes in length and 343 MUST conform to the resourceprep [13] profile of stringprep [11]. 345 4. XML Streams 347 4.1 Overview 349 Two fundamental concepts make possible the rapid, asynchronous 350 exchange of relatively small payloads of structured information 351 between presence-aware entities, XML streams and XML stanzas: 353 Definition of XML stream: An XML stream is a container for the 354 exchange of XML elements between any two entities over a network. 355 An XML stream is negotiated from an initiating entity (usually a 356 client or server) to a receiving entity (usually a server), 357 normally over a TCP socket. An XML stream corresponds to the 358 initiating entity's "session" with the receiving entity. The start 359 of the XML stream is denoted unambiguously by an opening XML 360 tag with appropriate attributes and namespace 361 declarations, and the end of the XML stream is denoted 362 unambiguously be a closing XML tag. An XML stream is 363 unidirectional; in order to enable bidirectional information 364 exchange, one stream must be negotiated from initiating entity to 365 receiving entity and another stream must be negotiated from 366 receiving entity to initiating entity. 368 Definition of XML stanza: An XML stanza is a discrete semantic unit 369 of structured information that is sent from one entity to another 370 over an XML stream. An XML stanza exists at the direct child level 371 of the root element and is said to be well-balanced if 372 it matches production [43] content of the XML specification [1]). 373 The start of any XML stanza is denoted unambiguously by the 374 element start tag at depth=1 (e.g., ), and the end of 375 any XML stanza is denoted unambiguously by the corresponding close 376 tag at depth=1 (e.g., ). An XML stanza MAY contain 377 child elements (with accompanying attributes, elements, and CDATA) 378 as necessary in order to convey the desired information. 380 Consider the example of a client's session with a server. In order to 381 connect to a server, a client must initiate an XML stream by sending 382 an opening tag to the server, optionally preceded by a text 383 declaration specifying the XML version supported and the character 384 encoding. The server SHOULD then reply with a second XML stream back 385 to the client, again optionally preceded by a text declaration. Once 386 the client has authenticated with the server (see Section 6), the 387 client MAY send an unlimited number of XML stanzas over the stream to 388 any recipient on the network. When the client desired to close the 389 stream, it simply sends a closing tag to the server 390 (alternatively, the session may be closed by the server). 392 Thus a client's session with a server can be seen as two open-ended 393 XML documents that are built up through the accumulation of the XML 394 stanzas sent over the two XML streams (i.e., one from the client to 395 the server and one from the server to the client), and the root 396 element can be considered the document entity for each 397 document. In essence, then, an XML stream acts as an envelope for all 398 the XML stanzas sent during a session. We can represent this 399 graphically as follows: 401 |-------------------| 402 | | 403 |-------------------| 404 | | 405 | | 406 | | 407 |-------------------| 408 | | 409 | | 410 | | 411 |-------------------| 412 | | 413 | | 414 | | 415 |-------------------| 416 | ... | 417 |-------------------| 418 | | 419 |-------------------| 421 4.2 Stream Attributes 423 The attributes of the stream element are as follows: 425 o to -- The 'to' attribute SHOULD be used only in the XML stream 426 from the initiating entity to the receiving entity, and MUST be 427 set to the XMPP address of the receiving entity. There SHOULD be 428 no 'to' attribute set in the XML stream by which the receiving 429 entity replies to the initiating entity; however, if a 'to' 430 attribute is included, it SHOULD be ignored by the initiating 431 entity. 433 o from -- The 'from' attribute SHOULD be used only in the XML stream 434 from the receiving entity to the initiating entity, and MUST be 435 set to the XMPP address of the receiving entity granting access to 436 the initiating entity. There SHOULD be no 'from' attribute on the 437 XML stream sent from the initiating entity to the receiving 438 entity; however, if a 'from' attribute is included, it SHOULD be 439 ignored by the receiving entity. 441 o id -- The 'id' attribute SHOULD be used only in the XML stream 442 from the receiving entity to the initiating entity. This attribute 443 is a unique identifier created by the receiving entity to function 444 as a session key for the initiating entity's session with the 445 receiving entity. There SHOULD be no 'id' attribute on the XML 446 stream sent from the initiating entity to the receiving entity; 447 however, if an 'id' attribute is included, it SHOULD be ignored by 448 the receiving entity. 450 o version -- The 'version' attribute MAY be used in the XML stream 451 from the initiating entity to the receiving entity in order signal 452 compliance with the protocol defined herein; this is done by 453 setting the value of the attribute to "1.0". If the initiating 454 entity includes the version attribute and the receiving entity 455 supports XMPP 1.0, the receiving entity MUST reciprocate by 456 including the attribute in its response. 458 We can summarize these values as follows: 460 | initiating to receiving | receiving to initiating 461 ------------------------------------------------------------ 462 to | JID of receiver | ignored 463 from | ignored | JID of receiver 464 id | ignored | session key 465 version | signals XMPP 1.0 support | signals XMPP 1.0 support 467 4.3 Namespace Declarations 469 The stream element MAY contain namespace declarations as defined in 470 the XML namespaces specification [14]. 472 A default namespace declaration ('xmlns') is REQUIRED and is used in 473 both XML streams in order to scope the allowable first-level children 474 of the root stream element for both streams. This namespace 475 declaration MUST be the same for the initiating stream and the 476 responding stream so that both streams are scoped consistently. The 477 default namespace declaration applies to the stream and all stanzas 478 sent within a stream. 480 A stream namespace declaration (e.g., 'xmlns:stream') is REQUIRED in 481 both XML streams. A compliant entity SHOULD accept any namespace 482 prefix on the element; however, for historical reasons some 483 entities MAY accept only a 'stream' prefix, resulting in the use of a 484 element as the stream root. The name of the stream 485 namespace MUST be "http://etherx.jabber.org/streams". 487 Since XML streams function as containers for any XML stanzas sent 488 asynchronously between network endpoints, it should be possible to 489 scope an XML stream with any default namespace declaration (i.e., it 490 should be possible to send any properly-namespaced XML stanza over an 491 XML stream). At a minimum, a compliant implementation MUST support 492 the following two namespaces (for historical reasons, existing 493 implementations MAY support only these two default namespaces): 495 o jabber:client -- this default namespace is declared when the 496 stream is used for communications between a client and a server 498 o jabber:server -- this default namespace is declared when the 499 stream is used for communications between two servers 501 The jabber:client and jabber:server namespaces are nearly identical 502 but are used in different contexts (client-to-server communications 503 for jabber:client and server-to-server communications for 504 jabber:server). The only difference between the two is that the 'to' 505 and 'from' attributes are OPTIONAL on stanzas sent within 506 jabber:client, whereas they are REQUIRED on stanzas sent within 507 jabber:server. If a compliant implementation accepts a stream that is 508 scoped by the 'jabber:client' or 'jabber:server' namespace, it MUST 509 support all three core stanza types (message, presence, and IQ) as 510 described herein and defined in the schema. 512 4.4 Stream Features 514 The root stream element MAY contain a features child element (e.g., 515 if the stream namespace prefix is 'stream'). This 516 is used to communicate generic stream-level capabilities including 517 stream-level features that can be negotiated as the streams are set 518 up. If the initiating entity sends a "version='1.0'" flag in its 519 initiating stream element, the receiving entity MUST send a features 520 child element to the initiating entity if there are any capabilities 521 that need to be advertised or features that can be negotiated for the 522 stream. Currently this is used for SASL and TLS negotiation only, but 523 it could be used for other negotiable features in the future (usage 524 is defined under Stream Encryption (Section 5) and Stream 525 Authentication (Section 6) below). If an entity does not understand 526 or support some features, it SHOULD ignore them. 528 4.5 Stream Errors 530 The root stream element MAY contain an error child element (e.g., 531 if the stream namespace prefix is 'stream'). The 532 error child MUST be sent by a Jabber entity (usually a server rather 533 than a client) if it perceives that a stream-level error has 534 occurred. 536 4.5.1 Rules 538 The following rules apply to stream-level errors: 540 o It is assumed that all stream-level errors are unrecoverable; 541 therefore, if an error occurs at the level of the stream, the 542 entity that detects the error MUST send a stream error to the 543 other entity and then send a closing tag. 545 o If the error occurs while the stream is being set up, the 546 receiving entity MUST still send the opening and closing stream 547 tags and include the error element as a child of the stream 548 element. In this case, if the initiating entity provides an 549 unknown host in the 'to' attribute (or provides no 'to' attribute 550 at all), the server SHOULD provide the server's authoritative 551 hostname in the 'from' attribute of the stream header. 553 4.5.2 Syntax 555 The syntax for stream errors is as follows: 557 558 559 560 561 563 The value of the 'class' attribute must be one of the following: 565 o address -- the condition relates to the JID or domain to which the 566 stream was addressed 568 o format -- the condition relates to XML format or structure 570 o redirect -- the condition relates to a host redirection 572 o server -- the condition relates to the internal state of the 573 server 575 The element MUST contain a child element that 576 specifies a particular stream-level error condition, as defined in 577 the next section. (Note: the XML namespace name 578 'urn:ietf:params:xml:ns:xmpp-streams' that scopes the 579 element adheres to the format defined in The IETF 580 XML Registry [15].) 582 4.5.3 Conditions 584 The following stream-level error conditions are defined: 586 o -- the value of the 'to' attribute provided by the 587 initiating entity in the stream header corresponds to a hostname 588 that is no longer hosted by the server; the associated class is 589 "address". 591 o -- the value of the 'to' attribute provided by the 592 initiating entity in the stream header does not correspond to a 593 hostname that is hosted by the server; the associated class is 594 "address". 596 o -- the server has experienced a 597 misconfiguration or an otherwise-undefined internal server error 598 that prevents it from servicing the stream; the associated class 599 is "server". 601 o -- the stream namespace name is something 602 other than "http://etherx.jabber.org/streams"; the associated 603 class is "format". 605 o -- the server is resource-contrained and is 606 unable to service the stream; the associated class is "server". 608 o -- the server will not provide service to the 609 initiating entity but is redirecting traffic to another host; this 610 element SHOULD contain CDATA specifying the alternate hostname or 611 IP address to which the initiating entity MAY attempt to connect; 612 the associated class is "redirect". 614 o -- the server is being shut down and all active 615 streams are being closed; the associated class is "server". 617 o -- the initiating entity has sent a 618 first-level child of the stream that is not supported by the 619 server; the associated class is "format". 621 o -- the value of the 'version' attribute 622 provided by the initiating entity in the stream header specifies a 623 version of XMPP that is not supported by the server; this element 624 MAY contain CDATA specifying the XMPP version(s) supported by the 625 server; the associated class is "format". 627 o -- the initiating entity has sent XML that 628 is not well-formed as defined by the XML specification [1]; the 629 associated class is "format". 631 4.5.4 Extensibility 633 If desired, an XMPP application MAY provide custom error information; 634 this MUST be contained in a properly-namespaced child of the 635 element (i.e., the namespace name MUST NOT be one 636 of the namespace names defined herein). 638 4.6 Simple Streams Example 640 The following is a stream-based session of a client on a server 641 (where the "C" lines are sent from the client to the server, and the 642 "S" lines are sent from the server to the client): 644 A basic session: 646 C: 647 652 S: 653 659 ... authentication ... 660 C: 661 C: Watson come here, I want you! 662 C: 663 S: 664 S: I'm on my way! 665 S: 666 C: 667 S: 669 These are in actuality a sending stream and a receiving stream, which 670 can be viewed a-chronologically as two XML documents: 672 C: 673 678 C: 679 C: Watson come here, I want you! 680 C: 681 C: 683 S: 684 690 S: 691 S: I'm on my way! 692 S: 693 S: 695 A session gone bad: 697 C: 698 703 S: 704 710 C: Bad XML, no closing body tag! 711 S: 712 713 714 715 716 S: 718 5. Stream Encryption 720 5.1 Overview 722 XMPP includes a method for securing the stream from tampering and 723 eavesdropping. This channel encryption method makes use of the 724 Transport Layer Security (TLS) [16] protocol, along with a "STARTTLS" 725 extension that is modelled on similar extensions for the IMAP [17], 726 POP3 [18], and ACAP [19] protocols as described in RFC 2595 [20]. The 727 namespace identifier for the STARTTLS extension is 'http:// 728 www.ietf.org/rfc/rfc2595.txt'. TLS SHOULD be used between any 729 initiating entity and any receiving entity (e.g., a stream from a 730 client to a server or from one server to another). 732 The following rules MUST be observed: 734 1. If the initiating entity is capable of using the STARTTLS 735 extension, it MUST include the "version='1.0'" flag in the 736 initiating stream header. 738 2. If the receiving entity is capable of using the STARTTLS 739 extension, it MUST send the element in the defined 740 namespace along with the list of features that it sends in 741 response to the opening stream tag received from the initiating 742 entity. 744 3. If the initiating entity chooses to use TLS for stream 745 encryption, TLS negotiation MUST be completed before proceeding 746 to authenticate the stream using SASL. 748 4. The initiating entity MUST validate the certificate presented by 749 the receiving entity: 751 1. If the initiating entity has been configured with a set of 752 trusted roots, either a well-known public set or a manually 753 configured Certificate Authority (e.g., an organization's own 754 Certificate Authority), normal certificate validation 755 processing is appropriate. 757 2. If the initiating entity has been configured with the 758 receiving entity's public key or certificate, a simple 759 comparison is appropriate. 761 If the above methods fail, the certificate MAY be presented to a 762 user for approval; the user SHOULD be given the option to store 763 the certificate and not ask again for at least some reasonable 764 period of time. 766 5. If the TLS negotiation is successful, the receiving entity MUST 767 discard any knowledge obtained from the initiating entity before 768 TLS takes effect. 770 6. If the TLS negotiation is successful, the initiating entity MUST 771 discard any knowledge obtained from the receiving entity before 772 TLS takes effect. 774 7. If the TLS negotiation is successful, the receiving entity MUST 775 NOT offer the STARTTLS extension to the initiating entity along 776 with the other stream features that are offered when the stream 777 is restarted. 779 8. Whether the TLS negotiation results in success or failure, the 780 initiating entity SHOULD continue with SASL negotiation. 782 5.2 Narrative 784 When an initiating entity secures a stream with a receiving entity, 785 the steps involved are as follows: 787 1. Then initiating entity opens a TCP connection and initiates the 788 stream by sending the opening XML stream header to the receiving 789 entity, including the "version='1.0'" flag. 791 2. The receiving entity responds by opening a TCP connection and 792 sending an XML stream header to the initiating entity. 794 3. The receiving entity offers the STARTTLS extension to the 795 initiating entity by sending it along with the list of supported 796 stream features. 798 4. Then initiating entity issues the STARTTLS command to instruct 799 the receiving entity that it wishes to begin a TLS negotiation to 800 secure the stream. 802 5. The receiving entity MUST reply with either an empty 803 element or an empty element, but keep the underlying 804 TCP connection open. 806 6. Then initiating entity begins a TLS negotiation in accordance 807 with RFC 2246 [16]. Upon completion of the negotiation, the 808 initiating entity initiates a new stream by sending a new opening 809 XML stream header to the receiving entity. 811 7. The receiving entity responds by sending an XML stream header to 812 the initiating entity along with the remaining available features 813 (but NOT including the STARTTLS element). 815 5.3 Client-to-Server Example 817 The following example shows the data flow for a client securing a 818 stream using STARTTLS. 820 Step 1: Client initiates stream to server: 822 828 Step 2: Server responds by sending a stream tag to the client: 830 836 Step 3: Server sends the STARTTLS extension to the client along with 837 authentication mechanisms and any other stream features: 839 840 841 842 DIGEST-MD5 843 PLAIN 844 845 847 Step 4: Client sends the STARTTLS command to the server: 849 851 Step 5: Server informs client to proceed: 853 855 Step 5 (alt): Server informs client that TLS negotiation has failed 856 (client SHOULD continue with stream authentication (Section 6)): 858 859 Step 6: Client and server complete TLS negotiation via TCP. 861 Step 7: Client initiates a new stream to the server: 863 869 Step 8: Server responds by sending a stream header to the client 870 along with any remaining negotiatiable stream features: 872 877 878 879 DIGEST-MD5 880 PLAIN 881 EXTERNAL 882 883 885 Step 9: Client SHOULD continue with stream authentication (Section 886 6). 888 5.4 Server-to-Server Example 890 By bilateral agreement, server administrators SHOULD choose to use 891 TLS between two domains for the purpose of securing server-to-server 892 communications. 894 The following example shows the data flow for two servers securing a 895 stream using STARTTLS. 897 Step 1: Server1 initiates stream to Server2: 899 904 Step 2: Server2 responds by sending a stream tag to Server1: 906 912 Step 3: Server2 sends the STARTTLS extension to Server1 along with 913 authentication mechanisms and any other stream features: 915 916 917 918 DIGEST-MD5 919 KERBEROS_V4 920 921 923 Step 4: Server1 sends the STARTTLS command to Server2: 925 927 Step 5: Server2 informs Server1 to proceed: 929 931 Step 5 (alt): Server2 informs Server1 that TLS negotiation has failed 932 (Server1 SHOULD continue with stream authentication (Section 6)): 934 936 Step 6: Server1 and Server2 complete TLS negotiation via TCP. 938 Step 7: Server1 initiates a new stream to Server2: 940 945 Step 8: Server2 responds by sending a stream header to Server1 along 946 with any remaining negotiatiable stream features: 948 953 954 955 DIGEST-MD5 956 KERBEROS_V4 957 EXTERNAL 958 959 961 Step 9: Server1 SHOULD continue with stream authentication (Section 962 6). 964 6. Stream Authentication 966 XMPP includes two methods for enforcing authentication at the level 967 of XML streams. When one entity is already known to another (i.e., 968 there is an existing trust relationship between the entities such as 969 that established when a user registers with a server or an 970 administrator configures a server to trust another server), the 971 preferred method for authenticating streams between the two entities 972 uses an XMPP adaptation of the Simple Authentication and Security 973 Layer (SASL) [21]. When there is no existing trust relationship 974 between two servers, some level of trust MAY be established based on 975 existing trust in DNS; the authentication method used in this case is 976 the server dialback protocol that is native to XMPP (no such ad-hoc 977 method is defined between a client and a server). If SASL is used for 978 server-to-server authentication, the servers MUST NOT use dialback. 979 Both SASL authentication and dialback are described in this section. 981 Stream authentication is REQUIRED for all direct communications 982 between two entities; if an entity sends a stanza to an 983 unauthenticated stream, the receiving entity SHOULD silently drop the 984 stanza and MUST NOT process it. 986 6.1 SASL Authentication 988 6.1.1 Overview 990 The Simple Authentication and Security Layer (SASL) provides a 991 generalized method for adding authentication support to 992 connection-based protocols. XMPP uses a generic XML namespace profile 993 for SASL that conforms to section 4 ("Profiling Requirements") of RFC 994 2222 [21] (the namespace identifier for this protocol is 'http:// 995 www.iana.org/assignments/sasl-mechanisms'). 997 The following rules MUST be observed: 999 1. If TLS is used for stream encryption, SASL MUST NOT be used for 1000 anything but stream authentication (i.e., a security layer MUST 1001 NOT be negotiated using SASL). Conversely, if a security layer is 1002 to be negotiated via SASL, TLS MUST NOT be used. 1004 2. If the initiating entity is capable of authenticating via SASL, 1005 it it MUST include the "version='1.0'" flag in the initiating 1006 stream header. 1008 3. If the receiving entity is capable of accepting authentications 1009 via SASL, it MUST send one or more authentication mechanisms 1010 within a element in response to the opening stream 1011 tag received from the initiating entity. 1013 4. If the SASL negotiation involves negotiation of a security layer, 1014 the receiving entity MUST discard any knowledge obtained from the 1015 initiating entity which was not obtained from the SASL 1016 negotiation itself. 1018 5. If the SASL negotiation involves negotiation of a security layer, 1019 the initiating entity MUST discard any knowledge obtained from 1020 the receiving entity which was not obtained from the SASL 1021 negotiation itself. 1023 6.1.2 Narrative 1025 When an initiating entity authenticates with a receiving entity, the 1026 steps involved are as follows: 1028 1. The initiating entity requests SASL authentication by including a 1029 'version' attribute in the opening XML stream header sent to the 1030 receiving entity, with the value set to "1.0". 1032 2. After sending an XML stream header in response, the receiving 1033 entity sends a list of available SASL authentication mechanisms, 1034 each of which is a element included as a child 1035 within a container element that is sent as a child 1036 of the first-level element. If channel encryption 1037 must be established before a particular authentication mechanism 1038 may be used, the receiving entity MUST NOT provide that mechanism 1039 in the list of available SASL authentication methods. If the 1040 initiating entity presents a valid initiating entity certificate 1041 during TLS negotiation, the receiving entity MAY offer the SASL 1042 EXTERNAL mechanism to the initiating entity during stream 1043 authentication (see RFC 2222 [21]). 1045 3. The initiating entity selects a mechanism by sending an 1046 element to the receiving entity; this element MAY optionally 1047 contain character data (in SASL terminology the "initial 1048 response") if the mechanism supports or requires it. If the 1049 initiating entity selects the EXTERNAL mechanism for 1050 authentication, the authentication credentials shall be taken 1051 from the certificate presented during TLS negotiation. 1053 4. If necessary, the receiving entity challenges the initiating 1054 entity by sending a element to the initiating 1055 entity; this element MAY optionally contain character data. 1057 5. The initiating entity responds to the challenge by sending a 1058 element to the receiving entity; this element MAY 1059 optionally contain character data. 1061 6. If necessary, the receiving entity sends more challenges and the 1062 initiating entity sends more responses. 1064 This series of challenge/response pairs continues until one of three 1065 things happens: 1067 1. The initiating entity aborts the handshake by sending an 1068 element to the receiving entity. 1070 2. The receiving entity reports failure of the handshake by sending 1071 a element to the initiating entity. The particular 1072 cause of failure optionally may be communicated in the 'code' 1073 attribute of the element, and may be 432 (password 1074 transition is needed), 534 (authentication mechanism is too 1075 weak), or 454 (temporary authentication failure). 1077 3. The receiving entity reports success of the handshake by sending 1078 a element to the initiating entity; this element MAY 1079 optionally contain character data (in SASL terminology 1080 "additional data with success"). 1082 Any character data contained within these elements MUST be encoded 1083 using base64. 1085 6.1.3 SASL Definition 1087 Section 4 of the SASL specification [21] requires that the following 1088 information be supplied by a protocol definition: 1090 service name: "xmpp" 1092 initiation sequence: After the initiating entity provides an opening 1093 XML stream header and the receiving entity replies in kind, the 1094 receiving entity provides a list of acceptable authentication 1095 methods. The initiating entity chooses one method from the list 1096 and sends it to the receiving entity as the value of the 1097 'mechanism' attribute possesed by an element, optionally 1098 including an initial response to avoid a round trip. 1100 exchange sequence: Challenges and responses are carried through the 1101 exchange of elements from receiving entity to 1102 initiating entity and elements from initiating entity 1103 to receiving entity. The receiving entity reports failure by 1104 sending a element and success by sending a 1105 element; the initiating entity aborts the exchange by sending an 1106 element. 1108 security layer negotiation: If a security layer is negotiated, both 1109 sides consider the original stream closed and new 1110 headers are sent by both entities. The security layer takes effect 1111 immediately following the ">" character of the empty 1112 element for the client and immediately following the closing ">" 1113 character of the element for the server. 1115 use of the authorization identity: The authorization identity, if 1116 present, is unused by xmpp. 1118 6.1.4 Client-to-Server Example 1120 The following example shows the data flow for a client authenticating 1121 with a server using SASL. 1123 Step 1: Client initiates stream to server: 1125 1131 Step 2: Server responds with a stream tag sent to the client: 1133 1140 Step 3: Server informs client of available authentication mechanisms: 1142 1143 1144 DIGEST-MD5 1145 PLAIN 1146 1147 1148 Step 4: Client selects an authentication mechanism ("initial 1149 response"): 1151 1155 Step 5: Server sends a base64-encoded challenge to the client: 1157 1158 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 1159 xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz 1160 1162 The decoded challenge is: 1164 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ 1165 qop="auth",charset=utf-8,algorithm=md5-sess 1167 Step 6: Client responds to the challenge: 1169 1170 dXNlcm5hbWU9InJvYiIscmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik 1171 9BNk1HOXRFUUdtMmhoIixcIGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5j 1172 PTAwMDAwMDAxLHFvcD1hdXRoLFwgZGlnZXN0LXVyaT0ieG1wcC9jYXRhY2 1173 x5c20uY3giLFwgcmVzcG9uc2U9ZDM4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZ 1174 jIxNDNhZjcsY2hhcnNldD11dGYtOA== 1175 1177 The decoded response is: 1179 username="rob",realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ 1180 cnonce="OA6MHXh6VqTrRk",nc=00000001,qop=auth,\ digest-uri="xmpp/ 1181 cataclysm.cx",\ 1182 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8 1184 Step 7: Server sends another challenge to the client: 1186 1187 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 1188 1190 The decoded challenge is: 1192 rspauth=ea40f60335c427b5527b84dbabcdfffd 1193 Step 8: Client responds to the challenge: 1195 1197 Step 9: Server informs client of successful authentication: 1199 1201 Step 9 (alt): Server informs client of failed authentication: 1203 1205 Step 10: Client initiates a new stream to the server: 1207 1213 Step 11: Server responds by sending a stream header to the client, 1214 with the stream already authenticated (not followed by further stream 1215 features): 1217 1224 6.1.5 Server-to-Server Example 1226 By bilateral agreement, server administrators MAY choose to use SASL 1227 between two domains for the purpose of securing server-to-server 1228 communications. 1230 The following example shows the data flow for a server authenticating 1231 with another server using SASL. 1233 Step 1: Server1 initiates stream to Server2: 1235 1240 Step 2: Server2 responds with a stream tag sent to Server1: 1242 1248 Step 3: Server2 informs Server1 of available authentication 1249 mechanisms: 1251 1252 1253 DIGEST-MD5 1254 KERBEROS_V4 1255 1256 1258 Step 4: Server1 selects an authentication mechanism ("initial 1259 response"): 1261 1265 Step 5: Server2 sends a base64-encoded challenge to Server1: 1267 1268 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 1269 xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz 1270 1272 The decoded challenge is: 1274 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ 1275 qop="auth",charset=utf-8,algorithm=md5-sess 1277 Step 6: Server1 responds to the challenge: 1279 1280 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixjbm9uY2U9Ik9B 1281 Nk1IWGg2VnFUclJrIixuYz0wMDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJ4bXBwL2Nh 1282 dGFjbHlzbS5jeCIscmVzcG9uc2U9ZDM4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcs 1283 Y2hhcnNldD11dGYtOAo= 1284 1286 The decoded response is: 1288 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ 1289 cnonce="OA6MHXh6VqTrRk",nc=00000001,qop=auth,\ digest-uri="xmpp/ 1290 cataclysm.cx",\ 1291 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8 1293 Step 7: Server2 sends another challenge to Server1: 1295 1296 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 1297 1299 The decoded challenge is: 1301 rspauth=ea40f60335c427b5527b84dbabcdfffd 1303 Step 8: Server1 responds to the challenge: 1305 1307 Step 9: Server2 informs Server1 of successful authentication: 1309 1311 Step 9 (alt): Server2 informs Server1 of failed authentication: 1313 1315 Step 10: Server1 initiates a new stream to Server2: 1317 1322 Step 11: Server2 responds by sending a stream header to Server1, with 1323 the stream already authenticated (not followed by further stream 1324 features): 1326 1332 6.2 Dialback Authentication 1334 XMPP includes a protocol-level method for verifying that a connection 1335 between two servers can be trusted (at least as much as the DNS can 1336 be trusted). The method is called dialback and is used only within 1337 XML streams that are declared under the "jabber:server" namespace. 1339 The purpose of the dialback protocol is to make server spoofing more 1340 difficult, and thus to make it more difficult to forge XML stanzas. 1341 Dialback is not intended as a mechanism for securing or encrypting 1342 the streams between servers as is done via SASL and TLS, only for 1343 helping to prevent the spoofing of a server and the sending of false 1344 data from it. Domains requiring more robust security SHOULD use TLS 1345 or SASL as defined above. 1347 Server dialback is made possible by the existence of DNS, since one 1348 server can verify that another server which is connecting to it is 1349 authorized to represent a given server on the Jabber network. All DNS 1350 hostname resolutions MUST first resolve the hostname using an SRV 1351 [23] record of _jabber._tcp.server. If the SRV lookup fails, the 1352 fallback is a normal A lookup to determine the IP address, using the 1353 jabber-server port of 5269 assigned by the Internet Assigned Numbers 1354 Authority [6]. 1356 Note: the method for generating and verifying the keys used in the 1357 dialback protocol MUST take into account the hostnames being used, 1358 along with a secret known only by the receiving server and the random 1359 ID generated for the stream. Generating unique but verifiable keys is 1360 important to prevent common man-in-the-middle attacks and server 1361 spoofing. 1363 In the description that follows we use the following terminology: 1365 o Originating Server -- the server that is attempting to establish a 1366 connection between the two servers 1368 o Receiving Server -- the server that is trying to authenticate that 1369 Originating Server represents the Jabber server which it claims to 1370 be 1372 o Authoritative Server -- the server that is given when a DNS lookup 1373 is performed on the name that Originating Server initially gave; 1374 for basic environments this will be Originating Server, but it 1375 could be a separate machine in Originating Server's network 1377 The following is a brief summary of the order of events in dialback: 1379 1. Originating Server establishes a connection to Receiving Server. 1381 2. Originating Server sends a 'key' value over the connection to 1382 Receiving Server. 1384 3. Receiving Server establishes a connection to Authoritative 1385 Server. 1387 4. Receiving Server sends the same 'key' value to Authoritative 1388 Server. 1390 5. Authoritative Server replies that key is valid or invalid. 1392 6. Receiving Server tells Originating Server whether it is 1393 authenticated or not. 1395 We can represent this flow of events graphically as follows: 1397 Originating Receiving 1398 Server Server 1399 ----------- --------- 1400 | | 1401 | establish connection | 1402 | ----------------------> | 1403 | | 1404 | send stream header | 1405 | ----------------------> | 1406 | | 1407 | establish connection | 1408 | <---------------------- | 1409 | | 1410 | send stream header | 1411 | <---------------------- | 1412 | | Authoritative 1413 | send dialback key | Server 1414 | ----------------------> | ------------- 1415 | | | 1416 | establish connection | 1417 | ----------------------> | 1418 | | 1419 | send stream header | 1420 | ----------------------> | 1421 | | 1422 | establish connection | 1423 | <---------------------- | 1424 | | 1425 | send stream header | 1426 | <---------------------- | 1427 | | 1428 | send dialback key | 1429 | ----------------------> | 1430 | | 1431 | validate dialback key | 1432 | <---------------------- | 1433 | 1434 | report dialback result | 1435 | <---------------------- | 1436 | | 1438 6.2.1 Dialback Protocol 1440 The traffic sent between the servers is as follows: 1442 1. Originating Server establishes TCP connection to Receiving 1443 Server 1445 2. Originating Server sends a stream header to Receiving Server 1446 (the 'to' and 'from' attributes are NOT REQUIRED on the root 1447 stream element): 1449 1454 Note: the value of the xmlns:db namespace declaration indicates 1455 to Receiving Server that Originating Server supports dialback. 1457 3. Receiving Server sends a stream header back to Originating 1458 Server (the 'to' and 'from' attributes are NOT REQUIRED on the 1459 root stream element): 1461 1467 4. Originating Server sends a dialback key to Receiving Server: 1469 1472 98AF014EDC0... 1473 1475 Note: this key is not examined by Receiving Server, since 1476 Receiving Server does not keep information about Originating 1477 Server between sessions. 1479 5. Receiving Server now establishes a connection back to 1480 Originating Server, getting Authoritative Server. 1482 6. Receiving Server sends Authoritative Server a stream header (the 1483 'to' and 'from' attributes are NOT REQUIRED on the root stream 1484 element): 1486 1491 7. Authoritative Server sends Receiving Server a stream header: 1493 1499 8. Receiving Server sends Authoritative Server a stanza indicating 1500 it wants Authoritative Server to verify a key: 1502 1506 98AF014EDC0... 1507 1509 Note: passed here are the hostnames, the original identifier 1510 from Receiving Server's stream header to Originating Server in 1511 step 2, and the key Originating Server gave Receiving Server in 1512 step 3. Based on this information and shared secret information 1513 within the 'Originating Server' network, the key is verified. 1514 Any verifiable method can be used to generate the key. 1516 9. Authoritative Server sends a stanza back to Receiving Server 1517 verifying whether the key was valid or invalid: 1519 1525 or 1527 1533 10. Receiving Server informs Originating Server of the result: 1535 1540 Note: At this point the connection has either been validated via 1541 a type='valid', or reported as invalid. Once the connection is 1542 validated, data can be sent by Originating Server and read by 1543 Receiving Server; before that, all data stanzas sent to 1544 Receiving Server SHOULD be dropped. As a final guard against 1545 domain spoofing, Receiving Server MUST verify that all XML 1546 stanzas received from Originating Server include a 'from' 1547 attribute and that the value of that attribute includes the 1548 validated domain. In addition, all XML stanzas MUST include a 1549 'to' attribute. 1551 7. XML Stanzas 1553 7.1 Overview 1555 Once the XML streams in each direction have been authenticated and 1556 (if desired) encrypted, XML stanzas can be sent over the streams. 1557 Three XML stanza types are defined for the 'jabber:client' and 1558 'jabber:server' namespaces: , , and . 1560 In essence, the stanza type can be seen as a "push" 1561 mechanism whereby one entity pushes information to another entity, 1562 similar to the communications that occur in a system such as email. 1563 The element can be seen as a basic broadcast or 1564 "publish-subscribe" mechanism, whereby multiple entities receive 1565 information (in this case, presence information) about an entity to 1566 which they have subscribed. The element can be seen as a 1567 "request-response" mechanism similar to HTTP, whereby two entities 1568 can engage in a structured conversation using 'get' or 'set' requests 1569 and 'result' or 'error' responses. 1571 The syntax for these stanza types is defined below. 1573 7.2 Common Attributes 1575 Five attributes are common to message, presence, and IQ stanzas. 1576 These are defined below. 1578 7.2.1 to 1580 The 'to' attribute specifies the JID of the intended recipient for 1581 the stanza. In the 'jabber:client' namespace, a stanza SHOULD possess 1582 a 'to' attribute, although a stanza sent from a client to a server 1583 for handling by that server (e.g., presence sent to the server for 1584 broadcasting to other entities) MAY legitimately lack a 'to' 1585 attribute. In the 'jabber:server' namespace, a stanza MUST possess a 1586 'to' attribute. 1588 7.2.2 from 1590 The 'from' attribute specifies the JID of the sender. 1592 In the 'jabber:client' namespace, a client MUST NOT include a 'from' 1593 attribute on the stanzas it sends to a server; if a server receives a 1594 stanza from a client and the stanza possesses a 'from' attribute, it 1595 MUST ignore the value of the 'from' attribute and MAY return an error 1596 to the sender. In addition, a server MUST stamp stanzas received from 1597 a client with the user@domain/resource (full JID) of the connected 1598 resource that generated the stanza. 1600 In the 'jabber:server' namespace, a stanza MUST possess a 'from' 1601 attribute. In particular, a server MUST include a 'from' attribute on 1602 stanzas it routes to other servers. The domain identifier of the JID 1603 contained in the 'from' attribute MUST match the hostname of the 1604 server (or a subdomain thereof) as communicated in the SASL 1605 negotiation or dialback negotiation. 1607 7.2.3 id 1609 The optional 'id' attribute MAY be used to track stanzas sent and 1610 received. The 'id' attribute is generated by the sender. An 'id' 1611 attribute included in an IQ request of type "get" or "set" SHOULD be 1612 returned to the sender in any IQ response of type "result" or "error" 1613 generated by the recipient of the request. A recipient of a message 1614 or presence stanza MAY return that 'id' in any replies, but is NOT 1615 REQUIRED to do so. 1617 The value of the 'id' attribute is not intended to be unique -- 1618 globally, within a domain, or within a stream. It is generated by a 1619 sender only for internal tracking of information within the sending 1620 application. 1622 7.2.4 type 1624 The 'type' attribute specifies detailed information about the purpose 1625 or context of the message, presence, or IQ stanza. The particular 1626 allowable values for the 'type' attribute vary depending on whether 1627 the stanza is a message, presence, or IQ, and thus are specified in 1628 the following sections. 1630 7.2.5 xml:lang 1632 Any message or presence stanza MAY possess an 'xml:lang' attribute 1633 specifying the default language of any CDATA sections of the stanza 1634 or its child elements. An IQ stanza SHOULD NOT possess an 'xml:lang' 1635 attribute, since it is merely a vessel for data in other namespaces 1636 and does not itself contain children that have CDATA. The value of 1637 the 'xml:lang' attribute MUST be an NMTOKEN and MUST conform to the 1638 format defined in RFC 3066 [22]. 1640 7.3 Message Stanzas 1642 Message stanzas in the 'jabber:client' or 'jabber:server' namespace 1643 are used to "push" information to another entity. Common uses in the 1644 context of instant messaging include single messages, messages sent 1645 in the context of a chat conversation, messages sent in the context 1646 of a multi-user chat room, headlines, and errors. These messages 1647 types are identified more fully below. 1649 7.3.1 Types of Message 1651 The 'type' attribute of a message stanza is OPTIONAL; if included, it 1652 specifies the conversational context of the message. The sending of a 1653 message stanza without a 'type' attribute signals that the message 1654 stanza is a single message. However, the 'type' attribute MAY also 1655 have one of the following values: 1657 o chat 1659 o error 1661 o groupchat 1663 o headline 1665 For information about the meaning of these message types, refer to 1666 XMPP IM [2]. 1668 7.3.2 Children 1670 As described under extended namespaces (Section 7.6), a message 1671 stanza MAY contain any properly-namespaced child element as long as 1672 the namespace name is not "jabber:client", "jabber:server", or 1673 "http://etherx.jabber.org/streams", and as long as the element name 1674 does not match that of one of the core data elements, stream 1675 elements, or defined children thereof. 1677 In accordance with the default namespace declaration, by default a 1678 message stanza is in the 'jabber:client' or 'jabber:server' 1679 namespace, which defines certain allowable children of message 1680 stanzas. If the message stanza is of type "error", it MUST include an 1681 child; for details, see Section 7.7. If the message stanza 1682 has no 'type' attribute or has a 'type' attribute with a value of 1683 "chat", "groupchat", or "headline", it MAY contain any of the 1684 following child elements without an explicit namespace declaration: 1686 7.3.2.1 Body 1688 The element contains the textual contents of the message; 1689 normally included but NOT REQUIRED. The element MUST NOT 1690 possess any attributes, with the exception of the 'xml:lang' 1691 attribute. Multiple instances of the element MAY be included 1692 but only if each instance possesses an 'xml:lang' attribute with a 1693 distinct language value. The element MUST NOT contain mixed 1694 content. 1696 7.3.2.2 Subject 1698 The element specifies the topic of the message. The 1699 element MUST NOT possess any attributes, with the 1700 exception of the 'xml:lang' attribute. Multiple instances of the 1701 element MAY be included for the purpose of providing 1702 alternate versions of the same subject, but only if each instance 1703 possesses an 'xml:lang' attribute with a distinct language value. The 1704 element MUST NOT contain mixed content. 1706 7.3.2.3 Thread 1708 The element contains a random string that is generated by 1709 the sender and that SHOULD be copied back in replies; it is used for 1710 tracking a conversation thread (sometimes referred to as an "IM 1711 session") between two entities. If used, it MUST be unique to that 1712 conversation thread within the stream and MUST be consistent 1713 throughout that conversation. The use of the element is 1714 optional and is not used to identify individual messages, only 1715 conversations. Only one element MAY be included in a 1716 message stanza, and it MUST NOT possess any attributes. The 1717 element MUST be treated as an opaque string by entities; no semantic 1718 meaning may be derived from it, and only exact, case-insensitve 1719 comparisons be made against it. The element MUST NOT contain 1720 mixed content. 1722 The method for generating thread IDs SHOULD be as follows: 1724 1. concatenate the sender's full JID (user@host/resource) with the 1725 recipient's full JID 1727 2. concatenate these JID strings with a full ISO-8601 timestamp 1728 including year, month, day, hours, minutes, seconds, and UTC 1729 offset in the following format: yyyy-mm-dd-Thh:mm:ss-hh:mm 1731 3. hash the resulting string according to the SHA1 algorithm 1733 4. convert the hexidecimal SHA1 output to all lowercase 1735 7.4 Presence Stanzas 1737 Presence stanzas are used in the 'jabber:client' or 'jabber:server' 1738 namespace to express an entity's current availability status (offline 1739 or online, along with various sub-states of the latter and optional 1740 user-defined descriptive text) and to communicate that status to 1741 other entities. Presence stanzas are also used to negotiate and 1742 manage subscriptions to the presence of other entities. 1744 7.4.1 Types of Presence 1746 The 'type' attribute of a presence stanza is optional. A presence 1747 stanza that does not possess a 'type' attribute is used to signal to 1748 the server that the sender is online and available for communication. 1749 If included, the 'type' attribute specifies a lack of availability, a 1750 request to manage a subscription to another entity's presence, a 1751 request for another entity's current presence, or an error related to 1752 a previously-sent presence stanza. The 'type' attribute MAY have one 1753 of the following values: 1755 o unavailable -- Signals that the entity is no longer available for 1756 communication. 1758 o subscribe -- The sender wishes to subscribe to the recipient's 1759 presence. 1761 o subscribed -- The sender has allowed the recipient to receive 1762 their presence. 1764 o unsubscribe -- A notification that an entity is unsubscribing from 1765 another entity's presence. 1767 o unsubscribed -- The subscription request has been denied or a 1768 previously-granted subscription has been cancelled. 1770 o probe -- A request for an entity's current presence. In general 1771 SHOULD NOT be sent by a client. 1773 o error -- An error has occurred regarding processing or delivery of 1774 a previously-sent presence stanza. 1776 Information about the subscription model used within XMPP can be 1777 found in XMPP IM [2]. 1779 7.4.2 Children 1781 As described under extended namespaces (Section 7.6), a presence 1782 stanza MAY contain any properly-namespaced child element as long as 1783 the namespace name is not "jabber:client", "jabber:server", or 1784 "http://etherx.jabber.org/streams", and as long as the element name 1785 does not match that of one of the core data elements, stream 1786 elements, or defined children thereof. 1788 In accordance with the default namespace declaration, by default a 1789 presence stanza is in the 'jabber:client' or 'jabber:server' 1790 namespace, which defines certain allowable children of presence 1791 stanzas. If the presence stanza is of type "error", it MUST include 1792 an child; for details, see Section 7.7. If the presence 1793 stanza possesses no 'type' attribute, it MAY contain any of the 1794 following child elements (note that the child MAY be sent 1795 in a presence stanza of type "unavailable" or, for historical 1796 reasons, "subscribe"): 1798 7.4.2.1 Show 1800 The element specifies describes the availability status of an 1801 entity or specific resource. Only one element MAY be included 1802 in a presence stanza, and it MUST NOT possess any attributes. The 1803 value SHOULD be one of the following (values other than these four 1804 MAY be ignored; additional availability types could be defined 1805 through a properly-namespaced child element of the presence stanza): 1807 o away 1809 o chat 1811 o xa 1813 o dnd 1815 For information about the meaning of these values, refer to XMPP IM 1816 [2]. 1818 7.4.2.2 Status 1820 The optional element specifies a natural-language 1821 description of availability status. It is normally used in 1822 conjunction with the show element to provide a detailed description 1823 of an availability state (e.g., "In a meeting"). The 1824 element MUST NOT possess any attributes, with the exception of the 1825 'xml:lang' attribute. Multiple instances of the element MAY 1826 be included but only if each instance possesses an 'xml:lang' 1827 attribute with a distinct language value. 1829 7.4.2.3 Priority 1831 The optional element specifies the priority level of the 1832 connected resource. The value may be any integer between -128 to 127. 1833 Only one element MAY be included in a presence stanza, 1834 and it MUST NOT possess any attributes. For information regarding the 1835 use of priority values in stanza routing within IM applications, see 1836 XMPP IM [2]. 1838 7.5 IQ Stanzas 1839 7.5.1 Overview 1841 Info/Query, or IQ, is a request-response mechanism, similar in some 1842 ways to HTTP [24]. IQ stanzas in the 'jabber:client' or 1843 'jabber:server' namespace enable an entity to make a request of, and 1844 receive a response from, another entity. The data content of the 1845 request and response is defined by the namespace declaration of a 1846 direct child element of the IQ element, and the interaction is 1847 tracked by the requesting entity through use of the 'id' attribute, 1848 which responding entities SHOULD return in any response. 1850 Most IQ interactions follow a common pattern of structured data 1851 exchange such as get/result or set/result (although an error may be 1852 returned in response to a request if appropriate): 1854 Requesting Responding 1855 Entity Entity 1856 ---------- ---------- 1857 | | 1858 | | 1859 | ------------------------> | 1860 | | 1861 | | 1862 | <------------------------ | 1863 | | 1864 | | 1865 | ------------------------> | 1866 | | 1867 | | 1868 | <------------------------ | 1869 | | 1871 An entity that receives an IQ request of type 'get' or 'set' MUST 1872 reply with an IQ response of type 'result' or 'error' (which response 1873 MUST preserve the 'id' attribute of the request). An entity that 1874 receives a stanza of type 'result' or 'error' MUST NOT respond to the 1875 stanza by sending a further IQ response of type 'result' or 'error'; 1876 however, as shown above, the requesting entity MAY send another 1877 request (e.g., an IQ of type 'set' in order to provide required 1878 information discovered through a get/result pair). 1880 7.5.2 Types of IQ 1882 The 'type' attribute of an IQ stanza is REQUIRED. The 'type' 1883 attribute specifies a distinct step within a request-response 1884 interaction. The value SHOULD be one of the following (all other 1885 values MAY be ignored): 1887 o get -- The stanza is a request for information. 1889 o set -- The stanza provides required data, sets new values, or 1890 replaces existing values. 1892 o result -- The stanza is a response to a successful get or set 1893 request. 1895 o error -- An error has occurred regarding processing or delivery of 1896 a previously-sent get or set. 1898 7.5.3 Children 1900 As described under extended namespaces (Section 7.6), an IQ stanza 1901 MAY contain any properly-namespaced child element as long as the 1902 namespace name is not "jabber:client", "jabber"server", or "http:// 1903 etherx.jabber.org/streams", and as long as the element name does not 1904 match that of one of the core data elements, stream elements, or 1905 defined children thereof. However, an IQ stanza contains no children 1906 in the 'jabber:client' or 'jabber:server' namespace since it is a 1907 vessel for XML in another namespace. 1909 If the IQ stanza is of type "error", it MUST include an 1910 child; for details, see Section 7.7. 1912 7.6 Extended Namespaces 1914 While the core data elements in the "jabber:client" or 1915 "jabber:server" namespace (along with their attributes and child 1916 elements) provide a basic level of functionality for messaging and 1917 presence, XMPP uses XML namespaces to extend the core data elements 1918 for the purpose of providing additional functionality. Thus a 1919 message, presence, or IQ stanza MAY house one or more optional child 1920 elements containing content that extends the meaning of the message 1921 (e.g., an encrypted form of the message body). This child element MAY 1922 be any element (other than the core data elements, stream elements, 1923 or defined children thereof). The child element MUST possess an 1924 'xmlns' namespace declaration (other than the stream namespace and 1925 the default namespace) that defines all data contained within the 1926 child element. 1928 Support for any given extended namespace is OPTIONAL on the part of 1929 any implementation. If an entity does not understand such a 1930 namespace, it MUST ignore the associated XML data (if the stanza is 1931 being routed on to another entity, ignore means "pass it on 1932 untouched"). If an entity receives a message or presence stanza that 1933 contains XML data in an extended namespace it does not understand, 1934 the portion of the stanza that is in the unknown namespace SHOULD be 1935 ignored. If an entity receives a message stanza without a 1936 element but containing only a child element bound by a namespace it 1937 does not understand, it MUST ignore the entire stanza. If an entity 1938 receives an IQ stanza in a namespace it does not understand, the 1939 entity SHOULD return an IQ stanza of type "error" with an error 1940 condition of . 1942 7.7 Stanza Errors 1944 As defined below, stanza-related errors are handled in a manner 1945 similar to stream errors (Section 4.5). 1947 7.7.1 Rules 1949 The following rules apply to stanza-related errors: 1951 o A stanza of type "error" MUST contain an child element. 1953 o The receiving or processing entity that returns an error to the 1954 sending entity SHOULD include the original XML sent along with the 1955 element and its children so that the sender can inspect 1956 and if necessary correct the XML before re-sending. 1958 o An entity that receives a message stanza of type 'error' MUST NOT 1959 respond to the stanza by sending a further message stanza of type 1960 'error'; this helps to prevent looping. 1962 o An child MUST NOT be included if the stanza type is 1963 something other than "error". 1965 7.7.2 Syntax 1967 The syntax for stanza-related errors is as follows: 1969 1970 [include sender XML here] 1971 1972 1973 1974 1975 1976 1978 The stanza name is one of message, presence, or iq. 1980 The value of the 'class' attribute must be one of the following: 1982 o access -- the condition relates to access rights, permissions, or 1983 authorization 1985 o address -- the condition relates to the JID or domain to which the 1986 stanza was addressed 1988 o app -- the condition is particular to an application and is 1989 specified in a namespace other than 1990 'urn:ietf:params:xml:ns:xmpp-stanzas' 1992 o format -- the condition relates to XML format or structure 1994 o recipient -- the condition relates to the state or capabilities of 1995 the recipient (which may be the server) 1997 o server -- the condition relates to the internal state of the 1998 server 2000 The element MUST contain a child element that 2001 specifies a particular stanza-related error condition, as defined in 2002 the next section. (Note: the XML namespace name 2003 'urn:ietf:params:xml:ns:xmpp-stanzas' that scopes the 2004 element adheres to the format defined in The IETF 2005 XML Registry [15].) 2007 7.7.3 Conditions 2009 The following stanza-related error conditions are defined: 2011 o -- the sender has sent XML that is malformed or 2012 cannot be processed (e.g., a client-generated stanza includes a 2013 'from' address, or an IQ stanza includes an unrecognized value of 2014 the 'type' attribute); the associated class is "format". 2016 o -- the feature requested is not 2017 implemented by the recipient or server and therefore cannot be 2018 processed; the associated class is "recipient". 2020 o -- the stanza is understood but the action is 2021 forbidden; the associated class is "access". 2023 o -- the server could not process the 2024 stanza because of a misconfiguration or an otherwise-undefined 2025 internal server error; the associated class is "server". 2027 o -- the value of the 'to' attribute in the 2028 sender's stanza does not adhere to the syntax defined in 2029 Addressing (Section 3); the associated class is "address". 2031 o -- the value of the 'to' attribute in the 2032 sender's stanza does not correspond to a Jabber ID on the user's 2033 server or a remote server; the associated class is "address". 2035 o -- the action is not permitted when attempted by 2036 the sender; the associated class is "access". 2038 o -- the specific recipient requested is 2039 currently unavailable; the associated class is "recipient". 2041 o -- the user is not authorized to access 2042 the requested service because registration is required; the 2043 associated class is "access". 2045 o -- a remote server or service specified 2046 as part or all of the JID of the intended recipient does not 2047 exist; the associated class is "address". 2049 o -- a remote server or service specified 2050 as part or all of the JID of the intended recipient could not be 2051 contacted within a reasonable amount of time; the associated class 2052 is "server". 2054 o -- the service requested is currently 2055 unavailable on the server; the associated class is "server". 2057 7.7.4 Extensibility 2059 If desired, an XMPP application MAY provide custom error information; 2060 this MUST be contained in a properly-namespaced child of the 2061 element (i.e., the namespace name MUST NOT be one 2062 of namespace names defined herein). 2064 8. XML Usage within XMPP 2066 8.1 Restrictions 2068 XMPP is a simplified and specialized protocol for streaming XML 2069 elements in order to exchange messages and presence information in 2070 close to real time. Because XMPP does not require the parsing of 2071 arbitrary and complete XML documents, there is no requirement that 2072 XMPP must support the full XML specification [1]. In particular, the 2073 following restrictions apply: 2075 With regard to XML generation, an XMPP implementation MUST NOT inject 2076 into an XML stream any of the following: 2078 o comments (as defined in Section 2.5 of the XML specification [1]) 2080 o processing instructions (Section 2.6) 2082 o internal or external DTD subsets (Section 2.8) 2084 o internal or external entity references (Section 4.2) with the 2085 exception of predefined entities (Section 4.6) 2087 With regard to XML processing, if an XMPP implementation receives 2088 such restricted XML data, it MUST ignore the data. 2090 8.2 Namespaces 2092 XML Namespaces [14] are used within all XMPP-compliant XML to create 2093 strict boundaries of data ownership. The basic function of namespaces 2094 is to separate different vocabularies of XML elements that are 2095 structurally mixed together. Ensuring that XMPP-compliant XML is 2096 namespace-aware enables any XML to be structurally mixed with any 2097 data element within XMPP. 2099 Additionally, XMPP is more strict about namespace prefixes than the 2100 XML namespace specification requires. 2102 8.3 Validation 2104 A server is not responsible for validating the XML elements forwarded 2105 to a client or another server; an implementation MAY choose to 2106 provide only validated data elements but is NOT REQUIRED to do so. 2107 Clients SHOULD NOT rely on the ability to send data which does not 2108 conform to the schemas, and SHOULD ignore any non-conformant elements 2109 or attributes on the incoming XML stream. Validation of XML streams 2110 and stanzas is NOT REQUIRED or recommended, and schemas are included 2111 herein for descriptive purposes only. 2113 8.4 Character Encodings 2115 Software implementing XML streams MUST support the UTF-8 (RFC 2279 2116 [25]) and UTF-16 (RFC 2781 [26]) transformations of Universal 2117 Character Set (ISO/IEC 10646-1 [27]) characters. Software MUST NOT 2118 attempt to use any other encoding for transmitted data. The encodings 2119 of the transmitted and received streams are independent. Software MAY 2120 select either UTF-8 or UTF-16 for the transmitted stream, and SHOULD 2121 deduce the encoding of the received stream as described in the XML 2122 specification [1]. For historical reasons, existing implementations 2123 MAY support UTF-8 only. 2125 8.5 Inclusion of Text Declaration 2127 An application MAY send a text declaration. Applications MUST follow 2128 the rules in the XML specification [1] regarding the circumstances 2129 under which a text declaration is included. 2131 9. IANA Considerations 2133 9.1 XML Namespace Name for Stream Errors 2135 A URN sub-namespace for XMPP stream error tags is defined as follows. 2137 URI: urn:ietf:params:xml:ns:xmpp-streams 2139 Specification: [RFCXXXX] 2141 Description: This is the XML namespace name for XMPP stream errors as 2142 defined by [RFCXXXX]. 2144 Registrant Contact: IETF, XMPP Working Group, 2146 9.2 XML Namespace Name for Stanza Errors 2148 A URN sub-namespace for XMPP stanza error tags is defined as follows. 2150 URI: urn:ietf:params:xml:ns:xmpp-stanzas 2152 Specification: [RFCXXXX] 2154 Description: This is the XML namespace name for XMPP stanza errors as 2155 defined by [RFCXXXX]. 2157 Registrant Contact: IETF, XMPP Working Group, 2159 9.3 Existing Registrations 2161 The IANA registers "xmpp" as a GSSAPI [29] service name, as specified 2162 in Section 6.1.3. 2164 Additionally, the IANA registers "jabber-client" and "jabber-server" 2165 as keywords for TCP ports 5222 and 5269 respectively. 2167 10. Internationalization Considerations 2169 Usage of the 'xml:lang' attribute is described above. If a client 2170 includes an 'xml:lang' attribute in a stanza, a server MUST NOT 2171 modify or delete it. 2173 11. Security Considerations 2175 11.1 High Security 2177 For the purposes of XMPP communications (client-to-server and 2178 server-to-server), the term "high security" refers to the use of 2179 security technologies that provide both mutual authentication and 2180 integrity-checking; in particular, when using certificate-based 2181 authentication to provide high security, a chain-of-trust must be 2182 established out-of-band (i.e., self-signed certificates are not 2183 sufficient). 2185 Implementations MUST support high security. Service provisioning 2186 SHOULD use high security, subject to local security policies. 2188 11.2 Client-to-Server Communications 2190 The TLS protocol for encrypting XML streams (defined under Section 5) 2191 provides a reliable mechanism for helping to ensure the 2192 confidentiality and data integrity of data exchanged between two 2193 entities. 2195 The SASL protocol for authenticating XML streams (defined under 2196 Section 6.1) provides a reliable mechanism for validating that a 2197 client connecting to a server is who it claims to be. 2199 The IP address and method of access of clients MUST NOT be made 2200 available by a server, nor are any connections other than the 2201 original server connection required. This helps protect the client's 2202 server from direct attack or identification by third parties. 2204 End-to-end encryption of message bodies and presence status 2205 information MAY be effected through use of the methods defined in 2206 End-to-End Object Encryption in XMPP [28]. 2208 11.3 Server-to-Server Communications 2210 A compliant implementation MUST support both TLS and SASL for 2211 inter-domain communications. For historical reasons, a compliant 2212 implementation SHOULD also support the lower-security Dialback 2213 Protocol (Section 6.2), which provides a mechanism for helping to 2214 prevent the spoofing of domains. 2216 Because service provisioning is a matter of policy, it is OPTIONAL 2217 for any given domain to communicate with other domains, and 2218 server-to-server communications MAY be disabled by the administrator 2219 of any given deployment. If a particular domain enables inter-domain 2220 communications, it SHOULD enable high security. In the absence of 2221 high security, a domain MAY use server dialback for inter-domain 2222 communications. 2224 11.4 Firewalls 2226 Communications using XMPP normally occur over TCP sockets on port 2227 5222 (client-to-server) or port 5269 (server-to-server), as 2228 registered with the IANA [6]. Use of these well-known ports allows 2229 administrators to easily enable or disable XMPP activity through 2230 existing and commonly-deployed firewalls. 2232 11.5 Mandatory to Implement Technologies 2234 At a minimum, all implementations MUST support the following 2235 mechanisms: 2237 for authentication: the SASL DIGEST-MD5 mechanism 2239 for confidentiality: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA 2240 cipher) 2242 for both: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher 2243 supporting client-side certificates) 2245 References 2247 [1] World Wide Web Consortium, "Extensible Markup Language (XML) 2248 1.0 (Second Edition)", W3C xml, October 2000, . 2251 [2] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging 2252 (draft-ietf-xmpp-im-08, work in progress)", April 2003. 2254 [3] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for 2255 Presence and Instant Messaging", RFC 2779, February 2000, 2256 . 2258 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2259 Levels", BCP 14, RFC 2119, March 1997. 2261 [5] University of Southern California, "Transmission Control 2262 Protocol", RFC 793, September 1981, . 2265 [6] Internet Assigned Numbers Authority, "Internet Assigned Numbers 2266 Authority", January 1998, . 2268 [7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 2269 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 2270 1998, . 2272 [8] Harrenstien, K., Stahl, M. and E. Feinler, "DoD Internet host 2273 table specification", RFC 952, October 1985. 2275 [9] Braden, R., "Requirements for Internet Hosts - Application and 2276 Support", STD 3, RFC 1123, October 1989. 2278 [10] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile 2279 for Internationalized Domain Names (draft-ietf-idn-nameprep-11, 2280 work in progress)", June 2002. 2282 [11] Hoffman, P. and M. Blanchet, "Preparation of Internationalized 2283 Strings ("stringprep")", RFC 3454, December 2002. 2285 [12] Saint-Andre, P. and J. Hildebrand, "Nodeprep: A Stringprep 2286 Profile for Node Identifiers in XMPP 2287 (draft-ietf-xmpp-nodeprep-01, work in progress)", February 2288 2003. 2290 [13] Saint-Andre, P. and J. Hildebrand, "Resourceprep: A Stringprep 2291 Profile for Resource Identifiers in XMPP 2292 (draft-ietf-xmpp-resourceprep-01, work in progress)", February 2293 2003. 2295 [14] World Wide Web Consortium, "Namespaces in XML", W3C xml-names, 2296 January 1999, . 2299 [15] Mealling, M., "The IANA XML Registry", 2300 draft-mealling-iana-xmlns-registry-04 (work in progress), June 2301 2002. 2303 [16] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 2304 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 2305 1999. 2307 [17] Crispin, M., "Internet Message Access Protocol - Version 2308 4rev1", RFC 2060, December 1996. 2310 [18] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 2311 53, RFC 1939, May 1996. 2313 [19] Newman, C. and J. Myers, "ACAP -- Application Configuration 2314 Access Protocol", RFC 2244, November 1997. 2316 [20] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, 2317 June 1999. 2319 [21] Myers, J., "Simple Authentication and Security Layer (SASL)", 2320 RFC 2222, October 1997. 2322 [22] Alvestrand, H., "Tags for the Identification of Languages", BCP 2323 47, RFC 3066, January 2001. 2325 [23] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the 2326 location of services (DNS SRV)", RFC 2052, October 1996. 2328 [24] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 2329 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 2330 HTTP/1.1", RFC 2616, June 1999. 2332 [25] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2333 2279, January 1998. 2335 [26] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", 2336 RFC 2781, February 2000. 2338 [27] International Organization for Standardization, "Information 2339 Technology - Universal Multiple-octet coded Character Set (UCS) 2340 - Amendment 2: UCS Transformation Format 8 (UTF-8)", ISO 2341 Standard 10646-1 Addendum 2, October 1996. 2343 [28] Saint-Andre, P. and J. Hildebrand, "End-to-End Object 2344 Encryption in XMPP (draft-ietf-xmpp-e2e-00, work in progress)", 2345 February 2003. 2347 [29] Linn, J., "Generic Security Service Application Program 2348 Interface, Version 2", RFC 2078, January 1997. 2350 Authors' Addresses 2352 Peter Saint-Andre 2353 Jabber Software Foundation 2355 EMail: stpeter@jabber.org 2356 URI: http://www.jabber.org/people/stpeter.php 2358 Jeremie Miller 2359 Jabber Software Foundation 2361 EMail: jeremie@jabber.org 2362 URI: http://www.jabber.org/people/jer.php 2364 Appendix A. XML Schemas 2366 The following XML schemas are descriptive, not normative. 2368 A.1 Streams namespace 2370 2372 2378 2379 2380 2381 2382 2383 2386 2389 2390 2391 2392 2393 2394 2395 2397 2398 2399 2403 2404 2406 2407 2408 2409 2410 2411 2412 2413 2414 2415 2416 2417 2418 2419 2420 2422 2424 A.2 TLS namespace 2426 2428 2434 2435 2436 2438 2440 A.3 SASL namespace 2441 2443 2449 2450 2451 2452 2453 2455 2457 2458 2459 2460 2461 2463 2464 2465 2466 2467 2468 2469 2470 2471 2473 2475 A.4 Dialback namespace 2477 2479 2485 2486 2487 2488 2489 2490 2491 2492 2493 2494 2495 2496 2497 2498 2499 2500 2501 2502 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2515 2516 2517 2518 2519 2520 2521 2522 2524 2526 A.5 Client namespace 2528 2530 2536 2537 2538 2539 2540 2541 2542 2543 2547 2548 2549 2550 2551 2552 2553 2554 2555 2556 2557 2558 2559 2560 2561 2562 2563 2565 2566 2567 2568 2569 2571 2572 2573 2574 2575 2577 2579 2580 2581 2582 2583 2584 2585 2586 2590 2591 2592 2593 2594 2595 2596 2597 2598 2599 2600 2601 2602 2603 2604 2605 2606 2607 2608 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2621 2622 2623 2624 2625 2627 2629 2630 2631 2632 2633 2637 2638 2639 2640 2641 2642 2643 2644 2645 2646 2647 2648 2649 2650 2651 2652 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2665 2666 2667 2668 2669 2671 2673 A.6 Server namespace 2675 2677 2683 2684 2685 2686 2687 2688 2689 2690 2694 2695 2696 2697 2698 2699 2700 2701 2702 2703 2704 2705 2706 2707 2708 2709 2710 2712 2713 2714 2715 2716 2718 2719 2720 2721 2722 2724 2726 2727 2728 2729 2730 2731 2732 2733 2737 2738 2739 2740 2741 2742 2743 2744 2745 2746 2747 2748 2749 2750 2751 2752 2753 2754 2755 2757 2758 2759 2760 2761 2762 2763 2764 2765 2766 2768 2769 2770 2771 2772 2774 2775 2776 2777 2778 2779 2783 2784 2785 2786 2787 2788 2789 2790 2791 2792 2793 2794 2795 2796 2797 2798 2800 2801 2802 2803 2804 2805 2806 2807 2808 2809 2810 2811 2812 2813 2814 2815 2817 2819 A.7 Stream error namespace 2821 2822 2828 2829 2830 2834 2835 2836 2837 2838 2839 2840 2841 2842 2843 2844 2845 2846 2848 2849 2850 2851 2852 2853 2854 2855 2856 2857 2859 2861 A.8 Stanza error namespace 2863 2865 2871 2872 2873 2877 2878 2879 2880 2881 2882 2883 2884 2885 2886 2887 2888 2889 2890 2891 2893 2894 2895 2896 2897 2898 2899 2900 2901 2902 2903 2904 2906 2908 Appendix B. Revision History 2910 Note to RFC editor: please remove this entire appendix, and the 2911 corresponding entries in the table of contents, prior to publication. 2913 B.1 Changes from draft-ietf-xmpp-core-07 2915 o Made several small editorial changes. 2917 B.2 Changes from draft-ietf-xmpp-core-06 2919 o Added text regarding certificate validation in TLS negotiation per 2920 list discussion. 2922 o Clarified nature of XML restrictions per discussion with W3C, and 2923 moved XML Restrictions subsection under "XML Usage within XMPP". 2925 o Further clarified that XML streams are unidirectional. 2927 o Changed stream error and stanza error namespace names to conform 2928 to the format defined in The IETF XML Registry [15]. 2930 o Removed note to RFC editor regarding provisional namespace names. 2932 B.3 Changes from draft-ietf-xmpp-core-05 2934 o Added as a stream error condition. 2936 o Adjusted security considerations per discussion at IETF 56 and on 2937 list. 2939 B.4 Changes from draft-ietf-xmpp-core-04 2941 o Added server-to-server examples for TLS and SASL. 2943 o Changed error syntax, rules, and examples based on list 2944 discussion. 2946 o Added schemas for the TLS, stream error, and stanza error 2947 namespaces. 2949 o Added note to RFC editor regarding provisional namespace names. 2951 o Made numerous small editorial changes and clarified text 2952 throughout. 2954 B.5 Changes from draft-ietf-xmpp-core-03 2956 o Clarified rules and procedures for TLS and SASL. 2958 o Amplified stream error code syntax per list discussion. 2960 o Made numerous small editorial changes. 2962 B.6 Changes from draft-ietf-xmpp-core-02 2964 o Added dialback schema. 2966 o Removed all DTDs since schemas provide more complete definitions. 2968 o Added stream error codes. 2970 o Clarified error code "philosophy". 2972 B.7 Changes from draft-ietf-xmpp-core-01 2974 o Updated the addressing restrictions per list discussion and added 2975 references to the new nodeprep and resourceprep profiles. 2977 o Corrected error in Stream Authentication regarding "version='1.0'" 2978 flag. 2980 o Made numerous small editorial changes. 2982 B.8 Changes from draft-ietf-xmpp-core-00 2984 o Added information about TLS from list discussion. 2986 o Clarified meaning of "ignore" based on list discussion. 2988 o Clarified information about Universal Character Set data and 2989 character encodings. 2991 o Provided base64-decoded information for examples. 2993 o Fixed several errors in the schemas. 2995 o Made numerous small editorial fixes. 2997 B.9 Changes from draft-miller-xmpp-core-02 2999 o Brought Streams Authentication section into line with discussion 3000 on list and at IETF 55 meeting. 3002 o Added information about the optional 'xml:lang' attribute per 3003 discussion on list and at IETF 55 meeting. 3005 o Specified that validation is neither required nor recommended, and 3006 that the formal definitions (DTDs and schemas) are included for 3007 descriptive purposes only. 3009 o Specified that the response to an IQ stanza of type 'get' or 'set' 3010 must be an IQ stanza of type 'result' or 'error'. 3012 o Specified that compliant server implementations must process 3013 stanzas in order. 3015 o Specified that for historical reasons some server implementations 3016 may accept 'stream:' as the only valid namespace prefix on the 3017 root stream element. 3019 o Clarified the difference between 'jabber:client' and 3020 'jabber:server' namespaces, namely, that 'to' and 'from' 3021 attributes are required on all stanzas in the latter but not the 3022 former. 3024 o Fixed typo in Step 9 of the dialback protocol (changed db:result 3025 to db:verify). 3027 o Removed references to TLS pending list discussion. 3029 o Removed the non-normative appendix on OpenPGP usage pending its 3030 inclusion in a separate I-D. 3032 o Simplified the architecture diagram, removed most references to 3033 services, and removed references to the 'jabber:component:*' 3034 namespaces. 3036 o Noted that XMPP activity respects firewall administration 3037 policies. 3039 o Further specified the scope and uniqueness of the 'id' attribute 3040 in all stanza types and the element in message stanzas. 3042 o Nomenclature changes: (1) from "chunks" to "stanzas"; (2) from 3043 "host" to "server" and from "node" to "client" (except with regard 3044 to definition of the addressing scheme). 3046 Intellectual Property Statement 3048 The IETF takes no position regarding the validity or scope of any 3049 intellectual property or other rights that might be claimed to 3050 pertain to the implementation or use of the technology described in 3051 this document or the extent to which any license under such rights 3052 might or might not be available; neither does it represent that it 3053 has made any effort to identify any such rights. Information on the 3054 IETF's procedures with respect to rights in standards-track and 3055 standards-related documentation can be found in BCP-11. Copies of 3056 claims of rights made available for publication and any assurances of 3057 licenses to be made available, or the result of an attempt made to 3058 obtain a general license or permission for the use of such 3059 proprietary rights by implementors or users of this specification can 3060 be obtained from the IETF Secretariat. 3062 The IETF invites any interested party to bring to its attention any 3063 copyrights, patents or patent applications, or other proprietary 3064 rights which may cover technology that may be required to practice 3065 this standard. Please address the information to the IETF Executive 3066 Director. 3068 Full Copyright Statement 3070 Copyright (C) The Internet Society (2003). All Rights Reserved. 3072 This document and translations of it may be copied and furnished to 3073 others, and derivative works that comment on or otherwise explain it 3074 or assist in its implementation may be prepared, copied, published 3075 and distributed, in whole or in part, without restriction of any 3076 kind, provided that the above copyright notice and this paragraph are 3077 included on all such copies and derivative works. However, this 3078 document itself may not be modified in any way, such as by removing 3079 the copyright notice or references to the Internet Society or other 3080 Internet organizations, except as needed for the purpose of 3081 developing Internet standards in which case the procedures for 3082 copyrights defined in the Internet Standards process must be 3083 followed, or as required to translate it into languages other than 3084 English. 3086 The limited permissions granted above are perpetual and will not be 3087 revoked by the Internet Society or its successors or assignees. 3089 This document and the information contained herein is provided on an 3090 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3091 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3092 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3093 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3094 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3096 Acknowledgement 3098 Funding for the RFC Editor function is currently provided by the 3099 Internet Society.