idnits 2.17.1 draft-ietf-xmpp-core-11.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 are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1048 has weird spacing: '... it it MU...' == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Recipient: If a recipient receives a stanza that contains a child element it does not understand, it SHOULD ignore that specific XML data, i.e., it SHOULD not process it or present it to a user or associated application (if any). In particular: -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 27, 2003) is 7671 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '43' is mentioned on line 378, but not defined -- Looks like a reference, but probably isn't: 'RFCXXXX' on line 2409 -- 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') -- Unexpected draft version: The latest known version of draft-ietf-idn-nameprep is -10, but you're referring to -11. ** Obsolete normative reference: RFC 3454 (ref. '9') (Obsoleted by RFC 7564) == Outdated reference: A later version (-03) exists of draft-ietf-xmpp-nodeprep-02 -- Possible downref: Normative reference to a draft: ref. '10' == Outdated reference: A later version (-03) exists of draft-ietf-xmpp-resourceprep-02 -- Possible downref: Normative reference to a draft: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' ** Obsolete normative reference: RFC 2246 (ref. '13') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2818 (ref. '14') (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 2222 (ref. '15') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2831 (ref. '16') (Obsoleted by RFC 6331) ** Obsolete normative reference: RFC 3066 (ref. '17') (Obsoleted by RFC 4646, RFC 4647) ** Obsolete normative reference: RFC 2052 (ref. '18') (Obsoleted by RFC 2782) ** Obsolete normative reference: RFC 2279 (ref. '19') (Obsoleted by RFC 3629) ** Downref: Normative reference to an Informational RFC: RFC 2781 (ref. '20') -- Possible downref: Non-RFC (?) normative reference: ref. '21' ** Obsolete normative reference: RFC 2078 (ref. '22') (Obsoleted by RFC 2743) == Outdated reference: A later version (-22) exists of draft-ietf-xmpp-im-09 -- Obsolete informational reference (is this intentional?): RFC 2396 (ref. '24') (Obsoleted by RFC 3986) == Outdated reference: A later version (-05) exists of draft-mealling-iana-xmlns-registry-04 -- Obsolete informational reference (is this intentional?): RFC 2060 (ref. '26') (Obsoleted by RFC 3501) -- Obsolete informational reference (is this intentional?): RFC 2535 (ref. '30') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 2616 (ref. '31') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-09) exists of draft-ietf-xmpp-e2e-02 Summary: 14 errors (**), 0 flaws (~~), 12 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft J. Miller 4 Expires: October 26, 2003 Jabber Software Foundation 5 April 27, 2003 7 XMPP Core 8 draft-ietf-xmpp-core-11 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that other 17 groups may also distribute working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at http:// 25 www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 This Internet-Draft will expire on October 26, 2003. 32 Copyright Notice 34 Copyright (C) The Internet Society (2003). All Rights Reserved. 36 Abstract 38 This document describes the core features of the Extensible Messaging 39 and Presence Protocol (XMPP), a protocol for streaming XML elements 40 in order to exchange messages and presence information in close to 41 real time. XMPP is used mainly for the purpose of building instant 42 messaging (IM) and presence applications, such as the servers and 43 clients that comprise the Jabber network. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 48 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 49 1.2 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5 50 1.3 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . 5 51 1.4 Intellectual Property Notice . . . . . . . . . . . . . . . . 5 52 2. Generalized Architecture . . . . . . . . . . . . . . . . . . 6 53 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 2.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 2.3 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 2.4 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 7 57 2.5 Network . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 3. Addressing Scheme . . . . . . . . . . . . . . . . . . . . . 8 59 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.2 Domain Identifier . . . . . . . . . . . . . . . . . . . . . 8 61 3.3 Node Identifier . . . . . . . . . . . . . . . . . . . . . . 8 62 3.4 Resource Identifier . . . . . . . . . . . . . . . . . . . . 9 63 4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . 10 64 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.2 Stream Attributes . . . . . . . . . . . . . . . . . . . . . 11 66 4.3 Namespace Declarations . . . . . . . . . . . . . . . . . . . 12 67 4.4 Stream Features . . . . . . . . . . . . . . . . . . . . . . 13 68 4.5 Stream Errors . . . . . . . . . . . . . . . . . . . . . . . 14 69 4.5.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 70 4.5.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 4.5.3 Conditions . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 4.5.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . . 16 73 4.6 Simple Streams Example . . . . . . . . . . . . . . . . . . . 16 74 5. Stream Encryption . . . . . . . . . . . . . . . . . . . . . 19 75 5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 5.2 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . 20 77 5.3 Client-to-Server Example . . . . . . . . . . . . . . . . . . 21 78 5.4 Server-to-Server Example . . . . . . . . . . . . . . . . . . 23 79 6. Stream Authentication . . . . . . . . . . . . . . . . . . . 26 80 6.1 SASL Authentication . . . . . . . . . . . . . . . . . . . . 26 81 6.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 26 82 6.1.2 Narrative . . . . . . . . . . . . . . . . . . . . . . . . . 27 83 6.1.3 SASL Definition . . . . . . . . . . . . . . . . . . . . . . 29 84 6.1.4 Client-to-Server Example . . . . . . . . . . . . . . . . . . 30 85 6.1.5 Server-to-Server Example . . . . . . . . . . . . . . . . . . 32 86 6.2 Dialback Authentication . . . . . . . . . . . . . . . . . . 35 87 6.2.1 Dialback Protocol . . . . . . . . . . . . . . . . . . . . . 37 88 7. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . 42 89 7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 42 90 7.2 Common Attributes . . . . . . . . . . . . . . . . . . . . . 42 91 7.2.1 to . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 92 7.2.2 from . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 93 7.2.3 id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 94 7.2.4 type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 95 7.2.5 xml:lang . . . . . . . . . . . . . . . . . . . . . . . . . . 44 96 7.3 Message Stanzas . . . . . . . . . . . . . . . . . . . . . . 44 97 7.3.1 Types of Message . . . . . . . . . . . . . . . . . . . . . . 44 98 7.3.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 44 99 7.4 Presence Stanzas . . . . . . . . . . . . . . . . . . . . . . 46 100 7.4.1 Types of Presence . . . . . . . . . . . . . . . . . . . . . 46 101 7.4.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 47 102 7.5 IQ Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 48 103 7.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 48 104 7.5.2 Types of IQ . . . . . . . . . . . . . . . . . . . . . . . . 49 105 7.5.3 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 49 106 7.6 Extended Namespaces . . . . . . . . . . . . . . . . . . . . 50 107 7.7 Stanza Errors . . . . . . . . . . . . . . . . . . . . . . . 51 108 7.7.1 Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 109 7.7.2 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 110 7.7.3 Conditions . . . . . . . . . . . . . . . . . . . . . . . . . 52 111 7.7.4 Extensibility . . . . . . . . . . . . . . . . . . . . . . . 53 112 8. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 54 113 8.1 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 54 114 8.2 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . 54 115 8.3 Validation . . . . . . . . . . . . . . . . . . . . . . . . . 54 116 8.4 Character Encodings . . . . . . . . . . . . . . . . . . . . 55 117 8.5 Inclusion of Text Declaration . . . . . . . . . . . . . . . 55 118 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 56 119 9.1 XML Namespace Name for TLS Data . . . . . . . . . . . . . . 56 120 9.2 XML Namespace Name for SASL Data . . . . . . . . . . . . . . 56 121 9.3 XML Namespace Name for Stream Errors . . . . . . . . . . . . 56 122 9.4 XML Namespace Name for Stanza Errors . . . . . . . . . . . . 57 123 9.5 Existing Registrations . . . . . . . . . . . . . . . . . . . 57 124 10. Internationalization Considerations . . . . . . . . . . . . 58 125 11. Security Considerations . . . . . . . . . . . . . . . . . . 59 126 11.1 High Security . . . . . . . . . . . . . . . . . . . . . . . 59 127 11.2 Client-to-Server Communications . . . . . . . . . . . . . . 59 128 11.3 Server-to-Server Communications . . . . . . . . . . . . . . 60 129 11.4 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . 60 130 11.5 Mandatory to Implement Technologies . . . . . . . . . . . . 60 131 Normative References . . . . . . . . . . . . . . . . . . . . 61 132 Informative References . . . . . . . . . . . . . . . . . . . 63 133 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 63 134 A. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . 65 135 A.1 Streams namespace . . . . . . . . . . . . . . . . . . . . . 65 136 A.2 TLS namespace . . . . . . . . . . . . . . . . . . . . . . . 66 137 A.3 SASL namespace . . . . . . . . . . . . . . . . . . . . . . . 66 138 A.4 Dialback namespace . . . . . . . . . . . . . . . . . . . . . 67 139 A.5 Client namespace . . . . . . . . . . . . . . . . . . . . . . 68 140 A.6 Server namespace . . . . . . . . . . . . . . . . . . . . . . 72 141 A.7 Stream error namespace . . . . . . . . . . . . . . . . . . . 75 142 A.8 Stanza error namespace . . . . . . . . . . . . . . . . . . . 76 143 B. Revision History . . . . . . . . . . . . . . . . . . . . . . 78 144 B.1 Changes from draft-ietf-xmpp-core-09 . . . . . . . . . . . . 78 145 B.2 Changes from draft-ietf-xmpp-core-08 . . . . . . . . . . . . 78 146 B.3 Changes from draft-ietf-xmpp-core-07 . . . . . . . . . . . . 78 147 B.4 Changes from draft-ietf-xmpp-core-06 . . . . . . . . . . . . 78 148 B.5 Changes from draft-ietf-xmpp-core-05 . . . . . . . . . . . . 79 149 B.6 Changes from draft-ietf-xmpp-core-04 . . . . . . . . . . . . 79 150 B.7 Changes from draft-ietf-xmpp-core-03 . . . . . . . . . . . . 79 151 B.8 Changes from draft-ietf-xmpp-core-02 . . . . . . . . . . . . 79 152 B.9 Changes from draft-ietf-xmpp-core-01 . . . . . . . . . . . . 80 153 B.10 Changes from draft-ietf-xmpp-core-00 . . . . . . . . . . . . 80 154 B.11 Changes from draft-miller-xmpp-core-02 . . . . . . . . . . . 80 155 Intellectual Property and Copyright Statements . . . . . . . 82 157 1. Introduction 159 1.1 Overview 161 The Extensible Messaging and Presence Protocol (XMPP) is an open XML 162 [1] protocol for near-real-time messaging, presence, and 163 request-response services. The basic syntax and semantics were 164 developed originally within the Jabber open-source community, mainly 165 in 1999. In 2002, the XMPP WG was chartered with developing an 166 adaptation of the Jabber protocol that would be suitable as an IETF 167 instant messaging and presence technology. As a result of work by the 168 XMPP WG, the current document defines the core features of XMPP; XMPP 169 IM [23] defines the extensions required to provide the instant 170 messaging (IM) and presence functionality defined in RFC 2779 [2]. 172 1.2 Terminology 174 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 175 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 176 "OPTIONAL" in this document are to be interpreted as described in RFC 177 2119 [3]. 179 1.3 Discussion Venue 181 The authors welcome discussion and comments related to the topics 182 presented in this document. The preferred forum is the 183 mailing list, for which archives and subscription 184 information are available at . 187 1.4 Intellectual Property Notice 189 This document is in full compliance with all provisions of Section 10 190 of RFC 2026. Parts of this specification use the term "jabber" for 191 identifying namespaces and other protocol syntax. Jabber[tm] is a 192 registered trademark of Jabber, Inc. Jabber, Inc. grants permission 193 to the IETF for use of the Jabber trademark in association with this 194 specification and its successors, if any. 196 2. Generalized Architecture 198 2.1 Overview 200 Although XMPP is not wedded to any specific network architecture, to 201 this point it has usually been implemented via a typical 202 client-server architecture, wherein a client utilizing XMPP accesses 203 a server over a TCP [4] socket. 205 The following diagram provides a high-level overview of this 206 architecture (where "-" represents communications that use XMPP and 207 "=" represents communications that use any other protocol). 209 C1 - S1 - S2 - C3 210 / \ 211 C2 - G1 = FN1 = FC1 213 The symbols are as follows: 215 o C1, C2, C3 -- XMPP clients 217 o S1, S2 -- XMPP servers 219 o G1 -- A gateway that translates between XMPP and the protocol(s) 220 used on a foreign (non-XMPP) messaging network 222 o FN1 -- A foreign messaging network 224 o FC1 -- A client on a foreign messaging network 226 2.2 Server 228 A server acts as an intelligent abstraction layer for XMPP 229 communications. Its primary responsibilities are to manage 230 connections from or sessions for other entities (in the form of XML 231 streams to and from authorized clients, servers, and other entities) 232 and to route appropriately-addressed XML data "stanzas" among such 233 entities over XML streams. Most XMPP-compliant servers also assume 234 responsibility for the storage of data that is used by clients (e.g., 235 contact lists for users of XMPP-based IM applications); in this case, 236 the XML data is processed directly by the server itself on behalf of 237 the client and is not routed to another entity. Compliant server 238 implementations MUST ensure in-order processing of XML stanzas 239 between any two entities. 241 2.3 Client 242 Most clients connect directly to a server over a TCP socket and use 243 XMPP to take full advantage of the functionality provided by a server 244 and any associated services. Although there is no necessary coupling 245 of an XML stream to a TCP socket (e.g., a client COULD connect via 246 HTTP polling or some other mechanism), this specification defines a 247 binding for XMPP to TCP only. Multiple resources (e.g., devices or 248 locations) MAY connect simultaneously to a server on behalf of each 249 authorized client, with each resource connecting over a discrete TCP 250 socket and differentiated by the resource identifier of a JID 251 (Section 3) (e.g., user@domain/home vs. user@domain/work). The port 252 registered with the IANA [5] for connections between a Jabber client 253 and a Jabber server is 5222. 255 2.4 Gateway 257 A gateway is a special-purpose server-side service whose primary 258 function is to translate XMPP into the protocol used by a foreign 259 (non-XMPP) messaging system, as well as to translate the return data 260 back into XMPP. Examples are gateways to Internet Relay Chat (IRC), 261 Short Message Service (SMS), SMTP, and legacy instant messaging 262 networks such as AIM, ICQ, MSN Messenger, and Yahoo! Instant 263 Messenger. Communications between gateways and servers, and between 264 gateways and the foreign messaging system, are not defined in this 265 document. 267 2.5 Network 269 Because each server is identified by a network address (typically a 270 DNS hostname) and because server-to-server communications are a 271 straightforward extension of the client-to-server protocol, in 272 practice the system consists of a network of servers that 273 inter-communicate. Thus user-a@domain1 is able to exchange messages, 274 presence, and other information with user-b@domain2. This pattern is 275 familiar from messaging protocols (such as SMTP) that make use of 276 network addressing standards. There are two methods for negotiating a 277 connection between any two servers: primarily SASL authentication 278 (Section 6.1) and secondarily server dialback (Section 6.2). 280 3. Addressing Scheme 282 3.1 Overview 284 An entity is anything that can be considered a network endpoint 285 (i.e., an ID on the network) and that can communicate using XMPP. All 286 such entities are uniquely addressable in a form that is consistent 287 with RFC 2396 [24]. In particular, a valid Jabber Identifier (JID) 288 contains a set of ordered elements formed of a domain identifier, 289 node identifier, and resource identifier in the following format: 290 [node@]domain[/resource]. 292 All JIDs are based on the foregoing structure. The most common use of 293 this structure is to identify an IM user, the server to which the 294 user connects, and the user's active session or connection (e.g., a 295 specific client) in the form of user@domain/resource. However, node 296 types other than clients are possible; for example, a specific chat 297 room offered by a multi-user chat service could be addressed as 298 (where "room" is the name of the chat room and 299 "service" is the hostname of the multi-user chat service) and a 300 specific occupant of such a room could be addressed as (where "nick" is the occupant's room nickname). Many other JID 302 types are possible (e.g., could be a server-side 303 script or service). 305 3.2 Domain Identifier 307 The domain identifier is the primary identifier and is the only 308 REQUIRED element of a JID (a mere domain identifier is a valid JID). 309 It usually represents the network gateway or "primary" server to 310 which other entities connect for XML routing and data management 311 capabilities. However, the entity referenced by a domain identifier 312 is not always a server, and may be a service that is addressed as a 313 subdomain of a server and that provides functionality above and 314 beyond the capabilities of a server (a multi-user chat service, a 315 user directory, a gateway to a foreign messaging system, etc.). 317 The domain identifier for every server or service that will 318 communicate over a network SHOULD resolve to a Fully Qualified Domain 319 Name. A domain identifier MUST conform to RFC 952 [6] and RFC 1123 320 [7]. A domain identifier MUST be no more than 1023 bytes in length 321 and MUST conform to the nameprep [8] profile of stringprep [9]. 323 3.3 Node Identifier 325 The node identifier is an optional secondary identifier. It usually 326 represents the entity requesting and using network access provided by 327 the server or gateway (i.e., a client), although it can also 328 represent other kinds of entities (e.g., a multi-user chat room 329 associated with a multi-user chat service). The entity represented by 330 a node identifier is addressed within the context of a specific 331 domain; within IM applications of XMPP this address is called a "bare 332 JID" and is of the form . 334 A node identifier MUST be no more than 1023 bytes in length and MUST 335 conform to the nodeprep [10] profile of stringprep [9]. 337 3.4 Resource Identifier 339 The resource identifier is an optional tertiary identifier, which may 340 modify either a "user@domain" or mere "domain" address. It usually 341 represents a specific session, connection (e.g., a device or 342 location), or object (e.g., a participant in a multi-user chat room) 343 belonging to the entity associated with a node identifier. A resource 344 identifier is typically defined by a client implementation and is 345 opaque to both servers and other clients. An entity may maintain 346 multiple resources simultaneously. 348 A resource identifier MUST be no more than 1023 bytes in length and 349 MUST conform to the resourceprep [11] profile of stringprep [9]. 351 4. XML Streams 353 4.1 Overview 355 Two fundamental concepts make possible the rapid, asynchronous 356 exchange of relatively small payloads of structured information 357 between presence-aware entities: XML streams and XML stanzas. The 358 terms may be defined as follows: 360 Definition of XML stream: An XML stream is a container for the 361 exchange of XML elements between any two entities over a network. 362 An XML stream is negotiated from an initiating entity (usually a 363 client or server) to a receiving entity (usually a server), 364 normally over a TCP socket, and corresponds to the initiating 365 entity's "session" with the receiving entity. The start of the XML 366 stream is denoted unambiguously by an opening XML tag 367 with appropriate attributes and namespace declarations, and the 368 end of the XML stream is denoted unambiguously be a closing XML tag. An XML stream is unidirectional; in order to enable 370 bidirectional information exchange, the initiating entity and 371 receiving entity must negotiate one stream in each direction, 372 normally over the same TCP connection. 374 Definition of XML stanza: An XML stanza is a discrete semantic unit 375 of structured information that is sent from one entity to another 376 over an XML stream. An XML stanza exists at the direct child level 377 of the root element and is said to be well-balanced if 378 it matches production [43] content of the XML specification [1]). 379 The start of any XML stanza is denoted unambiguously by the 380 element start tag at depth=1 (e.g., ), and the end of 381 any XML stanza is denoted unambiguously by the corresponding close 382 tag at depth=1 (e.g., ). An XML stanza MAY contain 383 child elements (with accompanying attributes, elements, and CDATA) 384 as necessary in order to convey the desired information. 386 Consider the example of a client's session with a server. In order to 387 connect to a server, a client must initiate an XML stream by sending 388 an opening tag to the server, optionally preceded by a text 389 declaration specifying the XML version supported and the character 390 encoding. The server SHOULD then reply with a second XML stream back 391 to the client, again optionally preceded by a text declaration. Once 392 the client has authenticated with the server (see Section 6), the 393 client MAY send an unlimited number of XML stanzas over the stream to 394 any recipient on the network. When the client desires to close the 395 stream, it simply sends a closing tag to the server 396 (alternatively, the session may be closed by the server), after which 397 both the client and server SHOULD close the underlying TCP connection 398 as well. 400 Those who are accustomed to thinking of XML in a document-centric 401 manner may wish to view a client's session with a server as 402 consisting of two open-ended XML documents: one from the client to 403 the server and one from the server to the client. From this 404 perspective, the root element can be considered the 405 document entity for each "document", and the two "documents" are 406 built up through the accumulation of XML stanzas sent over the two 407 XML streams. However, this perspective is a convenience only, and 408 XMPP does not deal in documents but in XML streams and XML stanzas. 410 In essence, then, an XML stream acts as an envelope for all the XML 411 stanzas sent during a session. We can represent this graphically as 412 follows: 414 |-------------------| 415 | | 416 |-------------------| 417 | | 418 | | 419 | | 420 |-------------------| 421 | | 422 | | 423 | | 424 |-------------------| 425 | | 426 | | 427 | | 428 |-------------------| 429 | ... | 430 |-------------------| 431 | | 432 |-------------------| 434 4.2 Stream Attributes 436 The attributes of the stream element are as follows: 438 o to -- The 'to' attribute SHOULD be used only in the XML stream 439 header from the initiating entity to the receiving entity, and 440 MUST be set to the XMPP address of the receiving entity. There 441 SHOULD be no 'to' attribute set in the XML stream header by which 442 the receiving entity replies to the initiating entity; however, if 443 a 'to' attribute is included, it SHOULD be silently ignored by the 444 initiating entity. 446 o from -- The 'from' attribute SHOULD be used only in the XML stream 447 header from the receiving entity to the initiating entity, and 448 MUST be set to the XMPP address of the receiving entity granting 449 access to the initiating entity. There SHOULD be no 'from' 450 attribute on the XML stream header sent from the initiating entity 451 to the receiving entity; however, if a 'from' attribute is 452 included, it SHOULD be silently ignored by the receiving entity. 454 o id -- The 'id' attribute SHOULD be used only in the XML stream 455 header from the receiving entity to the initiating entity. This 456 attribute is a unique identifier created by the receiving entity 457 to function as a session key for the initiating entity's session 458 with the receiving entity. There SHOULD be no 'id' attribute on 459 the XML stream header sent from the initiating entity to the 460 receiving entity; however, if an 'id' attribute is included, it 461 SHOULD be silently ignored by the receiving entity. 463 o version -- The 'version' attribute MAY be used in the XML stream 464 header from the initiating entity to the receiving entity in order 465 signal compliance with the protocol defined herein; this is done 466 by setting the value of the attribute to "1.0". If the initiating 467 entity includes the version attribute and the receiving entity 468 supports XMPP 1.0, the receiving entity MUST reciprocate by 469 including the attribute in its response. 471 We can summarize these values as follows: 473 | initiating to receiving | receiving to initiating 474 ------------------------------------------------------------ 475 to | hostname of receiver | silently ignored 476 from | silently ignored | hostname of receiver 477 id | silently ignored | session key 478 version | signals XMPP 1.0 support | signals XMPP 1.0 support 480 4.3 Namespace Declarations 482 The stream element MAY contain namespace declarations as defined in 483 the XML namespaces specification [12]. 485 A stream namespace declaration (e.g., 'xmlns:stream') is REQUIRED in 486 both XML streams. A compliant entity SHOULD accept any namespace 487 prefix on the element; however, for historical reasons some 488 entities MAY accept only a 'stream' prefix, resulting in the use of a 489 element as the stream root. The name of the stream 490 namespace MUST be "http://etherx.jabber.org/streams". 492 A default namespace declaration ('xmlns') is REQUIRED and is used in 493 both XML streams in order to define the allowable first-level 494 children of the root stream element for both streams. This namespace 495 declaration MUST be the same for the initiating stream and the 496 responding stream so that both streams are scoped consistently. The 497 default namespace declaration applies to the stream and all stanzas 498 sent within a stream (unless explicitly scoped by another namespace). 500 Since XML streams function as containers for any XML stanzas sent 501 asynchronously between network endpoints, it should be possible to 502 scope an XML stream with any default namespace declaration (i.e., it 503 should be possible to send any properly-namespaced XML stanza over an 504 XML stream). At a minimum, a compliant implementation MUST support 505 the following two namespaces (for historical reasons, some 506 implementations MAY support only these two default namespaces): 508 o jabber:client -- this default namespace is declared when the 509 stream is used for communications between a client and a server 511 o jabber:server -- this default namespace is declared when the 512 stream is used for communications between two servers 514 The jabber:client and jabber:server namespaces are nearly identical 515 but are used in different contexts (client-to-server communications 516 for jabber:client and server-to-server communications for 517 jabber:server). The only difference between the two is that the 'to' 518 and 'from' attributes are OPTIONAL on stanzas sent within 519 jabber:client, whereas they are REQUIRED on stanzas sent within 520 jabber:server. If a compliant implementation accepts a stream that is 521 scoped by the 'jabber:client' or 'jabber:server' namespace, it MUST 522 support all three core stanza types (message, presence, and IQ) as 523 described herein and defined in the schema. 525 4.4 Stream Features 527 The root stream element MAY contain a features child element (e.g., 528 if the stream namespace prefix is 'stream'). This 529 is used to communicate generic stream-level capabilities including 530 stream-level features that can be negotiated as the streams are set 531 up. If the initiating entity sends a "version='1.0'" flag in its 532 initiating stream element, the receiving entity MUST send a features 533 child element to the initiating entity if there are any capabilities 534 that need to be advertised or features that can be negotiated for the 535 stream. Currently this is used for SASL and TLS negotiation only, but 536 it could be used for other negotiable features in the future (usage 537 is defined under Stream Encryption (Section 5) and Stream 538 Authentication (Section 6) below). If an entity does not understand 539 or support some features, it SHOULD silently ignore them. 541 4.5 Stream Errors 543 The root stream element MAY contain an error child element (e.g., 544 if the stream namespace prefix is 'stream'). The 545 error child MUST be sent by a compliant entity (usually a server 546 rather than a client) if it perceives that a stream-level error has 547 occurred. 549 4.5.1 Rules 551 The following rules apply to stream-level errors: 553 o It is assumed that all stream-level errors are unrecoverable; 554 therefore, if an error occurs at the level of the stream, the 555 entity that detects the error MUST send a stream error to the 556 other entity, send a closing tag, and close the 557 underlying TCP connection. 559 o If the error occurs while the stream is being set up, the 560 receiving entity MUST still send the opening and closing stream 561 tags and include the error element as a child of the stream 562 element. In this case, if the initiating entity provides an 563 unknown host in the 'to' attribute (or provides no 'to' attribute 564 at all), the server SHOULD provide the server's authoritative 565 hostname in the 'from' attribute of the stream header sent before 566 termination. 568 4.5.2 Syntax 570 The syntax for stream errors is as follows: 572 573 574 575 576 578 The value of the 'class' attribute must be one of the following: 580 o address -- the condition relates to the JID or domain to which the 581 stream was addressed 583 o format -- the condition relates to XML format or structure 585 o redirect -- the condition relates to a host redirection 587 o server -- the condition relates to the internal state of the 588 server 590 The element MUST contain a child element that specifies 591 a particular stream-level error condition, as defined in the next 592 section. (Note: the XML namespace name 593 'urn:ietf:params:xml:ns:xmpp-streams' that scopes the 594 element adheres to the format defined in The IETF XML Registry [25].) 596 4.5.3 Conditions 598 The following stream-level error conditions are defined: 600 o -- the value of the 'to' attribute provided by the 601 initiating entity in the stream header corresponds to a hostname 602 that is no longer hosted by the server; the associated class is 603 "address". 605 o -- the value of the 'to' attribute provided by the 606 initiating entity in the stream header does not correspond to a 607 hostname that is hosted by the server; the associated class is 608 "address". 610 o -- the server has experienced a 611 misconfiguration or an otherwise-undefined internal server error 612 that prevents it from servicing the stream; the associated class 613 is "server". 615 o -- the stream ID or dialback ID is invalid or does 616 not match an ID previously provided; the associated class is 617 "format". 619 o -- the stream namespace name is something 620 other than "http://etherx.jabber.org/streams" or the dialback 621 namespace name is something other than "jabber:server:dialback"; 622 the associated class is "format". 624 o -- the hostname provided in a 'from' address 625 does not match the hostname (or any validated domain) negotiated 626 via SASL or dialback; the associated class is "address". 628 o -- the entity does not possess sufficient 629 privilegs to perform the desired action; the associated class is 630 "access". 632 o -- the server is unable to properly 633 connect to a remote resource that is required for authentication 634 or authorization; the associated class is "server". 636 o -- the server is resource-contrained and is 637 unable to service the stream; the associated class is "server". 639 o -- the server will not provide service to the 640 initiating entity but is redirecting traffic to another host; this 641 element SHOULD contain CDATA specifying the alternate hostname or 642 IP address to which the initiating entity MAY attempt to connect; 643 the associated class is "redirect". 645 o -- the server is being shut down and all active 646 streams are being closed; the associated class is "server". 648 o -- the initiating entity has sent a 649 first-level child of the stream that is not supported by the 650 server; the associated class is "format". 652 o -- the value of the 'version' attribute 653 provided by the initiating entity in the stream header specifies a 654 version of XMPP that is not supported by the server; this element 655 MAY contain CDATA specifying the XMPP version(s) supported by the 656 server; the associated class is "format". 658 o -- the initiating entity has sent XML that 659 is not well-formed as defined by the XML specification [1]; the 660 associated class is "format". 662 4.5.4 Extensibility 664 If desired, an XMPP application MAY provide custom error information; 665 this MUST be contained in a properly-namespaced child of the 666 element (i.e., the namespace name MUST NOT be one of the 667 namespace names defined herein). 669 4.6 Simple Streams Example 671 The following is a stream-based session of a client on a server 672 (where the "C" lines are sent from the client to the server, and the 673 "S" lines are sent from the server to the client): 675 A basic session: 677 C: 678 683 S: 684 690 ... authentication ... 691 C: 693 C: Art thou not Romeo, and a Montague? 694 C: 695 S: 697 S: Neither, fair saint, if either thee dislike. 698 S: 699 C: 700 S: 701 A session gone bad: 703 C: 704 709 S: 710 716 ... authentication ... 717 C: Bad XML, no closing body tag! 718 S: 719 720 721 722 723 S: 725 5. Stream Encryption 727 5.1 Overview 729 XMPP includes a method for securing the stream from tampering and 730 eavesdropping. This channel encryption method makes use of the 731 Transport Layer Security (TLS) [13] protocol, along with a "STARTTLS" 732 extension that is modelled on similar extensions for the IMAP [26], 733 POP3 [27], and ACAP [28] protocols as described in RFC 2595 [29]. The 734 namespace identifier for the STARTTLS extension is 735 'urn:ietf:params:xml:ns:xmpp-tls'. 737 TLS SHOULD be used between any initiating entity and any receiving 738 entity (e.g., a stream from a client to a server or from one server 739 to another). An administrator of a given domain MAY require use of 740 TLS for either or both client-to-server communications and 741 server-to-server communications. Servers SHOULD use TLS betweeen two 742 domains for the purpose of securing server-to-server communcations. 743 When the remote domain is already known, the server can verify the 744 credentials of the known domain by comparing known keys or 745 certificates. When the remote domain is not recognized, it may still 746 be possible to verify a certificate if it is signed by a common 747 trusted authority. Even if there is no way to verify certificates 748 (e.g., an unknown domain with a self-signed certificate, or a 749 certificate signed by an unrecognized authority), if the servers 750 choose to communicate despite the lack of verified credentials, TLS 751 still SHOULD be used to provide encryption. 753 The following business rules apply: 755 1. An initiating entity that complies with this specification MUST 756 include the "version='1.0'" flag in the initiating stream header. 758 2. When a receiving entity that complies with this specification 759 receives an initiating stream header that includes the 760 "version='1.0'" flag, after sending a stream header in reply it 761 MUST also send a element scoped by the 762 'urn:ietf:params:xml:ns:xmpp-tls' namespace as well as the list 763 of other stream features it supports. 765 3. If the initiating entity chooses to use TLS for stream 766 encryption, TLS negotiation MUST be completed before proceeding 767 to SASL negotiation. 769 4. The initiating entity MUST validate the certificate presented by 770 the receiving entity: 772 Case 1 -- The initiating entity has been configured with a set of 773 trusted root certificates: Normal certificate validation 774 processing is appropriate, and SHOULD follow the rules defined 775 for HTTP over TLS [14]. The trusted roots may be either a 776 well-known public set or a manually configured Root CA (e.g., 777 an organization's own Certificate Authority or a self-signed 778 Root CA for the service as described under High Security 779 (Section 11.1)). This case is RECOMMENDED. 781 Case 2 -- The initiating entity has been configured with the 782 receiving entity's self-signed service certificate: Simple 783 comparison of public keys is appropriate. This case is NOT 784 RECOMMENDED (see High Security (Section 11.1) for details). 786 If the above methods fail, the certificate SHOULD be presented to 787 a user for approval; if presented, the receiver MUST deliver the 788 entire certificate chain to the user, who SHOULD be given the 789 option to store the Root CA certificate (not the service or End 790 Entity certificate) and to not be queried again regarding 791 acceptance of the certificate for some reasonable period of time. 793 5. If the TLS negotiation is successful, the receiving entity MUST 794 discard any knowledge obtained from the initiating entity before 795 TLS takes effect. 797 6. If the TLS negotiation is successful, the initiating entity MUST 798 discard any knowledge obtained from the receiving entity before 799 TLS takes effect. 801 7. If the TLS negotiation is successful, the receiving entity MUST 802 NOT offer the STARTTLS extension to the initiating entity along 803 with the other stream features that are offered when the stream 804 is restarted. 806 8. If the TLS negotiation results in success, the initiating entity 807 SHOULD continue with SASL negotiation. 809 9. If the TLS negotiation results in failure, the receiving entity 810 MUST terminate both the XML stream and the underlying TCP 811 connection. 813 5.2 Narrative 815 When an initiating entity secures a stream with a receiving entity, 816 the steps involved are as follows: 818 1. The initiating entity opens a TCP connection and initiates the 819 stream by sending the opening XML stream header to the receiving 820 entity, including the "version='1.0'" flag. 822 2. The receiving entity responds by opening a TCP connection and 823 sending an XML stream header to the initiating entity. 825 3. The receiving entity offers the STARTTLS extension to the 826 initiating entity by sending it along with the list of supported 827 stream features. 829 4. The initiating entity issues the STARTTLS command to instruct the 830 receiving entity that it wishes to begin a TLS negotiation to 831 secure the stream. 833 5. The receiving entity MUST reply with either a element 834 or a element scoped by the 835 'urn:ietf:params:xml:ns:xmpp-tls' namespace, but keep the 836 underlying TCP connection open. 838 6. The initiating entity begins a TLS negotiation in accordance with 839 RFC 2246 [13]. Upon completion of the negotiation, the initiating 840 entity initiates a new stream by sending a new opening XML stream 841 header to the receiving entity. 843 7. The receiving entity responds by sending an XML stream header to 844 the initiating entity along with the remaining available features 845 (but NOT including the STARTTLS element). 847 5.3 Client-to-Server Example 849 The following example shows the data flow for a client securing a 850 stream using STARTTLS (the IANA registers port 5222 for 851 client-to-server communications using XMPP/Jabber, but another port 852 MAY be used). 854 Step 1: Client initiates stream to server: 856 862 Step 2: Server responds by sending a stream tag to the client: 864 870 Step 3: Server sends the STARTTLS extension to the client along with 871 authentication mechanisms and any other stream features (if TLS is 872 required for interaction with this server, the server SHOULD signal 873 that fact by including a element as a child of the 874 element): 876 877 878 879 880 881 DIGEST-MD5 882 PLAIN 883 884 886 Step 4: Client sends the STARTTLS command to the server: 888 890 Step 5: Server informs client to proceed: 892 894 Step 5 (alt): Server informs client that TLS negotiation has failed 895 and closes stream: 897 898 900 Step 6: Client and server complete TLS negotiation over the existing 901 TCP connection. 903 Step 7: Client initiates a new stream to the server: 905 911 Step 8: Server responds by sending a stream header to the client 912 along with any remaining negotiatiable stream features: 914 919 920 921 DIGEST-MD5 922 PLAIN 923 EXTERNAL 924 925 927 Step 9: Client SHOULD continue with stream authentication (Section 928 6). 930 5.4 Server-to-Server Example 932 The following example shows the data flow for two servers securing a 933 stream using STARTTLS (the IANA registers port 5269 for 934 server-to-server communications using XMPP/Jabber, but another port 935 MAY be used). 937 Step 1: Server1 initiates stream to Server2: 939 944 Step 2: Server2 responds by sending a stream tag to Server1: 946 952 Step 3: Server2 sends the STARTTLS extension to Server1 along with 953 authentication mechanisms and any other stream features (if TLS is 954 required for interaction with Server2, it SHOULD signal that fact by 955 including a element as a child of the 956 element): 958 959 960 961 962 963 DIGEST-MD5 964 KERBEROS_V4 965 966 968 Step 4: Server1 sends the STARTTLS command to Server2: 970 972 Step 5: Server2 informs Server1 to proceed: 974 976 Step 5 (alt): Server2 informs Server1 that TLS negotiation has failed 977 and closes stream: 979 980 982 Step 6: Server1 and Server2 complete TLS negotiation via TCP. 984 Step 7: Server1 initiates a new stream to Server2: 986 991 Step 8: Server2 responds by sending a stream header to Server1 along 992 with any remaining negotiatiable stream features: 994 999 1000 1001 DIGEST-MD5 1002 KERBEROS_V4 1003 EXTERNAL 1004 1005 1007 Step 9: Server1 SHOULD continue with stream authentication (Section 1008 6). 1010 6. Stream Authentication 1012 XMPP includes two methods for enforcing authentication at the level 1013 of XML streams. The secure and preferred method for authenticating 1014 streams between two entities uses an XMPP adaptation of the Simple 1015 Authentication and Security Layer (SASL) [15]. If SASL negotiation is 1016 not possible, some level of trust MAY be established based on 1017 existing trust in DNS; the authentication method used in this case is 1018 the server dialback protocol that is native to XMPP (no such ad-hoc 1019 method is defined between a client and a server). If SASL is used for 1020 server-to-server authentication, the servers MUST NOT use dialback. 1021 For further information about the relative merits of these two 1022 methods, consult Security Considerations (Section 11). 1024 Stream authentication is REQUIRED for all direct communications 1025 between two entities; if an entity sends a stanza to an 1026 unauthenticated stream, the receiving entity SHOULD silently drop the 1027 stanza and MUST NOT process it. 1029 6.1 SASL Authentication 1031 6.1.1 Overview 1033 The Simple Authentication and Security Layer (SASL) provides a 1034 generalized method for adding authentication support to 1035 connection-based protocols. XMPP uses a generic XML namespace profile 1036 for SASL that conforms to section 4 ("Profiling Requirements") of RFC 1037 2222 [15] (the XMPP-specific namespace identifier is 1038 'urn:ietf:params:xml:ns:xmpp-sasl'). 1040 The following business rules apply: 1042 1. If TLS is used for stream encryption, SASL MUST NOT be used for 1043 anything but stream authentication (i.e., a security layer MUST 1044 NOT be negotiated using SASL). Conversely, if a security layer is 1045 to be negotiated via SASL, TLS MUST NOT be used. 1047 2. If the initiating entity is capable of authenticating via SASL, 1048 it it MUST include the "version='1.0'" flag in the initiating 1049 stream header. 1051 3. If the receiving entity is capable of accepting authentications 1052 via SASL, it MUST send one or more authentication mechanisms 1053 within a element scoped by the 1054 'urn:ietf:params:xml:ns:xmpp-sasl' namespace in response to the 1055 opening stream tag received from the initiating entity. 1057 4. If the SASL negotiation involves negotiation of a security layer, 1058 the receiving entity MUST discard any knowledge obtained from the 1059 initiating entity which was not obtained from the SASL 1060 negotiation itself. 1062 5. If the SASL negotiation involves negotiation of a security layer, 1063 the initiating entity MUST discard any knowledge obtained from 1064 the receiving entity which was not obtained from the SASL 1065 negotiation itself. 1067 The following syntax rules apply: 1069 1. The initial challenge MUST include a realm, nonce, qop, charset, 1070 and algorithm. 1072 2. The inital response for client-to-server negotiation MUST include 1073 a username, realm, nonce, cnonce, nc, qop, digest-uri, response, 1074 charset, and authzid. 1076 3. The inital response for server-to-server negotiation MUST include 1077 a realm, nonce, cnonce, nc, qop, digest-uri, response, and 1078 charset. 1080 4. The realm-value MUST be no more than 1023 bytes in length and 1081 MUST conform to the nameprep [8] profile of stringprep [9]. 1083 5. The username-value MUST be no more than 1023 bytes in length and 1084 MUST conform to the nodeprep [10] profile of stringprep [9]. 1086 6. The response-value MUST be computed in accordance with the 1087 relevant SASL mechanism as defined by the appropriate RFC (e.g., 1088 RFC 2831 [16] for digest authentication). 1090 7. The resource identifier portion of the authzid-value MUST be no 1091 more than 1023 bytes in length and MUST conform to the 1092 resourceprep [11] profile of stringprep [9]. 1094 6.1.2 Narrative 1096 When an initiating entity authenticates with a receiving entity, the 1097 steps involved are as follows: 1099 1. The initiating entity requests SASL authentication by including a 1100 'version' attribute in the opening XML stream header sent to the 1101 receiving entity, with the value set to "1.0". 1103 2. After sending an XML stream header in response, the receiving 1104 entity sends a list of available SASL authentication mechanisms, 1105 each of which is a element included as a child 1106 within a container element scoped by the 1107 'urn:ietf:params:xml:ns:xmpp-sasl' namespace that is sent as a 1108 child of a element in the streams namespace. If 1109 channel encryption must be established before a particular 1110 authentication mechanism may be used, the receiving entity MUST 1111 NOT provide that mechanism in the list of available SASL 1112 authentication methods. If the initiating entity presents a valid 1113 initiating entity certificate during TLS negotiation, the 1114 receiving entity MAY offer the SASL EXTERNAL mechanism to the 1115 initiating entity during stream authentication (see RFC 2222 1116 [15]). 1118 3. The initiating entity selects a mechanism by sending an 1119 element scoped by the 'urn:ietf:params:xml:ns:xmpp-sasl' 1120 namespace to the receiving entity; this element MAY optionally 1121 contain character data (in SASL terminology the "initial 1122 response") if the mechanism supports or requires it. If the 1123 initiating entity selects the EXTERNAL mechanism for 1124 authentication, the authentication credentials shall be taken 1125 from the certificate presented during TLS negotiation. 1127 4. If necessary, the receiving entity challenges the initiating 1128 entity by sending a element scoped by the 1129 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating 1130 entity; this element MAY optionally contain character data (which 1131 MUST be computed in accordance with the SASL mechanism chosen by 1132 the initiating entity). 1134 5. The initiating entity responds to the challenge by sending a 1135 element scoped by the 1136 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the receiving 1137 entity; this element MAY optionally contain character data (which 1138 MUST be computed in accordance with the SASL mechanism chosen by 1139 the initiating entity). 1141 6. If necessary, the receiving entity sends more challenges and the 1142 initiating entity sends more responses. 1144 This series of challenge/response pairs continues until one of three 1145 things happens: 1147 1. The initiating entity aborts the handshake by sending an 1148 element to the receiving entity. 1150 2. The receiving entity reports failure of the handshake by sending 1151 a element scoped by the 1152 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating 1153 entity. The particular cause of failure SHOULD be communicated in 1154 an appropriate child element of the element. The 1155 following conditions are defined: 1157 * 1159 * 1161 * 1163 * 1165 * 1167 3. The receiving entity reports success of the handshake by sending 1168 a element scoped by the 1169 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating 1170 entity; this element MAY optionally contain character data (in 1171 SASL terminology "additional data with success"). 1173 Any character data contained within these elements MUST be encoded 1174 using base64. 1176 6.1.3 SASL Definition 1178 Section 4 of the SASL specification [15] requires that the following 1179 information be supplied by a protocol definition: 1181 service name: "xmpp" 1183 initiation sequence: After the initiating entity provides an opening 1184 XML stream header and the receiving entity replies in kind, the 1185 receiving entity provides a list of acceptable authentication 1186 methods. The initiating entity chooses one method from the list 1187 and sends it to the receiving entity as the value of the 1188 'mechanism' attribute possessed by an element, optionally 1189 including an initial response to avoid a round trip. 1191 exchange sequence: Challenges and responses are carried through the 1192 exchange of elements from receiving entity to 1193 initiating entity and elements from initiating entity 1194 to receiving entity. The receiving entity reports failure by 1195 sending a element and success by sending a 1196 element; the initiating entity aborts the exchange by sending an 1197 element. (All of these elements are scoped by the 1198 'urn:ietf:params:xml:ns:xmpp-sasl' namespace.) 1200 security layer negotiation: If a security layer is negotiated, both 1201 sides consider the original stream closed and new 1202 headers are sent by both entities. The security layer takes effect 1203 immediately following the ">" character of the element 1204 for the client and immediately following the closing ">" character 1205 of the element for the server. (Both of these elements 1206 are scoped by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace.) 1208 use of the authorization identity: The authorization identity is used 1209 by xmpp only in negotiation between a client and a server, and 1210 denotes the "full JID" (user@domain/resource) requested by the 1211 user or application associated with the client. 1213 6.1.4 Client-to-Server Example 1215 The following example shows the data flow for a client authenticating 1216 with a server using SASL (the IANA registers port 5222 for 1217 client-to-server communications using XMPP/Jabber, but another port 1218 MAY be used). 1220 Step 1: Client initiates stream to server: 1222 1228 Step 2: Server responds with a stream tag sent to the client: 1230 1237 Step 3: Server informs client of available authentication mechanisms: 1239 1240 1241 DIGEST-MD5 1242 PLAIN 1243 1244 1245 Step 4: Client selects an authentication mechanism: 1247 1251 Step 5: Server sends a base64-encoded challenge to the client: 1253 1254 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 1255 xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz 1256 1258 The decoded challenge is: 1260 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ 1261 qop="auth",charset=utf-8,algorithm=md5-sess 1263 Step 6: Client responds to the challenge: 1265 1266 dXNlcm5hbWU9InJvYiIscmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik 1267 9BNk1HOXRFUUdtMmhoIixjbm9uY2U9Ik9BNk1IWGg2VnFUclJrIixuYz0w 1268 MDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJ4bXBwL2NhdGFjbHlzbS 1269 5jeCIscmVzcG9uc2U9ZDM4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZjIxNDNh 1270 ZjcsY2hhcnNldD11dGYtOCxhdXRoemlkPSJyb2JAY2F0YWNseXNtLmN4L2 1271 15UmVzb3VyY2Ui 1272 1274 The decoded response is: 1276 username="rob",realm="cataclysm.cx",\ 1277 nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\ 1278 nc=00000001,qop=auth,digest-uri="xmpp/cataclysm.cx",\ 1279 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8,\ 1280 authzid="rob@cataclysm.cx/myResource" 1282 Step 7: Server sends another challenge to the client: 1284 1285 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 1286 1288 The decoded challenge is: 1290 rspauth=ea40f60335c427b5527b84dbabcdfffd 1291 Step 8: Client responds to the challenge: 1293 1295 Step 9: Server informs client of successful authentication: 1297 1299 Step 9 (alt): Server informs client of failed authentication: 1301 1302 1303 1305 Step 10: Client initiates a new stream to the server: 1307 1313 Step 11: Server responds by sending a stream header to the client, 1314 with the stream already authenticated (not followed by further stream 1315 features): 1317 1324 6.1.5 Server-to-Server Example 1326 The following example shows the data flow for a server authenticating 1327 with another server using SASL (the IANA registers port 5269 for 1328 server-to-server communications using XMPP/Jabber, but another port 1329 MAY be used). 1331 Step 1: Server1 initiates stream to Server2: 1333 1338 Step 2: Server2 responds with a stream tag sent to Server1: 1340 1346 Step 3: Server2 informs Server1 of available authentication 1347 mechanisms: 1349 1350 1351 DIGEST-MD5 1352 KERBEROS_V4 1353 1354 1356 Step 4: Server1 selects an authentication mechanism: 1358 1362 Step 5: Server2 sends a base64-encoded challenge to Server1: 1364 1365 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 1366 xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz 1367 1369 The decoded challenge is: 1371 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ 1372 qop="auth",charset=utf-8,algorithm=md5-sess 1374 Step 6: Server1 responds to the challenge: 1376 1377 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 1378 xjbm9uY2U9Ik9BNk1IWGg2VnFUclJrIixuYz0wMDAwMDAwMSxxb3A9YXV0 1379 aCxkaWdlc3QtdXJpPSJ4bXBwL2NhdGFjbHlzbS5jeCIscmVzcG9uc2U9ZD 1380 M4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcsY2hhcnNldD11dGYt 1381 OAo= 1382 1384 The decoded response is: 1386 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\ 1387 nc=00000001,qop=auth,digest-uri="xmpp/cataclysm.cx",\ 1388 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8 1390 Step 7: Server2 sends another challenge to Server1: 1392 1393 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 1394 1396 The decoded challenge is: 1398 rspauth=ea40f60335c427b5527b84dbabcdfffd 1400 Step 8: Server1 responds to the challenge: 1402 1404 Step 9: Server2 informs Server1 of successful authentication: 1406 1408 Step 9 (alt): Server2 informs Server1 of failed authentication: 1410 1411 1412 1414 Step 10: Server1 initiates a new stream to Server2: 1416 1421 Step 11: Server2 responds by sending a stream header to Server1, with 1422 the stream already authenticated (not followed by further stream 1423 features): 1425 1431 6.2 Dialback Authentication 1433 XMPP includes a protocol-level method for verifying that a connection 1434 between two servers can be trusted as much as the DNS can be trusted. 1435 The method is called dialback and is used only within XML streams 1436 that are declared under the "jabber:server" namespace. 1438 The purpose of the dialback protocol is to make server spoofing more 1439 difficult, and thus to make it more difficult to forge XML stanzas. 1440 Dialback is decidedly not intended as a mechanism for securing or 1441 encrypting the streams between servers as is done via SASL and TLS, 1442 only for helping to prevent the spoofing of a server and the sending 1443 of false data from it. In particular, dialback authentication is 1444 susceptible to DNS poisoning attacks unless DNSSec [30] is used. 1445 Furthermore, even if the DNS information is accurate, dialback 1446 authentication cannot protect from attacks where the attacker is 1447 capable of hijacking the IP address of the remote domain. Domains 1448 requiring more robust security SHOULD use TLS and SASL as defined 1449 above. 1451 Server dialback is made possible by the existence of DNS, since one 1452 server can verify that another server which is connecting to it is 1453 authorized to represent a given hostname. All DNS hostname 1454 resolutions MUST first resolve the hostname using an SRV [18] record 1455 of _jabber._tcp.server. If the SRV lookup fails, the fallback is a 1456 normal A lookup to determine the IP address, using the jabber-server 1457 port of 5269 assigned by the Internet Assigned Numbers Authority [5]. 1459 The method for generating and verifying the keys used in the dialback 1460 protocol MUST take into account the hostnames being used, the random 1461 ID generated for the stream, and a secret known by the authoritative 1462 server's network. Generating unique but verifiable keys is important 1463 to prevent common man-in-the-middle attacks and server spoofing. 1465 Any error that occurs during dialback negotiation MUST be considered 1466 a stream error, resulting in termination of the stream and of the 1467 underlying TCP connection. The possible error conditions are 1468 specified in the protocol description below. 1470 The following terminology applies: 1472 o Originating Server -- the server that is attempting to establish a 1473 connection between two domains. 1475 o Receiving Server -- the server that is trying to authenticate that 1476 Originating Server represents the domain which it claims to be. 1478 o Authoritative Server -- the server that answers to the DNS 1479 hostname asserted by Originating Server; for basic environments 1480 this will be Originating Server, but it could be a separate 1481 machine in Originating Server's network. 1483 The following is a brief summary of the order of events in dialback: 1485 1. Originating Server establishes a connection to Receiving Server. 1487 2. Originating Server sends a 'key' value over the connection to 1488 Receiving Server. 1490 3. Receiving Server establishes a connection to Authoritative 1491 Server. 1493 4. Receiving Server sends the same 'key' value to Authoritative 1494 Server. 1496 5. Authoritative Server replies that key is valid or invalid. 1498 6. Receiving Server tells Originating Server whether it is 1499 authenticated or not. 1501 We can represent this flow of events graphically as follows: 1503 Originating Receiving 1504 Server Server 1505 ----------- --------- 1506 | | 1507 | establish connection | 1508 | ----------------------> | 1509 | | 1510 | send stream header | 1511 | ----------------------> | 1512 | | 1513 | establish connection | 1514 | <---------------------- | 1515 | | 1516 | send stream header | 1517 | <---------------------- | 1518 | | Authoritative 1519 | send dialback key | Server 1520 | ----------------------> | ------------- 1521 | | | 1522 | establish connection | 1523 | ----------------------> | 1524 | | 1525 | send stream header | 1526 | ----------------------> | 1527 | | 1528 | establish connection | 1529 | <---------------------- | 1530 | | 1531 | send stream header | 1532 | <---------------------- | 1533 | | 1534 | send dialback key | 1535 | ----------------------> | 1536 | | 1537 | validate dialback key | 1538 | <---------------------- | 1539 | 1540 | report dialback result | 1541 | <---------------------- | 1542 | | 1544 6.2.1 Dialback Protocol 1546 The interaction between the servers is as follows: 1548 1. Originating Server establishes TCP connection to Receiving 1549 Server. 1551 2. Originating Server sends a stream header to Receiving Server: 1553 1558 Note: the 'to' and 'from' attributes are NOT REQUIRED on the 1559 root stream element. The inclusion of the xmlns:db namespace 1560 declaration with the name shown indicates to Receiving Server 1561 that Originating Server supports dialback. If the namespace name 1562 is incorrect, then Receiving Server MUST generate an 1563 stream error condition and terminate both 1564 the XML stream and the underlying TCP connection. 1566 3. Receiving Server SHOULD send a stream header back to Originating 1567 Server, including a unique ID for this interaction: 1569 1575 Note: The 'to' and 'from' attributes are NOT REQUIRED on the 1576 root stream element. If the namespace name is incorrect, then 1577 Originating Server MUST generate an stream 1578 error condition and terminate both the XML stream and the 1579 underlying TCP connection. Note well that Receiving Server is 1580 NOT REQUIRED to reply and MAY silently terminate the XML stream 1581 and underlying TCP connection depending on security policies in 1582 place. 1584 4. Originating Server sends a dialback key to Receiving Server: 1586 1589 98AF014EDC0... 1590 1592 Note: this key is not examined by Receiving Server, since 1593 Receiving Server does not keep information about Originating 1594 Server between sessions. The key generated by Originating Server 1595 must be based in part on the value of the ID provided by 1596 Receiving Server in the previous step, and in part on a secret 1597 shared by Originating Server and Authoritative Server. If the 1598 value of the 'to' address does not match a hostname recognized 1599 by Receiving Server, then Receiving Server MUST generate a 1600 stream error condition and terminate both the 1601 XML stream and the underlying TCP connection. If the value of 1602 the 'from' address matches a domain with which Receiving Server 1603 already has an established connection, then Receiving Server 1604 SHOULD generate a stream error condition and 1605 terminate both the XML stream and the underlying TCP connection. 1607 5. Receiving Server establishes a TCP connection back to the domain 1608 name asserted by Originating Server, as a result of which it 1609 connects to Authoritative Server. (Note: as an optimization, an 1610 implementation MAY reuse an existing trusted connection here 1611 rather than opening a new TCP connection.) 1613 6. Receiving Server sends Authoritative Server a stream header: 1615 1620 Note: the 'to' and 'from' attributes are NOT REQUIRED on the 1621 root stream element. If the namespace name is incorrect, then 1622 Authoritative Server MUST generate an 1623 stream error condition and terminate both the XML stream and the 1624 underlying TCP connection. 1626 7. Authoritative Server sends Receiving Server a stream header: 1628 1634 Note: if the namespace name is incorrect, then Receiving Server 1635 MUST generate an stream error condition and 1636 terminate both the XML stream and the underlying TCP connection 1637 between it and Authoritative Server. If the ID does not match 1638 that provided by Receiving Server in Step 3, then Receiving 1639 Server MUST generate an stream error condition and 1640 terminate both the XML stream and the underlying TCP connection 1641 between it and Authoritative Server. If either of the foregoing 1642 stream errors occurs between Receiving Server and Authoritative 1643 Server, then Receiving Server MUST generate a 1644 stream error condition and terminate 1645 both the XML stream and the underlying TCP connection between it 1646 and Originating Server. 1648 8. Receiving Server sends Authoritative Server a stanza requesting 1649 that Authoritative Server verify a key: 1651 1655 98AF014EDC0... 1656 1658 Note: passed here are the hostnames, the original identifier 1659 from Receiving Server's stream header to Originating Server in 1660 Step 3, and the key that Originating Server sent to Receiving 1661 Server in Step 4. Based on this information and shared secret 1662 information within the Authoritative Server's network, the key 1663 is verified. Any verifiable method MAY be used to generate the 1664 key. If the value of the 'to' address does not match a hostname 1665 recognized by Authoritative Server, then Authoritative Server 1666 MUST generate a stream error condition and 1667 terminate both the XML stream and the underlying TCP connection. 1668 If the value of the 'from' address does not match the hostname 1669 represented by Receiving Server when opening the TCP connection 1670 (or any validated domain), then Authoritative Server MUST 1671 generate a stream error condition and 1672 terminate both the XML stream and the underlying TCP connection. 1674 9. Authoritative Server sends a stanza back to Receiving Server 1675 verifying whether the key was valid or invalid: 1677 1683 or 1685 1691 Note: if the ID does not match that provided by Receiving Server 1692 in Step 3, then Receiving Server MUST generate an 1693 stream error condition and terminate both the XML stream and the 1694 underlying TCP connection. If the value of the 'to' address does 1695 not match a hostname recognized by Receiving Server, then 1696 Receiving Server MUST generate a stream error 1697 condition and terminate both the XML stream and the underlying 1698 TCP connection. If the value of the 'from' address does not 1699 match the hostname represented by Originating Server when 1700 opening the TCP connection (or any validated domain), then 1701 Receiving Server MUST generate a stream 1702 error condition and terminate both the XML stream and the 1703 underlying TCP connection. 1705 10. Receiving Server informs Originating Server of the result: 1707 1712 Note: At this point the connection has either been validated via 1713 a type='valid', or reported as invalid. If the connection is 1714 invalid, then Receiving Server MUST terminate both the XML 1715 stream and the underlying TCP connection. If the connection is 1716 validated, data can be sent by Originating Server and read by 1717 Receiving Server; before that, all data stanzas sent to 1718 Receiving Server SHOULD be silently dropped. 1720 Even if dialback negotiation is successful, a server MUST verify that 1721 all XML stanzas received from the other server include a 'from' 1722 attribute and a 'to' attribute; if a stanza does not meet this 1723 restriction, the server that receives the stanza MUST generate an 1724 stream error condition and terminate both the XML 1725 stream and the underlying TCP connection. Furthermore, a server MUST 1726 verify that the 'from' attribute of stanzas received from the other 1727 server includes the validated domain (or any validated domain); if a 1728 stanza does not meet this restriction, the server that receives the 1729 stanza MUST generate a stream error condition 1730 and terminate both the XML stream and the underlying TCP connection. 1731 Both of these checks help to prevent spoofing related to particular 1732 stanzas. 1734 7. XML Stanzas 1736 7.1 Overview 1738 Once the XML streams in each direction have been authenticated and 1739 (if desired) encrypted, XML stanzas can be sent over the streams. 1740 Three XML stanza types are defined for the 'jabber:client' and 1741 'jabber:server' namespaces: , , and . 1743 In essence, the stanza type can be seen as a "push" 1744 mechanism whereby one entity pushes information to another entity, 1745 similar to the communications that occur in a system such as email. 1746 The element can be seen as a basic broadcast or 1747 "publish-subscribe" mechanism, whereby multiple entities receive 1748 information (in this case, presence information) about an entity to 1749 which they have subscribed. The element can be seen as a 1750 "request-response" mechanism similar to HTTP, whereby two entities 1751 can engage in a structured conversation using 'get' or 'set' requests 1752 and 'result' or 'error' responses. 1754 The syntax for these stanza types is defined below. 1756 7.2 Common Attributes 1758 Five attributes are common to message, presence, and IQ stanzas. 1759 These are defined below. 1761 7.2.1 to 1763 The 'to' attribute specifies the JID of the intended recipient for 1764 the stanza. 1766 In the 'jabber:client' namespace, a stanza SHOULD possess a 'to' 1767 attribute, although a stanza sent from a client to a server for 1768 handling by that server (e.g., presence sent to the server for 1769 broadcasting to other entities) MAY legitimately lack a 'to' 1770 attribute. 1772 In the 'jabber:server' namespace, a stanza MUST possess a 'to' 1773 attribute; if a server receives a stanza that does not meet this 1774 restriction, it MUST generate an stream error 1775 condition and terminate both the XML stream and the underlying TCP 1776 connection. 1778 If the value of the 'to' attribute is invalid or cannot be contacted, 1779 the entity discovering that fact (usually the sender's or recipient's 1780 server) MUST return an appropriate error to the sender. 1782 7.2.2 from 1784 The 'from' attribute specifies the JID of the sender. 1786 In the 'jabber:client' namespace, a client MUST NOT include a 'from' 1787 attribute on the stanzas it sends to a server; if a server receives a 1788 stanza from a client and the stanza possesses a 'from' attribute, it 1789 MUST ignore the value of the 'from' attribute and MAY return an error 1790 to the sender. In addition, a server MUST stamp stanzas received from 1791 a client with the user@domain/resource (full JID) of the connected 1792 resource that generated the stanza as defined by the authzid provided 1793 in the SASL negotiation. 1795 In the 'jabber:server' namespace, a stanza MUST possess a 'from' 1796 attribute; if a server receives a stanza that does not meet this 1797 restriction, it MUST generate an stream error 1798 condition. Furthermore, the domain identifier portion of the JID 1799 contained in the 'from' attribute MUST match the hostname of the 1800 sending server (or any validated domain) as communicated in the SASL 1801 negotiation or dialback negotiation; if a server receives a stanza 1802 that does not meet this restriction, it MUST generate a 1803 stream error condition. Both of these conditions 1804 MUST result in closing of the stream and termination of the 1805 underlying TCP connection. 1807 7.2.3 id 1809 The optional 'id' attribute MAY be used to track stanzas sent and 1810 received. The 'id' attribute is generated by the sender. An 'id' 1811 attribute included in an IQ request of type "get" or "set" SHOULD be 1812 returned to the sender in any IQ response of type "result" or "error" 1813 generated by the recipient of the request. A recipient of a message 1814 or presence stanza MAY return that 'id' in any replies, but is NOT 1815 REQUIRED to do so. 1817 The value of the 'id' attribute is not intended to be unique -- 1818 globally, within a domain, or within a stream. It is generated by a 1819 sender only for internal tracking of information within the sending 1820 application. 1822 7.2.4 type 1824 The 'type' attribute specifies detailed information about the purpose 1825 or context of the message, presence, or IQ stanza. The particular 1826 allowable values for the 'type' attribute vary depending on whether 1827 the stanza is a message, presence, or IQ, and thus are specified in 1828 the following sections. 1830 7.2.5 xml:lang 1832 Any message or presence stanza MAY possess an 'xml:lang' attribute as 1833 defined in Section 2.12 of the XML specification [1]. Ths value this 1834 attribute specifies the default language of any XML character data 1835 contained in the stanza or its child elements. An IQ stanza SHOULD 1836 NOT possess an 'xml:lang' attribute, since it is merely a vessel for 1837 data in other namespaces and does not itself contain children that 1838 have CDATA. The value of the 'xml:lang' attribute MUST be an NMTOKEN 1839 and MUST conform to the format defined in RFC 3066 [17]. 1841 7.3 Message Stanzas 1843 Message stanzas in the 'jabber:client' or 'jabber:server' namespace 1844 are used to "push" information to another entity. Common uses in the 1845 context of instant messaging include single messages, messages sent 1846 in the context of a chat conversation, messages sent in the context 1847 of a multi-user chat room, headlines, and errors. These messages 1848 types are identified more fully below. 1850 7.3.1 Types of Message 1852 The 'type' attribute of a message stanza is OPTIONAL; if included, it 1853 specifies the conversational context of the message. The sending of a 1854 message stanza without a 'type' attribute signals that the message 1855 stanza is a single message. However, the 'type' attribute MAY also 1856 have one of the following values: 1858 o chat 1860 o error 1862 o groupchat 1864 o headline 1866 For information about the meaning of these message types, refer to 1867 XMPP IM [23]. 1869 7.3.2 Children 1871 As described under extended namespaces (Section 7.6), a message 1872 stanza MAY contain any properly-namespaced child element as long as 1873 the namespace name is not "jabber:client", "jabber:server", or 1874 "http://etherx.jabber.org/streams". 1876 In accordance with the default namespace declaration, by default a 1877 message stanza is in the 'jabber:client' or 'jabber:server' 1878 namespace, which defines certain allowable children of message 1879 stanzas. If the message stanza is of type "error", it MUST include an 1880 child; for details, see Section 7.7. If the message stanza 1881 has no 'type' attribute or has a 'type' attribute with a value of 1882 "chat", "groupchat", or "headline", it MAY contain any of the 1883 following child elements without an explicit namespace declaration: 1885 7.3.2.1 Body 1887 The element contains the textual contents of the message; 1888 normally included but NOT REQUIRED. The element SHOULD NOT 1889 possess any attributes, with the exception of the 'xml:lang' 1890 attribute. Multiple instances of the element MAY be included 1891 but only if each instance possesses an 'xml:lang' attribute with a 1892 distinct language value. The element MUST NOT contain mixed 1893 content. 1895 7.3.2.2 Subject 1897 The element specifies the topic of the message. The 1898 element SHOULD NOT possess any attributes, with the 1899 exception of the 'xml:lang' attribute. Multiple instances of the 1900 element MAY be included for the purpose of providing 1901 alternate versions of the same subject, but only if each instance 1902 possesses an 'xml:lang' attribute with a distinct language value. The 1903 element MUST NOT contain mixed content. 1905 7.3.2.3 Thread 1907 The element contains a random string that is generated by 1908 the sender and that SHOULD be copied back in replies; it is used for 1909 tracking a conversation thread (sometimes referred to as an "IM 1910 session") between two entities. If used, it MUST be unique to that 1911 conversation thread within the stream and MUST be consistent 1912 throughout that conversation. The use of the element is 1913 optional and is not used to identify individual messages, only 1914 conversations. Only one element MAY be included in a 1915 message stanza, and it MUST NOT possess any attributes. The 1916 element MUST be treated as an opaque string by entities; no semantic 1917 meaning may be derived from it, and only exact, case-insensitve 1918 comparisons be made against it. The element MUST NOT contain 1919 mixed content. 1921 The method for generating thread IDs SHOULD be as follows: 1923 1. concatenate the sender's full JID (user@domain/resource) with the 1924 recipient's full JID 1926 2. concatenate these JID strings with a full ISO-8601 timestamp 1927 including year, month, day, hours, minutes, seconds, and UTC 1928 offset in the following format: yyyy-mm-dd-Thh:mm:ss-hh:mm 1930 3. hash the resulting string according to the SHA1 algorithm 1932 4. convert the hexidecimal SHA1 output to all lowercase 1934 7.4 Presence Stanzas 1936 Presence stanzas are used in the 'jabber:client' or 'jabber:server' 1937 namespace to express an entity's current availability status (offline 1938 or online, along with various sub-states of the latter and optional 1939 user-defined descriptive text) and to communicate that status to 1940 other entities. Presence stanzas are also used to negotiate and 1941 manage subscriptions to the presence of other entities. 1943 7.4.1 Types of Presence 1945 The 'type' attribute of a presence stanza is optional. A presence 1946 stanza that does not possess a 'type' attribute is used to signal to 1947 the server that the sender is online and available for communication. 1948 If included, the 'type' attribute specifies a lack of availability, a 1949 request to manage a subscription to another entity's presence, a 1950 request for another entity's current presence, or an error related to 1951 a previously-sent presence stanza. The 'type' attribute MAY have one 1952 of the following values: 1954 o unavailable -- Signals that the entity is no longer available for 1955 communication. 1957 o subscribe -- The sender wishes to subscribe to the recipient's 1958 presence. 1960 o subscribed -- The sender has allowed the recipient to receive 1961 their presence. 1963 o unsubscribe -- A notification that an entity is unsubscribing from 1964 another entity's presence. 1966 o unsubscribed -- The subscription request has been denied or a 1967 previously-granted subscription has been cancelled. 1969 o probe -- A request for an entity's current presence. In general 1970 SHOULD NOT be sent by a client. 1972 o error -- An error has occurred regarding processing or delivery of 1973 a previously-sent presence stanza. 1975 Information about the subscription model used within XMPP can be 1976 found in XMPP IM [23]. 1978 7.4.2 Children 1980 As described under extended namespaces (Section 7.6), a presence 1981 stanza MAY contain any properly-namespaced child element as long as 1982 the namespace name is not "jabber:client", "jabber:server", or 1983 "http://etherx.jabber.org/streams". 1985 In accordance with the default namespace declaration, by default a 1986 presence stanza is in the 'jabber:client' or 'jabber:server' 1987 namespace, which defines certain allowable children of presence 1988 stanzas. If the presence stanza is of type "error", it MUST include 1989 an child; for details, see Section 7.7. If the presence 1990 stanza possesses no 'type' attribute, it MAY contain any of the 1991 following child elements (note that the child MAY be sent 1992 in a presence stanza of type "unavailable" or, for historical 1993 reasons, "subscribe"): 1995 7.4.2.1 Show 1997 The optional element specifies a particular availability 1998 status of an entity or specific resource (if a element is not 1999 provided, default availability is assumed (if a element is 2000 not provided, default availability is assumed)). Only one 2001 element MAY be included in a presence stanza, and it SHOULD NOT 2002 possess any attributes. The CDATA value SHOULD be one of the 2003 following (values other than these four SHOULD be ignored; additional 2004 availability types could be defined through a properly-namespaced 2005 child element of the presence stanza): 2007 o away 2009 o chat 2011 o xa 2013 o dnd 2015 For information about the meaning of these values, refer to XMPP IM 2016 [23]. 2018 7.4.2.2 Status 2020 The optional element contains a natural-language 2021 description of availability status. It is normally used in 2022 conjunction with the show element to provide a detailed description 2023 of an availability state (e.g., "In a meeting"). The 2024 element SHOULD NOT possess any attributes, with the exception of the 2025 'xml:lang' attribute. Multiple instances of the element MAY 2026 be included but only if each instance possesses an 'xml:lang' 2027 attribute with a distinct language value. 2029 7.4.2.3 Priority 2031 The optional element specifies the priority level of the 2032 connected resource. The value may be any integer between -128 to 127. 2033 Only one element MAY be included in a presence stanza, 2034 and it MUST NOT possess any attributes. For information regarding the 2035 use of priority values in stanza routing within IM applications, see 2036 XMPP IM [23]. 2038 7.5 IQ Stanzas 2040 7.5.1 Overview 2042 Info/Query, or IQ, is a request-response mechanism, similar in some 2043 ways to HTTP [31]. IQ stanzas in the 'jabber:client' or 2044 'jabber:server' namespace enable an entity to make a request of, and 2045 receive a response from, another entity. The data content of the 2046 request and response is defined by the namespace declaration of a 2047 direct child element of the IQ element, and the interaction is 2048 tracked by the requesting entity through use of the 'id' attribute, 2049 which responding entities SHOULD return in any response. 2051 Most IQ interactions follow a common pattern of structured data 2052 exchange such as get/result or set/result (although an error may be 2053 returned in response to a request if appropriate): 2055 Requesting Responding 2056 Entity Entity 2057 ---------- ---------- 2058 | | 2059 | | 2060 | ------------------------> | 2061 | | 2062 | | 2063 | <------------------------ | 2064 | | 2065 | | 2066 | ------------------------> | 2067 | | 2068 | | 2069 | <------------------------ | 2070 | | 2072 An entity that receives an IQ request of type 'get' or 'set' MUST 2073 reply with an IQ response of type 'result' or 'error' (which response 2074 MUST preserve the 'id' attribute of the request). An entity that 2075 receives a stanza of type 'result' or 'error' MUST NOT respond to the 2076 stanza by sending a further IQ response of type 'result' or 'error'; 2077 however, as shown above, the requesting entity MAY send another 2078 request (e.g., an IQ of type 'set' in order to provide required 2079 information discovered through a get/result pair). 2081 7.5.2 Types of IQ 2083 The 'type' attribute of an IQ stanza is REQUIRED. The 'type' 2084 attribute specifies a distinct step within a request-response 2085 interaction. The value SHOULD be one of the following (all other 2086 values SHOULD be ignored): 2088 o get -- The stanza is a request for information. 2090 o set -- The stanza provides required data, sets new values, or 2091 replaces existing values. 2093 o result -- The stanza is a response to a successful get or set 2094 request. 2096 o error -- An error has occurred regarding processing or delivery of 2097 a previously-sent get or set. 2099 7.5.3 Children 2101 As described under extended namespaces (Section 7.6), an IQ stanza 2102 MAY contain any properly-namespaced child element as long as the 2103 namespace name is not "jabber:client", "jabber"server", or "http:// 2104 etherx.jabber.org/streams". However, an IQ stanza contains no 2105 children in the 'jabber:client' or 'jabber:server' namespace since it 2106 is a vessel for XML in another namespace. 2108 An IQ stanza of type "get" or "set" MUST include one and only one 2109 child element. An the IQ stanza of type "error" SHOULD include the 2110 child element contained in the associated "set" or "get" and MUST 2111 include an child; for details, see Section 7.7. 2113 7.6 Extended Namespaces 2115 While the core data elements in the "jabber:client" or 2116 "jabber:server" namespace (along with their attributes and child 2117 elements) provide a basic level of functionality for messaging and 2118 presence, XMPP uses XML namespaces to extend the core data elements 2119 for the purpose of providing additional functionality. Thus a 2120 message, presence, or IQ stanza MAY house one or more optional child 2121 elements containing content that extends the meaning of the message 2122 (e.g., an encrypted form of the message body). This child element MAY 2123 be have any name and MUST possess an 'xmlns' namespace declaration 2124 (other than "jabber:client", "jabber:server", or "http:// 2125 etherx.jabber.org/streams") that defines all data contained within 2126 the child element. 2128 Support for any given extended namespace is OPTIONAL on the part of 2129 any implementation. If an entity does not understand such a 2130 namespace, the entity's expected behavior depends on whether the 2131 entity is (1) the recipient or (2) an entity that is routing the 2132 stanza to the recipient. In particular: 2134 Recipient: If a recipient receives a stanza that contains a child 2135 element it does not understand, it SHOULD ignore that specific XML 2136 data, i.e., it SHOULD not process it or present it to a user or 2137 associated application (if any). In particular: 2139 * If an entity receives a message or presence stanza that 2140 contains XML data in an extended namespace it does not 2141 understand, the portion of the stanza that is in the unknown 2142 namespace SHOULD be ignored. 2144 * If an entity receives a message stanza without a 2145 element but containing only a child element bound by a 2146 namespace it does not understand, it MUST ignore the entire 2147 stanza/ 2149 * If an entity receives an IQ stanza in a namespace it does not 2150 understand, the entity SHOULD return an IQ stanza of type 2151 "error" with an error condition of . 2153 Router: If a routing entity (usually a server) handles a stanza that 2154 contains a child element it does not understand, it SHOULD ignore 2155 the associated XML data by passing it on untouched to the 2156 recipient. 2158 7.7 Stanza Errors 2160 As defined herein, stanza-related errors are handled in a manner 2161 similar to stream errors (Section 4.5). 2163 7.7.1 Rules 2165 The following rules apply to stanza-related errors: 2167 o A stanza of type "error" MUST contain an child element. 2169 o The receiving or processing entity that returns an error to the 2170 sending entity SHOULD include the original XML sent along with the 2171 element and its children so that the sender can inspect 2172 and if necessary correct the XML before re-sending. 2174 o An entity that receives a message stanza of type 'error' MUST NOT 2175 respond to the stanza by sending a further message stanza of type 2176 'error'; this helps to prevent looping. 2178 o An child MUST NOT be included if the stanza type is 2179 something other than "error". 2181 7.7.2 Syntax 2183 The syntax for stanza-related errors is as follows: 2185 2186 [include sender XML here] 2187 2188 2189 2190 2191 2192 2194 The stanza-name is one of message, presence, or iq. 2196 The value of the 'class' attribute MUST be one of the following: 2198 o access -- the condition relates to access rights, permissions, or 2199 authorization 2201 o address -- the condition relates to the JID or domain to which the 2202 stanza was addressed 2204 o app -- the condition is particular to an application and is 2205 specified in a namespace other than 2206 'urn:ietf:params:xml:ns:xmpp-stanzas' 2208 o format -- the condition relates to XML format or structure 2210 o recipient -- the condition relates to the state or capabilities of 2211 the recipient (which may be the server) 2213 o server -- the condition relates to the internal state of the 2214 server 2216 The element MUST contain a child element that specifies 2217 a particular stanza-related error condition, as defined in the next 2218 section. (Note: the XML namespace name 2219 'urn:ietf:params:xml:ns:xmpp-stanzas' that scopes the 2220 element adheres to the format defined in The IETF XML Registry [25].) 2222 7.7.3 Conditions 2224 The following stanza-related error conditions are defined: 2226 o -- the sender has sent XML that is malformed or 2227 cannot be processed (e.g., a client-generated stanza includes a 2228 'from' address, or an IQ stanza includes an unrecognized value of 2229 the 'type' attribute); the associated class is "format". 2231 o -- access cannot be granted because an existing 2232 resource or session exists with the same name or address; the 2233 associated class is "access". 2235 o -- the feature requested is not 2236 implemented by the recipient or server and therefore cannot be 2237 processed; the associated class is "recipient". 2239 o -- the stanza is understood but the action is 2240 forbidden; the associated class is "access". 2242 o -- the server could not process the 2243 stanza because of a misconfiguration or an otherwise-undefined 2244 internal server error; the associated class is "server". 2246 o -- the value of the 'to' attribute in the 2247 sender's stanza does not adhere to the syntax defined in 2248 Addressing (Section 3); the associated class is "address". 2250 o -- the value of the 'to' attribute in the 2251 sender's stanza does not correspond to a Jabber ID on the user's 2252 server or a remote server; the associated class is "address". 2254 o -- the action is not permitted when attempted by 2255 the sender; the associated class is "access". 2257 o -- the specific recipient requested is 2258 currently unavailable; the associated class is "recipient". 2260 o -- the user is not authorized to access 2261 the requested service because registration is required; the 2262 associated class is "access". 2264 o -- a remote server or service specified 2265 as part or all of the JID of the intended recipient does not 2266 exist; the associated class is "address". 2268 o -- a remote server or service specified 2269 as part or all of the JID of the intended recipient could not be 2270 contacted within a reasonable amount of time; the associated class 2271 is "server". 2273 o -- the service requested is currently 2274 unavailable on the server; the associated class is "server". 2276 7.7.4 Extensibility 2278 If desired, an XMPP application MAY provide custom error information; 2279 the error class MUST be "app" and the data MUST be contained in a 2280 properly-namespaced child of the element (i.e., the 2281 namespace name MUST NOT be one of namespace names defined herein). 2283 8. XML Usage within XMPP 2285 8.1 Restrictions 2287 XMPP is a simplified and specialized protocol for streaming XML 2288 elements in order to exchange messages and presence information in 2289 close to real time. Because XMPP does not require the parsing of 2290 arbitrary and complete XML documents, there is no requirement that 2291 XMPP must support the full XML specification [1]. In particular, the 2292 following restrictions apply: 2294 With regard to XML generation, an XMPP implementation MUST NOT inject 2295 into an XML stream any of the following: 2297 o comments (as defined in Section 2.5 of the XML specification [1]) 2299 o processing instructions (Section 2.6) 2301 o internal or external DTD subsets (Section 2.8) 2303 o internal or external entity references (Section 4.2) with the 2304 exception of predefined entities (Section 4.6) 2306 With regard to XML processing, if an XMPP implementation receives 2307 such restricted XML data, it MUST ignore the data. 2309 8.2 Namespaces 2311 XML Namespaces [12] are used within all XMPP-compliant XML to create 2312 strict boundaries of data ownership. The basic function of namespaces 2313 is to separate different vocabularies of XML elements that are 2314 structurally mixed together. Ensuring that XMPP-compliant XML is 2315 namespace-aware enables any XML to be structurally mixed with any 2316 data element within XMPP. 2318 Additionally, XMPP is more strict about namespace prefixes than the 2319 XML namespace specification requires. 2321 8.3 Validation 2323 Except as noted with regard to 'to' and 'from' addresses for stanzas 2324 within the 'jabber:server' namespace, a server is not responsible for 2325 validating the XML elements forwarded to a client or another server; 2326 an implementation MAY choose to provide only validated data elements 2327 but is NOT REQUIRED to do so. Clients SHOULD NOT rely on the ability 2328 to send data which does not conform to the schemas, and SHOULD ignore 2329 any non-conformant elements or attributes on the incoming XML stream. 2330 Validation of XML streams and stanzas is NOT REQUIRED or recommended, 2331 and schemas are included herein for descriptive purposes only. 2333 8.4 Character Encodings 2335 Software implementing XML streams MUST support the UTF-8 (RFC 2279 2336 [19]) and UTF-16 (RFC 2781 [20]) transformations of Universal 2337 Character Set (ISO/IEC 10646-1 [21]) characters. Software MUST NOT 2338 attempt to use any other encoding for transmitted data. The encodings 2339 of the transmitted and received streams are independent. Software MAY 2340 select either UTF-8 or UTF-16 for the transmitted stream, and SHOULD 2341 deduce the encoding of the received stream as described in the XML 2342 specification [1]. For historical reasons, existing implementations 2343 MAY support UTF-8 only. 2345 8.5 Inclusion of Text Declaration 2347 An application MAY send a text declaration. Applications MUST follow 2348 the rules in the XML specification [1] regarding the circumstances 2349 under which a text declaration is included. 2351 9. IANA Considerations 2353 9.1 XML Namespace Name for TLS Data 2355 A URN sub-namespace for TLS-related data in the Extensible Messaging 2356 and Presence Protocol (XMPP) is defined as follows. 2358 URI: urn:ietf:params:xml:ns:xmpp-tls 2360 Specification: [RFCXXXX] 2362 Description: This is the XML namespace name for TLS-related data in 2363 the Extensible Messaging and Presence Protocol (XMPP) as defined 2364 by [RFCXXXX]. 2366 Registrant Contact: IETF, XMPP Working Group, 2368 9.2 XML Namespace Name for SASL Data 2370 A URN sub-namespace for SASL-related data in the Extensible Messaging 2371 and Presence Protocol (XMPP) is defined as follows. 2373 URI: urn:ietf:params:xml:ns:xmpp-sasl 2375 Specification: [RFCXXXX] 2377 Description: This is the XML namespace name for SASL-related data in 2378 the Extensible Messaging and Presence Protocol (XMPP) as defined 2379 by [RFCXXXX]. 2381 Registrant Contact: IETF, XMPP Working Group, 2383 9.3 XML Namespace Name for Stream Errors 2385 A URN sub-namespace for stream-related error data in the Extensible 2386 Messaging and Presence Protocol (XMPP) is defined as follows. 2388 URI: urn:ietf:params:xml:ns:xmpp-streams 2390 Specification: [RFCXXXX] 2392 Description: This is the XML namespace name for stream-related error 2393 data in the Extensible Messaging and Presence Protocol (XMPP) as 2394 defined by [RFCXXXX]. 2396 Registrant Contact: IETF, XMPP Working Group, 2398 9.4 XML Namespace Name for Stanza Errors 2400 A URN sub-namespace for stanza-related error data in the Extensible 2401 Messaging and Presence Protocol (XMPP) is defined as follows. 2403 URI: urn:ietf:params:xml:ns:xmpp-stanzas 2405 Specification: [RFCXXXX] 2407 Description: This is the XML namespace name for stanza-related error 2408 data in the Extensible Messaging and Presence Protocol (XMPP) as 2409 defined by [RFCXXXX]. 2411 Registrant Contact: IETF, XMPP Working Group, 2413 9.5 Existing Registrations 2415 The IANA registers "xmpp" as a GSSAPI [22] service name, as specified 2416 in Section 6.1.3. 2418 Additionally, the IANA registers "jabber-client" and "jabber-server" 2419 as keywords for TCP ports 5222 and 5269 respectively. 2421 10. Internationalization Considerations 2423 Usage of the 'xml:lang' attribute is described above. If a client 2424 includes an 'xml:lang' attribute in a stanza, a server MUST NOT 2425 modify or delete it. 2427 11. Security Considerations 2429 11.1 High Security 2431 For the purposes of XMPP communications (client-to-server and 2432 server-to-server), the term "high security" refers to the use of 2433 security technologies that provide both mutual authentication and 2434 integrity-checking; in particular, when using certificate-based 2435 authentication to provide high security, a chain-of-trust SHOULD be 2436 established out-of-band, although a shared certificate authority 2437 signing certificates could allow a previously unknown certificate to 2438 establish trust in-band. 2440 Standalone, self-signed service certificates SHOULD NOT be used; 2441 rather, an entity that wishes to generate a self-signed service 2442 certificate SHOULD first generate a self-signed Root CA certificate 2443 and then generate a signed service certificate. Entities that 2444 communicate with the service SHOULD be configured with the Root CA 2445 certificate rather than the service certificate; this avoids the 2446 problems associated with simple comparison of service certificates. 2447 If a self-signed service certificate is used, an entity SHOULD NOT 2448 trust it if it is changed to another self-signed certificate or a 2449 certificate signed by an unrecognized authority. 2451 Implementations MUST support high security. Service provisioning 2452 SHOULD use high security, subject to local security policies. 2454 11.2 Client-to-Server Communications 2456 The TLS protocol for encrypting XML streams (defined under Section 5) 2457 provides a reliable mechanism for helping to ensure the 2458 confidentiality and data integrity of data exchanged between two 2459 entities. 2461 The SASL protocol for authenticating XML streams (defined under 2462 Section 6.1) provides a reliable mechanism for validating that a 2463 client connecting to a server is who it claims to be. 2465 The IP address and method of access of clients MUST NOT be made 2466 available by a server, nor are any connections other than the 2467 original server connection required. This helps protect the client's 2468 server from direct attack or identification by third parties. 2470 End-to-end encryption of message bodies and presence status 2471 information MAY be effected through use of the methods defined in 2472 End-to-End Object Encryption in XMPP [32]. 2474 11.3 Server-to-Server Communications 2476 A compliant implementation MUST support both TLS and SASL for 2477 inter-domain communications. For historical reasons, a compliant 2478 implementation SHOULD also support the lower-security Dialback 2479 Protocol (Section 6.2), which provides a mechanism for helping to 2480 prevent the spoofing of domains. 2482 Because service provisioning is a matter of policy, it is OPTIONAL 2483 for any given domain to communicate with other domains, and 2484 server-to-server communications MAY be disabled by the administrator 2485 of any given deployment. If a particular domain enables inter-domain 2486 communications, it SHOULD enable high security. In the absence of 2487 high security, a domain MAY use server dialback for inter-domain 2488 communications. 2490 Administrators may want to require use of SASL for server-to-server 2491 communications in order to ensure authentication and confidentiality 2492 (e.g., on an organization's private network). Compliant 2493 implementations SHOULD support SASL for this purpose. 2495 11.4 Firewalls 2497 Communications using XMPP normally occur over TCP sockets on port 2498 5222 (client-to-server) or port 5269 (server-to-server), as 2499 registered with the IANA [5]. Use of these well-known ports allows 2500 administrators to easily enable or disable XMPP activity through 2501 existing and commonly-deployed firewalls. 2503 11.5 Mandatory to Implement Technologies 2505 At a minimum, all implementations MUST support the following 2506 mechanisms: 2508 for authentication: the SASL DIGEST-MD5 mechanism 2510 for confidentiality: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA 2511 cipher) 2513 for both: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher 2514 supporting client-side certificates) 2516 Normative References 2518 [1] World Wide Web Consortium, "Extensible Markup Language (XML) 2519 1.0 (Second Edition)", W3C xml, October 2000, . 2522 [2] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for 2523 Presence and Instant Messaging", RFC 2779, February 2000, 2524 . 2526 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2527 Levels", BCP 14, RFC 2119, March 1997. 2529 [4] University of Southern California, "Transmission Control 2530 Protocol", RFC 793, September 1981, . 2533 [5] Internet Assigned Numbers Authority, "Internet Assigned Numbers 2534 Authority", January 1998, . 2536 [6] Harrenstien, K., Stahl, M. and E. Feinler, "DoD Internet host 2537 table specification", RFC 952, October 1985. 2539 [7] Braden, R., "Requirements for Internet Hosts - Application and 2540 Support", STD 3, RFC 1123, October 1989. 2542 [8] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile 2543 for Internationalized Domain Names (draft-ietf-idn-nameprep-11, 2544 work in progress)", June 2002. 2546 [9] Hoffman, P. and M. Blanchet, "Preparation of Internationalized 2547 Strings ("stringprep")", RFC 3454, December 2002. 2549 [10] Saint-Andre, P. and J. Hildebrand, "Nodeprep: A Stringprep 2550 Profile for Node Identifiers in XMPP 2551 (draft-ietf-xmpp-nodeprep-02, work in progress)", April 2003. 2553 [11] Saint-Andre, P. and J. Hildebrand, "Resourceprep: A Stringprep 2554 Profile for Resource Identifiers in XMPP 2555 (draft-ietf-xmpp-resourceprep-02, work in progress)", April 2556 2003. 2558 [12] World Wide Web Consortium, "Namespaces in XML", W3C xml-names, 2559 January 1999, . 2562 [13] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 2563 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 2564 1999. 2566 [14] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2568 [15] Myers, J., "Simple Authentication and Security Layer (SASL)", 2569 RFC 2222, October 1997. 2571 [16] Leach, P. and C. Newman, "Using Digest Authentication as a SASL 2572 Mechanism", RFC 2831, May 2000. 2574 [17] Alvestrand, H., "Tags for the Identification of Languages", BCP 2575 47, RFC 3066, January 2001. 2577 [18] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the 2578 location of services (DNS SRV)", RFC 2052, October 1996. 2580 [19] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2581 2279, January 1998. 2583 [20] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", 2584 RFC 2781, February 2000. 2586 [21] International Organization for Standardization, "Information 2587 Technology - Universal Multiple-octet coded Character Set (UCS) 2588 - Amendment 2: UCS Transformation Format 8 (UTF-8)", ISO 2589 Standard 10646-1 Addendum 2, October 1996. 2591 [22] Linn, J., "Generic Security Service Application Program 2592 Interface, Version 2", RFC 2078, January 1997. 2594 Informative References 2596 [23] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging 2597 (draft-ietf-xmpp-im-09, work in progress)", April 2003. 2599 [24] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 2600 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 2601 1998, . 2603 [25] Mealling, M., "The IANA XML Registry", 2604 draft-mealling-iana-xmlns-registry-04 (work in progress), June 2605 2002. 2607 [26] Crispin, M., "Internet Message Access Protocol - Version 2608 4rev1", RFC 2060, December 1996. 2610 [27] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 2611 53, RFC 1939, May 1996. 2613 [28] Newman, C. and J. Myers, "ACAP -- Application Configuration 2614 Access Protocol", RFC 2244, November 1997. 2616 [29] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, 2617 June 1999. 2619 [30] Eastlake, D., "Domain Name System Security Extensions", RFC 2620 2535, March 1999. 2622 [31] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 2623 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 2624 HTTP/1.1", RFC 2616, June 1999. 2626 [32] Saint-Andre, P. and J. Hildebrand, "End-to-End Object 2627 Encryption in XMPP (draft-ietf-xmpp-e2e-02, work in progress)", 2628 April 2003. 2630 Authors' Addresses 2632 Peter Saint-Andre 2633 Jabber Software Foundation 2635 EMail: stpeter@jabber.org 2636 URI: http://www.jabber.org/people/stpeter.php 2637 Jeremie Miller 2638 Jabber Software Foundation 2640 EMail: jeremie@jabber.org 2641 URI: http://www.jabber.org/people/jer.php 2643 Appendix A. XML Schemas 2645 The following XML schemas are descriptive, not normative. 2647 A.1 Streams namespace 2649 2651 2657 2658 2659 2660 2661 2662 2665 2668 2669 2670 2671 2672 2673 2674 2676 2677 2678 2682 2683 2685 2686 2687 2688 2689 2690 2691 2692 2693 2694 2695 2696 2697 2698 2699 2701 2703 A.2 TLS namespace 2705 2707 2713 2714 2715 2716 2717 2718 2719 2720 2722 2724 A.3 SASL namespace 2726 2728 2734 2735 2736 2738 2739 2741 2743 2744 2745 2747 2748 2750 2751 2752 2753 2754 2755 2756 2757 2758 2759 2760 2761 2762 2763 2764 2766 2767 2768 2769 2770 2772 2774 A.4 Dialback namespace 2776 2778 2784 2785 2786 2787 2788 2789 2790 2791 2792 2793 2794 2795 2796 2797 2798 2799 2800 2801 2803 2804 2805 2806 2807 2808 2809 2810 2811 2812 2813 2814 2815 2816 2817 2818 2819 2820 2821 2823 2825 A.5 Client namespace 2827 2829 2835 2836 2837 2838 2840 2842 2843 2844 2848 2849 2850 2851 2852 2855 2856 2857 2858 2859 2860 2861 2862 2863 2864 2865 2866 2868 2869 2870 2871 2872 2873 2874 2875 2876 2878 2879 2880 2881 2882 2883 2884 2885 2886 2888 2890 2891 2892 2893 2894 2896 2897 2898 2902 2903 2904 2905 2906 2909 2910 2911 2912 2913 2914 2915 2916 2917 2918 2919 2920 2921 2922 2924 2925 2926 2927 2928 2929 2930 2931 2932 2933 2935 2936 2937 2938 2939 2940 2941 2942 2943 2945 2947 2948 2949 2950 2954 2955 2956 2957 2958 2959 2960 2961 2962 2963 2964 2965 2966 2967 2968 2969 2970 2972 2973 2974 2975 2976 2977 2978 2979 2980 2981 2982 2983 2984 2985 2986 2987 2989 2991 A.6 Server namespace 2993 2995 3001 3002 3003 3004 3006 3008 3009 3010 3014 3015 3016 3017 3018 3021 3022 3023 3024 3025 3026 3027 3028 3029 3030 3031 3032 3034 3035 3036 3037 3038 3039 3040 3041 3042 3044 3045 3046 3047 3048 3049 3050 3051 3052 3054 3056 3057 3058 3059 3060 3062 3063 3064 3068 3069 3070 3071 3072 3075 3076 3077 3078 3079 3080 3081 3082 3083 3084 3085 3086 3087 3088 3090 3091 3092 3093 3094 3095 3096 3097 3098 3099 3101 3102 3103 3104 3105 3106 3107 3108 3109 3111 3113 3114 3115 3116 3120 3121 3122 3123 3124 3125 3126 3127 3128 3129 3130 3131 3132 3133 3134 3135 3136 3138 3139 3140 3141 3142 3143 3144 3145 3146 3147 3148 3149 3150 3151 3152 3153 3155 3157 A.7 Stream error namespace 3159 3161 3167 3168 3169 3173 3174 3175 3176 3177 3178 3179 3180 3181 3182 3183 3184 3185 3186 3187 3188 3189 3191 3192 3193 3194 3195 3196 3197 3198 3199 3200 3201 3202 3203 3204 3206 3208 A.8 Stanza error namespace 3210 3212 3218 3219 3220 3224 3225 3226 3227 3228 3229 3230 3231 3232 3233 3234 3235 3236 3237 3238 3240 3241 3242 3243 3244 3245 3246 3247 3248 3249 3250 3251 3253 3255 Appendix B. Revision History 3257 Note to RFC Editor: please remove this entire appendix, and the 3258 corresponding entries in the table of contents, prior to publication. 3260 B.1 Changes from draft-ietf-xmpp-core-09 3262 o Fixed several dialback error conditions. 3264 o Cleaned up business rules regarding TLS and certificate processing 3265 based on off-list feedback. 3267 o Changed and elements to 3268 . 3270 o Added or modified several stream and stanza error conditions. 3272 o Specified only one child allowed for IQ, or two if type="error". 3274 o Fixed several errors in the schemas. 3276 B.2 Changes from draft-ietf-xmpp-core-08 3278 o Incorporated list discussion regarding addressing, SASL, TLS, TCP, 3279 dialback, namespaces, extensibility, and the meaning of 'ignore' 3280 for routers and recipients. 3282 o Specified dialback error conditions. 3284 o Made small editorial changes to address RFC Editor requirements. 3286 B.3 Changes from draft-ietf-xmpp-core-07 3288 o Made several small editorial changes. 3290 B.4 Changes from draft-ietf-xmpp-core-06 3292 o Added text regarding certificate validation in TLS negotiation per 3293 list discussion. 3295 o Clarified nature of XML restrictions per discussion with W3C, and 3296 moved XML Restrictions subsection under "XML Usage within XMPP". 3298 o Further clarified that XML streams are unidirectional. 3300 o Changed stream error and stanza error namespace names to conform 3301 to the format defined in The IETF XML Registry [25]. 3303 o Removed note to RFC Editor regarding provisional namespace names. 3305 B.5 Changes from draft-ietf-xmpp-core-05 3307 o Added as a stream error condition. 3309 o Adjusted security considerations per discussion at IETF 56 and on 3310 list. 3312 B.6 Changes from draft-ietf-xmpp-core-04 3314 o Added server-to-server examples for TLS and SASL. 3316 o Changed error syntax, rules, and examples based on list 3317 discussion. 3319 o Added schemas for the TLS, stream error, and stanza error 3320 namespaces. 3322 o Added note to RFC Editor regarding provisional namespace names. 3324 o Made numerous small editorial changes and clarified text 3325 throughout. 3327 B.7 Changes from draft-ietf-xmpp-core-03 3329 o Clarified rules and procedures for TLS and SASL. 3331 o Amplified stream error code syntax per list discussion. 3333 o Made numerous small editorial changes. 3335 B.8 Changes from draft-ietf-xmpp-core-02 3337 o Added dialback schema. 3339 o Removed all DTDs since schemas provide more complete definitions. 3341 o Added stream error codes. 3343 o Clarified error code "philosophy". 3345 B.9 Changes from draft-ietf-xmpp-core-01 3347 o Updated the addressing restrictions per list discussion and added 3348 references to the new nodeprep and resourceprep profiles. 3350 o Corrected error in Stream Authentication regarding "version='1.0'" 3351 flag. 3353 o Made numerous small editorial changes. 3355 B.10 Changes from draft-ietf-xmpp-core-00 3357 o Added information about TLS from list discussion. 3359 o Clarified meaning of "ignore" based on list discussion. 3361 o Clarified information about Universal Character Set data and 3362 character encodings. 3364 o Provided base64-decoded information for examples. 3366 o Fixed several errors in the schemas. 3368 o Made numerous small editorial fixes. 3370 B.11 Changes from draft-miller-xmpp-core-02 3372 o Brought Streams Authentication section into line with discussion 3373 on list and at IETF 55 meeting. 3375 o Added information about the optional 'xml:lang' attribute per 3376 discussion on list and at IETF 55 meeting. 3378 o Specified that validation is neither required nor recommended, and 3379 that the formal definitions (DTDs and schemas) are included for 3380 descriptive purposes only. 3382 o Specified that the response to an IQ stanza of type 'get' or 'set' 3383 must be an IQ stanza of type 'result' or 'error'. 3385 o Specified that compliant server implementations must process 3386 stanzas in order. 3388 o Specified that for historical reasons some server implementations 3389 may accept 'stream:' as the only valid namespace prefix on the 3390 root stream element. 3392 o Clarified the difference between 'jabber:client' and 3393 'jabber:server' namespaces, namely, that 'to' and 'from' 3394 attributes are required on all stanzas in the latter but not the 3395 former. 3397 o Fixed typo in Step 9 of the dialback protocol (changed db:result 3398 to db:verify). 3400 o Removed references to TLS pending list discussion. 3402 o Removed the non-normative appendix on OpenPGP usage pending its 3403 inclusion in a separate I-D. 3405 o Simplified the architecture diagram, removed most references to 3406 services, and removed references to the 'jabber:component:*' 3407 namespaces. 3409 o Noted that XMPP activity respects firewall administration 3410 policies. 3412 o Further specified the scope and uniqueness of the 'id' attribute 3413 in all stanza types and the element in message stanzas. 3415 o Nomenclature changes: (1) from "chunks" to "stanzas"; (2) from 3416 "host" to "server" and from "node" to "client" (except with regard 3417 to definition of the addressing scheme). 3419 Intellectual Property Statement 3421 The IETF takes no position regarding the validity or scope of any 3422 intellectual property or other rights that might be claimed to 3423 pertain to the implementation or use of the technology described in 3424 this document or the extent to which any license under such rights 3425 might or might not be available; neither does it represent that it 3426 has made any effort to identify any such rights. Information on the 3427 IETF's procedures with respect to rights in standards-track and 3428 standards-related documentation can be found in BCP-11. Copies of 3429 claims of rights made available for publication and any assurances of 3430 licenses to be made available, or the result of an attempt made to 3431 obtain a general license or permission for the use of such 3432 proprietary rights by implementors or users of this specification can 3433 be obtained from the IETF Secretariat. 3435 The IETF invites any interested party to bring to its attention any 3436 copyrights, patents or patent applications, or other proprietary 3437 rights which may cover technology that may be required to practice 3438 this standard. Please address the information to the IETF Executive 3439 Director. 3441 Full Copyright Statement 3443 Copyright (C) The Internet Society (2003). All Rights Reserved. 3445 This document and translations of it may be copied and furnished to 3446 others, and derivative works that comment on or otherwise explain it 3447 or assist in its implementation may be prepared, copied, published 3448 and distributed, in whole or in part, without restriction of any 3449 kind, provided that the above copyright notice and this paragraph are 3450 included on all such copies and derivative works. However, this 3451 document itself may not be modified in any way, such as by removing 3452 the copyright notice or references to the Internet Society or other 3453 Internet organizations, except as needed for the purpose of 3454 developing Internet standards in which case the procedures for 3455 copyrights defined in the Internet Standards process must be 3456 followed, or as required to translate it into languages other than 3457 English. 3459 The limited permissions granted above are perpetual and will not be 3460 revoked by the Internet Society or its successors or assignees. 3462 This document and the information contained herein is provided on an 3463 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3464 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3465 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3466 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3467 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3469 Acknowledgement 3471 Funding for the RFC Editor function is currently provided by the 3472 Internet Society.