idnits 2.17.1 draft-ietf-xmpp-core-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 23 instances of too long lines in the document, the longest one being 6 characters in excess of 72. == There are 3 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 17, 2003) is 7769 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: '43' is mentioned on line 378, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. '1' == Outdated reference: A later version (-22) exists of draft-ietf-xmpp-im-00 ** Downref: Normative reference to an Informational RFC: RFC 2779 (ref. '3') ** Obsolete normative reference: RFC 793 (ref. '5') (Obsoleted by RFC 9293) -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Obsolete normative reference: RFC 2246 (ref. '7') (Obsoleted by RFC 4346) ** Obsolete normative reference: RFC 2060 (ref. '8') (Obsoleted by RFC 3501) ** Obsolete normative reference: RFC 2222 (ref. '12') (Obsoleted by RFC 4422, RFC 4752) ** Obsolete normative reference: RFC 2396 (ref. '13') (Obsoleted by RFC 3986) ** Downref: Normative reference to an Unknown state RFC: RFC 952 (ref. '14') -- Possible downref: Non-RFC (?) normative reference: ref. '16' ** 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. '20') (Obsoleted by RFC 3629) ** Downref: Normative reference to an Informational RFC: RFC 2781 (ref. '21') -- Possible downref: Non-RFC (?) normative reference: ref. '22' ** Obsolete normative reference: RFC 2078 (ref. '23') (Obsoleted by RFC 2743) Summary: 15 errors (**), 0 flaws (~~), 6 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Miller 3 Internet-Draft P. Saint-Andre 4 Expires: July 18, 2003 Jabber Software Foundation 5 January 17, 2003 7 XMPP Core 8 draft-ietf-xmpp-core-01 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at http:// 26 www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on July 18, 2003. 33 Copyright Notice 35 Copyright (C) The Internet Society (2003). All Rights Reserved. 37 Abstract 39 This document describes the core features of the eXtensible Messaging 40 and Presence Protocol (XMPP), which is used by the servers, clients, 41 and other applications that comprise the Jabber network. 43 Table of Contents 45 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 46 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4 47 1.2 Conventions Used in this Document . . . . . . . . . . . . . 4 48 1.3 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . 4 49 1.4 Intellectual Property Notice . . . . . . . . . . . . . . . . 4 50 2. Generalized Architecture . . . . . . . . . . . . . . . . . . 5 51 2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 5 52 2.2 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 53 2.3 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 54 2.4 Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . 6 55 2.5 Network . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 3. Addressing Scheme . . . . . . . . . . . . . . . . . . . . . 7 57 3.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 7 58 3.2 Domain Identifier . . . . . . . . . . . . . . . . . . . . . 7 59 3.3 Node Identifier . . . . . . . . . . . . . . . . . . . . . . 7 60 3.4 Resource Identifier . . . . . . . . . . . . . . . . . . . . 8 61 4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . 9 62 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 9 63 4.2 Restrictions . . . . . . . . . . . . . . . . . . . . . . . . 10 64 4.3 Stream Attributes . . . . . . . . . . . . . . . . . . . . . 10 65 4.4 Namespace Declarations . . . . . . . . . . . . . . . . . . . 11 66 4.5 Stream Features . . . . . . . . . . . . . . . . . . . . . . 12 67 4.6 Stream Errors . . . . . . . . . . . . . . . . . . . . . . . 12 68 4.7 Simple Streams Example . . . . . . . . . . . . . . . . . . . 13 69 5. Stream Authentication . . . . . . . . . . . . . . . . . . . 15 70 5.1 SASL Authentication . . . . . . . . . . . . . . . . . . . . 15 71 5.1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 15 72 5.1.2 Example . . . . . . . . . . . . . . . . . . . . . . . . . . 16 73 5.2 Dialback Authentication . . . . . . . . . . . . . . . . . . 18 74 5.2.1 Dialback Protocol . . . . . . . . . . . . . . . . . . . . . 20 75 6. Stream Encryption . . . . . . . . . . . . . . . . . . . . . 24 76 6.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 24 77 6.2 Protocol Example . . . . . . . . . . . . . . . . . . . . . . 25 78 6.3 Certificate-Based Authentication . . . . . . . . . . . . . . 26 79 7. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . 27 80 7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 27 81 7.2 Common Attributes . . . . . . . . . . . . . . . . . . . . . 27 82 7.2.1 to . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 83 7.2.2 from . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 84 7.2.3 id . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27 85 7.2.4 type . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 86 7.2.5 xml:lang . . . . . . . . . . . . . . . . . . . . . . . . . . 28 87 7.3 Message Stanzas . . . . . . . . . . . . . . . . . . . . . . 28 88 7.3.1 Types of Message . . . . . . . . . . . . . . . . . . . . . . 28 89 7.3.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 29 90 7.4 Presence Stanzas . . . . . . . . . . . . . . . . . . . . . . 30 91 7.4.1 Types of Presence . . . . . . . . . . . . . . . . . . . . . 30 92 7.4.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 31 93 7.5 IQ Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 32 94 7.5.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 32 95 7.5.2 Types of IQ . . . . . . . . . . . . . . . . . . . . . . . . 33 96 7.5.3 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 33 97 7.6 Extended Namespaces . . . . . . . . . . . . . . . . . . . . 33 98 8. XML Usage within XMPP . . . . . . . . . . . . . . . . . . . 35 99 8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 35 100 8.2 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . 35 101 8.3 Validation . . . . . . . . . . . . . . . . . . . . . . . . . 35 102 8.4 Character Encodings . . . . . . . . . . . . . . . . . . . . 36 103 8.5 Inclusion of Text Declaration . . . . . . . . . . . . . . . 36 104 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 37 105 10. Internationalization Considerations . . . . . . . . . . . . 38 106 11. Security Considerations . . . . . . . . . . . . . . . . . . 39 107 11.1 Client-to-Server Communications . . . . . . . . . . . . . . 39 108 11.2 Server-to-Server Communications . . . . . . . . . . . . . . 39 109 11.3 Minimum Security Mechanisms . . . . . . . . . . . . . . . . 39 110 11.4 Firewalls . . . . . . . . . . . . . . . . . . . . . . . . . 40 111 References . . . . . . . . . . . . . . . . . . . . . . . . . 41 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 42 113 A. Standard Error Codes . . . . . . . . . . . . . . . . . . . . 44 114 B. Formal Definitions . . . . . . . . . . . . . . . . . . . . . 46 115 B.1 streams namespace . . . . . . . . . . . . . . . . . . . . . 46 116 B.1.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 117 B.1.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 47 118 B.2 SASL namespace . . . . . . . . . . . . . . . . . . . . . . . 47 119 B.2.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48 120 B.2.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 121 B.3 jabber:client namespace . . . . . . . . . . . . . . . . . . 49 122 B.3.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49 123 B.3.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 124 B.4 jabber:server namespace . . . . . . . . . . . . . . . . . . 53 125 B.4.1 DTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53 126 B.4.2 Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 127 C. Revision History . . . . . . . . . . . . . . . . . . . . . . 58 128 C.1 Changes from draft-ietf-xmpp-core-00 . . . . . . . . . . . . 58 129 C.2 Changes from draft-miller-xmpp-core-02 . . . . . . . . . . . 58 130 Full Copyright Statement . . . . . . . . . . . . . . . . . . 60 132 1. Introduction 134 1.1 Overview 136 The eXtensible Messaging and Presence Protocol (XMPP) is an open XML 137 [1] protocol for near-real-time messaging and presence. The protocol 138 was developed originally within the Jabber community starting in 139 1998, and since 2001 has continued to evolve under the auspices of 140 the Jabber Software Foundation and now the XMPP WG. Currently, there 141 exist multiple implementations of the protocol, mostly offered under 142 the name of Jabber. In addition, there are countless deployments of 143 these implementations, which provide instant messaging (IM) and 144 presence services at and among thousands of domains to a user base 145 that is estimated at over one million end users. The current 146 document defines the core constituents of XMPP; XMPP IM [2] defines 147 the extensions necessary to provide basic instant messaging and 148 presence functionality that addresses the requirements defined in RFC 149 2779 [3]. 151 1.2 Conventions Used in this Document 153 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 154 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 155 "OPTIONAL" in this document are to be interpreted as described in RFC 156 2119 [4]. 158 1.3 Discussion Venue 160 The authors welcome discussion and comments related to the topics 161 presented in this document, preferably on the "xmppwg@jabber.org" 162 mailing list (archives and subscription information are available at 163 http://www.jabber.org/cgi-bin/mailman/listinfo/xmppwg/). 165 1.4 Intellectual Property Notice 167 This document is in full compliance with all provisions of Section 10 168 of RFC 2026. Parts of this specification use the term "jabber" for 169 identifying namespaces and other protocol syntax. Jabber[tm] is a 170 registered trademark of Jabber, Inc. Jabber, Inc. grants permission 171 to the IETF for use of the Jabber trademark in association with this 172 specification and its successors, if any. 174 2. Generalized Architecture 176 2.1 Overview 178 Although XMPP is not wedded to any specific network architecture, to 179 this point it has usually been implemented via a typical client- 180 server architecture, wherein a client utilizing XMPP accesses a 181 server over a TCP [5] socket. 183 The following diagram provides a high-level overview of this 184 architecture (where "-" represents communications that use XMPP and 185 "=" represents communications that use any other protocol). 187 C1 - S1 - S2 - C3 188 / \ 189 C2 - G1 = FN1 = FC1 191 The symbols are as follows: 193 o C1, C2, C3 -- XMPP clients 195 o S1, S2 -- XMPP servers 197 o G1 -- A gateway that translates between XMPP and the protocol(s) 198 used on a foreign messaging network 200 o FN1 -- A foreign messaging network 202 o FC1 -- A client on a foreign messaging network 204 2.2 Server 206 A server acts as an intelligent abstraction layer for XMPP 207 communications. Its primary responsibilities are to manage 208 connections from or sessions for other entities (in the form of XML 209 streams to and from authorized clients and other servers) and to 210 route appropriately-addressed XML data "stanzas" among such entities 211 over XML streams. Most XMPP-compliant servers also assume 212 responsibility for the storage of data that is used by clients (e.g., 213 the contact list for each IM user); in this case, the XML data is 214 processed directly by the server itself on behalf of the client and 215 is not routed to another entity. Compliant server implementations 216 MUST ensure in-order processing of XML stanzas received from 217 connected clients, servers, and services. 219 2.3 Client 221 Most clients connect directly to a server over a TCP socket and use 222 XMPP to take full advantage of the functionality provided by a server 223 and any associated services. (Clients on foreign messaging networks 224 may also be part of the architecture, made accessable via a gateway 225 to that network.) Multiple resources (e.g., devices or locations) MAY 226 connect simultaneously to a server on behalf of each authorized 227 client, with each resource connecting over a discrete TCP socket and 228 differentiated by the resource identifier of a JID (Section 3) (e.g., 229 user@domain/home vs. user@domain/work). The port assigned by the 230 IANA [6] for connections between a Jabber client and a Jabber server 231 is 5222. For further details about client-to-server communications 232 for the purpose of instant messaging and presence, refer to XMPP IM 233 [2]. 235 2.4 Gateway 237 A gateway is a special-purpose server-side service whose primary 238 function is to translate XMPP into the protocol(s) of another 239 messaging system, as well as to translate the return data back into 240 XMPP. Examples are gateways to Internet Relay Chat (IRC), Short 241 Message Service (SMS), SMTP, and foreign instant messaging networks 242 such as Yahoo!, MSN, ICQ, and AIM. Communications between gateways 243 and servers, and between gateways and the foreign messaging system, 244 are not defined in this document. 246 2.5 Network 248 Because each server is identified by a network address (typically a 249 DNS hostname) and because server-to-server communications are a 250 simple extension of the client-to-server protocol, in practice the 251 system consists of a network of servers that inter-communicate. Thus 252 user-a@domain1 is able to exchange messages, presence, and other 253 information with user-b@domain2. This pattern is familiar from 254 messaging protocols (such as SMTP) that make use of network 255 addressing standards. The usual method for providing a connection 256 between two servers is to open a TCP socket on the IANA-assigned port 257 5269 and to negotiate a connection using the Dialback Protocol 258 (Section 5.2) as defined in this document. 260 3. Addressing Scheme 262 3.1 Overview 264 Any entity that can be considered a network endpoint (i.e., an ID on 265 the network) and that can communicate using XMPP is considered a 266 Jabber Entity. All such entities are uniquely addressable in a form 267 that is consistent with RFC 2396 [13]. In particular, a valid Jabber 268 Identifier (JID) contains a set of ordered elements formed of a 269 domain identifier, node identifier, and resource identifier in the 270 following format: [node@]domain[/resource]. 272 All JIDs are based on the foregoing structure. The most common use 273 of this structure is to identify an IM user, the server to which the 274 user connects, and the user's active session or connection (e.g., a 275 specific client) in the form of user@domain/resource. However, node 276 types other than clients are possible; for example, a specific chat 277 room offered by a multi-user chat service could be addressed as 278 room@service, where "room" is the name of the chat room and "service" 279 is the hostname of the multi-user chat service. 281 3.2 Domain Identifier 283 The domain identifier is the primary identifier and is the only 284 REQUIRED element of a JID (a simple domain identifier is a valid 285 JID). It usually represents the network gateway or "primary" server 286 to which other entities connect for XML routing and data management 287 capabilities. However, the entity referenced by a domain identifier 288 is not always a server, and may be a service that is addressed as a 289 subdomain of a server and that provides functionality above and 290 beyond the capabilities of a server (a multi-user chat service, a 291 user directory, a gateway to a foreign messaging system, etc.). 293 The domain identifier for every server or service that will 294 communicate over a network SHOULD resolve to a Fully Qualified Domain 295 Name, and a domain identifier SHOULD conform to RFC 952 [14] and RFC 296 1123 [15]. Specifically, a domain identifier is case-insensitive 7- 297 bit ASCII and is limited to 255 bytes. 299 3.3 Node Identifier 301 The node identifier is an optional secondary identifier. It usually 302 represents the entity requesting and using network access provided by 303 the server or gateway (e.g., a client), although it can also 304 represent other kinds of entities (e.g., a multi-user chat room 305 associated with a multi-user chat service). The entity represented 306 by a node identifier is addressed within the context of a specific 307 domain (e.g., user@domain). Node identifiers are restricted to 255 308 bytes. A node identifier MAY contain any valid, properly transformed 309 UCS character (see Character Encodings (Section 8.4), as long as the 310 character code either is higher than #x20 or is not one of the 311 following: 313 o #x22 (") 315 o #x26 (&) 317 o #x27 (') 319 o #x3A (:) 321 o #x3C (<) 323 o #x3E (>) 325 o #x40 (@) 327 o #x7F (del) 329 o #xFFFE (BOM) 331 o #xFFFF (BOM) 333 Case is preserved, but comparisons are made in case-normalized 334 canonical form. 336 3.4 Resource Identifier 338 The resource identifer is an optional third identifier. It 339 represents a specific session, connection (e.g., a device or 340 location), or object (e.g., a participant in a multi-user chat room) 341 belonging to the entity associated with a node identifier. An entity 342 may maintain multiple resources simultaneously. A resource 343 identifier is restricted to 255 bytes in length. A resource 344 identifier MAY include any valid, properly transformed UCS character 345 (see Character Encodings (Section 8.4)) greater than #x20, except 346 #xFFFE and #xFFFF; if the character is a valid XML character as 347 defined in Section 2.2 of the XML specification [1], it MUST be 348 suitably escaped for inclusion within an XML stream. Resource 349 identifiers are case sensitive. 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, as a result, 358 discrete units of structured information that are referred to as "XML 359 stanzas". (Note: in this overview we use the example of 360 communications between a client and server; however XML streams are 361 more generalized and may be used for communications from server to 362 server and from service to server as well.) 364 In order to connect to a server, a client must initiate an XML stream 365 by sending a tag to the server, optionally preceded by a 366 text declaration specifying the XML version supported and the 367 character encoding. A compliant entity SHOULD accept any namespace 368 prefix on the element; however, for historical reasons some 369 entities MAY accept only a 'stream' prefix, resulting in use of a 370 element. The server SHOULD then reply with a second 371 XML stream back to the client, again optionally preceded by a text 372 declaration. 374 Within the context of an XML stream, a sender is able to send a 375 discrete semantic unit of structured information to any recipient. 376 This unit of structured information is a well-balanced XML stanza, 377 such as a message, presence, or IQ stanza (a stanza of an XML 378 document is said to be well-balanced if it matches production [43] 379 content of the XML specification [1]). These stanzas exist at the 380 direct child level (depth=1) of the root element. The 381 start of any XML stanza is unambiguously denoted by the element start 382 tag at depth=1 (e.g., ), and the end of any XML stanza is 383 unambiguously denoted by the corresponding close tag at depth=1 384 (e.g., ). Each XML stanza MAY contain child elements or 385 CDATA sections as necessary in order to convey the desired 386 information from the sender to the recipient. The session is closed 387 at the client's request by sending a closing tag to the 388 server. 390 Thus a client's session with a server can be seen as two open-ended 391 XML documents that are built up through the accumulation of the XML 392 stanzas that are sent over the course of the session (one from the 393 client to the server and one from the server to the client), and the 394 root element can be considered the document entity for 395 those streams. In essence, then, an XML stream acts as an envelope 396 for all the XML stanzas sent during a session. We can represent this 397 graphically as follows: 399 |-------------------| 400 | | 401 |-------------------| 402 | | 403 | | 404 | | 405 |-------------------| 406 | | 407 | | 408 | | 409 |-------------------| 410 | | 411 | | 412 | | 413 |-------------------| 414 | | 415 |-------------------| 417 4.2 Restrictions 419 XML streams are used to transport a subset of XML. Specifically, XML 420 streams SHOULD NOT contain processing instructions, predefined 421 entities (as defined in Section 4.6 of the XML specification [1]), 422 comments, or DTDs. Any such XML data SHOULD be ignored. 424 4.3 Stream Attributes 426 The attributes of the stream element are as follows (we now 427 generalize the endpoints by using the terms "initiating entity" and 428 "receiving entity"): 430 o to -- The 'to' attribute SHOULD be used only in the XML stream 431 from the initiating entity to the receiving entity, and MUST be 432 set to the JID of the receiving entity. There SHOULD be no 'to' 433 attribute set in the XML stream by which the receiving entity 434 replies to the initiating entity; however, if a 'to' attribute is 435 included, it SHOULD be ignored by the receiving entity. 437 o from -- The 'from' attribute SHOULD be used only in the XML stream 438 from the receiving entity to the initiating entity, and MUST be 439 set to the JID of the receiving entity granting access to the 440 initiating entity. There SHOULD be no 'from' attribute on the XML 441 stream sent from the initiating entity to the receiving entity; 442 however, if a 'from' attribute is included, it SHOULD be ignored 443 by the receiving entity. 445 o id -- The 'id' attribute SHOULD be used only in the XML stream 446 from the receiving entity to the initiating entity. This 447 attribute is a unique identifier created by the receiving entity 448 to function as a session key for the initiating entity's session 449 with the receiving entity. There SHOULD be no 'id' attribute on 450 the XML stream sent from the initiating entity to the receiving 451 entity; however, if an 'id' attribute is included, it SHOULD be 452 ignored by the receiving entity. 454 o version -- The 'version' attribute MAY be used in the XML stream 455 from the initiating entity to the receiving entity in order signal 456 compliance with the protocol defined herein; this is done by 457 setting the value of the attribute to "1.0". If the initiating 458 entity includes the version attribute, the receiving entity MUST 459 reciprocate by including the attribute in its response (if the 460 receiving entity supports XMPP 1.0). 462 We can summarize these values as follows: 464 | initiating to receiving | receiving to initiating 465 ------------------------------------------------------------ 466 to | JID of receiver | ignored 467 from | ignored | JID of receiver 468 id | ignored | session key 469 version | signals XMPP 1.0 support | signals XMPP 1.0 support 471 4.4 Namespace Declarations 473 The stream element MAY also contain namespace declarations as defined 474 in the XML namespaces specification [16]. 476 A default namespace declaration ('xmlns') is REQUIRED and is used in 477 both XML streams in order to scope the allowable first-level children 478 of the root stream element for both streams. This namespace 479 declaration MUST be the same for the initiating stream and the 480 responding stream so that both streams are scoped consistently. The 481 default namespace declaration applies to the stream and all stanzas 482 sent within a stream. 484 A stream namespace declaration (e.g., 'xmlns:stream') is REQUIRED in 485 both XML streams. A compliant entity MUST accept any namespace 486 prefix on the element; however, for historical reasons some 487 entities MAY accept only a 'stream' prefix, resulting in use of a 488 element as the stream root. The value of the stream 489 namespace MUST be "http://etherx.jabber.org/streams". 491 XML streams function as containers for any XML stanzas sent 492 asynchronously between network endpoints. It should be possible to 493 scope an XML stream with any default namespace declaration, i.e., it 494 should be possible to send any properly-namespaced XML stanza over an 495 XML stream. A compliant implementation MUST support the following 496 two namespaces (for historical reasons, existing implementations MAY 497 support only these two default namespaces): 499 o jabber:client -- this default namespace is declared when the 500 stream is used for communications between a client and a server 502 o jabber:server -- this default namespace is declared when the 503 stream is used for communications between two servers 505 The jabber:client and jabber:server namespaces are nearly identical 506 but are used in different contexts (client-to-server communications 507 for jabber:client and server-to-server communications for 508 jabber:server). The only difference between the two is that the 'to' 509 and 'from' attributes are OPTIONAL on stanzas sent within 510 jabber:client, whereas they are REQUIRED on stanzas sent within 511 jabber:server. If a compliant implementation accepts a stream that 512 is scoped by the 'jabber:client' or 'jabber:server' namespace, it 513 MUST support all three core stanza types (message, presence, and IQ) 514 as described herein and defined in the DTD and schema. 516 4.5 Stream Features 518 The root stream element MAY contain a features child element (e.g., 519 if the stream namespace prefix is 'stream'). This 520 is used to communicate generic stream-level capabilities including 521 stream-level features that can be negotiated as the streams are set 522 up. If the initiating entity sends a "version='1.0'" attribute in 523 its initiating stream element, the receiving entity MUST send a 524 features child element to the initiating entity if there are any 525 capabilities that need to be advertised or features that can be 526 negotiated for the stream. Currently this is used for SASL and TLS 527 negotiation only, but it could be used for other negotiable features 528 in the future (examples are shown under Stream Authentication 529 (Section 5) below). If an entity does not understand or support some 530 features, it should ignore them. 532 4.6 Stream Errors 534 The root stream element MAY contain an error child element (e.g., 535 if the stream namespace prefix is 'stream'). The 536 error child SHOULD be sent by a Jabber entity (usually a server 537 rather than a client) if it perceives that a stream-level error has 538 occurred. Examples include the sending of invalid XML, the shutdown 539 of a server, an internal server error such as the shutdown of a 540 session manager, and an attempt by a client to authenticate as the 541 same resource that is currently connected. If an error occurs at the 542 level of the stream, the entity (initiating entity or receiving 543 entity) that detects the error SHOULD send a stream error to the 544 other entity specifying why the streams are being closed and then 545 send a closing tag. XML of the following form is sent 546 within the context of an existing stream: 548 549 ... 550 551 Error message (e.g., "Invalid XML") 552 553 555 4.7 Simple Streams Example 557 The following is a simple stream-based session of a client on a 558 server (where the "C" lines are sent from the client to the server, 559 and the "S" lines are sent from the server to the client): 561 A simple session: 563 C: 564 569 S: 570 576 ... authentication ... 577 C: 578 C: Watson come here, I need you! 579 C: 580 S: 581 S: I'm on my way! 582 S: 583 C: 584 S: 586 These are in actuality a sending stream and a receiving stream, which 587 can be viewed a-chronologically as two XML documents: 589 C: 590 595 C: 596 C: Watson come here, I need you! 597 C: 598 C: 600 S: 601 607 S: 608 S: I'm on my way! 609 S: 610 S: 612 A session gone bad: 614 C: 615 620 S: 621 627 C: Bad XML, no closing body tag! 628 S: Invalid XML 629 S: 631 5. Stream Authentication 633 XMPP includes two methods for enforcing authentication at the level 634 of XML streams. When one entity is already known to another (i.e., 635 there is an existing trust relationship between the entities such as 636 that established when a user registers with a server or an 637 administrator configures a server to trust a service), the preferred 638 method for authenticating streams between the two entities uses an 639 XMPP adaptation of the Simple Authentication and Security Layer 640 (SASL) [12]. When there is no existing trust relationship between 641 the two entities, such trust MAY be established based on existing 642 trust in DNS; the authentication method used when two such entities 643 are servers is the server dialback protocol that is native to XMPP. 644 Both of these methods are described in this section. 646 5.1 SASL Authentication 648 5.1.1 Overview 650 The Simple Authentication and Security Layer (SASL) provides a 651 generalized method for adding authentication support to connection- 652 based protocols. XMPP uses a generic XML namespace profile for SASL 653 that conforms to section 4 ("Profiling Requirements") of RFC 2222 654 [12] (the namespace identifier for this protocol is http:// 655 www.iana.org/assignments/sasl-mechanisms). If an entity (client, 656 server, or service) is capable of authenticating by means of SASL, it 657 MUST include the agreed-upon SASL namespace within the opening root 658 stream tag it uses to initiate communications. 660 The following example shows the use of SASL in client authentication 661 with a server, for which the steps involved are as follows: 663 1. The client requests SASL authentication by including the 664 appropriate namespace declaration (xmlns:sasl='http:// 665 www.iana.org/assignments/sasl-mechanisms') in the opening XML 666 stream header sent to the server. 668 2. The server includes the xmlns:sasl namespace declaration in the 669 XML stream header sent in reply to the client. 671 3. The server responds with a list of available SASL authentication 672 mechanisms, each of which is a element included as a 673 child within a container element that is sent as a 674 first-level child of the root element. 676 4. The client selects a mechanism by sending an element to 677 the server; this element MAY optionally contain character data if 678 the mechanism supports or requires it. 680 5. If necessary, the server challenges the client by sending a 681 element to the client; this element MAY optionally 682 contain character data. 684 6. The client responds to challenge by sending a element 685 to the server; this element MAY optionally contain character 686 data. 688 7. If necessary, the server sends more challenges and the client 689 sends more responses. 691 This series of challenge/response pairs continues until one of three 692 things happens: 694 o The client aborts the handshake by sending a element to 695 the server. 697 o The server reports failure by sending a element to the 698 client. 700 o The server reports success by sending a element to the 701 client; this element MAY optionally contain character data. 703 Any character data contained within these elements MUST be encoded 704 using base64. 706 5.1.2 Example 708 The following example shows the data flow for a client authenticating 709 with a server using SASL. 711 Step 1: Client initiates stream to server: 713 719 Step 2: Server responds with a stream tag sent to the client: 721 727 Step 3: Server informs client of available authentication mechanisms: 729 730 731 DIGEST-MD5 732 PLAIN 733 734 736 Step 4: Client selects an authentication mechanism: 738 742 Step 5: Server sends a base64-encoded challenge to the client: 744 745 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 746 xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz 747 749 The decoded challenge is: 751 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ qop="auth",charset=utf- 752 8,algorithm=md5-sess 754 Step 6: Client responds to the challenge: 756 757 dXNlcm5hbWU9InJvYiIscmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik 758 9BNk1HOXRFUUdtMmhoIixjbm9uY2U9Ik9BNk1IWGg2VnFUclJrIixuYz0w 759 MDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJqYWJiZXIvY2F0YWNseX 760 NtLmN4IixyZXNwb25zZT1kMzg4ZGFkOTBkNGJiZDc2MGExNTIzMjFmMjE0 761 M2FmNyxjaGFyc2V0PXV0Zi04 762 764 The decoded response is: 766 username="rob",realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ 767 cnonce="OA6MHXh6VqTrRk",nc=00000001,qop=auth,\ digest-uri="jabber/ 768 cataclysm.cx",\ 769 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8 771 Step 7: Server sends another challenge to the client: 773 774 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 775 777 The decoded challenge is: 779 rspauth=ea40f60335c427b5527b84dbabcdfffd 781 Step 8: Client responds to the challenge: 783 785 Step 9: Server informs client of successful authentication: 787 789 Step 9 (alt): Server informs client of failed authentication: 791 793 5.2 Dialback Authentication 795 XMPP includes a protocol-level method for verifying that a connection 796 between two servers can be trusted to some degree. The method is 797 called dialback and is used only within XML streams that are declared 798 under the "jabber:server" namespace. 800 The purpose of the dialback protocol is to make server spoofing more 801 difficult, and thus to make it more difficult to forge XML stanzas. 802 Dialback is not intended as a mechanism for securing or encrypting 803 the streams between servers, only for helping to prevent the spoofing 804 of a server and the sending of false data from it. Dialback is made 805 possible by the existence of DNS, since one server can verify that 806 another server which is connecting to it is authorized to represent a 807 given server on the Jabber network. All DNS hostname resolutions 808 MUST first resolve the hostname using an SRV [18] record of 809 _jabber._tcp.server. If the SRV lookup fails, the fallback is a 810 normal A lookup to determine the IP address, using the jabber-server 811 port of 5269 assigned by the Internet Assigned Numbers Authority [6]. 813 Note that the method used to generate and verify the keys used in the 814 dialback protocol MUST take into account the hostnames being used, 815 along with a secret known only by the receiving server and the random 816 ID per stream. Generating unique but verifiable keys is important to 817 prevent common man-in-the-middle attacks and server spoofing. 819 In the description that follows we use the following terminology: 821 o Originating Server -- the server that is attempting to establish a 822 connection between the two servers 824 o Receiving Server -- the server that is trying to authenticate that 825 the Originating Server represents the Jabber server which it 826 claims to be 828 o Authoritative Server -- the server which is given when a DNS 829 lookup is performed on the name that the Originating Server 830 initially gave; for simple environments this will be the 831 Originating Server, but it could be a separate machine in the 832 Originating Server's network 834 The following is a brief summary of the order of events in dialback: 836 1. Originating Server establishes a connection to Receiving Server. 838 2. Originating Server sends a 'key' value over the connection to 839 Receiving Server. 841 3. Receiving Server establishes a connection to Authoritative 842 Server. 844 4. Receiving Server sends the same 'key' value to Authoritative 845 Server. 847 5. Authoritative Server replies that key is valid or invalid. 849 6. Receiving Server tells Originating Server whether it is 850 authenticated or not. 852 We can represent this flow of events graphically as follows: 854 Originating Receiving 855 Server Server 856 ----------- --------- 857 | | 858 | establish connection | 859 | ----------------------> | 860 | | 861 | send stream header | 862 | ----------------------> | 863 | | 864 | establish connection | 865 | <---------------------- | 866 | | 867 | send stream header | 868 | <---------------------- | 869 | | Authoritative 870 | send dialback key | Server 871 | ----------------------> | ------------- 872 | | | 873 | establish connection | 874 | ----------------------> | 875 | | 876 | send stream header | 877 | ----------------------> | 878 | | 879 | send stream header | 880 | <---------------------- | 881 | | 882 | send dialback key | 883 | ----------------------> | 884 | | 885 | validate dialback key | 886 | <---------------------- | 887 | 888 | report dialback result | 889 | <---------------------- | 890 | | 892 5.2.1 Dialback Protocol 894 The traffic sent between the servers is as follows: 896 1. Originating Server establishes connection to Receiving Server 898 2. Originating Server sends a stream header to Receiving Server 899 (the 'to' and 'from' attributes are NOT REQUIRED on the root 900 stream element): 902 907 Note: the value of the xmlns:db namespace declaration indicates 908 to Receiving Server that the Originating Server supports 909 dialback. 911 3. Receiving Server sends a stream header back to Originating 912 Server (the 'to' and 'from' attributes are NOT REQUIRED on the 913 root stream element): 915 921 4. Originating Server sends a dialback key to Receiving Server: 923 926 98AF014EDC0... 927 929 Note: this key is not examined by Receiving Server, since the 930 Receiving Server does not keep information about Originating 931 Server between sessions. 933 5. Receiving Server now establishes a connection back to 934 Originating Server, getting the Authoritative Server. 936 6. Receiving Server sends Authoritative Server a stream header (the 937 'to' and 'from' attributes are NOT REQUIRED on the root stream 938 element): 940 945 7. Authoritative Server sends Receiving Server a stream header: 947 953 8. Receiving Server sends Authoritative Server a stanza indicating 954 it wants Authoritative Server to verify a key: 956 960 98AF014EDC0... 961 963 Note: passed here are the hostnames, the original identifier 964 from Receiving Server's stream header to Originating Server in 965 step 2, and the key Originating Server gave Receiving Server in 966 step 3. Based on this information and shared secret information 967 within the 'Originating Server' network, the key is verified. 968 Any verifiable method can be used to generate the key. 970 9. Authoritative Server sends a stanza back to Receiving Server 971 verifying whether the key was valid or invalid: 973 979 or 981 987 10. Receiving Server informs Originating Server of the result: 989 994 Note: At this point the connection has either been validated via 995 a type='valid', or reported as invalid. Once the connection is 996 validated, data can be sent by the Originating Server and read 997 by the Receiving Server; before that, all data stanzas sent to 998 Receiving Server SHOULD be dropped. As a final guard against 999 domain spoofing, the Receiving Server MUST verify that all XML 1000 stanzas received from the Originating Server include a 'from' 1001 attribute and that the value of that attribute includes the 1002 validated domain. In addition, all XML stanzas MUST include a 1003 'to' attribute. 1005 6. Stream Encryption 1007 6.1 Overview 1009 XMPP includes a method for securing the stream from tampering and 1010 eavesdropping. This method makes use of the Transport Layer Security 1011 (TLS) [7] protocol, along with a "STARTTLS" extension that is 1012 modelled on similar extensions for the IMAP [8], POP3 [9], and ACAP 1013 [10] protocols as described in RFC 2595 [11]. 1015 The namespace identifier for the STARTTLS extension is http:// 1016 www.ietf.org/rfc/rfc2595.txt. If an entity (client, server or 1017 service) is capable of using this extension, it MUST include the 1018 element in this namespace with the list of features that 1019 it sends in response to the opening stream tag that was used to 1020 initiate communications. 1022 The following example shows the use of STARTTLS by a client to secure 1023 a session with a server, for wich the steps involved are as follows: 1025 1. The client initiates the stream by sending the opening XML stream 1026 header to the server. 1028 2. The server responds by sending an XML stream header to the 1029 client. 1031 3. The server offers the STARTTLS extension to the client by 1032 including it in the list of supported stream features. 1034 4. The client issues the STARTTLS command to instruct the server 1035 that it wishes to begin a TLS negotiation to secure the stream. 1037 5. The server closes the XML stream, but keeps the underlying 1038 connection open. If the server is unable to prepare for the TLS 1039 negotiation for some reason, it returns an error. 1041 6. The client begins a TLS negotiation according to RFC 2246 [7]. 1042 Upon completion of the negotiation, the client initiates a new 1043 stream by sending a new opening XML stream header to the server. 1045 7. The server responds by sending an XML stream header to the 1046 client. 1048 Once the stream is secured, the server MUST NOT offer the STARTTLS 1049 extension to the client. 1051 6.2 Protocol Example 1053 The following example shows the data flow for a client securing a 1054 stream using STARTTLS. 1056 Step 1: Client initiates stream to server: 1058 1064 Step 2: Server responds by sending a stream tag to the client: 1066 1072 Step 3: Server sends STARTTLS extensions to the client along with 1073 authentication mechanisms and any other stream features: 1075 1076 1077 1078 DIGEST-MD5 1079 PLAIN 1080 1081 1083 Step 4: Client sends the STARTTLS command to the server: 1085 1087 Step 5: Server closes the stream: 1089 1091 Step 5 (alt): Server fails to prepare for the TLS negotiation: 1093 1094 Step 6: Client begins TLS negotiation. When it has finished, it 1095 initiates a new stream to the server:: 1097 1102 1103 1104 DIGEST-MD5 1105 PLAIN 1106 EXTERNAL 1107 1108 1110 Step 7: Server responds by sending a stream tag to the client: 1112 1118 6.3 Certificate-Based Authentication 1120 If the client presents a valid client certificate during the TLS 1121 negotiation, the server MAY offer the SASL EXTERNAL mechanism to the 1122 client (see RFC 2222 [12]). If the client selects this mechanism for 1123 authentication, the authentication credentials shall be taken from 1124 the presented certificate. 1126 7. XML Stanzas 1128 7.1 Overview 1130 There are three core data elements for XMPP communications: , , and . These elements are sent as direct 1132 (depth=1) children of the root element and are scoped by 1133 one of the default namespaces identified in Section 4.4. Any such 1134 direct child element of the root stream element is called an "XML 1135 stanza". 1137 7.2 Common Attributes 1139 Four attributes are common to message, presence, and IQ stanzas. 1140 These are defined below. 1142 7.2.1 to 1144 The 'to' attribute specifies the JID of the intended recipient for 1145 the stanza. In the 'jabber:client' namespace, a stanza SHOULD 1146 possess a 'to' attribute, although a stanza sent from a client to a 1147 server for handling by that server (e.g., presence sent to the server 1148 for broadcasting to other entities) MAY legitimately lack a 'to' 1149 attribute. In the 'jabber:server' namespace, a stanza MUST possess a 1150 'to' attribute. 1152 7.2.2 from 1154 The 'from' attribute specifies the JID of the sender. 1156 In the 'jabber:client' namespace, a client MUST NOT include a 'from' 1157 attribute on the stanzas it sends to a server; if a server receives a 1158 stanza from a client and the stanza possesses a 'from' attribute, it 1159 MUST ignore the value of the 'from' attribute. In addition, a server 1160 MUST stamp stanzas received from a client with the user@domain/ 1161 resource (full JID) of the connected resource that generated the 1162 stanza. In the 'jabber:server' namespace, a stanza MUST possess a 1163 'from' attribute. 1165 A server MUST include a 'from' attribute on stanzas it routes to 1166 other servers. The domain identifier of the JID contained in the 1167 'from' attribute MUST match the hostname of the server as 1168 communicated in the dialback negotiation (or a subdomain thereof). 1170 7.2.3 id 1172 The optional 'id' attribute MAY be used to track stanzas sent and 1173 received. The 'id' attribute is generated by the sender. An 'id' 1174 attribute included in an IQ request of type "get" or "set" SHOULD be 1175 returned to the sender in any IQ response of type "result" or "error" 1176 generated by the recipient of the request. A recipient of a message 1177 or presence stanza MAY return that 'id' in any replies, but is NOT 1178 REQUIRED to do so. 1180 The value of the 'id' attribute is not intended to be unique -- 1181 globally, within a domain, or within a stream. It is generated by a 1182 sender only for internal tracking of information within the sending 1183 application. 1185 7.2.4 type 1187 The 'type' attribute specifies detailed information about the purpose 1188 or context of the message, presence, or IQ stanza. The particular 1189 allowable values for the 'type' attribute vary depending on whether 1190 the stanza is a message, presence, or IQ, and thus are specified in 1191 the following sections. 1193 7.2.5 xml:lang 1195 Any message or presence stanza MAY possess an 'xml:lang' attribute 1196 specifying the default language of any CDATA sections of the stanza 1197 or its child elements. An IQ stanza SHOULD NOT possess an 'xml:lang' 1198 attribute, since it is merely a vessel for data in other namespaces 1199 and does not itself contain children that have CDATA. The value of 1200 the 'xml:lang' attribute MUST be a NMTOKEN and MUST conform to the 1201 format defined in RFC 3066 [17]. 1203 7.3 Message Stanzas 1205 Message stanzas in the 'jabber:client' or 'jabber:server' namespace 1206 are used to "push" information to another entity. Common uses in the 1207 context of instant messaging include single messages, messages sent 1208 in the context of a chat conversation, messages sent in the context 1209 of a multi-user chat room, headlines, and errors. These messages 1210 types are identified more fully below. 1212 7.3.1 Types of Message 1214 The 'type' attribute of a message stanza is optional and specifies 1215 the conversational context of the message. The sending of a message 1216 stanza without a 'type' attribute signals that the message stanza is 1217 a single message. However, the 'type' attribute MAY also have one of 1218 the following values: 1220 o chat -- The message is sent in the context of a one-to-one chat 1221 conversation. 1223 o groupchat -- The message is sent in the context of a multi-user 1224 chat environment. 1226 o headline -- The message is generated by an automated service that 1227 delivers content (news, sports, market information, etc.). 1229 o error - A message returned to a sender specifying an error 1230 associated with a previous message sent by the sender (for a full 1231 list of error messages, see error codes (Appendix A)) 1233 For detailed information about these message types, refer to XMPP IM 1234 [2]. 1236 7.3.2 Children 1238 If a message stanza in the 'jabber:client' or 'jabber:server' 1239 namespace has no 'type' attribute or has a 'type' attribute with a 1240 value of "chat", "groupchat", or "headline", it MAY contain any of 1241 the following child elements (which MUST NOT contain mixed content): 1243 o body -- The textual contents of the message; normally included but 1244 NOT REQUIRED. The element MUST NOT possess any 1245 attributes, with the exception of the 'xml:lang' attribute. 1246 Multiple instances of the element MAY be included but only 1247 if each instance possesses an 'xml:lang' attribute with a distinct 1248 language value. 1250 o subject -- The subject of the message. The element 1251 MUST NOT possess any attributes, with the exception of the 1252 'xml:lang' attribute. Multiple instances of the 1253 element MAY be included for the purpose of providing alternate 1254 versions of the same subject, but only if each instance possesses 1255 an 'xml:lang' attribute with a distinct language value. 1257 o thread -- A random string that is generated by the sender and that 1258 MAY be copied back in replies; it is used for tracking a 1259 conversation thread (sometimes referred to as an "IM session") 1260 between two entities. If used, it MUST be unique to that 1261 conversation thread within the stream and MUST be consistent 1262 throughout that conversation. The use of the element is 1263 optional and is not used to identify individual messages, only 1264 conversations. The recommended method for generating thread IDs 1265 is to concatenate the sender's full JID, the recipient's full JID, 1266 and an absolute date and time, then hash the resulting string 1267 according to the SHA1 algorithm. Only one element MAY 1268 be included in a message stanza, and it MUST NOT possess any 1269 attributes. The element MUST be treated as an opaque 1270 string by entities; no semantic meaning may be derived from it, 1271 and only exact, case insensitve comparisons can be made against 1272 it. 1274 If the message stanza is of type "error", it MUST include an 1275 child, which in turn MUST possess a 'code' attribute corresponding to 1276 one of the standard error codes (Appendix A), MAY possess an 1277 'xml:lang' attribute, and MAY also contain PCDATA corresponding to a 1278 natural-language description of the error. An child MUST 1279 NOT be included if the stanza type is anything other than "error". 1281 As described under extended namespaces (Section 7.6), a message 1282 stanza MAY also contain any properly-namespaced child element (other 1283 than the core data elements, stream elements, or defined children 1284 thereof). 1286 7.4 Presence Stanzas 1288 Presence stanzas are used in the 'jabber:client' or 'jabber:server' 1289 namespace to express an entity's current availability status (offline 1290 or online, along with various sub-states of the latter) and to 1291 communicate that status to other entities. They are also used to 1292 negotiate and manage subscriptions to the presence of other entities. 1294 7.4.1 Types of Presence 1296 The 'type' attribute of a presence stanza is optional. A presence 1297 stanza that does not have a 'type' attribute is used to signal that 1298 the sender is online and available for communication. If included, 1299 the 'type' attribute specifies the availability state of the sender, 1300 a request to manage a subscription to another entity's presence, a 1301 request for another entity's current presence, or an error related to 1302 a previously-sent presence stanza. The 'type' attribute MAY have one 1303 of the following values: 1305 o unavailable -- Signals that the entity is no longer available for 1306 communication. 1308 o subscribe -- The sender wishes to subscribe to the recipient's 1309 presence. 1311 o subscribed -- The sender has allowed the recipient to receive 1312 their presence. 1314 o unsubscribe -- A notification that an entity is unsubscribing from 1315 another entity's presence. 1317 o unsubscribed -- The subscription request has been denied or a 1318 previously-granted subscription has been cancelled. 1320 o probe -- A request for an entity's current presence. In general 1321 SHOULD NOT be sent by a client. 1323 o error -- An error has occurred regarding processing or delivery of 1324 a previously-sent presence stanza. 1326 Information about the subscription model used within XMPP can be 1327 found in XMPP IM [2]. 1329 7.4.2 Children 1331 If a presence stanza possesses no 'type' attribute, it MAY contain 1332 any of the following child elements (note that the child 1333 MAY be sent in a presence stanza of type "unavailable" or, for 1334 historical reasons, "subscribe"): 1336 o show -- Describes the availability status of an entity or specific 1337 resource. Only one element MAY be included in a presence 1338 stanza, and it MUST NOT possess any attributes. The value SHOULD 1339 be one of the following (values other than these four MAY be 1340 ignored; additional availability types could be defined through a 1341 properly-namespaced child element of the presence stanza): 1343 * away -- The entity or resource is temporarily away. 1345 * chat -- The entity or resource is actively interested in 1346 chatting. 1348 * xa -- The entity or resource is away for an extended period (xa 1349 = "eXtended Away"). 1351 * dnd -- The entity or resource is busy (dnd = "Do Not Disturb"). 1353 o status -- An optional natural-language description of availability 1354 status. Normally used in conjunction with the show element to 1355 provide a detailed description of an availability state (e.g., "In 1356 a meeting"). The element MUST NOT possess any 1357 attributes, with the exception of the 'xml:lang' attribute. 1358 Multiple instances of the element MAY be included but 1359 only if each instance possesses an 'xml:lang' attribute with a 1360 distinct language value. 1362 o priority -- An optional element specifying the priority level of 1363 the connected resource. The value may be any integer between -128 1364 to 127. Only one element MAY be included in a 1365 presence stanza, and it MUST NOT possess any attributes. 1367 If the presence stanza is of type "error", it MUST include an child, which in turn MUST possess a 'code' attribute corresponding 1369 to one of the standard error codes (Appendix A) and MAY contain 1370 PCDATA corresponding to a natural-language description of the error. 1371 An child MUST NOT be included if the stanza type is anything 1372 other than "error". 1374 As described under extended namespaces (Section 7.6), a presence 1375 stanza MAY also contain any properly-namespaced child element (other 1376 than the core data elements, stream elements, or defined children 1377 thereof). 1379 7.5 IQ Stanzas 1381 7.5.1 Overview 1383 Info/Query, or IQ, is a simple request-response mechanism. Just as 1384 HTTP is a request-response medium, so IQ stanzas in the 1385 'jabber:client' or 'jabber:server' namespace enable an entity to make 1386 a request of, and receive a response from, another entity. The data 1387 content of the request and response is defined by the namespace 1388 declaration of a direct child element of the IQ element, and the 1389 interaction is tracked by the requesting entity through use of the 1390 'id' attribute, which responding entities SHOULD return in any 1391 response. 1393 Most IQ interactions follow a common pattern of structured data 1394 exchange such as get/result or set/result (although an error may be 1395 returned in response to a request if appropriate): 1397 Requesting Responding 1398 Entity Entity 1399 ---------- ---------- 1400 | | 1401 | | 1402 | ------------------------> | 1403 | | 1404 | | 1405 | <------------------------ | 1406 | | 1407 | | 1408 | ------------------------> | 1409 | | 1410 | | 1411 | <------------------------ | 1412 | | 1414 An entity that receives an IQ request of type 'get' or 'set' MUST 1415 reply with an IQ response of type 'result' or 'error' (which response 1416 SHOULD preserve the 'id' attribute of the request). An entity that 1417 receives a stanza of type 'result' or 'error' MUST NOT respond to the 1418 stanza by sending a further IQ response of type 'result' or 'error'; 1419 however, as shown above, the requesting entity MAY send another 1420 request (e.g., an IQ of type 'set' in order to provide required 1421 information discovered through a get/result pair). 1423 7.5.2 Types of IQ 1425 The 'type' attribute of an IQ stanza is REQUIRED. The 'type' 1426 attribute specifies a distinct step within a request-response 1427 interaction. The value SHOULD be one of the following (all other 1428 values MAY be ignored): 1430 o get -- The stanza is a request for information. 1432 o set -- The stanza provides required data, sets new values, or 1433 replaces existing values. 1435 o result -- The stanza is a response to a successful get or set 1436 request. 1438 o error -- An error has occurred regarding processing or delivery of 1439 a previously-sent get or set. 1441 7.5.3 Children 1443 An IQ stanza contains no children in the 'jabber:client' or 1444 'jabber:server' namespace since it is a vessel for XML in another 1445 namespace. As described under extended namespaces (Section 7.6), an 1446 IQ stanza MAY contain any properly-namespaced child element (other 1447 than the core data elements, stream elements, or defined children 1448 thereof). 1450 If the IQ stanza is of type "error", it MUST include an 1451 child, which in turn MUST possess a 'code' attribute corresponding to 1452 one of the standard error codes (Appendix A) and MAY contain PCDATA 1453 corresponding to a natural-language description of the error. An 1454 child MUST NOT be included if the stanza type is anything 1455 other than "error". 1457 7.6 Extended Namespaces 1459 While the core data elements defined in this document provide a basic 1460 level of functionality for messaging and presence, XMPP uses XML 1461 namespaces to extend the core data elements for the purpose of 1462 providing additional functionality. Thus a message, presence, or IQ 1463 stanza MAY house one or more optional child elements containing 1464 content that extends the meaning of the message (e.g., an encrypted 1465 form of the message body). This child element MAY be any element 1466 (other than the core data elements, stream elements, or defined 1467 children thereof). The child element MUST possess an 'xmlns' 1468 namespace declaration (other than the stream namespace and the 1469 default namespace) that defines all data contained within the child 1470 element. 1472 Support for any given extended namespace is OPTIONAL on the part of 1473 any implementation. If an entity does not understand such a 1474 namespace, it MUST ignore the associated XML data (if the stanza is 1475 being routed on to another entity, ignore means "pass it on 1476 untouched"). If an entity receives an IQ stanza in a namespace it 1477 does not understand, the entity SHOULD return an IQ stanza of type 1478 "error" with an error element of code 400 (bad request). If an 1479 entity receives a message or presence stanza that contains XML data 1480 in an extended namespace it does not understand, the portion of the 1481 stanza that is in the unknown namespace SHOULD be ignored. If an 1482 entity receives a message stanza without a element but 1483 containing only a child element bound by a namespace it does not 1484 understand, it MUST ignore that stanza. 1486 8. XML Usage within XMPP 1488 8.1 Overview 1490 In essence, XMPP core consists of three interrelated parts: 1492 1. XML streams (Section 4), which provide a stateful means for 1493 transporting data in an asynchronous manner from one entity to 1494 another 1496 2. stream authentication using SASL authentication (Section 5.1) or 1497 the dialback protocol (Section 5.2) 1499 3. XML stanzas (Section 7) (message, presence, and IQ), which 1500 provide a framework for communications between entities 1502 XML [1] is used to define each of these protocols, as described in 1503 detail in the following sections. 1505 In addition, XMPP contains protocol extensions (such as extended 1506 namespaces) that address the specific functionality required to 1507 create a basic instant messaging and presence application; these non- 1508 core protocol extensions are defined in XMPP IM [2]. 1510 8.2 Namespaces 1512 XML Namespaces [16] are used within all XMPP-compliant XML to create 1513 strict boundaries of data ownership. The basic function of 1514 namespaces is to separate different vocabularies of XML elements that 1515 are structurally mixed together. Ensuring that XMPP-compliant XML is 1516 namespace-aware enables any XML to be structurally mixed with any 1517 data element within XMPP. Mainly for historical reasons, the default 1518 namespace for XMPP data stanzas MUST be one of the namespaces 1519 identified in Section 4.4. 1521 Additionally, XMPP is more strict about namespace prefixes than the 1522 XML namespace specification requires. 1524 8.3 Validation 1526 A server is not responsible for validating the XML elements forwarded 1527 to a client; an implementation MAY choose to provide only validated 1528 data elements but is NOT REQUIRED to do so. Clients SHOULD NOT rely 1529 on the ability to send data which does not conform to the schemas, 1530 and SHOULD ignore any non-conformant elements or attributes on the 1531 incoming XML stream. Validation of XML streams and stanzas is NOT 1532 REQUIRED or recommended, and DTDs and schemas are included herein for 1533 descriptive purposes only. 1535 8.4 Character Encodings 1537 Software implementing XML streams MUST support the UTF-8 (RFC 2279 1538 [20]) and UTF-16 (RFC 2781 [21]) transformations of Universal 1539 Character Set (ISO/IEC 10646-1 [22]) characters. Software MUST NOT 1540 attempt to use any other encoding for transmitted data. The 1541 encodings of the transmit and receive streams are independent. 1542 Software MAY select either UTF-8 or UTF-16 for the transmitted 1543 stream, and SHOULD deduce the encoding of the received stream as 1544 described in the XML specification [1]. For historical reasons, 1545 existing implementations MAY support UTF-8 only. 1547 8.5 Inclusion of Text Declaration 1549 An application MAY send a text declaration. Applications MUST follow 1550 the rules in the XML specification [1] concerning the circumstances 1551 in which a text declaration is included. 1553 9. IANA Considerations 1555 The IANA registers "jabber-client" and "jabber-server" as GSS-API 1556 [23] service names, as specified in Section 6.1.1; these service 1557 names are associated with TCP ports 5222 and 5269 respectively. 1559 10. Internationalization Considerations 1561 o If a client sends an xml:lang attribute on a stanza, the server 1562 MUST NOT modify or delete it. 1564 11. Security Considerations 1566 11.1 Client-to-Server Communications 1568 The SASL protocol for authenticating XML streams negotiated between a 1569 client and a server (defined under Section 5.1 above) provides a 1570 reliable mechanism for validating that a client connecting to a 1571 server is who it claims to be. 1573 The IP address and method of access of clients MUST NOT be made 1574 available by a server, nor are any connections other than the 1575 original server connection required. This helps protect the client's 1576 server from direct attack or identification by third parties. 1578 End-to-end encryption of message bodies and presence status 1579 information MAY be effected through use of OpenPGP [19]. 1581 11.2 Server-to-Server Communications 1583 It is OPTIONAL for any given server to communicate with other 1584 servers, and server-to-server communications MAY be disabled by the 1585 administrator of any given deployment. 1587 If two servers would like to enable communications between 1588 themselves, they MUST form a relationship of trust at some level, 1589 either based on trust in DNS or based on a pre-existing trust 1590 relationship (e.g., through exchange of certificates). If two 1591 servers have a pre-existing trust relationship, they MAY use SASL 1592 Authentication (Section 5.1) for the purpose of authenticating each 1593 other. If they do not have a pre-existing relationship, they MUST 1594 use the Dialback Protocol (Section 5.2), which provides a reliable 1595 mechanism for preventing the spoofing of servers. 1597 11.3 Minimum Security Mechanisms 1599 Although service provisioning is a policy matter, at a minimum, all 1600 implementations MUST support the following mechanisms: 1602 for authentication: the SASL DIGEST-MD5 mechanism 1604 for confidentiality: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA 1605 cipher) 1607 for both: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher 1608 supporting client-side certificates) 1610 11.4 Firewalls 1612 Communications using XMPP occur over TCP sockets on port 5222 1613 (client-to-server) or port 5269 (server-to-server), as registered 1614 with the IANA [6]. Use of these well-known ports allows 1615 administrators to easily enable or disable XMPP activity through 1616 existing and commonly-deployed firewalls. 1618 References 1620 [1] World Wide Web Consortium, "Extensible Markup Language (XML) 1621 1.0 (Second Edition)", W3C xml, October 2000, . 1624 [2] Miller, J. and P. Saint-Andre, "XMPP Instant Messaging (draft- 1625 ietf-xmpp-im-00, work in progress)", December 2002. 1627 [3] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for 1628 Presence and Instant Messaging", RFC 2779, February 2000, 1629 . 1631 [4] Bradner, S., "Key words for use in RFCs to Indicate Requirement 1632 Levels", BCP 14, RFC 2119, March 1997. 1634 [5] University of Southern California, "Transmission Control 1635 Protocol", RFC 793, September 1981, . 1638 [6] Internet Assigned Numbers Authority, "Internet Assigned Numbers 1639 Authority", January 1998, . 1641 [7] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 1642 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 1643 1999. 1645 [8] Crispin, M., "Internet Message Access Protocol - Version 1646 4rev1", RFC 2060, December 1996. 1648 [9] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 1649 53, RFC 1939, May 1996. 1651 [10] Newman, C. and J. Myers, "ACAP -- Application Configuration 1652 Access Protocol", RFC 2244, November 1997. 1654 [11] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, 1655 June 1999. 1657 [12] Myers, J., "Simple Authentication and Security Layer (SASL)", 1658 RFC 2222, October 1997. 1660 [13] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 1661 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1662 1998, . 1664 [14] Harrenstien, K., Stahl, M. and E. Feinler, "DoD Internet host 1665 table specification", RFC 952, October 1985. 1667 [15] Braden, R., "Requirements for Internet Hosts - Application and 1668 Support", STD 3, RFC 1123, October 1989. 1670 [16] World Wide Web Consortium, "Namespaces in XML", W3C xml-names, 1671 January 1999, . 1674 [17] Alvestrand, H., "Tags for the Identification of Languages", BCP 1675 47, RFC 3066, January 2001. 1677 [18] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the 1678 location of services (DNS SRV)", RFC 2052, October 1996. 1680 [19] Elkins, M., Del Torto, D., Levien, R. and T. Roessler, "MIME 1681 Security with OpenPGP", RFC 3156, August 2001. 1683 [20] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 1684 2279, January 1998. 1686 [21] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", 1687 RFC 2781, February 2000. 1689 [22] International Organization for Standardization, "Information 1690 Technology - Universal Multiple-octet coded Character Set (UCS) 1691 - Amendment 2: UCS Transformation Format 8 (UTF-8)", ISO 1692 Standard 10646-1 Addendum 2, October 1996. 1694 [23] Linn, J., "Generic Security Service Application Program 1695 Interface, Version 2", RFC 2078, January 1997. 1697 Authors' Addresses 1699 Jeremie Miller 1700 Jabber Software Foundation 1701 1899 Wynkoop Street, Suite 600 1702 Denver, CO 80202 1703 US 1705 EMail: jeremie@jabber.org 1706 URI: http://www.jabber.org/people/jer.php 1707 Peter Saint-Andre 1708 Jabber Software Foundation 1709 1899 Wynkoop Street, Suite 600 1710 Denver, CO 80202 1711 US 1713 EMail: stpeter@jabber.org 1714 URI: http://www.jabber.org/people/stpeter.php 1716 Appendix A. Standard Error Codes 1718 A standard error element is used for failed processing of XML 1719 stanzas. This element is a child of the failed stanza and MUST 1720 include a 'code' attribute corresponding to one of the following 1721 error codes. 1723 o 302 (Redirect) - Whereas HTTP contains eight different codes for 1724 redirection, XMPP contains only one (which is intended to stand 1725 for any redirection error). However, code 302 is being reserved 1726 for future functionality and is not implemented at this time. 1728 o 400 (Bad Request) - Code 400 is used to inform a sender that a 1729 request could not be understood by the recipient. This might be 1730 generated when, for example, an entity sends a message that does 1731 not have a 'to' attribute. 1733 o 401 (Unauthorized) - Code 401 is used to inform clients that they 1734 have provided incorrect authorization information, e.g., an 1735 incorrect password or unknown username when attempting to 1736 authenticate with a server. 1738 o 402 (Payment Required) - Code 402 is being reserved for future 1739 use. 1741 o 403 (Forbidden) - Code 403 is used to inform an entity that the 1742 its request was understood but that the recipient is refusing to 1743 fulfill it, e.g., if a user attempts to set information associated 1744 with another user. 1746 o 404 (Not Found) - Code 404 is used to inform a sender that no 1747 recipient was found matching the JID to which an XML stanza was 1748 sent, e.g., if a sender has attempted to send a message to a JID 1749 that does not exist. (Note: if the server of the intended 1750 recipient cannot be reached, an error code from the 500 series 1751 must be sent). 1753 o 405 (Not Allowed) - Code 405 is used when the action requested is 1754 not allowed for the JID identified by the 'from' address, e.g., if 1755 a client attempts to set the time or version of a server. 1757 o 406 (Not Acceptable) - Code 406 is used when an XML stanza is for 1758 some reason not acceptable to a server or other entity. This 1759 might be generated when, for example, a user attempts to register 1760 with a server using an empty password. 1762 o 407 (Registration Required) - Code 407 is used when a message or 1763 request is sent to a service that requires prior registration, 1764 e.g., if a user attempts to send a message through a gateway to a 1765 foreign messaging system without having first registered with that 1766 gateway. 1768 o 408 (Request Timeout) - Code 408 is returned when a recipient does 1769 not produce a response within the time that the sender was 1770 prepared to wait. 1772 o 500 (Internal Server Error) - Code 500 is used when a server or 1773 service encounters an unexpected condition which prevents it from 1774 handling an XML stanza from a sender, e.g., if an authentication 1775 request is not handled by a server because the password could not 1776 be retrieved. 1778 o 501 (Not Implemented) - Code 501 is used when the recipient does 1779 not support the functionality being requested by a sender, e.g., 1780 if a user attempts to register with a server that does not allow 1781 registration. 1783 o 502 (Remote Server Error) - Code 502 is used when delivery of an 1784 XML stanza fails because of an inability to reach the intended 1785 remote server or service, e.g., because a remote server's hostname 1786 could not be resolved. 1788 o 503 (Service Unavailable) - Code 503 is used when a sender 1789 requests a service that a recipient is temporarily unable to 1790 offer. 1792 o 504 (Remote Server Timeout) - Code 504 is used when attempts to 1793 contact a remote server timeout, e.g., if an incorrect hostname is 1794 specified. 1796 Appendix B. Formal Definitions 1798 B.1 streams namespace 1800 The namespace declaration for the root stream element is 'http:// 1801 etherx.jabber.org/streams'. 1803 B.1.1 DTD 1805 1806 1807 1813 1814 1816 B.1.2 Schema 1818 1819 1825 1826 1827 1828 1829 1832 1835 1836 1837 1838 1839 1840 1841 1843 1845 1847 B.2 SASL namespace 1849 The namespace declaration for SASL-related elements is 'http:// 1850 www.iana.org/assignments/sasl-mechanisms'. 1852 B.2.1 DTD 1854 1855 1856 1857 1858 1859 1860 1861 1862 1863 1865 B.2.2 Schema 1867 1868 1874 1875 1876 1877 1878 1879 1880 1882 1884 1885 1886 1887 1888 1890 1891 1892 1893 1894 1896 1898 B.3 jabber:client namespace 1900 B.3.1 DTD 1902 1903 1906 1915 1916 1917 1918 1919 1921 1923 1932 1933 1934 1935 1937 1939 1946 1947 1952 B.3.2 Schema 1954 1955 1961 1962 1963 1964 1965 1966 1967 1968 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1990 1991 1992 1993 1994 1996 1997 1998 1999 2000 2002 2004 2005 2006 2007 2008 2009 2010 2011 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2046 2047 2048 2049 2050 2052 2054 2055 2056 2057 2058 2062 2063 2064 2065 2066 2067 2068 2069 2070 2071 2072 2073 2074 2075 2076 2077 2079 2080 2081 2085 2086 2087 2089 2091 B.4 jabber:server namespace 2093 B.4.1 DTD 2095 2096 2099 2107 2108 2109 2110 2111 2113 2115 2124 2125 2126 2127 2129 2131 2138 2139 2144 B.4.2 Schema 2146 2147 2153 2154 2155 2156 2157 2158 2159 2160 2164 2165 2166 2167 2168 2169 2170 2171 2172 2173 2174 2175 2176 2177 2178 2179 2180 2182 2183 2184 2185 2186 2188 2189 2190 2191 2192 2194 2196 2197 2198 2199 2200 2201 2202 2203 2207 2208 2209 2210 2211 2212 2213 2214 2215 2216 2217 2218 2219 2220 2221 2222 2223 2224 2225 2227 2228 2229 2230 2231 2232 2233 2234 2235 2236 2238 2239 2240 2241 2242 2244 2246 2247 2248 2249 2250 2254 2255 2256 2257 2258 2259 2260 2261 2262 2263 2264 2265 2266 2267 2268 2269 2271 2272 2273 2277 2278 2279 2281 2283 Appendix C. Revision History 2285 Note to RFC editor: please remove this entire appendix, and the 2286 corresponding entries in the table of contents, prior to publication. 2288 C.1 Changes from draft-ietf-xmpp-core-00 2290 o Added information about TLS from list discussion. 2292 o Clarified meaning of "ignore" based on list discussion. 2294 o Clarified information about Universal Character Set data and 2295 character encodings. 2297 o Provided base64-decoded information for examples. 2299 o Fixed several errors in the schemas. 2301 o Made numerous small editorial fixes. 2303 C.2 Changes from draft-miller-xmpp-core-02 2305 o Brought Streams Authentication section into line with discussion 2306 on list and at IETF 55 meeting. 2308 o Added information about the optional 'xml:lang' attribute per 2309 discussion on list and at IETF 55 meeting. 2311 o Specified that validation is neither required nor recommended, and 2312 that the formal definitions (DTDs and schemas) are included for 2313 descriptive purposes only. 2315 o Specified that the response to an IQ stanza of type 'get' or 'set' 2316 must be an IQ stanza of type 'result' or 'error'. 2318 o Specified that compliant server implementations must process 2319 stanzas in order. 2321 o Specified that for historical reasons some server implementations 2322 may accept 'stream:' as the only valid namespace prefix on the 2323 root stream element. 2325 o Clarified the difference between 'jabber:client' and 2326 'jabber:server' namespaces, namely, that 'to' and 'from' 2327 attributes are required on all stanzas in the latter but not the 2328 former. 2330 o Fixed typo in Step 9 of the dialback protocol (changed db:result 2331 to db:verify). 2333 o Removed references to TLS pending list discussion. 2335 o Removed the non-normative appendix on OpenPGP usage pending its 2336 inclusion in a separate I-D. 2338 o Simplified the architecture diagram, removed most references to 2339 services, and removed references to the 'jabber:component:*' 2340 namespaces. 2342 o Noted that XMPP activity respects firewall administration 2343 policies. 2345 o Further specified the scope and uniqueness of the 'id' attribute 2346 in all stanza types and the element in message stanzas. 2348 o Nomenclature changes: (1) from "chunks" to "stanzas"; (2) from 2349 "host" to "server" and from "node" to "client" (except with regard 2350 to definition of the addressing scheme). 2352 Full Copyright Statement 2354 Copyright (C) The Internet Society (2003). All Rights Reserved. 2356 This document and translations of it may be copied and furnished to 2357 others, and derivative works that comment on or otherwise explain it 2358 or assist in its implementation may be prepared, copied, published 2359 and distributed, in whole or in part, without restriction of any 2360 kind, provided that the above copyright notice and this paragraph are 2361 included on all such copies and derivative works. However, this 2362 document itself may not be modified in any way, such as by removing 2363 the copyright notice or references to the Internet Society or other 2364 Internet organizations, except as needed for the purpose of 2365 developing Internet standards in which case the procedures for 2366 copyrights defined in the Internet Standards process must be 2367 followed, or as required to translate it into languages other than 2368 English. 2370 The limited permissions granted above are perpetual and will not be 2371 revoked by the Internet Society or its successors or assigns. 2373 This document and the information contained herein is provided on an 2374 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 2375 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 2376 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 2377 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 2378 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2380 Acknowledgement 2382 Funding for the RFC Editor function is currently provided by the 2383 Internet Society.