idnits 2.17.1 draft-ietf-xmpp-core-17.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 2 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 3564 has weird spacing: '... mailing list, for which archives and subscription 209 information are available at . 212 1.4 Intellectual Property Notice 214 This document is in full compliance with all provisions of Section 10 215 of RFC 2026. Parts of this specification use the term "jabber" for 216 identifying namespaces and other protocol syntax. Jabber[tm] is a 217 registered trademark of Jabber, Inc. Jabber, Inc. grants permission 218 to the IETF for use of the Jabber trademark in association with this 219 specification and its successors, if any. 221 2. Generalized Architecture 223 2.1 Overview 225 Although XMPP is not wedded to any specific network architecture, to 226 this point it usually has been implemented via a typical 227 client-server architecture, wherein a client utilizing XMPP accesses 228 a server over a TCP [4] socket. 230 The following diagram provides a high-level overview of this 231 architecture (where "-" represents communications that use XMPP and 232 "=" represents communications that use any other protocol). 234 C1 - S1 - S2 - C3 235 / \ 236 C2 - G1 = FN1 = FC1 238 The symbols are as follows: 240 o C1, C2, C3 -- XMPP clients 242 o S1, S2 -- XMPP servers 244 o G1 -- A gateway that translates between XMPP and the protocol(s) 245 used on a foreign (non-XMPP) messaging network 247 o FN1 -- A foreign messaging network 249 o FC1 -- A client on a foreign messaging network 251 2.2 Server 253 A server acts as an intelligent abstraction layer for XMPP 254 communications. Its primary responsibilities are to manage 255 connections from or sessions for other entities (in the form of XML 256 streams to and from authorized clients, servers, and other entities) 257 and to route appropriately-addressed XML data "stanzas" among such 258 entities over XML streams. Most XMPP-compliant servers also assume 259 responsibility for the storage of data that is used by clients (e.g., 260 contact lists for users of XMPP-based instant messaging 261 applications); in this case, the XML data is processed directly by 262 the server itself on behalf of the client and is not routed to 263 another entity. Compliant server implementations MUST ensure in-order 264 processing of XML stanzas between any two entities. 266 2.3 Client 267 Most clients connect directly to a server over a TCP socket and use 268 XMPP to take full advantage of the functionality provided by a server 269 and any associated services. Although there is no necessary coupling 270 of an XML stream to a TCP socket (e.g., a client COULD connect via 271 HTTP polling or some other mechanism), this specification defines a 272 binding for XMPP to TCP only. Multiple resources (e.g., devices or 273 locations) MAY connect simultaneously to a server on behalf of each 274 authorized client, with each resource connecting over a discrete TCP 275 socket and differentiated by the resource identifier of a JID (e.g., 276 vs. ) as defined under 277 Addressing Scheme (Section 3). The port registered with the IANA for 278 connections between a client and a server is 5222 (see IANA 279 Considerations (Section 10)). 281 2.4 Gateway 283 A gateway is a special-purpose server-side service whose primary 284 function is to translate XMPP into the protocol used by a foreign 285 (non-XMPP) messaging system, as well as to translate the return data 286 back into XMPP. Examples are gateways to Internet Relay Chat (IRC), 287 Short Message Service (SMS), SMTP, and legacy instant messaging 288 networks such as AIM, ICQ, MSN Messenger, and Yahoo! Instant 289 Messenger. Communications between gateways and servers, and between 290 gateways and the foreign messaging system, are not defined in this 291 document. 293 2.5 Network 295 Because each server is identified by a network address and because 296 server-to-server communications are a straightforward extension of 297 the client-to-server protocol, in practice the system consists of a 298 network of servers that inter-communicate. Thus user-a@domain1 is 299 able to exchange messages, presence, and other information with 300 user-b@domain2. This pattern is familiar from messaging protocols 301 (such as SMTP) that make use of network addressing standards. 302 Communications between any two servers are OPTIONAL; if enabled, such 303 communications occur over XML streams that are normally bound to TCP 304 sockets, using port 5269 as registered with the IANA (see IANA 305 Considerations (Section 10)). 307 3. Addressing Scheme 309 3.1 Overview 311 An entity is anything that can be considered a network endpoint 312 (i.e., an ID on the network) and that can communicate using XMPP. All 313 such entities are uniquely addressable in a form that is consistent 314 with RFC 2396 [25]. For historical reasons, the address of such an 315 entity is called a Jabber Identifier or JID. A valid JID contains a 316 set of ordered elements formed of a domain identifier, node 317 identifier, and resource identifier in the following format: 318 [node@]domain[/resource]. Each allowable portion of a JID (node 319 identifier, domain identifier, and resource identifier) may be up to 320 1023 bytes in length, resulting in a maximum total size (including 321 the '@' and '/' separators) of 3071 bytes. 323 All JIDs are based on the foregoing structure. The most common use of 324 this structure is to identify an instant messaging user, the server 325 to which the user connects, and the user's active session or 326 connection (e.g., a specific client) in the form of . However, node types other than clients are possible; for 328 example, a specific chat room offered by a multi-user chat service 329 could be addressed as (where "room" is the name of the 330 chat room and "service" is the hostname of the multi-user chat 331 service) and a specific occupant of such a room could be addressed as 332 (where "nick" is the occupant's room nickname). 333 Many other JID types are possible (e.g., could be a 334 server-side script or service). 336 3.2 Domain Identifier 338 The domain identifier is the primary identifier and is the only 339 REQUIRED element of a JID (a mere domain identifier is a valid JID). 340 It usually represents the network gateway or "primary" server to 341 which other entities connect for XML routing and data management 342 capabilities. However, the entity referenced by a domain identifier 343 is not always a server, and may be a service that is addressed as a 344 subdomain of a server and that provides functionality above and 345 beyond the capabilities of a server (e.g., a multi-user chat service, 346 a user directory, or a gateway to a foreign messaging system). 348 The domain identifier for every server or service that will 349 communicate over a network SHOULD resolve to a Fully Qualified Domain 350 Name. A domain identifier MUST conform to RFC 952 [6] and RFC 1123 351 [7]. In addition, a domain identifier MUST be no more than 1023 bytes 352 in length and MUST conform to the nameprep [8] profile of stringprep 353 [9]. 355 3.3 Node Identifier 357 The node identifier is an optional secondary identifier placed before 358 the domain identifier and separated from the latter by the '@' 359 character. It usually represents the entity requesting and using 360 network access provided by the server or gateway (i.e., a client), 361 although it can also represent other kinds of entities (e.g., a chat 362 room associated with a multi-user chat service). The entity 363 represented by a node identifier is addressed within the context of a 364 specific domain; within instant messaging applications of XMPP this 365 address is called a "bare JID" and is of the form . 367 A node identifier MUST be no more than 1023 bytes in length and MUST 368 conform to the nodeprep [10] profile of stringprep [9]. 370 3.4 Resource Identifier 372 The resource identifier is an optional tertiary identifier placed 373 after the domain identifier and separated from the latter by the '/' 374 character. A resource identifier may modify either a or 375 mere address. It usually represents a specific session, 376 connection (e.g., a device or location), or object (e.g., a 377 participant in a multi-user chat room) belonging to the entity 378 associated with a node identifier. A resource identifier is opaque to 379 both servers and other clients, and is typically defined by a client 380 implementation as the authzid value provided during stream 381 authentication. An entity may maintain multiple resources 382 simultaneously. 384 A resource identifier MUST be no more than 1023 bytes in length and 385 MUST conform to the resourceprep [11] profile of stringprep [9]. 387 4. XML Streams 389 4.1 Overview 391 Two fundamental concepts make possible the rapid, asynchronous 392 exchange of relatively small payloads of structured information 393 between presence-aware entities: XML streams and XML stanzas. These 394 terms may be defined as follows: 396 Definition of XML Stream: An XML stream is a container for the 397 exchange of XML elements between any two entities over a network. 398 An XML stream is negotiated from an initiating entity (usually a 399 client or server) to a receiving entity (usually a server), 400 normally over a TCP socket, and corresponds to the initiating 401 entity's "session" with the receiving entity. The start of the XML 402 stream is denoted unambiguously by an opening XML tag 403 with appropriate attributes and namespace declarations, and the 404 end of the XML stream is denoted unambiguously by a closing XML tag. An XML stream is unidirectional; in order to enable 406 bidirectional information exchange, the initiating entity and 407 receiving entity MUST negotiate one stream in each direction (the 408 "initial stream" and the "response stream"), normally over the 409 same TCP connection. 411 Definition of XML Stanza: An XML stanza is a discrete semantic unit 412 of structured information that is sent from one entity to another 413 over an XML stream. An XML stanza exists at the direct child level 414 of the root element and is said to be well-balanced if 415 it matches production [43] content of the XML specification [1]). 416 The start of any XML stanza is denoted unambiguously by the 417 element start tag at depth=1 of the XML stream (e.g., ), 418 and the end of any XML stanza is denoted unambiguously by the 419 corresponding close tag at depth=1 (e.g., ). An XML 420 stanza MAY contain child elements (with accompanying attributes, 421 elements, and CDATA) as necessary in order to convey the desired 422 information. An XML element sent for the purpose of stream 423 encryption, stream authentication, or server dialback is not 424 considered to be an XML stanza. 426 Consider the example of a client's session with a server. In order to 427 connect to a server, a client MUST initiate an XML stream by sending 428 an opening tag to the server, optionally preceded by a text 429 declaration specifying the XML version supported and the character 430 encoding (see also Character Encodings (Section 9.5)). The server 431 SHOULD then reply with a second XML stream back to the client, again 432 optionally preceded by a text declaration. Once the client has 433 authenticated with the server (see Section 6), the client MAY send an 434 unlimited number of XML stanzas over the stream to any recipient on 435 the network. When the client desires to close the stream, it simply 436 sends a closing tag to the server (alternatively, the 437 stream may be closed by the server), after which both the client and 438 server SHOULD close the underlying TCP connection as well. 440 Those who are accustomed to thinking of XML in a document-centric 441 manner may wish to view a client's session with a server as 442 consisting of two open-ended XML documents: one from the client to 443 the server and one from the server to the client. From this 444 perspective, the root element can be considered the 445 document entity for each "document", and the two "documents" are 446 built up through the accumulation of XML stanzas sent over the two 447 XML streams. However, this perspective is a convenience only, and 448 XMPP does not deal in documents but in XML streams and XML stanzas. 450 In essence, then, an XML stream acts as an envelope for all the XML 451 stanzas sent during a session. We can represent this graphically as 452 follows: 454 |--------------------| 455 | | 456 |--------------------| 457 | | 458 | | 459 | | 460 |--------------------| 461 | | 462 | | 463 | | 464 |--------------------| 465 | | 466 | | 467 | | 468 |--------------------| 469 | ... | 470 |--------------------| 471 | | 472 |--------------------| 474 4.2 Stream Attributes 476 The attributes of the stream element are as follows: 478 o to -- The 'to' attribute SHOULD be used only in the XML stream 479 header from the initiating entity to the receiving entity, and 480 MUST be set to the JID of the receiving entity. There SHOULD be no 481 'to' attribute set in the XML stream header by which the receiving 482 entity replies to the initiating entity; however, if a 'to' 483 attribute is included, it SHOULD be silently ignored by the 484 initiating entity. 486 o from -- The 'from' attribute SHOULD be used only in the XML stream 487 header from the receiving entity to the initiating entity, and 488 MUST be set to the JID of the receiving entity granting access to 489 the initiating entity. There SHOULD be no 'from' attribute on the 490 XML stream header sent from the initiating entity to the receiving 491 entity; however, if a 'from' attribute is included, it SHOULD be 492 silently ignored by the receiving entity. 494 o id -- The 'id' attribute SHOULD be used only in the XML stream 495 header from the receiving entity to the initiating entity. This 496 attribute is a unique identifier created by the receiving entity 497 to function as a session key for the initiating entity's streams 498 with the receiving entity, and MUST be unique within the receiving 499 application (normally a server). There SHOULD be no 'id' attribute 500 on the XML stream header sent from the initiating entity to the 501 receiving entity; however, if an 'id' attribute is included, it 502 SHOULD be silently ignored by the receiving entity. 504 o version -- The presence of the version attribute set to a value of 505 "1.0" signals support for the stream features defined in this 506 specification. Detailed rules regarding generation and handling of 507 this attribute are defined below. 509 We can summarize as follows: 511 | initiating to receiving | receiving to initiating 512 ------------------------------------------------------------ 513 to | hostname of receiver | silently ignored 514 from | silently ignored | hostname of receiver 515 id | silently ignored | session key 516 version | signals XMPP 1.0 support | signals XMPP 1.0 support 518 4.2.1 Version Support 520 The following rules apply to the generation and handling of the 521 'version' attribute: 523 1. If the initiating entity complies with the XML streams protocol 524 defined herein (including Stream Encryption (Section 5), Stream 525 Authentication (Section 6), and Stream Errors (Section 4.6)), it 526 MUST include the 'version' attribute in the XML stream header it 527 sends to the receiving entity, and it MUST set the value of the 528 'version' attribute to "1.0". 530 2. If the initiating entity includes the 'version' attribute set to 531 a value of "1.0" in its stream header and the receiving entity 532 supports XMPP 1.0, the receiving entity MUST reciprocate by 533 including the 'version' attribute set to a value of "1.0" in its 534 stream header response. 536 3. If the initiating entity does not include the 'version' attribute 537 in its stream header, the receiving entity still SHOULD include 538 the 'version' attribute set to a value of "1.0" in its stream 539 header response. 541 4. If the initiating entity includes the 'version' attribute set to 542 a value other than "1.0", the receiving entity SHOULD include the 543 'version' attribute set to a value of "1.0" in its stream header 544 response, but MAY at its discretion generate an 545 stream error and terminate the XML stream 546 and underlying TCP connection. 548 5. If the receiving entity includes the 'version' attribute set to a 549 value other than "1.0" in its stream header response, the 550 initiating entity SHOULD generate an 551 stream error and terminate the XML stream and underlying TCP 552 connection. 554 4.3 Namespace Declarations 556 The stream element MUST possess both a stream namespace declaration 557 and a default namespace declaration (as "namespace declaration" is 558 defined in the XML namespaces specification [12]). For detailed 559 information regarding the stream namespace and default namespace, see 560 Namespace Names and Prefixes (Section 9.2). 562 4.4 Stream Features 564 If the initiating entity includes the 'version' attribute set to a 565 value of "1.0" in its initiating stream element, the receiving entity 566 MUST send a child element (prefixed by the stream 567 namespace prefix) to the initiating entity in order to announce any 568 stream-level features that can be negotiated (or capabilities that 569 otherwise need to be advertised). Currently this is used for TLS and 570 SASL negotiation only, but it could be used for other negotiable 571 features in the future (usage is defined under Stream Encryption 572 (Section 5) and Stream Authentication (Section 6) below). If an 573 entity does not understand or support some features, it SHOULD 574 silently ignore them. 576 4.5 Stream Encryption and Authentication 578 XML streams in XMPP 1.0 SHOULD be encrypted as defined under Stream 579 Encryption (Section 5) and MUST be authenticated as defined under 580 Stream Authentication (Section 6). If the initiating entity attempts 581 to send an XML stanza before the stream is authenticated, the 582 receiving entity SHOULD return a stream error to 583 the initiating entity and then terminate both the XML stream and the 584 underlying TCP connection. 586 4.6 Stream Errors 588 The root stream element MAY contain an child element that is 589 prefixed by the stream namespace prefix. The error child MUST be sent 590 by a compliant entity (usually a server rather than a client) if it 591 perceives that a stream-level error has occurred. 593 4.6.1 Rules 595 The following rules apply to stream-level errors: 597 o It is assumed that all stream-level errors are unrecoverable; 598 therefore, if an error occurs at the level of the stream, the 599 entity that detects the error MUST send a stream error to the 600 other entity, send a closing tag, and terminate the 601 underlying TCP connection. 603 o If the error occurs while the stream is being set up, the 604 receiving entity MUST still send the opening tag, include 605 the element as a child of the stream element, send the 606 closing tag, and terminate the underlying TCP 607 connection. In this case, if the initiating entity provides an 608 unknown host in the 'to' attribute (or provides no 'to' attribute 609 at all), the server SHOULD provide the server's authoritative 610 hostname in the 'from' attribute of the stream header sent before 611 termination. 613 4.6.2 Syntax 615 The syntax for stream errors is as follows: 617 618 619 620 OPTIONAL descriptive text 621 622 [OPTIONAL application-specific condition element] 624 626 The element: 628 o MUST contain a child element corresponding to one of the defined 629 stanza error conditions defined below; this element MUST be 630 qualified by the 'urn:ietf:params:xml:ns:xmpp-streamstreams' 631 namespace 633 o MAY contain a child containing CDATA that describes the 634 error in more detail; this element MUST be qualified by the 635 'urn:ietf:params:xml:ns:xmpp-streams' namespace and SHOULD possess 636 an 'xml:lang' attribute 638 o MAY contain a child element for an application-specific error 639 condition; this element MUST be qualified by an 640 application-defined namespace, and its structure is defined by 641 that namespace 643 The element is OPTIONAL. If included, it SHOULD be used only 644 to provide descriptive or diagnostic information that supplements the 645 meaning of a defined condition or application-specific condition. It 646 SHOULD NOT be interpreted programmatically by an application. It 647 SHOULD NOT be used as the error message presented to user, but MAY be 648 shown in addition to the error message associated with the included 649 condition element (or elements). 651 Note: the XML namespace name 'urn:ietf:params:xml:ns:xmpp-streams' 652 that qualifies the descriptive element adheres to the format defined 653 in The IETF XML Registry [26]. 655 4.6.3 Defined Conditions 657 The following stream-level error conditions are defined: 659 o -- the server is closing the active stream for this 660 entity because a new stream has been initiated that conflicts with 661 the existing stream. 663 o -- the entity has not generated any traffic 664 over the stream for some period of time (configurable according to 665 a local service policy). 667 o -- the value of the 'to' attribute provided by the 668 initiating entity in the stream header corresponds to a hostname 669 that is no longer hosted by the server. 671 o -- the value of the 'to' attribute provided by the 672 initiating entity in the stream header does not correspond to a 673 hostname that is hosted by the server. 675 o -- a stanza sent between two servers lacks 676 a 'to' or 'from' attribute (or the attribute has no value). 678 o -- the server has experienced a 679 misconfiguration or an otherwise-undefined internal error that 680 prevents it from servicing the stream. 682 o -- the stream ID or dialback ID is invalid or does 683 not match an ID previously provided. 685 o -- the stream namespace name is something 686 other than "http://etherx.jabber.org/streams" or the dialback 687 namespace name is something other than "jabber:server:dialback". 689 o -- the hostname provided in a 'from' address 690 does not match the hostname (or other validated domain) negotiated 691 via SASL or dialback. 693 o -- the entity has attempted to send data before 694 authenticating, or otherwise is not authorized to perform an 695 action related to stream negotiation; the receiving entity SHOULD 696 silently drop the offending stanza and MUST NOT process it before 697 sending the stream error. 699 o -- the entity has violated some local service 700 policy; the server MAY choose to specify the policy in the 701 element. 703 o -- the server is unable to properly 704 connect to a remote resource that is required for authentication 705 or authorization. 707 o -- the server is resource-contrained and is 708 unable to service the stream. 710 o -- the server will not provide service to the 711 initiating entity but is redirecting traffic to another host; the 712 server SHOULD specify the alternate hostname or IP address in the 713 element. 715 o -- the server is being shut down and all active 716 streams are being closed. 718 o -- the error condition is not one of those 719 defined by the other conditions in this list; this error condition 720 SHOULD be used only in conjuction with an application-specific 721 condition. 723 o -- the initiating entity has encoded the 724 stream in an encoding that is not supported by the server. 726 o -- the initiating entity has sent a 727 first-level child of the stream that is not supported by the 728 server. 730 o -- the value of the 'version' attribute 731 provided by the initiating entity in the stream header specifies a 732 version of XMPP that is not supported by the server; the server 733 MAY specify the version(s) it supports in the element. 735 o -- the initiating entity has sent XML that 736 is not well-formed as defined by the XML specification [1]. 738 4.6.4 Application-Specific Conditions 740 As noted, an application MAY provide application-specific stream 741 error information by including a properly-namespaced child in the 742 error element. The application-specific element SHOULD supplement or 743 further qualify a defined element. Thus the element will 744 contain two or three child elements: 746 747 749 750 Some special application diagnostic information! 751 752 753 754 756 4.7 Simple Streams Example 758 The following is a stream-based session of a client on a server 759 (where the "C" lines are sent from the client to the server, and the 760 "S" lines are sent from the server to the client): 762 A basic session: 764 C: 765 770 S: 771 777 ... authentication ... 778 C: 781 C: Art thou not Romeo, and a Montague? 782 C: 783 S: 786 S: Neither, fair saint, if either thee dislike. 787 S: 788 C: 789 S: 791 A stream gone bad: 793 C: 794 799 S: 800 806 ... authentication ... 807 C: 808 Bad XML, no closing body tag! 809 810 S: 811 813 815 S: 817 5. Stream Encryption 819 5.1 Overview 821 XMPP includes a method for securing the stream from tampering and 822 eavesdropping. This channel encryption method makes use of the 823 Transport Layer Security (TLS) [13] protocol, along with a "STARTTLS" 824 extension that is modelled after similar extensions for the IMAP 825 [27], POP3 [28], and ACAP [29] protocols as described in RFC 2595 826 [30]. The namespace name for the STARTTLS extension is 827 'urn:ietf:params:xml:ns:xmpp-tls', which adheres to the format 828 defined in The IETF XML Registry [26]. 830 An administrator of a given domain MAY require the use of TLS for 831 client-to-server communications, server-to-server communications, or 832 both. Servers SHOULD use TLS betweeen two domains for the purpose of 833 securing server-to-server communications. See Mandatory to Implement 834 Technologies (Section 12.6) regarding mechanisms that MUST be 835 supported. 837 The following rules apply: 839 1. An initiating entity that complies with this specification MUST 840 include the 'version' attribute set to a value of "1.0" in the 841 initiating stream header. 843 2. If the TLS negotiation occurs between two servers, 844 communications MUST NOT proceed until the DNS hostnames asserted 845 by the servers have been resolved (see Server-to-Server 846 Communications (Section 12.3)). 848 3. When a receiving entity that complies with this specification 849 receives an initiating stream header that includes the 'version' 850 attribute set to a value of "1.0", after sending a stream header 851 in reply (including the version flag) it MUST include a 852 element (qualified by the 853 'urn:ietf:params:xml:ns:xmpp-tls' namespace) along with the list 854 of other stream features it supports. 856 4. If the initiating entity chooses to use TLS for stream 857 encryption, TLS negotiation MUST be completed before proceeding 858 to SASL negotiation. 860 5. The receiving entity MUST consider the TLS negotiation to have 861 begun immediately after sending the closing ">" of the element. The initiating entity MUST consider the TLS 863 negotiation to have begun immediately after receiving the 864 closing ">" of the element from the receiving entity. 866 6. The initiating entity MUST validate the certificate presented by 867 the receiving entity; there are two cases: 869 Case 1 -- The initiating entity has been configured with a set 870 of trusted root certificates: Normal certificate validation 871 processing is appropriate, and SHOULD follow the rules 872 defined for HTTP over TLS [14]. The trusted roots may be 873 either a well-known public set or a manually configured Root 874 CA (e.g., an organization's own Certificate Authority or a 875 self-signed Root CA for the service as described under High 876 Security (Section 12.1)). This case is RECOMMENDED. 878 Case 2 -- The initiating entity has been configured with the 879 receiving entity's self-signed service certificate: Simple 880 comparison of public keys is appropriate. This case is NOT 881 RECOMMENDED (see High Security (Section 12.1) for details). 883 If the above methods fail, the certificate SHOULD be presented 884 to a human (e.g., an end user or server administrator) for 885 approval; if presented, the receiver MUST deliver the entire 886 certificate chain to the human, who SHOULD be given the option 887 to store the Root CA certificate (not the service or End Entity 888 certificate) and to not be queried again regarding acceptance of 889 the certificate for some reasonable period of time. 891 7. If the TLS negotiation is successful, the receiving entity MUST 892 discard any knowledge obtained from the initiating entity before 893 TLS takes effect. 895 8. If the TLS negotiation is successful, the initiating entity MUST 896 discard any knowledge obtained from the receiving entity before 897 TLS takes effect. 899 9. If the TLS negotiation is successful, the receiving entity MUST 900 NOT offer the STARTTLS extension to the initiating entity along 901 with the other stream features that are offered when the stream 902 is restarted. 904 10. If the TLS negotiation is successful, the initiating entity 905 SHOULD continue with SASL negotiation. 907 11. If the TLS negotiation results in failure, the receiving entity 908 MUST terminate both the XML stream and the underlying TCP 909 connection. 911 5.2 Narrative 913 When an initiating entity secures a stream with a receiving entity, 914 the steps involved are as follows: 916 1. The initiating entity opens a TCP connection and initiates the 917 stream by sending the opening XML stream header to the receiving 918 entity, including the 'version' attribute set to a value of 919 "1.0". 921 2. The receiving entity responds by opening a TCP connection and 922 sending an XML stream header to the initiating entity, including 923 the 'version' attribute set to a value of "1.0". 925 3. The receiving entity offers the STARTTLS extension to the 926 initiating entity by including it with the list of other 927 supported stream features (if TLS is required for interaction 928 with the receiving entity, it SHOULD signal that fact by 929 including a element as a child of the 930 element). 932 4. The initiating entity issues the STARTTLS command (i.e., a 933 element qualified by the 934 'urn:ietf:params:xml:ns:xmpp-tls' namespace) to instruct the 935 receiving entity that it wishes to begin a TLS negotiation to 936 secure the stream. 938 5. The receiving entity MUST reply with either a element 939 or a element qualified by the 940 'urn:ietf:params:xml:ns:xmpp-tls' namespace. If the failure case 941 occurs, the receiving entity MUST terminate both the XML stream 942 and the underlying TCP connection. If the proceed case occurs, 943 the receiving entity MUST ignore any further XML data sent over 944 the XML stream but keep the underlying TCP connection open for 945 the purpose of completing the TLS negotiation. 947 6. The initiating entity and receiving entity attempt to complete a 948 TLS negotiation in accordance with RFC 2246 [13]. 950 7. If the TLS negotiation is unsuccessful, the receiving entity MUST 951 terminate the TCP connection. If the TLS negotiation is 952 successful, the initiating entity MUST initiate a new stream by 953 sending an opening XML stream header to the receiving entity. 955 8. Upon receiving the new stream header from the initiating entity, 956 the receiving entity MUST respond by sending a new XML stream 957 header to the initiating entity along with the remaining 958 available features (but NOT including the STARTTLS feature). 960 5.3 Client-to-Server Example 962 The following example shows the data flow for a client securing a 963 stream using STARTTLS (the IANA-registered port 5222 SHOULD be used; 964 see IANA Considerations (Section 10)). 966 Step 1: Client initiates stream to server: 968 974 Step 2: Server responds by sending a stream tag to client: 976 983 Step 3: Server sends the STARTTLS extension to client along with 984 authentication mechanisms and any other stream features: 986 987 988 989 990 991 DIGEST-MD5 992 PLAIN 993 994 996 Step 4: Client sends the STARTTLS command to server: 998 1000 Step 5: Server informs client to proceed: 1002 1004 Step 5 (alt): Server informs client that TLS negotiation has failed 1005 and closes both stream and TCP connection: 1007 1008 1010 Step 6: Client and server attempt to complete TLS negotiation over 1011 the existing TCP connection. 1013 Step 7: If TLS negotiation is successful, client initiates a new 1014 stream to server: 1016 1022 Step 7 (alt): If TLS negotiation is unsuccessful, server MUST close 1023 TCP connection. 1025 Step 8: Server responds by sending a stream header to client along 1026 with any remaining negotiable stream features: 1028 1034 1035 1036 DIGEST-MD5 1037 PLAIN 1038 EXTERNAL 1039 1040 1042 Step 9: Client SHOULD continue with Stream Authentication (Section 1043 6). 1045 5.4 Server-to-Server Example 1047 The following example shows the data flow for two servers securing a 1048 stream using STARTTLS (the IANA-registered port 5269 SHOULD be used; 1049 see IANA Considerations (Section 10)). 1051 Step 1: Server1 initiates stream to Server2: 1053 1059 Step 2: Server2 responds by sending a stream tag to Server1: 1061 1068 Step 3: Server2 sends the STARTTLS extension to Server1 along with 1069 authentication mechanisms and any other stream features: 1071 1072 1073 1074 1075 1076 DIGEST-MD5 1077 KERBEROS_V4 1078 1079 1081 Step 4: Server1 sends the STARTTLS command to Server2: 1083 1085 Step 5: Server2 informs Server1 to proceed: 1087 1089 Step 5 (alt): Server2 informs Server1 that TLS negotiation has failed 1090 and closes stream: 1092 1093 1095 Step 6: Server1 and Server2 attempt to complete TLS negotiation via 1096 TCP. 1098 Step 7: If TLS negotiation is successful, Server1 initiates a new 1099 stream to Server2: 1101 1107 Step 7 (alt): If TLS negotiation is unsuccessful, server MUST close 1108 TCP connection. 1110 Step 8: Server2 responds by sending a stream header to Server1 along 1111 with any remaining negotiable stream features: 1113 1119 1120 1121 DIGEST-MD5 1122 KERBEROS_V4 1123 EXTERNAL 1124 1125 1127 Step 9: Server1 SHOULD continue with Stream Authentication (Section 1128 6). 1130 6. Stream Authentication 1132 6.1 Overview 1134 XMPP includes a method for authenticating a stream using an XMPP 1135 adaptation of the Simple Authentication and Security Layer (SASL) 1136 [15]. SASL provides a generalized method for adding authentication 1137 support to connection-based protocols, and XMPP uses a generic XML 1138 namespace profile for SASL that conforms to section 4 ("Profiling 1139 Requirements") of RFC 2222 [15] (the XMPP-specific namespace name is 1140 'urn:ietf:params:xml:ns:xmpp-sasl', which adheres to the format 1141 defined in The IETF XML Registry [26]). Finally, see Mandatory to 1142 Implement Technologies (Section 12.6) regarding mechanisms that MUST 1143 be supported. 1145 The following rules apply: 1147 1. If the SASL negotiation occurs between two servers, 1148 communications MUST NOT proceed until the DNS hostnames asserted 1149 by the servers have been resolved (see Server-to-Server 1150 Communications (Section 12.3)). 1152 2. If TLS is used for stream encryption, SASL SHOULD NOT be used for 1153 anything except stream authentication (i.e., a security layer 1154 SHOULD NOT be negotiated using SASL). Conversely, if a security 1155 layer is to be negotiated via SASL, TLS SHOULD NOT be used. 1157 3. If the initiating entity is capable of authenticating via SASL, 1158 it MUST include the 'version' attribute set to a value of "1.0" 1159 in the initiating stream header. 1161 4. If the receiving entity is capable of negotiating authentication 1162 via SASL, it MUST send one or more authentication mechanisms 1163 within a element qualified by the 1164 'urn:ietf:params:xml:ns:xmpp-sasl' namespace in response to the 1165 opening stream tag received from the initiating entity (if the 1166 opening stream tag included the 'version' attribute set to a 1167 value of "1.0"). 1169 5. Upon successful SASL negotiation that involves negotiation of a 1170 security layer, the receiving entity MUST discard any knowledge 1171 obtained from the initiating entity which was not obtained from 1172 the SASL negotiation itself. 1174 6. Upon successful SASL negotiation that involves negotiation of a 1175 security layer, the initiating entity MUST discard any knowledge 1176 obtained from the receiving entity which was not obtained from 1177 the SASL negotiation itself. 1179 7. The initiating entity MUST provide an authzid during SASL 1180 negotiation. The authzid-value MUST be a valid JID of the form 1181 (i.e., a domain identifier only) for servers and of the 1182 form (i.e., node identifier, domain 1183 identifier, and resource identifier) for clients. The initiating 1184 entity MAY process the authzid-value in accordance with the rules 1185 defined in Addressing Scheme (Section 3) before providing it to 1186 the receiving entity, but is NOT REQUIRED to do so; however, the 1187 receiving entity MUST verify that the authzid-value provided by 1188 the initiating entity conforms to the rules defined therein. 1190 8. Any character data contained within the XML elements used during 1191 SASL negotiation MUST be encoded using base64. 1193 6.2 Narrative 1195 When an initiating entity authenticates with a receiving entity, the 1196 steps involved are as follows: 1198 1. The initiating entity requests SASL authentication by including 1199 the 'version' attribute in the opening XML stream header sent to 1200 the receiving entity, with the value set to "1.0". 1202 2. After sending an XML stream header in response, the receiving 1203 entity sends a list of available SASL authentication mechanisms; 1204 each of these is a element included as a child 1205 within a container element qualified by the 1206 'urn:ietf:params:xml:ns:xmpp-sasl' namespace, which in turn is a 1207 child of a element in the streams namespace. If 1208 channel encryption needs to be established before a particular 1209 authentication mechanism may be used, the receiving entity MUST 1210 NOT provide that mechanism in the list of available SASL 1211 authentication methods prior to channel encryption. If the 1212 initiating entity presents a valid certificate during prior TLS 1213 negotiation, the receiving entity MAY offer the SASL EXTERNAL 1214 mechanism to the initiating entity during stream authentication 1215 (refer to RFC 2222 [15]). 1217 3. The initiating entity selects a mechanism by sending an 1218 element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' 1219 namespace to the receiving entity and including an appropriate 1220 value for the 'mechanism' attribute; this element MAY optionally 1221 contain character data (in SASL terminology the "initial 1222 response") if the mechanism supports or requires it. If the 1223 initiating entity selects the EXTERNAL mechanism for 1224 authentication, the authentication credentials shall be taken 1225 from the certificate presented during prior TLS negotiation. 1227 4. If necessary, the receiving entity challenges the initiating 1228 entity by sending a element qualified by the 1229 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating 1230 entity; this element MAY optionally contain character data (which 1231 MUST be computed in accordance with the SASL mechanism chosen by 1232 the initiating entity). 1234 5. The initiating entity responds to the challenge by sending a 1235 element qualified by the 1236 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the receiving 1237 entity; this element MAY optionally contain character data (which 1238 MUST be computed in accordance with the SASL mechanism chosen by 1239 the initiating entity). 1241 6. If necessary, the receiving entity sends more challenges and the 1242 initiating entity sends more responses. 1244 This series of challenge/response pairs continues until one of three 1245 things happens: 1247 1. The initiating entity aborts the handshake by sending an 1248 element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' 1249 namespace to the receiving entity. Upon receiving the 1250 element, the receiving entity MUST terminate the TCP connection. 1252 2. The receiving entity reports failure of the handshake by sending 1253 a element qualified by the 1254 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating 1255 entity (the particular cause of failure SHOULD be communicated in 1256 an appropriate child element of the element as defined 1257 under SASL Errors (Section 6.3)). Immediately after sending the 1258 element, the receiving entity MUST terminate both the 1259 XML stream and the underlying TCP connection. 1261 3. The receiving entity reports success of the handshake by sending 1262 a element qualified by the 1263 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating 1264 entity; this element MAY optionally contain character data (in 1265 SASL terminology "additional data with success"). Upon receiving 1266 the element, the initiating entity MUST initiate a new 1267 stream by sending an opening XML stream header to the receiving 1268 entity (it is not necessary to send a closing 1269 element first, since the receiving entity and initiating entity 1270 MUST consider the original stream to be closed upon sending or 1271 receiving the element). Upon receiving the new stream 1272 header from the initiating entity, the receiving entity MUST 1273 respond by sending a new XML stream header to the initiating 1274 entity, along with any remaining available features (but NOT 1275 including the STARTTLS feature or any authentication mechanisms) 1276 or an empty features element (to signify that no additional 1277 features are available); note that any such additional features 1278 are not defined herein, and MUST be defined by the relevant 1279 extension to XMPP. 1281 6.3 SASL Errors 1283 The following SASL-related error conditions are defined: 1285 o -- The receiving entity acknowledges an 1286 element sent by the initiating entity; sent in response to the 1287 element. 1289 o -- The data provided by the initiating entity 1290 could not be processed, e.g. because does not adhere to the 1291 protocol for the requested mechanism; sent in response to the 1292 element. 1294 o -- The mechanism chosen by the initiating 1295 entity may be used only if the stream is already encrypted; sent 1296 in response to the element. 1298 o -- The authzid provided by the initiating 1299 entity is invalid, either because it is incorrectly formatted or 1300 because the initiating entity does not have permissions to 1301 authorize that ID; sent in response to a element. 1303 o -- The initiating entity did not provide a 1304 mechanism or requested a mechanism that is not supported by the 1305 receiving entity; sent in response to the element. 1307 o -- The realm provided by the initiating entity 1308 (in mechanisms that support the concept of a realm) does not match 1309 one of the hostnames served by the receiving entity; sent in 1310 response to a element. 1312 o -- The mechanism requested by the initiating 1313 entity is weaker than server policy permits for that initiating 1314 entity; sent in response to the element. 1316 o -- The authentication failed because the 1317 initiating entity did not provide valid credentials (this includes 1318 the case of an unknown username); sent in response to a element. 1321 o -- The authentication failed because of 1322 a temporary error condition within the receiving entity; sent in 1323 response to an element or element. 1325 6.4 SASL Definition 1327 Section 4 of the SASL specification [15] requires that the following 1328 information be supplied by a protocol definition: 1330 service name: "xmpp" 1332 initiation sequence: After the initiating entity provides an opening 1333 XML stream header and the receiving entity replies in kind, the 1334 receiving entity provides a list of acceptable authentication 1335 methods. The initiating entity chooses one method from the list 1336 and sends it to the receiving entity as the value of the 1337 'mechanism' attribute possessed by an element, optionally 1338 including an initial response to avoid a round trip. 1340 exchange sequence: Challenges and responses are carried through the 1341 exchange of elements from receiving entity to 1342 initiating entity and elements from initiating entity 1343 to receiving entity. The receiving entity reports failure by 1344 sending a element and success by sending a 1345 element; the initiating entity aborts the exchange by sending an 1346 element. (All of these elements are qualified by the 1347 'urn:ietf:params:xml:ns:xmpp-sasl' namespace.) Upon successful 1348 negotiation, both sides consider the original XML stream closed 1349 and new headers are sent by both entities. 1351 security layer negotiation: The security layer takes effect 1352 immediately after sending the closing ">" character of the 1353 element for the server, and immediately after receiving 1354 the closing ">" character of the element for the client 1355 (this element is qualified by the 1356 'urn:ietf:params:xml:ns:xmpp-sasl' namespace). 1358 use of the authorization identity: The authorization identity is used 1359 by xmpp to denote the "full JID" () of a 1360 client or the sending domain of a server. 1362 6.5 Client-to-Server Example 1364 The following example shows the data flow for a client authenticating 1365 with a server using SASL (the IANA-registered port 5222 SHOULD be 1366 used; see IANA Considerations (Section 10)). 1368 Step 1: Client initiates stream to server: 1370 1376 Step 2: Server responds with a stream tag sent to client: 1378 1385 Step 3: Server informs client of available authentication mechanisms: 1387 1388 1389 DIGEST-MD5 1390 PLAIN 1391 1392 1394 Step 4: Client selects an authentication mechanism: 1396 1400 Step 5: Server sends a base64-encoded challenge to client: 1402 1403 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 1404 xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz 1405 1407 The decoded challenge is: 1409 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ 1410 qop="auth",charset=utf-8,algorithm=md5-sess 1412 Step 5 (alt): Server returns error to client: 1414 1415 1417 1418 1420 Step 6: Client responds to the challenge: 1422 1423 dXNlcm5hbWU9InJvYiIscmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik 1424 9BNk1HOXRFUUdtMmhoIixjbm9uY2U9Ik9BNk1IWGg2VnFUclJrIixuYz0w 1425 MDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJ4bXBwL2NhdGFjbHlzbS 1426 5jeCIscmVzcG9uc2U9ZDM4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZjIxNDNh 1427 ZjcsY2hhcnNldD11dGYtOCxhdXRoemlkPSJyb2JAY2F0YWNseXNtLmN4L2 1428 15UmVzb3VyY2Ui 1429 1431 The decoded response is: 1433 username="rob",realm="cataclysm.cx",\ 1434 nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\ 1435 nc=00000001,qop=auth,digest-uri="xmpp/cataclysm.cx",\ 1436 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8,\ 1437 authzid="rob@cataclysm.cx/myResource" 1439 Step 7: Server sends another challenge to client: 1441 1442 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 1443 1445 The decoded challenge is: 1447 rspauth=ea40f60335c427b5527b84dbabcdfffd 1449 Step 7 (alt): Server returns error to client: 1451 1452 1453 1454 1456 Step 8: Client responds to the challenge: 1458 1460 Step 9: Server informs client of successful authentication: 1462 1463 Step 9 (alt): Server informs client of failed authentication: 1465 1466 1467 1468 1470 Step 10: Client initiates a new stream to server: 1472 1478 Step 11: Server responds by sending a stream header to client along 1479 with any additional features (or an empty features element): 1481 1487 1489 6.6 Server-to-Server Example 1491 The following example shows the data flow for a server authenticating 1492 with another server using SASL (the IANA-registered port 5269 SHOULD 1493 be used; see IANA Considerations (Section 10)). 1495 Step 1: Server1 initiates stream to Server2: 1497 1503 Step 2: Server2 responds with a stream tag sent to Server1: 1505 1512 Step 3: Server2 informs Server1 of available authentication 1513 mechanisms: 1515 1516 1517 DIGEST-MD5 1518 KERBEROS_V4 1519 1520 1522 Step 4: Server1 selects an authentication mechanism: 1524 1528 Step 5: Server2 sends a base64-encoded challenge to Server1: 1530 1531 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 1532 xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz 1533 1535 The decoded challenge is: 1537 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ 1538 qop="auth",charset=utf-8,algorithm=md5-sess 1540 Step 5 (alt): Server2 returns error to Server1: 1542 1543 1544 1545 1547 Step 6: Server1 responds to the challenge: 1549 1550 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 1551 xjbm9uY2U9Ik9BNk1IWGg2VnFUclJrIixuYz0wMDAwMDAwMSxxb3A9YXV0 1552 aCxkaWdlc3QtdXJpPSJ4bXBwL2NhdGFjbHlzbS5jeCIscmVzcG9uc2U9ZD 1553 M4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcsY2hhcnNldD11dGYt 1554 OAo= 1555 1557 The decoded response is: 1559 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\ 1560 nc=00000001,qop=auth,digest-uri="xmpp/cataclysm.cx",\ 1561 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8 1563 Step 7: Server2 sends another challenge to Server1: 1565 1566 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 1567 1569 The decoded challenge is: 1571 rspauth=ea40f60335c427b5527b84dbabcdfffd 1573 Step 5 (alt): Server2 returns error to Server1: 1575 1576 1577 1578 1580 Step 8: Server1 responds to the challenge: 1582 1584 Step 9: Server2 informs Server1 of successful authentication: 1586 1588 Step 9 (alt): Server2 informs Server1 of failed authentication: 1590 1591 1592 1593 1595 Step 10: Server1 initiates a new stream to Server2: 1597 1603 Step 11: Server2 responds by sending a stream header to Server1 along 1604 with any additional features (or an empty features element): 1606 1612 1614 7. Server Dialback 1616 7.1 Overview 1618 The Jabber protocol from which XMPP was adapted includes a "server 1619 dialback" method for protecting against domain spoofing, thus making 1620 it more difficult to spoof XML stanzas (see Server-to-Server 1621 Communications (Section 12.3) regarding this method's security 1622 characteristics). Server dialback also makes it easier to deploy 1623 systems in which outbound messages and inbound messages are handled 1624 by different machines for the same domain. The server dialback method 1625 is made possible by the existence of DNS, since one server can 1626 (normally) discover the authoritative server for a given domain. 1628 Because dialback depends on the Domain Name System, inter-domain 1629 communications MUST NOT proceed until the DNS hostnames asserted by 1630 the servers have been resolved (see Server-to-Server Communications 1631 (Section 12.3)). 1633 The method for generating and verifying the keys used in server 1634 dialback MUST take into account the hostnames being used, the random 1635 ID generated for the stream, and a secret known by the authoritative 1636 server's network. 1638 Any error that occurs during dialback negotiation MUST be considered 1639 a stream error, resulting in termination of the stream and of the 1640 underlying TCP connection. The possible error conditions are 1641 specified in the protocol description below. 1643 The following terminology applies: 1645 o Originating Server -- the server that is attempting to establish a 1646 connection between two domains. 1648 o Receiving Server -- the server that is trying to authenticate that 1649 Originating Server represents the domain which it claims to be. 1651 o Authoritative Server -- the server that answers to the DNS 1652 hostname asserted by Originating Server; for basic environments 1653 this will be Originating Server, but it could be a separate 1654 machine in Originating Server's network. 1656 The following is a brief summary of the order of events in dialback: 1658 1. Originating Server establishes a connection to Receiving Server. 1660 2. Originating Server sends a 'key' value over the connection to 1661 Receiving Server. 1663 3. Receiving Server establishes a connection to Authoritative 1664 Server. 1666 4. Receiving Server sends the same 'key' value to Authoritative 1667 Server. 1669 5. Authoritative Server replies that key is valid or invalid. 1671 6. Receiving Server informs Originating Server whether it is 1672 authenticated or not. 1674 We can represent this flow of events graphically as follows: 1676 Originating Receiving 1677 Server Server 1678 ----------- --------- 1679 | | 1680 | establish connection | 1681 | ----------------------> | 1682 | | 1683 | send stream header | 1684 | ----------------------> | 1685 | | 1686 | send stream header | 1687 | <---------------------- | 1688 | | Authoritative 1689 | send dialback key | Server 1690 | ----------------------> | ------------- 1691 | | | 1692 | establish connection | 1693 | ----------------------> | 1694 | | 1695 | send stream header | 1696 | ----------------------> | 1697 | | 1698 | establish connection | 1699 | <---------------------- | 1700 | | 1701 | send stream header | 1702 | <---------------------- | 1703 | | 1704 | send dialback key | 1705 | ----------------------> | 1706 | | 1707 | validate dialback key | 1708 | <---------------------- | 1709 | 1710 | report dialback result | 1711 | <---------------------- | 1712 | | 1714 7.2 Protocol 1716 The interaction between the servers is as follows: 1718 1. Originating Server establishes TCP connection to Receiving 1719 Server. 1721 2. Originating Server sends a stream header to Receiving Server: 1723 1728 Note: the 'to' and 'from' attributes are NOT REQUIRED on the 1729 root stream element. The inclusion of the xmlns:db namespace 1730 declaration with the name shown indicates to Receiving Server 1731 that Originating Server supports dialback. If the namespace name 1732 is incorrect, then Receiving Server MUST generate an 1733 stream error condition and terminate both 1734 the XML stream and the underlying TCP connection. 1736 3. Receiving Server SHOULD send a stream header back to Originating 1737 Server, including a unique ID for this interaction: 1739 1745 Note: The 'to' and 'from' attributes are NOT REQUIRED on the 1746 root stream element. If the namespace name is incorrect, then 1747 Originating Server MUST generate an stream 1748 error condition and terminate both the XML stream and the 1749 underlying TCP connection. Note well that Receiving Server is 1750 NOT REQUIRED to reply and MAY silently terminate the XML stream 1751 and underlying TCP connection depending on security policies in 1752 place. 1754 4. Originating Server sends a dialback key to Receiving Server: 1756 1759 98AF014EDC0... 1760 1762 Note: this key is not examined by Receiving Server, since 1763 Receiving Server does not keep information about Originating 1764 Server between sessions. The key generated by Originating Server 1765 MUST be based in part on the value of the ID provided by 1766 Receiving Server in the previous step, and in part on a secret 1767 shared by Originating Server and Authoritative Server. If the 1768 value of the 'to' address does not match a hostname recognized 1769 by Receiving Server, then Receiving Server MUST generate a 1770 stream error condition and terminate both the 1771 XML stream and the underlying TCP connection. If the value of 1772 the 'from' address matches a domain with which Receiving Server 1773 already has an established connection, then Receiving Server 1774 MUST maintain the existing connection until it validates whether 1775 the new connection is legitimate; additionally, Receiving Server 1776 MAY choose to generate a stream error 1777 condition for the new connection and then terminate both the XML 1778 stream and the underlying TCP connection related to the new 1779 request. 1781 5. Receiving Server establishes a TCP connection back to the domain 1782 name asserted by Originating Server, as a result of which it 1783 connects to Authoritative Server. (Note: as an optimization, an 1784 implementation MAY reuse an existing trusted connection here 1785 rather than opening a new TCP connection.) 1787 6. Receiving Server sends Authoritative Server a stream header: 1789 1794 Note: the 'to' and 'from' attributes are NOT REQUIRED on the 1795 root stream element. If the namespace name is incorrect, then 1796 Authoritative Server MUST generate an 1797 stream error condition and terminate both the XML stream and the 1798 underlying TCP connection. 1800 7. Authoritative Server sends Receiving Server a stream header: 1802 1808 Note: if the namespace name is incorrect, then Receiving Server 1809 MUST generate an stream error condition and 1810 terminate both the XML stream and the underlying TCP connection 1811 between it and Authoritative Server. If the ID does not match 1812 that provided by Receiving Server in Step 3, then Receiving 1813 Server MUST generate an stream error condition and 1814 terminate both the XML stream and the underlying TCP connection 1815 between it and Authoritative Server. If either of the foregoing 1816 stream errors occurs between Receiving Server and Authoritative 1817 Server, then Receiving Server MUST generate a 1818 stream error condition and terminate 1819 both the XML stream and the underlying TCP connection between it 1820 and Originating Server. 1822 8. Receiving Server sends Authoritative Server a stanza requesting 1823 that Authoritative Server verify a key: 1825 1829 98AF014EDC0... 1830 1832 Note: passed here are the hostnames, the original identifier 1833 from Receiving Server's stream header to Originating Server in 1834 Step 3, and the key that Originating Server sent to Receiving 1835 Server in Step 4. Based on this information as well as shared 1836 secret information within the Authoritative Server's network, 1837 the key is verified. Any verifiable method MAY be used to 1838 generate the key. If the value of the 'to' address does not 1839 match a hostname recognized by Authoritative Server, then 1840 Authoritative Server MUST generate a stream 1841 error condition and terminate both the XML stream and the 1842 underlying TCP connection. If the value of the 'from' address 1843 does not match the hostname represented by Receiving Server when 1844 opening the TCP connection (or any validated domain), then 1845 Authoritative Server MUST generate a stream 1846 error condition and terminate both the XML stream and the 1847 underlying TCP connection. 1849 9. Authoritative Server sends a stanza back to Receiving Server 1850 verifying whether the key was valid or invalid: 1852 1858 or 1860 1866 Note: if the ID does not match that provided by Receiving Server 1867 in Step 3, then Receiving Server MUST generate an 1868 stream error condition and terminate both the XML stream and the 1869 underlying TCP connection. If the value of the 'to' address does 1870 not match a hostname recognized by Receiving Server, then 1871 Receiving Server MUST generate a stream error 1872 condition and terminate both the XML stream and the underlying 1873 TCP connection. If the value of the 'from' address does not 1874 match the hostname represented by Originating Server when 1875 opening the TCP connection (or any validated domain), then 1876 Receiving Server MUST generate a stream 1877 error condition and terminate both the XML stream and the 1878 underlying TCP connection. 1880 10. Receiving Server informs Originating Server of the result: 1882 1887 Note: At this point the connection has either been validated via 1888 a type='valid', or reported as invalid. If the connection is 1889 invalid, then Receiving Server MUST terminate both the XML 1890 stream and the underlying TCP connection. If the connection is 1891 validated, data can be sent by Originating Server and read by 1892 Receiving Server; before that, all data stanzas sent to 1893 Receiving Server SHOULD be silently dropped. 1895 Even if dialback negotiation is successful, a server MUST verify that 1896 all XML stanzas received from the other server include a 'from' 1897 attribute and a 'to' attribute; if a stanza does not meet this 1898 restriction, the server that receives the stanza MUST generate an 1899 stream error condition and terminate both the 1900 XML stream and the underlying TCP connection. Furthermore, a server 1901 MUST verify that the 'from' attribute of stanzas received from the 1902 other server includes a validated domain for the stream; if a stanza 1903 does not meet this restriction, the server that receives the stanza 1904 MUST generate a stream error condition and 1905 terminate both the XML stream and the underlying TCP connection. Both 1906 of these checks help to prevent spoofing related to particular 1907 stanzas. 1909 8. XML Stanzas 1911 8.1 Overview 1913 Once XML streams in both directions have been authenticated and (if 1914 desired) encrypted, XML stanzas can be sent over the streams. Three 1915 XML stanza types are defined for the 'jabber:client' and 1916 'jabber:server' namespaces: , , and . 1918 In essence, the stanza type can be seen as a "push" 1919 mechanism whereby one entity pushes information to another entity, 1920 similar to the communications that occur in a system such as email. 1921 The element can be seen as a basic broadcast or 1922 "publish-subscribe" mechanism, whereby multiple entities receive 1923 information (in this case, presence information) about an entity to 1924 which they have subscribed. The element can be seen as a 1925 "request-response" mechanism similar to HTTP, whereby two entities 1926 can engage in a structured conversation using 'get' or 'set' requests 1927 and 'result' or 'error' responses. 1929 8.2 Common Attributes 1931 The following five attributes are common to message, presence, and IQ 1932 stanzas: 1934 8.2.1 to 1936 The 'to' attribute specifies the JID of the intended recipient for 1937 the stanza. 1939 In the 'jabber:client' namespace, a stanza SHOULD possess a 'to' 1940 attribute, although a stanza sent from a client to a server for 1941 handling by that server (e.g., presence sent to the server for 1942 broadcasting to other entities) SHOULD NOT possess a 'to' attribute. 1944 In the 'jabber:server' namespace, a stanza MUST possess a 'to' 1945 attribute; if a server receives a stanza that does not meet this 1946 restriction, it MUST generate an stream error 1947 condition and terminate both the XML stream and the underlying TCP 1948 connection with the offending server. 1950 If the value of the 'to' attribute is invalid or cannot be contacted, 1951 the entity discovering that fact (usually the sender's or recipient's 1952 server) MUST return an appropriate error to the sender. 1954 8.2.2 from 1956 The 'from' attribute specifies the JID of the sender. 1958 In the 'jabber:client' namespace, a client MUST NOT include a 'from' 1959 attribute on the stanzas it sends to a server; if a server receives 1960 an XML stanza from a client and the stanza possesses a 'from' 1961 attribute, it MUST ignore the value of the 'from' attribute and MAY 1962 return an error to the sender. When a client sends an XML stanza 1963 within the context of an authenticated stream, the server MUST stamp 1964 the stanza with the full JID () of the 1965 connected resource that generated the stanza as defined by the 1966 authzid provided in the SASL negotiation. If a client attempts to 1967 send an XML stanza before the stream is authenticated, the server 1968 SHOULD return a stream error to the client and then 1969 terminate both the XML stream and the underlying TCP connection. 1971 In the 'jabber:server' namespace, a stanza MUST possess a 'from' 1972 attribute; if a server receives a stanza that does not meet this 1973 restriction, it MUST generate an stream error 1974 condition. Furthermore, the domain identifier portion of the JID 1975 contained in the 'from' attribute MUST match the hostname of the 1976 sending server (or any validated domain) as communicated in the SASL 1977 negotiation or dialback negotiation; if a server receives a stanza 1978 that does not meet this restriction, it MUST generate a 1979 stream error condition. Both of these conditions 1980 MUST result in closing of the stream and termination of the 1981 underlying TCP connection. 1983 8.2.3 id 1985 The optional 'id' attribute MAY be used by a sending entity for 1986 internal tracking of stanzas that it sends and receives (especially 1987 for tracking the request-response interaction inherent in the use of 1988 IQ stanzas). The 'id' attribute is required for IQ stanzas. If the 1989 stanza sent by the sending entity is an IQ stanza of type "get" or 1990 "set", the receiving entity MUST include an 'id' attribute with the 1991 same value in any replies of type "result" or "error". The value of 1992 the 'id' attribute is NOT REQUIRED to be unique either globally, 1993 within a domain, or within a stream. 1995 8.2.4 type 1997 The 'type' attribute specifies detailed information about the purpose 1998 or context of the message, presence, or IQ stanza. The particular 1999 allowable values for the 'type' attribute vary depending on whether 2000 the stanza is a message, presence, or IQ, and thus are defined in the 2001 following sections. 2003 8.2.5 xml:lang 2005 A stanza SHOULD possess an 'xml:lang' attribute (as defined in 2006 Section 2.12 of the XML specification [1]) if the stanza contains XML 2007 character data that is intended to be presented to a human user (as 2008 explained in RFC 2277 [20], "internationalization is for humans"). 2009 The value of the 'xml:lang' attribute specifies the default language 2010 of any such XML character data, which MAY be overridden by the 2011 'xml:lang' attribute of a specific child element. The value of the 2012 attribute MUST be an NMTOKEN and MUST conform to the format defined 2013 in RFC 3066 [17]. 2015 8.3 Message Stanzas 2017 Message stanzas in the 'jabber:client' or 'jabber:server' namespace 2018 are used to "push" information to another entity. Common uses in the 2019 context of instant messaging include single messages, messages sent 2020 in the context of a chat conversation, messages sent in the context 2021 of a multi-user chat room, headlines, and errors. 2023 8.3.1 Types of Message 2025 The 'type' attribute of a message stanza is RECOMMENDED; if included, 2026 it specifies the conversational context of the message. The 'type' 2027 attribute SHOULD have one of the following values: 2029 o chat 2031 o error 2033 o groupchat 2035 o headline 2037 o normal 2039 A message stanza with a different value, or without a 'type' 2040 attribute, SHOULD be handled as if the 'type' were "normal". 2042 For information regarding the meaning of these message types in the 2043 context of XMPP-based instant messaging and presence applications, 2044 refer to XMPP IM [24]. 2046 8.3.2 Children 2048 As described under extended namespaces (Section 8.6), a message 2049 stanza MAY contain any properly-namespaced child element. 2051 In accordance with the default namespace declaration, by default a 2052 message stanza is in the 'jabber:client' or 'jabber:server' 2053 namespace, which defines certain allowable children of message 2054 stanzas. If the message stanza is of type "error", it MUST include an 2055 child; for details, see Stanza Errors (Section 8.7). 2056 Otherwise, the message stanza MAY contain any of the following child 2057 elements without an explicit namespace declaration: 2059 1. 2061 2. 2063 3. 2065 8.3.2.1 Subject 2067 The element specifies the topic of the message. The 2068 element SHOULD NOT possess any attributes, with the 2069 exception of the 'xml:lang' attribute. Multiple instances of the 2070 element MAY be included for the purpose of providing 2071 alternate versions of the same subject, but only if each instance 2072 possesses an 'xml:lang' attribute with a distinct language value. The 2073 element MUST NOT contain mixed content. 2075 8.3.2.2 Body 2077 The element contains the textual contents of the message; 2078 this child element is normally included but NOT REQUIRED. The 2079 element SHOULD NOT possess any attributes, with the exception of the 2080 'xml:lang' attribute. Multiple instances of the element MAY 2081 be included but only if each instance possesses an 'xml:lang' 2082 attribute with a distinct language value. The element MUST 2083 NOT contain mixed content. 2085 8.3.2.3 Thread 2087 The element contains a string that is generated by the 2088 sender and that SHOULD be copied back in replies; it is used for 2089 tracking a conversation thread (sometimes referred to as an "instant 2090 messaging session") between two entities. If used, it MUST be unique 2091 to that conversation thread within the stream and MUST be consistent 2092 throughout that conversation (a client that receives a message from 2093 the same full JID but with a different thread ID MUST assume that the 2094 message in question exists outside the context of the existing 2095 conversation thread). The use of the element is OPTIONAL 2096 and is not used to identify individual messages, only conversations. 2097 Only one element MAY be included in a message stanza, and 2098 it MUST NOT possess any attributes. The element MUST be 2099 treated as an opaque string by entities; no semantic meaning may be 2100 derived from it, and only exact comparisons may be made against it. 2102 The element MUST NOT contain mixed content. 2104 8.4 Presence Stanzas 2106 Presence stanzas are used in the 'jabber:client' or 'jabber:server' 2107 namespace to express an entity's current availability status (offline 2108 or online, along with various sub-states of the latter and optional 2109 user-defined descriptive text) and to communicate that status to 2110 other entities. Presence stanzas are also used to negotiate and 2111 manage subscriptions to the presence of other entities. 2113 8.4.1 Types of Presence 2115 The 'type' attribute of a presence stanza is OPTIONAL. A presence 2116 stanza that does not possess a 'type' attribute is used to signal to 2117 the server that the sender is online and available for communication. 2118 If included, the 'type' attribute specifies a lack of availability, a 2119 request to manage a subscription to another entity's presence, a 2120 request for another entity's current presence, or an error related to 2121 a previously-sent presence stanza. The 'type' attribute MAY have one 2122 of the following values: 2124 o unavailable -- Signals that the entity is no longer available for 2125 communication. 2127 o subscribe -- The sender wishes to subscribe to the recipient's 2128 presence. 2130 o subscribed -- The sender has allowed the recipient to receive 2131 their presence. 2133 o unsubscribe -- A notification that an entity is unsubscribing from 2134 another entity's presence. 2136 o unsubscribed -- The subscription request has been denied or a 2137 previously-granted subscription has been cancelled. 2139 o probe -- A request for an entity's current presence; in general, 2140 SHOULD NOT be sent by a client. 2142 o error -- An error has occurred regarding processing or delivery of 2143 a previously-sent presence stanza. 2145 For information regarding presence semantics and the subscription 2146 model used in the context of XMPP-based instant messaging and 2147 presence applications, refer to XMPP IM [24]. 2149 8.4.2 Children 2151 As described under extended namespaces (Section 8.6), a presence 2152 stanza MAY contain any properly-namespaced child element. 2154 In accordance with the default namespace declaration, by default a 2155 presence stanza is in the 'jabber:client' or 'jabber:server' 2156 namespace, which defines certain allowable children of presence 2157 stanzas. If the presence stanza is of type "error", it MUST include 2158 an child; for details, see Stanza Errors (Section 8.7). If 2159 the presence stanza possesses no 'type' attribute, it MAY contain any 2160 of the following child elements (note that the child MAY be 2161 sent in a presence stanza of type "unavailable" or, for historical 2162 reasons, "subscribe"): 2164 1. 2166 2. 2168 3. 2170 8.4.2.1 Show 2172 The OPTIONAL element specifies the particular availability 2173 status of an entity or specific resource (if a element is not 2174 provided, default availability is assumed). Only one element 2175 MAY be included in a presence stanza, and it SHOULD NOT possess any 2176 attributes. The CDATA value SHOULD be one of the following (values 2177 other than these four SHOULD be ignored; additional availability 2178 types could be defined through a properly-namespaced child element of 2179 the presence stanza): 2181 o away 2183 o chat 2185 o dnd 2187 o xa 2189 For information regarding the meaning of these values in the context 2190 of XMPP-based instant messaging and presence applications, refer to 2191 XMPP IM [24]. 2193 8.4.2.2 Status 2195 The OPTIONAL element contains a natural-language 2196 description of availability status. It is normally used in 2197 conjunction with the show element to provide a detailed description 2198 of an availability state (e.g., "In a meeting"). The 2199 element SHOULD NOT possess any attributes, with the exception of the 2200 'xml:lang' attribute. Multiple instances of the element MAY 2201 be included but only if each instance possesses an 'xml:lang' 2202 attribute with a distinct language value. 2204 8.4.2.3 Priority 2206 The OPTIONAL element specifies the priority level of the 2207 connected resource. The value may be any integer between -128 and 2208 +127. Only one element MAY be included in a presence 2209 stanza, and it MUST NOT possess any attributes. If no priority is 2210 provided, a server SHOULD consider the priority to be zero. For 2211 information regarding the semantics of priority values in stanza 2212 routing within instant messaging applications, refer to XMPP IM [24]. 2214 8.5 IQ Stanzas 2216 8.5.1 Overview 2218 Info/Query, or IQ, is a request-response mechanism, similar in some 2219 ways to HTTP [32]. IQ stanzas in the 'jabber:client' or 2220 'jabber:server' namespace enable an entity to make a request of, and 2221 receive a response from, another entity. The data content of the 2222 request and response is defined by the namespace declaration of a 2223 direct child element of the IQ element, and the interaction is 2224 tracked by the requesting entity through use of the 'id' attribute. 2226 Most IQ interactions follow a common pattern of structured data 2227 exchange such as get/result or set/result (although an error may be 2228 returned in response to a request if appropriate): 2230 Requesting Responding 2231 Entity Entity 2232 ---------- ---------- 2233 | | 2234 | | 2235 | ------------------------> | 2236 | | 2237 | | 2238 | <------------------------ | 2239 | | 2240 | | 2241 | ------------------------> | 2242 | | 2243 | | 2244 | <------------------------ | 2245 | | 2247 The 'id' attribute is REQUIRED for IQ stanzas. An entity that 2248 receives an IQ request of type "get" or "set" MUST reply with an IQ 2249 response of type "result" or "error" (which response MUST preserve 2250 the 'id' attribute of the request). An entity that receives a stanza 2251 of type "result" or "error" MUST NOT respond to the stanza by sending 2252 a further IQ response of type "result" or "error"; however, as shown 2253 above, the requesting entity MAY send another request (e.g., an IQ of 2254 type "set" in order to provide required information discovered 2255 through a get/result pair). 2257 8.5.2 Types of IQ 2259 The 'type' attribute of an IQ stanza is REQUIRED. The 'type' 2260 attribute specifies a distinct step within a request-response 2261 interaction. The value SHOULD be one of the following (all other 2262 values SHOULD be ignored): 2264 o get -- The stanza is a request for information or requirements. 2266 o set -- The stanza provides required data, sets new values, or 2267 replaces existing values. 2269 o result -- The stanza is a response to a successful get or set 2270 request. 2272 o error -- An error has occurred regarding processing or delivery of 2273 a previously-sent get or set. 2275 8.5.3 Children 2277 As described under extended namespaces (Section 8.6), an IQ stanza 2278 MAY contain any properly-namespaced child element. Note that an IQ 2279 stanza of type "get", "set", or "result" contains no children in the 2280 'jabber:client' or 'jabber:server' namespace since it is a vessel for 2281 XML in another namespace. 2283 An IQ stanza of type "get" or "set" MUST include one and only one 2284 child element. An IQ stanza of type "result" MUST include zero or one 2285 child elements. An IQ stanza of type "error" SHOULD include the child 2286 element contained in the associated "get" or "set" and MUST include 2287 an child; for details, see Stanza Errors (Section 8.7). 2289 8.6 Extended Namespaces 2290 While the three XML stanza types defined in the "jabber:client" or 2291 "jabber:server" namespace (along with their attributes and child 2292 elements) provide a basic level of functionality for messaging and 2293 presence, XMPP uses XML namespaces to extend the stanzas for the 2294 purpose of providing additional functionality. Thus a message, 2295 presence, or IQ stanza MAY house one or more optional child elements 2296 containing content that extends the meaning of the message (e.g., an 2297 XHTML-formatted version of the message body). This child element MAY 2298 have any name and MUST possess an 'xmlns' namespace declaration 2299 (other than "jabber:client", "jabber:server", or "http:// 2300 etherx.jabber.org/streams") that defines all data contained within 2301 the child element. 2303 Support for any given extended namespace is OPTIONAL on the part of 2304 any implementation. If an entity does not understand such a 2305 namespace, the entity's expected behavior depends on whether the 2306 entity is (1) the recipient or (2) an entity that is routing the 2307 stanza to the recipient: 2309 Recipient: If a recipient receives a stanza that contains a child 2310 element it does not understand, it SHOULD ignore that specific XML 2311 data, i.e., it SHOULD not process it or present it to a user or 2312 associated application (if any). In particular: 2314 * If an entity receives a message or presence stanza that 2315 contains XML data qualified by a namespace it does not 2316 understand, the portion of the stanza that is in the unknown 2317 namespace SHOULD be ignored. 2319 * If an entity receives a message stanza containing only a child 2320 element qualified by a namespace it does not understand, it 2321 MUST ignore the entire stanza. 2323 * If an entity receives an IQ stanza of type "get" or "set" 2324 containing a child element qualified by a namespace it does not 2325 understand, the entity SHOULD return an IQ stanza of type 2326 "error" with an error condition of . 2328 Router: If a routing entity (usually a server) handles a stanza that 2329 contains a child element it does not understand, it SHOULD ignore 2330 the associated XML data by passing it on untouched to the 2331 recipient. 2333 8.7 Stanza Errors 2335 Stanza-related errors are handled in a manner similar to stream 2336 errors (Section 4.6), except that hints are also provided to the 2337 receiving application regarding actions to take in reponse to the 2338 error. 2340 8.7.1 Rules 2342 The following rules apply to stanza-related errors: 2344 o A stanza whose 'type' attribute has a value of "error" MUST 2345 contain an child element. 2347 o The receiving or processing entity that returns an error to the 2348 sending entity SHOULD include the original XML sent so that the 2349 sender can inspect and if necessary correct the XML before 2350 re-sending. 2352 o An entity that receives a stanza whose 'type' attribute has a 2353 value of "error" MUST NOT respond to the stanza with a further 2354 stanza of type "error"; this helps to prevent looping. 2356 o An child MUST NOT be included if the 'type' attribute has 2357 a value other than "error" (or if there is no 'type' attribute). 2359 8.7.2 Syntax 2361 The syntax for stanza-related errors is as follows: 2363 2364 [RECOMMENDED to include sender XML here] 2365 2366 2367 2368 OPTIONAL descriptive text 2369 2370 [OPTIONAL application-specific condition element] 2371 2372 2374 The stanza-name is one of message, presence, or iq. 2376 The value of the element's 'type' attribute MUST be one of 2377 the following: 2379 o cancel -- do not retry (the error is unrecoverable) 2381 o continue -- proceed (the condition was only a warning) 2383 o modify -- retry after changing the data sent 2384 o auth -- retry after providing credentials 2386 o wait -- retry after waiting (the error is temporary) 2388 The element: 2390 o MUST contain a child element corresponding to one of the defined 2391 stanza error conditions defined below; this element MUST be 2392 qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace 2394 o MAY contain a child containing CDATA that describes the 2395 error in more detail; this element MUST be qualified by the 2396 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace and SHOULD possess 2397 an 'xml:lang' attribute 2399 o MAY contain a child element for an application-specific error 2400 condition; this element MUST be qualified by an 2401 application-defined namespace, and its structure is defined by 2402 that namespace 2404 The element is OPTIONAL. If included, it SHOULD be used only 2405 to provide descriptive or diagnostic information that supplements the 2406 meaning of a defined condition or application-specific condition. It 2407 SHOULD NOT be interpreted programmatically by an application. It 2408 SHOULD NOT be used as the error message presented to user, but MAY be 2409 shown in addition to the error message associated with the included 2410 condition element (or elements). 2412 Note: the XML namespace name 'urn:ietf:params:xml:ns:xmpp-stanzas' 2413 that qualifies the descriptive element adheres to the format defined 2414 in The IETF XML Registry [26]. 2416 8.7.3 Defined Conditions 2418 The following stanza-related error conditions are defined for use in 2419 stanza errors. 2421 o -- the sender has sent XML that is malformed or 2422 that cannot be processed (e.g., a client-generated stanza includes 2423 a 'from' address, or an IQ stanza includes an unrecognized value 2424 of the 'type' attribute); the associated error type SHOULD be 2425 "modify". 2427 o -- access cannot be granted because an existing 2428 resource or session exists with the same name or address; the 2429 associated error type SHOULD be "cancel". 2431 o -- the feature requested is not 2432 implemented by the recipient or server and therefore cannot be 2433 processed; the associated error type SHOULD be "cancel". 2435 o -- the requesting entity does not possess the 2436 required permissions to perform the action; the associated error 2437 type SHOULD be "auth". 2439 o -- the server could not process the 2440 stanza because of a misconfiguration or an otherwise-undefined 2441 internal server error; the associated error type SHOULD be "wait". 2443 o -- the addressed JID or item requested cannot be 2444 found; the associated error type SHOULD be "cancel". 2446 o -- the value of the 'to' attribute in the 2447 sender's stanza does not adhere to the syntax defined in 2448 Addressing Scheme (Section 3); the associated error type SHOULD be 2449 "modify". 2451 o -- the recipient does not allow any entity to 2452 perform the action; the associated error type SHOULD be "cancel". 2454 o -- the user is not authorized to access the 2455 requested service because payment is required; the associated 2456 error type SHOULD be "auth". 2458 o -- the specific recipient requested is 2459 currently unavailable; the associated error type SHOULD be "wait". 2461 o -- the user is not authorized to access 2462 the requested service because registration is required; the 2463 associated error type SHOULD be "auth". 2465 o -- a remote server or service specified 2466 as part or all of the JID of the intended recipient does not 2467 exist; the associated error type SHOULD be "cancel". 2469 o -- a remote server or service specified 2470 as part or all of the JID of the intended recipient could not be 2471 contacted within a reasonable amount of time; the associated error 2472 type SHOULD be "wait". 2474 o -- the server is resource-contrained and is 2475 unable to service the request; the associated error type SHOULD be 2476 "wait". 2478 o -- the service requested is currently 2479 unavailable on the server; the associated error type SHOULD be 2480 "cancel". 2482 o -- the user is not authorized to access 2483 the requested service because a subscription is required; the 2484 associated error type SHOULD be "auth". 2486 o -- the error condition is not one of those 2487 defined by the other conditions in this list; any error type may 2488 be associated with this condition, and it SHOULD be used only in 2489 conjuction with an application-specific condition. 2491 o -- the recipient understood the request but 2492 was not expecting it at this time (e.g., the request was out of 2493 order); the associated error type SHOULD be "wait". 2495 8.7.4 Application-Specific Conditions 2497 As noted, an application MAY provide application-specific stanza 2498 error information by including a properly-namespaced child in the 2499 error element. The application-specific element SHOULD supplement or 2500 further qualify a defined element. Thus the element will 2501 contain two or three child elements: 2503 2504 2505 2506 2507 2508 2510 2511 2512 2513 2514 Some special application diagnostic information! 2515 2516 2517 2518 2520 9. XML Usage within XMPP 2522 9.1 Restrictions 2524 XMPP is a simplified and specialized protocol for streaming XML 2525 elements in order to exchange messages and presence information in 2526 close to real time. Because XMPP does not require the parsing of 2527 arbitrary and complete XML documents, there is no requirement that 2528 XMPP needs to support the full XML specification [1]. In particular, 2529 the following restrictions apply. 2531 With regard to XML generation, an XMPP implementation MUST NOT inject 2532 into an XML stream any of the following: 2534 o comments (as defined in Section 2.5 of the XML specification [1]) 2536 o processing instructions (Section 2.6) 2538 o internal or external DTD subsets (Section 2.8) 2540 o internal or external entity references (Section 4.2) with the 2541 exception of predefined entities (Section 4.6) 2543 o character data or attribute values containing unescaped characters 2544 that map to the predefined entities (Section 4.6); such characters 2545 MUST be escaped 2547 With regard to XML processing, if an XMPP implementation receives 2548 such restricted XML data, it MUST ignore the data. 2550 9.2 XML Namespace Names and Prefixes 2552 XML Namespaces [12] are used within all XMPP-compliant XML to create 2553 strict boundaries of data ownership. The basic function of namespaces 2554 is to separate different vocabularies of XML elements that are 2555 structurally mixed together. Ensuring that XMPP-compliant XML is 2556 namespace-aware enables any XML to be structurally mixed with any 2557 data element within XMPP. Rules for XML namespace names and prefixes 2558 are defined below. 2560 9.2.1 Stream Namespace 2562 A stream namespace declaration is REQUIRED in both XML stream 2563 headers. The name of the stream namespace MUST be 'http:// 2564 etherx.jabber.org/streams'. The element names of the 2565 element and its and children MUST be qualified 2566 by the stream namespace prefix in all instances. An implementation 2567 SHOULD generate only the 'stream:' prefix for these elements, and for 2568 historical reasons MAY accept only the 'stream:' prefix. 2570 9.2.2 Default Namespace 2572 A default namespace declaration is REQUIRED and is used in both XML 2573 streams in order to define the allowable first-level children of the 2574 root stream element. This namespace declaration MUST be the same for 2575 the initiating stream and the responding stream so that both streams 2576 are qualified consistently. The default namespace declaration applies 2577 to the stream and all stanzas sent within a stream (unless explicitly 2578 qualified by another namespace, or by the prefix of the stream 2579 namespace or the dialback namespace). 2581 A server implementation MUST support the following two default 2582 namespaces (for historical reasons, some implementations MAY support 2583 only these two default namespaces): 2585 o jabber:client -- this default namespace is declared when the 2586 stream is used for communications between a client and a server 2588 o jabber:server -- this default namespace is declared when the 2589 stream is used for communications between two servers 2591 A client implementation MUST support the 'jabber:client' default 2592 namespace, and for historical reasons MAY support only that default 2593 namespace. 2595 An implementation MUST NOT generate namespace prefixes for elements 2596 in the default namespace if the default namespace is 'jabber:client' 2597 or 'jabber:server'. An implementation SHOULD NOT generate namespace 2598 prefixes for elements qualified by "extended" namespaces as described 2599 under Extended Namespaces (Section 8.6). 2601 Note: the 'jabber:client' and 'jabber:server' namespaces are nearly 2602 identical but are used in different contexts (client-to-server 2603 communications for 'jabber:client' and server-to-server 2604 communications for 'jabber:server'). The only difference between the 2605 two is that the 'to' and 'from' attributes are OPTIONAL on stanzas 2606 sent within 'jabber:client', whereas they are REQUIRED on stanzas 2607 sent within 'jabber:server'. If a compliant implementation accepts a 2608 stream that is qualified by the 'jabber:client' or 'jabber:server' 2609 namespace, it MUST support all three core stanza types (message, 2610 presence, and IQ) as described herein and defined in the schema. 2612 9.2.3 Dialback Namespace 2614 A dialback namespace declaration is REQUIRED for all elements used in 2615 server dialback. The name of the dialback namespace MUST be 2616 'jabber:server:dialback'. All elements qualified by this namespace 2617 MUST be prefixed. An implementation SHOULD generate only the 'db:' 2618 prefix for such elements and MAY accept only the 'db:' prefix. 2620 9.3 Validation 2622 Except as noted with regard to 'to' and 'from' addresses for stanzas 2623 within the 'jabber:server' namespace, a server is not responsible for 2624 validating the XML elements forwarded to a client or another server; 2625 an implementation MAY choose to provide only validated data elements 2626 but is NOT REQUIRED to do so (although an implementation MUST NOT 2627 accept XML that is not well-formed). Clients SHOULD NOT rely on the 2628 ability to send data which does not conform to the schemas, and 2629 SHOULD ignore any non-conformant elements or attributes on the 2630 incoming XML stream. Validation of XML streams and stanzas is NOT 2631 REQUIRED or recommended, and schemas are included herein for 2632 descriptive purposes only. 2634 9.4 Inclusion of Text Declaration 2636 Implementations SHOULD send a text declaration before sending a 2637 stream header. Applications MUST follow the rules in the XML 2638 specification [1] regarding the circumstances under which a text 2639 declaration is included. 2641 9.5 Character Encodings 2643 Implementations MUST support UTF-8 (RFC 2279 [19]) as required by RFC 2644 2277 [20], and SHOULD support UTF-16 (RFC 2781 [21]) for the sake of 2645 efficiency in encoding certain writing systems. If the character 2646 encoding is not specified in a text declaration sent before the 2647 stream header, implementations SHOULD deduce the encoding as 2648 described in Appendix F of the XML specification [1]. If an 2649 initiating entity attempts to use an encoding that the receiving 2650 entity does not understand, the receiving entity MUST reply with an 2651 stream error. Note well that the encodings of 2652 the initial stream and response stream are independent, and MAY be 2653 different. 2655 10. IANA Considerations 2657 10.1 XML Namespace Name for TLS Data 2659 A URN sub-namespace for TLS-related data in the Extensible Messaging 2660 and Presence Protocol (XMPP) is defined as follows. 2662 URI: urn:ietf:params:xml:ns:xmpp-tls 2664 Specification: [RFCXXXX] 2666 Description: This is the XML namespace name for TLS-related data in 2667 the Extensible Messaging and Presence Protocol (XMPP) as defined 2668 by [RFCXXXX]. 2670 Registrant Contact: IETF, XMPP Working Group, 2672 10.2 XML Namespace Name for SASL Data 2674 A URN sub-namespace for SASL-related data in the Extensible Messaging 2675 and Presence Protocol (XMPP) is defined as follows. 2677 URI: urn:ietf:params:xml:ns:xmpp-sasl 2679 Specification: [RFCXXXX] 2681 Description: This is the XML namespace name for SASL-related data in 2682 the Extensible Messaging and Presence Protocol (XMPP) as defined 2683 by [RFCXXXX]. 2685 Registrant Contact: IETF, XMPP Working Group, 2687 10.3 XML Namespace Name for Stream Errors 2689 A URN sub-namespace for stream-related error data in the Extensible 2690 Messaging and Presence Protocol (XMPP) is defined as follows. 2692 URI: urn:ietf:params:xml:ns:xmpp-streams 2694 Specification: [RFCXXXX] 2696 Description: This is the XML namespace name for stream-related error 2697 data in the Extensible Messaging and Presence Protocol (XMPP) as 2698 defined by [RFCXXXX]. 2700 Registrant Contact: IETF, XMPP Working Group, 2702 10.4 XML Namespace Name for Stanza Errors 2704 A URN sub-namespace for stanza-related error data in the Extensible 2705 Messaging and Presence Protocol (XMPP) is defined as follows. 2707 URI: urn:ietf:params:xml:ns:xmpp-stanzas 2709 Specification: [RFCXXXX] 2711 Description: This is the XML namespace name for stanza-related error 2712 data in the Extensible Messaging and Presence Protocol (XMPP) as 2713 defined by [RFCXXXX]. 2715 Registrant Contact: IETF, XMPP Working Group, 2717 10.5 Existing Registrations 2719 The IANA registers "xmpp" as a GSSAPI [23] service name, as specified 2720 in SASL Definition (Section 6.4). 2722 Additionally, the IANA registers "jabber-client" and "jabber-server" 2723 as keywords for TCP ports 5222 and 5269 respectively. These ports 2724 SHOULD be used for client-to-server and server-to-server 2725 communications respectively, but their use is NOT REQUIRED. The use 2726 of the string "jabber" in these keywords is historical. 2728 11. Internationalization Considerations 2730 Each XML stanza SHOULD include an 'xml:lang' attribute. Servers MUST 2731 NOT modify or delete 'xml:lang' attributes from stanzas they receive 2732 from other entities. 2734 12. Security Considerations 2736 12.1 High Security 2738 For the purposes of XMPP communications (client-to-server and 2739 server-to-server), the term "high security" refers to the use of 2740 security technologies that provide both mutual authentication and 2741 integrity-checking; in particular, when using certificate-based 2742 authentication to provide high security, a chain-of-trust SHOULD be 2743 established out-of-band, although a shared certificate authority 2744 signing certificates could allow a previously unknown certificate to 2745 establish trust in-band. 2747 Standalone, self-signed service certificates SHOULD NOT be used; 2748 rather, an entity that wishes to generate a self-signed service 2749 certificate SHOULD first generate a self-signed Root CA certificate 2750 and then generate a signed service certificate. Entities that 2751 communicate with the service SHOULD be configured with the Root CA 2752 certificate rather than the service certificate; this avoids problems 2753 associated with simple comparison of service certificates. If a 2754 self-signed service certificate is used, an entity SHOULD NOT trust 2755 it if it is changed to another self-signed certificate or a 2756 certificate signed by an unrecognized authority. 2758 Implementations MUST support high security. Service provisioning 2759 SHOULD use high security, subject to local security policies. 2761 12.2 Client-to-Server Communications 2763 A compliant implementation MUST support both TLS and SASL for 2764 connections to a server. 2766 The TLS protocol for encrypting XML streams (defined under Stream 2767 Encryption (Section 5)) provides a reliable mechanism for helping to 2768 ensure the confidentiality and data integrity of data exchanged 2769 between two entities. 2771 The SASL protocol for authenticating XML streams (defined under 2772 Stream Authentication (Section 6)) provides a reliable mechanism for 2773 validating that a client connecting to a server is who it claims to 2774 be. 2776 Client-to-server communications MUST NOT proceed until the DNS 2777 hostname asserted by the server has been resolved. Such resolutions 2778 SHOULD first attempt to resolve the hostname using an SRV [18] 2779 Service of "jabber-client" and Proto of "tcp", resulting in resource 2780 records such as "_jabber-client._tcp.shakespeare.lit." (the use of 2781 the string "jabber-client" for the service identifier is consistent 2782 with the existing IANA registration). If the SRV lookup fails, the 2783 fallback is a normal A lookup to determine the IP address, using the 2784 "jabber-client" port of 5222 assigned by the Internet Assigned 2785 Numbers Authority [5]. 2787 The IP address and method of access of clients MUST NOT be made 2788 available by a server, nor are any connections other than the 2789 original server connection required. This helps to protect the 2790 client's server from direct attack or identification by third 2791 parties. 2793 12.3 Server-to-Server Communications 2795 A compliant implementation MUST support both TLS and SASL for 2796 inter-domain communications. For historical reasons, a compliant 2797 implementation SHOULD also support Server Dialback (Section 7). 2799 Because service provisioning is a matter of policy, it is OPTIONAL 2800 for any given domain to communicate with other domains, and 2801 server-to-server communications MAY be disabled by the administrator 2802 of any given deployment. If a particular domain enables inter-domain 2803 communications, it SHOULD enable high security. 2805 Administrators may want to require use of SASL for server-to-server 2806 communications in order to ensure both authentication and 2807 confidentiality (e.g., on an organization's private network). 2808 Compliant implementations SHOULD support SASL for this purpose. 2810 Inter-domain connections MUST NOT proceed until the DNS hostnames 2811 asserted by the servers have been resolved. Such resolutions MUST 2812 first attempt to resolve the hostname using an SRV [18] Service of 2813 "jabber-server" and Proto of "tcp", resulting in resource records 2814 such as "_jabber-server._tcp.shakespeare.lit." (the use of the string 2815 "jabber-server" for the service identifer is consistent with the 2816 existing IANA registration; note well that the "jabber-server" 2817 service identifier supersedes the earlier use of a "jabber" service 2818 identifier, since the earlier usage did not conform to RFC 2782 2819 [18]). If the SRV lookup fails, the fallback is a normal A lookup to 2820 determine the IP address, using the "jabber-server" port of 5269 2821 assigned by the Internet Assigned Numbers Authority [5]. 2823 Server dialback helps protect against domain spoofing, thus making it 2824 more difficult to spoof XML stanzas. It is not a mechanism for 2825 authenticating, securing, or encrypting streams between servers as is 2826 done via SASL and TLS. Furthermore, it is susceptible to DNS 2827 poisoning attacks unless DNSSec [31] is used, and even if the DNS 2828 information is accurate, dialback cannot protect from attacks where 2829 the attacker is capable of hijacking the IP address of the remote 2830 domain. Domains requiring robust security SHOULD use TLS and SASL. If 2831 SASL is used for server-to-server authentication, dialback SHOULD NOT 2832 be used since it is unnecessary. 2834 12.4 Order of Layers 2836 The order of layers in which protocols MUST be stacked is as follows: 2838 1. TCP 2840 2. TLS 2842 3. SASL 2844 4. XMPP 2846 The rationale for this order is that TCP is the base connection layer 2847 used by all of the protocols stacked on top of TCP, TLS is often 2848 provided at the operating system layer, SASL is often provided at the 2849 application layer, and XMPP is the application itself. 2851 12.5 Firewalls 2853 Communications using XMPP normally occur over TCP sockets on port 2854 5222 (client-to-server) or port 5269 (server-to-server), as 2855 registered with the IANA [5] (see IANA Considerations (Section 10)). 2856 Use of these well-known ports allows administrators to easily enable 2857 or disable XMPP activity through existing and commonly-deployed 2858 firewalls. 2860 12.6 Mandatory to Implement Technologies 2862 At a minimum, all implementations MUST support the following 2863 mechanisms: 2865 for authentication: the SASL DIGEST-MD5 mechanism 2867 for confidentiality: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA 2868 cipher) 2870 for both: TLS plus SASL EXTERNAL(using the 2871 TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side 2872 certificates) 2874 13. Compliance Requirements 2876 This section summarizes the specific aspects of the Extensible 2877 Messaging and Presence Protocol that MUST be supported by servers and 2878 clients in order to be considered compliant implementations, as well 2879 as additional protocol aspects that SHOULD be supported. For 2880 compliance purposes, we draw a distinction between core protocols 2881 (which MUST be supported by any server or client, regardless of the 2882 specific application) and instant messaging protocols (which MUST be 2883 supported only by instant messaging applications built on top of the 2884 core protocols). Compliance requirements that apply to all servers 2885 and clients are specified in this section; compliance requirements 2886 for instant messaging servers and clients are specified in the 2887 corresponding section of XMPP IM [24]. 2889 13.1 Servers 2891 A server MUST support the following core protocols in order to be 2892 considered compliant: 2894 o Enforcement of the nodeprep [10] and resourceprep [11] profiles of 2895 stringprep 2897 o XML streams (Section 4) as defined in this document, including 2898 stream encryption (Section 5) using TLS and stream authentication 2899 (Section 6) using SASL 2901 o The basic semantics of the three defined XML stanzas (Section 8) 2902 (i.e., , , and ) 2904 o Generation (and, where appropriate, handling) of error syntax and 2905 semantics related to streams, TLS, SASL, and XML stanzas 2907 In addition, a server SHOULD support the following core protocol: 2909 o Server dialback (Section 7) 2911 13.2 Clients 2913 A client MUST support the following core protocols in order to be 2914 considered compliant: 2916 o XML streams (Section 4) as defined in this document, including 2917 stream encryption (Section 5) using TLS and stream authentication 2918 (Section 6) using SASL 2920 o The basic semantics of the three defined XML stanzas (Section 8) 2921 (i.e., , , and ) 2923 o Handling (and, where appropriate, generation) of error syntax and 2924 semantics related to streams, TLS, SASL, and XML stanzas 2926 In addition, a client SHOULD support the following core protocols: 2928 o Generation of addresses in accordance with the nodeprep [10] and 2929 resourceprep [11] profiles of stringprep 2931 14. Differences Between Jabber and XMPP 2933 This section is non-normative. 2935 XMPP has been adapted from the protocols originally developed in the 2936 Jabber open-source community, which can be thought of as "XMPP 0.9". 2937 Because there exists a large installed base of Jabber implementations 2938 and deployments, it may be helpful to specify the key differences 2939 between Jabber and XMPP in order to expedite and encourage upgrades 2940 of those implementations and deployments to XMPP. This section 2941 summarizes the core differences, and the corresponding section of 2942 XMPP IM [24] summarizes the differences that relate specifically to 2943 instant messaging applications. 2945 14.1 Authentication 2947 The client-server authentication protocol developed in Jabber 2948 community uses a basic IQ interaction scoped by the 'jabber:iq:auth' 2949 namespace (documention of this protocol is contained in "JEP-0078: 2950 Non-SASL Authentication", published by the Jabber Software Foundation 2951 [33]). XMPP uses SASL for authentication, as defined in the Stream 2952 Authentication (Section 6) section of this document. 2954 The Jabber community does not currently possess an authentication 2955 protocol for server-to-server communications, only the Server 2956 Dialback (Section 7) protocol to prevent server spoofing. XMPP 2957 augments Server Dialback with a true server-to-server authentication 2958 protocol, as defined in the Stream Authentication (Section 6) section 2959 of this document. 2961 14.2 Channel Encryption 2963 It is common practice in the Jabber community to use SSL for channel 2964 encryption on ports other than 5222 and 5269 (the convention is to 2965 use ports 5223 and 5270). XMPP uses TLS over the IANA-registered 2966 ports for channel encryption, as defined in the Stream Encryption 2967 (Section 5) section of this document. 2969 14.3 JID Processing 2971 JID processing was somewhat loosely defined by the Jabber community 2972 (documentation of forbidden characters and case handling is contained 2973 in "JEP-0029: Definition of Jabber Identifiers", published by the 2974 Jabber Software Foundation [33]). XMPP defines two stringprep [9] 2975 profiles for JID processing: nodeprep [10] and resourceprep [11]. 2977 14.4 Error Handling 2978 Stream-related errors are handled in the Jabber community via simple 2979 CDATA text in a element. In XMPP, stream-related 2980 errors are handled via an extensible mechanism defined in the Stream 2981 Errors (Section 4.6) section of this document. 2983 Stanza-related errors are handled in the Jabber community via 2984 HTTP-style error codes. In XMPP, stanza-related errors are handled 2985 via an extensible mechanism defined in the Stanza Errors (Section 2986 8.7) section of this document. (Documentation of a mapping between 2987 Jabber and XMPP error handling mechanisms is contained in "JEP-0086: 2988 Legacy Errors", published by the Jabber Software Foundation [33].) 2990 14.5 Internationalization 2992 Although use of UTF-8 has always been standard practice within the 2993 Jabber community, the community did not define mechanisms for 2994 specifying the language of human-readable text provided in CDATA 2995 sections. XMPP specifies the use of the 'xml:lang' attribute in such 2996 contexts, as defined in the xml:lang (Section 8.2.5) section of this 2997 document. 2999 14.6 Stream Version Attribute 3001 The Jabber community does not include a 'version' attribute in stream 3002 headers. XMPP specifies inclusion of that attribute, with a value of 3003 '1.0', as a way to signal support for the stream features 3004 (authentication, encryption, etc.) defined in the Version Support 3005 (Section 4.2.1) section of this document. 3007 Normative References 3009 [1] World Wide Web Consortium, "Extensible Markup Language (XML) 3010 1.0 (Second Edition)", W3C xml, October 2000, . 3013 [2] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 3014 Presence Protocol Requirements", RFC 2779, February 2000. 3016 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 3017 Levels", BCP 14, RFC 2119, March 1997. 3019 [4] University of Southern California, "Transmission Control 3020 Protocol", RFC 793, September 1981, . 3023 [5] Internet Assigned Numbers Authority, "Internet Assigned Numbers 3024 Authority", January 1998, . 3026 [6] Harrenstien, K., Stahl, M. and E. Feinler, "DoD Internet host 3027 table specification", RFC 952, October 1985. 3029 [7] Braden, R., "Requirements for Internet Hosts - Application and 3030 Support", STD 3, RFC 1123, October 1989. 3032 [8] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile 3033 for Internationalized Domain Names (draft-ietf-idn-nameprep-11, 3034 work in progress)", June 2002. 3036 [9] Hoffman, P. and M. Blanchet, "Preparation of Internationalized 3037 Strings ("stringprep")", RFC 3454, December 2002. 3039 [10] Saint-Andre, P. and J. Hildebrand, "Nodeprep: A Stringprep 3040 Profile for Node Identifiers in XMPP", 3041 draft-ietf-xmpp-nodeprep-03 (work in progress), June 2003. 3043 [11] Saint-Andre, P. and J. Hildebrand, "Resourceprep: A Stringprep 3044 Profile for Resource Identifiers in XMPP", 3045 draft-ietf-xmpp-resourceprep-03 (work in progress), June 2003. 3047 [12] World Wide Web Consortium, "Namespaces in XML", W3C xml-names, 3048 January 1999, . 3051 [13] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 3052 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 3053 1999. 3055 [14] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 3057 [15] Myers, J., "Simple Authentication and Security Layer (SASL)", 3058 RFC 2222, October 1997. 3060 [16] Leach, P. and C. Newman, "Using Digest Authentication as a SASL 3061 Mechanism", RFC 2831, May 2000. 3063 [17] Alvestrand, H., "Tags for the Identification of Languages", BCP 3064 47, RFC 3066, January 2001. 3066 [18] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 3067 specifying the location of services (DNS SRV)", RFC 2782, 3068 February 2000. 3070 [19] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 3071 2279, January 1998. 3073 [20] Alvestrand, H., "IETF Policy on Character Sets and Languages", 3074 BCP 18, RFC 2277, January 1998. 3076 [21] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", 3077 RFC 2781, February 2000. 3079 [22] International Organization for Standardization, "Information 3080 Technology - Universal Multiple-octet coded Character Set (UCS) 3081 - Amendment 2: UCS Transformation Format 8 (UTF-8)", ISO 3082 Standard 10646-1 Addendum 2, October 1996. 3084 [23] Linn, J., "Generic Security Service Application Program 3085 Interface, Version 2", RFC 2078, January 1997. 3087 Informative References 3089 [24] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging", 3090 draft-ietf-xmpp-im-16 (work in progress), August 2003. 3092 [25] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 3093 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 3094 1998, . 3096 [26] Mealling, M., "The IANA XML Registry", 3097 draft-mealling-iana-xmlns-registry-05 (work in progress), June 3098 2003. 3100 [27] Crispin, M., "Internet Message Access Protocol - Version 3101 4rev1", RFC 2060, December 1996. 3103 [28] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 3104 53, RFC 1939, May 1996. 3106 [29] Newman, C. and J. Myers, "ACAP -- Application Configuration 3107 Access Protocol", RFC 2244, November 1997. 3109 [30] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, 3110 June 1999. 3112 [31] Eastlake, D., "Domain Name System Security Extensions", RFC 3113 2535, March 1999. 3115 [32] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 3116 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 3117 HTTP/1.1", RFC 2616, June 1999. 3119 [33] Jabber Software Foundation, "Jabber Software Foundation", 3120 . 3122 Authors' Addresses 3124 Peter Saint-Andre 3125 Jabber Software Foundation 3127 EMail: stpeter@jabber.org 3129 Jeremie Miller 3130 Jabber Software Foundation 3132 EMail: jeremie@jabber.org 3134 Appendix A. XML Schemas 3136 The following XML schemas are descriptive, not normative. 3138 A.1 Stream namespace 3140 3142 3148 3149 3150 3151 3152 3153 3156 3159 3160 3161 3162 3163 3164 3165 3166 3167 3169 3170 3171 3172 3176 3177 3178 3180 3181 3182 3183 3185 3189 3190 3191 3193 3195 A.2 Stream error namespace 3197 3199 3206 3209 3210 3211 3212 3213 3214 3215 3216 3217 3218 3219 3220 3221 3222 3223 3224 3225 3226 3227 3228 3229 3230 3231 3232 3233 3235 3236 3237 3238 3239 3241 3243 A.3 TLS namespace 3245 3247 3253 3254 3255 3256 3260 3261 3262 3264 3265 3266 3268 3269 3270 3271 3272 3274 3276 A.4 SASL namespace 3278 3280 3286 3287 3288 3289 3290 3291 3292 3294 3296 3297 3298 3301 3302 3304 3305 3306 3307 3309 3310 3311 3312 3313 3314 3315 3316 3317 3318 3319 3320 3321 3322 3323 3324 3325 3326 3327 3328 3329 3330 3331 3332 3334 3335 3336 3337 3338 3340 3342 A.5 Dialback namespace 3344 3346 3352 3353 3354 3355 3356 3357 3358 3359 3360 3361 3362 3363 3364 3365 3366 3367 3368 3369 3370 3371 3372 3373 3374 3375 3376 3377 3378 3379 3380 3381 3382 3383 3384 3385 3386 3387 3388 3390 3392 A.6 Client namespace 3394 3396 3403 3406 3407 3408 3409 3412 3415 3418 3421 3424 3425 3428 3431 3434 3435 3436 3437 3438 3439 3440 3441 3442 3443 3444 3445 3446 3447 3449 3450 3451 3452 3453 3455 3456 3457 3458 3459 3461 3463 3464 3465 3466 3469 3472 3475 3478 3481 3482 3485 3488 3491 3492 3493 3494 3495 3496 3497 3498 3499 3500 3501 3502 3503 3504 3505 3507 3508 3509 3510 3511 3512 3513 3514 3515 3516 3518 3519 3520 3521 3522 3524 3526 3527 3528 3529 3532 3535 3536 3539 3542 3545 3546 3547 3548 3549 3550 3551 3552 3553 3554 3555 3556 3557 3559 3560 3561 3562 3564 3567 3571 3572 3573 3574 3575 3576 3577 3578 3579 3580 3581 3582 3583 3584 3586 3588 A.7 Server namespace 3590 3592 3599 3602 3603 3604 3605 3609 3612 3615 3618 3621 3622 3625 3628 3631 3632 3633 3634 3635 3636 3637 3638 3639 3640 3641 3642 3643 3644 3646 3647 3648 3649 3650 3652 3653 3654 3655 3656 3657 3659 3660 3661 3662 3665 3668 3671 3674 3677 3678 3681 3684 3687 3688 3689 3690 3691 3692 3693 3694 3695 3696 3697 3698 3699 3700 3701 3703 3704 3705 3706 3707 3708 3709 3710 3711 3712 3714 3715 3716 3717 3718 3720 3722 3723 3724 3725 3728 3731 3732 3735 3738 3741 3742 3743 3744 3745 3746 3747 3748 3749 3750 3751 3752 3754 3756 3757 3758 3759 3761 3764 3768 3769 3770 3771 3772 3773 3774 3775 3776 3777 3778 3779 3780 3781 3783 3785 A.8 Stanza error namespace 3787 3789 3796 3799 3800 3801 3802 3803 3804 3805 3806 3807 3808 3809 3810 3811 3812 3813 3814 3815 3816 3818 3819 3820 3821 3822 3824 3825 3826 3827 3828 3830 3832 Appendix B. Revision History 3834 Note to RFC Editor: please remove this entire appendix, and the 3835 corresponding entries in the table of contents, prior to publication. 3837 B.1 Changes from draft-ietf-xmpp-core-16 3839 o Added and stream errors. 3841 o Changed the datatype for the and 3842 stream errors from 'xs:string' to 'empty'. 3844 o Further clarified server handling of the basic stanza types. 3846 o Further clarified character encoding rules per list discussion. 3848 o Specified meaning of version='1.0' flag in stream headers. 3850 o Added stream closure to SASL failure cases in order to mirror 3851 handling of TLS failures. 3853 o Added section on compliance requirements for server and client 3854 implementations. 3856 o Added non-normative section on differences between Jabber usage 3857 and XMPP specifications. 3859 B.2 Changes from draft-ietf-xmpp-core-15 3861 o Added and stream errors. 3863 o Added SASL error and clarified error. 3865 o Made 'id' required for IQ stanzas. 3867 B.3 Changes from draft-ietf-xmpp-core-14 3869 o Added SRV lookup for client-to-server communications. 3871 o Changed server SRV record to conform to RFC 2782; specifically, 3872 the service identifier was changed from 'jabber' to 3873 'jabber-server'. 3875 B.4 Changes from draft-ietf-xmpp-core-13 3877 o Clarified stream restart after successful TLS and SASL 3878 negotiation. 3880 o Clarified requirement for resolution of DNS hostnames. 3882 o Clarified text regarding namespaces. 3884 o Clarified examples regarding empty element. 3886 o Added several more SASL error conditions. 3888 o Changed stream error to and 3889 added to schema. 3891 o Made small editorial changes and fixed several schema errors. 3893 B.5 Changes from draft-ietf-xmpp-core-12 3895 o Moved server dialback to a separate section; clarified its 3896 security characteristics and its role in the protocol. 3898 o Adjusted error handling syntax and semantics per list discussion. 3900 o Further clarified length of node identifiers and total length of 3901 JIDs. 3903 o Documented message type='normal'. 3905 o Corrected several small errors in the TLS and SASL sections. 3907 o Corrected several errors in the schemas. 3909 B.6 Changes from draft-ietf-xmpp-core-11 3911 o Corrected several small errors in the TLS and SASL sections. 3913 o Made small editorial changes and fixed several schema errors. 3915 B.7 Changes from draft-ietf-xmpp-core-10 3917 o Adjusted TLS content regarding certificate validation process. 3919 o Specified that stanza error extensions for specific applications 3920 are to be properly namespaced children of the relevant descriptive 3921 element. 3923 o Clarified rules for inclusion of the 'id' attribute. 3925 o Specified that the 'xml:lang' attribute SHOULD be included (per 3926 list discussion). 3928 o Made small editorial changes and fixed several schema errors. 3930 B.8 Changes from draft-ietf-xmpp-core-09 3932 o Fixed several dialback error conditions. 3934 o Cleaned up rules regarding TLS and certificate processing based on 3935 off-list feedback. 3937 o Changed and elements to 3938 . 3940 o Added or modified several stream and stanza error conditions. 3942 o Specified only one child allowed for IQ, or two if type="error". 3944 o Fixed several errors in the schemas. 3946 B.9 Changes from draft-ietf-xmpp-core-08 3948 o Incorporated list discussion regarding addressing, SASL, TLS, TCP, 3949 dialback, namespaces, extensibility, and the meaning of 'ignore' 3950 for routers and recipients. 3952 o Specified dialback error conditions. 3954 o Made small editorial changes to address RFC Editor requirements. 3956 B.10 Changes from draft-ietf-xmpp-core-07 3958 o Made several small editorial changes. 3960 B.11 Changes from draft-ietf-xmpp-core-06 3962 o Added text regarding certificate validation in TLS negotiation per 3963 list discussion. 3965 o Clarified nature of XML restrictions per discussion with W3C, and 3966 moved XML Restrictions subsection under "XML Usage within XMPP". 3968 o Further clarified that XML streams are unidirectional. 3970 o Changed stream error and stanza error namespace names to conform 3971 to the format defined in The IETF XML Registry [26]. 3973 o Removed note to RFC Editor regarding provisional namespace names. 3975 B.12 Changes from draft-ietf-xmpp-core-05 3977 o Added as a stream error condition. 3979 o Adjusted security considerations per discussion at IETF 56 and on 3980 list. 3982 B.13 Changes from draft-ietf-xmpp-core-04 3984 o Added server-to-server examples for TLS and SASL. 3986 o Changed error syntax, rules, and examples based on list 3987 discussion. 3989 o Added schemas for the TLS, stream error, and stanza error 3990 namespaces. 3992 o Added note to RFC Editor regarding provisional namespace names. 3994 o Made numerous small editorial changes and clarified text 3995 throughout. 3997 B.14 Changes from draft-ietf-xmpp-core-03 3999 o Clarified rules and procedures for TLS and SASL. 4001 o Amplified stream error code syntax per list discussion. 4003 o Made numerous small editorial changes. 4005 B.15 Changes from draft-ietf-xmpp-core-02 4007 o Added dialback schema. 4009 o Removed all DTDs since schemas provide more complete definitions. 4011 o Added stream error codes. 4013 o Clarified error code "philosophy". 4015 B.16 Changes from draft-ietf-xmpp-core-01 4017 o Updated the addressing restrictions per list discussion and added 4018 references to the new nodeprep and resourceprep profiles. 4020 o Corrected error in Stream Authentication regarding 'version' 4021 attribute. 4023 o Made numerous small editorial changes. 4025 B.17 Changes from draft-ietf-xmpp-core-00 4027 o Added information about TLS from list discussion. 4029 o Clarified meaning of "ignore" based on list discussion. 4031 o Clarified information about Universal Character Set data and 4032 character encodings. 4034 o Provided base64-decoded information for examples. 4036 o Fixed several errors in the schemas. 4038 o Made numerous small editorial fixes. 4040 B.18 Changes from draft-miller-xmpp-core-02 4042 o Brought Streams Authentication section into line with discussion 4043 on list and at IETF 55 meeting. 4045 o Added information about the optional 'xml:lang' attribute per 4046 discussion on list and at IETF 55 meeting. 4048 o Specified that validation is neither required nor recommended, and 4049 that the formal definitions (DTDs and schemas) are included for 4050 descriptive purposes only. 4052 o Specified that the response to an IQ stanza of type "get" or "set" 4053 must be an IQ stanza of type "result" or "error". 4055 o Specified that compliant server implementations must process 4056 stanzas in order. 4058 o Specified that for historical reasons some server implementations 4059 may accept 'stream:' as the only valid namespace prefix on the 4060 root stream element. 4062 o Clarified the difference between 'jabber:client' and 4063 'jabber:server' namespaces, namely, that 'to' and 'from' 4064 attributes are required on all stanzas in the latter but not the 4065 former. 4067 o Fixed typo in Step 9 of the dialback protocol (changed db:result 4068 to db:verify). 4070 o Removed references to TLS pending list discussion. 4072 o Removed the non-normative appendix on OpenPGP usage pending its 4073 inclusion in a separate I-D. 4075 o Simplified the architecture diagram, removed most references to 4076 services, and removed references to the 'jabber:component:*' 4077 namespaces. 4079 o Noted that XMPP activity respects firewall administration 4080 policies. 4082 o Further specified the scope and uniqueness of the 'id' attribute 4083 in all stanza types and the element in message stanzas. 4085 o Nomenclature changes: (1) from "chunks" to "stanzas"; (2) from 4086 "host" to "server" and from "node" to "client" (except with regard 4087 to definition of the addressing scheme). 4089 Intellectual Property Statement 4091 The IETF takes no position regarding the validity or scope of any 4092 intellectual property or other rights that might be claimed to 4093 pertain to the implementation or use of the technology described in 4094 this document or the extent to which any license under such rights 4095 might or might not be available; neither does it represent that it 4096 has made any effort to identify any such rights. Information on the 4097 IETF's procedures with respect to rights in standards-track and 4098 standards-related documentation can be found in BCP-11. Copies of 4099 claims of rights made available for publication and any assurances of 4100 licenses to be made available, or the result of an attempt made to 4101 obtain a general license or permission for the use of such 4102 proprietary rights by implementors or users of this specification can 4103 be obtained from the IETF Secretariat. 4105 The IETF invites any interested party to bring to its attention any 4106 copyrights, patents or patent applications, or other proprietary 4107 rights which may cover technology that may be required to practice 4108 this standard. Please address the information to the IETF Executive 4109 Director. 4111 Full Copyright Statement 4113 Copyright (C) The Internet Society (2003). All Rights Reserved. 4115 This document and translations of it may be copied and furnished to 4116 others, and derivative works that comment on or otherwise explain it 4117 or assist in its implementation may be prepared, copied, published 4118 and distributed, in whole or in part, without restriction of any 4119 kind, provided that the above copyright notice and this paragraph are 4120 included on all such copies and derivative works. However, this 4121 document itself may not be modified in any way, such as by removing 4122 the copyright notice or references to the Internet Society or other 4123 Internet organizations, except as needed for the purpose of 4124 developing Internet standards in which case the procedures for 4125 copyrights defined in the Internet Standards process must be 4126 followed, or as required to translate it into languages other than 4127 English. 4129 The limited permissions granted above are perpetual and will not be 4130 revoked by the Internet Society or its successors or assignees. 4132 This document and the information contained herein is provided on an 4133 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 4134 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 4135 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 4136 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 4137 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4139 Acknowledgment 4141 Funding for the RFC Editor function is currently provided by the 4142 Internet Society.