idnits 2.17.1 draft-ietf-xmpp-core-18.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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance 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 == 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 (September 7, 2003) is 7536 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 434, but not defined -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 2529 -- Possible downref: Non-RFC (?) normative reference: ref. '1' ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '2') ** Obsolete normative reference: RFC 793 (ref. '4') (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Downref: Normative reference to an Unknown state RFC: RFC 952 (ref. '6') ** Obsolete normative reference: RFC 3491 (ref. '8') (Obsoleted by RFC 5891) ** Obsolete normative reference: RFC 3454 (ref. '9') (Obsoleted by RFC 7564) -- Possible downref: Non-RFC (?) normative reference: ref. '10' ** Obsolete normative reference: RFC 2246 (ref. '11') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2818 (ref. '12') (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 2222 (ref. '13') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 3066 (ref. '15') (Obsoleted by RFC 4646, RFC 4647) ** Obsolete normative reference: RFC 2279 (ref. '16') (Obsoleted by RFC 3629) -- Possible downref: Non-RFC (?) normative reference: ref. '17' ** Obsolete normative reference: RFC 2078 (ref. '18') (Obsoleted by RFC 2743) == Outdated reference: A later version (-22) exists of draft-ietf-xmpp-im-17 -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '21') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2396 (ref. '22') (Obsoleted by RFC 3986) -- Obsolete informational reference (is this intentional?): RFC 2060 (ref. '24') (Obsoleted by RFC 3501) -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '28') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 14 errors (**), 0 flaws (~~), 6 warnings (==), 13 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: March 7, 2004 Jabber Software Foundation 5 September 7, 2003 7 XMPP Core 8 draft-ietf-xmpp-core-18 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on March 7, 2004. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document describes the core features of the Extensible Messaging 39 and Presence Protocol (XMPP), a protocol for streaming XML [1] 40 elements in order to exchange messages and presence information in 41 close to real time. While XMPP provides a generalized, extensible 42 framework for transporting structured information, it is used mainly 43 for the purpose of building instant messaging and presence 44 applications that meet the requirements of RFC 2779. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 49 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 50 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 6 51 1.3 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . 6 52 1.4 Intellectual Property Notice . . . . . . . . . . . . . . . . 6 53 2. Generalized Architecture . . . . . . . . . . . . . . . . . . 7 54 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 55 2.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 56 2.3 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 57 2.4 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 8 58 2.5 Network . . . . . . . . . . . . . . . . . . . . . . . . . . 8 59 3. Addressing Scheme . . . . . . . . . . . . . . . . . . . . . 9 60 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 9 61 3.2 Domain Identifier . . . . . . . . . . . . . . . . . . . . . 9 62 3.3 Node Identifier . . . . . . . . . . . . . . . . . . . . . . 10 63 3.4 Resource Identifier . . . . . . . . . . . . . . . . . . . . 10 64 4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . 11 65 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 11 66 4.2 Stream Attributes . . . . . . . . . . . . . . . . . . . . . 12 67 4.2.1 Version Support . . . . . . . . . . . . . . . . . . . . . . 13 68 4.3 Namespace Declarations . . . . . . . . . . . . . . . . . . . 14 69 4.4 Stream Features . . . . . . . . . . . . . . . . . . . . . . 14 70 4.5 Stream Encryption and Authentication . . . . . . . . . . . . 15 71 4.6 Stream Errors . . . . . . . . . . . . . . . . . . . . . . . 15 72 4.6.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 73 4.6.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 4.6.3 Defined Conditions . . . . . . . . . . . . . . . . . . . . . 16 75 4.6.4 Application-Specific Conditions . . . . . . . . . . . . . . 18 76 4.7 Simple Streams Example . . . . . . . . . . . . . . . . . . . 19 77 5. Stream Encryption . . . . . . . . . . . . . . . . . . . . . 21 78 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 21 79 5.2 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . 23 80 5.3 Client-to-Server Example . . . . . . . . . . . . . . . . . . 24 81 5.4 Server-to-Server Example . . . . . . . . . . . . . . . . . . 25 82 6. Stream Authentication . . . . . . . . . . . . . . . . . . . 28 83 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 28 84 6.2 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . 29 85 6.3 SASL Errors . . . . . . . . . . . . . . . . . . . . . . . . 31 86 6.4 SASL Definition . . . . . . . . . . . . . . . . . . . . . . 32 87 6.5 Client-to-Server Example . . . . . . . . . . . . . . . . . . 32 88 6.6 Server-to-Server Example . . . . . . . . . . . . . . . . . . 35 89 7. Server Dialback . . . . . . . . . . . . . . . . . . . . . . 39 90 7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 39 91 7.2 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 41 92 8. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . 45 93 8.1 Common Attributes . . . . . . . . . . . . . . . . . . . . . 45 94 8.1.1 to . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 95 8.1.2 from . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 96 8.1.3 id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 97 8.1.4 type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 98 8.1.5 xml:lang . . . . . . . . . . . . . . . . . . . . . . . . . . 46 99 8.2 Basic Semantics . . . . . . . . . . . . . . . . . . . . . . 47 100 8.2.1 Message Semantics . . . . . . . . . . . . . . . . . . . . . 47 101 8.2.2 Presence Semantics . . . . . . . . . . . . . . . . . . . . . 47 102 8.2.3 IQ Semantics . . . . . . . . . . . . . . . . . . . . . . . . 47 103 8.3 Stanza Errors . . . . . . . . . . . . . . . . . . . . . . . 49 104 8.3.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 105 8.3.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 106 8.3.3 Defined Conditions . . . . . . . . . . . . . . . . . . . . . 51 107 8.3.4 Application-Specific Conditions . . . . . . . . . . . . . . 52 108 9. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 54 109 9.1 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 54 110 9.2 XML Namespace Names and Prefixes . . . . . . . . . . . . . . 54 111 9.2.1 Stream Namespace . . . . . . . . . . . . . . . . . . . . . . 54 112 9.2.2 Default Namespace . . . . . . . . . . . . . . . . . . . . . 55 113 9.2.3 Dialback Namespace . . . . . . . . . . . . . . . . . . . . . 55 114 9.3 Validation . . . . . . . . . . . . . . . . . . . . . . . . . 56 115 9.4 Inclusion of Text Declaration . . . . . . . . . . . . . . . 56 116 9.5 Character Encoding . . . . . . . . . . . . . . . . . . . . . 56 117 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 57 118 10.1 XML Namespace Name for TLS Data . . . . . . . . . . . . . . 57 119 10.2 XML Namespace Name for SASL Data . . . . . . . . . . . . . . 57 120 10.3 XML Namespace Name for Stream Errors . . . . . . . . . . . . 57 121 10.4 XML Namespace Name for Stanza Errors . . . . . . . . . . . . 58 122 10.5 Nodeprep Profile of Stringprep . . . . . . . . . . . . . . . 58 123 10.6 Resourceprep Profile of Stringprep . . . . . . . . . . . . . 58 124 10.7 Existing Registrations . . . . . . . . . . . . . . . . . . . 59 125 11. Internationalization Considerations . . . . . . . . . . . . 60 126 12. Security Considerations . . . . . . . . . . . . . . . . . . 61 127 12.1 High Security . . . . . . . . . . . . . . . . . . . . . . . 61 128 12.2 Client-to-Server Communications . . . . . . . . . . . . . . 61 129 12.3 Server-to-Server Communications . . . . . . . . . . . . . . 62 130 12.4 Order of Layers . . . . . . . . . . . . . . . . . . . . . . 63 131 12.5 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . 63 132 12.6 Mandatory to Implement Technologies . . . . . . . . . . . . 63 133 12.7 Stringprep Profiles . . . . . . . . . . . . . . . . . . . . 63 134 13. Server Rules for Handling XML Stanzas . . . . . . . . . . . 65 135 13.1 No 'to' Address . . . . . . . . . . . . . . . . . . . . . . 65 136 13.2 Foreign Domain . . . . . . . . . . . . . . . . . . . . . . . 65 137 13.3 Subdomain . . . . . . . . . . . . . . . . . . . . . . . . . 66 138 13.4 Bare Domain or Specific Resource . . . . . . . . . . . . . . 66 139 13.5 Node in Same Domain . . . . . . . . . . . . . . . . . . . . 66 140 14. Compliance Requirements . . . . . . . . . . . . . . . . . . 68 141 14.1 Servers . . . . . . . . . . . . . . . . . . . . . . . . . . 68 142 14.2 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . 68 143 Normative References . . . . . . . . . . . . . . . . . . . . 70 144 Informative References . . . . . . . . . . . . . . . . . . . 72 145 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 72 146 A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . . . . . 73 147 A.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 73 148 A.2 Character Repertoire . . . . . . . . . . . . . . . . . . . . 73 149 A.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 73 150 A.4 Normalization . . . . . . . . . . . . . . . . . . . . . . . 73 151 A.5 Prohibited Output . . . . . . . . . . . . . . . . . . . . . 74 152 A.6 Bidirectional Characters . . . . . . . . . . . . . . . . . . 75 153 B. Resourceprep . . . . . . . . . . . . . . . . . . . . . . . . 76 154 B.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . 76 155 B.2 Character Repertoire . . . . . . . . . . . . . . . . . . . . 76 156 B.3 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . 76 157 B.4 Normalization . . . . . . . . . . . . . . . . . . . . . . . 76 158 B.5 Prohibited Output . . . . . . . . . . . . . . . . . . . . . 77 159 B.6 Bidirectional Characters . . . . . . . . . . . . . . . . . . 77 160 C. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . 78 161 C.1 Stream namespace . . . . . . . . . . . . . . . . . . . . . . 78 162 C.2 Stream error namespace . . . . . . . . . . . . . . . . . . . 79 163 C.3 TLS namespace . . . . . . . . . . . . . . . . . . . . . . . 80 164 C.4 SASL namespace . . . . . . . . . . . . . . . . . . . . . . . 81 165 C.5 Dialback namespace . . . . . . . . . . . . . . . . . . . . . 82 166 C.6 Stanza error namespace . . . . . . . . . . . . . . . . . . . 83 167 D. Differences Between Jabber and XMPP . . . . . . . . . . . . 85 168 D.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . 85 169 D.2 Channel Encryption . . . . . . . . . . . . . . . . . . . . . 85 170 D.3 JID Processing . . . . . . . . . . . . . . . . . . . . . . . 85 171 D.4 Error Handling . . . . . . . . . . . . . . . . . . . . . . . 86 172 D.5 Internationalization . . . . . . . . . . . . . . . . . . . . 86 173 D.6 Stream Version Attribute . . . . . . . . . . . . . . . . . . 86 174 E. Revision History . . . . . . . . . . . . . . . . . . . . . . 87 175 E.1 Changes from draft-ietf-xmpp-core-17 . . . . . . . . . . . . 87 176 E.2 Changes from draft-ietf-xmpp-core-16 . . . . . . . . . . . . 87 177 E.3 Changes from draft-ietf-xmpp-core-15 . . . . . . . . . . . . 88 178 E.4 Changes from draft-ietf-xmpp-core-14 . . . . . . . . . . . . 88 179 E.5 Changes from draft-ietf-xmpp-core-13 . . . . . . . . . . . . 88 180 E.6 Changes from draft-ietf-xmpp-core-12 . . . . . . . . . . . . 88 181 E.7 Changes from draft-ietf-xmpp-core-11 . . . . . . . . . . . . 89 182 E.8 Changes from draft-ietf-xmpp-core-10 . . . . . . . . . . . . 89 183 E.9 Changes from draft-ietf-xmpp-core-09 . . . . . . . . . . . . 89 184 E.10 Changes from draft-ietf-xmpp-core-08 . . . . . . . . . . . . 89 185 E.11 Changes from draft-ietf-xmpp-core-07 . . . . . . . . . . . . 90 186 E.12 Changes from draft-ietf-xmpp-core-06 . . . . . . . . . . . . 90 187 E.13 Changes from draft-ietf-xmpp-core-05 . . . . . . . . . . . . 90 188 E.14 Changes from draft-ietf-xmpp-core-04 . . . . . . . . . . . . 90 189 E.15 Changes from draft-ietf-xmpp-core-03 . . . . . . . . . . . . 91 190 E.16 Changes from draft-ietf-xmpp-core-02 . . . . . . . . . . . . 91 191 E.17 Changes from draft-ietf-xmpp-core-01 . . . . . . . . . . . . 91 192 E.18 Changes from draft-ietf-xmpp-core-00 . . . . . . . . . . . . 91 193 E.19 Changes from draft-miller-xmpp-core-02 . . . . . . . . . . . 92 194 Intellectual Property and Copyright Statements . . . . . . . 94 196 1. Introduction 198 1.1 Overview 200 The Extensible Messaging and Presence Protocol (XMPP) is an open XML 201 [1] protocol for near-real-time messaging, presence, and 202 request-response services. The basic syntax and semantics were 203 developed originally within the Jabber open-source community, mainly 204 in 1999. In 2002, the XMPP WG was chartered with developing an 205 adaptation of the Jabber protocol that would be suitable as an IETF 206 instant messaging (IM) and presence technology. As a result of work 207 by the XMPP WG, the current document defines the core features of 208 XMPP; XMPP IM [20] defines the extensions required to provide the 209 instant messaging and presence functionality defined in RFC 2779 [2]. 211 1.2 Terminology 213 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 214 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 215 "OPTIONAL" in this document are to be interpreted as described in RFC 216 2119 [3]. 218 1.3 Discussion Venue 220 The authors welcome discussion and comments related to the topics 221 presented in this document. The preferred forum is the 222 mailing list, for which archives and subscription 223 information are available at . 226 1.4 Intellectual Property Notice 228 This document is in full compliance with all provisions of Section 10 229 of RFC 2026. Parts of this specification use the term "jabber" for 230 identifying namespaces and other protocol syntax. Jabber[tm] is a 231 registered trademark of Jabber, Inc. Jabber, Inc. grants permission 232 to the IETF for use of the Jabber trademark in association with this 233 specification and its successors, if any. 235 2. Generalized Architecture 237 2.1 Overview 239 Although XMPP is not wedded to any specific network architecture, to 240 this point it usually has been implemented via a typical 241 client-server architecture, wherein a client utilizing XMPP accesses 242 a server over a TCP [4] socket. 244 The following diagram provides a high-level overview of this 245 architecture (where "-" represents communications that use XMPP and 246 "=" represents communications that use any other protocol). 248 C1 - S1 - S2 - C3 249 / \ 250 C2 - G1 = FN1 = FC1 252 The symbols are as follows: 254 o C1, C2, C3 -- XMPP clients 256 o S1, S2 -- XMPP servers 258 o G1 -- A gateway that translates between XMPP and the protocol(s) 259 used on a foreign (non-XMPP) messaging network 261 o FN1 -- A foreign messaging network 263 o FC1 -- A client on a foreign messaging network 265 2.2 Server 267 A server acts as an intelligent abstraction layer for XMPP 268 communications. Its primary responsibilities are to manage 269 connections from or sessions for other entities (in the form of XML 270 streams (Section 4) to and from authorized clients, servers, and 271 other entities) and to route appropriately-addressed XML stanzas 272 (Section 8) among such entities over XML streams. Most XMPP-compliant 273 servers also assume responsibility for the storage of data that is 274 used by clients (e.g., contact lists for users of XMPP-based instant 275 messaging and presence applications); in this case, the XML data is 276 processed directly by the server itself on behalf of the client and 277 is not routed to another entity. Compliant server implementations 278 MUST ensure in-order processing of XML stanzas between any two 279 entities. 281 2.3 Client 283 Most clients connect directly to a server over a TCP socket and use 284 XMPP to take full advantage of the functionality provided by a server 285 and any associated services. Although there is no necessary coupling 286 of an XML stream to a TCP socket (e.g., a client COULD connect via 287 HTTP [21] polling or some other mechanism), this specification 288 defines a binding of XMPP to TCP only. Multiple resources (e.g., 289 devices or locations) MAY connect simultaneously to a server on 290 behalf of each authorized client, with each resource connecting over 291 a discrete TCP socket and differentiated by the resource identifier 292 of a JID (e.g., vs. ) as defined 293 under Addressing Scheme (Section 3). The port registered with the 294 Internet Assigned Numbers Authority (IANA) [5] for connections 295 between a client and a server is 5222 (see IANA Considerations 296 (Section 10)). 298 2.4 Gateway 300 A gateway is a special-purpose server-side service whose primary 301 function is to translate XMPP into the protocol used by a foreign 302 (non-XMPP) messaging system, as well as to translate the return data 303 back into XMPP. Examples are gateways to Internet Relay Chat (IRC), 304 Short Message Service (SMS), SMTP, and legacy instant messaging 305 networks such as AIM, ICQ, MSN Messenger, and Yahoo! Instant 306 Messenger. Communications between gateways and servers, and between 307 gateways and the foreign messaging system, are not defined in this 308 document. 310 2.5 Network 312 Because each server is identified by a network address and because 313 server-to-server communications are a straightforward extension of 314 the client-to-server protocol, in practice the system consists of a 315 network of servers that inter-communicate. Thus user-a@domain1 is 316 able to exchange messages, presence, and other information with 317 user-b@domain2. This pattern is familiar from messaging protocols 318 (such as SMTP) that make use of network addressing standards. 319 Communications between any two servers are OPTIONAL; if enabled, such 320 communications occur over XML streams that are normally bound to TCP 321 sockets, using port 5269 as registered with the IANA (see IANA 322 Considerations (Section 10)). 324 3. Addressing Scheme 326 3.1 Overview 328 An entity is anything that can be considered a network endpoint 329 (i.e., an ID on the network) and that can communicate using XMPP. All 330 such entities are uniquely addressable in a form that is consistent 331 with RFC 2396 [22]. For historical reasons, the address of such an 332 entity is called a Jabber Identifier or JID. A valid JID contains a 333 set of ordered elements formed of a domain identifier, node 334 identifier, and resource identifier in the following format: 335 [node@]domain[/resource]. Each allowable portion of a JID (node 336 identifier, domain identifier, and resource identifier) may be up to 337 1023 bytes in length, resulting in a maximum total size (including 338 the '@' and '/' separators) of 3071 bytes. 340 All JIDs are based on the foregoing structure. The most common use of 341 this structure is to identify an instant messaging user, the server 342 to which the user connects, and the user's active session or 343 connection (e.g., a specific client) in the form of . However, node types other than clients are possible; for 345 example, a specific chat room offered by a multi-user chat service 346 could be addressed as (where "room" is the name of the 347 chat room and "service" is the hostname of the multi-user chat 348 service) and a specific occupant of such a room could be addressed as 349 (where "nick" is the occupant's room nickname). 350 Many other JID types are possible (e.g., could be a 351 server-side script or service). 353 3.2 Domain Identifier 355 The domain identifier is the primary identifier and is the only 356 REQUIRED element of a JID (a mere domain identifier is a valid JID). 357 It usually represents the network gateway or "primary" server to 358 which other entities connect for XML routing and data management 359 capabilities. However, the entity referenced by a domain identifier 360 is not always a server, and may be a service that is addressed as a 361 subdomain of a server and that provides functionality above and 362 beyond the capabilities of a server (e.g., a multi-user chat service, 363 a user directory, or a gateway to a foreign messaging system). 365 The domain identifier for every server or service that will 366 communicate over a network SHOULD resolve to a Fully Qualified Domain 367 Name. A domain identifier MUST conform to RFC 952 [6] and RFC 1123 368 [7]. In addition, a domain identifier MUST be no more than 1023 bytes 369 in length and MUST conform to the Nameprep [8] profile of stringprep 370 [9]. 372 3.3 Node Identifier 374 The node identifier is an optional secondary identifier placed before 375 the domain identifier and separated from the latter by the '@' 376 character. It usually represents the entity requesting and using 377 network access provided by the server or gateway (i.e., a client), 378 although it can also represent other kinds of entities (e.g., a chat 379 room associated with a multi-user chat service). The entity 380 represented by a node identifier is addressed within the context of a 381 specific domain; within instant messaging and presence applications 382 of XMPP this address is called a "bare JID" and is of the form 383 . 385 A node identifier MUST be no more than 1023 bytes in length and MUST 386 conform to the Nodeprep (Appendix A) profile of stringprep [9]. 388 3.4 Resource Identifier 390 The resource identifier is an optional tertiary identifier placed 391 after the domain identifier and separated from the latter by the '/' 392 character. A resource identifier may modify either a or 393 mere address. It usually represents a specific session, 394 connection (e.g., a device or location), or object (e.g., a 395 participant in a multi-user chat room) belonging to the entity 396 associated with a node identifier. A resource identifier is opaque to 397 both servers and other clients, and is typically defined by a client 398 implementation when it provides the information necessary to complete 399 stream authentication (Section 6). An entity may maintain multiple 400 resources simultaneously. 402 A resource identifier MUST be no more than 1023 bytes in length and 403 MUST conform to the Resourceprep (Appendix B) profile of stringprep 404 [9]. 406 4. XML Streams 408 4.1 Overview 410 Two fundamental concepts make possible the rapid, asynchronous 411 exchange of relatively small payloads of structured information 412 between presence-aware entities: XML streams and XML stanzas. These 413 terms may be defined as follows: 415 Definition of XML Stream: An XML stream is a container for the 416 exchange of XML elements between any two entities over a network. 417 An XML stream is negotiated from an initiating entity (usually a 418 client or server) to a receiving entity (usually a server), 419 normally over a TCP socket, and corresponds to the initiating 420 entity's "session" with the receiving entity. The start of the XML 421 stream is denoted unambiguously by an opening XML tag 422 (with appropriate attributes and namespace declarations), while 423 the end of the XML stream is denoted unambiguously by a closing 424 XML tag. An XML stream is unidirectional; in order to 425 enable bidirectional information exchange, the initiating entity 426 and receiving entity MUST negotiate one stream in each direction 427 (the "initial stream" and the "response stream"), normally over 428 the same TCP connection. 430 Definition of XML Stanza: An XML stanza is a discrete semantic unit 431 of structured information that is sent from one entity to another 432 over an XML stream. An XML stanza exists at the direct child level 433 of the root element and is said to be well-balanced if 434 it matches production [43] content of the XML specification [1]). 435 The start of any XML stanza is denoted unambiguously by the 436 element start tag at depth=1 of the XML stream (e.g., ), 437 and the end of any XML stanza is denoted unambiguously by the 438 corresponding close tag at depth=1 (e.g., ). An XML 439 stanza MAY contain child elements (with accompanying attributes, 440 elements, and CDATA) as necessary in order to convey the desired 441 information. An XML element sent for the purpose of stream 442 encryption, stream authentication, or server dialback is not 443 considered to be an XML stanza. 445 Consider the example of a client's session with a server. In order to 446 connect to a server, a client MUST initiate an XML stream by sending 447 an opening tag to the server, optionally preceded by a text 448 declaration specifying the XML version supported and the character 449 encoding (see also Character Encoding (Section 9.5)). The server 450 SHOULD then reply with a second XML stream back to the client, again 451 optionally preceded by a text declaration. Once the client has 452 authenticated with the server (see Section 6), the client MAY send an 453 unlimited number of XML stanzas over the stream to any recipient on 454 the network. When the client desires to close the stream, it simply 455 sends a closing tag to the server (alternatively, the 456 stream may be closed by the server), after which both the client and 457 server SHOULD close the underlying TCP connection as well. 459 Those who are accustomed to thinking of XML in a document-centric 460 manner may wish to view a client's session with a server as 461 consisting of two open-ended XML documents: one from the client to 462 the server and one from the server to the client. From this 463 perspective, the root element can be considered the 464 document entity for each "document", and the two "documents" are 465 built up through the accumulation of XML stanzas sent over the two 466 XML streams. However, this perspective is a convenience only, and 467 XMPP does not deal in documents but in XML streams and XML stanzas. 469 In essence, then, an XML stream acts as an envelope for all the XML 470 stanzas sent during a session. We can represent this graphically as 471 follows: 473 |--------------------| 474 | | 475 |--------------------| 476 | | 477 | | 478 | | 479 |--------------------| 480 | | 481 | | 482 | | 483 |--------------------| 484 | | 485 | | 486 | | 487 |--------------------| 488 | ... | 489 |--------------------| 490 | | 491 |--------------------| 493 4.2 Stream Attributes 495 The attributes of the stream element are as follows: 497 o to -- The 'to' attribute SHOULD be used only in the XML stream 498 header from the initiating entity to the receiving entity, and 499 MUST be set to the JID of the receiving entity. There SHOULD be no 500 'to' attribute set in the XML stream header by which the receiving 501 entity replies to the initiating entity; however, if a 'to' 502 attribute is included, it SHOULD be silently ignored by the 503 initiating entity. 505 o from -- The 'from' attribute SHOULD be used only in the XML stream 506 header from the receiving entity to the initiating entity, and 507 MUST be set to the JID of the receiving entity granting access to 508 the initiating entity. There SHOULD be no 'from' attribute on the 509 XML stream header sent from the initiating entity to the receiving 510 entity; however, if a 'from' attribute is included, it SHOULD be 511 silently ignored by the receiving entity. 513 o id -- The 'id' attribute SHOULD be used only in the XML stream 514 header from the receiving entity to the initiating entity. This 515 attribute is a unique identifier created by the receiving entity 516 to function as a session key for the initiating entity's streams 517 with the receiving entity, and MUST be unique within the receiving 518 application (normally a server). There SHOULD be no 'id' attribute 519 on the XML stream header sent from the initiating entity to the 520 receiving entity; however, if an 'id' attribute is included, it 521 SHOULD be silently ignored by the receiving entity. 523 o version -- The presence of the version attribute set to a value of 524 "1.0" signals support for the stream features defined in this 525 specification. Detailed rules regarding generation and handling of 526 this attribute are defined below. 528 We can summarize as follows: 530 | initiating to receiving | receiving to initiating 531 ------------------------------------------------------------ 532 to | hostname of receiver | silently ignored 533 from | silently ignored | hostname of receiver 534 id | silently ignored | session key 535 version | signals XMPP 1.0 support | signals XMPP 1.0 support 537 4.2.1 Version Support 539 The following rules apply to the generation and handling of the 540 'version' attribute: 542 1. If the initiating entity complies with the XML streams protocol 543 defined herein (including Stream Encryption (Section 5), Stream 544 Authentication (Section 6), and Stream Errors (Section 4.6)), it 545 MUST include the 'version' attribute in the XML stream header it 546 sends to the receiving entity, and it MUST set the value of the 547 'version' attribute to "1.0". 549 2. If the initiating entity includes the 'version' attribute set to 550 a value of "1.0" in its stream header and the receiving entity 551 supports XMPP 1.0, the receiving entity MUST reciprocate by 552 including the 'version' attribute set to a value of "1.0" in its 553 stream header response. 555 3. If the initiating entity does not include the 'version' attribute 556 in its stream header, the receiving entity still SHOULD include 557 the 'version' attribute set to a value of "1.0" in its stream 558 header response. 560 4. If the initiating entity includes the 'version' attribute set to 561 a value other than "1.0", the receiving entity SHOULD include the 562 'version' attribute set to a value of "1.0" in its stream header 563 response, but MAY at its discretion generate an 564 stream error and terminate the XML stream 565 and underlying TCP connection. 567 5. If the receiving entity includes the 'version' attribute set to a 568 value other than "1.0" in its stream header response, the 569 initiating entity SHOULD generate an 570 stream error and terminate the XML stream and underlying TCP 571 connection. 573 4.3 Namespace Declarations 575 The stream element MUST possess both a stream namespace declaration 576 and a default namespace declaration (as "namespace declaration" is 577 defined in the XML namespaces specification [10]). For detailed 578 information regarding the stream namespace and default namespace, see 579 Namespace Names and Prefixes (Section 9.2). 581 4.4 Stream Features 583 If the initiating entity includes the 'version' attribute set to a 584 value of "1.0" in its initiating stream element, the receiving entity 585 MUST send a child element (prefixed by the stream 586 namespace prefix) to the initiating entity in order to announce any 587 stream-level features that can be negotiated (or capabilities that 588 otherwise need to be advertised). Currently this is used for TLS and 589 SASL negotiation only, but it could be used for other negotiable 590 features in the future (usage is defined under Stream Encryption 591 (Section 5) and Stream Authentication (Section 6) below). If an 592 entity does not understand or support some features, it SHOULD 593 silently ignore them. 595 4.5 Stream Encryption and Authentication 597 XML streams in XMPP 1.0 SHOULD be encrypted as defined under Stream 598 Encryption (Section 5) and MUST be authenticated as defined under 599 Stream Authentication (Section 6). If the initiating entity attempts 600 to send an XML stanza before the stream is authenticated, the 601 receiving entity SHOULD return a stream error to 602 the initiating entity and then terminate both the XML stream and the 603 underlying TCP connection. 605 4.6 Stream Errors 607 The root stream element MAY contain an child element that is 608 prefixed by the stream namespace prefix. The error child MUST be sent 609 by a compliant entity (usually a server rather than a client) if it 610 perceives that a stream-level error has occurred. 612 4.6.1 Rules 614 The following rules apply to stream-level errors: 616 o It is assumed that all stream-level errors are unrecoverable; 617 therefore, if an error occurs at the level of the stream, the 618 entity that detects the error MUST send a stream error to the 619 other entity, send a closing tag, and terminate the 620 underlying TCP connection. 622 o If the error occurs while the stream is being set up, the 623 receiving entity MUST still send the opening tag, include 624 the element as a child of the stream element, send the 625 closing tag, and terminate the underlying TCP 626 connection. In this case, if the initiating entity provides an 627 unknown host in the 'to' attribute (or provides no 'to' attribute 628 at all), the server SHOULD provide the server's authoritative 629 hostname in the 'from' attribute of the stream header sent before 630 termination. 632 4.6.2 Syntax 634 The syntax for stream errors is as follows: 636 637 638 639 OPTIONAL descriptive text 640 641 [OPTIONAL application-specific condition element] 643 645 The element: 647 o MUST contain a child element corresponding to one of the defined 648 stanza error conditions defined below; this element MUST be 649 qualified by the 'urn:ietf:params:xml:ns:xmpp-streamstreams' 650 namespace 652 o MAY contain a child containing CDATA that describes the 653 error in more detail; this element MUST be qualified by the 654 'urn:ietf:params:xml:ns:xmpp-streams' namespace and SHOULD possess 655 an 'xml:lang' attribute 657 o MAY contain a child element for an application-specific error 658 condition; this element MUST be qualified by an 659 application-defined namespace, and its structure is defined by 660 that namespace 662 The element is OPTIONAL. If included, it SHOULD be used only 663 to provide descriptive or diagnostic information that supplements the 664 meaning of a defined condition or application-specific condition. It 665 SHOULD NOT be interpreted programmatically by an application. It 666 SHOULD NOT be used as the error message presented to user, but MAY be 667 shown in addition to the error message associated with the included 668 condition element (or elements). 670 Note: the XML namespace name 'urn:ietf:params:xml:ns:xmpp-streams' 671 that qualifies the descriptive element adheres to the format defined 672 in The IETF XML Registry [23]. 674 4.6.3 Defined Conditions 676 The following stream-level error conditions are defined: 678 o -- the entity has sent XML that cannot be processed; 679 this error may be used rather than more specific XML-related 680 errors such as , , 681 , , and 682 , although the more specific errors are 683 preferred. 685 o -- the entity has sent a namespace prefix 686 that is unsupported, or has sent no namespace prefix on an element 687 that requires such a prefix (see the XML Namespace Names and 688 Prefixes (Section 9.2) section of this document). 690 o -- the server is closing the active stream for this 691 entity because a new stream has been initiated that conflicts with 692 the existing stream. 694 o -- the entity has not generated any traffic 695 over the stream for some period of time (configurable according to 696 a local service policy). 698 o -- the value of the 'to' attribute provided by the 699 initiating entity in the stream header corresponds to a hostname 700 that is no longer hosted by the server. 702 o -- the value of the 'to' attribute provided by the 703 initiating entity in the stream header does not correspond to a 704 hostname that is hosted by the server. 706 o -- a stanza sent between two servers lacks 707 a 'to' or 'from' attribute (or the attribute has no value). 709 o -- the server has experienced a 710 misconfiguration or an otherwise-undefined internal error that 711 prevents it from servicing the stream. 713 o -- the stream ID or dialback ID is invalid or does 714 not match an ID previously provided. 716 o -- the stream namespace name is something 717 other than "http://etherx.jabber.org/streams" or the dialback 718 namespace name is something other than "jabber:server:dialback" 719 (see the XML Namespace Names and Prefixes (Section 9.2) section of 720 this document). 722 o -- the entity has sent invalid XML over the stream 723 to a server that performs validation (see the Validation (Section 724 9.3) section of this document). 726 o -- the hostname provided in a 'from' address 727 does not match the hostname (or other validated domain) negotiated 728 via SASL or dialback. 730 o -- the entity has attempted to send data before 731 authenticating, or otherwise is not authorized to perform an 732 action related to stream negotiation; the receiving entity SHOULD 733 silently drop the offending stanza and MUST NOT process it before 734 sending the stream error. 736 o -- the entity has violated some local service 737 policy; the server MAY choose to specify the policy in the 738 element. 740 o -- the server is unable to properly 741 connect to a remote resource that is required for authentication 742 or authorization. 744 o -- the server is resource-constrained and 745 is unable to service the stream. 747 o -- the entity has attempted to send a comment, 748 processing instruction, DTD, entity reference, or unescaped 749 character (see the Restrictions (Section 9.1) section of this 750 document). 752 o -- the server will not provide service to the 753 initiating entity but is redirecting traffic to another host; the 754 server SHOULD specify the alternate hostname or IP address in the 755 element. 757 o -- the server is being shut down and all active 758 streams are being closed. 760 o -- the error condition is not one of those 761 defined by the other conditions in this list; this error condition 762 SHOULD be used only in conjunction with an application-specific 763 condition. 765 o -- the initiating entity has encoded the 766 stream in an encoding that is not supported by the server (see the 767 Character Encoding (Section 9.5) section of this document). 769 o -- the initiating entity has sent a 770 first-level child of the stream that is not supported by the 771 server. 773 o -- the value of the 'version' attribute 774 provided by the initiating entity in the stream header specifies a 775 version of XMPP that is not supported by the server; the server 776 MAY specify the version(s) it supports in the element. 778 o -- the initiating entity has sent XML that 779 is not well-formed as defined by the XML specification [1]. 781 4.6.4 Application-Specific Conditions 783 As noted, an application MAY provide application-specific stream 784 error information by including a properly-namespaced child in the 785 error element. The application-specific element SHOULD supplement or 786 further qualify a defined element. Thus the element will 787 contain two or three child elements: 789 790 792 793 Some special application diagnostic information! 794 795 796 797 799 4.7 Simple Streams Example 801 The following is a stream-based session of a client on a server 802 (where the "C" lines are sent from the client to the server, and the 803 "S" lines are sent from the server to the client): 805 A basic session: 807 C: 808 813 S: 814 820 ... authentication ... 821 C: 824 C: Art thou not Romeo, and a Montague? 825 C: 826 S: 829 S: Neither, fair saint, if either thee dislike. 830 S: 831 C: 832 S: 833 A stream gone bad: 835 C: 836 841 S: 842 848 ... authentication ... 849 C: 850 Bad XML, no closing body tag! 851 852 S: 853 855 856 S: 858 5. Stream Encryption 860 5.1 Overview 862 XMPP includes a method for securing the stream from tampering and 863 eavesdropping. This channel encryption method makes use of the 864 Transport Layer Security (TLS) [11] protocol, along with a "STARTTLS" 865 extension that is modelled after similar extensions for the IMAP 866 [24], POP3 [25], and ACAP [26] protocols as described in RFC 2595 867 [27]. The namespace name for the STARTTLS extension is 868 'urn:ietf:params:xml:ns:xmpp-tls', which adheres to the format 869 defined in The IETF XML Registry [23]. 871 An administrator of a given domain MAY require the use of TLS for 872 client-to-server communications, server-to-server communications, or 873 both. Servers SHOULD use TLS between two domains for the purpose of 874 securing server-to-server communications. See Mandatory to Implement 875 Technologies (Section 12.6) regarding mechanisms that MUST be 876 supported. 878 The following rules apply: 880 1. An initiating entity that complies with this specification MUST 881 include the 'version' attribute set to a value of "1.0" in the 882 initiating stream header. 884 2. If the TLS negotiation occurs between two servers, 885 communications MUST NOT proceed until the DNS hostnames asserted 886 by the servers have been resolved (see Server-to-Server 887 Communications (Section 12.3)). 889 3. When a receiving entity that complies with this specification 890 receives an initiating stream header that includes the 'version' 891 attribute set to a value of "1.0", after sending a stream header 892 in reply (including the version flag) it MUST include a 893 element (qualified by the 894 'urn:ietf:params:xml:ns:xmpp-tls' namespace) along with the list 895 of other stream features it supports. 897 4. If the initiating entity chooses to use TLS for stream 898 encryption, TLS negotiation MUST be completed before proceeding 899 to SASL negotiation. 901 5. The receiving entity MUST consider the TLS negotiation to have 902 begun immediately after sending the closing ">" of the element. The initiating entity MUST consider the TLS 904 negotiation to have begun immediately after receiving the 905 closing ">" of the element from the receiving entity. 907 6. The initiating entity MUST validate the certificate presented by 908 the receiving entity; there are two cases: 910 Case 1 -- The initiating entity has been configured with a set 911 of trusted root certificates: Normal certificate validation 912 processing is appropriate, and SHOULD follow the rules 913 defined for HTTP over TLS [12]. The trusted roots may be 914 either a well-known public set or a manually configured Root 915 CA (e.g., an organization's own Certificate Authority or a 916 self-signed Root CA for the service as described under High 917 Security (Section 12.1)). This case is RECOMMENDED. 919 Case 2 -- The initiating entity has been configured with the 920 receiving entity's self-signed service certificate: Simple 921 comparison of public keys is appropriate. This case is NOT 922 RECOMMENDED (see High Security (Section 12.1) for details). 924 If the above methods fail, the certificate SHOULD be presented 925 to a human (e.g., an end user or server administrator) for 926 approval; if presented, the receiver MUST deliver the entire 927 certificate chain to the human, who SHOULD be given the option 928 to store the Root CA certificate (not the service or End Entity 929 certificate) and to not be queried again regarding acceptance of 930 the certificate for some reasonable period of time. 932 7. If the TLS negotiation is successful, the receiving entity MUST 933 discard any knowledge obtained from the initiating entity before 934 TLS takes effect. 936 8. If the TLS negotiation is successful, the initiating entity MUST 937 discard any knowledge obtained from the receiving entity before 938 TLS takes effect. 940 9. If the TLS negotiation is successful, the receiving entity MUST 941 NOT offer the STARTTLS extension to the initiating entity along 942 with the other stream features that are offered when the stream 943 is restarted. 945 10. If the TLS negotiation is successful, the initiating entity 946 SHOULD continue with SASL negotiation. 948 11. If the TLS negotiation results in failure, the receiving entity 949 MUST terminate both the XML stream and the underlying TCP 950 connection. 952 5.2 Narrative 954 When an initiating entity secures a stream with a receiving entity, 955 the steps involved are as follows: 957 1. The initiating entity opens a TCP connection and initiates the 958 stream by sending the opening XML stream header to the receiving 959 entity, including the 'version' attribute set to a value of 960 "1.0". 962 2. The receiving entity responds by opening a TCP connection and 963 sending an XML stream header to the initiating entity, including 964 the 'version' attribute set to a value of "1.0". 966 3. The receiving entity offers the STARTTLS extension to the 967 initiating entity by including it with the list of other 968 supported stream features (if TLS is required for interaction 969 with the receiving entity, it SHOULD signal that fact by 970 including a element as a child of the 971 element). 973 4. The initiating entity issues the STARTTLS command (i.e., a 974 element qualified by the 975 'urn:ietf:params:xml:ns:xmpp-tls' namespace) to instruct the 976 receiving entity that it wishes to begin a TLS negotiation to 977 secure the stream. 979 5. The receiving entity MUST reply with either a element 980 or a element qualified by the 981 'urn:ietf:params:xml:ns:xmpp-tls' namespace. If the failure case 982 occurs, the receiving entity MUST terminate both the XML stream 983 and the underlying TCP connection. If the proceed case occurs, 984 the receiving entity MUST ignore any further XML data sent over 985 the XML stream but keep the underlying TCP connection open for 986 the purpose of completing the TLS negotiation. 988 6. The initiating entity and receiving entity attempt to complete a 989 TLS negotiation in accordance with RFC 2246 [11]. 991 7. If the TLS negotiation is unsuccessful, the receiving entity MUST 992 terminate the TCP connection. If the TLS negotiation is 993 successful, the initiating entity MUST initiate a new stream by 994 sending an opening XML stream header to the receiving entity. 996 8. Upon receiving the new stream header from the initiating entity, 997 the receiving entity MUST respond by sending a new XML stream 998 header to the initiating entity along with the remaining 999 available features (but NOT including the STARTTLS feature). 1001 5.3 Client-to-Server Example 1003 The following example shows the data flow for a client securing a 1004 stream using STARTTLS (the IANA-registered port 5222 SHOULD be used; 1005 see IANA Considerations (Section 10)). 1007 Step 1: Client initiates stream to server: 1009 1015 Step 2: Server responds by sending a stream tag to client: 1017 1024 Step 3: Server sends the STARTTLS extension to client along with 1025 authentication mechanisms and any other stream features: 1027 1028 1029 1030 1031 1032 DIGEST-MD5 1033 PLAIN 1034 1035 1037 Step 4: Client sends the STARTTLS command to server: 1039 1041 Step 5: Server informs client to proceed: 1043 1045 Step 5 (alt): Server informs client that TLS negotiation has failed 1046 and closes both stream and TCP connection: 1048 1049 1051 Step 6: Client and server attempt to complete TLS negotiation over 1052 the existing TCP connection. 1054 Step 7: If TLS negotiation is successful, client initiates a new 1055 stream to server: 1057 1063 Step 7 (alt): If TLS negotiation is unsuccessful, server MUST close 1064 TCP connection. 1066 Step 8: Server responds by sending a stream header to client along 1067 with any remaining negotiable stream features: 1069 1075 1076 1077 DIGEST-MD5 1078 PLAIN 1079 EXTERNAL 1080 1081 1083 Step 9: Client SHOULD continue with Stream Authentication (Section 1084 6). 1086 5.4 Server-to-Server Example 1088 The following example shows the data flow for two servers securing a 1089 stream using STARTTLS (the IANA-registered port 5269 SHOULD be used; 1090 see IANA Considerations (Section 10)). 1092 Step 1: Server1 initiates stream to Server2: 1094 1100 Step 2: Server2 responds by sending a stream tag to Server1: 1102 1109 Step 3: Server2 sends the STARTTLS extension to Server1 along with 1110 authentication mechanisms and any other stream features: 1112 1113 1114 1115 1116 1117 DIGEST-MD5 1118 KERBEROS_V4 1119 1120 1122 Step 4: Server1 sends the STARTTLS command to Server2: 1124 1126 Step 5: Server2 informs Server1 to proceed: 1128 1130 Step 5 (alt): Server2 informs Server1 that TLS negotiation has failed 1131 and closes stream: 1133 1134 1136 Step 6: Server1 and Server2 attempt to complete TLS negotiation via 1137 TCP. 1139 Step 7: If TLS negotiation is successful, Server1 initiates a new 1140 stream to Server2: 1142 1148 Step 7 (alt): If TLS negotiation is unsuccessful, server MUST close 1149 TCP connection. 1151 Step 8: Server2 responds by sending a stream header to Server1 along 1152 with any remaining negotiable stream features: 1154 1160 1161 1162 DIGEST-MD5 1163 KERBEROS_V4 1164 EXTERNAL 1165 1166 1168 Step 9: Server1 SHOULD continue with Stream Authentication (Section 1169 6). 1171 6. Stream Authentication 1173 6.1 Overview 1175 XMPP includes a method for authenticating a stream using an XMPP 1176 adaptation of the Simple Authentication and Security Layer (SASL) 1177 [13]. SASL provides a generalized method for adding authentication 1178 support to connection-based protocols, and XMPP uses a generic XML 1179 namespace profile for SASL that conforms to section 4 ("Profiling 1180 Requirements") of RFC 2222 [13] (the XMPP-specific namespace name is 1181 'urn:ietf:params:xml:ns:xmpp-sasl', which adheres to the format 1182 defined in The IETF XML Registry [23]). Finally, see Mandatory to 1183 Implement Technologies (Section 12.6) regarding mechanisms that MUST 1184 be supported. 1186 The following rules apply: 1188 1. If the SASL negotiation occurs between two servers, 1189 communications MUST NOT proceed until the DNS hostnames asserted 1190 by the servers have been resolved (see Server-to-Server 1191 Communications (Section 12.3)). 1193 2. If TLS is used for stream encryption, SASL SHOULD NOT be used for 1194 anything except stream authentication (i.e., a security layer 1195 SHOULD NOT be negotiated using SASL). Conversely, if a security 1196 layer is to be negotiated via SASL, TLS SHOULD NOT be used. 1198 3. If the initiating entity is capable of authenticating via SASL, 1199 it MUST include the 'version' attribute set to a value of "1.0" 1200 in the initiating stream header. 1202 4. If the receiving entity is capable of negotiating authentication 1203 via SASL, it MUST send one or more authentication mechanisms 1204 within a element qualified by the 1205 'urn:ietf:params:xml:ns:xmpp-sasl' namespace in response to the 1206 opening stream tag received from the initiating entity (if the 1207 opening stream tag included the 'version' attribute set to a 1208 value of "1.0"). 1210 5. Upon successful SASL negotiation that involves negotiation of a 1211 security layer, the receiving entity MUST discard any knowledge 1212 obtained from the initiating entity which was not obtained from 1213 the SASL negotiation itself. 1215 6. Upon successful SASL negotiation that involves negotiation of a 1216 security layer, the initiating entity MUST discard any knowledge 1217 obtained from the receiving entity which was not obtained from 1218 the SASL negotiation itself. 1220 7. The initiating entity MUST provide an authzid during SASL 1221 negotiation. The authzid-value MUST be a valid JID of the form 1222 (i.e., a domain identifier only) for servers and of the 1223 form (i.e., node identifier, domain 1224 identifier, and resource identifier) for clients. The initiating 1225 entity MAY process the authzid-value in accordance with the rules 1226 defined in Addressing Scheme (Section 3) before providing it to 1227 the receiving entity, but is NOT REQUIRED to do so; however, the 1228 receiving entity MUST verify that the authzid-value provided by 1229 the initiating entity conforms to the rules defined therein. 1231 8. Any character data contained within the XML elements used during 1232 SASL negotiation MUST be encoded using base64. 1234 6.2 Narrative 1236 When an initiating entity authenticates with a receiving entity, the 1237 steps involved are as follows: 1239 1. The initiating entity requests SASL authentication by including 1240 the 'version' attribute in the opening XML stream header sent to 1241 the receiving entity, with the value set to "1.0". 1243 2. After sending an XML stream header in response, the receiving 1244 entity sends a list of available SASL authentication mechanisms; 1245 each of these is a element included as a child 1246 within a container element qualified by the 1247 'urn:ietf:params:xml:ns:xmpp-sasl' namespace, which in turn is a 1248 child of a element in the streams namespace. If 1249 channel encryption needs to be established before a particular 1250 authentication mechanism may be used, the receiving entity MUST 1251 NOT provide that mechanism in the list of available SASL 1252 authentication methods prior to channel encryption. If the 1253 initiating entity presents a valid certificate during prior TLS 1254 negotiation, the receiving entity MAY offer the SASL EXTERNAL 1255 mechanism to the initiating entity during stream authentication 1256 (refer to RFC 2222 [13]). 1258 3. The initiating entity selects a mechanism by sending an 1259 element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' 1260 namespace to the receiving entity and including an appropriate 1261 value for the 'mechanism' attribute; this element MAY optionally 1262 contain character data (in SASL terminology the "initial 1263 response") if the mechanism supports or requires it. If the 1264 initiating entity selects the EXTERNAL mechanism for 1265 authentication, the authentication credentials shall be taken 1266 from the certificate presented during prior TLS negotiation. 1268 4. If necessary, the receiving entity challenges the initiating 1269 entity by sending a element qualified by the 1270 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating 1271 entity; this element MAY optionally contain character data (which 1272 MUST be computed in accordance with the SASL mechanism chosen by 1273 the initiating entity). 1275 5. The initiating entity responds to the challenge by sending a 1276 element qualified by the 1277 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the receiving 1278 entity; this element MAY optionally contain character data (which 1279 MUST be computed in accordance with the SASL mechanism chosen by 1280 the initiating entity). 1282 6. If necessary, the receiving entity sends more challenges and the 1283 initiating entity sends more responses. 1285 This series of challenge/response pairs continues until one of three 1286 things happens: 1288 1. The initiating entity aborts the handshake by sending an 1289 element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' 1290 namespace to the receiving entity. Upon receiving the 1291 element, the receiving entity MUST terminate the TCP connection. 1293 2. The receiving entity reports failure of the handshake by sending 1294 a element qualified by the 1295 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating 1296 entity (the particular cause of failure SHOULD be communicated in 1297 an appropriate child element of the element as defined 1298 under SASL Errors (Section 6.3)). Immediately after sending the 1299 element, the receiving entity MUST terminate both the 1300 XML stream and the underlying TCP connection. 1302 3. The receiving entity reports success of the handshake by sending 1303 a element qualified by the 1304 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating 1305 entity; this element MAY optionally contain character data (in 1306 SASL terminology "additional data with success"). Upon receiving 1307 the element, the initiating entity MUST initiate a new 1308 stream by sending an opening XML stream header to the receiving 1309 entity (it is not necessary to send a closing 1310 element first, since the receiving entity and initiating entity 1311 MUST consider the original stream to be closed upon sending or 1312 receiving the element). Upon receiving the new stream 1313 header from the initiating entity, the receiving entity MUST 1314 respond by sending a new XML stream header to the initiating 1315 entity, along with any remaining available features (but NOT 1316 including the STARTTLS feature or any authentication mechanisms) 1317 or an empty features element (to signify that no additional 1318 features are available); note that any such additional features 1319 are not defined herein, and MUST be defined by the relevant 1320 extension to XMPP. 1322 6.3 SASL Errors 1324 The following SASL-related error conditions are defined: 1326 o -- The receiving entity acknowledges an 1327 element sent by the initiating entity; sent in response to the 1328 element. 1330 o -- The data provided by the initiating entity 1331 could not be processed, e.g. because does not adhere to the 1332 protocol for the requested mechanism; sent in response to the 1333 element. 1335 o -- The mechanism chosen by the initiating 1336 entity may be used only if the stream is already encrypted; sent 1337 in response to the element. 1339 o -- The authzid provided by the initiating 1340 entity is invalid, either because it is incorrectly formatted or 1341 because the initiating entity does not have permissions to 1342 authorize that ID; sent in response to a element. 1344 o -- The initiating entity did not provide a 1345 mechanism or requested a mechanism that is not supported by the 1346 receiving entity; sent in response to the element. 1348 o -- The realm provided by the initiating entity 1349 (in mechanisms that support the concept of a realm) does not match 1350 one of the hostnames served by the receiving entity; sent in 1351 response to a element. 1353 o -- The mechanism requested by the initiating 1354 entity is weaker than server policy permits for that initiating 1355 entity; sent in response to the element. 1357 o -- The authentication failed because the 1358 initiating entity did not provide valid credentials (this includes 1359 the case of an unknown username); sent in response to a element. 1362 o -- The authentication failed because of 1363 a temporary error condition within the receiving entity; sent in 1364 response to an element or element. 1366 6.4 SASL Definition 1368 Section 4 of the SASL specification [13] requires that the following 1369 information be supplied by a protocol definition: 1371 service name: "xmpp" 1373 initiation sequence: After the initiating entity provides an opening 1374 XML stream header and the receiving entity replies in kind, the 1375 receiving entity provides a list of acceptable authentication 1376 methods. The initiating entity chooses one method from the list 1377 and sends it to the receiving entity as the value of the 1378 'mechanism' attribute possessed by an element, optionally 1379 including an initial response to avoid a round trip. 1381 exchange sequence: Challenges and responses are carried through the 1382 exchange of elements from receiving entity to 1383 initiating entity and elements from initiating entity 1384 to receiving entity. The receiving entity reports failure by 1385 sending a element and success by sending a 1386 element; the initiating entity aborts the exchange by sending an 1387 element. (All of these elements are qualified by the 1388 'urn:ietf:params:xml:ns:xmpp-sasl' namespace.) Upon successful 1389 negotiation, both sides consider the original XML stream closed 1390 and new headers are sent by both entities. 1392 security layer negotiation: The security layer takes effect 1393 immediately after sending the closing ">" character of the 1394 element for the server, and immediately after receiving 1395 the closing ">" character of the element for the client 1396 (this element is qualified by the 1397 'urn:ietf:params:xml:ns:xmpp-sasl' namespace). 1399 use of the authorization identity: The authorization identity is used 1400 by xmpp to denote the "full JID" () of a 1401 client or the sending domain of a server. 1403 6.5 Client-to-Server Example 1405 The following example shows the data flow for a client authenticating 1406 with a server using SASL (the IANA-registered port 5222 SHOULD be 1407 used; see IANA Considerations (Section 10)). 1409 Step 1: Client initiates stream to server: 1411 1417 Step 2: Server responds with a stream tag sent to client: 1419 1426 Step 3: Server informs client of available authentication mechanisms: 1428 1429 1430 DIGEST-MD5 1431 PLAIN 1432 1433 1435 Step 4: Client selects an authentication mechanism: 1437 1441 Step 5: Server sends a base64-encoded challenge to client: 1443 1444 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 1445 xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz 1446 1448 The decoded challenge is: 1450 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ 1451 qop="auth",charset=utf-8,algorithm=md5-sess 1453 Step 5 (alt): Server returns error to client: 1455 1456 1458 1459 1461 Step 6: Client responds to the challenge: 1463 1464 dXNlcm5hbWU9InJvYiIscmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik 1465 9BNk1HOXRFUUdtMmhoIixjbm9uY2U9Ik9BNk1IWGg2VnFUclJrIixuYz0w 1466 MDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJ4bXBwL2NhdGFjbHlzbS 1467 5jeCIscmVzcG9uc2U9ZDM4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZjIxNDNh 1468 ZjcsY2hhcnNldD11dGYtOCxhdXRoemlkPSJyb2JAY2F0YWNseXNtLmN4L2 1469 15UmVzb3VyY2Ui 1470 1472 The decoded response is: 1474 username="rob",realm="cataclysm.cx",\ 1475 nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\ 1476 nc=00000001,qop=auth,digest-uri="xmpp/cataclysm.cx",\ 1477 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8,\ 1478 authzid="rob@cataclysm.cx/myResource" 1480 Step 7: Server sends another challenge to client: 1482 1483 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 1484 1486 The decoded challenge is: 1488 rspauth=ea40f60335c427b5527b84dbabcdfffd 1490 Step 7 (alt): Server returns error to client: 1492 1493 1494 1495 1497 Step 8: Client responds to the challenge: 1499 1501 Step 9: Server informs client of successful authentication: 1503 1504 Step 9 (alt): Server informs client of failed authentication: 1506 1507 1508 1509 1511 Step 10: Client initiates a new stream to server: 1513 1519 Step 11: Server responds by sending a stream header to client along 1520 with any additional features (or an empty features element): 1522 1528 1530 6.6 Server-to-Server Example 1532 The following example shows the data flow for a server authenticating 1533 with another server using SASL (the IANA-registered port 5269 SHOULD 1534 be used; see IANA Considerations (Section 10)). 1536 Step 1: Server1 initiates stream to Server2: 1538 1544 Step 2: Server2 responds with a stream tag sent to Server1: 1546 1553 Step 3: Server2 informs Server1 of available authentication 1554 mechanisms: 1556 1557 1558 DIGEST-MD5 1559 KERBEROS_V4 1560 1561 1563 Step 4: Server1 selects an authentication mechanism: 1565 1569 Step 5: Server2 sends a base64-encoded challenge to Server1: 1571 1572 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 1573 xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz 1574 1576 The decoded challenge is: 1578 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ 1579 qop="auth",charset=utf-8,algorithm=md5-sess 1581 Step 5 (alt): Server2 returns error to Server1: 1583 1584 1585 1586 1588 Step 6: Server1 responds to the challenge: 1590 1591 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 1592 xjbm9uY2U9Ik9BNk1IWGg2VnFUclJrIixuYz0wMDAwMDAwMSxxb3A9YXV0 1593 aCxkaWdlc3QtdXJpPSJ4bXBwL2NhdGFjbHlzbS5jeCIscmVzcG9uc2U9ZD 1594 M4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcsY2hhcnNldD11dGYt 1595 OAo= 1596 1598 The decoded response is: 1600 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\ 1601 nc=00000001,qop=auth,digest-uri="xmpp/cataclysm.cx",\ 1602 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8 1604 Step 7: Server2 sends another challenge to Server1: 1606 1607 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 1608 1610 The decoded challenge is: 1612 rspauth=ea40f60335c427b5527b84dbabcdfffd 1614 Step 5 (alt): Server2 returns error to Server1: 1616 1617 1618 1619 1621 Step 8: Server1 responds to the challenge: 1623 1625 Step 9: Server2 informs Server1 of successful authentication: 1627 1629 Step 9 (alt): Server2 informs Server1 of failed authentication: 1631 1632 1633 1634 1636 Step 10: Server1 initiates a new stream to Server2: 1638 1644 Step 11: Server2 responds by sending a stream header to Server1 along 1645 with any additional features (or an empty features element): 1647 1653 1655 7. Server Dialback 1657 7.1 Overview 1659 The Jabber protocol from which XMPP was adapted includes a "server 1660 dialback" method for protecting against domain spoofing, thus making 1661 it more difficult to spoof XML stanzas (see Server-to-Server 1662 Communications (Section 12.3) regarding this method's security 1663 characteristics). Server dialback also makes it easier to deploy 1664 systems in which outbound messages and inbound messages are handled 1665 by different machines for the same domain. The server dialback method 1666 is made possible by the existence of DNS, since one server can 1667 (normally) discover the authoritative server for a given domain. 1669 Because dialback depends on the Domain Name System, inter-domain 1670 communications MUST NOT proceed until the DNS hostnames asserted by 1671 the servers have been resolved (see Server-to-Server Communications 1672 (Section 12.3)). 1674 The method for generating and verifying the keys used in server 1675 dialback MUST take into account the hostnames being used, the random 1676 ID generated for the stream, and a secret known by the authoritative 1677 server's network. 1679 Any error that occurs during dialback negotiation MUST be considered 1680 a stream error, resulting in termination of the stream and of the 1681 underlying TCP connection. The possible error conditions are 1682 specified in the protocol description below. 1684 The following terminology applies: 1686 o Originating Server -- the server that is attempting to establish a 1687 connection between two domains. 1689 o Receiving Server -- the server that is trying to authenticate that 1690 Originating Server represents the domain which it claims to be. 1692 o Authoritative Server -- the server that answers to the DNS 1693 hostname asserted by Originating Server; for basic environments 1694 this will be Originating Server, but it could be a separate 1695 machine in Originating Server's network. 1697 The following is a brief summary of the order of events in dialback: 1699 1. Originating Server establishes a connection to Receiving Server. 1701 2. Originating Server sends a 'key' value over the connection to 1702 Receiving Server. 1704 3. Receiving Server establishes a connection to Authoritative 1705 Server. 1707 4. Receiving Server sends the same 'key' value to Authoritative 1708 Server. 1710 5. Authoritative Server replies that key is valid or invalid. 1712 6. Receiving Server informs Originating Server whether it is 1713 authenticated or not. 1715 We can represent this flow of events graphically as follows: 1717 Originating Receiving 1718 Server Server 1719 ----------- --------- 1720 | | 1721 | establish connection | 1722 | ----------------------> | 1723 | | 1724 | send stream header | 1725 | ----------------------> | 1726 | | 1727 | send stream header | 1728 | <---------------------- | 1729 | | Authoritative 1730 | send dialback key | Server 1731 | ----------------------> | ------------- 1732 | | | 1733 | establish connection | 1734 | ----------------------> | 1735 | | 1736 | send stream header | 1737 | ----------------------> | 1738 | | 1739 | establish connection | 1740 | <---------------------- | 1741 | | 1742 | send stream header | 1743 | <---------------------- | 1744 | | 1745 | send dialback key | 1746 | ----------------------> | 1747 | | 1748 | validate dialback key | 1749 | <---------------------- | 1750 | 1751 | report dialback result | 1752 | <---------------------- | 1753 | | 1755 7.2 Protocol 1757 The interaction between the servers is as follows: 1759 1. Originating Server establishes TCP connection to Receiving 1760 Server. 1762 2. Originating Server sends a stream header to Receiving Server: 1764 1769 Note: the 'to' and 'from' attributes are NOT REQUIRED on the 1770 root stream element. The inclusion of the xmlns:db namespace 1771 declaration with the name shown indicates to Receiving Server 1772 that Originating Server supports dialback. If the namespace name 1773 is incorrect, then Receiving Server MUST generate an 1774 stream error condition and terminate both 1775 the XML stream and the underlying TCP connection. 1777 3. Receiving Server SHOULD send a stream header back to Originating 1778 Server, including a unique ID for this interaction: 1780 1786 Note: The 'to' and 'from' attributes are NOT REQUIRED on the 1787 root stream element. If the namespace name is incorrect, then 1788 Originating Server MUST generate an stream 1789 error condition and terminate both the XML stream and the 1790 underlying TCP connection. Note well that Receiving Server is 1791 NOT REQUIRED to reply and MAY silently terminate the XML stream 1792 and underlying TCP connection depending on security policies in 1793 place. 1795 4. Originating Server sends a dialback key to Receiving Server: 1797 1800 98AF014EDC0... 1801 1803 Note: this key is not examined by Receiving Server, since 1804 Receiving Server does not keep information about Originating 1805 Server between sessions. The key generated by Originating Server 1806 MUST be based in part on the value of the ID provided by 1807 Receiving Server in the previous step, and in part on a secret 1808 shared by Originating Server and Authoritative Server. If the 1809 value of the 'to' address does not match a hostname recognized 1810 by Receiving Server, then Receiving Server MUST generate a 1811 stream error condition and terminate both the 1812 XML stream and the underlying TCP connection. If the value of 1813 the 'from' address matches a domain with which Receiving Server 1814 already has an established connection, then Receiving Server 1815 MUST maintain the existing connection until it validates whether 1816 the new connection is legitimate; additionally, Receiving Server 1817 MAY choose to generate a stream error 1818 condition for the new connection and then terminate both the XML 1819 stream and the underlying TCP connection related to the new 1820 request. 1822 5. Receiving Server establishes a TCP connection back to the domain 1823 name asserted by Originating Server, as a result of which it 1824 connects to Authoritative Server. (Note: as an optimization, an 1825 implementation MAY reuse an existing trusted connection here 1826 rather than opening a new TCP connection.) 1828 6. Receiving Server sends Authoritative Server a stream header: 1830 1835 Note: the 'to' and 'from' attributes are NOT REQUIRED on the 1836 root stream element. If the namespace name is incorrect, then 1837 Authoritative Server MUST generate an 1838 stream error condition and terminate both the XML stream and the 1839 underlying TCP connection. 1841 7. Authoritative Server sends Receiving Server a stream header: 1843 1849 Note: if the namespace name is incorrect, then Receiving Server 1850 MUST generate an stream error condition and 1851 terminate both the XML stream and the underlying TCP connection 1852 between it and Authoritative Server. If a stream error occurs 1853 between Receiving Server and Authoritative Server, then 1854 Receiving Server MUST generate a 1855 stream error condition and terminate both the XML stream and the 1856 underlying TCP connection between it and Originating Server. 1858 8. Receiving Server sends Authoritative Server a stanza requesting 1859 that Authoritative Server verify a key: 1861 1865 98AF014EDC0... 1866 1868 Note: passed here are the hostnames, the original identifier 1869 from Receiving Server's stream header to Originating Server in 1870 Step 3, and the key that Originating Server sent to Receiving 1871 Server in Step 4. Based on this information as well as shared 1872 secret information within the Authoritative Server's network, 1873 the key is verified. Any verifiable method MAY be used to 1874 generate the key. If the value of the 'to' address does not 1875 match a hostname recognized by Authoritative Server, then 1876 Authoritative Server MUST generate a stream 1877 error condition and terminate both the XML stream and the 1878 underlying TCP connection. If the value of the 'from' address 1879 does not match the hostname represented by Receiving Server when 1880 opening the TCP connection (or any validated domain), then 1881 Authoritative Server MUST generate a stream 1882 error condition and terminate both the XML stream and the 1883 underlying TCP connection. 1885 9. Authoritative Server sends a stanza back to Receiving Server 1886 verifying whether the key was valid or invalid: 1888 1894 or 1896 1902 Note: if the ID does not match that provided by Receiving Server 1903 in Step 3, then Receiving Server MUST generate an 1904 stream error condition and terminate both the XML stream and the 1905 underlying TCP connection. If the value of the 'to' address does 1906 not match a hostname recognized by Receiving Server, then 1907 Receiving Server MUST generate a stream error 1908 condition and terminate both the XML stream and the underlying 1909 TCP connection. If the value of the 'from' address does not 1910 match the hostname represented by Originating Server when 1911 opening the TCP connection (or any validated domain), then 1912 Receiving Server MUST generate a stream 1913 error condition and terminate both the XML stream and the 1914 underlying TCP connection. 1916 10. Receiving Server informs Originating Server of the result: 1918 1923 Note: At this point the connection has either been validated via 1924 a type='valid', or reported as invalid. If the connection is 1925 invalid, then Receiving Server MUST terminate both the XML 1926 stream and the underlying TCP connection. If the connection is 1927 validated, data can be sent by Originating Server and read by 1928 Receiving Server; before that, all data stanzas sent to 1929 Receiving Server SHOULD be silently dropped. 1931 Even if dialback negotiation is successful, a server MUST verify that 1932 all XML stanzas received from the other server include a 'from' 1933 attribute and a 'to' attribute; if a stanza does not meet this 1934 restriction, the server that receives the stanza MUST generate an 1935 stream error condition and terminate both the 1936 XML stream and the underlying TCP connection. Furthermore, a server 1937 MUST verify that the 'from' attribute of stanzas received from the 1938 other server includes a validated domain for the stream; if a stanza 1939 does not meet this restriction, the server that receives the stanza 1940 MUST generate a stream error condition and 1941 terminate both the XML stream and the underlying TCP connection. Both 1942 of these checks help to prevent spoofing related to particular 1943 stanzas. 1945 8. XML Stanzas 1947 Once XML streams in both directions have been authenticated and (if 1948 desired) encrypted, XML stanzas can be sent over the streams. Three 1949 kinds of XML stanza are defined for the 'jabber:client' and 1950 'jabber:server' namespaces: , , and . In 1951 addition, there are five common attributes for these kinds of stanza. 1952 These common attributes and the basic semantics of the three stanza 1953 kinds are defined herein; more detailed information regarding the 1954 syntax of XML stanzas in relation to instant messaging and presence 1955 applications is provided in XMPP IM [20]. 1957 8.1 Common Attributes 1959 The following five attributes are common to message, presence, and IQ 1960 stanzas: 1962 8.1.1 to 1964 The 'to' attribute specifies the JID of the intended recipient for 1965 the stanza. 1967 In the 'jabber:client' namespace, a stanza SHOULD possess a 'to' 1968 attribute, although a stanza sent from a client to a server for 1969 handling by that server (e.g., presence sent to the server for 1970 broadcasting to other entities) SHOULD NOT possess a 'to' attribute. 1972 In the 'jabber:server' namespace, a stanza MUST possess a 'to' 1973 attribute; if a server receives a stanza that does not meet this 1974 restriction, it MUST generate an stream error 1975 condition and terminate both the XML stream and the underlying TCP 1976 connection with the offending server. 1978 If the value of the 'to' attribute is invalid or cannot be contacted, 1979 the entity discovering that fact (usually the sender's or recipient's 1980 server) MUST return an appropriate error to the sender. 1982 8.1.2 from 1984 The 'from' attribute specifies the JID of the sender. 1986 In the 'jabber:client' namespace, a client MUST NOT include a 'from' 1987 attribute on the stanzas it sends to a server; if a server receives 1988 an XML stanza from a client and the stanza possesses a 'from' 1989 attribute, it MUST ignore the value of the 'from' attribute and MAY 1990 return an error to the sender. When a client sends an XML stanza 1991 within the context of an authenticated stream, the server MUST stamp 1992 the stanza with the full JID () of the 1993 connected resource that generated the stanza as defined by the 1994 authzid provided in the SASL negotiation. If a client attempts to 1995 send an XML stanza before the stream is authenticated, the server 1996 SHOULD return a stream error to the client and then 1997 terminate both the XML stream and the underlying TCP connection. 1999 In the 'jabber:server' namespace, a stanza MUST possess a 'from' 2000 attribute; if a server receives a stanza that does not meet this 2001 restriction, it MUST generate an stream error 2002 condition. Furthermore, the domain identifier portion of the JID 2003 contained in the 'from' attribute MUST match the hostname of the 2004 sending server (or any validated domain) as communicated in the SASL 2005 negotiation or dialback negotiation; if a server receives a stanza 2006 that does not meet this restriction, it MUST generate a 2007 stream error condition. Both of these conditions 2008 MUST result in closing of the stream and termination of the 2009 underlying TCP connection. 2011 8.1.3 id 2013 The optional 'id' attribute MAY be used by a sending entity for 2014 internal tracking of stanzas that it sends and receives (especially 2015 for tracking the request-response interaction inherent in the use of 2016 IQ stanzas). The value of the 'id' attribute is NOT REQUIRED to be 2017 unique either globally, within a domain, or within a stream. The 2018 semantics of IQ stanzas impose additional restrictions; see the IQ 2019 Semantics (Section 8.2.3) section of this document. 2021 8.1.4 type 2023 The 'type' attribute specifies detailed information about the purpose 2024 or context of the message, presence, or IQ stanza. The particular 2025 allowable values for the 'type' attribute vary depending on whether 2026 the stanza is a message, presence, or IQ; the values for message and 2027 presence stanzas are specific to instant messaging and presence 2028 applications and therefore are defined in XMPP IM [20], whereas the 2029 values for IQ stanzas specify the role of an IQ stanza in a 2030 structured request-response "conversation" and thus are described 2031 under IQ Semantics (Section 8.2.3) below. The only 'type' value 2032 common to all three stanzas is "error"; see Stanza Errors (Section 2033 8.3). 2035 8.1.5 xml:lang 2037 A stanza SHOULD possess an 'xml:lang' attribute (as defined in 2038 Section 2.12 of the XML specification [1]) if the stanza contains XML 2039 character data that is intended to be presented to a human user (as 2040 explained in RFC 2277 [14], "internationalization is for humans"). 2042 The value of the 'xml:lang' attribute specifies the default language 2043 of any such XML character data, which MAY be overridden by the 2044 'xml:lang' attribute of a specific child element. The value of the 2045 attribute MUST be an NMTOKEN and MUST conform to the format defined 2046 in RFC 3066 [15]. 2048 8.2 Basic Semantics 2050 8.2.1 Message Semantics 2052 The stanza kind can be seen as a "push" mechanism whereby 2053 one entity pushes information to another entity, similar to the 2054 communications that occur in a system such as email. All message 2055 stanzas SHOULD possess a 'to' attribute that specifies the intended 2056 recipient of the message; upon receiving such a stanza, a server 2057 SHOULD route or deliver it to the intended recipient (see Server 2058 Rules for Handling XML Stanzas (Section 13) for general routing and 2059 delivery rules related to XML stanzas). 2061 8.2.2 Presence Semantics 2063 The element can be seen as a basic broadcast or 2064 "publish-subscribe" mechanism, whereby multiple entities receive 2065 information (in this case, presence information) about an entity to 2066 which they have subscribed. In general, a publishing entity SHOULD 2067 send a presence stanza with no 'to' attribute, in which case the 2068 server to which the entity is connected SHOULD broadcast or multiplex 2069 that stanza to all subscribing entities. However, a publishing entity 2070 MAY also send a presence stanza with a 'to' attribute, in which case 2071 the server SHOULD route or deliver that stanza to the intended 2072 recipient. See Server Rules for Handling XML Stanzas (Section 13) for 2073 general routing and delivery rules related to XML stanzas, and XMPP 2074 IM [20] for presence-specific rules in the context of an instant 2075 messaging and presence application. 2077 8.2.3 IQ Semantics 2079 Info/Query, or IQ, is a request-response mechanism, similar in some 2080 ways to HTTP [21]. The semantics of IQ enable an entity to make a 2081 request of, and receive a response from, another entity. The data 2082 content of the request and response is defined by the namespace 2083 declaration of a direct child element of the IQ element, and the 2084 interaction is tracked by the requesting entity through use of the 2085 'id' attribute. Thus IQ interactions follow a common pattern of 2086 structured data exchange such as get/result or set/result (although 2087 an error may be returned in response to a request if appropriate): 2089 Requesting Responding 2090 Entity Entity 2091 ---------- ---------- 2092 | | 2093 | | 2094 | ------------------------> | 2095 | | 2096 | | 2097 | <------------------------ | 2098 | | 2099 | | 2100 | ------------------------> | 2101 | | 2102 | | 2103 | <------------------------ | 2104 | | 2106 In order to enforce these semantics, the following rules apply: 2108 1. The 'id' attribute is REQUIRED for IQ stanzas. 2110 2. The 'type' attribute is REQUIRED for IQ stanzas. The value SHOULD 2111 be one of the following (all other values SHOULD be ignored): 2113 * get -- The stanza is a request for information or 2114 requirements. 2116 * set -- The stanza provides required data, sets new values, or 2117 replaces existing values. 2119 * result -- The stanza is a response to a successful get or set 2120 request. 2122 * error -- An error has occurred regarding processing or 2123 delivery of a previously-sent get or set (see Stanza Errors 2124 (Section 8.3)). 2126 3. An entity that receives an IQ request of type "get" or "set" MUST 2127 reply with an IQ response of type "result" or "error" (which 2128 response MUST preserve the 'id' attribute of the request). 2130 4. An entity that receives a stanza of type "result" or "error" MUST 2131 NOT respond to the stanza by sending a further IQ response of 2132 type "result" or "error"; however, as shown above, the requesting 2133 entity MAY send another request (e.g., an IQ of type "set" in 2134 order to provide required information discovered through a get/ 2135 result pair). 2137 5. An IQ stanza of type "get" or "set" MUST contain one and only one 2138 child element (properly-namespaced as defined in XMPP IM [20]) 2139 that specifies the semantics of the particular request or 2140 response. 2142 6. An IQ stanza of type "result" MUST include zero or one child 2143 elements. 2145 7. An IQ stanza of type "error" SHOULD include the child element 2146 contained in the associated "get" or "set" and MUST include an 2147 child; for details, see Stanza Errors (Section 8.3). 2149 8.3 Stanza Errors 2151 Stanza-related errors are handled in a manner similar to stream 2152 errors (Section 4.6), except that hints are also provided to the 2153 receiving application regarding actions to take in response to the 2154 error. 2156 8.3.1 Rules 2158 The following rules apply to stanza-related errors: 2160 o The receiving or processing entity that detects an error condition 2161 in relation to a stanza MUST return to the sending entity a stanza 2162 of the same kind (message, presence, or IQ) whose 'type' attribute 2163 is set to a value of "error". 2165 o The entity that generates a stanza of type "error" SHOULD (but is 2166 NOT REQUIRED to) include the original XML sent so that the sender 2167 can inspect and if necessary correct the XML before attempting to 2168 resend. 2170 o A stanza whose 'type' attribute has a value of "error" MUST 2171 contain an child element. 2173 o An child MUST NOT be included if the 'type' attribute has 2174 a value other than "error" (or if there is no 'type' attribute). 2176 o An entity that receives a stanza whose 'type' attribute has a 2177 value of "error" MUST NOT respond to the stanza with a further 2178 stanza of type "error"; this helps to prevent looping. 2180 8.3.2 Syntax 2182 The syntax for stanza-related errors is as follows: 2184 2185 [RECOMMENDED to include sender XML here] 2186 2187 2188 2189 OPTIONAL descriptive text 2190 2191 [OPTIONAL application-specific condition element] 2192 2193 2195 The stanza-name is one of message, presence, or iq. 2197 The value of the element's 'type' attribute MUST be one of 2198 the following: 2200 o cancel -- do not retry (the error is unrecoverable) 2202 o continue -- proceed (the condition was only a warning) 2204 o modify -- retry after changing the data sent 2206 o auth -- retry after providing credentials 2208 o wait -- retry after waiting (the error is temporary) 2210 The element: 2212 o MUST contain a child element corresponding to one of the defined 2213 stanza error conditions defined below; this element MUST be 2214 qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace 2216 o MAY contain a child containing CDATA that describes the 2217 error in more detail; this element MUST be qualified by the 2218 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace and SHOULD possess 2219 an 'xml:lang' attribute 2221 o MAY contain a child element for an application-specific error 2222 condition; this element MUST be qualified by an 2223 application-defined namespace, and its structure is defined by 2224 that namespace 2226 The element is OPTIONAL. If included, it SHOULD be used only 2227 to provide descriptive or diagnostic information that supplements the 2228 meaning of a defined condition or application-specific condition. It 2229 SHOULD NOT be interpreted programmatically by an application. It 2230 SHOULD NOT be used as the error message presented to user, but MAY be 2231 shown in addition to the error message associated with the included 2232 condition element (or elements). 2234 Note: the XML namespace name 'urn:ietf:params:xml:ns:xmpp-stanzas' 2235 that qualifies the descriptive element adheres to the format defined 2236 in The IETF XML Registry [23]. 2238 8.3.3 Defined Conditions 2240 The following stanza-related error conditions are defined for use in 2241 stanza errors. 2243 o -- the sender has sent XML that is malformed or 2244 that cannot be processed (e.g., a client-generated stanza includes 2245 a 'from' address, or an IQ stanza includes an unrecognized value 2246 of the 'type' attribute); the associated error type SHOULD be 2247 "modify". 2249 o -- access cannot be granted because an existing 2250 resource or session exists with the same name or address; the 2251 associated error type SHOULD be "cancel". 2253 o -- the feature requested is not 2254 implemented by the recipient or server and therefore cannot be 2255 processed; the associated error type SHOULD be "cancel". 2257 o -- the requesting entity does not possess the 2258 required permissions to perform the action; the associated error 2259 type SHOULD be "auth". 2261 o -- the server could not process the 2262 stanza because of a misconfiguration or an otherwise-undefined 2263 internal server error; the associated error type SHOULD be "wait". 2265 o -- the addressed JID or item requested cannot be 2266 found; the associated error type SHOULD be "cancel". 2268 o -- the value of the 'to' attribute in the 2269 sender's stanza does not adhere to the syntax defined in 2270 Addressing Scheme (Section 3); the associated error type SHOULD be 2271 "modify". 2273 o -- the recipient does not allow any entity to 2274 perform the action; the associated error type SHOULD be "cancel". 2276 o -- the user is not authorized to access the 2277 requested service because payment is required; the associated 2278 error type SHOULD be "auth". 2280 o -- the specific recipient requested is 2281 currently unavailable; the associated error type SHOULD be "wait". 2283 o -- the user is not authorized to access 2284 the requested service because registration is required; the 2285 associated error type SHOULD be "auth". 2287 o -- a remote server or service specified 2288 as part or all of the JID of the intended recipient does not 2289 exist; the associated error type SHOULD be "cancel". 2291 o -- a remote server or service specified 2292 as part or all of the JID of the intended recipient could not be 2293 contacted within a reasonable amount of time; the associated error 2294 type SHOULD be "wait". 2296 o -- the server is resource-constrained and 2297 is unable to service the request; the associated error type SHOULD 2298 be "wait". 2300 o -- the service requested is currently 2301 unavailable on the server; the associated error type SHOULD be 2302 "cancel". 2304 o -- the user is not authorized to access 2305 the requested service because a subscription is required; the 2306 associated error type SHOULD be "auth". 2308 o -- the error condition is not one of those 2309 defined by the other conditions in this list; any error type may 2310 be associated with this condition, and it SHOULD be used only in 2311 conjunction with an application-specific condition. 2313 o -- the recipient understood the request but 2314 was not expecting it at this time (e.g., the request was out of 2315 order); the associated error type SHOULD be "wait". 2317 8.3.4 Application-Specific Conditions 2319 As noted, an application MAY provide application-specific stanza 2320 error information by including a properly-namespaced child in the 2321 error element. The application-specific element SHOULD supplement or 2322 further qualify a defined element. Thus the element will 2323 contain two or three child elements: 2325 2326 2327 2328 2329 2330 2332 2333 2334 2335 2336 Some special application diagnostic information! 2337 2338 2339 2340 2342 9. XML Usage within XMPP 2344 9.1 Restrictions 2346 XMPP is a simplified and specialized protocol for streaming XML 2347 elements in order to exchange messages and presence information in 2348 close to real time. Because XMPP does not require the parsing of 2349 arbitrary and complete XML documents, there is no requirement that 2350 XMPP needs to support the full XML specification [1]. In particular, 2351 the following restrictions apply. 2353 With regard to XML generation, an XMPP implementation MUST NOT inject 2354 into an XML stream any of the following: 2356 o comments (as defined in Section 2.5 of the XML specification [1]) 2358 o processing instructions (Section 2.6) 2360 o internal or external DTD subsets (Section 2.8) 2362 o internal or external entity references (Section 4.2) with the 2363 exception of predefined entities (Section 4.6) 2365 o character data or attribute values containing unescaped characters 2366 that map to the predefined entities (Section 4.6); such characters 2367 MUST be escaped 2369 With regard to XML processing, if an XMPP implementation receives 2370 such restricted XML data, it MUST ignore the data. 2372 9.2 XML Namespace Names and Prefixes 2374 XML Namespaces [10] are used within all XMPP-compliant XML to create 2375 strict boundaries of data ownership. The basic function of namespaces 2376 is to separate different vocabularies of XML elements that are 2377 structurally mixed together. Ensuring that XMPP-compliant XML is 2378 namespace-aware enables any XML to be structurally mixed with any 2379 data element within XMPP. Rules for XML namespace names and prefixes 2380 are defined below. 2382 9.2.1 Stream Namespace 2384 A stream namespace declaration is REQUIRED in both XML stream 2385 headers. The name of the stream namespace MUST be 'http:// 2386 etherx.jabber.org/streams'. The element names of the 2387 element and its and children MUST be qualified 2388 by the stream namespace prefix in all instances. An implementation 2389 SHOULD generate only the 'stream:' prefix for these elements, and for 2390 historical reasons MAY accept only the 'stream:' prefix. 2392 9.2.2 Default Namespace 2394 A default namespace declaration is REQUIRED and is used in both XML 2395 streams in order to define the allowable first-level children of the 2396 root stream element. This namespace declaration MUST be the same for 2397 the initiating stream and the responding stream so that both streams 2398 are qualified consistently. The default namespace declaration applies 2399 to the stream and all stanzas sent within a stream (unless explicitly 2400 qualified by another namespace, or by the prefix of the stream 2401 namespace or the dialback namespace). 2403 A server implementation MUST support the following two default 2404 namespaces (for historical reasons, some implementations MAY support 2405 only these two default namespaces): 2407 o jabber:client -- this default namespace is declared when the 2408 stream is used for communications between a client and a server 2410 o jabber:server -- this default namespace is declared when the 2411 stream is used for communications between two servers 2413 A client implementation MUST support the 'jabber:client' default 2414 namespace, and for historical reasons MAY support only that default 2415 namespace. 2417 An implementation MUST NOT generate namespace prefixes for elements 2418 in the default namespace if the default namespace is 'jabber:client' 2419 or 'jabber:server'. An implementation SHOULD NOT generate namespace 2420 prefixes for elements qualified by content (as opposed to stream) 2421 namespaces other than 'jabber:client' and 'jabber:server'. 2423 Note: the 'jabber:client' and 'jabber:server' namespaces are nearly 2424 identical but are used in different contexts (client-to-server 2425 communications for 'jabber:client' and server-to-server 2426 communications for 'jabber:server'). The only difference between the 2427 two is that the 'to' and 'from' attributes are OPTIONAL on stanzas 2428 sent within 'jabber:client', whereas they are REQUIRED on stanzas 2429 sent within 'jabber:server'. If a compliant implementation accepts a 2430 stream that is qualified by the 'jabber:client' or 'jabber:server' 2431 namespace, it MUST support the common attributes (Section 8.1) and 2432 basic semantics (Section 8.2) of all three core stanza kinds 2433 (message, presence, and IQ). 2435 9.2.3 Dialback Namespace 2437 A dialback namespace declaration is REQUIRED for all elements used in 2438 server dialback. The name of the dialback namespace MUST be 2439 'jabber:server:dialback'. All elements qualified by this namespace 2440 MUST be prefixed. An implementation SHOULD generate only the 'db:' 2441 prefix for such elements and MAY accept only the 'db:' prefix. 2443 9.3 Validation 2445 Except as noted with regard to 'to' and 'from' addresses for stanzas 2446 within the 'jabber:server' namespace, a server is not responsible for 2447 validating the XML elements forwarded to a client or another server; 2448 an implementation MAY choose to provide only validated data elements 2449 but is NOT REQUIRED to do so (although an implementation MUST NOT 2450 accept XML that is not well-formed). Clients SHOULD NOT rely on the 2451 ability to send data which does not conform to the schemas, and 2452 SHOULD ignore any non-conformant elements or attributes on the 2453 incoming XML stream. Validation of XML streams and stanzas is NOT 2454 REQUIRED or recommended, and schemas are included herein for 2455 descriptive purposes only. 2457 9.4 Inclusion of Text Declaration 2459 Implementations SHOULD send a text declaration before sending a 2460 stream header. Applications MUST follow the rules in the XML 2461 specification [1] regarding the circumstances under which a text 2462 declaration is included. 2464 9.5 Character Encoding 2466 Implementations MUST support the UTF-8 (RFC 2279 [16]) transformation 2467 of Universal Character Set (ISO/IEC 10646-1 [17]) characters, as 2468 required by RFC 2277 [14]. Implementations MUST NOT attempt to use 2469 any other encoding. 2471 10. IANA Considerations 2473 10.1 XML Namespace Name for TLS Data 2475 A URN sub-namespace for TLS-related data in the Extensible Messaging 2476 and Presence Protocol (XMPP) is defined as follows. 2478 URI: urn:ietf:params:xml:ns:xmpp-tls 2480 Specification: [RFCXXXX] 2482 Description: This is the XML namespace name for TLS-related data in 2483 the Extensible Messaging and Presence Protocol (XMPP) as defined 2484 by [RFCXXXX]. 2486 Registrant Contact: IETF, XMPP Working Group, 2488 10.2 XML Namespace Name for SASL Data 2490 A URN sub-namespace for SASL-related data in the Extensible Messaging 2491 and Presence Protocol (XMPP) is defined as follows. 2493 URI: urn:ietf:params:xml:ns:xmpp-sasl 2495 Specification: [RFCXXXX] 2497 Description: This is the XML namespace name for SASL-related data in 2498 the Extensible Messaging and Presence Protocol (XMPP) as defined 2499 by [RFCXXXX]. 2501 Registrant Contact: IETF, XMPP Working Group, 2503 10.3 XML Namespace Name for Stream Errors 2505 A URN sub-namespace for stream-related error data in the Extensible 2506 Messaging and Presence Protocol (XMPP) is defined as follows. 2508 URI: urn:ietf:params:xml:ns:xmpp-streams 2510 Specification: [RFCXXXX] 2512 Description: This is the XML namespace name for stream-related error 2513 data in the Extensible Messaging and Presence Protocol (XMPP) as 2514 defined by [RFCXXXX]. 2516 Registrant Contact: IETF, XMPP Working Group, 2518 10.4 XML Namespace Name for Stanza Errors 2520 A URN sub-namespace for stanza-related error data in the Extensible 2521 Messaging and Presence Protocol (XMPP) is defined as follows. 2523 URI: urn:ietf:params:xml:ns:xmpp-stanzas 2525 Specification: [RFCXXXX] 2527 Description: This is the XML namespace name for stanza-related error 2528 data in the Extensible Messaging and Presence Protocol (XMPP) as 2529 defined by [RFCXXXX]. 2531 Registrant Contact: IETF, XMPP Working Group, 2533 10.5 Nodeprep Profile of Stringprep 2535 The Nodeprep profile of stringprep is defined in Appendix A (Appendix 2536 A) of this document. If and when this document becomes an RFC, the 2537 Nodeprep profile shall be registered in the stringprep profile 2538 registry maintained by the IANA [5]. 2540 Name of this profile: 2542 Nodeprep 2544 RFC in which the profile is defined: 2546 This document 2548 Indicator whether or not this is the newest version of the profile: 2550 This is the first version of Nodeprep 2552 10.6 Resourceprep Profile of Stringprep 2554 The Resourceprep profile of stringprep is defined in Appendix B 2555 (Appendix B) of this document. If and when this document becomes an 2556 RFC, the Resourceprep profile shall be registered in the stringprep 2557 profile registry maintained by the IANA [5]. 2559 Name of this profile: 2561 Resourceprep 2563 RFC in which the profile is defined: 2565 This document 2567 Indicator whether or not this is the newest version of the profile: 2569 This is the first version of Resourceprep 2571 10.7 Existing Registrations 2573 The IANA registers "xmpp" as a GSSAPI [18] service name, as defined 2574 under SASL Definition (Section 6.4). 2576 Additionally, the IANA registers "jabber-client" and "jabber-server" 2577 as keywords for TCP ports 5222 and 5269 respectively. These ports 2578 SHOULD be used for client-to-server and server-to-server 2579 communications respectively, but their use is NOT REQUIRED. The use 2580 of the string "jabber" in these keywords is historical. 2582 11. Internationalization Considerations 2584 XML streams MUST be encoded in UTF-8 as specified under the Character 2585 Encoding (Section 9.5) section of this document. As speficied under 2586 xml:lang (Section 8.1.5), an XML stanza SHOULD include an 'xml:lang' 2587 attribute if the stanza contains XML character data that is intended 2588 to be presented to a human user. Servers MUST NOT modify or delete 2589 'xml:lang' attributes from stanzas they receive from other entities. 2591 12. Security Considerations 2593 12.1 High Security 2595 For the purposes of XMPP communications (client-to-server and 2596 server-to-server), the term "high security" refers to the use of 2597 security technologies that provide both mutual authentication and 2598 integrity-checking; in particular, when using certificate-based 2599 authentication to provide high security, a chain-of-trust SHOULD be 2600 established out-of-band, although a shared certificate authority 2601 signing certificates could allow a previously unknown certificate to 2602 establish trust in-band. 2604 Standalone, self-signed service certificates SHOULD NOT be used; 2605 rather, an entity that wishes to generate a self-signed service 2606 certificate SHOULD first generate a self-signed Root CA certificate 2607 and then generate a signed service certificate. Entities that 2608 communicate with the service SHOULD be configured with the Root CA 2609 certificate rather than the service certificate; this avoids problems 2610 associated with simple comparison of service certificates. If a 2611 self-signed service certificate is used, an entity SHOULD NOT trust 2612 it if it is changed to another self-signed certificate or a 2613 certificate signed by an unrecognized authority. 2615 Implementations MUST support high security. Service provisioning 2616 SHOULD use high security, subject to local security policies. 2618 12.2 Client-to-Server Communications 2620 A compliant implementation MUST support both TLS and SASL for 2621 connections to a server. 2623 The TLS protocol for encrypting XML streams (defined under Stream 2624 Encryption (Section 5)) provides a reliable mechanism for helping to 2625 ensure the confidentiality and data integrity of data exchanged 2626 between two entities. 2628 The SASL protocol for authenticating XML streams (defined under 2629 Stream Authentication (Section 6)) provides a reliable mechanism for 2630 validating that a client connecting to a server is who it claims to 2631 be. 2633 Client-to-server communications MUST NOT proceed until the DNS 2634 hostname asserted by the server has been resolved. Such resolutions 2635 SHOULD first attempt to resolve the hostname using an SRV [19] 2636 Service of "jabber-client" and Proto of "tcp", resulting in resource 2637 records such as "_jabber-client._tcp.example.com." (the use of the 2638 string "jabber-client" for the service identifier is consistent with 2639 the existing IANA registration). If the SRV lookup fails, the 2640 fallback is a normal A lookup to determine the IP address, using the 2641 "jabber-client" port of 5222 assigned by the Internet Assigned 2642 Numbers Authority [5]. 2644 The IP address and method of access of clients MUST NOT be made 2645 available by a server, nor are any connections other than the 2646 original server connection required. This helps to protect the 2647 client's server from direct attack or identification by third 2648 parties. 2650 12.3 Server-to-Server Communications 2652 A compliant implementation MUST support both TLS and SASL for 2653 inter-domain communications. For historical reasons, a compliant 2654 implementation SHOULD also support Server Dialback (Section 7). 2656 Because service provisioning is a matter of policy, it is OPTIONAL 2657 for any given domain to communicate with other domains, and 2658 server-to-server communications MAY be disabled by the administrator 2659 of any given deployment. If a particular domain enables inter-domain 2660 communications, it SHOULD enable high security. 2662 Administrators may want to require use of SASL for server-to-server 2663 communications in order to ensure both authentication and 2664 confidentiality (e.g., on an organization's private network). 2665 Compliant implementations SHOULD support SASL for this purpose. 2667 Inter-domain connections MUST NOT proceed until the DNS hostnames 2668 asserted by the servers have been resolved. Such resolutions MUST 2669 first attempt to resolve the hostname using an SRV [19] Service of 2670 "jabber-server" and Proto of "tcp", resulting in resource records 2671 such as "_jabber-server._tcp.example.com." (the use of the string 2672 "jabber-server" for the service identifier is consistent with the 2673 existing IANA registration; note well that the "jabber-server" 2674 service identifier supersedes the earlier use of a "jabber" service 2675 identifier, since the earlier usage did not conform to RFC 2782 2676 [19]). If the SRV lookup fails, the fallback is a normal A lookup to 2677 determine the IP address, using the "jabber-server" port of 5269 2678 assigned by the Internet Assigned Numbers Authority [5]. 2680 Server dialback helps protect against domain spoofing, thus making it 2681 more difficult to spoof XML stanzas. It is not a mechanism for 2682 authenticating, securing, or encrypting streams between servers as is 2683 done via SASL and TLS. Furthermore, it is susceptible to DNS 2684 poisoning attacks unless DNSSec [28] is used, and even if the DNS 2685 information is accurate, dialback cannot protect from attacks where 2686 the attacker is capable of hijacking the IP address of the remote 2687 domain. Domains requiring robust security SHOULD use TLS and SASL. If 2688 SASL is used for server-to-server authentication, dialback SHOULD NOT 2689 be used since it is unnecessary. 2691 12.4 Order of Layers 2693 The order of layers in which protocols MUST be stacked is as follows: 2695 1. TCP 2697 2. TLS 2699 3. SASL 2701 4. XMPP 2703 The rationale for this order is that TCP is the base connection layer 2704 used by all of the protocols stacked on top of TCP, TLS is often 2705 provided at the operating system layer, SASL is often provided at the 2706 application layer, and XMPP is the application itself. 2708 12.5 Firewalls 2710 Communications using XMPP normally occur over TCP sockets on port 2711 5222 (client-to-server) or port 5269 (server-to-server), as 2712 registered with the IANA [5] (see IANA Considerations (Section 10)). 2713 Use of these well-known ports allows administrators to easily enable 2714 or disable XMPP activity through existing and commonly-deployed 2715 firewalls. 2717 12.6 Mandatory to Implement Technologies 2719 At a minimum, all implementations MUST support the following 2720 mechanisms: 2722 for authentication: the SASL DIGEST-MD5 mechanism 2724 for confidentiality: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA 2725 cipher) 2727 for both: TLS plus SASL EXTERNAL(using the 2728 TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side 2729 certificates) 2731 12.7 Stringprep Profiles 2733 XMPP defines two profiles of stringprep [9]: Nodeprep (Appendix A) 2734 (for node identifiers) and Resourceprep (Appendix B) (for resource 2735 identifiers). 2737 The Unicode and ISO/IEC 10646 repertoires have many characters that 2738 look similar. In many cases, users of security protocols might do 2739 visual matching, such as when comparing the names of trusted third 2740 parties. Because it is impossible to map similar-looking characters 2741 without a great deal of context such as knowing the fonts used, 2742 stringprep does nothing to map similar-looking characters together 2743 nor to prohibit some characters because they look like others. 2745 A node identifier can be employed as one part of an entity's address 2746 in XMPP. One common usage is as the username of an instant messaging 2747 user; another is as the name of a multi-user chat room; and many 2748 other kinds of entities could use node identifiers as part of their 2749 addresses. The security of such services could be compromised based 2750 on different interpretations of the internationalized node 2751 identifier; for example, a user entering a single internationalized 2752 node identifier could access another user's account information, or a 2753 user could gain access to an otherwise restricted chat room or 2754 service. 2756 A resource identifier can be employed as one part of an entity's 2757 address in XMPP. One common usage is as the name for an instant 2758 messaging user's active session; another is as the nickname of a user 2759 in a multi-user chat room; and many other kinds of entities could use 2760 resource identifiers as part of their addresses. The security of such 2761 services could be compromised based on different interpretations of 2762 the internationalized resource identifier; for example, a user could 2763 attempt to initiate multiple sessions with the same name, or a user 2764 could send a message to someone other than the intended recipient in 2765 a multi-user chat room. 2767 13. Server Rules for Handling XML Stanzas 2769 Each server implementation will contain its own "delivery tree" for 2770 handling stanzas it receives. Such a tree determines whether a stanza 2771 needs to be routed to another domain, processed internally, or 2772 delivered to a resource associated with a connected node. The 2773 following rules apply: 2775 13.1 No 'to' Address 2777 If the stanza possesses no 'to' attribute, the server SHOULD process 2778 it on behalf of the entity that sent it. Because all stanzas received 2779 from other servers MUST possess a 'to' attribute, this rule applies 2780 only to stanzas received from a registered entity (such as a client) 2781 that is connected to the server. If the server receives a presence 2782 stanza with no 'to' attribute, the server SHOULD broadcast it to the 2783 entities that are subscribed to the sending entity's presence, if 2784 applicable (the semantics of presence broadcast for instant messaging 2785 and presence applications are defined in XMPP IM [20]). If the server 2786 receives an IQ stanza of type "get" or "set" with no 'to' attribute 2787 and it understands the namespace that qualifies the content of the 2788 stanza, it MUST either process the stanza on behalf of sending entity 2789 (where the meaning of "process" is determined by the semantics of the 2790 qualifying namespace) or return an error to the sending entity. 2792 13.2 Foreign Domain 2794 If the hostname of the domain identifier portion of the JID contained 2795 in the 'to' attribute does not match one of the configured hostnames 2796 of the server itself or a subdomain thereof, the server SHOULD route 2797 the stanza to the foreign domain (subject to local service 2798 provisioning and security policies regarding inter-domain 2799 communication). There are two possible cases: 2801 A server-to-server stream already exists between the two domains: The 2802 sender's server routes the stanza to the authoritative server for 2803 the foreign domain over the existing stream 2805 There exists no server-to-server stream between the two domains: The 2806 sender's server first (1) resolves the hostname of the foreign 2807 domain (as defined under Server-to-Server Communications (Section 2808 12.3)), (2) negotiates a server-to-server stream between the two 2809 domains, and (3) routes the stanza to the authoritative server for 2810 the foreign domain over the newly-established stream 2812 If routing to the recipient's server is unsuccessful, the sender's 2813 server MUST return an error to the sender; if the recipient's server 2814 can be contacted but delivery by the recipient's server to the 2815 recipient is unsuccessful, the recipient's server MUST return an 2816 error to the sender by way of the sender's server. 2818 13.3 Subdomain 2820 If the hostname of the domain identifier portion of the JID contained 2821 in the 'to' attribute matches a subdomain of one of the configured 2822 hostnames of the server itself, the server MAY process the stanza 2823 itself or MAY route the stanza to a specialized service that is 2824 responsible for that subdomain (if any). 2826 13.4 Bare Domain or Specific Resource 2828 If the hostname of the domain identifier portion of the JID contained 2829 in the 'to' attribute matches the hostname of the server itself and 2830 the JID contained in the 'to' attribute is of the form or 2831 , the server (or a defined resource thereof) SHOULD 2832 process the stanza as appropriate for the stanza kind. If the stanza 2833 is an IQ stanza and the server understands the namespace that 2834 qualifies the content of the stanza, the server MUST either process 2835 the request according to the semantics of the qualifying namespace or 2836 reply with an IQ of type "error". 2838 13.5 Node in Same Domain 2840 If the hostname of the domain identifier portion of the JID contained 2841 in the 'to' attribute matches the hostname of the server itself and 2842 the JID contained in the 'to' attribute is of the form 2843 or , the server SHOULD deliver the stanza to 2844 the intended recipient of the stanza as represented by the JID 2845 contained in the 'to' attribute. The following rules apply: 2847 1. If the JID contains a resource identifier (i.e., is of the form 2848 ) and there is an available resource whose 2849 authzid matches the full JID, the recipient's server SHOULD 2850 deliver the stanza to the session that exactly matches the 2851 resource identifier. 2853 2. If the JID contains a resource identifier and there is no 2854 available resource whose authzid matches the full JID, the 2855 recipient's server SHOULD return to the sender a 2856 stanza error. 2858 3. If the JID is of the form and there is at least one 2859 available resource available for the node, the recipient's server 2860 MUST deliver the stanza to at least one of the available 2861 resources, according to application-specific rules (a set of 2862 delivery rules for instant messaging and presence applications is 2863 defined in XMPP IM [20]). 2865 14. Compliance Requirements 2867 This section summarizes the specific aspects of the Extensible 2868 Messaging and Presence Protocol that MUST be supported by servers and 2869 clients in order to be considered compliant implementations, as well 2870 as additional protocol aspects that SHOULD be supported. For 2871 compliance purposes, we draw a distinction between core protocols 2872 (which MUST be supported by any server or client, regardless of the 2873 specific application) and instant messaging protocols (which MUST be 2874 supported only by instant messaging and presence applications built 2875 on top of the core protocols). Compliance requirements that apply to 2876 all servers and clients are specified in this section; compliance 2877 requirements for instant messaging servers and clients are specified 2878 in the corresponding section of XMPP IM [20]. 2880 14.1 Servers 2882 A server MUST support the following core protocols in order to be 2883 considered compliant: 2885 o Enforcement of the Nodeprep (Appendix A) and Resourceprep 2886 (Appendix B) profiles of stringprep 2888 o XML streams (Section 4) as defined in this document, including 2889 stream encryption (Section 5) using TLS and stream authentication 2890 (Section 6) using SASL 2892 o The basic semantics of the three defined XML stanzas (Section 8) 2893 (i.e., , , and ) 2895 o Generation (and, where appropriate, handling) of error syntax and 2896 semantics related to streams, TLS, SASL, and XML stanzas 2898 In addition, a server SHOULD support the following core protocol: 2900 o Server dialback (Section 7) 2902 14.2 Clients 2904 A client MUST support the following core protocols in order to be 2905 considered compliant: 2907 o XML streams (Section 4) as defined in this document, including 2908 stream encryption (Section 5) using TLS and stream authentication 2909 (Section 6) using SASL 2911 o The basic semantics of the three defined XML stanzas (Section 8) 2912 (i.e., , , and ) 2914 o Handling (and, where appropriate, generation) of error syntax and 2915 semantics related to streams, TLS, SASL, and XML stanzas 2917 In addition, a client SHOULD support the following core protocols: 2919 o Generation of addresses in accordance with the Nodeprep (Appendix 2920 A) and Resourceprep (Appendix B) profiles of stringprep 2922 Normative References 2924 [1] World Wide Web Consortium, "Extensible Markup Language (XML) 2925 1.0 (Second Edition)", W3C xml, October 2000, . 2928 [2] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 2929 Presence Protocol Requirements", RFC 2779, February 2000. 2931 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2932 Levels", BCP 14, RFC 2119, March 1997. 2934 [4] University of Southern California, "Transmission Control 2935 Protocol", RFC 793, September 1981, . 2938 [5] Internet Assigned Numbers Authority, "Internet Assigned Numbers 2939 Authority", January 1998, . 2941 [6] Harrenstien, K., Stahl, M. and E. Feinler, "DoD Internet host 2942 table specification", RFC 952, October 1985. 2944 [7] Braden, R., "Requirements for Internet Hosts - Application and 2945 Support", STD 3, RFC 1123, October 1989. 2947 [8] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile 2948 for Internationalized Domain Names (IDN)", RFC 3491, March 2949 2003. 2951 [9] Hoffman, P. and M. Blanchet, "Preparation of Internationalized 2952 Strings ("stringprep")", RFC 3454, December 2002. 2954 [10] World Wide Web Consortium, "Namespaces in XML", W3C xml-names, 2955 January 1999, . 2958 [11] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 2959 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 2960 1999. 2962 [12] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2964 [13] Myers, J., "Simple Authentication and Security Layer (SASL)", 2965 RFC 2222, October 1997. 2967 [14] Alvestrand, H., "IETF Policy on Character Sets and Languages", 2968 BCP 18, RFC 2277, January 1998. 2970 [15] Alvestrand, H., "Tags for the Identification of Languages", BCP 2971 47, RFC 3066, January 2001. 2973 [16] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2974 2279, January 1998. 2976 [17] International Organization for Standardization, "Information 2977 Technology - Universal Multiple-octet coded Character Set (UCS) 2978 - Amendment 2: UCS Transformation Format 8 (UTF-8)", ISO 2979 Standard 10646-1 Addendum 2, October 1996. 2981 [18] Linn, J., "Generic Security Service Application Program 2982 Interface, Version 2", RFC 2078, January 1997. 2984 [19] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 2985 specifying the location of services (DNS SRV)", RFC 2782, 2986 February 2000. 2988 Informative References 2990 [20] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging", 2991 draft-ietf-xmpp-im-17 (work in progress), September 2003. 2993 [21] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 2994 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 2995 HTTP/1.1", RFC 2616, June 1999. 2997 [22] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 2998 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 2999 1998, . 3001 [23] Mealling, M., "The IANA XML Registry", 3002 draft-mealling-iana-xmlns-registry-05 (work in progress), June 3003 2003. 3005 [24] Crispin, M., "Internet Message Access Protocol - Version 3006 4rev1", RFC 2060, December 1996. 3008 [25] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 3009 53, RFC 1939, May 1996. 3011 [26] Newman, C. and J. Myers, "ACAP -- Application Configuration 3012 Access Protocol", RFC 2244, November 1997. 3014 [27] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, 3015 June 1999. 3017 [28] Eastlake, D., "Domain Name System Security Extensions", RFC 3018 2535, March 1999. 3020 [29] Jabber Software Foundation, "Jabber Software Foundation", 3021 . 3023 Authors' Addresses 3025 Peter Saint-Andre 3026 Jabber Software Foundation 3028 EMail: stpeter@jabber.org 3030 Jeremie Miller 3031 Jabber Software Foundation 3033 EMail: jeremie@jabber.org 3035 Appendix A. Nodeprep 3037 A.1 Introduction 3039 This appendix defines the "Nodeprep" profile of stringprep (RFC 3454 3040 [9]). As such, it specifies processing rules that will enable users 3041 to enter internationalized node identifiers in XMPP and have the 3042 highest chance of getting the content of the strings correct. These 3043 processing rules are intended only for XMPP node identifiers (which 3044 are often associated with usernames), and are not intended for 3045 arbitrary text. 3047 This profile defines the following, as required by RFC 3454 [9]: 3049 o The intended applicability of the profile: internationalized node 3050 identifiers within XMPP 3052 o The character repertoire that is the input and output to 3053 stringprep: Unicode 3.2, specified in section 2 of this Appendix 3055 o The mappings used: specified in section 3 3057 o The Unicode normalization used: specified in section 4 3059 o The characters that are prohibited as output: specified in section 3060 5 3062 o Bidirectional character handling: specified in section 6 3064 A.2 Character Repertoire 3066 This profile uses Unicode 3.2 with the list of unassigned code points 3067 being Table A.1, both defined in Appendix A of RFC 3454 [9]. 3069 A.3 Mapping 3071 This profile specifies mapping using the following tables from RFC 3072 3454 [9]: 3074 Table B.1 3076 Table B.2 3078 A.4 Normalization 3080 This profile specifies using Unicode normalization form KC, as 3081 described in RFC 3454 [9]. 3083 A.5 Prohibited Output 3085 This profile specifies prohibiting use of the following tables from 3086 RFC 3454 [9]. 3088 Table C.1.1 3090 Table C.1.2 3092 Table C.2.1 3094 Table C.2.2 3096 Table C.3 3098 Table C.4 3100 Table C.5 3102 Table C.6 3104 Table C.7 3106 Table C.8 3108 Table C.9 3110 In addition, the following Unicode characters are also prohibited: 3112 #x22 (") 3114 #x26 (&) 3116 #x27 (') 3118 #x2F (/) 3120 #x3A (:) 3122 #x3C (<) 3124 #x3E (>) 3126 #x40 (@) 3128 A.6 Bidirectional Characters 3130 This profile specifies checking bidirectional strings as described in 3131 section 6 of RFC 3454 [9]. 3133 Appendix B. Resourceprep 3135 B.1 Introduction 3137 This appendix defines the "Resourceprep" profile of stringprep (RFC 3138 3454 [9]). As such, it specifies processing rules that will enable 3139 users to enter internationalized resource identifiers in XMPP and 3140 have the highest chance of getting the content of the strings 3141 correct. These processing rules are intended only for XMPP resource 3142 identifiers (which are often associated with session names), and are 3143 not intended for arbitrary text. 3145 This profile defines the following, as required by RFC 3454 [9]: 3147 o The intended applicability of the profile: internationalized 3148 resource identifiers within XMPP 3150 o The character repertoire that is the input and output to 3151 stringprep: Unicode 3.2, specified in section 2 of this Appendix 3153 o The mappings used: specified in section 3 3155 o The Unicode normalization used: specified in section 4 3157 o The characters that are prohibited as output: specified in section 3158 5 3160 o Bidirectional character handling: specified in section 6 3162 B.2 Character Repertoire 3164 This profile uses Unicode 3.2 with the list of unassigned code points 3165 being Table A.1, both defined in Appendix A of RFC 3454 [9]. 3167 B.3 Mapping 3169 This profile specifies mapping using the following tables from RFC 3170 3454 [9]: 3172 Table B.1 3174 B.4 Normalization 3176 This profile specifies using Unicode normalization form KC, as 3177 described in RFC 3454 [9]. 3179 B.5 Prohibited Output 3181 This profile specifies prohibiting use of the following tables from 3182 RFC 3454 [9]. 3184 Table C.1.2 3186 Table C.2.1 3188 Table C.2.2 3190 Table C.3 3192 Table C.4 3194 Table C.5 3196 Table C.6 3198 Table C.7 3200 Table C.8 3202 Table C.9 3204 B.6 Bidirectional Characters 3206 This profile specifies checking bidirectional strings as described in 3207 section 6 of RFC 3454 [9]. 3209 Appendix C. XML Schemas 3211 The following XML schemas are descriptive, not normative. For schemas 3212 defining the 'jabber:client' and 'jabber:server' namespaces, refer to 3213 XMPP IM [20]. 3215 C.1 Stream namespace 3217 3219 3225 3226 3227 3228 3229 3230 3233 3236 3237 3238 3239 3240 3241 3242 3243 3244 3246 3247 3248 3249 3253 3254 3255 3256 3257 3258 3259 3261 3265 3266 3267 3269 3271 C.2 Stream error namespace 3273 3275 3282 3285 3286 3287 3288 3289 3290 3291 3292 3293 3294 3295 3296 3297 3298 3299 3300 3301 3302 3303 3304 3305 3306 3307 3308 3310 3311 3312 3313 3314 3316 3317 3318 3319 3320 3322 3324 C.3 TLS namespace 3326 3328 3334 3335 3336 3337 3341 3342 3343 3345 3346 3347 3349 3350 3351 3352 3353 3355 3357 C.4 SASL namespace 3359 3361 3367 3368 3369 3370 3371 3372 3373 3375 3377 3378 3379 3382 3383 3385 3386 3387 3388 3390 3391 3392 3393 3394 3395 3396 3397 3398 3399 3400 3401 3402 3403 3404 3406 3407 3408 3409 3410 3411 3412 3413 3414 3416 3417 3418 3419 3420 3422 3424 C.5 Dialback namespace 3426 3428 3434 3435 3436 3437 3438 3439 3440 3441 3442 3443 3444 3445 3446 3447 3448 3449 3450 3451 3453 3454 3455 3456 3457 3458 3459 3460 3461 3462 3463 3464 3465 3466 3467 3468 3469 3470 3471 3473 3475 C.6 Stanza error namespace 3477 3479 3486 3489 3490 3491 3492 3493 3494 3495 3496 3497 3498 3499 3500 3501 3502 3503 3504 3505 3506 3508 3509 3510 3511 3512 3514 3515 3516 3517 3518 3520 3522 Appendix D. Differences Between Jabber and XMPP 3524 This section is non-normative. 3526 XMPP has been adapted from the protocols originally developed in the 3527 Jabber open-source community, which can be thought of as "XMPP 0.9". 3528 Because there exists a large installed base of Jabber implementations 3529 and deployments, it may be helpful to specify the key differences 3530 between Jabber and XMPP in order to expedite and encourage upgrades 3531 of those implementations and deployments to XMPP. This section 3532 summarizes the core differences, and the corresponding section of 3533 XMPP IM [20] summarizes the differences that relate specifically to 3534 instant messaging and presence applications. 3536 D.1 Authentication 3538 The client-server authentication protocol developed in the Jabber 3539 community uses a basic IQ interaction qualified by the 3540 'jabber:iq:auth' namespace (documentation of this protocol is 3541 contained in "JEP-0078: Non-SASL Authentication", published by the 3542 Jabber Software Foundation [29]). XMPP uses SASL for authentication, 3543 as defined in the Stream Authentication (Section 6) section of this 3544 document. 3546 The Jabber community does not currently possess an authentication 3547 protocol for server-to-server communications, only the Server 3548 Dialback (Section 7) protocol to prevent server spoofing. XMPP 3549 augments Server Dialback with a true server-to-server authentication 3550 protocol, as defined in the Stream Authentication (Section 6) section 3551 of this document. 3553 D.2 Channel Encryption 3555 It is common practice in the Jabber community to use SSL for channel 3556 encryption on ports other than 5222 and 5269 (the convention is to 3557 use ports 5223 and 5270). XMPP uses TLS over the IANA-registered 3558 ports for channel encryption, as defined in the Stream Encryption 3559 (Section 5) section of this document. 3561 D.3 JID Processing 3563 JID processing was somewhat loosely defined by the Jabber community 3564 (documentation of forbidden characters and case handling is contained 3565 in "JEP-0029: Definition of Jabber Identifiers", published by the 3566 Jabber Software Foundation [29]). XMPP defines two stringprep [9] 3567 profiles for JID processing: Nodeprep (Appendix A) and Resourceprep 3568 (Appendix B). 3570 D.4 Error Handling 3572 Stream-related errors are handled in the Jabber community via simple 3573 CDATA text in a element. In XMPP, stream-related 3574 errors are handled via an extensible mechanism defined in the Stream 3575 Errors (Section 4.6) section of this document. 3577 Stanza-related errors are handled in the Jabber community via 3578 HTTP-style error codes. In XMPP, stanza-related errors are handled 3579 via an extensible mechanism defined in the Stanza Errors (Section 3580 8.3) section of this document. (Documentation of a mapping between 3581 Jabber and XMPP error handling mechanisms is contained in "JEP-0086: 3582 Legacy Errors", published by the Jabber Software Foundation [29].) 3584 D.5 Internationalization 3586 Although use of UTF-8 has always been standard practice within the 3587 Jabber community, the community did not define mechanisms for 3588 specifying the language of human-readable text provided in CDATA 3589 sections. XMPP specifies the use of the 'xml:lang' attribute in such 3590 contexts, as defined in the xml:lang (Section 8.1.5) section of this 3591 document. 3593 D.6 Stream Version Attribute 3595 The Jabber community does not include a 'version' attribute in stream 3596 headers. XMPP specifies inclusion of that attribute, with a value of 3597 '1.0', as a way to signal support for the stream features 3598 (authentication, encryption, etc.) defined in the Version Support 3599 (Section 4.2.1) section of this document. 3601 Appendix E. Revision History 3603 Note to RFC Editor: please remove this entire appendix, and the 3604 corresponding entries in the table of contents, prior to publication. 3606 E.1 Changes from draft-ietf-xmpp-core-17 3608 o Specified that UTF-8 is the only allowable encoding. 3610 o Added stream errors for , , 3611 and , as well as a error for 3612 generic XML error conditions. 3614 o Folded Nodeprep and Resourceprep profiles into this document. 3616 o Moved most delivery handling rules from XMPP IM to XMPP Core. 3618 o Moved detailed stanza syntax descriptions from XMPP Core to XMPP 3619 IM. 3621 o Moved stanza schemas from XMPP Core to XMPP IM. 3623 E.2 Changes from draft-ietf-xmpp-core-16 3625 o Added and stream errors. 3627 o Changed the datatype for the and 3628 stream errors from 'xs:string' to 'empty'. 3630 o Further clarified server handling of the basic stanza kinds. 3632 o Further clarified character encoding rules per list discussion. 3634 o Specified meaning of version='1.0' flag in stream headers. 3636 o Added stream closure to SASL failure cases in order to mirror 3637 handling of TLS failures. 3639 o Added section on compliance requirements for server and client 3640 implementations. 3642 o Added non-normative section on differences between Jabber usage 3643 and XMPP specifications. 3645 E.3 Changes from draft-ietf-xmpp-core-15 3647 o Added and stream errors. 3649 o Added SASL error and clarified error. 3651 o Made 'id' required for IQ stanzas. 3653 E.4 Changes from draft-ietf-xmpp-core-14 3655 o Added SRV lookup for client-to-server communications. 3657 o Changed server SRV record to conform to RFC 2782; specifically, 3658 the service identifier was changed from 'jabber' to 3659 'jabber-server'. 3661 E.5 Changes from draft-ietf-xmpp-core-13 3663 o Clarified stream restart after successful TLS and SASL 3664 negotiation. 3666 o Clarified requirement for resolution of DNS hostnames. 3668 o Clarified text regarding namespaces. 3670 o Clarified examples regarding empty element. 3672 o Added several more SASL error conditions. 3674 o Changed stream error to and 3675 added to schema. 3677 o Made small editorial changes and fixed several schema errors. 3679 E.6 Changes from draft-ietf-xmpp-core-12 3681 o Moved server dialback to a separate section; clarified its 3682 security characteristics and its role in the protocol. 3684 o Adjusted error handling syntax and semantics per list discussion. 3686 o Further clarified length of node identifiers and total length of 3687 JIDs. 3689 o Documented message type='normal'. 3691 o Corrected several small errors in the TLS and SASL sections. 3693 o Corrected several errors in the schemas. 3695 E.7 Changes from draft-ietf-xmpp-core-11 3697 o Corrected several small errors in the TLS and SASL sections. 3699 o Made small editorial changes and fixed several schema errors. 3701 E.8 Changes from draft-ietf-xmpp-core-10 3703 o Adjusted TLS content regarding certificate validation process. 3705 o Specified that stanza error extensions for specific applications 3706 are to be properly namespaced children of the relevant descriptive 3707 element. 3709 o Clarified rules for inclusion of the 'id' attribute. 3711 o Specified that the 'xml:lang' attribute SHOULD be included (per 3712 list discussion). 3714 o Made small editorial changes and fixed several schema errors. 3716 E.9 Changes from draft-ietf-xmpp-core-09 3718 o Fixed several dialback error conditions. 3720 o Cleaned up rules regarding TLS and certificate processing based on 3721 off-list feedback. 3723 o Changed and elements to 3724 . 3726 o Added or modified several stream and stanza error conditions. 3728 o Specified only one child allowed for IQ, or two if type="error". 3730 o Fixed several errors in the schemas. 3732 E.10 Changes from draft-ietf-xmpp-core-08 3734 o Incorporated list discussion regarding addressing, SASL, TLS, TCP, 3735 dialback, namespaces, extensibility, and the meaning of 'ignore' 3736 for routers and recipients. 3738 o Specified dialback error conditions. 3740 o Made small editorial changes to address RFC Editor requirements. 3742 E.11 Changes from draft-ietf-xmpp-core-07 3744 o Made several small editorial changes. 3746 E.12 Changes from draft-ietf-xmpp-core-06 3748 o Added text regarding certificate validation in TLS negotiation per 3749 list discussion. 3751 o Clarified nature of XML restrictions per discussion with W3C, and 3752 moved XML Restrictions subsection under "XML Usage within XMPP". 3754 o Further clarified that XML streams are unidirectional. 3756 o Changed stream error and stanza error namespace names to conform 3757 to the format defined in The IETF XML Registry [23]. 3759 o Removed note to RFC Editor regarding provisional namespace names. 3761 E.13 Changes from draft-ietf-xmpp-core-05 3763 o Added as a stream error condition. 3765 o Adjusted security considerations per discussion at IETF 56 and on 3766 list. 3768 E.14 Changes from draft-ietf-xmpp-core-04 3770 o Added server-to-server examples for TLS and SASL. 3772 o Changed error syntax, rules, and examples based on list 3773 discussion. 3775 o Added schemas for the TLS, stream error, and stanza error 3776 namespaces. 3778 o Added note to RFC Editor regarding provisional namespace names. 3780 o Made numerous small editorial changes and clarified text 3781 throughout. 3783 E.15 Changes from draft-ietf-xmpp-core-03 3785 o Clarified rules and procedures for TLS and SASL. 3787 o Amplified stream error code syntax per list discussion. 3789 o Made numerous small editorial changes. 3791 E.16 Changes from draft-ietf-xmpp-core-02 3793 o Added dialback schema. 3795 o Removed all DTDs since schemas provide more complete definitions. 3797 o Added stream error codes. 3799 o Clarified error code "philosophy". 3801 E.17 Changes from draft-ietf-xmpp-core-01 3803 o Updated the addressing restrictions per list discussion and added 3804 references to the new Nodeprep and Resourceprep profiles. 3806 o Corrected error in Stream Authentication regarding 'version' 3807 attribute. 3809 o Made numerous small editorial changes. 3811 E.18 Changes from draft-ietf-xmpp-core-00 3813 o Added information about TLS from list discussion. 3815 o Clarified meaning of "ignore" based on list discussion. 3817 o Clarified information about Universal Character Set data and 3818 character encodings. 3820 o Provided base64-decoded information for examples. 3822 o Fixed several errors in the schemas. 3824 o Made numerous small editorial fixes. 3826 E.19 Changes from draft-miller-xmpp-core-02 3828 o Brought Streams Authentication section into line with discussion 3829 on list and at IETF 55 meeting. 3831 o Added information about the optional 'xml:lang' attribute per 3832 discussion on list and at IETF 55 meeting. 3834 o Specified that validation is neither required nor recommended, and 3835 that the formal definitions (DTDs and schemas) are included for 3836 descriptive purposes only. 3838 o Specified that the response to an IQ stanza of type "get" or "set" 3839 must be an IQ stanza of type "result" or "error". 3841 o Specified that compliant server implementations must process 3842 stanzas in order. 3844 o Specified that for historical reasons some server implementations 3845 may accept 'stream:' as the only valid namespace prefix on the 3846 root stream element. 3848 o Clarified the difference between 'jabber:client' and 3849 'jabber:server' namespaces, namely, that 'to' and 'from' 3850 attributes are required on all stanzas in the latter but not the 3851 former. 3853 o Fixed typo in Step 9 of the dialback protocol (changed db:result 3854 to db:verify). 3856 o Removed references to TLS pending list discussion. 3858 o Removed the non-normative appendix on OpenPGP usage pending its 3859 inclusion in a separate I-D. 3861 o Simplified the architecture diagram, removed most references to 3862 services, and removed references to the 'jabber:component:*' 3863 namespaces. 3865 o Noted that XMPP activity respects firewall administration 3866 policies. 3868 o Further specified the scope and uniqueness of the 'id' attribute 3869 in all stanza kinds and the element in message stanzas. 3871 o Nomenclature changes: (1) from "chunks" to "stanzas"; (2) from 3872 "host" to "server" and from "node" to "client" (except with regard 3873 to definition of the addressing scheme). 3875 Intellectual Property Statement 3877 The IETF takes no position regarding the validity or scope of any 3878 intellectual property or other rights that might be claimed to 3879 pertain to the implementation or use of the technology described in 3880 this document or the extent to which any license under such rights 3881 might or might not be available; neither does it represent that it 3882 has made any effort to identify any such rights. Information on the 3883 IETF's procedures with respect to rights in standards-track and 3884 standards-related documentation can be found in BCP-11. Copies of 3885 claims of rights made available for publication and any assurances of 3886 licenses to be made available, or the result of an attempt made to 3887 obtain a general license or permission for the use of such 3888 proprietary rights by implementors or users of this specification can 3889 be obtained from the IETF Secretariat. 3891 The IETF invites any interested party to bring to its attention any 3892 copyrights, patents or patent applications, or other proprietary 3893 rights which may cover technology that may be required to practice 3894 this standard. Please address the information to the IETF Executive 3895 Director. 3897 Full Copyright Statement 3899 Copyright (C) The Internet Society (2003). All Rights Reserved. 3901 This document and translations of it may be copied and furnished to 3902 others, and derivative works that comment on or otherwise explain it 3903 or assist in its implementation may be prepared, copied, published 3904 and distributed, in whole or in part, without restriction of any 3905 kind, provided that the above copyright notice and this paragraph are 3906 included on all such copies and derivative works. However, this 3907 document itself may not be modified in any way, such as by removing 3908 the copyright notice or references to the Internet Society or other 3909 Internet organizations, except as needed for the purpose of 3910 developing Internet standards in which case the procedures for 3911 copyrights defined in the Internet Standards process must be 3912 followed, or as required to translate it into languages other than 3913 English. 3915 The limited permissions granted above are perpetual and will not be 3916 revoked by the Internet Society or its successors or assignees. 3918 This document and the information contained herein is provided on an 3919 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3920 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3921 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3922 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3923 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3925 Acknowledgment 3927 Funding for the RFC Editor function is currently provided by the 3928 Internet Society.