idnits 2.17.1 draft-ietf-xmpp-core-07.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 1019 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 2, 2003) is 7689 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 373, but not defined -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 2171 -- Possible downref: Non-RFC (?) normative reference: ref. '1' == Outdated reference: A later version (-22) exists of draft-ietf-xmpp-im-07 ** 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 1, 2003 Jabber Software Foundation 5 April 2, 2003 7 XMPP Core 8 draft-ietf-xmpp-core-07 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 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on October 1, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document describes the core features of the Extensible Messaging 40 and Presence Protocol (XMPP), a protocol for streaming XML elements 41 in order to exchange messages and presence information in close to 42 real time. XMPP is used mainly for the purpose of building instant 43 messaging (IM) and presence applications, such as the servers and 44 clients that comprise the Jabber network. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 49 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 50 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 51 1.3 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . 5 52 1.4 Intellectual Property Notice . . . . . . . . . . . . . . . . 5 53 2. Generalized Architecture . . . . . . . . . . . . . . . . . . 6 54 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 2.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 2.3 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 2.4 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 2.5 Network . . . . . . . . . . . . . . . . . . . . . . . . . . 7 59 3. Addressing Scheme . . . . . . . . . . . . . . . . . . . . . 8 60 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.2 Domain Identifier . . . . . . . . . . . . . . . . . . . . . 8 62 3.3 Node Identifier . . . . . . . . . . . . . . . . . . . . . . 8 63 3.4 Resource Identifier . . . . . . . . . . . . . . . . . . . . 9 64 4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 10 66 4.2 Stream Attributes . . . . . . . . . . . . . . . . . . . . . 11 67 4.3 Namespace Declarations . . . . . . . . . . . . . . . . . . . 12 68 4.4 Stream Features . . . . . . . . . . . . . . . . . . . . . . 13 69 4.5 Stream Errors . . . . . . . . . . . . . . . . . . . . . . . 13 70 4.5.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 4.5.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 4.5.3 Conditions . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 4.5.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . . 16 74 4.6 Simple Streams Example . . . . . . . . . . . . . . . . . . . 16 75 5. Stream Encryption . . . . . . . . . . . . . . . . . . . . . 18 76 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 18 77 5.2 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 5.3 Client-to-Server Example . . . . . . . . . . . . . . . . . . 20 79 5.4 Server-to-Server Example . . . . . . . . . . . . . . . . . . 21 80 6. Stream Authentication . . . . . . . . . . . . . . . . . . . 24 81 6.1 SASL Authentication . . . . . . . . . . . . . . . . . . . . 24 82 6.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 24 83 6.1.2 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . 25 84 6.1.3 SASL Definition . . . . . . . . . . . . . . . . . . . . . . 26 85 6.1.4 Client-to-Server Example . . . . . . . . . . . . . . . . . . 27 86 6.1.5 Server-to-Server Example . . . . . . . . . . . . . . . . . . 29 87 6.2 Dialback Authentication . . . . . . . . . . . . . . . . . . 32 88 6.2.1 Dialback Protocol . . . . . . . . . . . . . . . . . . . . . 34 89 7. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . 37 90 7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 37 91 7.2 Common Attributes . . . . . . . . . . . . . . . . . . . . . 37 92 7.2.1 to . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 93 7.2.2 from . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 94 7.2.3 id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 95 7.2.4 type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 96 7.2.5 xml:lang . . . . . . . . . . . . . . . . . . . . . . . . . . 38 97 7.3 Message Stanzas . . . . . . . . . . . . . . . . . . . . . . 38 98 7.3.1 Types of Message . . . . . . . . . . . . . . . . . . . . . . 39 99 7.3.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 39 100 7.4 Presence Stanzas . . . . . . . . . . . . . . . . . . . . . . 40 101 7.4.1 Types of Presence . . . . . . . . . . . . . . . . . . . . . 41 102 7.4.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 41 103 7.5 IQ Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 43 104 7.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 43 105 7.5.2 Types of IQ . . . . . . . . . . . . . . . . . . . . . . . . 43 106 7.5.3 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 44 107 7.6 Extended Namespaces . . . . . . . . . . . . . . . . . . . . 44 108 7.7 Stanza Errors . . . . . . . . . . . . . . . . . . . . . . . 45 109 7.7.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 110 7.7.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 111 7.7.3 Conditions . . . . . . . . . . . . . . . . . . . . . . . . . 46 112 7.7.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . . 47 113 8. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 48 114 8.1 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 48 115 8.2 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . 48 116 8.3 Validation . . . . . . . . . . . . . . . . . . . . . . . . . 48 117 8.4 Character Encodings . . . . . . . . . . . . . . . . . . . . 49 118 8.5 Inclusion of Text Declaration . . . . . . . . . . . . . . . 49 119 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 50 120 9.1 XML Namespace Name for Stream Errors . . . . . . . . . . . . 50 121 9.2 XML Namespace Name for Stanza Errors . . . . . . . . . . . . 50 122 9.3 Existing Registrations . . . . . . . . . . . . . . . . . . . 50 123 10. Internationalization Considerations . . . . . . . . . . . . 51 124 11. Security Considerations . . . . . . . . . . . . . . . . . . 52 125 11.1 High Security . . . . . . . . . . . . . . . . . . . . . . . 52 126 11.2 Client-to-Server Communications . . . . . . . . . . . . . . 52 127 11.3 Server-to-Server Communications . . . . . . . . . . . . . . 52 128 11.4 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . 53 129 11.5 Mandatory to Implement Technologies . . . . . . . . . . . . 53 130 References . . . . . . . . . . . . . . . . . . . . . . . . . 54 131 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 56 132 A. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . 57 133 A.1 Streams namespace . . . . . . . . . . . . . . . . . . . . . 57 134 A.2 TLS namespace . . . . . . . . . . . . . . . . . . . . . . . 58 135 A.3 SASL namespace . . . . . . . . . . . . . . . . . . . . . . . 58 136 A.4 Dialback namespace . . . . . . . . . . . . . . . . . . . . . 59 137 A.5 Client namespace . . . . . . . . . . . . . . . . . . . . . . 60 138 A.6 Server namespace . . . . . . . . . . . . . . . . . . . . . . 63 139 A.7 Stream error namespace . . . . . . . . . . . . . . . . . . . 66 140 A.8 Stanza error namespace . . . . . . . . . . . . . . . . . . . 67 141 B. Revision History . . . . . . . . . . . . . . . . . . . . . . 69 142 B.1 Changes from draft-ietf-xmpp-core-06 . . . . . . . . . . . . 69 143 B.2 Changes from draft-ietf-xmpp-core-05 . . . . . . . . . . . . 69 144 B.3 Changes from draft-ietf-xmpp-core-04 . . . . . . . . . . . . 69 145 B.4 Changes from draft-ietf-xmpp-core-03 . . . . . . . . . . . . 70 146 B.5 Changes from draft-ietf-xmpp-core-02 . . . . . . . . . . . . 70 147 B.6 Changes from draft-ietf-xmpp-core-01 . . . . . . . . . . . . 70 148 B.7 Changes from draft-ietf-xmpp-core-00 . . . . . . . . . . . . 70 149 B.8 Changes from draft-miller-xmpp-core-02 . . . . . . . . . . . 71 150 Full Copyright Statement . . . . . . . . . . . . . . . . . . 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 request- 158 response services. The basic syntax and semantics were developed 159 originally within the Jabber open-source community, mainly in 1999. 160 In 2002, the XMPP WG was chartered with developing an adaptation of 161 the Jabber protocol that would be suitable as an IETF instant 162 messaging and presence technology. As a result of work by the XMPP 163 WG, the current document defines the core features of XMPP; XMPP IM 164 [2] defines the extensions required to provide the instant messaging 165 (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 client- 197 server architecture, wherein a client utilizing XMPP accesses a 198 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 received from connected clients, servers, and services. 236 2.3 Client 238 Most clients connect directly to a server over a TCP socket and use 239 XMPP to take full advantage of the functionality provided by a server 240 and any associated services, although it must be noted that there is 241 no necessary coupling of an XML stream to a TCP socket (e.g., a 242 client COULD connect via HTTP polling or some other mechanism). 243 Multiple resources (e.g., devices or locations) MAY connect 244 simultaneously to a server on behalf of each authorized client, with 245 each resource connecting over a discrete TCP socket and 246 differentiated by the resource identifier of a JID (Section 3) (e.g., 247 user@domain/home vs. user@domain/work). The port registered with 248 the IANA [6] for connections between a Jabber client and a Jabber 249 server is 5222. For further details about client-to-server 250 communications expressly for the purpose of instant messaging and 251 presence, refer to XMPP IM [2]. 253 2.4 Gateway 255 A gateway is a special-purpose server-side service whose primary 256 function is to translate XMPP into the protocol(s) of another 257 messaging system, as well as to translate the return data back into 258 XMPP. Examples are gateways to SIMPLE, Internet Relay Chat (IRC), 259 Short Message Service (SMS), SMTP, and foreign instant messaging 260 networks such as Yahoo!, MSN, ICQ, and AIM. Communications between 261 gateways and servers, and between gateways and the foreign messaging 262 system, are not defined in this document. 264 2.5 Network 266 Because each server is identified by a network address (typically a 267 DNS hostname) and because server-to-server communications are a 268 straightforward extension of the client-to-server protocol, in 269 practice the system consists of a network of servers that inter- 270 communicate. Thus user-a@domain1 is able to exchange messages, 271 presence, and other information with user-b@domain2. This pattern is 272 familiar from messaging protocols (such as SMTP) that make use of 273 network addressing standards. Upon opening a TCP socket on the IANA- 274 registered port 5269, there are two methods for negotiating a 275 connection between any two servers: server dialback (Section 6.2) and 276 SASL authentication (Section 6.1). 278 3. Addressing Scheme 280 3.1 Overview 282 An entity is anything that can be considered a network endpoint 283 (i.e., an ID on the network) and that can communicate using XMPP. 284 All such entities are uniquely addressable in a form that is 285 consistent with RFC 2396 [7]. In particular, a valid Jabber 286 Identifier (JID) contains a set of ordered elements formed of a 287 domain identifier, node identifier, and resource identifier in the 288 following format: [node@]domain[/resource]. 290 All JIDs are based on the foregoing structure. The most common use 291 of this structure is to identify an IM user, the server to which the 292 user connects, and the user's active session or connection (e.g., a 293 specific client) in the form of user@domain/resource. However, node 294 types other than clients are possible; for example, a specific chat 295 room offered by a multi-user chat service could be addressed as 296 (where "room" is the name of the chat room and 297 "service" is the hostname of the multi-user chat service) and a 298 specific occupant of such a room could be addressed as (where "nick" is the occupant's room nickname). Many other JID 300 types are possible (e.g., could be a server-side 301 script or service). 303 3.2 Domain Identifier 305 The domain identifier is the primary identifier and is the only 306 REQUIRED element of a JID (a mere domain identifier is a valid JID). 307 It usually represents the network gateway or "primary" server to 308 which other entities connect for XML routing and data management 309 capabilities. However, the entity referenced by a domain identifier 310 is not always a server, and may be a service that is addressed as a 311 subdomain of a server and that provides functionality above and 312 beyond the capabilities of a server (a multi-user chat service, a 313 user directory, a gateway to a foreign messaging system, etc.). 315 The domain identifier for every server or service that will 316 communicate over a network SHOULD resolve to a Fully Qualified Domain 317 Name. A domain identifier MUST conform to RFC 952 [8] and RFC 1123 318 [9]. A domain identifier MUST be no more than 1023 bytes in length 319 and MUST conform to the nameprep [10] profile of stringprep [11]. 321 3.3 Node Identifier 323 The node identifier is an optional secondary identifier. It usually 324 represents the entity requesting and using network access provided by 325 the server or gateway (i.e., a client), although it can also 326 represent other kinds of entities (e.g., a multi-user chat room 327 associated with a multi-user chat service). The entity represented 328 by a node identifier is addressed within the context of a specific 329 domain; within IM applications of XMPP this address is called a "bare 330 JID" and is of the form . 332 A node identifier MUST be no more than 1023 bytes in length and MUST 333 conform to the nodeprep [12] profile of stringprep [11]. 335 3.4 Resource Identifier 337 The resource identifer is an optional tertiary identifier. It 338 usually represents a specific session, connection (e.g., a device or 339 location), or object (e.g., a participant in a multi-user chat room) 340 belonging to the entity associated with a node identifier. An entity 341 may maintain multiple resources simultaneously. 343 A resource identifier MUST be no more than 1023 bytes in length and 344 MUST conform to the resourceprep [13] profile of stringprep [11]. 346 4. XML Streams 348 4.1 Overview 350 Two fundamental concepts make possible the rapid, asynchronous 351 exchange of relatively small payloads of structured information 352 between presence-aware entities: XML streams and XML stanzas: 354 Definition of XML stream: An XML stream is a container for the 355 exchange of XML elements between any two entities over a network. 356 An XML stream is negotiated from an initiating entity (usually a 357 client or server) to a receiving entity (usually a server), 358 normally over a TCP socket. An XML stream corresponds to the 359 initiating entity's "session" with the receiving entity. The 360 start of the XML stream is denoted unambiguously by an opening XML 361 tag with appropriate attributes and namespace 362 declarations, and the end of the XML stream is denoted 363 unambiguously be a closing XML tag. An XML stream is 364 unidirectional; in order to enable bidirectional information 365 exchange, one stream must be negotiated from initiating entity to 366 receiving entity and another stream must be negotiated from 367 receiving entity to initiating entity. 369 Definition of XML stanza: An XML stanza is a discrete semantic unit 370 of structured information that is sent from one entity to another 371 over an XML stream. An XML stanza exists at the direct child 372 level of the root element and is said to be well- 373 balanced if it matches production [43] content of the XML 374 specification [1]). The start of any XML stanza is denoted 375 unambiguously by the element start tag at depth=1 (e.g., 376 ), and the end of any XML stanza is denoted 377 unambiguously by the corresponding close tag at depth=1 (e.g., ). An XML stanza MAY contain child elements or CDATA 379 sections as necessary in order to convey the desired information. 381 Consider the example of a client's session with a server. In order 382 to connect to a server, a client must initiate an XML stream by 383 sending an opening tag to the server, optionally preceded by 384 a text declaration specifying the XML version supported and the 385 character encoding. The server SHOULD then reply with a second XML 386 stream back to the client, again optionally preceded by a text 387 declaration. Once the client has authenticated with the server (see 388 Section 6), the client MAY send an unlimited number of XML stanzas 389 over the stream to any recipient on the network. When the client 390 desired to close the stream, it simply sends a closing tag 391 to the server (alternatively, the session may be closed by the 392 server). 394 Thus a client's session with a server can be seen as two open-ended 395 XML documents that are built up through the accumulation of the XML 396 stanzas sent over the two XML streams (i.e., one from the client to 397 the server and one from the server to the client), and the root 398 element can be considered the document entity for each 399 document. In essence, then, an XML stream acts as an envelope for 400 all the XML stanzas sent during a session. We can represent this 401 graphically as follows: 403 |-------------------| 404 | | 405 |-------------------| 406 | | 407 | | 408 | | 409 |-------------------| 410 | | 411 | | 412 | | 413 |-------------------| 414 | | 415 | | 416 | | 417 |-------------------| 418 | ... | 419 |-------------------| 420 | | 421 |-------------------| 423 4.2 Stream Attributes 425 The attributes of the stream element are as follows: 427 o to -- The 'to' attribute SHOULD be used only in the XML stream 428 from the initiating entity to the receiving entity, and MUST be 429 set to the XMPP address of the receiving entity. There SHOULD be 430 no 'to' attribute set in the XML stream by which the receiving 431 entity replies to the initiating entity; however, if a 'to' 432 attribute is included, it SHOULD be ignored by the initiating 433 entity. 435 o from -- The 'from' attribute SHOULD be used only in the XML stream 436 from the receiving entity to the initiating entity, and MUST be 437 set to the XMPP address of the receiving entity granting access to 438 the initiating entity. There SHOULD be no 'from' attribute on the 439 XML stream sent from the initiating entity to the receiving 440 entity; however, if a 'from' attribute is included, it SHOULD be 441 ignored by the receiving entity. 443 o id -- The 'id' attribute SHOULD be used only in the XML stream 444 from the receiving entity to the initiating entity. This 445 attribute is a unique identifier created by the receiving entity 446 to function as a session key for the initiating entity's session 447 with the receiving entity. There SHOULD be no 'id' attribute on 448 the XML stream sent from the initiating entity to the receiving 449 entity; however, if an 'id' attribute is included, it SHOULD be 450 ignored by the receiving entity. 452 o version -- The 'version' attribute MAY be used in the XML stream 453 from the initiating entity to the receiving entity in order signal 454 compliance with the protocol defined herein; this is done by 455 setting the value of the attribute to "1.0". If the initiating 456 entity includes the version attribute and the receiving entity 457 supports XMPP 1.0, the receiving entity MUST reciprocate by 458 including the attribute in its response. 460 We can summarize these values as follows: 462 | initiating to receiving | receiving to initiating 463 ------------------------------------------------------------ 464 to | JID of receiver | ignored 465 from | ignored | JID of receiver 466 id | ignored | session key 467 version | signals XMPP 1.0 support | signals XMPP 1.0 support 469 4.3 Namespace Declarations 471 The stream element MAY contain namespace declarations as defined in 472 the XML namespaces specification [14]. 474 A default namespace declaration ('xmlns') is REQUIRED and is used in 475 both XML streams in order to scope the allowable first-level children 476 of the root stream element for both streams. This namespace 477 declaration MUST be the same for the initiating stream and the 478 responding stream so that both streams are scoped consistently. The 479 default namespace declaration applies to the stream and all stanzas 480 sent within a stream. 482 A stream namespace declaration (e.g., 'xmlns:stream') is REQUIRED in 483 both XML streams. A compliant entity SHOULD accept any namespace 484 prefix on the element; however, for historical reasons some 485 entities MAY accept only a 'stream' prefix, resulting in the use of a 486 element as the stream root. The name of the stream 487 namespace MUST be "http://etherx.jabber.org/streams". 489 Since XML streams function as containers for any XML stanzas sent 490 asynchronously between network endpoints, it should be possible to 491 scope an XML stream with any default namespace declaration (i.e., it 492 should be possible to send any properly-namespaced XML stanza over an 493 XML stream). At a minimum, a compliant implementation MUST support 494 the following two namespaces (for historical reasons, existing 495 implementations MAY support only these two default namespaces): 497 o jabber:client -- this default namespace is declared when the 498 stream is used for communications between a client and a server 500 o jabber:server -- this default namespace is declared when the 501 stream is used for communications between two servers 503 The jabber:client and jabber:server namespaces are nearly identical 504 but are used in different contexts (client-to-server communications 505 for jabber:client and server-to-server communications for 506 jabber:server). The only difference between the two is that the 'to' 507 and 'from' attributes are OPTIONAL on stanzas sent within 508 jabber:client, whereas they are REQUIRED on stanzas sent within 509 jabber:server. If a compliant implementation accepts a stream that 510 is scoped by the 'jabber:client' or 'jabber:server' namespace, it 511 MUST support all three core stanza types (message, presence, and IQ) 512 as described herein and defined in the schema. 514 4.4 Stream Features 516 The root stream element MAY contain a features child element (e.g., 517 if the stream namespace prefix is 'stream'). This 518 is used to communicate generic stream-level capabilities including 519 stream-level features that can be negotiated as the streams are set 520 up. If the initiating entity sends a "version='1.0'" flag in its 521 initiating stream element, the receiving entity MUST send a features 522 child element to the initiating entity if there are any capabilities 523 that need to be advertised or features that can be negotiated for the 524 stream. Currently this is used for SASL and TLS negotiation only, 525 but it could be used for other negotiable features in the future 526 (usage is defined under Stream Encryption (Section 5) and Stream 527 Authentication (Section 6) below). If an entity does not understand 528 or support some features, it SHOULD ignore them. 530 4.5 Stream Errors 532 The root stream element MAY contain an error child element (e.g., 533 if the stream namespace prefix is 'stream'). The 534 error child MUST be sent by a Jabber entity (usually a server rather 535 than a client) if it perceives that a stream-level error has 536 occurred. 538 4.5.1 Rules 540 The following rules apply to stream-level errors: 542 o It is assumed that all stream-level errors are unrecoverable; 543 therefore, if an error occurs at the level of the stream, the 544 entity that detects the error MUST send a stream error to the 545 other entity and then send a closing tag. 547 o If the error occurs while the stream is being set up, the 548 receiving entity MUST still send the opening and closing stream 549 tags and include the error element as a child of the stream 550 element. In this case, if the initiating entity provides an 551 unknown host in the 'to' attribute (or provides no 'to' attribute 552 at all), the server SHOULD provide the server's authoritative 553 hostname in the 'from' attribute of the stream header. 555 4.5.2 Syntax 557 The syntax for stream errors is as follows: 559 560 561 562 563 565 The value of the 'class' attribute must be one of the following: 567 o address -- the condition relates to the JID or domain to which the 568 stream was addressed 570 o format -- the condition relates to XML format or structure 572 o redirect -- the condition relates to a host redirection 574 o server -- the condition relates to the internal state of the 575 server 577 The element MUST contain a child element that 578 specifies a particular stream-level error condition, as defined in 579 the next section. (Note: the XML namespace name 580 'urn:ietf:params:xml:ns:xmpp-streams' that scopes the element adheres to the format defined in The IETF XML 582 Registry [15].) 584 4.5.3 Conditions 586 The following stream-level error conditions are defined: 588 o -- the value of the 'to' attribute provided by the 589 initiating entity in the stream header corresponds to a hostname 590 that is no longer hosted by the server; the associated class is 591 "address". 593 o -- the value of the 'to' attribute provided by the 594 initiating entity in the stream header does not correspond to a 595 hostname that is hosted by the server; the associated class is 596 "address". 598 o -- the server has experienced a 599 misconfiguration or an otherwise-undefined internal server error 600 that prevents it from servicing the stream; the associated class 601 is "server". 603 o -- the stream namespace name is something 604 other than "http://etherx.jabber.org/streams"; the associated 605 class is "format". 607 o -- the server is resource-contrained and is 608 unable to service the stream; the associated class is "server". 610 o -- the server will not provide service to the 611 initiating entity but is redirecting traffic to another host; this 612 element SHOULD contain CDATA specifying the alternate hostname or 613 IP address to which the initiating entity MAY attempt to connect; 614 the associated class is "redirect". 616 o -- the server is being shut down and all active 617 streams are being closed; the associated class is "server". 619 o -- the initiating entity has sent a 620 first-level child of the stream that is not supported by the 621 server; the associated class is "format". 623 o -- the value of the 'version' attribute 624 provided by the initiating entity in the stream header specifies a 625 version of XMPP that is not supported by the server; this element 626 MAY contain CDATA specifying the XMPP version(s) supported by the 627 server; the associated class is "format". 629 o -- the initiating entity has sent XML that 630 is not well-formed as defined by the XML specification [1]; the 631 associated class is "format". 633 4.5.4 Extensibility 635 If desired, an XMPP application MAY provide custom error information; 636 this MUST be contained in a properly-namespaced child of the element (i.e., the namespace name MUST NOT be one of the 638 namespace names defined herein). 640 4.6 Simple Streams Example 642 The following is a stream-based session of a client on a server 643 (where the "C" lines are sent from the client to the server, and the 644 "S" lines are sent from the server to the client): 646 A basic session: 648 C: 649 654 S: 655 661 ... authentication ... 662 C: 663 C: Watson come here, I want you! 664 C: 665 S: 666 S: I'm on my way! 667 S: 668 C: 669 S: 671 These are in actuality a sending stream and a receiving stream, which 672 can be viewed a-chronologically as two XML documents: 674 C: 675 680 C: 681 C: Watson come here, I want you! 682 C: 683 C: 685 S: 686 692 S: 693 S: I'm on my way! 694 S: 695 S: 697 A session gone bad: 699 C: 700 705 S: 706 712 C: Bad XML, no closing body tag! 713 S: 714 715 716 717 718 S: 720 5. Stream Encryption 722 5.1 Overview 724 XMPP includes a method for securing the stream from tampering and 725 eavesdropping. This channel encryption method makes use of the 726 Transport Layer Security (TLS) [16] protocol, along with a "STARTTLS" 727 extension that is modelled on similar extensions for the IMAP [17], 728 POP3 [18], and ACAP [19] protocols as described in RFC 2595 [20]. 729 The namespace identifier for the STARTTLS extension is 'http:// 730 www.ietf.org/rfc/rfc2595.txt'. TLS SHOULD be used between any 731 initiating entity and any receiving entity (e.g., a stream from a 732 client to a server or from one server to another). 734 The following rules MUST be observed: 736 1. If the initiating entity is capable of using the STARTTLS 737 extension, it MUST include the "version='1.0'" flag in the 738 initiating stream header. 740 2. If the receiving entity is capable of using the STARTTLS 741 extension, it MUST send the element in the defined 742 namespace along with the list of features that it sends in 743 response to the opening stream tag received from the initiating 744 entity. 746 3. If the initiating entity chooses to use TLS for stream 747 encryption, TLS negotiation MUST be completed before proceeding 748 to authenticate the stream using SASL. 750 4. The initiating entity MUST validate the certificate presented by 751 the receiving entity: 753 1. If the initiating entity has been configured with a set of 754 trusted roots, either a well-known public set or a manually 755 configured Certificate Authority (e.g., an organization's 756 own Certificate Authority), normal certificate validation 757 processing is appropriate. 759 2. If the initiating entity has been configured with the 760 receiving entity's public key or certificate, a simple 761 comparison is appropriate. 763 If the above methods fail, the certificate MAY be presented to a 764 user for approval; the user SHOULD be given the option to store 765 the certificate and not ask again for at least some reasonable 766 period of time. 768 5. If the TLS negotiation is successful, TLS takes effect 769 immediately following the closing ">" character of the 770 element for the client and immediately following the 771 closing ">" character of the element for the server. 772 A new stream MUST then be initiated by the initiating entity. 774 6. If the TLS negotiation is successful, the receiving entity MUST 775 discard any knowledge obtained from the initiating entity before 776 TLS takes effect. 778 7. If the TLS negotiation is successful, the initiating entity MUST 779 discard any knowledge obtained from the receiving entity before 780 TLS takes effect. 782 8. If the TLS negotiation is successful, the receiving entity MUST 783 NOT offer the STARTTLS extension to the initiating entity along 784 with the other stream features that are offered when the stream 785 is restarted. 787 9. Whether the TLS negotiation results in success or failure, the 788 initiating entity SHOULD continue with SASL negotiation. 790 10. If TLS is used for stream encryption, SASL MUST NOT be used for 791 anything but stream authentication (i.e., a security layer MUST 792 NOT be negotiated using SASL). Conversely, if a security layer 793 is to be negotiated via SASL, TLS MUST NOT be used. 795 5.2 Narrative 797 When an initiating entity secures a stream with a receiving entity, 798 the steps involved are as follows: 800 1. Then initiating entity opens a TCP connection and initiates the 801 stream by sending the opening XML stream header to the receiving 802 entity, including the "version='1.0'" flag. 804 2. The receiving entity responds by opening a TCP connection and 805 sending an XML stream header to then initiating entity. 807 3. The receiving entity offers the STARTTLS extension to then 808 initiating entity by sending it along with the list of supported 809 stream features. 811 4. Then initiating entity issues the STARTTLS command to instruct 812 the receiving entity that it wishes to begin a TLS negotiation to 813 secure the stream. 815 5. The receiving entity MUST reply with either an empty 816 element or an empty element, but keep the underlying 817 TCP connection open. 819 6. Then initiating entity begins a TLS negotiation in accordance 820 with RFC 2246 [16]. Upon completion of the negotiation, then 821 initiating entity initiates a new stream by sending a new opening 822 XML stream header to the receiving entity. 824 7. The receiving entity responds by sending an XML stream header to 825 then initiating entity along with the remaining available 826 features (but NOT including the STARTTLS element). 828 5.3 Client-to-Server Example 830 The following example shows the data flow for a client securing a 831 stream using STARTTLS. 833 Step 1: Client initiates stream to server: 835 841 Step 2: Server responds by sending a stream tag to the client: 843 849 Step 3: Server sends the STARTTLS extension to the client along with 850 authentication mechanisms and any other stream features: 852 853 854 855 DIGEST-MD5 856 PLAIN 857 858 859 Step 4: Client sends the STARTTLS command to the server: 861 863 Step 5: Server informs client to proceed: 865 867 Step 5 (alt): Server informs client that TLS negotiation has failed 868 (client SHOULD continue with stream authentication (Section 6)): 870 872 Step 6: Client and server complete TLS negotiation via TCP. 874 Step 7: Client initiates a new stream to the server: 876 882 Step 8: Server responds by sending a stream header to the client 883 along with any remaining negotiatiable stream features: 885 890 891 892 DIGEST-MD5 893 PLAIN 894 EXTERNAL 895 896 898 Step 9: Client SHOULD continue with stream authentication (Section 899 6). 901 5.4 Server-to-Server Example 903 By bilateral agreement, server administrators SHOULD choose to use 904 TLS between two domains for the purpose of securing server-to-server 905 communications. 907 The following example shows the data flow for two servers securing a 908 stream using STARTTLS. 910 Step 1: Server1 initiates stream to Server2: 912 917 Step 2: Server2 responds by sending a stream tag to Server1: 919 925 Step 3: Server2 sends the STARTTLS extension to Server1 along with 926 authentication mechanisms and any other stream features: 928 929 930 931 DIGEST-MD5 932 KERBEROS_V4 933 934 936 Step 4: Server1 sends the STARTTLS command to Server2: 938 940 Step 5: Server2 informs Server1 to proceed: 942 944 Step 5 (alt): Server2 informs Server1 that TLS negotiation has failed 945 (Server1 SHOULD continue with stream authentication (Section 6)): 947 949 Step 6: Server1 and Server2 complete TLS negotiation via TCP. 951 Step 7: Server1 initiates a new stream to Server2: 953 958 Step 8: Server2 responds by sending a stream header to Server1 along 959 with any remaining negotiatiable stream features: 961 966 967 968 DIGEST-MD5 969 KERBEROS_V4 970 EXTERNAL 971 972 974 Step 9: Server1 SHOULD continue with stream authentication (Section 975 6). 977 6. Stream Authentication 979 XMPP includes two methods for enforcing authentication at the level 980 of XML streams. When one entity is already known to another (i.e., 981 there is an existing trust relationship between the entities such as 982 that established when a user registers with a server or an 983 administrator configures a server to trust another server), the 984 preferred method for authenticating streams between the two entities 985 uses an XMPP adaptation of the Simple Authentication and Security 986 Layer (SASL) [21]. When there is no existing trust relationship 987 between two servers, some level of trust MAY be established based on 988 existing trust in DNS; the authentication method used in this case is 989 the server dialback protocol that is native to XMPP (no such ad-hoc 990 method is defined between a client and a server). If SASL is used 991 for server-to-server authentication, the servers MUST NOT use 992 dialback. Both SASL authentication and dialback are described in 993 this section. 995 Stream authentication is REQUIRED for all direct communications 996 between two entities; if an entity sends a stanza to an 997 unauthenticated stream, the receiving entity SHOULD silently drop the 998 stanza and MUST NOT process it. 1000 6.1 SASL Authentication 1002 6.1.1 Overview 1004 The Simple Authentication and Security Layer (SASL) provides a 1005 generalized method for adding authentication support to connection- 1006 based protocols. XMPP uses a generic XML namespace profile for SASL 1007 that conforms to section 4 ("Profiling Requirements") of RFC 2222 1008 [21] (the namespace identifier for this protocol is 'http:// 1009 www.iana.org/assignments/sasl-mechanisms'). 1011 The following rules MUST be observed: 1013 1. If TLS is used for stream encryption, SASL MUST NOT be used for 1014 anything but stream authentication (i.e., a security layer MUST 1015 NOT be negotiated using SASL). Conversely, if a security layer 1016 is to be negotiated via SASL, TLS MUST NOT be used. 1018 2. If the initiating entity is capable of authenticating via SASL, 1019 it it MUST include the "version='1.0'" flag in the initiating 1020 stream header. 1022 3. If the receiving entity is capable of accepting authentications 1023 via SASL, it MUST send one or more authentication mechanisms 1024 within a element in response to the opening stream 1025 tag received from the initiating entity. 1027 4. If the SASL negotiation involves negotiation of a security layer, 1028 the receiving entity MUST discard any knowledge obtained from the 1029 initiating entity which was not obtained from the SASL 1030 negotiation itself. 1032 5. If the SASL negotiation involves negotiation of a security layer, 1033 the initiating entity MUST discard any knowledge obtained from 1034 the receiving entity which was not obtained from the SASL 1035 negotiation itself. 1037 6.1.2 Narrative 1039 When an initiating entity authenticates with a receiving entity, the 1040 steps involved are as follows: 1042 1. The initiating entity requests SASL authentication by including a 1043 'version' attribute in the opening XML stream header sent to the 1044 receiving entity, with the value set to "1.0". 1046 2. After sending an XML stream header in response, the receiving 1047 entity sends a list of available SASL authentication mechanisms, 1048 each of which is a element included as a child 1049 within a container element that is sent as a child 1050 of the first-level element. If channel encryption 1051 must be established before a particular authentication mechanism 1052 may be used, the receiving entity MUST NOT provide that mechanism 1053 in the list of available SASL authentication methods. If the 1054 initiating entity presents a valid initiating entity certificate 1055 during TLS negotiation, the receiving entity MAY offer the SASL 1056 EXTERNAL mechanism to the initiating entity during stream 1057 authentication (see RFC 2222 [21]). 1059 3. The initiating entity selects a mechanism by sending an 1060 element to the receiving entity; this element MAY optionally 1061 contain character data (in SASL terminology the "initial 1062 response") if the mechanism supports or requires it. If the 1063 initiating entity selects the EXTERNAL mechanism for 1064 authentication, the authentication credentials shall be taken 1065 from the certificate presented during TLS negotiation. 1067 4. If necessary, the receiving entity challenges the initiating 1068 entity by sending a element to the initiating 1069 entity; this element MAY optionally contain character data. 1071 5. The initiating entity responds to the challenge by sending a 1072 element to the receiving entity; this element MAY 1073 optionally contain character data. 1075 6. If necessary, the receiving entity sends more challenges and the 1076 initiating entity sends more responses. 1078 This series of challenge/response pairs continues until one of three 1079 things happens: 1081 1. The initiating entity aborts the handshake by sending an 1082 element to the receiving entity. 1084 2. The receiving entity reports failure of the handshake by sending 1085 a element to the initiating entity. The particular 1086 cause of failure optionally may be communicated in the 'code' 1087 attribute of the element, and may be 432 (password 1088 transition is needed), 534 (authentication mechanism is too 1089 weak), or 454 (temporary authentication failure). 1091 3. The receiving entity reports success of the handshake by sending 1092 a element to the initiating entity; this element MAY 1093 optionally contain character data (in SASL terminology 1094 "additional data with success"). 1096 Any character data contained within these elements MUST be encoded 1097 using base64. 1099 6.1.3 SASL Definition 1101 Section 4 of the SASL specification [21] requires that the following 1102 information be supplied by a protocol definition: 1104 service name: "xmpp" 1106 initiation sequence: After the initiating entity provides an opening 1107 XML stream header and the receiving entity replies in kind, the 1108 receiving entity provides a list of acceptable authentication 1109 methods. The initiating entity chooses one method from the list 1110 and sends it to the receiving entity as the value of the 1111 'mechanism' attribute possesed by an element, optionally 1112 including an initial response to avoid a round trip. 1114 exchange sequence: Challenges and responses are carried through the 1115 exchange of elements from receiving entity to 1116 initiating entity and elements from initiating entity 1117 to receiving entity. The receiving entity reports failure by 1118 sending a element and success by sending a 1119 element; the initiating entity aborts the exchange by sending an 1120 element. 1122 security layer negotiation: If a security layer is negotiated, both 1123 sides consider the original stream closed and new 1124 headers are sent by both entities. The security layer takes 1125 effect immediately following the ">" character of the empty 1126 element for the client and immediately following the 1127 closing ">" character of the element for the server. 1129 use of the authorization identity: The authorization identity, if 1130 present, is unused by xmpp. 1132 6.1.4 Client-to-Server Example 1134 The following example shows the data flow for a client authenticating 1135 with a server using SASL. 1137 Step 1: Client initiates stream to server: 1139 1145 Step 2: Server responds with a stream tag sent to the client: 1147 1154 Step 3: Server informs client of available authentication mechanisms: 1156 1157 1158 DIGEST-MD5 1159 PLAIN 1160 1161 1162 Step 4: Client selects an authentication mechanism ("initial 1163 response"): 1165 1169 Step 5: Server sends a base64-encoded challenge to the client: 1171 1172 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 1173 xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz 1174 1176 The decoded challenge is: 1178 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ qop="auth",charset=utf- 1179 8,algorithm=md5-sess 1181 Step 6: Client responds to the challenge: 1183 1184 dXNlcm5hbWU9InJvYiIscmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik 1185 9BNk1HOXRFUUdtMmhoIixcIGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5j 1186 PTAwMDAwMDAxLHFvcD1hdXRoLFwgZGlnZXN0LXVyaT0ieG1wcC9jYXRhY2 1187 x5c20uY3giLFwgcmVzcG9uc2U9ZDM4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZ 1188 jIxNDNhZjcsY2hhcnNldD11dGYtOA== 1189 1191 The decoded response is: 1193 username="rob",realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ 1194 cnonce="OA6MHXh6VqTrRk",nc=00000001,qop=auth,\ digest-uri="xmpp/ 1195 cataclysm.cx",\ 1196 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8 1198 Step 7: Server sends another challenge to the client: 1200 1201 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 1202 1204 The decoded challenge is: 1206 rspauth=ea40f60335c427b5527b84dbabcdfffd 1207 Step 8: Client responds to the challenge: 1209 1211 Step 9: Server informs client of successful authentication: 1213 1215 Step 9 (alt): Server informs client of failed authentication: 1217 1219 Step 10: Client initiates a new stream to the server: 1221 1227 Step 11: Server responds by sending a stream header to the client, 1228 with the stream already authenticated (not followed by further stream 1229 features): 1231 1238 6.1.5 Server-to-Server Example 1240 By bilateral agreement, server administrators MAY choose to use SASL 1241 between two domains for the purpose of securing server-to-server 1242 communications. 1244 The following example shows the data flow for a server authenticating 1245 with another server using SASL. 1247 Step 1: Server1 initiates stream to Server2: 1249 1254 Step 2: Server2 responds with a stream tag sent to Server1: 1256 1262 Step 3: Server2 informs Server1 of available authentication 1263 mechanisms: 1265 1266 1267 DIGEST-MD5 1268 KERBEROS_V4 1269 1270 1272 Step 4: Server1 selects an authentication mechanism ("initial 1273 response"): 1275 1279 Step 5: Server2 sends a base64-encoded challenge to Server1: 1281 1282 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 1283 xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz 1284 1286 The decoded challenge is: 1288 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ qop="auth",charset=utf- 1289 8,algorithm=md5-sess 1291 Step 6: Server1 responds to the challenge: 1293 1294 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixjbm9uY2U9Ik9B 1295 Nk1IWGg2VnFUclJrIixuYz0wMDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJ4bXBwL2Nh 1296 dGFjbHlzbS5jeCIscmVzcG9uc2U9ZDM4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcs 1297 Y2hhcnNldD11dGYtOAo= 1298 1300 The decoded response is: 1302 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ 1303 cnonce="OA6MHXh6VqTrRk",nc=00000001,qop=auth,\ digest-uri="xmpp/ 1304 cataclysm.cx",\ 1305 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8 1307 Step 7: Server2 sends another challenge to Server1: 1309 1310 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 1311 1313 The decoded challenge is: 1315 rspauth=ea40f60335c427b5527b84dbabcdfffd 1317 Step 8: Server1 responds to the challenge: 1319 1321 Step 9: Server2 informs Server1 of successful authentication: 1323 1325 Step 9 (alt): Server2 informs Server1 of failed authentication: 1327 1329 Step 10: Server1 initiates a new stream to Server2: 1331 1336 Step 11: Server2 responds by sending a stream header to Server1, with 1337 the stream already authenticated (not followed by further stream 1338 features): 1340 1346 6.2 Dialback Authentication 1348 XMPP includes a protocol-level method for verifying that a connection 1349 between two servers can be trusted (at least as much as the DNS can 1350 be trusted). The method is called dialback and is used only within 1351 XML streams that are declared under the "jabber:server" namespace. 1353 The purpose of the dialback protocol is to make server spoofing more 1354 difficult, and thus to make it more difficult to forge XML stanzas. 1355 Dialback is not intended as a mechanism for securing or encrypting 1356 the streams between servers as is done via SASL and TLS, only for 1357 helping to prevent the spoofing of a server and the sending of false 1358 data from it. Domains requiring more robust security SHOULD use TLS 1359 or SASL as defined above. 1361 Server dialback is made possible by the existence of DNS, since one 1362 server can verify that another server which is connecting to it is 1363 authorized to represent a given server on the Jabber network. All 1364 DNS hostname resolutions MUST first resolve the hostname using an SRV 1365 [23] record of _jabber._tcp.server. If the SRV lookup fails, the 1366 fallback is a normal A lookup to determine the IP address, using the 1367 jabber-server port of 5269 assigned by the Internet Assigned Numbers 1368 Authority [6]. 1370 Note: the method for generating and verifying the keys used in the 1371 dialback protocol MUST take into account the hostnames being used, 1372 along with a secret known only by the receiving server and the random 1373 ID generated for the stream. Generating unique but verifiable keys 1374 is important to prevent common man-in-the-middle attacks and server 1375 spoofing. 1377 In the description that follows we use the following terminology: 1379 o Originating Server -- the server that is attempting to establish a 1380 connection between the two servers 1382 o Receiving Server -- the server that is trying to authenticate that 1383 Originating Server represents the Jabber server which it claims to 1384 be 1386 o Authoritative Server -- the server that is given when a DNS lookup 1387 is performed on the name that Originating Server initially gave; 1388 for basic environments this will be Originating Server, but it 1389 could be a separate machine in Originating Server's network 1391 The following is a brief summary of the order of events in dialback: 1393 1. Originating Server establishes a connection to Receiving Server. 1395 2. Originating Server sends a 'key' value over the connection to 1396 Receiving Server. 1398 3. Receiving Server establishes a connection to Authoritative 1399 Server. 1401 4. Receiving Server sends the same 'key' value to Authoritative 1402 Server. 1404 5. Authoritative Server replies that key is valid or invalid. 1406 6. Receiving Server tells Originating Server whether it is 1407 authenticated or not. 1409 We can represent this flow of events graphically as follows: 1411 Originating Receiving 1412 Server Server 1413 ----------- --------- 1414 | | 1415 | establish connection | 1416 | ----------------------> | 1417 | | 1418 | send stream header | 1419 | ----------------------> | 1420 | | 1421 | establish connection | 1422 | <---------------------- | 1423 | | 1424 | send stream header | 1425 | <---------------------- | 1426 | | Authoritative 1427 | send dialback key | Server 1428 | ----------------------> | ------------- 1429 | | | 1430 | establish connection | 1431 | ----------------------> | 1432 | | 1433 | send stream header | 1434 | ----------------------> | 1435 | | 1436 | establish connection | 1437 | <---------------------- | 1438 | | 1439 | send stream header | 1440 | <---------------------- | 1441 | | 1442 | send dialback key | 1443 | ----------------------> | 1444 | | 1445 | validate dialback key | 1446 | <---------------------- | 1447 | 1448 | report dialback result | 1449 | <---------------------- | 1450 | | 1452 6.2.1 Dialback Protocol 1454 The traffic sent between the servers is as follows: 1456 1. Originating Server establishes TCP connection to Receiving 1457 Server 1459 2. Originating Server sends a stream header to Receiving Server 1460 (the 'to' and 'from' attributes are NOT REQUIRED on the root 1461 stream element): 1463 1468 Note: the value of the xmlns:db namespace declaration indicates 1469 to Receiving Server that Originating Server supports dialback. 1471 3. Receiving Server sends a stream header back to Originating 1472 Server (the 'to' and 'from' attributes are NOT REQUIRED on the 1473 root stream element): 1475 1481 4. Originating Server sends a dialback key to Receiving Server: 1483 1486 98AF014EDC0... 1487 1489 Note: this key is not examined by Receiving Server, since 1490 Receiving Server does not keep information about Originating 1491 Server between sessions. 1493 5. Receiving Server now establishes a connection back to 1494 Originating Server, getting Authoritative Server. 1496 6. Receiving Server sends Authoritative Server a stream header (the 1497 'to' and 'from' attributes are NOT REQUIRED on the root stream 1498 element): 1500 1505 7. Authoritative Server sends Receiving Server a stream header: 1507 1513 8. Receiving Server sends Authoritative Server a stanza indicating 1514 it wants Authoritative Server to verify a key: 1516 1520 98AF014EDC0... 1521 1523 Note: passed here are the hostnames, the original identifier 1524 from Receiving Server's stream header to Originating Server in 1525 step 2, and the key Originating Server gave Receiving Server in 1526 step 3. Based on this information and shared secret information 1527 within the 'Originating Server' network, the key is verified. 1528 Any verifiable method can be used to generate the key. 1530 9. Authoritative Server sends a stanza back to Receiving Server 1531 verifying whether the key was valid or invalid: 1533 1539 or 1541 1547 10. Receiving Server informs Originating Server of the result: 1549 1554 Note: At this point the connection has either been validated via 1555 a type='valid', or reported as invalid. Once the connection is 1556 validated, data can be sent by Originating Server and read by 1557 Receiving Server; before that, all data stanzas sent to 1558 Receiving Server SHOULD be dropped. As a final guard against 1559 domain spoofing, Receiving Server MUST verify that all XML 1560 stanzas received from Originating Server include a 'from' 1561 attribute and that the value of that attribute includes the 1562 validated domain. In addition, all XML stanzas MUST include a 1563 'to' attribute. 1565 7. XML Stanzas 1567 7.1 Overview 1569 Once the XML streams in each direction have been authenticated and 1570 (if desired) encrypted, XML stanzas can be sent over the streams. 1571 Three XML stanza types are defined for the 'jabber:client' and 1572 'jabber:server' namespaces: , , and . 1574 In essence, the stanza type can be seen as a "push" 1575 mechanism whereby one entity pushes information to another entity, 1576 similar to the communications that occur in a system such as email. 1577 The element can be seen as a basic broadcast or "publish- 1578 subscribe" mechanism, whereby multiple entities receive information 1579 (in this case, presence information) about an entity to which they 1580 have subscribed. The element can be seen as a "request- 1581 response" mechanism similar to HTTP, whereby two entities can engage 1582 in a structured conversation using 'get' or 'set' requests and 1583 'result' or 'error' responses. 1585 The syntax for these stanza types is defined below. 1587 7.2 Common Attributes 1589 Five attributes are common to message, presence, and IQ stanzas. 1590 These are defined below. 1592 7.2.1 to 1594 The 'to' attribute specifies the JID of the intended recipient for 1595 the stanza. In the 'jabber:client' namespace, a stanza SHOULD 1596 possess a 'to' attribute, although a stanza sent from a client to a 1597 server for handling by that server (e.g., presence sent to the server 1598 for broadcasting to other entities) MAY legitimately lack a 'to' 1599 attribute. In the 'jabber:server' namespace, a stanza MUST possess a 1600 'to' attribute. 1602 7.2.2 from 1604 The 'from' attribute specifies the JID of the sender. 1606 In the 'jabber:client' namespace, a client MUST NOT include a 'from' 1607 attribute on the stanzas it sends to a server; if a server receives a 1608 stanza from a client and the stanza possesses a 'from' attribute, it 1609 MUST ignore the value of the 'from' attribute and MAY return an error 1610 to the sender. In addition, a server MUST stamp stanzas received 1611 from a client with the user@domain/resource (full JID) of the 1612 connected resource that generated the stanza. 1614 In the 'jabber:server' namespace, a stanza MUST possess a 'from' 1615 attribute. In particular, a server MUST include a 'from' attribute 1616 on stanzas it routes to other servers. The domain identifier of the 1617 JID contained in the 'from' attribute MUST match the hostname of the 1618 server (or a subdomain thereof) as communicated in the SASL 1619 negotiation or dialback negotiation. 1621 7.2.3 id 1623 The optional 'id' attribute MAY be used to track stanzas sent and 1624 received. The 'id' attribute is generated by the sender. An 'id' 1625 attribute included in an IQ request of type "get" or "set" SHOULD be 1626 returned to the sender in any IQ response of type "result" or "error" 1627 generated by the recipient of the request. A recipient of a message 1628 or presence stanza MAY return that 'id' in any replies, but is NOT 1629 REQUIRED to do so. 1631 The value of the 'id' attribute is not intended to be unique -- 1632 globally, within a domain, or within a stream. It is generated by a 1633 sender only for internal tracking of information within the sending 1634 application. 1636 7.2.4 type 1638 The 'type' attribute specifies detailed information about the purpose 1639 or context of the message, presence, or IQ stanza. The particular 1640 allowable values for the 'type' attribute vary depending on whether 1641 the stanza is a message, presence, or IQ, and thus are specified in 1642 the following sections. 1644 7.2.5 xml:lang 1646 Any message or presence stanza MAY possess an 'xml:lang' attribute 1647 specifying the default language of any CDATA sections of the stanza 1648 or its child elements. An IQ stanza SHOULD NOT possess an 'xml:lang' 1649 attribute, since it is merely a vessel for data in other namespaces 1650 and does not itself contain children that have CDATA. The value of 1651 the 'xml:lang' attribute MUST be an NMTOKEN and MUST conform to the 1652 format defined in RFC 3066 [22]. 1654 7.3 Message Stanzas 1656 Message stanzas in the 'jabber:client' or 'jabber:server' namespace 1657 are used to "push" information to another entity. Common uses in the 1658 context of instant messaging include single messages, messages sent 1659 in the context of a chat conversation, messages sent in the context 1660 of a multi-user chat room, headlines, and errors. These messages 1661 types are identified more fully below. 1663 7.3.1 Types of Message 1665 The 'type' attribute of a message stanza is OPTIONAL; if included, it 1666 specifies the conversational context of the message. The sending of 1667 a message stanza without a 'type' attribute signals that the message 1668 stanza is a single message. However, the 'type' attribute MAY also 1669 have one of the following values: 1671 o chat 1673 o error 1675 o groupchat 1677 o headline 1679 For information about the meaning of these message types, refer to 1680 XMPP IM [2]. 1682 7.3.2 Children 1684 As described under extended namespaces (Section 7.6), a message 1685 stanza MAY contain any properly-namespaced child element as long as 1686 the namespace name is not "jabber:client", "jabber:server", or 1687 "http://etherx.jabber.org/streams", and as long as the element name 1688 does not match that of one of the core data elements, stream 1689 elements, or defined children thereof. 1691 In accordance with the default namespace declaration, by default a 1692 message stanza is in the 'jabber:client' or 'jabber:server' 1693 namespace, which defines certain allowable children of message 1694 stanzas. If the message stanza is of type "error", it MUST include 1695 an child; for details, see Section 7.7. If the message 1696 stanza has no 'type' attribute or has a 'type' attribute with a value 1697 of "chat", "groupchat", or "headline", it MAY contain any of the 1698 following child elements without an explicit namespace declaration: 1700 7.3.2.1 Body 1702 The element contains the textual contents of the message; 1703 normally included but NOT REQUIRED. The element MUST NOT 1704 possess any attributes, with the exception of the 'xml:lang' 1705 attribute. Multiple instances of the element MAY be included 1706 but only if each instance possesses an 'xml:lang' attribute with a 1707 distinct language value. The element MUST NOT contain mixed 1708 content. 1710 7.3.2.2 Subject 1712 The element specifies the topic of the message. The 1713 element MUST NOT possess any attributes, with the 1714 exception of the 'xml:lang' attribute. Multiple instances of the 1715 element MAY be included for the purpose of providing 1716 alternate versions of the same subject, but only if each instance 1717 possesses an 'xml:lang' attribute with a distinct language value. 1718 The element MUST NOT contain mixed content. 1720 7.3.2.3 Thread 1722 The element contains a random string that is generated by 1723 the sender and that SHOULD be copied back in replies; it is used for 1724 tracking a conversation thread (sometimes referred to as an "IM 1725 session") between two entities. If used, it MUST be unique to that 1726 conversation thread within the stream and MUST be consistent 1727 throughout that conversation. The use of the element is 1728 optional and is not used to identify individual messages, only 1729 conversations. Only one element MAY be included in a 1730 message stanza, and it MUST NOT possess any attributes. The element MUST be treated as an opaque string by entities; no 1732 semantic meaning may be derived from it, and only exact, case- 1733 insensitve comparisons be made against it. The element MUST 1734 NOT contain mixed content. 1736 The method for generating thread IDs SHOULD be as follows: 1738 1. concatenate the sender's full JID (user@host/resource) with the 1739 recipient's full JID 1741 2. concatenate these JID strings with a full ISO-8601 timestamp 1742 including year, month, day, hours, minutes, seconds, and UTC 1743 offset in the following format: yyyy-mm-dd-Thh:mm:ss-hh:mm 1745 3. hash the resulting string according to the SHA1 algorithm 1747 4. convert the hexidecimal SHA1 output to all lowercase 1749 7.4 Presence Stanzas 1751 Presence stanzas are used in the 'jabber:client' or 'jabber:server' 1752 namespace to express an entity's current availability status (offline 1753 or online, along with various sub-states of the latter and optional 1754 user-defined descriptive text) and to communicate that status to 1755 other entities. Presence stanzas are also used to negotiate and 1756 manage subscriptions to the presence of other entities. 1758 7.4.1 Types of Presence 1760 The 'type' attribute of a presence stanza is optional. A presence 1761 stanza that does not possess a 'type' attribute is used to signal to 1762 the server that the sender is online and available for communication. 1763 If included, the 'type' attribute specifies a lack of availability, a 1764 request to manage a subscription to another entity's presence, a 1765 request for another entity's current presence, or an error related to 1766 a previously-sent presence stanza. The 'type' attribute MAY have one 1767 of the following values: 1769 o unavailable -- Signals that the entity is no longer available for 1770 communication. 1772 o subscribe -- The sender wishes to subscribe to the recipient's 1773 presence. 1775 o subscribed -- The sender has allowed the recipient to receive 1776 their presence. 1778 o unsubscribe -- A notification that an entity is unsubscribing from 1779 another entity's presence. 1781 o unsubscribed -- The subscription request has been denied or a 1782 previously-granted subscription has been cancelled. 1784 o probe -- A request for an entity's current presence. In general 1785 SHOULD NOT be sent by a client. 1787 o error -- An error has occurred regarding processing or delivery of 1788 a previously-sent presence stanza. 1790 Information about the subscription model used within XMPP can be 1791 found in XMPP IM [2]. 1793 7.4.2 Children 1795 As described under extended namespaces (Section 7.6), a presence 1796 stanza MAY contain any properly-namespaced child element as long as 1797 the namespace name is not "jabber:client", "jabber:server", or 1798 "http://etherx.jabber.org/streams", and as long as the element name 1799 does not match that of one of the core data elements, stream 1800 elements, or defined children thereof. 1802 In accordance with the default namespace declaration, by default a 1803 presence stanza is in the 'jabber:client' or 'jabber:server' 1804 namespace, which defines certain allowable children of presence 1805 stanzas. If the presence stanza is of type "error", it MUST include 1806 an child; for details, see Section 7.7. If the presence 1807 stanza possesses no 'type' attribute, it MAY contain any of the 1808 following child elements (note that the child MAY be sent 1809 in a presence stanza of type "unavailable" or, for historical 1810 reasons, "subscribe"): 1812 7.4.2.1 Show 1814 The element specifies describes the availability status of an 1815 entity or specific resource. Only one element MAY be 1816 included in a presence stanza, and it MUST NOT possess any 1817 attributes. The value SHOULD be one of the following (values other 1818 than these four MAY be ignored; additional availability types could 1819 be defined through a properly-namespaced child element of the 1820 presence stanza): 1822 o away 1824 o chat 1826 o xa 1828 o dnd 1830 For information about the meaning of these values, refer to XMPP IM 1831 [2]. 1833 7.4.2.2 Status 1835 The optional element specifies a natural-language 1836 description of availability status. It is normally used in 1837 conjunction with the show element to provide a detailed description 1838 of an availability state (e.g., "In a meeting"). The 1839 element MUST NOT possess any attributes, with the exception of the 1840 'xml:lang' attribute. Multiple instances of the element 1841 MAY be included but only if each instance possesses an 'xml:lang' 1842 attribute with a distinct language value. 1844 7.4.2.3 Priority 1846 The optional element specifies the priority level of the 1847 connected resource. The value may be any integer between -128 to 1848 127. Only one element MAY be included in a presence 1849 stanza, and it MUST NOT possess any attributes. For information 1850 regarding the use of priority values in stanza routing within IM 1851 applications, see XMPP IM [2]. 1853 7.5 IQ Stanzas 1855 7.5.1 Overview 1857 Info/Query, or IQ, is a request-response mechanism, similar in some 1858 ways to HTTP [24]. IQ stanzas in the 'jabber:client' or 1859 'jabber:server' namespace enable an entity to make a request of, and 1860 receive a response from, another entity. The data content of the 1861 request and response is defined by the namespace declaration of a 1862 direct child element of the IQ element, and the interaction is 1863 tracked by the requesting entity through use of the 'id' attribute, 1864 which responding entities SHOULD return in any response. 1866 Most IQ interactions follow a common pattern of structured data 1867 exchange such as get/result or set/result (although an error may be 1868 returned in response to a request if appropriate): 1870 Requesting Responding 1871 Entity Entity 1872 ---------- ---------- 1873 | | 1874 | | 1875 | ------------------------> | 1876 | | 1877 | | 1878 | <------------------------ | 1879 | | 1880 | | 1881 | ------------------------> | 1882 | | 1883 | | 1884 | <------------------------ | 1885 | | 1887 An entity that receives an IQ request of type 'get' or 'set' MUST 1888 reply with an IQ response of type 'result' or 'error' (which response 1889 MUST preserve the 'id' attribute of the request). An entity that 1890 receives a stanza of type 'result' or 'error' MUST NOT respond to the 1891 stanza by sending a further IQ response of type 'result' or 'error'; 1892 however, as shown above, the requesting entity MAY send another 1893 request (e.g., an IQ of type 'set' in order to provide required 1894 information discovered through a get/result pair). 1896 7.5.2 Types of IQ 1898 The 'type' attribute of an IQ stanza is REQUIRED. The 'type' 1899 attribute specifies a distinct step within a request-response 1900 interaction. The value SHOULD be one of the following (all other 1901 values MAY be ignored): 1903 o get -- The stanza is a request for information. 1905 o set -- The stanza provides required data, sets new values, or 1906 replaces existing values. 1908 o result -- The stanza is a response to a successful get or set 1909 request. 1911 o error -- An error has occurred regarding processing or delivery of 1912 a previously-sent get or set. 1914 7.5.3 Children 1916 As described under extended namespaces (Section 7.6), an IQ stanza 1917 MAY contain any properly-namespaced child element as long as the 1918 namespace name is not "jabber:client", "jabber"server", or "http:// 1919 etherx.jabber.org/streams", and as long as the element name does not 1920 match that of one of the core data elements, stream elements, or 1921 defined children thereof. However, an IQ stanza contains no children 1922 in the 'jabber:client' or 'jabber:server' namespace since it is a 1923 vessel for XML in another namespace. 1925 If the IQ stanza is of type "error", it MUST include an 1926 child; for details, see Section 7.7. 1928 7.6 Extended Namespaces 1930 While the core data elements in the "jabber:client" or 1931 "jabber:server" namespace (along with their attributes and child 1932 elements) provide a basic level of functionality for messaging and 1933 presence, XMPP uses XML namespaces to extend the core data elements 1934 for the purpose of providing additional functionality. Thus a 1935 message, presence, or IQ stanza MAY house one or more optional child 1936 elements containing content that extends the meaning of the message 1937 (e.g., an encrypted form of the message body). This child element 1938 MAY be any element (other than the core data elements, stream 1939 elements, or defined children thereof). The child element MUST 1940 possess an 'xmlns' namespace declaration (other than the stream 1941 namespace and the default namespace) that defines all data contained 1942 within the child element. 1944 Support for any given extended namespace is OPTIONAL on the part of 1945 any implementation. If an entity does not understand such a 1946 namespace, it MUST ignore the associated XML data (if the stanza is 1947 being routed on to another entity, ignore means "pass it on 1948 untouched"). If an entity receives a message or presence stanza that 1949 contains XML data in an extended namespace it does not understand, 1950 the portion of the stanza that is in the unknown namespace SHOULD be 1951 ignored. If an entity receives a message stanza without a 1952 element but containing only a child element bound by a namespace it 1953 does not understand, it MUST ignore the entire stanza. If an entity 1954 receives an IQ stanza in a namespace it does not understand, the 1955 entity SHOULD return an IQ stanza of type "error" with an error 1956 condition of . 1958 7.7 Stanza Errors 1960 As defined below, stanza-related errors are handled in a manner 1961 similar to stream errors (Section 4.5). 1963 7.7.1 Rules 1965 The following rules apply to stanza-related errors: 1967 o A stanza of type "error" MUST contain an child element. 1969 o The receiving or processing entity that returns an error to the 1970 sending entity SHOULD include the original XML sent along with the 1971 element and its children so that the sender can inspect 1972 and if necessary correct the XML before re-sending. 1974 o An entity that receives a message stanza of type 'error' MUST NOT 1975 respond to the stanza by sending a further message stanza of type 1976 'error'; this helps to prevent looping. 1978 o An child MUST NOT be included if the stanza type is 1979 something other than "error". 1981 7.7.2 Syntax 1983 The syntax for stanza-related errors is as follows: 1985 1986 [include sender XML here] 1987 1988 1989 1990 1991 1992 1994 The stanza name is one of message, presence, or iq. 1996 The value of the 'class' attribute must be one of the following: 1998 o access -- the condition relates to access rights, permissions, or 1999 authorization 2001 o address -- the condition relates to the JID or domain to which the 2002 stanza was addressed 2004 o app -- the condition is particular to an application and is 2005 specified in a namespace other than 'urn:ietf:params:xml:ns:xmpp- 2006 stanzas' 2008 o format -- the condition relates to XML format or structure 2010 o recipient -- the condition relates to the state or capabilities of 2011 the recipient (which may be the server) 2013 o server -- the condition relates to the internal state of the 2014 server 2016 The element MUST contain a child element that 2017 specifies a particular stanza-related error condition, as defined in 2018 the next section. (Note: the XML namespace name 2019 'urn:ietf:params:xml:ns:xmpp-stanzas' that scopes the element adheres to the format defined in The IETF XML 2021 Registry [15].) 2023 7.7.3 Conditions 2025 The following stanza-related error conditions are defined: 2027 o -- the sender has sent XML that is malformed or 2028 cannot be processed (e.g., a client-generated stanza includes a 2029 'from' address, or an IQ stanza includes an unrecognized value of 2030 the 'type' attribute); the associated class is "format". 2032 o -- the feature requested is not 2033 implemented by the recipient or server and therefore cannot be 2034 processed; the associated class is "recipient". 2036 o -- the stanza is understood but the action is 2037 forbidden; the associated class is "access". 2039 o -- the server could not process the 2040 stanza because of a misconfiguration or an otherwise-undefined 2041 internal server error; the associated class is "server". 2043 o -- the value of the 'to' attribute in the 2044 sender's stanza does not adhere to the syntax defined in 2045 Addressing (Section 3); the associated class is "address". 2047 o -- the value of the 'to' attribute in the 2048 sender's stanza does not correspond to a Jabber ID on the user's 2049 server or a remote server; the associated class is "address". 2051 o -- the action is not permitted when attempted by 2052 the sender; the associated class is "access". 2054 o -- the specific recipient requested is 2055 currently unavailable; the associated class is "recipient". 2057 o -- the user is not authorized to access 2058 the requested service because registration is required; the 2059 associated class is "access". 2061 o -- a remote server or service specified 2062 as part or all of the JID of the intended recipient does not 2063 exist; the associated class is "address". 2065 o -- a remote server or service specified 2066 as part or all of the JID of the intended recipient could not be 2067 contacted within a reasonable amount of time; the associated class 2068 is "server". 2070 o -- the service requested is currently 2071 unavailable on the server; the associated class is "server". 2073 7.7.4 Extensibility 2075 If desired, an XMPP application MAY provide custom error information; 2076 this MUST be contained in a properly-namespaced child of the element (i.e., the namespace name MUST NOT be one of 2078 namespace names defined herein). 2080 8. XML Usage within XMPP 2082 8.1 Restrictions 2084 XMPP is a simplified and specialized protocol for streaming XML 2085 elements in order to exchange messages and presence information in 2086 close to real time. Because XMPP does not require the parsing of 2087 arbitrary and complete XML documents, there is no requirement that 2088 XMPP must support the full XML specification [1]. In particular, the 2089 following restrictions apply: 2091 With regard to XML generation, an XMPP implementation MUST NOT inject 2092 into an XML stream any of the following: 2094 o comments (as defined in Section 2.5 of the XML specification [1]) 2096 o processing instructions (Section 2.6) 2098 o internal or external DTD subsets (Section 2.8) 2100 o internal or external entity references (Section 4.2) with the 2101 exception of predefined entities (Section 4.6) 2103 With regard to XML processing, if an XMPP implementation receives 2104 such restricted XML data, it MUST ignore the data. 2106 8.2 Namespaces 2108 XML Namespaces [14] are used within all XMPP-compliant XML to create 2109 strict boundaries of data ownership. The basic function of 2110 namespaces is to separate different vocabularies of XML elements that 2111 are structurally mixed together. Ensuring that XMPP-compliant XML is 2112 namespace-aware enables any XML to be structurally mixed with any 2113 data element within XMPP. 2115 Additionally, XMPP is more strict about namespace prefixes than the 2116 XML namespace specification requires. 2118 8.3 Validation 2120 A server is not responsible for validating the XML elements forwarded 2121 to a client or another server; an implementation MAY choose to 2122 provide only validated data elements but is NOT REQUIRED to do so. 2123 Clients SHOULD NOT rely on the ability to send data which does not 2124 conform to the schemas, and SHOULD ignore any non-conformant elements 2125 or attributes on the incoming XML stream. Validation of XML streams 2126 and stanzas is NOT REQUIRED or recommended, and schemas are included 2127 herein for descriptive purposes only. 2129 8.4 Character Encodings 2131 Software implementing XML streams MUST support the UTF-8 (RFC 2279 2132 [25]) and UTF-16 (RFC 2781 [26]) transformations of Universal 2133 Character Set (ISO/IEC 10646-1 [27]) characters. Software MUST NOT 2134 attempt to use any other encoding for transmitted data. The 2135 encodings of the transmitted and received streams are independent. 2136 Software MAY select either UTF-8 or UTF-16 for the transmitted 2137 stream, and SHOULD deduce the encoding of the received stream as 2138 described in the XML specification [1]. For historical reasons, 2139 existing implementations MAY support UTF-8 only. 2141 8.5 Inclusion of Text Declaration 2143 An application MAY send a text declaration. Applications MUST follow 2144 the rules in the XML specification [1] regarding the circumstances 2145 under which a text declaration is included. 2147 9. IANA Considerations 2149 9.1 XML Namespace Name for Stream Errors 2151 A URN sub-namespace for XMPP stream error tags is defined as follows. 2153 URI: urn:ietf:params:xml:ns:xmpp-streams 2155 Specification: [RFCXXXX] 2157 Description: This is the XML namespace name for XMPP stream errors as 2158 defined by [RFCXXXX]. 2160 Registrant Contact: IETF, XMPP Working Group, 2162 9.2 XML Namespace Name for Stanza Errors 2164 A URN sub-namespace for XMPP stanza error tags is defined as follows. 2166 URI: urn:ietf:params:xml:ns:xmpp-stanzas 2168 Specification: [RFCXXXX] 2170 Description: This is the XML namespace name for XMPP stanza errors as 2171 defined by [RFCXXXX]. 2173 Registrant Contact: IETF, XMPP Working Group, 2175 9.3 Existing Registrations 2177 The IANA registers "xmpp" as a GSSAPI [29] service name, as specified 2178 in Section 6.1.3. 2180 Additionally, the IANA registers "jabber-client" and "jabber-server" 2181 as keywords for TCP ports 5222 and 5269 respectively. 2183 10. Internationalization Considerations 2185 Usage of the 'xml:lang' attribute is described above. If a client 2186 includes an 'xml:lang' attribute in a stanza, the server MUST NOT 2187 modify or delete it. 2189 11. Security Considerations 2191 11.1 High Security 2193 For the purposes of XMPP communications (client-to-server and server- 2194 to-server), the term "high security" refers to the use of security 2195 technologies that provide both mutual authentication and integrity- 2196 checking; in particular, when using certificate-based authentication 2197 to provide high security, a chain-of-trust must be established out- 2198 of-band (i.e., no self-signed certificates). 2200 Implementations MUST support high security. Service provisioning 2201 SHOULD use high security, subject to local security policies. 2203 11.2 Client-to-Server Communications 2205 The TLS protocol for encrypting XML streams (defined under Section 5) 2206 provides a reliable mechanism for helping to ensure the 2207 confidentiality and data integrity of data exchanged between two 2208 entities. 2210 The SASL protocol for authenticating XML streams (defined under 2211 Section 6.1) provides a reliable mechanism for validating that a 2212 client connecting to a server is who it claims to be. 2214 The IP address and method of access of clients MUST NOT be made 2215 available by a server, nor are any connections other than the 2216 original server connection required. This helps protect the client's 2217 server from direct attack or identification by third parties. 2219 End-to-end encryption of message bodies and presence status 2220 information MAY be effected through use of the methods defined in 2221 End-to-End Object Encryption in XMPP [28]. 2223 11.3 Server-to-Server Communications 2225 A compliant implementation MUST support both TLS and SASL for inter- 2226 domain communications. For historical reasons, a compliant 2227 implementation SHOULD also support the lower-security Dialback 2228 Protocol (Section 6.2), which provides a mechanism for helping to 2229 prevent the spoofing of domains. 2231 Because service provisioning is a matter of policy, it is OPTIONAL 2232 for any given domain to communicate with other domains, and server- 2233 to-server communications MAY be disabled by the administrator of any 2234 given deployment. If a particular domain enables inter-domain 2235 communications, it SHOULD enable high security. In the absence of 2236 high security, a domain MAY use server dialback for inter-domain 2237 communications. 2239 11.4 Firewalls 2241 Communications using XMPP normally occur over TCP sockets on port 2242 5222 (client-to-server) or port 5269 (server-to-server), as 2243 registered with the IANA [6]. Use of these well-known ports allows 2244 administrators to easily enable or disable XMPP activity through 2245 existing and commonly-deployed firewalls. 2247 11.5 Mandatory to Implement Technologies 2249 At a minimum, all implementations MUST support the following 2250 mechanisms: 2252 for authentication: the SASL DIGEST-MD5 mechanism 2254 for confidentiality: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA 2255 cipher) 2257 for both: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher 2258 supporting client-side certificates) 2260 References 2262 [1] World Wide Web Consortium, "Extensible Markup Language (XML) 2263 1.0 (Second Edition)", W3C xml, October 2000, . 2266 [2] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging (draft- 2267 ietf-xmpp-im-07, work in progress)", April 2003. 2269 [3] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for 2270 Presence and Instant Messaging", RFC 2779, February 2000, 2271 . 2273 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2274 Levels", BCP 14, RFC 2119, March 1997. 2276 [5] University of Southern California, "Transmission Control 2277 Protocol", RFC 793, September 1981, . 2280 [6] Internet Assigned Numbers Authority, "Internet Assigned Numbers 2281 Authority", January 1998, . 2283 [7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 2284 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 2285 1998, . 2287 [8] Harrenstien, K., Stahl, M. and E. Feinler, "DoD Internet host 2288 table specification", RFC 952, October 1985. 2290 [9] Braden, R., "Requirements for Internet Hosts - Application and 2291 Support", STD 3, RFC 1123, October 1989. 2293 [10] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile 2294 for Internationalized Domain Names (draft-ietf-idn-nameprep-11, 2295 work in progress)", June 2002. 2297 [11] Hoffman, P. and M. Blanchet, "Preparation of Internationalized 2298 Strings ("stringprep")", RFC 3454, December 2002. 2300 [12] Saint-Andre, P. and J. Hildebrand, "Nodeprep: A Stringprep 2301 Profile for Node Identifiers in XMPP (draft-ietf-xmpp-nodeprep- 2302 01, work in progress)", February 2003. 2304 [13] Saint-Andre, P. and J. Hildebrand, "Resourceprep: A Stringprep 2305 Profile for Resource Identifiers in XMPP (draft-ietf-xmpp- 2306 resourceprep-01, work in progress)", February 2003. 2308 [14] World Wide Web Consortium, "Namespaces in XML", W3C xml-names, 2309 January 1999, . 2312 [15] Mealling, M., "The IANA XML Registry", draft-mealling-iana- 2313 xmlns-registry-04 (work in progress), June 2002. 2315 [16] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 2316 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 2317 1999. 2319 [17] Crispin, M., "Internet Message Access Protocol - Version 2320 4rev1", RFC 2060, December 1996. 2322 [18] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 2323 53, RFC 1939, May 1996. 2325 [19] Newman, C. and J. Myers, "ACAP -- Application Configuration 2326 Access Protocol", RFC 2244, November 1997. 2328 [20] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, 2329 June 1999. 2331 [21] Myers, J., "Simple Authentication and Security Layer (SASL)", 2332 RFC 2222, October 1997. 2334 [22] Alvestrand, H., "Tags for the Identification of Languages", BCP 2335 47, RFC 3066, January 2001. 2337 [23] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the 2338 location of services (DNS SRV)", RFC 2052, October 1996. 2340 [24] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 2341 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 2342 HTTP/1.1", RFC 2616, June 1999. 2344 [25] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2345 2279, January 1998. 2347 [26] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", 2348 RFC 2781, February 2000. 2350 [27] International Organization for Standardization, "Information 2351 Technology - Universal Multiple-octet coded Character Set (UCS) 2352 - Amendment 2: UCS Transformation Format 8 (UTF-8)", ISO 2353 Standard 10646-1 Addendum 2, October 1996. 2355 [28] Saint-Andre, P. and J. Hildebrand, "End-to-End Object 2356 Encryption in XMPP (draft-ietf-xmpp-e2e-00, work in progress)", 2357 February 2003. 2359 [29] Linn, J., "Generic Security Service Application Program 2360 Interface, Version 2", RFC 2078, January 1997. 2362 Authors' Addresses 2364 Peter Saint-Andre 2365 Jabber Software Foundation 2367 EMail: stpeter@jabber.org 2368 URI: http://www.jabber.org/people/stpeter.php 2370 Jeremie Miller 2371 Jabber Software Foundation 2373 EMail: jeremie@jabber.org 2374 URI: http://www.jabber.org/people/jer.php 2376 Appendix A. XML Schemas 2378 The following XML schemas are descriptive, not normative. 2380 A.1 Streams namespace 2382 2384 2390 2391 2392 2393 2394 2395 2398 2401 2402 2403 2404 2405 2406 2407 2409 2410 2411 2415 2416 2418 2419 2420 2421 2422 2423 2424 2425 2426 2427 2428 2429 2430 2431 2432 2434 2436 A.2 TLS namespace 2438 2440 2446 2447 2448 2450 2452 A.3 SASL namespace 2453 2455 2461 2462 2463 2464 2465 2467 2469 2470 2471 2472 2473 2475 2476 2477 2478 2479 2480 2481 2482 2483 2485 2487 A.4 Dialback namespace 2489 2491 2497 2498 2499 2500 2501 2502 2503 2504 2505 2506 2507 2508 2509 2510 2511 2512 2513 2514 2516 2517 2518 2519 2520 2521 2522 2523 2524 2525 2526 2527 2528 2529 2530 2531 2532 2533 2534 2536 2538 A.5 Client namespace 2540 2542 2548 2549 2550 2551 2552 2553 2554 2555 2559 2560 2561 2562 2563 2564 2565 2566 2567 2568 2569 2570 2571 2572 2573 2574 2575 2577 2578 2579 2580 2581 2583 2584 2585 2586 2587 2589 2591 2592 2593 2594 2595 2596 2597 2598 2602 2603 2604 2605 2606 2607 2608 2609 2610 2611 2612 2613 2614 2615 2616 2617 2618 2619 2620 2622 2623 2624 2625 2626 2627 2628 2629 2630 2631 2633 2634 2635 2636 2637 2639 2641 2642 2643 2644 2645 2649 2650 2651 2652 2653 2654 2655 2656 2657 2658 2659 2660 2661 2662 2663 2664 2666 2667 2668 2669 2670 2671 2672 2673 2674 2675 2676 2677 2678 2679 2680 2681 2683 2685 A.6 Server namespace 2687 2689 2695 2696 2697 2698 2699 2700 2701 2702 2706 2707 2708 2709 2710 2711 2712 2713 2714 2715 2716 2717 2718 2719 2720 2721 2722 2724 2725 2726 2727 2728 2730 2731 2732 2733 2734 2736 2738 2739 2740 2741 2742 2743 2744 2745 2749 2750 2751 2752 2753 2754 2755 2756 2757 2758 2759 2760 2761 2762 2763 2764 2765 2766 2767 2769 2770 2771 2772 2773 2774 2775 2776 2777 2778 2780 2781 2782 2783 2784 2786 2787 2788 2789 2790 2791 2795 2796 2797 2798 2799 2800 2801 2802 2803 2804 2805 2806 2807 2808 2809 2810 2812 2813 2814 2815 2816 2817 2818 2819 2820 2821 2822 2823 2824 2825 2826 2827 2829 2831 A.7 Stream error namespace 2833 2834 2840 2841 2842 2846 2847 2848 2849 2850 2851 2852 2853 2854 2855 2856 2857 2858 2860 2861 2862 2863 2864 2865 2866 2867 2868 2869 2871 2873 A.8 Stanza error namespace 2875 2877 2883 2884 2885 2889 2890 2891 2892 2893 2894 2895 2896 2897 2898 2899 2900 2901 2902 2903 2905 2906 2907 2908 2909 2910 2911 2912 2913 2914 2915 2916 2918 2920 Appendix B. Revision History 2922 Note to RFC editor: please remove this entire appendix, and the 2923 corresponding entries in the table of contents, prior to publication. 2925 B.1 Changes from draft-ietf-xmpp-core-06 2927 o Added text regarding certificate validation in TLS negotiation per 2928 list discussion. 2930 o Clarified nature of XML restrictions per discussion with W3C, and 2931 moved XML Restrictions subsection under "XML Usage within XMPP". 2933 o Further clarified that XML streams are unidirectional. 2935 o Changed stream error and stanza error namespace names to conform 2936 to the format defined in The IETF XML Registry [15]. 2938 o Removed note to RFC editor regarding provisional namespace names. 2940 B.2 Changes from draft-ietf-xmpp-core-05 2942 o Added as a stream error condition. 2944 o Adjusted security considerations per discussion at IETF 56 and on 2945 list. 2947 B.3 Changes from draft-ietf-xmpp-core-04 2949 o Added server-to-server examples for TLS and SASL. 2951 o Changed error syntax, rules, and examples based on list 2952 discussion. 2954 o Added schemas for the TLS, stream error, and stanza error 2955 namespaces. 2957 o Added note to RFC editor regarding provisional namespace names. 2959 o Made numerous small editorial changes and clarified text 2960 throughout. 2962 B.4 Changes from draft-ietf-xmpp-core-03 2964 o Clarified rules and procedures for TLS and SASL. 2966 o Amplified stream error code syntax per list discussion. 2968 o Made numerous small editorial changes. 2970 B.5 Changes from draft-ietf-xmpp-core-02 2972 o Added dialback schema. 2974 o Removed all DTDs since schemas provide more complete definitions. 2976 o Added stream error codes. 2978 o Clarified error code "philosophy". 2980 B.6 Changes from draft-ietf-xmpp-core-01 2982 o Updated the addressing restrictions per list discussion and added 2983 references to the new nodeprep and resourceprep profiles. 2985 o Corrected error in Stream Authentication regarding "version='1.0'" 2986 flag. 2988 o Made numerous small editorial changes. 2990 B.7 Changes from draft-ietf-xmpp-core-00 2992 o Added information about TLS from list discussion. 2994 o Clarified meaning of "ignore" based on list discussion. 2996 o Clarified information about Universal Character Set data and 2997 character encodings. 2999 o Provided base64-decoded information for examples. 3001 o Fixed several errors in the schemas. 3003 o Made numerous small editorial fixes. 3005 B.8 Changes from draft-miller-xmpp-core-02 3007 o Brought Streams Authentication section into line with discussion 3008 on list and at IETF 55 meeting. 3010 o Added information about the optional 'xml:lang' attribute per 3011 discussion on list and at IETF 55 meeting. 3013 o Specified that validation is neither required nor recommended, and 3014 that the formal definitions (DTDs and schemas) are included for 3015 descriptive purposes only. 3017 o Specified that the response to an IQ stanza of type 'get' or 'set' 3018 must be an IQ stanza of type 'result' or 'error'. 3020 o Specified that compliant server implementations must process 3021 stanzas in order. 3023 o Specified that for historical reasons some server implementations 3024 may accept 'stream:' as the only valid namespace prefix on the 3025 root stream element. 3027 o Clarified the difference between 'jabber:client' and 3028 'jabber:server' namespaces, namely, that 'to' and 'from' 3029 attributes are required on all stanzas in the latter but not the 3030 former. 3032 o Fixed typo in Step 9 of the dialback protocol (changed db:result 3033 to db:verify). 3035 o Removed references to TLS pending list discussion. 3037 o Removed the non-normative appendix on OpenPGP usage pending its 3038 inclusion in a separate I-D. 3040 o Simplified the architecture diagram, removed most references to 3041 services, and removed references to the 'jabber:component:*' 3042 namespaces. 3044 o Noted that XMPP activity respects firewall administration 3045 policies. 3047 o Further specified the scope and uniqueness of the 'id' attribute 3048 in all stanza types and the element in message stanzas. 3050 o Nomenclature changes: (1) from "chunks" to "stanzas"; (2) from 3051 "host" to "server" and from "node" to "client" (except with regard 3052 to definition of the addressing scheme). 3054 Full Copyright Statement 3056 Copyright (C) The Internet Society (2003). All Rights Reserved. 3058 This document and translations of it may be copied and furnished to 3059 others, and derivative works that comment on or otherwise explain it 3060 or assist in its implementation may be prepared, copied, published 3061 and distributed, in whole or in part, without restriction of any 3062 kind, provided that the above copyright notice and this paragraph are 3063 included on all such copies and derivative works. However, this 3064 document itself may not be modified in any way, such as by removing 3065 the copyright notice or references to the Internet Society or other 3066 Internet organizations, except as needed for the purpose of 3067 developing Internet standards in which case the procedures for 3068 copyrights defined in the Internet Standards process must be 3069 followed, or as required to translate it into languages other than 3070 English. 3072 The limited permissions granted above are perpetual and will not be 3073 revoked by the Internet Society or its successors or assigns. 3075 This document and the information contained herein is provided on an 3076 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3077 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3078 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3079 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3080 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3082 Acknowledgement 3084 Funding for the RFC Editor function is currently provided by the 3085 Internet Society.