idnits 2.17.1 draft-ietf-xmpp-core-16.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 3390 has weird spacing: '... mailing list, for which archives and subscription 199 information are available at . 202 1.4 Intellectual Property Notice 204 This document is in full compliance with all provisions of Section 10 205 of RFC 2026. Parts of this specification use the term "jabber" for 206 identifying namespaces and other protocol syntax. Jabber[tm] is a 207 registered trademark of Jabber, Inc. Jabber, Inc. grants permission 208 to the IETF for use of the Jabber trademark in association with this 209 specification and its successors, if any. 211 2. Generalized Architecture 213 2.1 Overview 215 Although XMPP is not wedded to any specific network architecture, to 216 this point it usually has been implemented via a typical 217 client-server architecture, wherein a client utilizing XMPP accesses 218 a server over a TCP [4] socket. 220 The following diagram provides a high-level overview of this 221 architecture (where "-" represents communications that use XMPP and 222 "=" represents communications that use any other protocol). 224 C1 - S1 - S2 - C3 225 / \ 226 C2 - G1 = FN1 = FC1 228 The symbols are as follows: 230 o C1, C2, C3 -- XMPP clients 232 o S1, S2 -- XMPP servers 234 o G1 -- A gateway that translates between XMPP and the protocol(s) 235 used on a foreign (non-XMPP) messaging network 237 o FN1 -- A foreign messaging network 239 o FC1 -- A client on a foreign messaging network 241 2.2 Server 243 A server acts as an intelligent abstraction layer for XMPP 244 communications. Its primary responsibilities are to manage 245 connections from or sessions for other entities (in the form of XML 246 streams to and from authorized clients, servers, and other entities) 247 and to route appropriately-addressed XML data "stanzas" among such 248 entities over XML streams. Most XMPP-compliant servers also assume 249 responsibility for the storage of data that is used by clients (e.g., 250 contact lists for users of XMPP-based instant messaging 251 applications); in this case, the XML data is processed directly by 252 the server itself on behalf of the client and is not routed to 253 another entity. Compliant server implementations MUST ensure in-order 254 processing of XML stanzas between any two entities. 256 2.3 Client 257 Most clients connect directly to a server over a TCP socket and use 258 XMPP to take full advantage of the functionality provided by a server 259 and any associated services. Although there is no necessary coupling 260 of an XML stream to a TCP socket (e.g., a client COULD connect via 261 HTTP polling or some other mechanism), this specification defines a 262 binding for XMPP to TCP only. Multiple resources (e.g., devices or 263 locations) MAY connect simultaneously to a server on behalf of each 264 authorized client, with each resource connecting over a discrete TCP 265 socket and differentiated by the resource identifier of a JID (e.g., 266 vs. ) as defined under 267 Addressing Scheme (Section 3). The port registered with the IANA for 268 connections between a client and a server is 5222 (see IANA 269 Considerations (Section 10)). 271 2.4 Gateway 273 A gateway is a special-purpose server-side service whose primary 274 function is to translate XMPP into the protocol used by a foreign 275 (non-XMPP) messaging system, as well as to translate the return data 276 back into XMPP. Examples are gateways to Internet Relay Chat (IRC), 277 Short Message Service (SMS), SMTP, and legacy instant messaging 278 networks such as AIM, ICQ, MSN Messenger, and Yahoo! Instant 279 Messenger. Communications between gateways and servers, and between 280 gateways and the foreign messaging system, are not defined in this 281 document. 283 2.5 Network 285 Because each server is identified by a network address and because 286 server-to-server communications are a straightforward extension of 287 the client-to-server protocol, in practice the system consists of a 288 network of servers that inter-communicate. Thus user-a@domain1 is 289 able to exchange messages, presence, and other information with 290 user-b@domain2. This pattern is familiar from messaging protocols 291 (such as SMTP) that make use of network addressing standards. 292 Communications between any two servers are OPTIONAL; if enabled, such 293 communications occur over XML streams that are normally bound to TCP 294 sockets, using port 5269 as registered with the IANA (see IANA 295 Considerations (Section 10)). 297 3. Addressing Scheme 299 3.1 Overview 301 An entity is anything that can be considered a network endpoint 302 (i.e., an ID on the network) and that can communicate using XMPP. All 303 such entities are uniquely addressable in a form that is consistent 304 with RFC 2396 [24]. For historical reasons, the address of such an 305 entity is called a Jabber Identifier or JID. A valid JID contains a 306 set of ordered elements formed of a domain identifier, node 307 identifier, and resource identifier in the following format: 308 [node@]domain[/resource]. Each allowable portion of a JID (node 309 identifier, domain identifier, and resource identifier) may be up to 310 1023 bytes in length, resulting in a maximum total size (including 311 the '@' and '/' separators) of 3071 bytes. 313 All JIDs are based on the foregoing structure. The most common use of 314 this structure is to identify an instant messaging user, the server 315 to which the user connects, and the user's active session or 316 connection (e.g., a specific client) in the form of . However, node types other than clients are possible; for 318 example, a specific chat room offered by a multi-user chat service 319 could be addressed as (where "room" is the name of the 320 chat room and "service" is the hostname of the multi-user chat 321 service) and a specific occupant of such a room could be addressed as 322 (where "nick" is the occupant's room nickname). 323 Many other JID types are possible (e.g., could be a 324 server-side script or service). 326 3.2 Domain Identifier 328 The domain identifier is the primary identifier and is the only 329 REQUIRED element of a JID (a mere domain identifier is a valid JID). 330 It usually represents the network gateway or "primary" server to 331 which other entities connect for XML routing and data management 332 capabilities. However, the entity referenced by a domain identifier 333 is not always a server, and may be a service that is addressed as a 334 subdomain of a server and that provides functionality above and 335 beyond the capabilities of a server (e.g., a multi-user chat service, 336 a user directory, or a gateway to a foreign messaging system). 338 The domain identifier for every server or service that will 339 communicate over a network SHOULD resolve to a Fully Qualified Domain 340 Name. A domain identifier MUST conform to RFC 952 [6] and RFC 1123 341 [7]. In addition, a domain identifier MUST be no more than 1023 bytes 342 in length and MUST conform to the nameprep [8] profile of stringprep 343 [9]. 345 3.3 Node Identifier 347 The node identifier is an optional secondary identifier placed before 348 the domain identifier and separated from the latter by the '@' 349 character. It usually represents the entity requesting and using 350 network access provided by the server or gateway (i.e., a client), 351 although it can also represent other kinds of entities (e.g., a chat 352 room associated with a multi-user chat service). The entity 353 represented by a node identifier is addressed within the context of a 354 specific domain; within instant messaging applications of XMPP this 355 address is called a "bare JID" and is of the form . 357 A node identifier MUST be no more than 1023 bytes in length and MUST 358 conform to the nodeprep [10] profile of stringprep [9]. 360 3.4 Resource Identifier 362 The resource identifier is an optional tertiary identifier placed 363 after the domain identifier and separated from the latter by the '/' 364 character. A resource identifier may modify either a or 365 mere address. It usually represents a specific session, 366 connection (e.g., a device or location), or object (e.g., a 367 participant in a multi-user chat room) belonging to the entity 368 associated with a node identifier. A resource identifier is opaque to 369 both servers and other clients, and is typically defined by a client 370 implementation as the authzid value provided during stream 371 authentication. An entity may maintain multiple resources 372 simultaneously. 374 A resource identifier MUST be no more than 1023 bytes in length and 375 MUST conform to the resourceprep [11] profile of stringprep [9]. 377 4. XML Streams 379 4.1 Overview 381 Two fundamental concepts make possible the rapid, asynchronous 382 exchange of relatively small payloads of structured information 383 between presence-aware entities: XML streams and XML stanzas. These 384 terms may be defined as follows: 386 Definition of XML Stream: An XML stream is a container for the 387 exchange of XML elements between any two entities over a network. 388 An XML stream is negotiated from an initiating entity (usually a 389 client or server) to a receiving entity (usually a server), 390 normally over a TCP socket, and corresponds to the initiating 391 entity's "session" with the receiving entity. The start of the XML 392 stream is denoted unambiguously by an opening XML tag 393 with appropriate attributes and namespace declarations, and the 394 end of the XML stream is denoted unambiguously by a closing XML tag. An XML stream is unidirectional; in order to enable 396 bidirectional information exchange, the initiating entity and 397 receiving entity MUST negotiate one stream in each direction, 398 normally over the same TCP connection. 400 Definition of XML Stanza: An XML stanza is a discrete semantic unit 401 of structured information that is sent from one entity to another 402 over an XML stream. An XML stanza exists at the direct child level 403 of the root element and is said to be well-balanced if 404 it matches production [43] content of the XML specification [1]). 405 The start of any XML stanza is denoted unambiguously by the 406 element start tag at depth=1 of the XML stream (e.g., ), 407 and the end of any XML stanza is denoted unambiguously by the 408 corresponding close tag at depth=1 (e.g., ). An XML 409 stanza MAY contain child elements (with accompanying attributes, 410 elements, and CDATA) as necessary in order to convey the desired 411 information. An XML element sent for the purpose of stream 412 encryption, stream authentication, or server dialback is not 413 considered to be an XML stanza. 415 Consider the example of a client's session with a server. In order to 416 connect to a server, a client MUST initiate an XML stream by sending 417 an opening tag to the server, optionally preceded by a text 418 declaration specifying the XML version supported and the character 419 encoding (see also Character Encodings (Section 9.4)). The server 420 SHOULD then reply with a second XML stream back to the client, again 421 optionally preceded by a text declaration. Once the client has 422 authenticated with the server (see Section 6), the client MAY send an 423 unlimited number of XML stanzas over the stream to any recipient on 424 the network. When the client desires to close the stream, it simply 425 sends a closing tag to the server (alternatively, the 426 stream may be closed by the server), after which both the client and 427 server SHOULD close the underlying TCP connection as well. 429 Those who are accustomed to thinking of XML in a document-centric 430 manner may wish to view a client's session with a server as 431 consisting of two open-ended XML documents: one from the client to 432 the server and one from the server to the client. From this 433 perspective, the root element can be considered the 434 document entity for each "document", and the two "documents" are 435 built up through the accumulation of XML stanzas sent over the two 436 XML streams. However, this perspective is a convenience only, and 437 XMPP does not deal in documents but in XML streams and XML stanzas. 439 In essence, then, an XML stream acts as an envelope for all the XML 440 stanzas sent during a session. We can represent this graphically as 441 follows: 443 |--------------------| 444 | | 445 |--------------------| 446 | | 447 | | 448 | | 449 |--------------------| 450 | | 451 | | 452 | | 453 |--------------------| 454 | | 455 | | 456 | | 457 |--------------------| 458 | ... | 459 |--------------------| 460 | | 461 |--------------------| 463 4.2 Stream Attributes 465 The attributes of the stream element are as follows: 467 o to -- The 'to' attribute SHOULD be used only in the XML stream 468 header from the initiating entity to the receiving entity, and 469 MUST be set to the JID of the receiving entity. There SHOULD be no 470 'to' attribute set in the XML stream header by which the receiving 471 entity replies to the initiating entity; however, if a 'to' 472 attribute is included, it SHOULD be silently ignored by the 473 initiating entity. 475 o from -- The 'from' attribute SHOULD be used only in the XML stream 476 header from the receiving entity to the initiating entity, and 477 MUST be set to the JID of the receiving entity granting access to 478 the initiating entity. There SHOULD be no 'from' attribute on the 479 XML stream header sent from the initiating entity to the receiving 480 entity; however, if a 'from' attribute is included, it SHOULD be 481 silently ignored by the receiving entity. 483 o id -- The 'id' attribute SHOULD be used only in the XML stream 484 header from the receiving entity to the initiating entity. This 485 attribute is a unique identifier created by the receiving entity 486 to function as a session key for the initiating entity's streams 487 with the receiving entity, and MUST be unique within the receiving 488 application (normally a server). There SHOULD be no 'id' attribute 489 on the XML stream header sent from the initiating entity to the 490 receiving entity; however, if an 'id' attribute is included, it 491 SHOULD be silently ignored by the receiving entity. 493 o version -- The presence of the version attribute set to a value of 494 "1.0" indicates compliance with this specification. Detailed rules 495 regarding generation and handling of this attribute are defined 496 below. 498 We can summarize as follows: 500 | initiating to receiving | receiving to initiating 501 ------------------------------------------------------------ 502 to | hostname of receiver | silently ignored 503 from | silently ignored | hostname of receiver 504 id | silently ignored | session key 505 version | signals XMPP 1.0 support | signals XMPP 1.0 support 507 4.2.1 Version Support 509 The following rules apply to the generation and handling of the 510 'version' attribute: 512 1. If the initiating entity complies with the protocol defined 513 herein, it MUST include the 'version' attribute in the XML stream 514 header it sends to the receiving entity, and it MUST set the 515 value of the 'version' attribute to "1.0". 517 2. If the initiating entity includes the 'version' attribute set to 518 a value of "1.0" in its stream header and the receiving entity 519 supports XMPP 1.0, the receiving entity MUST reciprocate by 520 including the 'version' attribute set to a value of "1.0" in its 521 stream header response. 523 3. If the initiating entity does not include the 'version' attribute 524 in its stream header, the receiving entity still SHOULD include 525 the 'version' attribute set to a value of "1.0" in its stream 526 header response. 528 4. If the initiating entity includes the 'version' attribute set to 529 a value other than "1.0", the receiving entity SHOULD include the 530 'version' attribute set to a value of "1.0" in its stream header 531 response, but MAY at its discretion generate an 532 stream error and terminate the XML stream 533 and underlying TCP connection. 535 5. If the receiving entity includes the 'version' attribute set to a 536 value other than "1.0" in its stream header response, the 537 initiating entity SHOULD generate an 538 stream error and terminate the XML stream and underlying TCP 539 connection. 541 4.3 Namespace Declarations 543 The stream element MUST possess both a stream namespace declaration 544 and a default namespace declaration (as "namespace declaration" is 545 defined in the XML namespaces specification [12]). For detailed 546 information regarding the stream namespace and default namespace, see 547 Namespace Names and Prefixes (Section 9.2). 549 4.4 Stream Features 551 If the initiating entity includes the 'version' attribute set to a 552 value of "1.0" in its initiating stream element, the receiving entity 553 MUST send a child element (prefixed by the stream 554 namespace prefix) to the initiating entity in order to announce any 555 stream-level features that can be negotiated (or capabilities that 556 otherwise need to be advertised). Currently this is used for TLS and 557 SASL negotiation only, but it could be used for other negotiable 558 features in the future (usage is defined under Stream Encryption 559 (Section 5) and Stream Authentication (Section 6) below). If an 560 entity does not understand or support some features, it SHOULD 561 silently ignore them. 563 4.5 Stream Encryption and Authentication 565 XML streams in XMPP 1.0 SHOULD be encrypted as defined under Stream 566 Encryption (Section 5) and MUST be authenticated as defined under 567 Stream Authentication (Section 6). If the initiating entity attempts 568 to send an XML stanza before the stream is authenticated, the 569 receiving entity SHOULD return a stream error to 570 the initiating entity and then terminate both the XML stream and the 571 underlying TCP connection. 573 4.6 Stream Errors 575 The root stream element MAY contain an child element that is 576 prefixed by the stream namespace prefix. The error child MUST be sent 577 by a compliant entity (usually a server rather than a client) if it 578 perceives that a stream-level error has occurred. 580 4.6.1 Rules 582 The following rules apply to stream-level errors: 584 o It is assumed that all stream-level errors are unrecoverable; 585 therefore, if an error occurs at the level of the stream, the 586 entity that detects the error MUST send a stream error to the 587 other entity, send a closing tag, and terminate the 588 underlying TCP connection. 590 o If the error occurs while the stream is being set up, the 591 receiving entity MUST still send the opening tag, include 592 the element as a child of the stream element, send the 593 closing tag, and terminate the underlying TCP 594 connection. In this case, if the initiating entity provides an 595 unknown host in the 'to' attribute (or provides no 'to' attribute 596 at all), the server SHOULD provide the server's authoritative 597 hostname in the 'from' attribute of the stream header sent before 598 termination. 600 4.6.2 Syntax 602 The syntax for stream errors is as follows: 604 605 606 607 OPTIONAL descriptive text 608 609 [OPTIONAL application-specific condition element] 610 612 The element: 614 o MUST contain a child element corresponding to one of the defined 615 stanza error conditions defined below; this element MUST be 616 qualified by the 'urn:ietf:params:xml:ns:xmpp-streamstreams' 617 namespace 619 o MAY contain a child containing CDATA that describes the 620 error in more detail; this element MUST be qualified by the 621 'urn:ietf:params:xml:ns:xmpp-streams' namespace and SHOULD possess 622 an 'xml:lang' attribute 624 o MAY contain a child element for an application-specific error 625 condition; this element MUST be qualified by an 626 application-defined namespace, and its structure is defined by 627 that namespace 629 The element is OPTIONAL. If included, it SHOULD be used only 630 to provide descriptive or diagnostic information that supplements the 631 meaning of a defined condition or application-specific condition. It 632 SHOULD NOT be interpreted programmatically by an application. It 633 SHOULD NOT be used as the error message presented to user, but MAY be 634 shown in addition to the error message associated with the included 635 condition element (or elements). 637 Note: the XML namespace name 'urn:ietf:params:xml:ns:xmpp-streams' 638 that qualifies the descriptive element adheres to the format defined 639 in The IETF XML Registry [25]. 641 4.6.3 Defined Conditions 643 The following stream-level error conditions are defined: 645 o -- the entity has not generated any traffic 646 over the stream for some period of time (configurable according to 647 a local service policy). 649 o -- the value of the 'to' attribute provided by the 650 initiating entity in the stream header corresponds to a hostname 651 that is no longer hosted by the server. 653 o -- the value of the 'to' attribute provided by the 654 initiating entity in the stream header does not correspond to a 655 hostname that is hosted by the server. 657 o -- a stanza sent between two servers lacks 658 a 'to' or 'from' attribute (or the attribute has no value). 660 o -- the server has experienced a 661 misconfiguration or an otherwise-undefined internal error that 662 prevents it from servicing the stream. 664 o -- the stream ID or dialback ID is invalid or does 665 not match an ID previously provided. 667 o -- the stream namespace name is something 668 other than "http://etherx.jabber.org/streams" or the dialback 669 namespace name is something other than "jabber:server:dialback". 671 o -- the hostname provided in a 'from' address 672 does not match the hostname (or other validated domain) negotiated 673 via SASL or dialback. 675 o -- the entity has attempted to send data before 676 authenticating, or otherwise is not authorized to perform an 677 action related to stream negotiation; the receiving entity SHOULD 678 silently drop the offending stanza and MUST NOT process it before 679 sending the stream error. 681 o -- the entity has violated some local service 682 policy. 684 o -- the server is unable to properly 685 connect to a remote resource that is required for authentication 686 or authorization. 688 o -- the server is resource-contrained and is 689 unable to service the stream. 691 o -- the server will not provide service to the 692 initiating entity but is redirecting traffic to another host; this 693 element SHOULD contain CDATA specifying the alternate hostname or 694 IP address to which the initiating entity MAY attempt to connect. 696 o -- the server is being shut down and all active 697 streams are being closed. 699 o -- the error condition is not one of those 700 defined by the other conditions in this list; this error condition 701 SHOULD be used only in conjuction with an application-specific 702 condition. 704 o -- the initiating entity has sent a 705 first-level child of the stream that is not supported by the 706 server. 708 o -- the value of the 'version' attribute 709 provided by the initiating entity in the stream header specifies a 710 version of XMPP that is not supported by the server; this element 711 MAY contain CDATA specifying the XMPP version(s) supported by the 712 server. 714 o -- the initiating entity has sent XML that 715 is not well-formed as defined by the XML specification [1]. 717 4.6.4 Application-Specific Conditions 719 As noted, an application MAY provide application-specific stream 720 error information by including a properly-namespaced child in the 721 error element. The application-specific element SHOULD supplement or 722 further qualify a defined element. Thus the element will 723 contain two or three child elements: 725 726 728 729 Some special application diagnostic information! 730 731 732 733 735 4.7 Simple Streams Example 737 The following is a stream-based session of a client on a server 738 (where the "C" lines are sent from the client to the server, and the 739 "S" lines are sent from the server to the client): 741 A basic session: 743 C: 744 749 S: 750 756 ... authentication ... 757 C: 760 C: Art thou not Romeo, and a Montague? 761 C: 762 S: 765 S: Neither, fair saint, if either thee dislike. 766 S: 767 C: 768 S: 769 A stream gone bad: 771 C: 772 777 S: 778 784 ... authentication ... 785 C: 786 Bad XML, no closing body tag! 787 788 S: 789 791 792 S: 794 5. Stream Encryption 796 5.1 Overview 798 XMPP includes a method for securing the stream from tampering and 799 eavesdropping. This channel encryption method makes use of the 800 Transport Layer Security (TLS) [13] protocol, along with a "STARTTLS" 801 extension that is modelled after similar extensions for the IMAP 802 [26], POP3 [27], and ACAP [28] protocols as described in RFC 2595 803 [29]. The namespace name for the STARTTLS extension is 804 'urn:ietf:params:xml:ns:xmpp-tls', which adheres to the format 805 defined in The IETF XML Registry [25]. 807 An administrator of a given domain MAY require the use of TLS for 808 client-to-server communications, server-to-server communications, or 809 both. Servers SHOULD use TLS betweeen two domains for the purpose of 810 securing server-to-server communications. See Mandatory to Implement 811 Technologies (Section 12.6) regarding mechanisms that MUST be 812 supported. 814 The following rules apply: 816 1. An initiating entity that complies with this specification MUST 817 include the 'version' attribute set to a value of "1.0" in the 818 initiating stream header. 820 2. If the TLS negotiation occurs between two servers, 821 communications MUST NOT proceed until the DNS hostnames asserted 822 by the servers have been resolved (see Server-to-Server 823 Communications (Section 12.3)). 825 3. When a receiving entity that complies with this specification 826 receives an initiating stream header that includes the 'version' 827 attribute set to a value of "1.0", after sending a stream header 828 in reply (including the version flag) it MUST include a 829 element (qualified by the 830 'urn:ietf:params:xml:ns:xmpp-tls' namespace) along with the list 831 of other stream features it supports. 833 4. If the initiating entity chooses to use TLS for stream 834 encryption, TLS negotiation MUST be completed before proceeding 835 to SASL negotiation. 837 5. The receiving entity MUST consider the TLS negotiation to have 838 begun immediately after sending the closing ">" of the element. The initiating entity MUST consider the TLS 840 negotiation to have begun immediately after receiving the 841 closing ">" of the element from the receiving entity. 843 6. The initiating entity MUST validate the certificate presented by 844 the receiving entity; there are two cases: 846 Case 1 -- The initiating entity has been configured with a set 847 of trusted root certificates: Normal certificate validation 848 processing is appropriate, and SHOULD follow the rules 849 defined for HTTP over TLS [14]. The trusted roots may be 850 either a well-known public set or a manually configured Root 851 CA (e.g., an organization's own Certificate Authority or a 852 self-signed Root CA for the service as described under High 853 Security (Section 12.1)). This case is RECOMMENDED. 855 Case 2 -- The initiating entity has been configured with the 856 receiving entity's self-signed service certificate: Simple 857 comparison of public keys is appropriate. This case is NOT 858 RECOMMENDED (see High Security (Section 12.1) for details). 860 If the above methods fail, the certificate SHOULD be presented 861 to a human (e.g., an end user or server administrator) for 862 approval; if presented, the receiver MUST deliver the entire 863 certificate chain to the human, who SHOULD be given the option 864 to store the Root CA certificate (not the service or End Entity 865 certificate) and to not be queried again regarding acceptance of 866 the certificate for some reasonable period of time. 868 7. If the TLS negotiation is successful, the receiving entity MUST 869 discard any knowledge obtained from the initiating entity before 870 TLS takes effect. 872 8. If the TLS negotiation is successful, the initiating entity MUST 873 discard any knowledge obtained from the receiving entity before 874 TLS takes effect. 876 9. If the TLS negotiation is successful, the receiving entity MUST 877 NOT offer the STARTTLS extension to the initiating entity along 878 with the other stream features that are offered when the stream 879 is restarted. 881 10. If the TLS negotiation is successful, the initiating entity 882 SHOULD continue with SASL negotiation. 884 11. If the TLS negotiation results in failure, the receiving entity 885 MUST terminate both the XML stream and the underlying TCP 886 connection. 888 5.2 Narrative 890 When an initiating entity secures a stream with a receiving entity, 891 the steps involved are as follows: 893 1. The initiating entity opens a TCP connection and initiates the 894 stream by sending the opening XML stream header to the receiving 895 entity, including the 'version' attribute set to a value of 896 "1.0". 898 2. The receiving entity responds by opening a TCP connection and 899 sending an XML stream header to the initiating entity, including 900 the 'version' attribute set to a value of "1.0". 902 3. The receiving entity offers the STARTTLS extension to the 903 initiating entity by including it with the list of other 904 supported stream features (if TLS is required for interaction 905 with the receiving entity, it SHOULD signal that fact by 906 including a element as a child of the 907 element). 909 4. The initiating entity issues the STARTTLS command (i.e., a 910 element qualified by the 911 'urn:ietf:params:xml:ns:xmpp-tls' namespace) to instruct the 912 receiving entity that it wishes to begin a TLS negotiation to 913 secure the stream. 915 5. The receiving entity MUST reply with either a element 916 or a element qualified by the 917 'urn:ietf:params:xml:ns:xmpp-tls' namespace. If the failure case 918 occurs, the receiving entity MUST terminate both the XML stream 919 and the underlying TCP connection. If the proceed case occurs, 920 the receiving entity MUST ignore any further XML data sent over 921 the XML stream but keep the underlying TCP connection open for 922 the purpose of completing the TLS negotiation. 924 6. The initiating entity and receiving entity attempt to complete a 925 TLS negotiation in accordance with RFC 2246 [13]. 927 7. If the TLS negotiation is unsuccessful, the receiving entity MUST 928 terminate the TCP connection. If the TLS negotiation is 929 successful, the initiating entity MUST initiate a new stream by 930 sending an opening XML stream header to the receiving entity. 932 8. Upon receiving the new stream header from the initiating entity, 933 the receiving entity MUST respond by sending a new XML stream 934 header to the initiating entity along with the remaining 935 available features (but NOT including the STARTTLS feature). 937 5.3 Client-to-Server Example 939 The following example shows the data flow for a client securing a 940 stream using STARTTLS (the IANA-registered port 5222 SHOULD be used; 941 see IANA Considerations (Section 10)). 943 Step 1: Client initiates stream to server: 945 951 Step 2: Server responds by sending a stream tag to client: 953 960 Step 3: Server sends the STARTTLS extension to client along with 961 authentication mechanisms and any other stream features: 963 964 965 966 967 968 DIGEST-MD5 969 PLAIN 970 971 973 Step 4: Client sends the STARTTLS command to server: 975 977 Step 5: Server informs client to proceed: 979 980 Step 5 (alt): Server informs client that TLS negotiation has failed 981 and closes both stream and TCP connection: 983 984 986 Step 6: Client and server attempt to complete TLS negotiation over 987 the existing TCP connection. 989 Step 7: If TLS negotiation is successful, client initiates a new 990 stream to server: 992 998 Step 7 (alt): If TLS negotiation is unsuccessful, server MUST close 999 TCP connection. 1001 Step 8: Server responds by sending a stream header to client along 1002 with any remaining negotiable stream features: 1004 1010 1011 1012 DIGEST-MD5 1013 PLAIN 1014 EXTERNAL 1015 1016 1018 Step 9: Client SHOULD continue with Stream Authentication (Section 1019 6). 1021 5.4 Server-to-Server Example 1023 The following example shows the data flow for two servers securing a 1024 stream using STARTTLS (the IANA-registered port 5269 SHOULD be used; 1025 see IANA Considerations (Section 10)). 1027 Step 1: Server1 initiates stream to Server2: 1029 1035 Step 2: Server2 responds by sending a stream tag to Server1: 1037 1044 Step 3: Server2 sends the STARTTLS extension to Server1 along with 1045 authentication mechanisms and any other stream features: 1047 1048 1049 1050 1051 1052 DIGEST-MD5 1053 KERBEROS_V4 1054 1055 1057 Step 4: Server1 sends the STARTTLS command to Server2: 1059 1061 Step 5: Server2 informs Server1 to proceed: 1063 1065 Step 5 (alt): Server2 informs Server1 that TLS negotiation has failed 1066 and closes stream: 1068 1069 1071 Step 6: Server1 and Server2 attempt to complete TLS negotiation via 1072 TCP. 1074 Step 7: If TLS negotiation is successful, Server1 initiates a new 1075 stream to Server2: 1077 1083 Step 7 (alt): If TLS negotiation is unsuccessful, server MUST close 1084 TCP connection. 1086 Step 8: Server2 responds by sending a stream header to Server1 along 1087 with any remaining negotiable stream features: 1089 1095 1096 1097 DIGEST-MD5 1098 KERBEROS_V4 1099 EXTERNAL 1100 1101 1103 Step 9: Server1 SHOULD continue with Stream Authentication (Section 1104 6). 1106 6. Stream Authentication 1108 6.1 Overview 1110 XMPP includes a method for authenticating a stream using an XMPP 1111 adaptation of the Simple Authentication and Security Layer (SASL) 1112 [15]. SASL provides a generalized method for adding authentication 1113 support to connection-based protocols, and XMPP uses a generic XML 1114 namespace profile for SASL that conforms to section 4 ("Profiling 1115 Requirements") of RFC 2222 [15] (the XMPP-specific namespace name is 1116 'urn:ietf:params:xml:ns:xmpp-sasl', which adheres to the format 1117 defined in The IETF XML Registry [25]). Finally, see Mandatory to 1118 Implement Technologies (Section 12.6) regarding mechanisms that MUST 1119 be supported. 1121 The following rules apply: 1123 1. If the SASL negotiation occurs between two servers, 1124 communications MUST NOT proceed until the DNS hostnames asserted 1125 by the servers have been resolved (see Server-to-Server 1126 Communications (Section 12.3)). 1128 2. If TLS is used for stream encryption, SASL SHOULD NOT be used for 1129 anything except stream authentication (i.e., a security layer 1130 SHOULD NOT be negotiated using SASL). Conversely, if a security 1131 layer is to be negotiated via SASL, TLS SHOULD NOT be used. 1133 3. If the initiating entity is capable of authenticating via SASL, 1134 it MUST include the 'version' attribute set to a value of "1.0" 1135 in the initiating stream header. 1137 4. If the receiving entity is capable of negotiating authentication 1138 via SASL, it MUST send one or more authentication mechanisms 1139 within a element qualified by the 1140 'urn:ietf:params:xml:ns:xmpp-sasl' namespace in response to the 1141 opening stream tag received from the initiating entity (if the 1142 opening stream tag included the 'version' attribute set to a 1143 value of "1.0"). 1145 5. Upon successful SASL negotiation that involves negotiation of a 1146 security layer, the receiving entity MUST discard any knowledge 1147 obtained from the initiating entity which was not obtained from 1148 the SASL negotiation itself. 1150 6. Upon successful SASL negotiation that involves negotiation of a 1151 security layer, the initiating entity MUST discard any knowledge 1152 obtained from the receiving entity which was not obtained from 1153 the SASL negotiation itself. 1155 7. The initiating entity MUST provide an authzid during SASL 1156 negotiation. The authzid-value MUST be a valid JID of the form 1157 (i.e., a domain identifier only) for servers and of the 1158 form (i.e., node identifier, domain 1159 identifier, and resource identifier) for clients. The initiating 1160 entity MAY process the authzid-value in accordance with the rules 1161 defined in Addressing Scheme (Section 3) before providing it to 1162 the receiving entity, but is NOT REQUIRED to do so. 1164 8. Any character data contained within the XML elements used during 1165 SASL negotiation MUST be encoded using base64. 1167 6.2 Narrative 1169 When an initiating entity authenticates with a receiving entity, the 1170 steps involved are as follows: 1172 1. The initiating entity requests SASL authentication by including 1173 the 'version' attribute in the opening XML stream header sent to 1174 the receiving entity, with the value set to "1.0". 1176 2. After sending an XML stream header in response, the receiving 1177 entity sends a list of available SASL authentication mechanisms; 1178 each of these is a element included as a child 1179 within a container element qualified by the 1180 'urn:ietf:params:xml:ns:xmpp-sasl' namespace, which in turn is a 1181 child of a element in the streams namespace. If 1182 channel encryption needs to be established before a particular 1183 authentication mechanism may be used, the receiving entity MUST 1184 NOT provide that mechanism in the list of available SASL 1185 authentication methods prior to channel encryption. If the 1186 initiating entity presents a valid certificate during prior TLS 1187 negotiation, the receiving entity MAY offer the SASL EXTERNAL 1188 mechanism to the initiating entity during stream authentication 1189 (refer to RFC 2222 [15]). 1191 3. The initiating entity selects a mechanism by sending an 1192 element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' 1193 namespace to the receiving entity and including an appropriate 1194 value for the 'mechanism' attribute; this element MAY optionally 1195 contain character data (in SASL terminology the "initial 1196 response") if the mechanism supports or requires it. If the 1197 initiating entity selects the EXTERNAL mechanism for 1198 authentication, the authentication credentials shall be taken 1199 from the certificate presented during prior TLS negotiation. 1201 4. If necessary, the receiving entity challenges the initiating 1202 entity by sending a element qualified by the 1203 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating 1204 entity; this element MAY optionally contain character data (which 1205 MUST be computed in accordance with the SASL mechanism chosen by 1206 the initiating entity). 1208 5. The initiating entity responds to the challenge by sending a 1209 element qualified by the 1210 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the receiving 1211 entity; this element MAY optionally contain character data (which 1212 MUST be computed in accordance with the SASL mechanism chosen by 1213 the initiating entity). 1215 6. If necessary, the receiving entity sends more challenges and the 1216 initiating entity sends more responses. 1218 This series of challenge/response pairs continues until one of three 1219 things happens: 1221 1. The initiating entity aborts the handshake by sending an 1222 element qualified by the 'urn:ietf:params:xml:ns:xmpp-sasl' 1223 namespace to the receiving entity. Upon receiving the 1224 element, the receiving entity MUST terminate the TCP connection. 1226 2. The receiving entity reports failure of the handshake by sending 1227 a element qualified by the 1228 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating 1229 entity (the particular cause of failure SHOULD be communicated in 1230 an appropriate child element of the element as defined 1231 under SASL Errors (Section 6.3)). Immediately after sending the 1232 element, the receiving entity MUST terminate the TCP 1233 connection. 1235 3. The receiving entity reports success of the handshake by sending 1236 a element qualified by the 1237 'urn:ietf:params:xml:ns:xmpp-sasl' namespace to the initiating 1238 entity; this element MAY optionally contain character data (in 1239 SASL terminology "additional data with success"). Upon receiving 1240 the element, the initiating entity MUST initiate a new 1241 stream by sending an opening XML stream header to the receiving 1242 entity (it is not necessary to send a closing 1243 element first, since the receiving entity and initiating entity 1244 MUST consider the original stream to be closed upon sending or 1245 receiving the element). Upon receiving the new stream 1246 header from the initiating entity, the receiving entity MUST 1247 respond by sending a new XML stream header to the initiating 1248 entity, along with any remaining available features (but NOT 1249 including the STARTTLS feature or any authentication mechanisms) 1250 or an empty features element (to signify that no additional 1251 features are available); note that any such additional features 1252 are not defined herein, and MUST be defined by the relevant 1253 extension to XMPP. 1255 6.3 SASL Errors 1257 The following SASL-related error conditions are defined: 1259 o -- The receiving entity acknowledges an 1260 element sent by the initiating entity; sent in response to the 1261 element. 1263 o -- The data provided by the initiating entity 1264 could not be processed, e.g. because does not adhere to the 1265 protocol for the requested mechanism; sent in response to the 1266 element. 1268 o -- The mechanism chosen by the initiating 1269 entity may be used only if the stream is already encrypted; sent 1270 in response to the element. 1272 o -- The authzid provided by the initiating 1273 entity is invalid, either because it is incorrectly formatted or 1274 because the initiating entity does not have permissions to 1275 authorize that ID; sent in response to a element. 1277 o -- The initiating entity did not provide a 1278 mechanism or requested a mechanism that is not supported by the 1279 receiving entity; sent in response to the element. 1281 o -- The realm provided by the initiating entity 1282 (in mechanisms that support the concept of a realm) does not match 1283 one of the hostnames served by the receiving entity; sent in 1284 response to a element. 1286 o -- The mechanism requested by the initiating 1287 entity is weaker than server policy permits for that initiating 1288 entity; sent in response to the element. 1290 o -- The authentication failed because the 1291 initiating entity did not provide valid credentials (this includes 1292 the case of an unknown username); sent in response to a element. 1295 o -- The authentication failed because of 1296 a temporary error condition within the receiving entity; sent in 1297 response to an element or element. 1299 6.4 SASL Definition 1301 Section 4 of the SASL specification [15] requires that the following 1302 information be supplied by a protocol definition: 1304 service name: "xmpp" 1306 initiation sequence: After the initiating entity provides an opening 1307 XML stream header and the receiving entity replies in kind, the 1308 receiving entity provides a list of acceptable authentication 1309 methods. The initiating entity chooses one method from the list 1310 and sends it to the receiving entity as the value of the 1311 'mechanism' attribute possessed by an element, optionally 1312 including an initial response to avoid a round trip. 1314 exchange sequence: Challenges and responses are carried through the 1315 exchange of elements from receiving entity to 1316 initiating entity and elements from initiating entity 1317 to receiving entity. The receiving entity reports failure by 1318 sending a element and success by sending a 1319 element; the initiating entity aborts the exchange by sending an 1320 element. (All of these elements are qualified by the 1321 'urn:ietf:params:xml:ns:xmpp-sasl' namespace.) Upon successful 1322 negotiation, both sides consider the original XML stream closed 1323 and new headers are sent by both entities. 1325 security layer negotiation: The security layer takes effect 1326 immediately after sending the closing ">" character of the 1327 element for the server, and immediately after receiving 1328 the closing ">" character of the element for the client 1329 (this element is qualified by the 1330 'urn:ietf:params:xml:ns:xmpp-sasl' namespace). 1332 use of the authorization identity: The authorization identity is used 1333 by xmpp to denote the "full JID" () of a 1334 client or the sending domain of a server. 1336 6.5 Client-to-Server Example 1338 The following example shows the data flow for a client authenticating 1339 with a server using SASL (the IANA-registered port 5222 SHOULD be 1340 used; see IANA Considerations (Section 10)). 1342 Step 1: Client initiates stream to server: 1344 1350 Step 2: Server responds with a stream tag sent to client: 1352 1359 Step 3: Server informs client of available authentication mechanisms: 1361 1362 1363 DIGEST-MD5 1364 PLAIN 1365 1366 1368 Step 4: Client selects an authentication mechanism: 1370 1374 Step 5: Server sends a base64-encoded challenge to client: 1376 1377 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 1378 xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz 1379 1381 The decoded challenge is: 1383 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ 1384 qop="auth",charset=utf-8,algorithm=md5-sess 1385 Step 5 (alt): Server returns error to client: 1387 1388 1389 1391 Step 6: Client responds to the challenge: 1393 1394 dXNlcm5hbWU9InJvYiIscmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik 1395 9BNk1HOXRFUUdtMmhoIixjbm9uY2U9Ik9BNk1IWGg2VnFUclJrIixuYz0w 1396 MDAwMDAwMSxxb3A9YXV0aCxkaWdlc3QtdXJpPSJ4bXBwL2NhdGFjbHlzbS 1397 5jeCIscmVzcG9uc2U9ZDM4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZjIxNDNh 1398 ZjcsY2hhcnNldD11dGYtOCxhdXRoemlkPSJyb2JAY2F0YWNseXNtLmN4L2 1399 15UmVzb3VyY2Ui 1400 1402 The decoded response is: 1404 username="rob",realm="cataclysm.cx",\ 1405 nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\ 1406 nc=00000001,qop=auth,digest-uri="xmpp/cataclysm.cx",\ 1407 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8,\ 1408 authzid="rob@cataclysm.cx/myResource" 1410 Step 7: Server sends another challenge to client: 1412 1413 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 1414 1416 The decoded challenge is: 1418 rspauth=ea40f60335c427b5527b84dbabcdfffd 1420 Step 7 (alt): Server returns error to client: 1422 1423 1424 1426 Step 8: Client responds to the challenge: 1428 1429 Step 9: Server informs client of successful authentication: 1431 1433 Step 9 (alt): Server informs client of failed authentication: 1435 1436 1437 1439 Step 10: Client initiates a new stream to server: 1441 1447 Step 11: Server responds by sending a stream header to client along 1448 with any additional features (or an empty features element): 1450 1456 1458 6.6 Server-to-Server Example 1460 The following example shows the data flow for a server authenticating 1461 with another server using SASL (the IANA-registered port 5269 SHOULD 1462 be used; see IANA Considerations (Section 10)). 1464 Step 1: Server1 initiates stream to Server2: 1466 1472 Step 2: Server2 responds with a stream tag sent to Server1: 1474 1481 Step 3: Server2 informs Server1 of available authentication 1482 mechanisms: 1484 1485 1486 DIGEST-MD5 1487 KERBEROS_V4 1488 1489 1491 Step 4: Server1 selects an authentication mechanism: 1493 1497 Step 5: Server2 sends a base64-encoded challenge to Server1: 1499 1500 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 1501 xxb3A9ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz 1502 1504 The decoded challenge is: 1506 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",\ 1507 qop="auth",charset=utf-8,algorithm=md5-sess 1509 Step 5 (alt): Server2 returns error to Server1: 1511 1512 1513 1514 Step 6: Server1 responds to the challenge: 1516 1517 cmVhbG09ImNhdGFjbHlzbS5jeCIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIi 1518 xjbm9uY2U9Ik9BNk1IWGg2VnFUclJrIixuYz0wMDAwMDAwMSxxb3A9YXV0 1519 aCxkaWdlc3QtdXJpPSJ4bXBwL2NhdGFjbHlzbS5jeCIscmVzcG9uc2U9ZD 1520 M4OGRhZDkwZDRiYmQ3NjBhMTUyMzIxZjIxNDNhZjcsY2hhcnNldD11dGYt 1521 OAo= 1522 1524 The decoded response is: 1526 realm="cataclysm.cx",nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\ 1527 nc=00000001,qop=auth,digest-uri="xmpp/cataclysm.cx",\ 1528 response=d388dad90d4bbd760a152321f2143af7,charset=utf-8 1530 Step 7: Server2 sends another challenge to Server1: 1532 1533 cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZA== 1534 1536 The decoded challenge is: 1538 rspauth=ea40f60335c427b5527b84dbabcdfffd 1540 Step 5 (alt): Server2 returns error to Server1: 1542 1543 1544 1546 Step 8: Server1 responds to the challenge: 1548 1550 Step 9: Server2 informs Server1 of successful authentication: 1552 1554 Step 9 (alt): Server2 informs Server1 of failed authentication: 1556 1557 1558 1559 Step 10: Server1 initiates a new stream to Server2: 1561 1567 Step 11: Server2 responds by sending a stream header to Server1 along 1568 with any additional features (or an empty features element): 1570 1576 1578 7. Server Dialback 1580 7.1 Overview 1582 The Jabber protocol from which XMPP was adapted includes a "server 1583 dialback" method for protecting against domain spoofing, thus making 1584 it more difficult to spoof XML stanzas (see Server-to-Server 1585 Communications (Section 12.3) regarding this method's security 1586 characteristics). Server dialback also makes it easier to deploy 1587 systems in which outbound messages and inbound messages are handled 1588 by different machines for the same domain. The server dialback method 1589 is made possible by the existence of DNS, since one server can 1590 (normally) discover the authoritative server for a given domain. 1592 Because dialback depends on the Domain Name System, inter-domain 1593 communications MUST NOT proceed until the DNS hostnames asserted by 1594 the servers have been resolved (see Server-to-Server Communications 1595 (Section 12.3)). 1597 The method for generating and verifying the keys used in server 1598 dialback MUST take into account the hostnames being used, the random 1599 ID generated for the stream, and a secret known by the authoritative 1600 server's network. 1602 Any error that occurs during dialback negotiation MUST be considered 1603 a stream error, resulting in termination of the stream and of the 1604 underlying TCP connection. The possible error conditions are 1605 specified in the protocol description below. 1607 The following terminology applies: 1609 o Originating Server -- the server that is attempting to establish a 1610 connection between two domains. 1612 o Receiving Server -- the server that is trying to authenticate that 1613 Originating Server represents the domain which it claims to be. 1615 o Authoritative Server -- the server that answers to the DNS 1616 hostname asserted by Originating Server; for basic environments 1617 this will be Originating Server, but it could be a separate 1618 machine in Originating Server's network. 1620 The following is a brief summary of the order of events in dialback: 1622 1. Originating Server establishes a connection to Receiving Server. 1624 2. Originating Server sends a 'key' value over the connection to 1625 Receiving Server. 1627 3. Receiving Server establishes a connection to Authoritative 1628 Server. 1630 4. Receiving Server sends the same 'key' value to Authoritative 1631 Server. 1633 5. Authoritative Server replies that key is valid or invalid. 1635 6. Receiving Server informs Originating Server whether it is 1636 authenticated or not. 1638 We can represent this flow of events graphically as follows: 1640 Originating Receiving 1641 Server Server 1642 ----------- --------- 1643 | | 1644 | establish connection | 1645 | ----------------------> | 1646 | | 1647 | send stream header | 1648 | ----------------------> | 1649 | | 1650 | send stream header | 1651 | <---------------------- | 1652 | | Authoritative 1653 | send dialback key | Server 1654 | ----------------------> | ------------- 1655 | | | 1656 | establish connection | 1657 | ----------------------> | 1658 | | 1659 | send stream header | 1660 | ----------------------> | 1661 | | 1662 | establish connection | 1663 | <---------------------- | 1664 | | 1665 | send stream header | 1666 | <---------------------- | 1667 | | 1668 | send dialback key | 1669 | ----------------------> | 1670 | | 1671 | validate dialback key | 1672 | <---------------------- | 1673 | 1674 | report dialback result | 1675 | <---------------------- | 1676 | | 1678 7.2 Protocol 1680 The interaction between the servers is as follows: 1682 1. Originating Server establishes TCP connection to Receiving 1683 Server. 1685 2. Originating Server sends a stream header to Receiving Server: 1687 1692 Note: the 'to' and 'from' attributes are NOT REQUIRED on the 1693 root stream element. The inclusion of the xmlns:db namespace 1694 declaration with the name shown indicates to Receiving Server 1695 that Originating Server supports dialback. If the namespace name 1696 is incorrect, then Receiving Server MUST generate an 1697 stream error condition and terminate both 1698 the XML stream and the underlying TCP connection. 1700 3. Receiving Server SHOULD send a stream header back to Originating 1701 Server, including a unique ID for this interaction: 1703 1709 Note: The 'to' and 'from' attributes are NOT REQUIRED on the 1710 root stream element. If the namespace name is incorrect, then 1711 Originating Server MUST generate an stream 1712 error condition and terminate both the XML stream and the 1713 underlying TCP connection. Note well that Receiving Server is 1714 NOT REQUIRED to reply and MAY silently terminate the XML stream 1715 and underlying TCP connection depending on security policies in 1716 place. 1718 4. Originating Server sends a dialback key to Receiving Server: 1720 1723 98AF014EDC0... 1724 1726 Note: this key is not examined by Receiving Server, since 1727 Receiving Server does not keep information about Originating 1728 Server between sessions. The key generated by Originating Server 1729 MUST be based in part on the value of the ID provided by 1730 Receiving Server in the previous step, and in part on a secret 1731 shared by Originating Server and Authoritative Server. If the 1732 value of the 'to' address does not match a hostname recognized 1733 by Receiving Server, then Receiving Server MUST generate a 1734 stream error condition and terminate both the 1735 XML stream and the underlying TCP connection. If the value of 1736 the 'from' address matches a domain with which Receiving Server 1737 already has an established connection, then Receiving Server 1738 MUST maintain the existing connection until it validates whether 1739 the new connection is legitimate; additionally, Receiving Server 1740 MAY choose to generate a stream error 1741 condition for the new connection and then terminate both the XML 1742 stream and the underlying TCP connection related to the new 1743 request. 1745 5. Receiving Server establishes a TCP connection back to the domain 1746 name asserted by Originating Server, as a result of which it 1747 connects to Authoritative Server. (Note: as an optimization, an 1748 implementation MAY reuse an existing trusted connection here 1749 rather than opening a new TCP connection.) 1751 6. Receiving Server sends Authoritative Server a stream header: 1753 1758 Note: the 'to' and 'from' attributes are NOT REQUIRED on the 1759 root stream element. If the namespace name is incorrect, then 1760 Authoritative Server MUST generate an 1761 stream error condition and terminate both the XML stream and the 1762 underlying TCP connection. 1764 7. Authoritative Server sends Receiving Server a stream header: 1766 1772 Note: if the namespace name is incorrect, then Receiving Server 1773 MUST generate an stream error condition and 1774 terminate both the XML stream and the underlying TCP connection 1775 between it and Authoritative Server. If the ID does not match 1776 that provided by Receiving Server in Step 3, then Receiving 1777 Server MUST generate an stream error condition and 1778 terminate both the XML stream and the underlying TCP connection 1779 between it and Authoritative Server. If either of the foregoing 1780 stream errors occurs between Receiving Server and Authoritative 1781 Server, then Receiving Server MUST generate a 1782 stream error condition and terminate 1783 both the XML stream and the underlying TCP connection between it 1784 and Originating Server. 1786 8. Receiving Server sends Authoritative Server a stanza requesting 1787 that Authoritative Server verify a key: 1789 1793 98AF014EDC0... 1794 1796 Note: passed here are the hostnames, the original identifier 1797 from Receiving Server's stream header to Originating Server in 1798 Step 3, and the key that Originating Server sent to Receiving 1799 Server in Step 4. Based on this information as well as shared 1800 secret information within the Authoritative Server's network, 1801 the key is verified. Any verifiable method MAY be used to 1802 generate the key. If the value of the 'to' address does not 1803 match a hostname recognized by Authoritative Server, then 1804 Authoritative Server MUST generate a stream 1805 error condition and terminate both the XML stream and the 1806 underlying TCP connection. If the value of the 'from' address 1807 does not match the hostname represented by Receiving Server when 1808 opening the TCP connection (or any validated domain), then 1809 Authoritative Server MUST generate a stream 1810 error condition and terminate both the XML stream and the 1811 underlying TCP connection. 1813 9. Authoritative Server sends a stanza back to Receiving Server 1814 verifying whether the key was valid or invalid: 1816 1822 or 1824 1830 Note: if the ID does not match that provided by Receiving Server 1831 in Step 3, then Receiving Server MUST generate an 1832 stream error condition and terminate both the XML stream and the 1833 underlying TCP connection. If the value of the 'to' address does 1834 not match a hostname recognized by Receiving Server, then 1835 Receiving Server MUST generate a stream error 1836 condition and terminate both the XML stream and the underlying 1837 TCP connection. If the value of the 'from' address does not 1838 match the hostname represented by Originating Server when 1839 opening the TCP connection (or any validated domain), then 1840 Receiving Server MUST generate a stream 1841 error condition and terminate both the XML stream and the 1842 underlying TCP connection. 1844 10. Receiving Server informs Originating Server of the result: 1846 1851 Note: At this point the connection has either been validated via 1852 a type='valid', or reported as invalid. If the connection is 1853 invalid, then Receiving Server MUST terminate both the XML 1854 stream and the underlying TCP connection. If the connection is 1855 validated, data can be sent by Originating Server and read by 1856 Receiving Server; before that, all data stanzas sent to 1857 Receiving Server SHOULD be silently dropped. 1859 Even if dialback negotiation is successful, a server MUST verify that 1860 all XML stanzas received from the other server include a 'from' 1861 attribute and a 'to' attribute; if a stanza does not meet this 1862 restriction, the server that receives the stanza MUST generate an 1863 stream error condition and terminate both the 1864 XML stream and the underlying TCP connection. Furthermore, a server 1865 MUST verify that the 'from' attribute of stanzas received from the 1866 other server includes a validated domain for the stream; if a stanza 1867 does not meet this restriction, the server that receives the stanza 1868 MUST generate a stream error condition and 1869 terminate both the XML stream and the underlying TCP connection. Both 1870 of these checks help to prevent spoofing related to particular 1871 stanzas. 1873 8. XML Stanzas 1875 8.1 Overview 1877 Once XML streams in both directions have been authenticated and (if 1878 desired) encrypted, XML stanzas can be sent over the streams. Three 1879 XML stanza types are defined for the 'jabber:client' and 1880 'jabber:server' namespaces: , , and . 1882 In essence, the stanza type can be seen as a "push" 1883 mechanism whereby one entity pushes information to another entity, 1884 similar to the communications that occur in a system such as email. 1885 The element can be seen as a basic broadcast or 1886 "publish-subscribe" mechanism, whereby multiple entities receive 1887 information (in this case, presence information) about an entity to 1888 which they have subscribed. The element can be seen as a 1889 "request-response" mechanism similar to HTTP, whereby two entities 1890 can engage in a structured conversation using 'get' or 'set' requests 1891 and 'result' or 'error' responses. 1893 8.2 Common Attributes 1895 The following five attributes are common to message, presence, and IQ 1896 stanzas: 1898 8.2.1 to 1900 The 'to' attribute specifies the JID of the intended recipient for 1901 the stanza. 1903 In the 'jabber:client' namespace, a stanza SHOULD possess a 'to' 1904 attribute, although a stanza sent from a client to a server for 1905 handling by that server (e.g., presence sent to the server for 1906 broadcasting to other entities) SHOULD NOT possess a 'to' attribute. 1908 In the 'jabber:server' namespace, a stanza MUST possess a 'to' 1909 attribute; if a server receives a stanza that does not meet this 1910 restriction, it MUST generate an stream error 1911 condition and terminate both the XML stream and the underlying TCP 1912 connection with the offending server. 1914 If the value of the 'to' attribute is invalid or cannot be contacted, 1915 the entity discovering that fact (usually the sender's or recipient's 1916 server) MUST return an appropriate error to the sender. 1918 8.2.2 from 1920 The 'from' attribute specifies the JID of the sender. 1922 In the 'jabber:client' namespace, a client MUST NOT include a 'from' 1923 attribute on the stanzas it sends to a server; if a server receives 1924 an XML stanza from a client and the stanza possesses a 'from' 1925 attribute, it MUST ignore the value of the 'from' attribute and MAY 1926 return an error to the sender. When a client sends an XML stanza 1927 within the context of an authenticated stream, the server MUST stamp 1928 the stanza with the full JID () of the 1929 connected resource that generated the stanza as defined by the 1930 authzid provided in the SASL negotiation. If a client attempts to 1931 send an XML stanza before the stream is authenticated, the server 1932 SHOULD return a stream error to the client and then 1933 terminate both the XML stream and the underlying TCP connection. 1935 In the 'jabber:server' namespace, a stanza MUST possess a 'from' 1936 attribute; if a server receives a stanza that does not meet this 1937 restriction, it MUST generate an stream error 1938 condition. Furthermore, the domain identifier portion of the JID 1939 contained in the 'from' attribute MUST match the hostname of the 1940 sending server (or any validated domain) as communicated in the SASL 1941 negotiation or dialback negotiation; if a server receives a stanza 1942 that does not meet this restriction, it MUST generate a 1943 stream error condition. Both of these conditions 1944 MUST result in closing of the stream and termination of the 1945 underlying TCP connection. 1947 8.2.3 id 1949 The optional 'id' attribute MAY be used by a sending entity for 1950 internal tracking of stanzas that it sends and receives (especially 1951 for tracking the request-response interaction inherent in the use of 1952 IQ stanzas). The 'id' attribute is required for IQ stanzas. If the 1953 stanza sent by the sending entity is an IQ stanza of type "get" or 1954 "set", the receiving entity MUST include an 'id' attribute with the 1955 same value in any replies of type "result" or "error". The value of 1956 the 'id' attribute is NOT REQUIRED to be unique either globally, 1957 within a domain, or within a stream. 1959 8.2.4 type 1961 The 'type' attribute specifies detailed information about the purpose 1962 or context of the message, presence, or IQ stanza. The particular 1963 allowable values for the 'type' attribute vary depending on whether 1964 the stanza is a message, presence, or IQ, and thus are defined in the 1965 following sections. 1967 8.2.5 xml:lang 1969 A stanza SHOULD possess an 'xml:lang' attribute (as defined in 1970 Section 2.12 of the XML specification [1]) if the stanza contains XML 1971 character data that is intended to be presented to a human user (as 1972 explained in RFC 2277 [31], "internationalization is for humans"). 1973 The value of the 'xml:lang' attribute specifies the default language 1974 of any such XML character data, which MAY be overridden by the 1975 'xml:lang' attribute of a specific child element. The value of the 1976 attribute MUST be an NMTOKEN and MUST conform to the format defined 1977 in RFC 3066 [17]. 1979 8.3 Message Stanzas 1981 Message stanzas in the 'jabber:client' or 'jabber:server' namespace 1982 are used to "push" information to another entity. Common uses in the 1983 context of instant messaging include single messages, messages sent 1984 in the context of a chat conversation, messages sent in the context 1985 of a multi-user chat room, headlines, and errors. 1987 8.3.1 Types of Message 1989 The 'type' attribute of a message stanza is RECOMMENDED; if included, 1990 it specifies the conversational context of the message. The 'type' 1991 attribute SHOULD have one of the following values: 1993 o chat 1995 o error 1997 o groupchat 1999 o headline 2001 o normal 2003 A message stanza with a different value, or without a 'type' 2004 attribute, SHOULD be handled as if the 'type' were "normal". 2006 For information regarding the meaning of these message types in the 2007 context of XMPP-based instant messaging and presence applications, 2008 refer to XMPP IM [23]. 2010 8.3.2 Children 2012 As described under extended namespaces (Section 8.6), a message 2013 stanza MAY contain any properly-namespaced child element. 2015 In accordance with the default namespace declaration, by default a 2016 message stanza is in the 'jabber:client' or 'jabber:server' 2017 namespace, which defines certain allowable children of message 2018 stanzas. If the message stanza is of type "error", it MUST include an 2019 child; for details, see Stanza Errors (Section 8.7). 2020 Otherwise, the message stanza MAY contain any of the following child 2021 elements without an explicit namespace declaration: 2023 1. 2025 2. 2027 3. 2029 8.3.2.1 Subject 2031 The element specifies the topic of the message. The 2032 element SHOULD NOT possess any attributes, with the 2033 exception of the 'xml:lang' attribute. Multiple instances of the 2034 element MAY be included for the purpose of providing 2035 alternate versions of the same subject, but only if each instance 2036 possesses an 'xml:lang' attribute with a distinct language value. The 2037 element MUST NOT contain mixed content. 2039 8.3.2.2 Body 2041 The element contains the textual contents of the message; 2042 this child element is normally included but NOT REQUIRED. The 2043 element SHOULD NOT possess any attributes, with the exception of the 2044 'xml:lang' attribute. Multiple instances of the element MAY 2045 be included but only if each instance possesses an 'xml:lang' 2046 attribute with a distinct language value. The element MUST 2047 NOT contain mixed content. 2049 8.3.2.3 Thread 2051 The element contains a string that is generated by the 2052 sender and that SHOULD be copied back in replies; it is used for 2053 tracking a conversation thread (sometimes referred to as an "instant 2054 messaging session") between two entities. If used, it MUST be unique 2055 to that conversation thread within the stream and MUST be consistent 2056 throughout that conversation (a client that receives a message from 2057 the same full JID but with a different thread ID MUST assume that the 2058 message in question exists outside the context of the existing 2059 conversation thread). The use of the element is OPTIONAL 2060 and is not used to identify individual messages, only conversations. 2061 Only one element MAY be included in a message stanza, and 2062 it MUST NOT possess any attributes. The element MUST be 2063 treated as an opaque string by entities; no semantic meaning may be 2064 derived from it, and only exact comparisons may be made against it. 2066 The element MUST NOT contain mixed content. 2068 8.4 Presence Stanzas 2070 Presence stanzas are used in the 'jabber:client' or 'jabber:server' 2071 namespace to express an entity's current availability status (offline 2072 or online, along with various sub-states of the latter and optional 2073 user-defined descriptive text) and to communicate that status to 2074 other entities. Presence stanzas are also used to negotiate and 2075 manage subscriptions to the presence of other entities. 2077 8.4.1 Types of Presence 2079 The 'type' attribute of a presence stanza is OPTIONAL. A presence 2080 stanza that does not possess a 'type' attribute is used to signal to 2081 the server that the sender is online and available for communication. 2082 If included, the 'type' attribute specifies a lack of availability, a 2083 request to manage a subscription to another entity's presence, a 2084 request for another entity's current presence, or an error related to 2085 a previously-sent presence stanza. The 'type' attribute MAY have one 2086 of the following values: 2088 o unavailable -- Signals that the entity is no longer available for 2089 communication. 2091 o subscribe -- The sender wishes to subscribe to the recipient's 2092 presence. 2094 o subscribed -- The sender has allowed the recipient to receive 2095 their presence. 2097 o unsubscribe -- A notification that an entity is unsubscribing from 2098 another entity's presence. 2100 o unsubscribed -- The subscription request has been denied or a 2101 previously-granted subscription has been cancelled. 2103 o probe -- A request for an entity's current presence; in general, 2104 SHOULD NOT be sent by a client. 2106 o error -- An error has occurred regarding processing or delivery of 2107 a previously-sent presence stanza. 2109 For information regarding presence semantics and the subscription 2110 model used in the context of XMPP-based instant messaging and 2111 presence applications, refer to XMPP IM [23]. 2113 8.4.2 Children 2115 As described under extended namespaces (Section 8.6), a presence 2116 stanza MAY contain any properly-namespaced child element. 2118 In accordance with the default namespace declaration, by default a 2119 presence stanza is in the 'jabber:client' or 'jabber:server' 2120 namespace, which defines certain allowable children of presence 2121 stanzas. If the presence stanza is of type "error", it MUST include 2122 an child; for details, see Stanza Errors (Section 8.7). If 2123 the presence stanza possesses no 'type' attribute, it MAY contain any 2124 of the following child elements (note that the child MAY be 2125 sent in a presence stanza of type "unavailable" or, for historical 2126 reasons, "subscribe"): 2128 1. 2130 2. 2132 3. 2134 8.4.2.1 Show 2136 The OPTIONAL element specifies the particular availability 2137 status of an entity or specific resource (if a element is not 2138 provided, default availability is assumed). Only one element 2139 MAY be included in a presence stanza, and it SHOULD NOT possess any 2140 attributes. The CDATA value SHOULD be one of the following (values 2141 other than these four SHOULD be ignored; additional availability 2142 types could be defined through a properly-namespaced child element of 2143 the presence stanza): 2145 o away 2147 o chat 2149 o dnd 2151 o xa 2153 For information regarding the meaning of these values in the context 2154 of XMPP-based instant messaging and presence applications, refer to 2155 XMPP IM [23]. 2157 8.4.2.2 Status 2159 The OPTIONAL element contains a natural-language 2160 description of availability status. It is normally used in 2161 conjunction with the show element to provide a detailed description 2162 of an availability state (e.g., "In a meeting"). The 2163 element SHOULD NOT possess any attributes, with the exception of the 2164 'xml:lang' attribute. Multiple instances of the element MAY 2165 be included but only if each instance possesses an 'xml:lang' 2166 attribute with a distinct language value. 2168 8.4.2.3 Priority 2170 The OPTIONAL element specifies the priority level of the 2171 connected resource. The value may be any integer between -128 and 2172 +127. Only one element MAY be included in a presence 2173 stanza, and it MUST NOT possess any attributes. If no priority is 2174 provided, a server SHOULD consider the priority to be zero. For 2175 information regarding the semantics of priority values in stanza 2176 routing within instant messaging applications, refer to XMPP IM [23]. 2178 8.5 IQ Stanzas 2180 8.5.1 Overview 2182 Info/Query, or IQ, is a request-response mechanism, similar in some 2183 ways to HTTP [32]. IQ stanzas in the 'jabber:client' or 2184 'jabber:server' namespace enable an entity to make a request of, and 2185 receive a response from, another entity. The data content of the 2186 request and response is defined by the namespace declaration of a 2187 direct child element of the IQ element, and the interaction is 2188 tracked by the requesting entity through use of the 'id' attribute. 2190 Most IQ interactions follow a common pattern of structured data 2191 exchange such as get/result or set/result (although an error may be 2192 returned in response to a request if appropriate): 2194 Requesting Responding 2195 Entity Entity 2196 ---------- ---------- 2197 | | 2198 | | 2199 | ------------------------> | 2200 | | 2201 | | 2202 | <------------------------ | 2203 | | 2204 | | 2205 | ------------------------> | 2206 | | 2207 | | 2208 | <------------------------ | 2209 | | 2211 The 'id' attribute is REQUIRED for IQ stanzas. An entity that 2212 receives an IQ request of type "get" or "set" MUST reply with an IQ 2213 response of type "result" or "error" (which response MUST preserve 2214 the 'id' attribute of the request). An entity that receives a stanza 2215 of type "result" or "error" MUST NOT respond to the stanza by sending 2216 a further IQ response of type "result" or "error"; however, as shown 2217 above, the requesting entity MAY send another request (e.g., an IQ of 2218 type "set" in order to provide required information discovered 2219 through a get/result pair). 2221 8.5.2 Types of IQ 2223 The 'type' attribute of an IQ stanza is REQUIRED. The 'type' 2224 attribute specifies a distinct step within a request-response 2225 interaction. The value SHOULD be one of the following (all other 2226 values SHOULD be ignored): 2228 o get -- The stanza is a request for information or requirements. 2230 o set -- The stanza provides required data, sets new values, or 2231 replaces existing values. 2233 o result -- The stanza is a response to a successful get or set 2234 request. 2236 o error -- An error has occurred regarding processing or delivery of 2237 a previously-sent get or set. 2239 8.5.3 Children 2241 As described under extended namespaces (Section 8.6), an IQ stanza 2242 MAY contain any properly-namespaced child element. Note that an IQ 2243 stanza of type "get", "set", or "result" contains no children in the 2244 'jabber:client' or 'jabber:server' namespace since it is a vessel for 2245 XML in another namespace. 2247 An IQ stanza of type "get" or "set" MUST include one and only one 2248 child element. An IQ stanza of type "result" MUST include zero or one 2249 child elements. An IQ stanza of type "error" SHOULD include the child 2250 element contained in the associated "get" or "set" and MUST include 2251 an child; for details, see Stanza Errors (Section 8.7). 2253 8.6 Extended Namespaces 2255 While the three XML stanza types defined in the "jabber:client" or 2256 "jabber:server" namespace (along with their attributes and child 2257 elements) provide a basic level of functionality for messaging and 2258 presence, XMPP uses XML namespaces to extend the stanzas for the 2259 purpose of providing additional functionality. Thus a message, 2260 presence, or IQ stanza MAY house one or more optional child elements 2261 containing content that extends the meaning of the message (e.g., an 2262 XHTML-formatted version of the message body). This child element MAY 2263 have any name and MUST possess an 'xmlns' namespace declaration 2264 (other than "jabber:client", "jabber:server", or "http:// 2265 etherx.jabber.org/streams") that defines all data contained within 2266 the child element. 2268 Support for any given extended namespace is OPTIONAL on the part of 2269 any implementation. If an entity does not understand such a 2270 namespace, the entity's expected behavior depends on whether the 2271 entity is (1) the recipient or (2) an entity that is routing the 2272 stanza to the recipient: 2274 Recipient: If a recipient receives a stanza that contains a child 2275 element it does not understand, it SHOULD ignore that specific XML 2276 data, i.e., it SHOULD not process it or present it to a user or 2277 associated application (if any). In particular: 2279 * If an entity receives a message or presence stanza that 2280 contains XML data qualified by a namespace it does not 2281 understand, the portion of the stanza that is in the unknown 2282 namespace SHOULD be ignored. 2284 * If an entity receives a message stanza containing only a child 2285 element qualified by a namespace it does not understand, it 2286 MUST ignore the entire stanza. 2288 * If an entity receives an IQ stanza of type "get" or "set" 2289 containing a child element qualified by a namespace it does not 2290 understand, the entity SHOULD return an IQ stanza of type 2291 "error" with an error condition of . 2293 Router: If a routing entity (usually a server) handles a stanza that 2294 contains a child element it does not understand, it SHOULD ignore 2295 the associated XML data by passing it on untouched to the 2296 recipient. 2298 8.7 Stanza Errors 2300 Stanza-related errors are handled in a manner similar to stream 2301 errors (Section 4.6), except that hints are also provided to the 2302 receiving application regarding actions to take in reponse to the 2303 error. 2305 8.7.1 Rules 2307 The following rules apply to stanza-related errors: 2309 o A stanza whose 'type' attribute has a value of "error" MUST 2310 contain an child element. 2312 o The receiving or processing entity that returns an error to the 2313 sending entity SHOULD include the original XML sent so that the 2314 sender can inspect and if necessary correct the XML before 2315 re-sending. 2317 o An entity that receives a stanza whose 'type' attribute has a 2318 value of "error" MUST NOT respond to the stanza with a further 2319 stanza of type "error"; this helps to prevent looping. 2321 o An child MUST NOT be included if the 'type' attribute has 2322 a value other than "error" (or if there is no 'type' attribute). 2324 8.7.2 Syntax 2326 The syntax for stanza-related errors is as follows: 2328 2329 [RECOMMENDED to include sender XML here] 2330 2331 2332 2333 OPTIONAL descriptive text 2334 2335 [OPTIONAL application-specific condition element] 2336 2337 2339 The stanza-name is one of message, presence, or iq. 2341 The value of the element's 'type' attribute MUST be one of 2342 the following: 2344 o cancel -- do not retry (the error is unrecoverable) 2346 o continue -- proceed (the condition was only a warning) 2348 o modify -- retry after changing the data sent 2350 o auth -- retry after providing credentials 2352 o wait -- retry after waiting (the error is temporary) 2354 The element: 2356 o MUST contain a child element corresponding to one of the defined 2357 stanza error conditions defined below; this element MUST be 2358 qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace 2360 o MAY contain a child containing CDATA that describes the 2361 error in more detail; this element MUST be qualified by the 2362 'urn:ietf:params:xml:ns:xmpp-stanzas' namespace and SHOULD possess 2363 an 'xml:lang' attribute 2365 o MAY contain a child element for an application-specific error 2366 condition; this element MUST be qualified by an 2367 application-defined namespace, and its structure is defined by 2368 that namespace 2370 The element is OPTIONAL. If included, it SHOULD be used only 2371 to provide descriptive or diagnostic information that supplements the 2372 meaning of a defined condition or application-specific condition. It 2373 SHOULD NOT be interpreted programmatically by an application. It 2374 SHOULD NOT be used as the error message presented to user, but MAY be 2375 shown in addition to the error message associated with the included 2376 condition element (or elements). 2378 Note: the XML namespace name 'urn:ietf:params:xml:ns:xmpp-stanzas' 2379 that qualifies the descriptive element adheres to the format defined 2380 in The IETF XML Registry [25]. 2382 8.7.3 Defined Conditions 2384 The following stanza-related error conditions are defined for use in 2385 stanza errors. 2387 o -- the sender has sent XML that is malformed or 2388 that cannot be processed (e.g., a client-generated stanza includes 2389 a 'from' address, or an IQ stanza includes an unrecognized value 2390 of the 'type' attribute); the associated error type SHOULD be 2391 "modify". 2393 o -- access cannot be granted because an existing 2394 resource or session exists with the same name or address; the 2395 associated error type SHOULD be "cancel". 2397 o -- the feature requested is not 2398 implemented by the recipient or server and therefore cannot be 2399 processed; the associated error type SHOULD be "cancel". 2401 o -- the requesting entity does not possess the 2402 required permissions to perform the action; the associated error 2403 type SHOULD be "auth". 2405 o -- the server could not process the 2406 stanza because of a misconfiguration or an otherwise-undefined 2407 internal server error; the associated error type SHOULD be "wait". 2409 o -- the addressed JID or item requested cannot be 2410 found; the associated error type SHOULD be "cancel". 2412 o -- the value of the 'to' attribute in the 2413 sender's stanza does not adhere to the syntax defined in 2414 Addressing Scheme (Section 3); the associated error type SHOULD be 2415 "modify". 2417 o -- the recipient does not allow any entity to 2418 perform the action; the associated error type SHOULD be "cancel". 2420 o -- the specific recipient requested is 2421 currently unavailable; the associated error type SHOULD be "wait". 2423 o -- the user is not authorized to access 2424 the requested service because registration is required; the 2425 associated error type SHOULD be "auth". 2427 o -- a remote server or service specified 2428 as part or all of the JID of the intended recipient does not 2429 exist; the associated error type SHOULD be "cancel". 2431 o -- a remote server or service specified 2432 as part or all of the JID of the intended recipient could not be 2433 contacted within a reasonable amount of time; the associated error 2434 type SHOULD be "wait". 2436 o -- the server is resource-contrained and is 2437 unable to service the request; the associated error type SHOULD be 2438 "wait". 2440 o -- the service requested is currently 2441 unavailable on the server; the associated error type SHOULD be 2442 "cancel". 2444 o -- the user is not authorized to access 2445 the requested service because a subscription is required; the 2446 associated error type SHOULD be "auth". 2448 o -- the error condition is not one of those 2449 defined by the other conditions in this list; any error type may 2450 be associated with this condition, and it SHOULD be used only in 2451 conjuction with an application-specific condition. 2453 o -- the recipient understood the request but 2454 was not expecting it at this time (e.g., the request was out of 2455 order); the associated error type SHOULD be "wait". 2457 8.7.4 Application-Specific Conditions 2459 As noted, an application MAY provide application-specific stanza 2460 error information by including a properly-namespaced child in the 2461 error element. The application-specific element SHOULD supplement or 2462 further qualify a defined element. Thus the element will 2463 contain two or three child elements: 2465 2466 2467 2468 2469 2470 2471 2472 2473 2474 2475 Some special application diagnostic information! 2476 2477 2478 2479 2481 9. XML Usage within XMPP 2483 9.1 Restrictions 2485 XMPP is a simplified and specialized protocol for streaming XML 2486 elements in order to exchange messages and presence information in 2487 close to real time. Because XMPP does not require the parsing of 2488 arbitrary and complete XML documents, there is no requirement that 2489 XMPP needs to support the full XML specification [1]. In particular, 2490 the following restrictions apply. 2492 With regard to XML generation, an XMPP implementation MUST NOT inject 2493 into an XML stream any of the following: 2495 o comments (as defined in Section 2.5 of the XML specification [1]) 2497 o processing instructions (Section 2.6) 2499 o internal or external DTD subsets (Section 2.8) 2501 o internal or external entity references (Section 4.2) with the 2502 exception of predefined entities (Section 4.6) 2504 o character data or attribute values containing unescaped characters 2505 that map to the predefined entities (Section 4.6); such characters 2506 MUST be escaped 2508 With regard to XML processing, if an XMPP implementation receives 2509 such restricted XML data, it MUST ignore the data. 2511 9.2 XML Namespace Names and Prefixes 2513 XML Namespaces [12] are used within all XMPP-compliant XML to create 2514 strict boundaries of data ownership. The basic function of namespaces 2515 is to separate different vocabularies of XML elements that are 2516 structurally mixed together. Ensuring that XMPP-compliant XML is 2517 namespace-aware enables any XML to be structurally mixed with any 2518 data element within XMPP. Rules for XML namespace names and prefixes 2519 are defined below. 2521 9.2.1 Stream Namespace 2523 A stream namespace declaration is REQUIRED in both XML stream 2524 headers. The name of the stream namespace MUST be 'http:// 2525 etherx.jabber.org/streams'. The element names of the 2526 element and its and children MUST be qualified 2527 by the stream namespace prefix in all instances. An implementation 2528 SHOULD generate only the 'stream:' prefix for these elements, and for 2529 historical reasons MAY accept only the 'stream:' prefix. 2531 9.2.2 Default Namespace 2533 A default namespace declaration is REQUIRED and is used in both XML 2534 streams in order to define the allowable first-level children of the 2535 root stream element. This namespace declaration MUST be the same for 2536 the initiating stream and the responding stream so that both streams 2537 are qualified consistently. The default namespace declaration applies 2538 to the stream and all stanzas sent within a stream (unless explicitly 2539 qualified by another namespace, or by the prefix of the stream 2540 namespace or the dialback namespace). 2542 A server implementation MUST support the following two default 2543 namespaces (for historical reasons, some implementations MAY support 2544 only these two default namespaces): 2546 o jabber:client -- this default namespace is declared when the 2547 stream is used for communications between a client and a server 2549 o jabber:server -- this default namespace is declared when the 2550 stream is used for communications between two servers 2552 A client implementation MUST support the 'jabber:client' default 2553 namespace, and for historical reasons MAY support only that default 2554 namespace. 2556 An implementation MUST NOT generate namespace prefixes for elements 2557 in the default namespace if the default namespace is 'jabber:client' 2558 or 'jabber:server'. An implementation SHOULD NOT generate namespace 2559 prefixes for elements qualified by "extended" namespaces as described 2560 under Extended Namespaces (Section 8.6). 2562 Note: the 'jabber:client' and 'jabber:server' namespaces are nearly 2563 identical but are used in different contexts (client-to-server 2564 communications for 'jabber:client' and server-to-server 2565 communications for 'jabber:server'). The only difference between the 2566 two is that the 'to' and 'from' attributes are OPTIONAL on stanzas 2567 sent within 'jabber:client', whereas they are REQUIRED on stanzas 2568 sent within 'jabber:server'. If a compliant implementation accepts a 2569 stream that is qualified by the 'jabber:client' or 'jabber:server' 2570 namespace, it MUST support all three core stanza types (message, 2571 presence, and IQ) as described herein and defined in the schema. 2573 9.2.3 Dialback Namespace 2575 A dialback namespace declaration is REQUIRED for all elements used in 2576 server dialback. The name of the dialback namespace MUST be 2577 'jabber:server:dialback'. All elements qualified by this namespace 2578 MUST be prefixed. An implementation SHOULD generate only the 'db:' 2579 prefix for such elements and MAY accept only the 'db:' prefix. 2581 9.3 Validation 2583 Except as noted with regard to 'to' and 'from' addresses for stanzas 2584 within the 'jabber:server' namespace, a server is not responsible for 2585 validating the XML elements forwarded to a client or another server; 2586 an implementation MAY choose to provide only validated data elements 2587 but is NOT REQUIRED to do so (although an implementation MUST NOT 2588 accept XML that is not well-formed). Clients SHOULD NOT rely on the 2589 ability to send data which does not conform to the schemas, and 2590 SHOULD ignore any non-conformant elements or attributes on the 2591 incoming XML stream. Validation of XML streams and stanzas is NOT 2592 REQUIRED or recommended, and schemas are included herein for 2593 descriptive purposes only. 2595 9.4 Character Encodings 2597 Software implementing XML streams MUST support the UTF-8 (RFC 2279 2598 [19]) and UTF-16 (RFC 2781 [20]) transformations of Universal 2599 Character Set (ISO/IEC 10646-1 [21]) characters. Implementations MUST 2600 NOT attempt to use any other encoding for transmitted data. The 2601 encodings of the transmitted and received streams are independent. 2602 Implementations MAY select either UTF-8 or UTF-16 for the transmitted 2603 stream, and SHOULD deduce the encoding of the received stream as 2604 described in the XML specification [1]. For historical reasons, 2605 existing implementations MAY support UTF-8 only. 2607 9.5 Inclusion of Text Declaration 2609 An application MAY send a text declaration. Applications MUST follow 2610 the rules in the XML specification [1] regarding the circumstances 2611 under which a text declaration is included. 2613 10. IANA Considerations 2615 10.1 XML Namespace Name for TLS Data 2617 A URN sub-namespace for TLS-related data in the Extensible Messaging 2618 and Presence Protocol (XMPP) is defined as follows. 2620 URI: urn:ietf:params:xml:ns:xmpp-tls 2622 Specification: [RFCXXXX] 2624 Description: This is the XML namespace name for TLS-related data in 2625 the Extensible Messaging and Presence Protocol (XMPP) as defined 2626 by [RFCXXXX]. 2628 Registrant Contact: IETF, XMPP Working Group, 2630 10.2 XML Namespace Name for SASL Data 2632 A URN sub-namespace for SASL-related data in the Extensible Messaging 2633 and Presence Protocol (XMPP) is defined as follows. 2635 URI: urn:ietf:params:xml:ns:xmpp-sasl 2637 Specification: [RFCXXXX] 2639 Description: This is the XML namespace name for SASL-related data in 2640 the Extensible Messaging and Presence Protocol (XMPP) as defined 2641 by [RFCXXXX]. 2643 Registrant Contact: IETF, XMPP Working Group, 2645 10.3 XML Namespace Name for Stream Errors 2647 A URN sub-namespace for stream-related error data in the Extensible 2648 Messaging and Presence Protocol (XMPP) is defined as follows. 2650 URI: urn:ietf:params:xml:ns:xmpp-streams 2652 Specification: [RFCXXXX] 2654 Description: This is the XML namespace name for stream-related error 2655 data in the Extensible Messaging and Presence Protocol (XMPP) as 2656 defined by [RFCXXXX]. 2658 Registrant Contact: IETF, XMPP Working Group, 2660 10.4 XML Namespace Name for Stanza Errors 2662 A URN sub-namespace for stanza-related error data in the Extensible 2663 Messaging and Presence Protocol (XMPP) is defined as follows. 2665 URI: urn:ietf:params:xml:ns:xmpp-stanzas 2667 Specification: [RFCXXXX] 2669 Description: This is the XML namespace name for stanza-related error 2670 data in the Extensible Messaging and Presence Protocol (XMPP) as 2671 defined by [RFCXXXX]. 2673 Registrant Contact: IETF, XMPP Working Group, 2675 10.5 Existing Registrations 2677 The IANA registers "xmpp" as a GSSAPI [22] service name, as specified 2678 in SASL Definition (Section 6.4). 2680 Additionally, the IANA registers "jabber-client" and "jabber-server" 2681 as keywords for TCP ports 5222 and 5269 respectively. These ports 2682 SHOULD be used for client-to-server and server-to-server 2683 communications respectively, but their use is NOT REQUIRED. The use 2684 of the string "jabber" in these keywords is historical. 2686 11. Internationalization Considerations 2688 Each XML stanza SHOULD include an 'xml:lang' attribute. Servers MUST 2689 NOT modify or delete 'xml:lang' attributes from stanzas they receive 2690 from other entities. 2692 12. Security Considerations 2694 12.1 High Security 2696 For the purposes of XMPP communications (client-to-server and 2697 server-to-server), the term "high security" refers to the use of 2698 security technologies that provide both mutual authentication and 2699 integrity-checking; in particular, when using certificate-based 2700 authentication to provide high security, a chain-of-trust SHOULD be 2701 established out-of-band, although a shared certificate authority 2702 signing certificates could allow a previously unknown certificate to 2703 establish trust in-band. 2705 Standalone, self-signed service certificates SHOULD NOT be used; 2706 rather, an entity that wishes to generate a self-signed service 2707 certificate SHOULD first generate a self-signed Root CA certificate 2708 and then generate a signed service certificate. Entities that 2709 communicate with the service SHOULD be configured with the Root CA 2710 certificate rather than the service certificate; this avoids problems 2711 associated with simple comparison of service certificates. If a 2712 self-signed service certificate is used, an entity SHOULD NOT trust 2713 it if it is changed to another self-signed certificate or a 2714 certificate signed by an unrecognized authority. 2716 Implementations MUST support high security. Service provisioning 2717 SHOULD use high security, subject to local security policies. 2719 12.2 Client-to-Server Communications 2721 A compliant implementation MUST support both TLS and SASL for 2722 connections to a server. 2724 The TLS protocol for encrypting XML streams (defined under Stream 2725 Encryption (Section 5)) provides a reliable mechanism for helping to 2726 ensure the confidentiality and data integrity of data exchanged 2727 between two entities. 2729 The SASL protocol for authenticating XML streams (defined under 2730 Stream Authentication (Section 6)) provides a reliable mechanism for 2731 validating that a client connecting to a server is who it claims to 2732 be. 2734 Client-to-server communications MUST NOT proceed until the DNS 2735 hostname asserted by the server has been resolved. Such resolutions 2736 SHOULD first attempt to resolve the hostname using an SRV [18] 2737 Service of "jabber-client" and Proto of "tcp", resulting in resource 2738 records such as "_jabber-client._tcp.shakespeare.lit." (the use of 2739 the string "jabber-client" for the service identifier is consistent 2740 with the existing IANA registration). If the SRV lookup fails, the 2741 fallback is a normal A lookup to determine the IP address, using the 2742 "jabber-client" port of 5222 assigned by the Internet Assigned 2743 Numbers Authority [5]. 2745 The IP address and method of access of clients MUST NOT be made 2746 available by a server, nor are any connections other than the 2747 original server connection required. This helps to protect the 2748 client's server from direct attack or identification by third 2749 parties. 2751 12.3 Server-to-Server Communications 2753 A compliant implementation MUST support both TLS and SASL for 2754 inter-domain communications. For historical reasons, a compliant 2755 implementation SHOULD also support Server Dialback (Section 7). 2757 Because service provisioning is a matter of policy, it is OPTIONAL 2758 for any given domain to communicate with other domains, and 2759 server-to-server communications MAY be disabled by the administrator 2760 of any given deployment. If a particular domain enables inter-domain 2761 communications, it SHOULD enable high security. 2763 Administrators may want to require use of SASL for server-to-server 2764 communications in order to ensure both authentication and 2765 confidentiality (e.g., on an organization's private network). 2766 Compliant implementations SHOULD support SASL for this purpose. 2768 Inter-domain connections MUST NOT proceed until the DNS hostnames 2769 asserted by the servers have been resolved. Such resolutions MUST 2770 first attempt to resolve the hostname using an SRV [18] Service of 2771 "jabber-server" and Proto of "tcp", resulting in resource records 2772 such as "_jabber-server._tcp.shakespeare.lit." (the use of the string 2773 "jabber-server" for the service identifer is consistent with the 2774 existing IANA registration; note well that the "jabber-server" 2775 service identifier supersedes the earlier use of a "jabber" service 2776 identifier, since the earlier usage did not conform to RFC 2782 2777 [18]). If the SRV lookup fails, the fallback is a normal A lookup to 2778 determine the IP address, using the "jabber-server" port of 5269 2779 assigned by the Internet Assigned Numbers Authority [5]. 2781 Server dialback helps protect against domain spoofing, thus making it 2782 more difficult to spoof XML stanzas. It is not a mechanism for 2783 authenticating, securing, or encrypting streams between servers as is 2784 done via SASL and TLS. Furthermore, it is susceptible to DNS 2785 poisoning attacks unless DNSSec [30] is used, and even if the DNS 2786 information is accurate, dialback cannot protect from attacks where 2787 the attacker is capable of hijacking the IP address of the remote 2788 domain. Domains requiring robust security SHOULD use TLS and SASL. If 2789 SASL is used for server-to-server authentication, dialback SHOULD NOT 2790 be used since it is unnecessary. 2792 12.4 Order of Layers 2794 The order of layers in which protocols MUST be stacked is as follows: 2796 1. TCP 2798 2. TLS 2800 3. SASL 2802 4. XMPP 2804 The rationale for this order is that TCP is the base connection layer 2805 used by all of the protocols stacked on top of TCP, TLS is often 2806 provided at the operating system layer, SASL is often provided at the 2807 application layer, and XMPP is the application itself. 2809 12.5 Firewalls 2811 Communications using XMPP normally occur over TCP sockets on port 2812 5222 (client-to-server) or port 5269 (server-to-server), as 2813 registered with the IANA [5] (see IANA Considerations (Section 10)). 2814 Use of these well-known ports allows administrators to easily enable 2815 or disable XMPP activity through existing and commonly-deployed 2816 firewalls. 2818 12.6 Mandatory to Implement Technologies 2820 At a minimum, all implementations MUST support the following 2821 mechanisms: 2823 for authentication: the SASL DIGEST-MD5 mechanism 2825 for confidentiality: TLS (using the TLS_RSA_WITH_3DES_EDE_CBC_SHA 2826 cipher) 2828 for both: TLS plus SASL EXTERNAL(using the 2829 TLS_RSA_WITH_3DES_EDE_CBC_SHA cipher supporting client-side 2830 certificates) 2832 Normative References 2834 [1] World Wide Web Consortium, "Extensible Markup Language (XML) 2835 1.0 (Second Edition)", W3C xml, October 2000, . 2838 [2] Day, M., Aggarwal, S. and J. Vincent, "Instant Messaging / 2839 Presence Protocol Requirements", RFC 2779, February 2000. 2841 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 2842 Levels", BCP 14, RFC 2119, March 1997. 2844 [4] University of Southern California, "Transmission Control 2845 Protocol", RFC 793, September 1981, . 2848 [5] Internet Assigned Numbers Authority, "Internet Assigned Numbers 2849 Authority", January 1998, . 2851 [6] Harrenstien, K., Stahl, M. and E. Feinler, "DoD Internet host 2852 table specification", RFC 952, October 1985. 2854 [7] Braden, R., "Requirements for Internet Hosts - Application and 2855 Support", STD 3, RFC 1123, October 1989. 2857 [8] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile 2858 for Internationalized Domain Names (draft-ietf-idn-nameprep-11, 2859 work in progress)", June 2002. 2861 [9] Hoffman, P. and M. Blanchet, "Preparation of Internationalized 2862 Strings ("stringprep")", RFC 3454, December 2002. 2864 [10] Saint-Andre, P. and J. Hildebrand, "Nodeprep: A Stringprep 2865 Profile for Node Identifiers in XMPP", 2866 draft-ietf-xmpp-nodeprep-03 (work in progress), June 2003. 2868 [11] Saint-Andre, P. and J. Hildebrand, "Resourceprep: A Stringprep 2869 Profile for Resource Identifiers in XMPP", 2870 draft-ietf-xmpp-resourceprep-03 (work in progress), June 2003. 2872 [12] World Wide Web Consortium, "Namespaces in XML", W3C xml-names, 2873 January 1999, . 2876 [13] Dierks, T., Allen, C., Treese, W., Karlton, P., Freier, A. and 2877 P. Kocher, "The TLS Protocol Version 1.0", RFC 2246, January 2878 1999. 2880 [14] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 2882 [15] Myers, J., "Simple Authentication and Security Layer (SASL)", 2883 RFC 2222, October 1997. 2885 [16] Leach, P. and C. Newman, "Using Digest Authentication as a SASL 2886 Mechanism", RFC 2831, May 2000. 2888 [17] Alvestrand, H., "Tags for the Identification of Languages", BCP 2889 47, RFC 3066, January 2001. 2891 [18] Gulbrandsen, A., Vixie, P. and L. Esibov, "A DNS RR for 2892 specifying the location of services (DNS SRV)", RFC 2782, 2893 February 2000. 2895 [19] Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2896 2279, January 1998. 2898 [20] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", 2899 RFC 2781, February 2000. 2901 [21] International Organization for Standardization, "Information 2902 Technology - Universal Multiple-octet coded Character Set (UCS) 2903 - Amendment 2: UCS Transformation Format 8 (UTF-8)", ISO 2904 Standard 10646-1 Addendum 2, October 1996. 2906 [22] Linn, J., "Generic Security Service Application Program 2907 Interface, Version 2", RFC 2078, January 1997. 2909 Informative References 2911 [23] Saint-Andre, P. and J. Miller, "XMPP Instant Messaging", 2912 draft-ietf-xmpp-im-14 (work in progress), June 2003. 2914 [24] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform 2915 Resource Identifiers (URI): Generic Syntax", RFC 2396, August 2916 1998, . 2918 [25] Mealling, M., "The IANA XML Registry", 2919 draft-mealling-iana-xmlns-registry-05 (work in progress), June 2920 2003. 2922 [26] Crispin, M., "Internet Message Access Protocol - Version 2923 4rev1", RFC 2060, December 1996. 2925 [27] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 2926 53, RFC 1939, May 1996. 2928 [28] Newman, C. and J. Myers, "ACAP -- Application Configuration 2929 Access Protocol", RFC 2244, November 1997. 2931 [29] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, 2932 June 1999. 2934 [30] Eastlake, D., "Domain Name System Security Extensions", RFC 2935 2535, March 1999. 2937 [31] Alvestrand, H., "IETF Policy on Character Sets and Languages", 2938 BCP 18, RFC 2277, January 1998. 2940 [32] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., Masinter, L., 2941 Leach, P. and T. Berners-Lee, "Hypertext Transfer Protocol -- 2942 HTTP/1.1", RFC 2616, June 1999. 2944 Authors' Addresses 2946 Peter Saint-Andre 2947 Jabber Software Foundation 2949 EMail: stpeter@jabber.org 2951 Jeremie Miller 2952 Jabber Software Foundation 2954 EMail: jeremie@jabber.org 2956 Appendix A. XML Schemas 2958 The following XML schemas are descriptive, not normative. 2960 A.1 Stream namespace 2962 2964 2970 2971 2972 2973 2974 2975 2978 2981 2982 2983 2984 2985 2986 2987 2988 2989 2991 2992 2993 2994 2998 2999 3000 3002 3003 3004 3005 3007 3011 3012 3013 3015 3017 A.2 Stream error namespace 3019 3021 3028 3031 3032 3033 3034 3035 3036 3037 3038 3039 3040 3041 3042 3043 3044 3045 3046 3047 3048 3050 3051 3052 3053 3054 3056 3057 3058 3059 3060 3062 3064 A.3 TLS namespace 3066 3068 3074 3075 3076 3077 3081 3082 3083 3085 3086 3087 3089 3090 3091 3092 3093 3095 3097 A.4 SASL namespace 3099 3101 3107 3108 3109 3110 3112 3113 3114 3116 3118 3119 3120 3123 3124 3126 3127 3128 3129 3131 3132 3133 3134 3135 3136 3137 3138 3139 3140 3141 3142 3143 3144 3145 3147 3148 3149 3150 3151 3152 3153 3154 3155 3157 3158 3159 3161 3162 3164 3166 A.5 Dialback namespace 3168 3170 3176 3177 3178 3179 3180 3181 3182 3183 3184 3185 3186 3187 3188 3189 3190 3191 3192 3193 3195 3196 3197 3198 3199 3200 3201 3202 3203 3204 3205 3206 3207 3209 3210 3211 3212 3213 3214 3216 3218 A.6 Client namespace 3220 3222 3229 3232 3233 3234 3235 3238 3241 3244 3247 3250 3251 3254 3257 3260 3261 3262 3263 3264 3265 3266 3267 3268 3269 3270 3271 3272 3273 3275 3276 3277 3278 3279 3281 3282 3283 3284 3285 3287 3289 3290 3291 3292 3295 3298 3301 3305 3308 3309 3312 3315 3318 3319 3320 3321 3322 3323 3324 3325 3326 3327 3328 3329 3330 3331 3332 3334 3335 3336 3337 3338 3339 3340 3341 3342 3343 3345 3346 3347 3348 3349 3351 3352 3353 3354 3355 3358 3361 3362 3365 3368 3371 3372 3373 3374 3375 3376 3377 3378 3379 3380 3381 3382 3383 3385 3386 3387 3388 3390 3393 3397 3398 3399 3400 3401 3402 3403 3404 3405 3406 3407 3408 3409 3410 3412 3414 A.7 Server namespace 3416 3418 3425 3428 3429 3430 3431 3434 3437 3440 3443 3446 3447 3450 3453 3456 3457 3458 3459 3460 3461 3462 3463 3464 3465 3466 3467 3468 3469 3471 3472 3473 3474 3475 3477 3478 3479 3480 3481 3483 3485 3486 3487 3488 3491 3494 3497 3500 3503 3504 3507 3510 3513 3514 3515 3516 3517 3518 3519 3520 3521 3522 3523 3524 3525 3526 3527 3529 3530 3531 3532 3533 3534 3535 3536 3537 3538 3540 3541 3542 3544 3545 3547 3549 3550 3551 3552 3555 3558 3559 3562 3565 3568 3569 3570 3571 3572 3573 3574 3575 3576 3577 3578 3579 3580 3582 3583 3584 3585 3587 3590 3594 3595 3596 3597 3598 3599 3600 3601 3602 3603 3604 3605 3606 3607 3609 3611 A.8 Stanza error namespace 3613 3615 3622 3625 3626 3627 3628 3629 3630 3631 3632 3633 3634 3635 3636 3637 3638 3639 3640 3641 3643 3644 3645 3646 3647 3649 3650 3651 3652 3653 3655 3657 Appendix B. Revision History 3659 Note to RFC Editor: please remove this entire appendix, and the 3660 corresponding entries in the table of contents, prior to publication. 3662 B.1 Changes from draft-ietf-xmpp-core-15 3664 o Added and stream errors. 3666 o Added SASL error and clarified error. 3668 o Made 'id' required for IQ stanzas. 3670 B.2 Changes from draft-ietf-xmpp-core-14 3672 o Added SRV lookup for client-to-server communications. 3674 o Changed server SRV record to conform to RFC 2782; specifically, 3675 the service identifier was changed from 'jabber' to 3676 'jabber-server'. 3678 B.3 Changes from draft-ietf-xmpp-core-13 3680 o Clarified stream restart after successful TLS and SASL 3681 negotiation. 3683 o Clarified requirement for resolution of DNS hostnames. 3685 o Clarified text regarding namespaces. 3687 o Clarified examples regarding empty element. 3689 o Added several more SASL error conditions. 3691 o Changed stream error to and 3692 added to schema. 3694 o Made small editorial changes and fixed several schema errors. 3696 B.4 Changes from draft-ietf-xmpp-core-12 3698 o Moved server dialback to a separate section; clarified its 3699 security characteristics and its role in the protocol. 3701 o Adjusted error handling syntax and semantics per list discussion. 3703 o Further clarified length of node identifiers and total length of 3704 JIDs. 3706 o Documented message type='normal'. 3708 o Corrected several small errors in the TLS and SASL sections. 3710 o Corrected several errors in the schemas. 3712 B.5 Changes from draft-ietf-xmpp-core-11 3714 o Corrected several small errors in the TLS and SASL sections. 3716 o Made small editorial changes and fixed several schema errors. 3718 B.6 Changes from draft-ietf-xmpp-core-10 3720 o Adjusted TLS content regarding certificate validation process. 3722 o Specified that stanza error extensions for specific applications 3723 are to be properly namespaced children of the relevant descriptive 3724 element. 3726 o Clarified rules for inclusion of the 'id' attribute. 3728 o Specified that the 'xml:lang' attribute SHOULD be included (per 3729 list discussion). 3731 o Made small editorial changes and fixed several schema errors. 3733 B.7 Changes from draft-ietf-xmpp-core-09 3735 o Fixed several dialback error conditions. 3737 o Cleaned up rules regarding TLS and certificate processing based on 3738 off-list feedback. 3740 o Changed and elements to 3741 . 3743 o Added or modified several stream and stanza error conditions. 3745 o Specified only one child allowed for IQ, or two if type="error". 3747 o Fixed several errors in the schemas. 3749 B.8 Changes from draft-ietf-xmpp-core-08 3751 o Incorporated list discussion regarding addressing, SASL, TLS, TCP, 3752 dialback, namespaces, extensibility, and the meaning of 'ignore' 3753 for routers and recipients. 3755 o Specified dialback error conditions. 3757 o Made small editorial changes to address RFC Editor requirements. 3759 B.9 Changes from draft-ietf-xmpp-core-07 3761 o Made several small editorial changes. 3763 B.10 Changes from draft-ietf-xmpp-core-06 3765 o Added text regarding certificate validation in TLS negotiation per 3766 list discussion. 3768 o Clarified nature of XML restrictions per discussion with W3C, and 3769 moved XML Restrictions subsection under "XML Usage within XMPP". 3771 o Further clarified that XML streams are unidirectional. 3773 o Changed stream error and stanza error namespace names to conform 3774 to the format defined in The IETF XML Registry [25]. 3776 o Removed note to RFC Editor regarding provisional namespace names. 3778 B.11 Changes from draft-ietf-xmpp-core-05 3780 o Added as a stream error condition. 3782 o Adjusted security considerations per discussion at IETF 56 and on 3783 list. 3785 B.12 Changes from draft-ietf-xmpp-core-04 3787 o Added server-to-server examples for TLS and SASL. 3789 o Changed error syntax, rules, and examples based on list 3790 discussion. 3792 o Added schemas for the TLS, stream error, and stanza error 3793 namespaces. 3795 o Added note to RFC Editor regarding provisional namespace names. 3797 o Made numerous small editorial changes and clarified text 3798 throughout. 3800 B.13 Changes from draft-ietf-xmpp-core-03 3802 o Clarified rules and procedures for TLS and SASL. 3804 o Amplified stream error code syntax per list discussion. 3806 o Made numerous small editorial changes. 3808 B.14 Changes from draft-ietf-xmpp-core-02 3810 o Added dialback schema. 3812 o Removed all DTDs since schemas provide more complete definitions. 3814 o Added stream error codes. 3816 o Clarified error code "philosophy". 3818 B.15 Changes from draft-ietf-xmpp-core-01 3820 o Updated the addressing restrictions per list discussion and added 3821 references to the new nodeprep and resourceprep profiles. 3823 o Corrected error in Stream Authentication regarding 'version' 3824 attribute. 3826 o Made numerous small editorial changes. 3828 B.16 Changes from draft-ietf-xmpp-core-00 3830 o Added information about TLS from list discussion. 3832 o Clarified meaning of "ignore" based on list discussion. 3834 o Clarified information about Universal Character Set data and 3835 character encodings. 3837 o Provided base64-decoded information for examples. 3839 o Fixed several errors in the schemas. 3841 o Made numerous small editorial fixes. 3843 B.17 Changes from draft-miller-xmpp-core-02 3845 o Brought Streams Authentication section into line with discussion 3846 on list and at IETF 55 meeting. 3848 o Added information about the optional 'xml:lang' attribute per 3849 discussion on list and at IETF 55 meeting. 3851 o Specified that validation is neither required nor recommended, and 3852 that the formal definitions (DTDs and schemas) are included for 3853 descriptive purposes only. 3855 o Specified that the response to an IQ stanza of type "get" or "set" 3856 must be an IQ stanza of type "result" or "error". 3858 o Specified that compliant server implementations must process 3859 stanzas in order. 3861 o Specified that for historical reasons some server implementations 3862 may accept 'stream:' as the only valid namespace prefix on the 3863 root stream element. 3865 o Clarified the difference between 'jabber:client' and 3866 'jabber:server' namespaces, namely, that 'to' and 'from' 3867 attributes are required on all stanzas in the latter but not the 3868 former. 3870 o Fixed typo in Step 9 of the dialback protocol (changed db:result 3871 to db:verify). 3873 o Removed references to TLS pending list discussion. 3875 o Removed the non-normative appendix on OpenPGP usage pending its 3876 inclusion in a separate I-D. 3878 o Simplified the architecture diagram, removed most references to 3879 services, and removed references to the 'jabber:component:*' 3880 namespaces. 3882 o Noted that XMPP activity respects firewall administration 3883 policies. 3885 o Further specified the scope and uniqueness of the 'id' attribute 3886 in all stanza types and the element in message stanzas. 3888 o Nomenclature changes: (1) from "chunks" to "stanzas"; (2) from 3889 "host" to "server" and from "node" to "client" (except with regard 3890 to definition of the addressing scheme). 3892 Intellectual Property Statement 3894 The IETF takes no position regarding the validity or scope of any 3895 intellectual property or other rights that might be claimed to 3896 pertain to the implementation or use of the technology described in 3897 this document or the extent to which any license under such rights 3898 might or might not be available; neither does it represent that it 3899 has made any effort to identify any such rights. Information on the 3900 IETF's procedures with respect to rights in standards-track and 3901 standards-related documentation can be found in BCP-11. Copies of 3902 claims of rights made available for publication and any assurances of 3903 licenses to be made available, or the result of an attempt made to 3904 obtain a general license or permission for the use of such 3905 proprietary rights by implementors or users of this specification can 3906 be obtained from the IETF Secretariat. 3908 The IETF invites any interested party to bring to its attention any 3909 copyrights, patents or patent applications, or other proprietary 3910 rights which may cover technology that may be required to practice 3911 this standard. Please address the information to the IETF Executive 3912 Director. 3914 Full Copyright Statement 3916 Copyright (C) The Internet Society (2003). All Rights Reserved. 3918 This document and translations of it may be copied and furnished to 3919 others, and derivative works that comment on or otherwise explain it 3920 or assist in its implementation may be prepared, copied, published 3921 and distributed, in whole or in part, without restriction of any 3922 kind, provided that the above copyright notice and this paragraph are 3923 included on all such copies and derivative works. However, this 3924 document itself may not be modified in any way, such as by removing 3925 the copyright notice or references to the Internet Society or other 3926 Internet organizations, except as needed for the purpose of 3927 developing Internet standards in which case the procedures for 3928 copyrights defined in the Internet Standards process must be 3929 followed, or as required to translate it into languages other than 3930 English. 3932 The limited permissions granted above are perpetual and will not be 3933 revoked by the Internet Society or its successors or assignees. 3935 This document and the information contained herein is provided on an 3936 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 3937 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 3938 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 3939 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 3940 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3942 Acknowledgement 3944 Funding for the RFC Editor function is currently provided by the 3945 Internet Society.