idnits 2.17.1 draft-ietf-xmpp-core-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == 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 3341 has weird spacing: '... mailing list, for which archives and subscription 197 information are available at . 200 1.4 Intellectual Property Notice 202 This document is in full compliance with all provisions of Section 10 203 of RFC 2026. Parts of this specification use the term "jabber" for 204 identifying namespaces and other protocol syntax. Jabber[tm] is a 205 registered trademark of Jabber, Inc. Jabber, Inc. grants permission 206 to the IETF for use of the Jabber trademark in association with this 207 specification and its successors, if any. 209 2. Generalized Architecture 211 2.1 Overview 213 Although XMPP is not wedded to any specific network architecture, to 214 this point it usually has been implemented via a typical 215 client-server architecture, wherein a client utilizing XMPP accesses 216 a server over a TCP [4] socket. 218 The following diagram provides a high-level overview of this 219 architecture (where "-" represents communications that use XMPP and 220 "=" represents communications that use any other protocol). 222 C1 - S1 - S2 - C3 223 / \ 224 C2 - G1 = FN1 = FC1 226 The symbols are as follows: 228 o C1, C2, C3 -- XMPP clients 230 o S1, S2 -- XMPP servers 232 o G1 -- A gateway that translates between XMPP and the protocol(s) 233 used on a foreign (non-XMPP) messaging network 235 o FN1 -- A foreign messaging network 237 o FC1 -- A client on a foreign messaging network 239 2.2 Server 241 A server acts as an intelligent abstraction layer for XMPP 242 communications. Its primary responsibilities are to manage 243 connections from or sessions for other entities (in the form of XML 244 streams to and from authorized clients, servers, and other entities) 245 and to route appropriately-addressed XML data "stanzas" among such 246 entities over XML streams. Most XMPP-compliant servers also assume 247 responsibility for the storage of data that is used by clients (e.g., 248 contact lists for users of XMPP-based instant messaging 249 applications); in this case, the XML data is processed directly by 250 the server itself on behalf of the client and is not routed to 251 another entity. Compliant server implementations MUST ensure in-order 252 processing of XML stanzas between any two entities. 254 2.3 Client 255 Most clients connect directly to a server over a TCP socket and use 256 XMPP to take full advantage of the functionality provided by a server 257 and any associated services. Although there is no necessary coupling 258 of an XML stream to a TCP socket (e.g., a client COULD connect via 259 HTTP polling or some other mechanism), this specification defines a 260 binding for XMPP to TCP only. Multiple resources (e.g., devices or 261 locations) MAY connect simultaneously to a server on behalf of each 262 authorized client, with each resource connecting over a discrete TCP 263 socket and differentiated by the resource identifier of a JID (e.g., 264 vs. ) as defined under 265 Addressing Scheme (Section 3). The port registered with the IANA for 266 connections between a client and a server is 5222 (see IANA 267 Considerations (Section 10)). 269 2.4 Gateway 271 A gateway is a special-purpose server-side service whose primary 272 function is to translate XMPP into the protocol used by a foreign 273 (non-XMPP) messaging system, as well as to translate the return data 274 back into XMPP. Examples are gateways to Internet Relay Chat (IRC), 275 Short Message Service (SMS), SMTP, and legacy instant messaging 276 networks such as AIM, ICQ, MSN Messenger, and Yahoo! Instant 277 Messenger. Communications between gateways and servers, and between 278 gateways and the foreign messaging system, are not defined in this 279 document. 281 2.5 Network 283 Because each server is identified by a network address and because 284 server-to-server communications are a straightforward extension of 285 the client-to-server protocol, in practice the system consists of a 286 network of servers that inter-communicate. Thus user-a@domain1 is 287 able to exchange messages, presence, and other information with 288 user-b@domain2. This pattern is familiar from messaging protocols 289 (such as SMTP) that make use of network addressing standards. 290 Communications between any two servers are OPTIONAL; if enabled, such 291 communications occur over XML streams that are normally bound to TCP 292 sockets, using port 5269 as registered with the IANA (see IANA 293 Considerations (Section 10)). 295 3. Addressing Scheme 297 3.1 Overview 299 An entity is anything that can be considered a network endpoint 300 (i.e., an ID on the network) and that can communicate using XMPP. All 301 such entities are uniquely addressable in a form that is consistent 302 with RFC 2396 [24]. For historical reasons, the address of such an 303 entity is called a Jabber Identifier or JID. A valid JID contains a 304 set of ordered elements formed of a domain identifier, node 305 identifier, and resource identifier in the following format: 306 [node@]domain[/resource]. Each allowable portion of a JID (node 307 identifier, domain identifier, and resource identifier) may be up to 308 1023 bytes in length, resulting in a maximum total size (including 309 the '@' and '/' separators) of 3071 bytes. 311 All JIDs are based on the foregoing structure. The most common use of 312 this structure is to identify an instant messaging user, the server 313 to which the user connects, and the user's active session or 314 connection (e.g., a specific client) in the form of . However, node types other than clients are possible; for 316 example, a specific chat room offered by a multi-user chat service 317 could be addressed as (where "room" is the name of the 318 chat room and "service" is the hostname of the multi-user chat 319 service) and a specific occupant of such a room could be addressed as 320 (where "nick" is the occupant's room nickname). 321 Many other JID types are possible (e.g., could be a 322 server-side script or service). 324 3.2 Domain Identifier 326 The domain identifier is the primary identifier and is the only 327 REQUIRED element of a JID (a mere domain identifier is a valid JID). 328 It usually represents the network gateway or "primary" server to 329 which other entities connect for XML routing and data management 330 capabilities. However, the entity referenced by a domain identifier 331 is not always a server, and may be a service that is addressed as a 332 subdomain of a server and that provides functionality above and 333 beyond the capabilities of a server (e.g., a multi-user chat service, 334 a user directory, or a gateway to a foreign messaging system). 336 The domain identifier for every server or service that will 337 communicate over a network SHOULD resolve to a Fully Qualified Domain 338 Name. A domain identifier MUST conform to RFC 952 [6] and RFC 1123 339 [7]. In addition, a domain identifier MUST be no more than 1023 bytes 340 in length and MUST conform to the nameprep [8] profile of stringprep 341 [9]. 343 3.3 Node Identifier 345 The node identifier is an optional secondary identifier placed before 346 the domain identifier and separated from the latter by the '@' 347 character. It usually represents the entity requesting and using 348 network access provided by the server or gateway (i.e., a client), 349 although it can also represent other kinds of entities (e.g., a chat 350 room associated with a multi-user chat service). The entity 351 represented by a node identifier is addressed within the context of a 352 specific domain; within instant messaging applications of XMPP this 353 address is called a "bare JID" and is of the form . 355 A node identifier MUST be no more than 1023 bytes in length and MUST 356 conform to the nodeprep [10] profile of stringprep [9]. 358 3.4 Resource Identifier 360 The resource identifier is an optional tertiary identifier placed 361 after the domain identifier and separated from the latter by the '/' 362 character. A resource identifier may modify either a or 363 mere address. It usually represents a specific session, 364 connection (e.g., a device or location), or object (e.g., a 365 participant in a multi-user chat room) belonging to the entity 366 associated with a node identifier. A resource identifier is opaque to 367 both servers and other clients, and is typically defined by a client 368 implementation as the authzid value provided during stream 369 authentication. An entity may maintain multiple resources 370 simultaneously. 372 A resource identifier MUST be no more than 1023 bytes in length and 373 MUST conform to the resourceprep [11] profile of stringprep [9]. 375 4. XML Streams 377 4.1 Overview 379 Two fundamental concepts make possible the rapid, asynchronous 380 exchange of relatively small payloads of structured information 381 between presence-aware entities: XML streams and XML stanzas. These 382 terms may be defined as follows: 384 Definition of XML Stream: An XML stream is a container for the 385 exchange of XML elements between any two entities over a network. 386 An XML stream is negotiated from an initiating entity (usually a 387 client or server) to a receiving entity (usually a server), 388 normally over a TCP socket, and corresponds to the initiating 389 entity's "session" with the receiving entity. The start of the XML 390 stream is denoted unambiguously by an opening XML tag 391 with appropriate attributes and namespace declarations, and the 392 end of the XML stream is denoted unambiguously by a closing XML tag. An XML stream is unidirectional; in order to enable 394 bidirectional information exchange, the initiating entity and 395 receiving entity MUST negotiate one stream in each direction, 396 normally over the same TCP connection. 398 Definition of XML Stanza: An XML stanza is a discrete semantic unit 399 of structured information that is sent from one entity to another 400 over an XML stream. An XML stanza exists at the direct child level 401 of the root element and is said to be well-balanced if 402 it matches production [43] content of the XML specification [1]). 403 The start of any XML stanza is denoted unambiguously by the 404 element start tag at depth=1 of the XML stream (e.g., ), 405 and the end of any XML stanza is denoted unambiguously by the 406 corresponding close tag at depth=1 (e.g., ). An XML 407 stanza MAY contain child elements (with accompanying attributes, 408 elements, and CDATA) as necessary in order to convey the desired 409 information. An XML element sent for the purpose of stream 410 encryption, stream authentication, or server dialback is not 411 considered to be an XML stanza. 413 Consider the example of a client's session with a server. In order to 414 connect to a server, a client MUST initiate an XML stream by sending 415 an opening tag to the server, optionally preceded by a text 416 declaration specifying the XML version supported and the character 417 encoding (see also Character Encodings (Section 9.4)). The server 418 SHOULD then reply with a second XML stream back to the client, again 419 optionally preceded by a text declaration. Once the client has 420 authenticated with the server (see Section 6), the client MAY send an 421 unlimited number of XML stanzas over the stream to any recipient on 422 the network. When the client desires to close the stream, it simply 423 sends a closing tag to the server (alternatively, the 424 stream may be closed by the server), after which both the client and 425 server SHOULD close the underlying TCP connection as well. 427 Those who are accustomed to thinking of XML in a document-centric 428 manner may wish to view a client's session with a server as 429 consisting of two open-ended XML documents: one from the client to 430 the server and one from the server to the client. From this 431 perspective, the root element can be considered the 432 document entity for each "document", and the two "documents" are 433 built up through the accumulation of XML stanzas sent over the two 434 XML streams. However, this perspective is a convenience only, and 435 XMPP does not deal in documents but in XML streams and XML stanzas. 437 In essence, then, an XML stream acts as an envelope for all the XML 438 stanzas sent during a session. We can represent this graphically as 439 follows: 441 |--------------------| 442 | | 443 |--------------------| 444 | | 445 | | 446 | | 447 |--------------------| 448 | | 449 | | 450 | | 451 |--------------------| 452 | | 453 | | 454 | | 455 |--------------------| 456 | ... | 457 |--------------------| 458 | | 459 |--------------------| 461 4.2 Stream Attributes 463 The attributes of the stream element are as follows: 465 o to -- The 'to' attribute SHOULD be used only in the XML stream 466 header from the initiating entity to the receiving entity, and 467 MUST be set to the JID of the receiving entity. There SHOULD be no 468 'to' attribute set in the XML stream header by which the receiving 469 entity replies to the initiating entity; however, if a 'to' 470 attribute is included, it SHOULD be silently ignored by the 471 initiating entity. 473 o from -- The 'from' attribute SHOULD be used only in the XML stream 474 header from the receiving entity to the initiating entity, and 475 MUST be set to the JID of the receiving entity granting access to 476 the initiating entity. There SHOULD be no 'from' attribute on the 477 XML stream header sent from the initiating entity to the receiving 478 entity; however, if a 'from' attribute is included, it SHOULD be 479 silently ignored by the receiving entity. 481 o id -- The 'id' attribute SHOULD be used only in the XML stream 482 header from the receiving entity to the initiating entity. This 483 attribute is a unique identifier created by the receiving entity 484 to function as a session key for the initiating entity's streams 485 with the receiving entity, and MUST be unique within the receiving 486 application (normally a server). There SHOULD be no 'id' attribute 487 on the XML stream header sent from the initiating entity to the 488 receiving entity; however, if an 'id' attribute is included, it 489 SHOULD be silently ignored by the receiving entity. 491 o version -- The presence of the version attribute set to a value of 492 "1.0" indicates compliance with this specification. Detailed rules 493 regarding generation and handling of this attribute are defined 494 below. 496 We can summarize as follows: 498 | initiating to receiving | receiving to initiating 499 ------------------------------------------------------------ 500 to | hostname of receiver | silently ignored 501 from | silently ignored | hostname of receiver 502 id | silently ignored | session key 503 version | signals XMPP 1.0 support | signals XMPP 1.0 support 505 4.2.1 Version Support 507 The following rules apply to the generation and handling of the 508 'version' attribute: 510 1. If the initiating entity complies with the protocol defined 511 herein, it MUST include the 'version' attribute in the XML stream 512 header it sends to the receiving entity, and it MUST set the 513 value of the 'version' attribute to "1.0". 515 2. If the initiating entity includes the 'version' attribute set to 516 a value of "1.0" in its stream header and the receiving entity 517 supports XMPP 1.0, the receiving entity MUST reciprocate by 518 including the 'version' attribute set to a value of "1.0" in its 519 stream header response. 521 3. If the initiating entity does not include the 'version' attribute 522 in its stream header, the receiving entity still SHOULD include 523 the 'version' attribute set to a value of "1.0" in its stream 524 header response. 526 4. If the initiating entity includes the 'version' attribute set to 527 a value other than "1.0", the receiving entity SHOULD include the 528 'version' attribute set to a value of "1.0" in its stream header 529 response, but MAY at its discretion generate an 530 stream error and terminate the XML stream 531 and underlying TCP connection. 533 5. If the receiving entity includes the 'version' attribute set to a 534 value other than "1.0" in its stream header response, the 535 initiating entity SHOULD generate an 536 stream error and terminate the XML stream and underlying TCP 537 connection. 539 4.3 Namespace Declarations 541 The stream element MUST possess both a stream namespace declaration 542 and a default namespace declaration (as "namespace declaration" is 543 defined in the XML namespaces specification [12]). For detailed 544 information regarding the stream namespace and default namespace, see 545 Namespace Names and Prefixes (Section 9.2). 547 4.4 Stream Features 549 If the initiating entity includes the 'version' attribute set to a 550 value of "1.0" in its initiating stream element, the receiving entity 551 MUST send a child element (prefixed by the stream 552 namespace prefix) to the initiating entity in order to announce any 553 stream-level features that can be negotiated (or capabilities that 554 otherwise need to be advertised). Currently this is used for TLS and 555 SASL negotiation only, but it could be used for other negotiable 556 features in the future (usage is defined under Stream Encryption 557 (Section 5) and Stream Authentication (Section 6) below). If an 558 entity does not understand or support some features, it SHOULD 559 silently ignore them. 561 4.5 Stream Encryption and Authentication 563 XML streams in XMPP 1.0 SHOULD be encrypted as defined under Stream 564 Encryption (Section 5) and MUST be authenticated as defined under 565 Stream Authentication (Section 6). If the initiating entity attempts 566 to send an XML stanza before the stream is authenticated, the 567 receiving entity SHOULD return a stream error to 568 the initiating entity and then terminate both the XML stream and the 569 underlying TCP connection. 571 4.6 Stream Errors 573 The root stream element MAY contain an child element that is 574 prefixed by the stream namespace prefix. The error child MUST be sent 575 by a compliant entity (usually a server rather than a client) if it 576 perceives that a stream-level error has occurred. 578 4.6.1 Rules 580 The following rules apply to stream-level errors: 582 o It is assumed that all stream-level errors are unrecoverable; 583 therefore, if an error occurs at the level of the stream, the 584 entity that detects the error MUST send a stream error to the 585 other entity, send a closing tag, and terminate the 586 underlying TCP connection. 588 o If the error occurs while the stream is being set up, the 589 receiving entity MUST still send the opening tag, include 590 the element as a child of the stream element, send the 591 closing tag, and terminate the underlying TCP 592 connection. In this case, if the initiating entity provides an 593 unknown host in the 'to' attribute (or provides no 'to' attribute 594 at all), the server SHOULD provide the server's authoritative 595 hostname in the 'from' attribute of the stream header sent before 596 termination. 598 4.6.2 Syntax 600 The syntax for stream errors is as follows: 602 603 604 605 OPTIONAL descriptive text 606 607 [OPTIONAL application-specific condition element] 608 610 The element: 612 o MUST contain a child element corresponding to one of the defined 613 stanza error conditions defined below; this element MUST be 614 qualified by the 'urn:ietf:params:xml:ns:xmpp-streamstreams' 615 namespace 617 o MAY contain a child containing CDATA that describes the 618 error in more detail; this element MUST be qualified by the 619 'urn:ietf:params:xml:ns:xmpp-streams' namespace and SHOULD possess 620 an 'xml:lang' attribute 622 o MAY contain a child element for an application-specific error 623 condition; this element MUST be qualified by an 624 application-defined namespace, and its structure is defined by 625 that namespace 627 The element is OPTIONAL. If included, it SHOULD be used only 628 to provide descriptive or diagnostic information that supplements the 629 meaning of a defined condition or application-specific condition. It 630 SHOULD NOT be interpreted programmatically by an application. It 631 SHOULD NOT be used as the error message presented to user, but MAY be 632 shown in addition to the error message associated with the included 633 condition element (or elements). 635 Note: the XML namespace name 'urn:ietf:params:xml:ns:xmpp-streams' 636 that qualifies the descriptive element adheres to the format defined 637 in The IETF XML Registry [25]. 639 4.6.3 Defined Conditions 641 The following stream-level error conditions are defined: 643 o -- the value of the 'to' attribute provided by the 644 initiating entity in the stream header corresponds to a hostname 645 that is no longer hosted by the server. 647 o -- the value of the 'to' attribute provided by the 648 initiating entity in the stream header does not correspond to a 649 hostname that is hosted by the server. 651 o -- a stanza sent between two servers lacks 652 a 'to' or 'from' attribute (or the attribute has no value). 654 o -- the server has experienced a 655 misconfiguration or an otherwise-undefined internal error that 656 prevents it from servicing the stream. 658 o -- the stream ID or dialback ID is invalid or does 659 not match an ID previously provided. 661 o -- the stream namespace name is something 662 other than "http://etherx.jabber.org/streams" or the dialback 663 namespace name is something other than "jabber:server:dialback". 665 o -- the hostname provided in a 'from' address 666 does not match the hostname (or other validated domain) negotiated 667 via SASL or dialback. 669 o -- the entity has attempted to send data before 670 authenticating, or otherwise is not authorized to perform an 671 action related to stream negotiation; the receiving entity SHOULD 672 silently drop the offending stanza and MUST NOT process it before 673 sending the stream error. 675 o -- the server is unable to properly 676 connect to a remote resource that is required for authentication 677 or authorization. 679 o -- the server is resource-contrained and is 680 unable to service the stream. 682 o -- the server will not provide service to the 683 initiating entity but is redirecting traffic to another host; this 684 element SHOULD contain CDATA specifying the alternate hostname or 685 IP address to which the initiating entity MAY attempt to connect. 687 o -- the server is being shut down and all active 688 streams are being closed. 690 o -- the initiating entity has sent a 691 first-level child of the stream that is not supported by the 692 server. 694 o -- the value of the 'version' attribute 695 provided by the initiating entity in the stream header specifies a 696 version of XMPP that is not supported by the server; this element 697 MAY contain CDATA specifying the XMPP version(s) supported by the 698 server. 700 o -- the initiating entity has sent XML that 701 is not well-formed as defined by the XML specification [1]. 703 4.6.4 Application-Specific Conditions 705 As noted, an application MAY provide application-specific stream 706 error information by including a properly-namespaced child in the 707 error element. The application-specific element SHOULD supplement or 708 further qualify a defined element. Thus the element will 709 contain two or three child elements: 711 712 714 715 Some special application diagnostic information! 716 717 718 719 721 4.7 Simple Streams Example 723 The following is a stream-based session of a client on a server 724 (where the "C" lines are sent from the client to the server, and the 725 "S" lines are sent from the server to the client): 727 A basic session: 729 C: 730 735 S: 736 742 ... authentication ... 743 C: 746 C: Art thou not Romeo, and a Montague? 747 C: 748 S: 751 S: Neither, fair saint, if either thee dislike. 752 S: 753 C: 754 S: 755 A stream gone bad: 757 C: 758 763 S: 764 770 ... authentication ... 771 C: 772 Bad XML, no closing body tag! 773 774 S: 775 777 778 S: 780 5. Stream Encryption 782 5.1 Overview 784 XMPP includes a method for securing the stream from tampering and 785 eavesdropping. This channel encryption method makes use of the 786 Transport Layer Security (TLS) [13] protocol, along with a "STARTTLS" 787 extension that is modelled after similar extensions for the IMAP 788 [26], POP3 [27], and ACAP [28] protocols as described in RFC 2595 789 [29]. The namespace name for the STARTTLS extension is 790 'urn:ietf:params:xml:ns:xmpp-tls', which adheres to the format 791 defined in The IETF XML Registry [25]. 793 An administrator of a given domain MAY require the use of TLS for 794 client-to-server communications, server-to-server communications, or 795 both. Servers SHOULD use TLS betweeen two domains for the purpose of 796 securing server-to-server communications. See Mandatory to Implement 797 Technologies (Section 12.6) regarding mechanisms that MUST be 798 supported. 800 The following rules apply: 802 1. An initiating entity that complies with this specification MUST 803 include the 'version' attribute set to a value of "1.0" in the 804 initiating stream header. 806 2. If the TLS negotiation occurs between two servers, 807 communications MUST NOT proceed until the DNS hostnames asserted 808 by the servers have been resolved (see Server-to-Server 809 Communications (Section 12.3)). 811 3. When a receiving entity that complies with this specification 812 receives an initiating stream header that includes the 'version' 813 attribute set to a value of "1.0", after sending a stream header 814 in reply (including the version flag) it MUST include a 815 element (qualified by the 816 'urn:ietf:params:xml:ns:xmpp-tls' namespace) along with the list 817 of other stream features it supports. 819 4. If the initiating entity chooses to use TLS for stream 820 encryption, TLS negotiation MUST be completed before proceeding 821 to SASL negotiation. 823 5. The receiving entity MUST consider the TLS negotiation to have 824 begun immediately after sending the closing ">" of the element. The initiating entity MUST consider the TLS 826 negotiation to have begun immediately after receiving the 827 closing ">" of the element from the receiving entity. 829 6. The initiating entity MUST validate the certificate presented by 830 the receiving entity; there are two cases: 832 Case 1 -- The initiating entity has been configured with a set 833 of trusted root certificates: Normal certificate validation 834 processing is appropriate, and SHOULD follow the rules 835 defined for HTTP over TLS [14]. The trusted roots may be 836 either a well-known public set or a manually configured Root 837 CA (e.g., an organization's own Certificate Authority or a 838 self-signed Root CA for the service as described under High 839 Security (Section 12.1)). This case is RECOMMENDED. 841 Case 2 -- The initiating entity has been configured with the 842 receiving entity's self-signed service certificate: Simple 843 comparison of public keys is appropriate. This case is NOT 844 RECOMMENDED (see High Security (Section 12.1) for details). 846 If the above methods fail, the certificate SHOULD be presented 847 to a human (e.g., an end user or server administrator) for 848 approval; if presented, the receiver MUST deliver the entire 849 certificate chain to the human, who SHOULD be given the option 850 to store the Root CA certificate (not the service or End Entity 851 certificate) and to not be queried again regarding acceptance of 852 the certificate for some reasonable period of time. 854 7. If the TLS negotiation is successful, the receiving entity MUST 855 discard any knowledge obtained from the initiating entity before 856 TLS takes effect. 858 8. If the TLS negotiation is successful, the initiating entity MUST 859 discard any knowledge obtained from the receiving entity before 860 TLS takes effect. 862 9. If the TLS negotiation is successful, the receiving entity MUST 863 NOT offer the STARTTLS extension to the initiating entity along 864 with the other stream features that are offered when the stream 865 is restarted. 867 10. If the TLS negotiation is successful, the initiating entity 868 SHOULD continue with SASL negotiation. 870 11. If the TLS negotiation results in failure, the receiving entity 871 MUST terminate both the XML stream and the underlying TCP 872 connection. 874 5.2 Narrative 876 When an initiating entity secures a stream with a receiving entity, 877 the steps involved are as follows: 879 1. The initiating entity opens a TCP connection and initiates the 880 stream by sending the opening XML stream header to the receiving 881 entity, including the 'version' attribute set to a value of 882 "1.0". 884 2. The receiving entity responds by opening a TCP connection and 885 sending an XML stream header to the initiating entity, including 886 the 'version' attribute set to a value of "1.0". 888 3. The receiving entity offers the STARTTLS extension to the 889 initiating entity by including it with the list of other 890 supported stream features (if TLS is required for interaction 891 with the receiving entity, it SHOULD signal that fact by 892 including a element as a child of the 893 element). 895 4. The initiating entity issues the STARTTLS command (i.e., a 896 element qualified by the 897 'urn:ietf:params:xml:ns:xmpp-tls' namespace) to instruct the 898 receiving entity that it wishes to begin a TLS negotiation to 899 secure the stream. 901 5. The receiving entity MUST reply with either a element 902 or a element qualified by the 903 'urn:ietf:params:xml:ns:xmpp-tls' namespace. If the failure case 904 occurs, the receiving entity MUST terminate both the XML stream 905 and the underlying TCP connection. If the proceed case occurs, 906 the receiving entity MUST ignore any further XML data sent over 907 the XML stream but keep the underlying TCP connection open for 908 the purpose of completing the TLS negotiation. 910 6. The initiating entity and receiving entity attempt to complete a 911 TLS negotiation in accordance with RFC 2246 [13]. 913 7. If the TLS negotiation is unsuccessful, the receiving entity MUST 914 terminate the TCP connection. If the TLS negotiation is 915 successful, the initiating entity MUST initiate a new stream by 916 sending an opening XML stream header to the receiving entity. 918 8. Upon receiving the new stream header from the initiating entity, 919 the receiving entity MUST respond by sending a new XML stream 920 header to the initiating entity along with the remaining 921 available features (but NOT including the STARTTLS feature). 923 5.3 Client-to-Server Example 925 The following example shows the data flow for a client securing a 926 stream using STARTTLS (the IANA-registered port 5222 SHOULD be used; 927 see IANA Considerations (Section 10)). 929 Step 1: Client initiates stream to server: 931 937 Step 2: Server responds by sending a stream tag to client: 939 946 Step 3: Server sends the STARTTLS extension to client along with 947 authentication mechanisms and any other stream features: 949 950 951 952 953 954 DIGEST-MD5 955 PLAIN 956 957 959 Step 4: Client sends the STARTTLS command to server: 961 963 Step 5: Server informs client to proceed: 965 966 Step 5 (alt): Server informs client that TLS negotiation has failed 967 and closes both stream and TCP connection: 969 970 972 Step 6: Client and server attempt to complete TLS negotiation over 973 the existing TCP connection. 975 Step 7: If TLS negotiation is successful, client initiates a new 976 stream to server: 978 984 Step 7 (alt): If TLS negotiation is unsuccessful, server MUST close 985 TCP connection. 987 Step 8: Server responds by sending a stream header to client along 988 with any remaining negotiable stream features: 990 996 997 998 DIGEST-MD5 999 PLAIN 1000 EXTERNAL 1001 1002 1004 Step 9: Client SHOULD continue with Stream Authentication (Section 1005 6). 1007 5.4 Server-to-Server Example 1009 The following example shows the data flow for two servers securing a 1010 stream using STARTTLS (the IANA-registered port 5269 SHOULD be used; 1011 see IANA Considerations (Section 10)). 1013 Step 1: Server1 initiates stream to Server2: 1015 1021 Step 2: Server2 responds by sending a stream tag to Server1: 1023 1030 Step 3: Server2 sends the STARTTLS extension to Server1 along with 1031 authentication mechanisms and any other stream features: 1033 1034 1035 1036 1037 1038 DIGEST-MD5 1039 KERBEROS_V4 1040 1041 1043 Step 4: Server1 sends the STARTTLS command to Server2: 1045 1047 Step 5: Server2 informs Server1 to proceed: 1049 1051 Step 5 (alt): Server2 informs Server1 that TLS negotiation has failed 1052 and closes stream: 1054 1055 1057 Step 6: Server1 and Server2 attempt to complete TLS negotiation via 1058 TCP. 1060 Step 7: If TLS negotiation is successful, Server1 initiates a new 1061 stream to Server2: 1063 1069 Step 7 (alt): If TLS negotiation is unsuccessful, server MUST close 1070 TCP connection. 1072 Step 8: Server2 responds by sending a stream header to Server1 along 1073 with any remaining negotiable stream features: 1075 1081 1082 1083 DIGEST-MD5 1084 KERBEROS_V4 1085 EXTERNAL 1086 1087 1089 Step 9: Server1 SHOULD continue with Stream Authentication (Section 1090 6). 1092 6. Stream Authentication 1094 6.1 Overview 1096 XMPP includes a method for authenticating a stream using an XMPP 1097 adaptation of the Simple Authentication and Security Layer (SASL) 1098 [15]. SASL provides a generalized method for adding authentication 1099 support to connection-based protocols, and XMPP uses a generic XML 1100 namespace profile for SASL that conforms to section 4 ("Profiling 1101 Requirements") of RFC 2222 [15] (the XMPP-specific namespace name is 1102 'urn:ietf:params:xml:ns:xmpp-sasl', which adheres to the format 1103 defined in The IETF XML Registry [25]). Finally, see Mandatory to 1104 Implement Technologies (Section 12.6) regarding mechanisms that MUST 1105 be supported. 1107 The following rules apply: 1109 1. If the SASL negotiation occurs between two servers, 1110 communications MUST NOT proceed until the DNS hostnames asserted 1111 by the servers have been resolved (see Server-to-Server 1112 Communications (Section 12.3)). 1114 2. If TLS is used for stream encryption, SASL SHOULD NOT be used for 1115 anything except stream authentication (i.e., a security layer 1116 SHOULD NOT be negotiated using SASL). Conversely, if a security 1117 layer is to be negotiated via SASL, TLS SHOULD NOT be used. 1119 3. If the initiating entity is capable of authenticating via SASL, 1120 it MUST include the 'version' attribute set to a value of "1.0" 1121 in the initiating stream header. 1123 4. If the receiving entity is capable of negotiating authentication 1124 via SASL, it MUST send one or more authentication mechanisms 1125 within a element qualified by the 1126 'urn:ietf:params:xml:ns:xmpp-sasl' namespace in response to the 1127 opening stream tag received from the initiating entity (if the 1128 opening stream tag included the 'version' attribute set to a 1129 value of "1.0"). 1131 5. Upon successful SASL negotiation that involves negotiation of a 1132 security layer, the receiving entity MUST discard any knowledge 1133 obtained from the initiating entity which was not obtained from 1134 the SASL negotiation itself. 1136 6. Upon successful SASL negotiation that involves negotiation of a 1137 security layer, the initiating entity MUST discard any knowledge 1138 obtained from the receiving entity which was not obtained from 1139 the SASL negotiation itself. 1141 7. The initiating entity MUST provide an authzid during SASL 1142 negotiation. The authzid-value MUST be a valid JID of the form 1143 (i.e., a domain identifier only) for servers and of the 1144 form (i.e., node identifier, domain 1145 identifier, and resource identifier) for clients. The initiating 1146 entity MAY process the authzid-value in accordance with the rules 1147 defined in Addressing Scheme (Section 3) before providing it to 1148 the receiving entity, but is NOT REQUIRED to do so. 1150 8. Any character data contained within the XML elements used during 1151 SASL negotiation MUST be encoded using base64. 1153 6.2 Narrative 1155 When an initiating entity authenticates with a receiving entity, the 1156 steps involved are as follows: 1158 1. The initiating entity requests SASL authentication by including 1159 the 'version' attribute in the opening XML stream header sent to 1160 the receiving entity, with the value set to "1.0". 1162 2. After sending an XML stream header in response, the receiving 1163 entity sends a list of available SASL authentication mechanisms; 1164 each of these is a element included as a child 1165 within a container element qualified by the 1166 'urn:ietf:params:xml:ns:xmpp-sasl' namespace, which in turn is a 1167 child of a element in the streams namespace. If 1168 channel encryption needs to be established before a particular 1169 authentication mechanism may be used, the receiving entity MUST 1170 NOT provide that mechanism in the list of available SASL 1171 authentication methods prior to channel encryption. If the 1172 initiating entity presents a valid certificate during prior TLS 1173 negotiation, the receiving entity MAY offer the SASL EXTERNAL 1174 mechanism to the initiating entity during stream authentication 1175 (refer to RFC 2222 [15]). 1177 3. The initiating entity selects a mechanism by sending an 1178 element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' 1179 namespace to the receiving entity and including an appropriate 1180 value for the 'mechanism' attribute; this element MAY optionally 1181 contain character data (in SASL terminology the "initial 1182 response") if the mechanism supports or requires it. If the 1183 initiating entity selects the EXTERNAL mechanism for 1184 authentication, the authentication credentials shall be taken 1185 from the certificate presented during prior TLS negotiation. 1187 4. If necessary, the receiving entity challenges the initiating 1188 entity by sending a element qualified by the 1189 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating 1190 entity; this element MAY optionally contain character data (which 1191 MUST be computed in accordance with the SASL mechanism chosen by 1192 the initiating entity). 1194 5. The initiating entity responds to the challenge by sending a 1195 element qualified by the 1196 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the receiving 1197 entity; this element MAY optionally contain character data (which 1198 MUST be computed in accordance with the SASL mechanism chosen by 1199 the initiating entity). 1201 6. If necessary, the receiving entity sends more challenges and the 1202 initiating entity sends more responses. 1204 This series of challenge/response pairs continues until one of three 1205 things happens: 1207 1. The initiating entity aborts the handshake by sending an 1208 element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' 1209 namespace to the receiving entity. Upon receiving the 1210 element, the receiving entity MUST terminate the TCP connection. 1212 2. The receiving entity reports failure of the handshake by sending 1213 a element qualified by the 1214 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating 1215 entity (the particular cause of failure SHOULD be communicated in 1216 an appropriate child element of the element as defined 1217 under SASL Errors (Section 6.3)). Immediately after sending the 1218 element, the receiving entity MUST terminate the TCP 1219 connection. 1221 3. The receiving entity reports success of the handshake by sending 1222 a element qualified by the 1223 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating 1224 entity; this element MAY optionally contain character data (in 1225 SASL terminology "additional data with success"). Upon receiving 1226 the element, the initiating entity MUST initiate a new 1227 stream by sending an opening XML stream header to the receiving 1228 entity (it is not necessary to send a closing 1229 element first, since the receiving entity and initiating entity 1230 MUST consider the original stream to be closed upon sending or 1231 receiving the element). Upon receiving the new stream 1232 header from the initiating entity, the receiving entity MUST 1233 respond by sending a new XML stream header to the initiating 1234 entity, along with any remaining available features (but NOT 1235 including the STARTTLS feature or any authentication mechanisms) 1236 or an empty features element (to signify that no additional 1237 features are available); note that any such additional features 1238 are not defined herein, and MUST be defined by the relevant 1239 extension to XMPP. 1241 6.3 SASL Errors 1243 The following SASL-related error conditions are defined: 1245 o -- The data provided by the initiating entity does 1246 not adhere to the protocol for the requested mechanism; sent in 1247 response to the element. 1249 o -- The mechanism chosen by the initiating 1250 entity may be used only if the stream is already encrypted; sent 1251 in response to the element. 1253 o -- The authzid provided by the initiating 1254 entity is invalid, either because it is incorrectly formatted or 1255 because the initiating entity does not have permissions to 1256 authorize that ID; sent in response to a element. 1258 o -- The initiating entity did not provide a 1259 mechanism or requested a mechanism that is not supported by the 1260 receiving entity; sent in response to the element. 1262 o -- The realm provided by the initiating entity 1263 (in mechanisms that support the concept of a realm) does not match 1264 one of the hostnames served by the receiving entity; sent in 1265 response to a element. 1267 o -- The mechanism requested by the initiating 1268 entity is weaker than server policy permits for that initiating 1269 entity; sent in response to the element. 1271 o -- The authentication failed because the 1272 initiating entity did not provide valid credentials (this includes 1273 the case of an unknown username); sent in response to a element. 1276 o -- The authentication failed because of 1277 a temporary error condition within the receiving entity; sent in 1278 response to an element or element. 1280 6.4 SASL Definition 1282 Section 4 of the SASL specification [15] requires that the following 1283 information be supplied by a protocol definition: 1285 service name: "xmpp" 1287 initiation sequence: After the initiating entity provides an opening 1288 XML stream header and the receiving entity replies in kind, the 1289 receiving entity provides a list of acceptable authentication 1290 methods. The initiating entity chooses one method from the list 1291 and sends it to the receiving entity as the value of the 1292 'mechanism' attribute possessed by an element, optionally 1293 including an initial response to avoid a round trip. 1295 exchange sequence: Challenges and responses are carried through the 1296 exchange of elements from receiving entity to 1297 initiating entity and elements from initiating entity 1298 to receiving entity. The receiving entity reports failure by 1299 sending a element and success by sending a 1300 element; the initiating entity aborts the exchange by sending an 1301 element. (All of these elements are qualified by the 1302 'urn:ietf:params:xml:ns:xmpp-sasl' namespace.) Upon successful 1303 negotiation, both sides consider the original XML stream closed 1304 and new headers are sent by both entities. 1306 security layer negotiation: The security layer takes effect 1307 immediately after sending the closing ">" character of the 1308 element for the server, and immediately after receiving 1309 the closing ">" character of the element for the client 1310 (this element is qualified by the 1311 'urn:ietf:params:xml:ns:xmpp-sasl' namespace). 1313 use of the authorization identity: The authorization identity is used 1314 by xmpp to denote the "full JID" () of a 1315 client or the sending domain of a server. 1317 6.5 Client-to-Server Example 1319 The following example shows the data flow for a client authenticating 1320 with a server using SASL (the IANA-registered port 5222 SHOULD be 1321 used; see IANA Considerations (Section 10)). 1323 Step 1: Client initiates stream to server: 1325 1331 Step 2: Server responds with a stream tag sent to client: 1333 1340 Step 3: Server informs client of available authentication mechanisms: 1342 1343 1344 DIGEST-MD5 1345 PLAIN 1346 1347 1349 Step 4: Client selects an authentication mechanism: 1351 1355 Step 5: Server sends a base64-encoded challenge to client: 1357 1358 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 1359 xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz 1360 1362 The decoded challenge is: 1364 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ 1365 qop="auth",charset=utf-8,algorithm=md5-sess 1366 Step 5 (alt): Server returns error to client: 1368 1369 1370 1372 Step 6: Client responds to the challenge: 1374 1375 dXNlcm5hbWU9InJvYiIscmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik 1376 9BNk1HOXRFUUdtMmhoIixjbm9uY2U9Ik9BNk1IWGg2VnFUclJrIixuYz0w 1377 MDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJ4bXBwL2NhdGFjbHlzbS 1378 5jeCIscmVzcG9uc2U9ZDM4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZjIxNDNh 1379 ZjcsY2hhcnNldD11dGYtOCxhdXRoemlkPSJyb2JAY2F0YWNseXNtLmN4L2 1380 15UmVzb3VyY2Ui 1381 1383 The decoded response is: 1385 username="rob",realm="cataclysm.cx",\ 1386 nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\ 1387 nc=00000001,qop=auth,digest-uri="xmpp/cataclysm.cx",\ 1388 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8,\ 1389 authzid="rob@cataclysm.cx/myResource" 1391 Step 7: Server sends another challenge to client: 1393 1394 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 1395 1397 The decoded challenge is: 1399 rspauth=ea40f60335c427b5527b84dbabcdfffd 1401 Step 7 (alt): Server returns error to client: 1403 1404 1405 1407 Step 8: Client responds to the challenge: 1409 1410 Step 9: Server informs client of successful authentication: 1412 1414 Step 9 (alt): Server informs client of failed authentication: 1416 1417 1418 1420 Step 10: Client initiates a new stream to server: 1422 1428 Step 11: Server responds by sending a stream header to client along 1429 with any additional features (or an empty features element): 1431 1437 1439 6.6 Server-to-Server Example 1441 The following example shows the data flow for a server authenticating 1442 with another server using SASL (the IANA-registered port 5269 SHOULD 1443 be used; see IANA Considerations (Section 10)). 1445 Step 1: Server1 initiates stream to Server2: 1447 1453 Step 2: Server2 responds with a stream tag sent to Server1: 1455 1462 Step 3: Server2 informs Server1 of available authentication 1463 mechanisms: 1465 1466 1467 DIGEST-MD5 1468 KERBEROS_V4 1469 1470 1472 Step 4: Server1 selects an authentication mechanism: 1474 1478 Step 5: Server2 sends a base64-encoded challenge to Server1: 1480 1481 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 1482 xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz 1483 1485 The decoded challenge is: 1487 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ 1488 qop="auth",charset=utf-8,algorithm=md5-sess 1490 Step 5 (alt): Server2 returns error to Server1: 1492 1493 1494 1495 Step 6: Server1 responds to the challenge: 1497 1498 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 1499 xjbm9uY2U9Ik9BNk1IWGg2VnFUclJrIixuYz0wMDAwMDAwMSxxb3A9YXV0 1500 aCxkaWdlc3QtdXJpPSJ4bXBwL2NhdGFjbHlzbS5jeCIscmVzcG9uc2U9ZD 1501 M4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcsY2hhcnNldD11dGYt 1502 OAo= 1503 1505 The decoded response is: 1507 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\ 1508 nc=00000001,qop=auth,digest-uri="xmpp/cataclysm.cx",\ 1509 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8 1511 Step 7: Server2 sends another challenge to Server1: 1513 1514 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 1515 1517 The decoded challenge is: 1519 rspauth=ea40f60335c427b5527b84dbabcdfffd 1521 Step 5 (alt): Server2 returns error to Server1: 1523 1524 1525 1527 Step 8: Server1 responds to the challenge: 1529 1531 Step 9: Server2 informs Server1 of successful authentication: 1533 1535 Step 9 (alt): Server2 informs Server1 of failed authentication: 1537 1538 1539 1540 Step 10: Server1 initiates a new stream to Server2: 1542 1548 Step 11: Server2 responds by sending a stream header to Server1 along 1549 with any additional features (or an empty features element): 1551 1557 1559 7. Server Dialback 1561 7.1 Overview 1563 The Jabber protocol from which XMPP was adapted includes a "server 1564 dialback" method for protecting against domain spoofing, thus making 1565 it more difficult to spoof XML stanzas (see Server-to-Server 1566 Communications (Section 12.3) regarding this method's security 1567 characteristics). Server dialback also makes it easier to deploy 1568 systems in which outbound messages and inbound messages are handled 1569 by different machines for the same domain. The server dialback method 1570 is made possible by the existence of DNS, since one server can 1571 (normally) discover the authoritative server for a given domain. 1573 Because dialback depends on the Domain Name System, inter-domain 1574 communications MUST NOT proceed until the DNS hostnames asserted by 1575 the servers have been resolved (see Server-to-Server Communications 1576 (Section 12.3)). 1578 The method for generating and verifying the keys used in server 1579 dialback MUST take into account the hostnames being used, the random 1580 ID generated for the stream, and a secret known by the authoritative 1581 server's network. 1583 Any error that occurs during dialback negotiation MUST be considered 1584 a stream error, resulting in termination of the stream and of the 1585 underlying TCP connection. The possible error conditions are 1586 specified in the protocol description below. 1588 The following terminology applies: 1590 o Originating Server -- the server that is attempting to establish a 1591 connection between two domains. 1593 o Receiving Server -- the server that is trying to authenticate that 1594 Originating Server represents the domain which it claims to be. 1596 o Authoritative Server -- the server that answers to the DNS 1597 hostname asserted by Originating Server; for basic environments 1598 this will be Originating Server, but it could be a separate 1599 machine in Originating Server's network. 1601 The following is a brief summary of the order of events in dialback: 1603 1. Originating Server establishes a connection to Receiving Server. 1605 2. Originating Server sends a 'key' value over the connection to 1606 Receiving Server. 1608 3. Receiving Server establishes a connection to Authoritative 1609 Server. 1611 4. Receiving Server sends the same 'key' value to Authoritative 1612 Server. 1614 5. Authoritative Server replies that key is valid or invalid. 1616 6. Receiving Server informs Originating Server whether it is 1617 authenticated or not. 1619 We can represent this flow of events graphically as follows: 1621 Originating Receiving 1622 Server Server 1623 ----------- --------- 1624 | | 1625 | establish connection | 1626 | ----------------------> | 1627 | | 1628 | send stream header | 1629 | ----------------------> | 1630 | | 1631 | send stream header | 1632 | <---------------------- | 1633 | | Authoritative 1634 | send dialback key | Server 1635 | ----------------------> | ------------- 1636 | | | 1637 | establish connection | 1638 | ----------------------> | 1639 | | 1640 | send stream header | 1641 | ----------------------> | 1642 | | 1643 | establish connection | 1644 | <---------------------- | 1645 | | 1646 | send stream header | 1647 | <---------------------- | 1648 | | 1649 | send dialback key | 1650 | ----------------------> | 1651 | | 1652 | validate dialback key | 1653 | <---------------------- | 1654 | 1655 | report dialback result | 1656 | <---------------------- | 1657 | | 1659 7.2 Protocol 1661 The interaction between the servers is as follows: 1663 1. Originating Server establishes TCP connection to Receiving 1664 Server. 1666 2. Originating Server sends a stream header to Receiving Server: 1668 1673 Note: the 'to' and 'from' attributes are NOT REQUIRED on the 1674 root stream element. The inclusion of the xmlns:db namespace 1675 declaration with the name shown indicates to Receiving Server 1676 that Originating Server supports dialback. If the namespace name 1677 is incorrect, then Receiving Server MUST generate an 1678 stream error condition and terminate both 1679 the XML stream and the underlying TCP connection. 1681 3. Receiving Server SHOULD send a stream header back to Originating 1682 Server, including a unique ID for this interaction: 1684 1690 Note: The 'to' and 'from' attributes are NOT REQUIRED on the 1691 root stream element. If the namespace name is incorrect, then 1692 Originating Server MUST generate an stream 1693 error condition and terminate both the XML stream and the 1694 underlying TCP connection. Note well that Receiving Server is 1695 NOT REQUIRED to reply and MAY silently terminate the XML stream 1696 and underlying TCP connection depending on security policies in 1697 place. 1699 4. Originating Server sends a dialback key to Receiving Server: 1701 1704 98AF014EDC0... 1705 1707 Note: this key is not examined by Receiving Server, since 1708 Receiving Server does not keep information about Originating 1709 Server between sessions. The key generated by Originating Server 1710 MUST be based in part on the value of the ID provided by 1711 Receiving Server in the previous step, and in part on a secret 1712 shared by Originating Server and Authoritative Server. If the 1713 value of the 'to' address does not match a hostname recognized 1714 by Receiving Server, then Receiving Server MUST generate a 1715 stream error condition and terminate both the 1716 XML stream and the underlying TCP connection. If the value of 1717 the 'from' address matches a domain with which Receiving Server 1718 already has an established connection, then Receiving Server 1719 MUST maintain the existing connection until it validates whether 1720 the new connection is legitimate; additionally, Receiving Server 1721 MAY choose to generate a stream error 1722 condition for the new connection and then terminate both the XML 1723 stream and the underlying TCP connection related to the new 1724 request. 1726 5. Receiving Server establishes a TCP connection back to the domain 1727 name asserted by Originating Server, as a result of which it 1728 connects to Authoritative Server. (Note: as an optimization, an 1729 implementation MAY reuse an existing trusted connection here 1730 rather than opening a new TCP connection.) 1732 6. Receiving Server sends Authoritative Server a stream header: 1734 1739 Note: the 'to' and 'from' attributes are NOT REQUIRED on the 1740 root stream element. If the namespace name is incorrect, then 1741 Authoritative Server MUST generate an 1742 stream error condition and terminate both the XML stream and the 1743 underlying TCP connection. 1745 7. Authoritative Server sends Receiving Server a stream header: 1747 1753 Note: if the namespace name is incorrect, then Receiving Server 1754 MUST generate an stream error condition and 1755 terminate both the XML stream and the underlying TCP connection 1756 between it and Authoritative Server. If the ID does not match 1757 that provided by Receiving Server in Step 3, then Receiving 1758 Server MUST generate an stream error condition and 1759 terminate both the XML stream and the underlying TCP connection 1760 between it and Authoritative Server. If either of the foregoing 1761 stream errors occurs between Receiving Server and Authoritative 1762 Server, then Receiving Server MUST generate a 1763 stream error condition and terminate 1764 both the XML stream and the underlying TCP connection between it 1765 and Originating Server. 1767 8. Receiving Server sends Authoritative Server a stanza requesting 1768 that Authoritative Server verify a key: 1770 1774 98AF014EDC0... 1775 1777 Note: passed here are the hostnames, the original identifier 1778 from Receiving Server's stream header to Originating Server in 1779 Step 3, and the key that Originating Server sent to Receiving 1780 Server in Step 4. Based on this information as well as shared 1781 secret information within the Authoritative Server's network, 1782 the key is verified. Any verifiable method MAY be used to 1783 generate the key. If the value of the 'to' address does not 1784 match a hostname recognized by Authoritative Server, then 1785 Authoritative Server MUST generate a stream 1786 error condition and terminate both the XML stream and the 1787 underlying TCP connection. If the value of the 'from' address 1788 does not match the hostname represented by Receiving Server when 1789 opening the TCP connection (or any validated domain), then 1790 Authoritative Server MUST generate a stream 1791 error condition and terminate both the XML stream and the 1792 underlying TCP connection. 1794 9. Authoritative Server sends a stanza back to Receiving Server 1795 verifying whether the key was valid or invalid: 1797 1803 or 1805 1811 Note: if the ID does not match that provided by Receiving Server 1812 in Step 3, then Receiving Server MUST generate an 1813 stream error condition and terminate both the XML stream and the 1814 underlying TCP connection. If the value of the 'to' address does 1815 not match a hostname recognized by Receiving Server, then 1816 Receiving Server MUST generate a stream error 1817 condition and terminate both the XML stream and the underlying 1818 TCP connection. If the value of the 'from' address does not 1819 match the hostname represented by Originating Server when 1820 opening the TCP connection (or any validated domain), then 1821 Receiving Server MUST generate a stream 1822 error condition and terminate both the XML stream and the 1823 underlying TCP connection. 1825 10. Receiving Server informs Originating Server of the result: 1827 1832 Note: At this point the connection has either been validated via 1833 a type='valid', or reported as invalid. If the connection is 1834 invalid, then Receiving Server MUST terminate both the XML 1835 stream and the underlying TCP connection. If the connection is 1836 validated, data can be sent by Originating Server and read by 1837 Receiving Server; before that, all data stanzas sent to 1838 Receiving Server SHOULD be silently dropped. 1840 Even if dialback negotiation is successful, a server MUST verify that 1841 all XML stanzas received from the other server include a 'from' 1842 attribute and a 'to' attribute; if a stanza does not meet this 1843 restriction, the server that receives the stanza MUST generate an 1844 stream error condition and terminate both the 1845 XML stream and the underlying TCP connection. Furthermore, a server 1846 MUST verify that the 'from' attribute of stanzas received from the 1847 other server includes a validated domain for the stream; if a stanza 1848 does not meet this restriction, the server that receives the stanza 1849 MUST generate a stream error condition and 1850 terminate both the XML stream and the underlying TCP connection. Both 1851 of these checks help to prevent spoofing related to particular 1852 stanzas. 1854 8. XML Stanzas 1856 8.1 Overview 1858 Once XML streams in both directions have been authenticated and (if 1859 desired) encrypted, XML stanzas can be sent over the streams. Three 1860 XML stanza types are defined for the 'jabber:client' and 1861 'jabber:server' namespaces: , , and . 1863 In essence, the stanza type can be seen as a "push" 1864 mechanism whereby one entity pushes information to another entity, 1865 similar to the communications that occur in a system such as email. 1866 The element can be seen as a basic broadcast or 1867 "publish-subscribe" mechanism, whereby multiple entities receive 1868 information (in this case, presence information) about an entity to 1869 which they have subscribed. The element can be seen as a 1870 "request-response" mechanism similar to HTTP, whereby two entities 1871 can engage in a structured conversation using 'get' or 'set' requests 1872 and 'result' or 'error' responses. 1874 8.2 Common Attributes 1876 The following five attributes are common to message, presence, and IQ 1877 stanzas: 1879 8.2.1 to 1881 The 'to' attribute specifies the JID of the intended recipient for 1882 the stanza. 1884 In the 'jabber:client' namespace, a stanza SHOULD possess a 'to' 1885 attribute, although a stanza sent from a client to a server for 1886 handling by that server (e.g., presence sent to the server for 1887 broadcasting to other entities) SHOULD NOT possess a 'to' attribute. 1889 In the 'jabber:server' namespace, a stanza MUST possess a 'to' 1890 attribute; if a server receives a stanza that does not meet this 1891 restriction, it MUST generate an stream error 1892 condition and terminate both the XML stream and the underlying TCP 1893 connection with the offending server. 1895 If the value of the 'to' attribute is invalid or cannot be contacted, 1896 the entity discovering that fact (usually the sender's or recipient's 1897 server) MUST return an appropriate error to the sender. 1899 8.2.2 from 1901 The 'from' attribute specifies the JID of the sender. 1903 In the 'jabber:client' namespace, a client MUST NOT include a 'from' 1904 attribute on the stanzas it sends to a server; if a server receives 1905 an XML stanza from a client and the stanza possesses a 'from' 1906 attribute, it MUST ignore the value of the 'from' attribute and MAY 1907 return an error to the sender. When a client sends an XML stanza 1908 within the context of an authenticated stream, the server MUST stamp 1909 the stanza with the full JID () of the 1910 connected resource that generated the stanza as defined by the 1911 authzid provided in the SASL negotiation. If a client attempts to 1912 send an XML stanza before the stream is authenticated, the server 1913 SHOULD return a stream error to the client and then 1914 terminate both the XML stream and the underlying TCP connection. 1916 In the 'jabber:server' namespace, a stanza MUST possess a 'from' 1917 attribute; if a server receives a stanza that does not meet this 1918 restriction, it MUST generate an stream error 1919 condition. Furthermore, the domain identifier portion of the JID 1920 contained in the 'from' attribute MUST match the hostname of the 1921 sending server (or any validated domain) as communicated in the SASL 1922 negotiation or dialback negotiation; if a server receives a stanza 1923 that does not meet this restriction, it MUST generate a 1924 stream error condition. Both of these conditions 1925 MUST result in closing of the stream and termination of the 1926 underlying TCP connection. 1928 8.2.3 id 1930 The optional 'id' attribute MAY be used by a sending entity for 1931 internal tracking of stanzas that it sends and receives (especially 1932 for tracking the request-response interaction inherent in the use of 1933 IQ stanzas). If the stanza sent by the sending entity is an IQ stanza 1934 of type "get" or "set", the receiving entity MUST include an 'id' 1935 attribute with the same value in any replies of type "result" or 1936 "error". The value of the 'id' attribute is NOT REQUIRED to be unique 1937 either globally, within a domain, or within a stream. 1939 8.2.4 type 1941 The 'type' attribute specifies detailed information about the purpose 1942 or context of the message, presence, or IQ stanza. The particular 1943 allowable values for the 'type' attribute vary depending on whether 1944 the stanza is a message, presence, or IQ, and thus are defined in the 1945 following sections. 1947 8.2.5 xml:lang 1949 A stanza SHOULD possess an 'xml:lang' attribute (as defined in 1950 Section 2.12 of the XML specification [1]) if the stanza contains XML 1951 character data that is intended to be presented to a human user (as 1952 explained in RFC 2277 [31], "internationalization is for humans"). 1953 The value of the 'xml:lang' attribute specifies the default language 1954 of any such XML character data, which MAY be overridden by the 1955 'xml:lang' attribute of a specific child element. The value of the 1956 attribute MUST be an NMTOKEN and MUST conform to the format defined 1957 in RFC 3066 [17]. 1959 8.3 Message Stanzas 1961 Message stanzas in the 'jabber:client' or 'jabber:server' namespace 1962 are used to "push" information to another entity. Common uses in the 1963 context of instant messaging include single messages, messages sent 1964 in the context of a chat conversation, messages sent in the context 1965 of a multi-user chat room, headlines, and errors. 1967 8.3.1 Types of Message 1969 The 'type' attribute of a message stanza is RECOMMENDED; if included, 1970 it specifies the conversational context of the message. The 'type' 1971 attribute SHOULD have one of the following values: 1973 o chat 1975 o error 1977 o groupchat 1979 o headline 1981 o normal 1983 A message stanza with a different value, or without a 'type' 1984 attribute, SHOULD be handled as if the 'type' were "normal". 1986 For information regarding the meaning of these message types in the 1987 context of XMPP-based instant messaging and presence applications, 1988 refer to XMPP IM [23]. 1990 8.3.2 Children 1992 As described under extended namespaces (Section 8.6), a message 1993 stanza MAY contain any properly-namespaced child element. 1995 In accordance with the default namespace declaration, by default a 1996 message stanza is in the 'jabber:client' or 'jabber:server' 1997 namespace, which defines certain allowable children of message 1998 stanzas. If the message stanza is of type "error", it MUST include an 1999 child; for details, see Stanza Errors (Section 8.7). 2000 Otherwise, the message stanza MAY contain any of the following child 2001 elements without an explicit namespace declaration: 2003 1. 2005 2. 2007 3. 2009 8.3.2.1 Subject 2011 The element specifies the topic of the message. The 2012 element SHOULD NOT possess any attributes, with the 2013 exception of the 'xml:lang' attribute. Multiple instances of the 2014 element MAY be included for the purpose of providing 2015 alternate versions of the same subject, but only if each instance 2016 possesses an 'xml:lang' attribute with a distinct language value. The 2017 element MUST NOT contain mixed content. 2019 8.3.2.2 Body 2021 The element contains the textual contents of the message; 2022 this child element is normally included but NOT REQUIRED. The 2023 element SHOULD NOT possess any attributes, with the exception of the 2024 'xml:lang' attribute. Multiple instances of the element MAY 2025 be included but only if each instance possesses an 'xml:lang' 2026 attribute with a distinct language value. The element MUST 2027 NOT contain mixed content. 2029 8.3.2.3 Thread 2031 The element contains a string that is generated by the 2032 sender and that SHOULD be copied back in replies; it is used for 2033 tracking a conversation thread (sometimes referred to as an "instant 2034 messaging session") between two entities. If used, it MUST be unique 2035 to that conversation thread within the stream and MUST be consistent 2036 throughout that conversation (a client that receives a message from 2037 the same full JID but with a different thread ID MUST assume that the 2038 message in question exists outside the context of the existing 2039 conversation thread). The use of the element is OPTIONAL 2040 and is not used to identify individual messages, only conversations. 2041 Only one element MAY be included in a message stanza, and 2042 it MUST NOT possess any attributes. The element MUST be 2043 treated as an opaque string by entities; no semantic meaning may be 2044 derived from it, and only exact comparisons may be made against it. 2045 The element MUST NOT contain mixed content. 2047 8.4 Presence Stanzas 2049 Presence stanzas are used in the 'jabber:client' or 'jabber:server' 2050 namespace to express an entity's current availability status (offline 2051 or online, along with various sub-states of the latter and optional 2052 user-defined descriptive text) and to communicate that status to 2053 other entities. Presence stanzas are also used to negotiate and 2054 manage subscriptions to the presence of other entities. 2056 8.4.1 Types of Presence 2058 The 'type' attribute of a presence stanza is OPTIONAL. A presence 2059 stanza that does not possess a 'type' attribute is used to signal to 2060 the server that the sender is online and available for communication. 2061 If included, the 'type' attribute specifies a lack of availability, a 2062 request to manage a subscription to another entity's presence, a 2063 request for another entity's current presence, or an error related to 2064 a previously-sent presence stanza. The 'type' attribute MAY have one 2065 of the following values: 2067 o unavailable -- Signals that the entity is no longer available for 2068 communication. 2070 o subscribe -- The sender wishes to subscribe to the recipient's 2071 presence. 2073 o subscribed -- The sender has allowed the recipient to receive 2074 their presence. 2076 o unsubscribe -- A notification that an entity is unsubscribing from 2077 another entity's presence. 2079 o unsubscribed -- The subscription request has been denied or a 2080 previously-granted subscription has been cancelled. 2082 o probe -- A request for an entity's current presence; in general, 2083 SHOULD NOT be sent by a client. 2085 o error -- An error has occurred regarding processing or delivery of 2086 a previously-sent presence stanza. 2088 For information regarding presence semantics and the subscription 2089 model used in the context of XMPP-based instant messaging and 2090 presence applications, refer to XMPP IM [23]. 2092 8.4.2 Children 2094 As described under extended namespaces (Section 8.6), a presence 2095 stanza MAY contain any properly-namespaced child element. 2097 In accordance with the default namespace declaration, by default a 2098 presence stanza is in the 'jabber:client' or 'jabber:server' 2099 namespace, which defines certain allowable children of presence 2100 stanzas. If the presence stanza is of type "error", it MUST include 2101 an child; for details, see Stanza Errors (Section 8.7). If 2102 the presence stanza possesses no 'type' attribute, it MAY contain any 2103 of the following child elements (note that the child MAY be 2104 sent in a presence stanza of type "unavailable" or, for historical 2105 reasons, "subscribe"): 2107 1. 2109 2. 2111 3. 2113 8.4.2.1 Show 2115 The OPTIONAL element specifies the particular availability 2116 status of an entity or specific resource (if a element is not 2117 provided, default availability is assumed). Only one element 2118 MAY be included in a presence stanza, and it SHOULD NOT possess any 2119 attributes. The CDATA value SHOULD be one of the following (values 2120 other than these four SHOULD be ignored; additional availability 2121 types could be defined through a properly-namespaced child element of 2122 the presence stanza): 2124 o away 2126 o chat 2128 o dnd 2130 o xa 2132 For information regarding the meaning of these values in the context 2133 of XMPP-based instant messaging and presence applications, refer to 2134 XMPP IM [23]. 2136 8.4.2.2 Status 2138 The OPTIONAL element contains a natural-language 2139 description of availability status. It is normally used in 2140 conjunction with the show element to provide a detailed description 2141 of an availability state (e.g., "In a meeting"). The 2142 element SHOULD NOT possess any attributes, with the exception of the 2143 'xml:lang' attribute. Multiple instances of the element MAY 2144 be included but only if each instance possesses an 'xml:lang' 2145 attribute with a distinct language value. 2147 8.4.2.3 Priority 2149 The OPTIONAL element specifies the priority level of the 2150 connected resource. The value may be any integer between -128 and 2151 +127. Only one element MAY be included in a presence 2152 stanza, and it MUST NOT possess any attributes. If no priority is 2153 provided, a server SHOULD consider the priority to be zero. For 2154 information regarding the semantics of priority values in stanza 2155 routing within instant messaging applications, refer to XMPP IM [23]. 2157 8.5 IQ Stanzas 2159 8.5.1 Overview 2161 Info/Query, or IQ, is a request-response mechanism, similar in some 2162 ways to HTTP [32]. IQ stanzas in the 'jabber:client' or 2163 'jabber:server' namespace enable an entity to make a request of, and 2164 receive a response from, another entity. The data content of the 2165 request and response is defined by the namespace declaration of a 2166 direct child element of the IQ element, and the interaction is 2167 tracked by the requesting entity through use of the 'id' attribute. 2169 Most IQ interactions follow a common pattern of structured data 2170 exchange such as get/result or set/result (although an error may be 2171 returned in response to a request if appropriate): 2173 Requesting Responding 2174 Entity Entity 2175 ---------- ---------- 2176 | | 2177 | | 2178 | ------------------------> | 2179 | | 2180 | | 2181 | <------------------------ | 2182 | | 2183 | | 2184 | ------------------------> | 2185 | | 2186 | | 2187 | <------------------------ | 2188 | | 2190 An entity that receives an IQ request of type "get" or "set" MUST 2191 reply with an IQ response of type "result" or "error" (which response 2192 MUST preserve the 'id' attribute of the request, if provided). An 2193 entity that receives a stanza of type "result" or "error" MUST NOT 2194 respond to the stanza by sending a further IQ response of type 2195 "result" or "error"; however, as shown above, the requesting entity 2196 MAY send another request (e.g., an IQ of type "set" in order to 2197 provide required information discovered through a get/result pair). 2199 8.5.2 Types of IQ 2201 The 'type' attribute of an IQ stanza is REQUIRED. The 'type' 2202 attribute specifies a distinct step within a request-response 2203 interaction. The value SHOULD be one of the following (all other 2204 values SHOULD be ignored): 2206 o get -- The stanza is a request for information or requirements. 2208 o set -- The stanza provides required data, sets new values, or 2209 replaces existing values. 2211 o result -- The stanza is a response to a successful get or set 2212 request. 2214 o error -- An error has occurred regarding processing or delivery of 2215 a previously-sent get or set. 2217 8.5.3 Children 2219 As described under extended namespaces (Section 8.6), an IQ stanza 2220 MAY contain any properly-namespaced child element. Note that an IQ 2221 stanza of type "get", "set", or "result" contains no children in the 2222 'jabber:client' or 'jabber:server' namespace since it is a vessel for 2223 XML in another namespace. 2225 An IQ stanza of type "get" or "set" MUST include one and only one 2226 child element. An IQ stanza of type "result" MUST include zero or one 2227 child elements. An IQ stanza of type "error" SHOULD include the child 2228 element contained in the associated "get" or "set" and MUST include 2229 an child; for details, see Stanza Errors (Section 8.7). 2231 8.6 Extended Namespaces 2233 While the three XML stanza types defined in the "jabber:client" or 2234 "jabber:server" namespace (along with their attributes and child 2235 elements) provide a basic level of functionality for messaging and 2236 presence, XMPP uses XML namespaces to extend the stanzas for the 2237 purpose of providing additional functionality. Thus a message, 2238 presence, or IQ stanza MAY house one or more optional child elements 2239 containing content that extends the meaning of the message (e.g., an 2240 XHTML-formatted version of the message body). This child element MAY 2241 have any name and MUST possess an 'xmlns' namespace declaration 2242 (other than "jabber:client", "jabber:server", or "http:// 2243 etherx.jabber.org/streams") that defines all data contained within 2244 the child element. 2246 Support for any given extended namespace is OPTIONAL on the part of 2247 any implementation. If an entity does not understand such a 2248 namespace, the entity's expected behavior depends on whether the 2249 entity is (1) the recipient or (2) an entity that is routing the 2250 stanza to the recipient: 2252 Recipient: If a recipient receives a stanza that contains a child 2253 element it does not understand, it SHOULD ignore that specific XML 2254 data, i.e., it SHOULD not process it or present it to a user or 2255 associated application (if any). In particular: 2257 * If an entity receives a message or presence stanza that 2258 contains XML data qualified by a namespace it does not 2259 understand, the portion of the stanza that is in the unknown 2260 namespace SHOULD be ignored. 2262 * If an entity receives a message stanza containing only a child 2263 element qualified by a namespace it does not understand, it 2264 MUST ignore the entire stanza. 2266 * If an entity receives an IQ stanza of type "get" or "set" 2267 containing a child element qualified by a namespace it does not 2268 understand, the entity SHOULD return an IQ stanza of type 2269 "error" with an error condition of . 2271 Router: If a routing entity (usually a server) handles a stanza that 2272 contains a child element it does not understand, it SHOULD ignore 2273 the associated XML data by passing it on untouched to the 2274 recipient. 2276 8.7 Stanza Errors 2278 Stanza-related errors are handled in a manner similar to stream 2279 errors (Section 4.6), except that hints are also provided to the 2280 receiving application regarding actions to take in reponse to the 2281 error. 2283 8.7.1 Rules 2285 The following rules apply to stanza-related errors: 2287 o A stanza whose 'type' attribute has a value of "error" MUST 2288 contain an child element. 2290 o The receiving or processing entity that returns an error to the 2291 sending entity SHOULD include the original XML sent so that the 2292 sender can inspect and if necessary correct the XML before 2293 re-sending. 2295 o An entity that receives a stanza whose 'type' attribute has a 2296 value of "error" MUST NOT respond to the stanza with a further 2297 stanza of type "error"; this helps to prevent looping. 2299 o An child MUST NOT be included if the 'type' attribute has 2300 a value other than "error" (or if there is no 'type' attribute). 2302 8.7.2 Syntax 2304 The syntax for stanza-related errors is as follows: 2306 2307 [RECOMMENDED to include sender XML here] 2308 2309 2310 2311 OPTIONAL descriptive text 2312 2313 [OPTIONAL application-specific condition element] 2314 2315 2317 The stanza-name is one of message, presence, or iq. 2319 The value of the element's 'type' attribute MUST be one of 2320 the following: 2322 o cancel -- do not retry (the error is unrecoverable) 2324 o continue -- proceed (the condition was only a warning) 2326 o modify -- retry after changing the data sent 2328 o auth -- retry after providing credentials 2329 o wait -- retry after waiting (the error is temporary) 2331 The element: 2333 o MUST contain a child element corresponding to one of the defined 2334 stanza error conditions defined below; this element MUST be 2335 qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace 2337 o MAY contain a child containing CDATA that describes the 2338 error in more detail; this element MUST be qualified by the 2339 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace and SHOULD possess 2340 an 'xml:lang' attribute 2342 o MAY contain a child element for an application-specific error 2343 condition; this element MUST be qualified by an 2344 application-defined namespace, and its structure is defined by 2345 that namespace 2347 The element is OPTIONAL. If included, it SHOULD be used only 2348 to provide descriptive or diagnostic information that supplements the 2349 meaning of a defined condition or application-specific condition. It 2350 SHOULD NOT be interpreted programmatically by an application. It 2351 SHOULD NOT be used as the error message presented to user, but MAY be 2352 shown in addition to the error message associated with the included 2353 condition element (or elements). 2355 Note: the XML namespace name 'urn:ietf:params:xml:ns:xmpp-stanzas' 2356 that qualifies the descriptive element adheres to the format defined 2357 in The IETF XML Registry [25]. 2359 8.7.3 Defined Conditions 2361 The following stanza-related error conditions are defined for use in 2362 stanza errors. 2364 o -- the sender has sent XML that is malformed or 2365 that cannot be processed (e.g., a client-generated stanza includes 2366 a 'from' address, or an IQ stanza includes an unrecognized value 2367 of the 'type' attribute); the associated error type SHOULD be 2368 "modify". 2370 o -- access cannot be granted because an existing 2371 resource or session exists with the same name or address; the 2372 associated error type SHOULD be "cancel". 2374 o -- the feature requested is not 2375 implemented by the recipient or server and therefore cannot be 2376 processed; the associated error type SHOULD be "cancel". 2378 o -- the requesting entity does not possess the 2379 required permissions to perform the action; the associated error 2380 type SHOULD be "auth". 2382 o -- the server could not process the 2383 stanza because of a misconfiguration or an otherwise-undefined 2384 internal server error; the associated error type SHOULD be "wait". 2386 o -- the addressed JID or item requested cannot be 2387 found; the associated error type SHOULD be "cancel". 2389 o -- the value of the 'to' attribute in the 2390 sender's stanza does not adhere to the syntax defined in 2391 Addressing Scheme (Section 3); the associated error type SHOULD be 2392 "modify". 2394 o -- the recipient does not allow any entity to 2395 perform the action; the associated error type SHOULD be "cancel". 2397 o -- the specific recipient requested is 2398 currently unavailable; the associated error type SHOULD be "wait". 2400 o -- the user is not authorized to access 2401 the requested service because registration is required; the 2402 associated error type SHOULD be "auth". 2404 o -- a remote server or service specified 2405 as part or all of the JID of the intended recipient does not 2406 exist; the associated error type SHOULD be "cancel". 2408 o -- a remote server or service specified 2409 as part or all of the JID of the intended recipient could not be 2410 contacted within a reasonable amount of time; the associated error 2411 type SHOULD be "wait". 2413 o -- the server is resource-contrained and is 2414 unable to service the request; the associated error type SHOULD be 2415 "wait". 2417 o -- the service requested is currently 2418 unavailable on the server; the associated error type SHOULD be 2419 "cancel". 2421 o -- the user is not authorized to access 2422 the requested service because a subscription is required; the 2423 associated error type SHOULD be "auth". 2425 o -- the error condition is not one of those 2426 defined by the other conditions in this list; any error type may 2427 be associated with this condition, and it SHOULD be used only in 2428 conjuction with an application-specific condition. 2430 o -- the recipient understood the request but 2431 was not expecting it at this time (e.g., the request was out of 2432 order); the associated error type SHOULD be "wait". 2434 8.7.4 Application-Specific Conditions 2436 As noted, an application MAY provide application-specific stanza 2437 error information by including a properly-namespaced child in the 2438 error element. The application-specific element SHOULD supplement or 2439 further qualify a defined element. Thus the element will 2440 contain two or three child elements: 2442 2443 2444 2445 2446 2447 2449 2450 2451 2452 2453 Some special application diagnostic information! 2454 2455 2456 2457 2459 9. XML Usage within XMPP 2461 9.1 Restrictions 2463 XMPP is a simplified and specialized protocol for streaming XML 2464 elements in order to exchange messages and presence information in 2465 close to real time. Because XMPP does not require the parsing of 2466 arbitrary and complete XML documents, there is no requirement that 2467 XMPP needs to support the full XML specification [1]. In particular, 2468 the following restrictions apply. 2470 With regard to XML generation, an XMPP implementation MUST NOT inject 2471 into an XML stream any of the following: 2473 o comments (as defined in Section 2.5 of the XML specification [1]) 2475 o processing instructions (Section 2.6) 2477 o internal or external DTD subsets (Section 2.8) 2479 o internal or external entity references (Section 4.2) with the 2480 exception of predefined entities (Section 4.6) 2482 o character data or attribute values containing unescaped characters 2483 that map to the predefined entities (Section 4.6); such characters 2484 MUST be escaped 2486 With regard to XML processing, if an XMPP implementation receives 2487 such restricted XML data, it MUST ignore the data. 2489 9.2 XML Namespace Names and Prefixes 2491 XML Namespaces [12] are used within all XMPP-compliant XML to create 2492 strict boundaries of data ownership. The basic function of namespaces 2493 is to separate different vocabularies of XML elements that are 2494 structurally mixed together. Ensuring that XMPP-compliant XML is 2495 namespace-aware enables any XML to be structurally mixed with any 2496 data element within XMPP. Rules for XML namespace names and prefixes 2497 are defined below. 2499 9.2.1 Stream Namespace 2501 A stream namespace declaration is REQUIRED in both XML stream 2502 headers. The name of the stream namespace MUST be 'http:// 2503 etherx.jabber.org/streams'. The element names of the 2504 element and its and children MUST be qualified 2505 by the stream namespace prefix in all instances. An implementation 2506 SHOULD generate only the 'stream:' prefix for these elements, and for 2507 historical reasons MAY accept only the 'stream:' prefix. 2509 9.2.2 Default Namespace 2511 A default namespace declaration is REQUIRED and is used in both XML 2512 streams in order to define the allowable first-level children of the 2513 root stream element. This namespace declaration MUST be the same for 2514 the initiating stream and the responding stream so that both streams 2515 are qualified consistently. The default namespace declaration applies 2516 to the stream and all stanzas sent within a stream (unless explicitly 2517 qualified by another namespace, or by the prefix of the stream 2518 namespace or the dialback namespace). 2520 A server implementation MUST support the following two default 2521 namespaces (for historical reasons, some implementations MAY support 2522 only these two default namespaces): 2524 o jabber:client -- this default namespace is declared when the 2525 stream is used for communications between a client and a server 2527 o jabber:server -- this default namespace is declared when the 2528 stream is used for communications between two servers 2530 A client implementation MUST support the 'jabber:client' default 2531 namespace, and for historical reasons MAY support only that default 2532 namespace. 2534 An implementation MUST NOT generate namespace prefixes for elements 2535 in the default namespace if the default namespace is 'jabber:client' 2536 or 'jabber:server'. An implementation SHOULD NOT generate namespace 2537 prefixes for elements qualified by "extended" namespaces as described 2538 under Extended Namespaces (Section 8.6). 2540 Note: the 'jabber:client' and 'jabber:server' namespaces are nearly 2541 identical but are used in different contexts (client-to-server 2542 communications for 'jabber:client' and server-to-server 2543 communications for 'jabber:server'). The only difference between the 2544 two is that the 'to' and 'from' attributes are OPTIONAL on stanzas 2545 sent within 'jabber:client', whereas they are REQUIRED on stanzas 2546 sent within 'jabber:server'. If a compliant implementation accepts a 2547 stream that is qualified by the 'jabber:client' or 'jabber:server' 2548 namespace, it MUST support all three core stanza types (message, 2549 presence, and IQ) as described herein and defined in the schema. 2551 9.2.3 Dialback Namespace 2553 A dialback namespace declaration is REQUIRED for all elements used in 2554 server dialback. The name of the dialback namespace MUST be 2555 'jabber:server:dialback'. All elements qualified by this namespace 2556 MUST be prefixed. An implementation SHOULD generate only the 'db:' 2557 prefix for such elements and MAY accept only the 'db:' prefix. 2559 9.3 Validation 2561 Except as noted with regard to 'to' and 'from' addresses for stanzas 2562 within the 'jabber:server' namespace, a server is not responsible for 2563 validating the XML elements forwarded to a client or another server; 2564 an implementation MAY choose to provide only validated data elements 2565 but is NOT REQUIRED to do so (although an implementation MUST NOT 2566 accept XML that is not well-formed). Clients SHOULD NOT rely on the 2567 ability to send data which does not conform to the schemas, and 2568 SHOULD ignore any non-conformant elements or attributes on the 2569 incoming XML stream. Validation of XML streams and stanzas is NOT 2570 REQUIRED or recommended, and schemas are included herein for 2571 descriptive purposes only. 2573 9.4 Character Encodings 2575 Software implementing XML streams MUST support the UTF-8 (RFC 2279 2576 [19]) and UTF-16 (RFC 2781 [20]) transformations of Universal 2577 Character Set (ISO/IEC 10646-1 [21]) characters. Implementations MUST 2578 NOT attempt to use any other encoding for transmitted data. The 2579 encodings of the transmitted and received streams are independent. 2580 Implementations MAY select either UTF-8 or UTF-16 for the transmitted 2581 stream, and SHOULD deduce the encoding of the received stream as 2582 described in the XML specification [1]. For historical reasons, 2583 existing implementations MAY support UTF-8 only. 2585 9.5 Inclusion of Text Declaration 2587 An application MAY send a text declaration. Applications MUST follow 2588 the rules in the XML specification [1] regarding the circumstances 2589 under which a text declaration is included. 2591 10. IANA Considerations 2593 10.1 XML Namespace Name for TLS Data 2595 A URN sub-namespace for TLS-related data in the Extensible Messaging 2596 and Presence Protocol (XMPP) is defined as follows. 2598 URI: urn:ietf:params:xml:ns:xmpp-tls 2600 Specification: [RFCXXXX] 2602 Description: This is the XML namespace name for TLS-related data in 2603 the Extensible Messaging and Presence Protocol (XMPP) as defined 2604 by [RFCXXXX]. 2606 Registrant Contact: IETF, XMPP Working Group, 2608 10.2 XML Namespace Name for SASL Data 2610 A URN sub-namespace for SASL-related data in the Extensible Messaging 2611 and Presence Protocol (XMPP) is defined as follows. 2613 URI: urn:ietf:params:xml:ns:xmpp-sasl 2615 Specification: [RFCXXXX] 2617 Description: This is the XML namespace name for SASL-related data in 2618 the Extensible Messaging and Presence Protocol (XMPP) as defined 2619 by [RFCXXXX]. 2621 Registrant Contact: IETF, XMPP Working Group, 2623 10.3 XML Namespace Name for Stream Errors 2625 A URN sub-namespace for stream-related error data in the Extensible 2626 Messaging and Presence Protocol (XMPP) is defined as follows. 2628 URI: urn:ietf:params:xml:ns:xmpp-streams 2630 Specification: [RFCXXXX] 2632 Description: This is the XML namespace name for stream-related error 2633 data in the Extensible Messaging and Presence Protocol (XMPP) as 2634 defined by [RFCXXXX]. 2636 Registrant Contact: IETF, XMPP Working Group, 2638 10.4 XML Namespace Name for Stanza Errors 2640 A URN sub-namespace for stanza-related error data in the Extensible 2641 Messaging and Presence Protocol (XMPP) is defined as follows. 2643 URI: urn:ietf:params:xml:ns:xmpp-stanzas 2645 Specification: [RFCXXXX] 2647 Description: This is the XML namespace name for stanza-related error 2648 data in the Extensible Messaging and Presence Protocol (XMPP) as 2649 defined by [RFCXXXX]. 2651 Registrant Contact: IETF, XMPP Working Group, 2653 10.5 Existing Registrations 2655 The IANA registers "xmpp" as a GSSAPI [22] service name, as specified 2656 in SASL Definition (Section 6.4). 2658 Additionally, the IANA registers "jabber-client" and "jabber-server" 2659 as keywords for TCP ports 5222 and 5269 respectively. These ports 2660 SHOULD be used for client-to-server and server-to-server 2661 communications respectively, but their use is NOT REQUIRED. The use 2662 of the string "jabber" in these keywords is historical. 2664 11. Internationalization Considerations 2666 Each XML stanza SHOULD include an 'xml:lang' attribute. Servers MUST 2667 NOT modify or delete 'xml:lang' attributes from stanzas they receive 2668 from other entities. 2670 12. Security Considerations 2672 12.1 High Security 2674 For the purposes of XMPP communications (client-to-server and 2675 server-to-server), the term "high security" refers to the use of 2676 security technologies that provide both mutual authentication and 2677 integrity-checking; in particular, when using certificate-based 2678 authentication to provide high security, a chain-of-trust SHOULD be 2679 established out-of-band, although a shared certificate authority 2680 signing certificates could allow a previously unknown certificate to 2681 establish trust in-band. 2683 Standalone, self-signed service certificates SHOULD NOT be used; 2684 rather, an entity that wishes to generate a self-signed service 2685 certificate SHOULD first generate a self-signed Root CA certificate 2686 and then generate a signed service certificate. Entities that 2687 communicate with the service SHOULD be configured with the Root CA 2688 certificate rather than the service certificate; this avoids problems 2689 associated with simple comparison of service certificates. If a 2690 self-signed service certificate is used, an entity SHOULD NOT trust 2691 it if it is changed to another self-signed certificate or a 2692 certificate signed by an unrecognized authority. 2694 Implementations MUST support high security. Service provisioning 2695 SHOULD use high security, subject to local security policies. 2697 12.2 Client-to-Server Communications 2699 A compliant implementation MUST support both TLS and SASL for 2700 connections to a server. 2702 The TLS protocol for encrypting XML streams (defined under Stream 2703 Encryption (Section 5)) provides a reliable mechanism for helping to 2704 ensure the confidentiality and data integrity of data exchanged 2705 between two entities. 2707 The SASL protocol for authenticating XML streams (defined under 2708 Stream Authentication (Section 6)) provides a reliable mechanism for 2709 validating that a client connecting to a server is who it claims to 2710 be. 2712 The IP address and method of access of clients MUST NOT be made 2713 available by a server, nor are any connections other than the 2714 original server connection required. This helps to protect the 2715 client's server from direct attack or identification by third 2716 parties. 2718 12.3 Server-to-Server Communications 2720 A compliant implementation MUST support both TLS and SASL for 2721 inter-domain communications. For historical reasons, a compliant 2722 implementation SHOULD also support Server Dialback (Section 7). 2724 Because service provisioning is a matter of policy, it is OPTIONAL 2725 for any given domain to communicate with other domains, and 2726 server-to-server communications MAY be disabled by the administrator 2727 of any given deployment. If a particular domain enables inter-domain 2728 communications, it SHOULD enable high security. 2730 Administrators may want to require use of SASL for server-to-server 2731 communications in order to ensure both authentication and 2732 confidentiality (e.g., on an organization's private network). 2733 Compliant implementations SHOULD support SASL for this purpose. 2735 Inter-domain connections MUST NOT proceed until the DNS hostnames 2736 asserted by the servers have been resolved. Such resolutions MUST 2737 first attempt to resolve the hostname using an SRV [18] record of 2738 _jabber._tcp.server (the use of the string "jabber" for SRV purposes 2739 is historical). If the SRV lookup fails, the fallback is a normal A 2740 lookup to determine the IP address, using the jabber-server port of 2741 5269 assigned by the Internet Assigned Numbers Authority [5]. 2743 Server dialback helps protect against domain spoofing, thus making it 2744 more difficult to spoof XML stanzas. It is not a mechanism for 2745 authenticating, securing, or encrypting streams between servers as is 2746 done via SASL and TLS. Furthermore, it is susceptible to DNS 2747 poisoning attacks unless DNSSec [30] is used, and even if the DNS 2748 information is accurate, dialback cannot protect from attacks where 2749 the attacker is capable of hijacking the IP address of the remote 2750 domain. Domains requiring robust security SHOULD use TLS and SASL. If 2751 SASL is used for server-to-server authentication, dialback SHOULD NOT 2752 be used since it is unnecessary. 2754 12.4 Order of Layers 2756 The order of layers in which protocols MUST be stacked is as follows: 2758 1. TCP 2760 2. TLS 2762 3. SASL 2764 4. XMPP 2765 The rationale for this order is that TCP is the base connection layer 2766 used by all of the protocols stacked on top of TCP, TLS is often 2767 provided at the operating system layer, SASL is often provided at the 2768 application layer, and XMPP is the application itself. 2770 12.5 Firewalls 2772 Communications using XMPP normally occur over TCP sockets on port 2773 5222 (client-to-server) or port 5269 (server-to-server), as 2774 registered with the IANA [5] (see IANA Considerations (Section 10)). 2775 Use of these well-known ports allows administrators to easily enable 2776 or disable XMPP activity through existing and commonly-deployed 2777 firewalls. 2779 12.6 Mandatory to Implement Technologies 2781 At a minimum, all implementations MUST support the following 2782 mechanisms: 2784 for authentication: the SASL DIGEST-MD5 mechanism 2786 for confidentiality: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA 2787 cipher) 2789 for both: TLS plus SASL EXTERNAL(using the 2790 TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side 2791 certificates) 2793 Normative References 2795 [1] World Wide Web Consortium, "Extensible Markup Language (XML) 2796 1.0 (Second Edition)", W3C xml, October 2000, . 2799 [2] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 2800 Presence Protocol Requirements", RFC 2779, February 2000. 2802 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2803 Levels", BCP 14, RFC 2119, March 1997. 2805 [4] University of Southern California, "Transmission Control 2806 Protocol", RFC 793, September 1981, . 2809 [5] Internet Assigned Numbers Authority, "Internet Assigned Numbers 2810 Authority", January 1998, . 2812 [6] Harrenstien, K., Stahl, M. and E. Feinler, "DoD Internet host 2813 table specification", RFC 952, October 1985. 2815 [7] Braden, R., "Requirements for Internet Hosts - Application and 2816 Support", STD 3, RFC 1123, October 1989. 2818 [8] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile 2819 for Internationalized Domain Names (draft-ietf-idn-nameprep-11, 2820 work in progress)", June 2002. 2822 [9] Hoffman, P. and M. Blanchet, "Preparation of Internationalized 2823 Strings ("stringprep")", RFC 3454, December 2002. 2825 [10] Saint-Andre, P. and J. Hildebrand, "Nodeprep: A Stringprep 2826 Profile for Node Identifiers in XMPP", 2827 draft-ietf-xmpp-nodeprep-03 (work in progress), June 2003. 2829 [11] Saint-Andre, P. and J. Hildebrand, "Resourceprep: A Stringprep 2830 Profile for Resource Identifiers in XMPP", 2831 draft-ietf-xmpp-resourceprep-03 (work in progress), June 2003. 2833 [12] World Wide Web Consortium, "Namespaces in XML", W3C xml-names, 2834 January 1999, . 2837 [13] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 2838 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 2839 1999. 2841 [14] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2843 [15] Myers, J., "Simple Authentication and Security Layer (SASL)", 2844 RFC 2222, October 1997. 2846 [16] Leach, P. and C. Newman, "Using Digest Authentication as a SASL 2847 Mechanism", RFC 2831, May 2000. 2849 [17] Alvestrand, H., "Tags for the Identification of Languages", BCP 2850 47, RFC 3066, January 2001. 2852 [18] Gulbrandsen, A. and P. Vixie, "A DNS RR for specifying the 2853 location of services (DNS SRV)", RFC 2052, October 1996. 2855 [19] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2856 2279, January 1998. 2858 [20] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", 2859 RFC 2781, February 2000. 2861 [21] International Organization for Standardization, "Information 2862 Technology - Universal Multiple-octet coded Character Set (UCS) 2863 - Amendment 2: UCS Transformation Format 8 (UTF-8)", ISO 2864 Standard 10646-1 Addendum 2, October 1996. 2866 [22] Linn, J., "Generic Security Service Application Program 2867 Interface, Version 2", RFC 2078, January 1997. 2869 Informative References 2871 [23] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging", 2872 draft-ietf-xmpp-im-12 (work in progress), June 2003. 2874 [24] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 2875 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 2876 1998, . 2878 [25] Mealling, M., "The IANA XML Registry", 2879 draft-mealling-iana-xmlns-registry-04 (work in progress), June 2880 2002. 2882 [26] Crispin, M., "Internet Message Access Protocol - Version 2883 4rev1", RFC 2060, December 1996. 2885 [27] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 2886 53, RFC 1939, May 1996. 2888 [28] Newman, C. and J. Myers, "ACAP -- Application Configuration 2889 Access Protocol", RFC 2244, November 1997. 2891 [29] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, 2892 June 1999. 2894 [30] Eastlake, D., "Domain Name System Security Extensions", RFC 2895 2535, March 1999. 2897 [31] Alvestrand, H., "IETF Policy on Character Sets and Languages", 2898 BCP 18, RFC 2277, January 1998. 2900 [32] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 2901 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 2902 HTTP/1.1", RFC 2616, June 1999. 2904 Authors' Addresses 2906 Peter Saint-Andre 2907 Jabber Software Foundation 2909 EMail: stpeter@jabber.org 2911 Jeremie Miller 2912 Jabber Software Foundation 2914 EMail: jeremie@jabber.org 2916 Appendix A. XML Schemas 2918 The following XML schemas are descriptive, not normative. 2920 A.1 Stream namespace 2922 2924 2930 2931 2932 2933 2934 2935 2938 2941 2942 2943 2944 2945 2946 2947 2948 2949 2951 2952 2953 2954 2958 2959 2960 2962 2963 2964 2965 2967 2971 2972 2973 2975 2977 A.2 Stream error namespace 2979 2981 2988 2991 2992 2993 2994 2995 2996 2997 2998 2999 3000 3001 3002 3003 3004 3005 3007 3008 3009 3010 3012 3014 3015 3016 3017 3018 3020 3022 A.3 TLS namespace 3024 3026 3032 3033 3034 3035 3039 3040 3041 3043 3044 3045 3047 3048 3049 3050 3051 3053 3055 A.4 SASL namespace 3057 3058 3064 3065 3066 3067 3068 3069 3070 3072 3074 3075 3076 3079 3080 3082 3083 3084 3085 3087 3088 3089 3090 3091 3092 3093 3094 3095 3096 3097 3098 3099 3100 3102 3103 3104 3105 3106 3107 3108 3109 3111 3112 3113 3114 3115 3117 3119 A.5 Dialback namespace 3121 3123 3129 3130 3131 3132 3133 3134 3135 3136 3137 3138 3139 3140 3141 3142 3143 3144 3145 3146 3148 3149 3150 3151 3152 3153 3154 3155 3156 3157 3158 3159 3160 3161 3162 3163 3164 3165 3166 3168 3170 A.6 Client namespace 3172 3174 3181 3184 3185 3186 3187 3190 3193 3196 3199 3202 3203 3206 3209 3212 3213 3214 3215 3216 3217 3218 3219 3220 3221 3222 3223 3224 3225 3227 3228 3229 3230 3231 3233 3234 3235 3236 3237 3239 3241 3242 3243 3244 3247 3250 3253 3256 3259 3260 3263 3266 3269 3270 3271 3272 3273 3274 3275 3276 3277 3278 3279 3280 3281 3282 3283 3285 3286 3287 3288 3289 3290 3291 3292 3293 3294 3295 3296 3297 3298 3299 3301 3303 3304 3305 3306 3309 3312 3313 3316 3319 3322 3323 3324 3325 3326 3327 3328 3329 3330 3331 3332 3333 3334 3336 3337 3338 3339 3341 3344 3348 3349 3350 3351 3352 3353 3354 3355 3356 3357 3358 3359 3360 3361 3363 3365 A.7 Server namespace 3367 3369 3376 3379 3380 3381 3382 3385 3388 3391 3394 3397 3398 3401 3404 3407 3408 3409 3410 3411 3412 3413 3414 3415 3416 3417 3418 3419 3420 3422 3423 3424 3425 3426 3428 3429 3430 3431 3432 3434 3436 3437 3438 3439 3442 3445 3448 3451 3454 3455 3458 3461 3464 3465 3466 3467 3468 3469 3470 3471 3472 3473 3474 3475 3476 3477 3478 3480 3481 3482 3483 3484 3485 3486 3487 3488 3489 3491 3492 3493 3494 3495 3497 3499 3500 3501 3502 3505 3508 3509 3512 3515 3518 3519 3520 3521 3522 3523 3524 3525 3526 3527 3528 3529 3530 3532 3533 3534 3535 3537 3540 3544 3545 3546 3547 3548 3549 3550 3551 3552 3553 3554 3555 3556 3557 3559 3561 A.8 Stanza error namespace 3563 3565 3572 3575 3576 3577 3578 3579 3580 3581 3582 3583 3584 3585 3586 3587 3588 3589 3590 3591 3593 3594 3595 3596 3597 3599 3600 3601 3602 3603 3605 3607 Appendix B. Revision History 3609 Note to RFC Editor: please remove this entire appendix, and the 3610 corresponding entries in the table of contents, prior to publication. 3612 B.1 Changes from draft-ietf-xmpp-core-13 3614 o Clarified stream restart after successful TLS and SASL 3615 negotiation. 3617 o Clarified requirement for resolution of DNS hostnames. 3619 o Clarified text regarding namespaces. 3621 o Clarified examples regarding empty element. 3623 o Added several more SASL error conditions. 3625 o Changed stream error to and 3626 added to schema. 3628 o Made small editorial changes and fixed several schema errors. 3630 B.2 Changes from draft-ietf-xmpp-core-12 3632 o Moved server dialback to a separate section; clarified its 3633 security characteristics and its role in the protocol. 3635 o Adjusted error handling syntax and semantics per list discussion. 3637 o Further clarified length of node identifiers and total length of 3638 JIDs. 3640 o Documented message type='normal'. 3642 o Corrected several small errors in the TLS and SASL sections. 3644 o Corrected several errors in the schemas. 3646 B.3 Changes from draft-ietf-xmpp-core-11 3648 o Corrected several small errors in the TLS and SASL sections. 3650 o Made small editorial changes and fixed several schema errors. 3652 B.4 Changes from draft-ietf-xmpp-core-10 3654 o Adjusted TLS content regarding certificate validation process. 3656 o Specified that stanza error extensions for specific applications 3657 are to be properly namespaced children of the relevant descriptive 3658 element. 3660 o Clarified rules for inclusion of the 'id' attribute. 3662 o Specified that the 'xml:lang' attribute SHOULD be included (per 3663 list discussion). 3665 o Made small editorial changes and fixed several schema errors. 3667 B.5 Changes from draft-ietf-xmpp-core-09 3669 o Fixed several dialback error conditions. 3671 o Cleaned up rules regarding TLS and certificate processing based on 3672 off-list feedback. 3674 o Changed and elements to 3675 . 3677 o Added or modified several stream and stanza error conditions. 3679 o Specified only one child allowed for IQ, or two if type="error". 3681 o Fixed several errors in the schemas. 3683 B.6 Changes from draft-ietf-xmpp-core-08 3685 o Incorporated list discussion regarding addressing, SASL, TLS, TCP, 3686 dialback, namespaces, extensibility, and the meaning of 'ignore' 3687 for routers and recipients. 3689 o Specified dialback error conditions. 3691 o Made small editorial changes to address RFC Editor requirements. 3693 B.7 Changes from draft-ietf-xmpp-core-07 3695 o Made several small editorial changes. 3697 B.8 Changes from draft-ietf-xmpp-core-06 3699 o Added text regarding certificate validation in TLS negotiation per 3700 list discussion. 3702 o Clarified nature of XML restrictions per discussion with W3C, and 3703 moved XML Restrictions subsection under "XML Usage within XMPP". 3705 o Further clarified that XML streams are unidirectional. 3707 o Changed stream error and stanza error namespace names to conform 3708 to the format defined in The IETF XML Registry [25]. 3710 o Removed note to RFC Editor regarding provisional namespace names. 3712 B.9 Changes from draft-ietf-xmpp-core-05 3714 o Added as a stream error condition. 3716 o Adjusted security considerations per discussion at IETF 56 and on 3717 list. 3719 B.10 Changes from draft-ietf-xmpp-core-04 3721 o Added server-to-server examples for TLS and SASL. 3723 o Changed error syntax, rules, and examples based on list 3724 discussion. 3726 o Added schemas for the TLS, stream error, and stanza error 3727 namespaces. 3729 o Added note to RFC Editor regarding provisional namespace names. 3731 o Made numerous small editorial changes and clarified text 3732 throughout. 3734 B.11 Changes from draft-ietf-xmpp-core-03 3736 o Clarified rules and procedures for TLS and SASL. 3738 o Amplified stream error code syntax per list discussion. 3740 o Made numerous small editorial changes. 3742 B.12 Changes from draft-ietf-xmpp-core-02 3744 o Added dialback schema. 3746 o Removed all DTDs since schemas provide more complete definitions. 3748 o Added stream error codes. 3750 o Clarified error code "philosophy". 3752 B.13 Changes from draft-ietf-xmpp-core-01 3754 o Updated the addressing restrictions per list discussion and added 3755 references to the new nodeprep and resourceprep profiles. 3757 o Corrected error in Stream Authentication regarding 'version' 3758 attribute. 3760 o Made numerous small editorial changes. 3762 B.14 Changes from draft-ietf-xmpp-core-00 3764 o Added information about TLS from list discussion. 3766 o Clarified meaning of "ignore" based on list discussion. 3768 o Clarified information about Universal Character Set data and 3769 character encodings. 3771 o Provided base64-decoded information for examples. 3773 o Fixed several errors in the schemas. 3775 o Made numerous small editorial fixes. 3777 B.15 Changes from draft-miller-xmpp-core-02 3779 o Brought Streams Authentication section into line with discussion 3780 on list and at IETF 55 meeting. 3782 o Added information about the optional 'xml:lang' attribute per 3783 discussion on list and at IETF 55 meeting. 3785 o Specified that validation is neither required nor recommended, and 3786 that the formal definitions (DTDs and schemas) are included for 3787 descriptive purposes only. 3789 o Specified that the response to an IQ stanza of type "get" or "set" 3790 must be an IQ stanza of type "result" or "error". 3792 o Specified that compliant server implementations must process 3793 stanzas in order. 3795 o Specified that for historical reasons some server implementations 3796 may accept 'stream:' as the only valid namespace prefix on the 3797 root stream element. 3799 o Clarified the difference between 'jabber:client' and 3800 'jabber:server' namespaces, namely, that 'to' and 'from' 3801 attributes are required on all stanzas in the latter but not the 3802 former. 3804 o Fixed typo in Step 9 of the dialback protocol (changed db:result 3805 to db:verify). 3807 o Removed references to TLS pending list discussion. 3809 o Removed the non-normative appendix on OpenPGP usage pending its 3810 inclusion in a separate I-D. 3812 o Simplified the architecture diagram, removed most references to 3813 services, and removed references to the 'jabber:component:*' 3814 namespaces. 3816 o Noted that XMPP activity respects firewall administration 3817 policies. 3819 o Further specified the scope and uniqueness of the 'id' attribute 3820 in all stanza types and the element in message stanzas. 3822 o Nomenclature changes: (1) from "chunks" to "stanzas"; (2) from 3823 "host" to "server" and from "node" to "client" (except with regard 3824 to definition of the addressing scheme). 3826 Intellectual Property Statement 3828 The IETF takes no position regarding the validity or scope of any 3829 intellectual property or other rights that might be claimed to 3830 pertain to the implementation or use of the technology described in 3831 this document or the extent to which any license under such rights 3832 might or might not be available; neither does it represent that it 3833 has made any effort to identify any such rights. Information on the 3834 IETF's procedures with respect to rights in standards-track and 3835 standards-related documentation can be found in BCP-11. Copies of 3836 claims of rights made available for publication and any assurances of 3837 licenses to be made available, or the result of an attempt made to 3838 obtain a general license or permission for the use of such 3839 proprietary rights by implementors or users of this specification can 3840 be obtained from the IETF Secretariat. 3842 The IETF invites any interested party to bring to its attention any 3843 copyrights, patents or patent applications, or other proprietary 3844 rights which may cover technology that may be required to practice 3845 this standard. Please address the information to the IETF Executive 3846 Director. 3848 Full Copyright Statement 3850 Copyright (C) The Internet Society (2003). All Rights Reserved. 3852 This document and translations of it may be copied and furnished to 3853 others, and derivative works that comment on or otherwise explain it 3854 or assist in its implementation may be prepared, copied, published 3855 and distributed, in whole or in part, without restriction of any 3856 kind, provided that the above copyright notice and this paragraph are 3857 included on all such copies and derivative works. However, this 3858 document itself may not be modified in any way, such as by removing 3859 the copyright notice or references to the Internet Society or other 3860 Internet organizations, except as needed for the purpose of 3861 developing Internet standards in which case the procedures for 3862 copyrights defined in the Internet Standards process must be 3863 followed, or as required to translate it into languages other than 3864 English. 3866 The limited permissions granted above are perpetual and will not be 3867 revoked by the Internet Society or its successors or assignees. 3869 This document and the information contained herein is provided on an 3870 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3871 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3872 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3873 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3874 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3876 Acknowledgement 3878 Funding for the RFC Editor function is currently provided by the 3879 Internet Society.