Network Working Group P. Saint-Andre, Ed. Internet-Draft XMPP Standards Foundation Obsoletes: 3920 (if approved) July 1, 2008 Intended status: Standards Track Expires: January 2, 2009 Extensible Messaging and Presence Protocol (XMPP): Core draft-saintandre-rfc3920bis-06 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 2, 2009. Copyright Notice Copyright (C) The IETF Trust (2008). Abstract This document defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a technology for streaming Extensible Markup Language (XML) elements for the purpose of exchanging structured information in close to real time between any two or more network-aware entities. XMPP provides a generalized, extensible framework for incrementally exchanging XML data, upon which a variety of applications can be built. The framework includes methods for Saint-Andre Expires January 2, 2009 [Page 1] Internet-Draft XMPP Core July 2008 stream setup and teardown, channel encryption, authentication of a client to a server and of one server to another server, and primitives for push-style messages, publication of network availability information ("presence"), and request-response interactions. This document also specifies the format for XMPP addresses, which are fully internationalizable. This document obsoletes RFC 3920. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2. Functional Summary . . . . . . . . . . . . . . . . . . . 10 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . 11 1.4. Acknowledgements . . . . . . . . . . . . . . . . . . . . 12 1.5. Discussion Venue . . . . . . . . . . . . . . . . . . . . 12 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 12 2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 2.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3. Client . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.4. Network . . . . . . . . . . . . . . . . . . . . . . . . 14 3. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 14 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 14 3.2. Domain Identifier . . . . . . . . . . . . . . . . . . . 15 3.3. Node Identifier . . . . . . . . . . . . . . . . . . . . 16 3.4. Resource Identifier . . . . . . . . . . . . . . . . . . 17 3.5. Determination of Addresses . . . . . . . . . . . . . . . 18 4. TCP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2. Hostname Resolution . . . . . . . . . . . . . . . . . . 19 4.3. Client-to-Server Communication . . . . . . . . . . . . . 19 4.4. Server-to-Server Communication . . . . . . . . . . . . . 20 4.5. Reconnection . . . . . . . . . . . . . . . . . . . . . . 20 4.6. Other Bindings . . . . . . . . . . . . . . . . . . . . . 21 5. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . . 21 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 21 5.2. Stream Security . . . . . . . . . . . . . . . . . . . . 23 5.3. Stream Attributes . . . . . . . . . . . . . . . . . . . 24 5.3.1. from . . . . . . . . . . . . . . . . . . . . . . . . 24 5.3.2. to . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.3.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.3.4. xml:lang . . . . . . . . . . . . . . . . . . . . . . 27 5.3.5. version . . . . . . . . . . . . . . . . . . . . . . 29 5.3.6. Summary of Stream Attributes . . . . . . . . . . . . 30 5.4. Namespace Declarations . . . . . . . . . . . . . . . . . 30 5.5. Stream Features . . . . . . . . . . . . . . . . . . . . 31 Saint-Andre Expires January 2, 2009 [Page 2] Internet-Draft XMPP Core July 2008 5.6. Restarts During Stream Negotiation . . . . . . . . . . . 33 5.7. Closing a Stream . . . . . . . . . . . . . . . . . . . . 33 5.7.1. With Stream Error . . . . . . . . . . . . . . . . . 33 5.7.2. Without Stream Error . . . . . . . . . . . . . . . . 33 5.7.3. Handling of Idle Streams . . . . . . . . . . . . . . 34 5.8. Stream Errors . . . . . . . . . . . . . . . . . . . . . 34 5.8.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 35 5.8.1.1. Stream Errors Are Unrecoverable . . . . . . . . . 35 5.8.1.2. Stream Errors Can Occur During Setup . . . . . . 35 5.8.1.3. Stream Errors When the Host is Unspecified or Unknown . . . . . . . . . . . . . . . . . . . . . 36 5.8.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 37 5.8.3. Defined Stream Error Conditions . . . . . . . . . . 38 5.8.3.1. bad-format . . . . . . . . . . . . . . . . . . . 38 5.8.3.2. bad-namespace-prefix . . . . . . . . . . . . . . 38 5.8.3.3. conflict . . . . . . . . . . . . . . . . . . . . 39 5.8.3.4. connection-timeout . . . . . . . . . . . . . . . 40 5.8.3.5. host-gone . . . . . . . . . . . . . . . . . . . . 40 5.8.3.6. host-unknown . . . . . . . . . . . . . . . . . . 41 5.8.3.7. improper-addressing . . . . . . . . . . . . . . . 42 5.8.3.8. internal-server-error . . . . . . . . . . . . . . 42 5.8.3.9. invalid-from . . . . . . . . . . . . . . . . . . 43 5.8.3.10. invalid-id . . . . . . . . . . . . . . . . . . . 43 5.8.3.11. invalid-namespace . . . . . . . . . . . . . . . . 44 5.8.3.12. invalid-xml . . . . . . . . . . . . . . . . . . . 44 5.8.3.13. not-authorized . . . . . . . . . . . . . . . . . 45 5.8.3.14. policy-violation . . . . . . . . . . . . . . . . 46 5.8.3.15. remote-connection-failed . . . . . . . . . . . . 47 5.8.3.16. resource-constraint . . . . . . . . . . . . . . . 47 5.8.3.17. restricted-xml . . . . . . . . . . . . . . . . . 48 5.8.3.18. see-other-host . . . . . . . . . . . . . . . . . 48 5.8.3.19. system-shutdown . . . . . . . . . . . . . . . . . 49 5.8.3.20. undefined-condition . . . . . . . . . . . . . . . 50 5.8.3.21. unsupported-encoding . . . . . . . . . . . . . . 50 5.8.3.22. unsupported-stanza-type . . . . . . . . . . . . . 51 5.8.3.23. unsupported-version . . . . . . . . . . . . . . . 51 5.8.3.24. xml-not-well-formed . . . . . . . . . . . . . . . 52 5.8.4. Application-Specific Conditions . . . . . . . . . . 53 5.9. Simplified Stream Examples . . . . . . . . . . . . . . . 53 6. STARTTLS Negotiation . . . . . . . . . . . . . . . . . . . . 55 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 56 6.2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . 56 6.2.1. Data Formatting . . . . . . . . . . . . . . . . . . 56 6.2.2. Order of Negotiation . . . . . . . . . . . . . . . . 56 6.3. Process . . . . . . . . . . . . . . . . . . . . . . . . 57 6.3.1. Exchange of Stream Headers and Stream Features . . . 57 6.3.2. Initiation of STARTTLS Negotiation . . . . . . . . . 58 6.3.2.1. STARTTLS Command . . . . . . . . . . . . . . . . 58 Saint-Andre Expires January 2, 2009 [Page 3] Internet-Draft XMPP Core July 2008 6.3.2.2. Failure Case . . . . . . . . . . . . . . . . . . 58 6.3.2.3. Proceed Case . . . . . . . . . . . . . . . . . . 59 6.3.3. TLS Negotiation . . . . . . . . . . . . . . . . . . 59 6.3.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . 59 6.3.3.2. TLS Failure . . . . . . . . . . . . . . . . . . . 60 6.3.3.3. TLS Success . . . . . . . . . . . . . . . . . . . 60 7. SASL Negotiation . . . . . . . . . . . . . . . . . . . . . . 61 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 61 7.2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . 61 7.2.1. Mechanism Preferences . . . . . . . . . . . . . . . 61 7.2.2. Mechanism Offers . . . . . . . . . . . . . . . . . . 62 7.2.3. Data Formatting . . . . . . . . . . . . . . . . . . 62 7.2.4. Security Layers . . . . . . . . . . . . . . . . . . 63 7.2.5. Simple Usernames . . . . . . . . . . . . . . . . . . 63 7.2.6. Authorization Identities . . . . . . . . . . . . . . 63 7.2.7. Round Trips . . . . . . . . . . . . . . . . . . . . 64 7.3. Process . . . . . . . . . . . . . . . . . . . . . . . . 64 7.3.1. Exchange of Stream Headers and Stream Features . . . 64 7.3.2. Initiation . . . . . . . . . . . . . . . . . . . . . 66 7.3.3. Challenge-Response Sequence . . . . . . . . . . . . 66 7.3.4. Abort . . . . . . . . . . . . . . . . . . . . . . . 67 7.3.5. Failure . . . . . . . . . . . . . . . . . . . . . . 67 7.3.6. Success . . . . . . . . . . . . . . . . . . . . . . 68 7.4. SASL Errors . . . . . . . . . . . . . . . . . . . . . . 69 7.4.1. aborted . . . . . . . . . . . . . . . . . . . . . . 70 7.4.2. account-disabled . . . . . . . . . . . . . . . . . . 70 7.4.3. credentials-expired . . . . . . . . . . . . . . . . 70 7.4.4. encryption-required . . . . . . . . . . . . . . . . 70 7.4.5. incorrect-encoding . . . . . . . . . . . . . . . . . 71 7.4.6. invalid-authzid . . . . . . . . . . . . . . . . . . 71 7.4.7. invalid-mechanism . . . . . . . . . . . . . . . . . 71 7.4.8. malformed-request . . . . . . . . . . . . . . . . . 72 7.4.9. mechanism-too-weak . . . . . . . . . . . . . . . . . 72 7.4.10. not-authorized . . . . . . . . . . . . . . . . . . . 72 7.4.11. temporary-auth-failure . . . . . . . . . . . . . . . 73 7.4.12. transition-needed . . . . . . . . . . . . . . . . . 73 7.5. SASL Definition . . . . . . . . . . . . . . . . . . . . 73 8. Resource Binding . . . . . . . . . . . . . . . . . . . . . . 74 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 74 8.2. Advertising Support . . . . . . . . . . . . . . . . . . 75 8.3. Generation of Resource Identifiers . . . . . . . . . . . 75 8.4. Server-Generated Resource Identifier . . . . . . . . . . 76 8.4.1. Success Case . . . . . . . . . . . . . . . . . . . . 76 8.4.2. Error Cases . . . . . . . . . . . . . . . . . . . . 77 8.4.2.1. Resource Constraint . . . . . . . . . . . . . . . 77 8.4.2.2. Not Allowed . . . . . . . . . . . . . . . . . . . 77 8.5. Client-Submitted Resource Identifier . . . . . . . . . . 78 8.5.1. Success Case . . . . . . . . . . . . . . . . . . . . 78 Saint-Andre Expires January 2, 2009 [Page 4] Internet-Draft XMPP Core July 2008 8.5.2. Error Cases . . . . . . . . . . . . . . . . . . . . 79 8.5.2.1. Bad Request . . . . . . . . . . . . . . . . . . . 79 8.5.2.2. Conflict . . . . . . . . . . . . . . . . . . . . 79 8.5.3. Retries . . . . . . . . . . . . . . . . . . . . . . 80 8.6. Binding Multiple Resources . . . . . . . . . . . . . . . 80 8.6.1. Support . . . . . . . . . . . . . . . . . . . . . . 80 8.6.2. Binding an Additional Resource . . . . . . . . . . . 81 8.6.3. Unbinding a Resource . . . . . . . . . . . . . . . . 81 8.6.3.1. Success Case . . . . . . . . . . . . . . . . . . 81 8.6.3.2. Error Cases . . . . . . . . . . . . . . . . . . . 82 8.6.4. From Addresses . . . . . . . . . . . . . . . . . . . 82 9. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 83 9.1. Common Attributes . . . . . . . . . . . . . . . . . . . 83 9.1.1. to . . . . . . . . . . . . . . . . . . . . . . . . . 83 9.1.1.1. Client-to-Server Streams . . . . . . . . . . . . 84 9.1.1.2. Server-to-Server Streams . . . . . . . . . . . . 84 9.1.2. from . . . . . . . . . . . . . . . . . . . . . . . . 84 9.1.2.1. Client-to-Server Streams . . . . . . . . . . . . 85 9.1.2.2. Server-to-Server Streams . . . . . . . . . . . . 85 9.1.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 86 9.1.4. type . . . . . . . . . . . . . . . . . . . . . . . . 86 9.1.5. xml:lang . . . . . . . . . . . . . . . . . . . . . . 86 9.2. Basic Semantics . . . . . . . . . . . . . . . . . . . . 87 9.2.1. Message Semantics . . . . . . . . . . . . . . . . . 87 9.2.2. Presence Semantics . . . . . . . . . . . . . . . . . 88 9.2.3. IQ Semantics . . . . . . . . . . . . . . . . . . . . 88 9.3. Stanza Errors . . . . . . . . . . . . . . . . . . . . . 90 9.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 90 9.3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 90 9.3.3. Defined Conditions . . . . . . . . . . . . . . . . . 92 9.3.3.1. bad-request . . . . . . . . . . . . . . . . . . . 92 9.3.3.2. conflict . . . . . . . . . . . . . . . . . . . . 92 9.3.3.3. feature-not-implemented . . . . . . . . . . . . . 93 9.3.3.4. forbidden . . . . . . . . . . . . . . . . . . . . 93 9.3.3.5. gone . . . . . . . . . . . . . . . . . . . . . . 94 9.3.3.6. internal-server-error . . . . . . . . . . . . . . 94 9.3.3.7. item-not-found . . . . . . . . . . . . . . . . . 95 9.3.3.8. jid-malformed . . . . . . . . . . . . . . . . . . 95 9.3.3.9. not-acceptable . . . . . . . . . . . . . . . . . 96 9.3.3.10. not-allowed . . . . . . . . . . . . . . . . . . . 96 9.3.3.11. not-authorized . . . . . . . . . . . . . . . . . 97 9.3.3.12. not-modified . . . . . . . . . . . . . . . . . . 97 9.3.3.13. payment-required . . . . . . . . . . . . . . . . 98 9.3.3.14. recipient-unavailable . . . . . . . . . . . . . . 99 9.3.3.15. redirect . . . . . . . . . . . . . . . . . . . . 100 9.3.3.16. registration-required . . . . . . . . . . . . . . 100 9.3.3.17. remote-server-not-found . . . . . . . . . . . . . 101 9.3.3.18. remote-server-timeout . . . . . . . . . . . . . . 101 Saint-Andre Expires January 2, 2009 [Page 5] Internet-Draft XMPP Core July 2008 9.3.3.19. resource-constraint . . . . . . . . . . . . . . . 101 9.3.3.20. service-unavailable . . . . . . . . . . . . . . . 102 9.3.3.21. subscription-required . . . . . . . . . . . . . . 102 9.3.3.22. undefined-condition . . . . . . . . . . . . . . . 103 9.3.3.23. unexpected-request . . . . . . . . . . . . . . . 104 9.3.3.24. unknown-sender . . . . . . . . . . . . . . . . . 105 9.3.4. Application-Specific Conditions . . . . . . . . . . 105 9.4. Extended Content . . . . . . . . . . . . . . . . . . . . 106 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 107 10.1. Client-to-Server . . . . . . . . . . . . . . . . . . . . 107 10.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 108 10.1.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 109 10.1.3. Resource Binding . . . . . . . . . . . . . . . . . . 110 10.1.4. Stanza Exchange . . . . . . . . . . . . . . . . . . 111 10.1.5. Close . . . . . . . . . . . . . . . . . . . . . . . 112 10.2. Server-to-Server Examples . . . . . . . . . . . . . . . 112 10.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 112 10.2.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 114 10.2.3. Stanza Exchange . . . . . . . . . . . . . . . . . . 115 10.2.4. Close . . . . . . . . . . . . . . . . . . . . . . . 116 11. Server Rules for Processing XML Stanzas . . . . . . . . . . . 116 11.1. No 'to' Address . . . . . . . . . . . . . . . . . . . . 116 11.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 116 11.1.2. Message . . . . . . . . . . . . . . . . . . . . . . 117 11.1.3. Presence . . . . . . . . . . . . . . . . . . . . . . 117 11.1.4. IQ . . . . . . . . . . . . . . . . . . . . . . . . . 117 11.2. Local Domain . . . . . . . . . . . . . . . . . . . . . . 117 11.2.1. Mere Domain . . . . . . . . . . . . . . . . . . . . 118 11.2.2. Domain with Resource . . . . . . . . . . . . . . . . 118 11.2.3. Node at Domain . . . . . . . . . . . . . . . . . . . 118 11.2.3.1. No Such User . . . . . . . . . . . . . . . . . . 118 11.2.3.2. Bare JID . . . . . . . . . . . . . . . . . . . . 118 11.2.3.3. Full JID . . . . . . . . . . . . . . . . . . . . 119 11.3. Foreign Domain . . . . . . . . . . . . . . . . . . . . . 119 11.3.1. Existing Stream . . . . . . . . . . . . . . . . . . 119 11.3.2. No Existing Stream . . . . . . . . . . . . . . . . . 119 11.3.3. Error Handling . . . . . . . . . . . . . . . . . . . 120 12. XML Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 120 12.1. Restrictions . . . . . . . . . . . . . . . . . . . . . . 120 12.2. XML Namespace Names and Prefixes . . . . . . . . . . . . 121 12.2.1. Streams Namespace . . . . . . . . . . . . . . . . . 121 12.2.2. Default Namespace . . . . . . . . . . . . . . . . . 121 12.2.3. Extended Namespaces . . . . . . . . . . . . . . . . 122 12.3. Well-Formedness . . . . . . . . . . . . . . . . . . . . 123 12.4. Validation . . . . . . . . . . . . . . . . . . . . . . . 124 12.5. Inclusion of Text Declaration . . . . . . . . . . . . . 124 12.6. Character Encoding . . . . . . . . . . . . . . . . . . . 124 12.7. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 124 Saint-Andre Expires January 2, 2009 [Page 6] Internet-Draft XMPP Core July 2008 13. Compliance Requirements . . . . . . . . . . . . . . . . . . . 124 13.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . 125 13.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . 125 14. Internationalization Considerations . . . . . . . . . . . . . 126 15. Security Considerations . . . . . . . . . . . . . . . . . . . 126 15.1. High Security . . . . . . . . . . . . . . . . . . . . . 126 15.2. Certificates . . . . . . . . . . . . . . . . . . . . . . 127 15.2.1. Certificate Generation . . . . . . . . . . . . . . . 127 15.2.1.1. Server Certificates . . . . . . . . . . . . . . . 127 15.2.1.2. Client Certificates . . . . . . . . . . . . . . . 129 15.2.1.3. ASN.1 Object Identifier . . . . . . . . . . . . . 129 15.2.2. Certificate Validation . . . . . . . . . . . . . . . 130 15.2.2.1. Server-to-Server Streams . . . . . . . . . . . . 130 15.2.2.2. Client-to-Server Streams . . . . . . . . . . . . 132 15.2.2.3. Use of Certificates in XMPP Extensions . . . . . 133 15.3. Client-to-Server Communication . . . . . . . . . . . . . 133 15.4. Server-to-Server Communication . . . . . . . . . . . . . 133 15.5. Order of Layers . . . . . . . . . . . . . . . . . . . . 134 15.6. Lack of SASL Channel Binding to TLS . . . . . . . . . . 134 15.7. Mandatory-to-Implement Technologies . . . . . . . . . . 135 15.8. Firewalls . . . . . . . . . . . . . . . . . . . . . . . 135 15.9. Use of base64 in SASL . . . . . . . . . . . . . . . . . 135 15.10. Stringprep Profiles . . . . . . . . . . . . . . . . . . 136 15.11. Address Spoofing . . . . . . . . . . . . . . . . . . . . 136 15.11.1. Address Forging . . . . . . . . . . . . . . . . . . 137 15.11.2. Address Mimicking . . . . . . . . . . . . . . . . . 137 15.12. Denial of Service . . . . . . . . . . . . . . . . . . . 138 15.13. Presence Leaks . . . . . . . . . . . . . . . . . . . . . 140 15.14. Directory Harvesting . . . . . . . . . . . . . . . . . . 140 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 140 16.1. XML Namespace Name for TLS Data . . . . . . . . . . . . 140 16.2. XML Namespace Name for SASL Data . . . . . . . . . . . . 140 16.3. XML Namespace Name for Stream Errors . . . . . . . . . . 141 16.4. XML Namespace Name for Resource Binding . . . . . . . . 141 16.5. XML Namespace Name for Stanza Errors . . . . . . . . . . 141 16.6. Nodeprep Profile of Stringprep . . . . . . . . . . . . . 142 16.7. Resourceprep Profile of Stringprep . . . . . . . . . . . 142 16.8. GSSAPI Service Name . . . . . . . . . . . . . . . . . . 142 16.9. Port Numbers . . . . . . . . . . . . . . . . . . . . . . 142 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 143 17.1. Normative References . . . . . . . . . . . . . . . . . . 143 17.2. Informative References . . . . . . . . . . . . . . . . . 145 Appendix A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . 149 A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 149 A.2. Character Repertoire . . . . . . . . . . . . . . . . . . 149 A.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . 149 A.4. Normalization . . . . . . . . . . . . . . . . . . . . . 149 A.5. Prohibited Output . . . . . . . . . . . . . . . . . . . 150 Saint-Andre Expires January 2, 2009 [Page 7] Internet-Draft XMPP Core July 2008 A.6. Bidirectional Characters . . . . . . . . . . . . . . . . 150 A.7. Notes . . . . . . . . . . . . . . . . . . . . . . . . . 150 Appendix B. Resourceprep . . . . . . . . . . . . . . . . . . . . 151 B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 151 B.2. Character Repertoire . . . . . . . . . . . . . . . . . . 152 B.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . 152 B.4. Normalization . . . . . . . . . . . . . . . . . . . . . 152 B.5. Prohibited Output . . . . . . . . . . . . . . . . . . . 152 B.6. Bidirectional Characters . . . . . . . . . . . . . . . . 152 Appendix C. XML Schemas . . . . . . . . . . . . . . . . . . . . 152 C.1. Streams Namespace . . . . . . . . . . . . . . . . . . . 153 C.2. Stream Error Namespace . . . . . . . . . . . . . . . . . 154 C.3. STARTTLS Namespace . . . . . . . . . . . . . . . . . . . 156 C.4. SASL Namespace . . . . . . . . . . . . . . . . . . . . . 156 C.5. Resource Binding Namespace . . . . . . . . . . . . . . . 158 C.6. Stanza Error Namespace . . . . . . . . . . . . . . . . . 159 Appendix D. Contact Addresses . . . . . . . . . . . . . . . . . 161 Appendix E. Account Provisioning . . . . . . . . . . . . . . . . 161 Appendix F. Differences From RFC 3920 . . . . . . . . . . . . . 162 Appendix G. Copying Conditions . . . . . . . . . . . . . . . . . 163 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 164 Intellectual Property and Copyright Statements . . . . . . . . . 165 Saint-Andre Expires January 2, 2009 [Page 8] Internet-Draft XMPP Core July 2008 1. Introduction 1.1. Overview The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language [XML] for streaming XML data in close to real time between any two (or more) network-aware entities. XMPP is typically used to exchange messages, share presence information, and engage in structured request-response interactions. The basic syntax and semantics of XMPP were developed originally within the Jabber open-source community, mainly in 1999. In late 2002, the XMPP Working Group was chartered with developing an adaptation of the core Jabber protocol that would be suitable as an IETF instant messaging (IM) and presence technology. As a result of work by the XMPP WG, [RFC3920] and [RFC3921] were published in October 2004, representing the most complete definition of XMPP at that time. As a result of extensive implementation and deployment experience with XMPP since 2004, as well as more formal interoperability testing carried out under the auspices of the XMPP Standards Foundation (XSF), this document reflects consensus from the XMPP developer community regarding XMPP's core XML streaming technology. In particular, this document incorporates the following backward- compatible changes from RFC 3920: o Corrections and errata o Additional examples throughout o Clarifications and more complete specification of matters that were underspecified o Modifications to reflect updated technologies for which XMPP is a using protocol, e.g., Transport Layer Security (TLS) and the Simple Authentication and Security Layer (SASL) o Definition of several additional stream, stanza, and SASL error conditions o Removal of the deprecated DIGEST-MD5 SASL mechanism [DIGEST-MD5] as a mandatory-to-implement technology o Addition of TLS plus the SASL PLAIN mechanism [PLAIN] as a mandatory-to-implement technology o Definition of optional support for multiple resources over the same connection o Transfer of historical documentation for the server dialback protocol from this specification to a separate specification Therefore, this document defines the core features of XMPP 1.0 and obsoletes RFC 3920. Saint-Andre Expires January 2, 2009 [Page 9] Internet-Draft XMPP Core July 2008 Note: [XMPP-IM] defines the XMPP features needed to provide the basic instant messaging and presence functionality that is described in [IMP-REQS]. 1.2. Functional Summary This non-normative section provides a developer-friendly, functional summary of XMPP; refer to the sections that follow for a normative definition of XMPP. The purpose of XMPP is to enable the exchange of relatively small pieces of structured data (called "XML stanzas") over a network between any two (or more) entities. XMPP is implemented using a client-server architecture, wherein a client must connect to a server in order to gain access to the network and thus be allowed to exchange XML stanzas with other entities (which may be associated with other servers). The process whereby a client connects to a server, exchanges XML stanzas, and ends the connection is: 1. Determine the hostname and port at which to connect 2. Open a TCP connection 3. Open an XML stream 4. Complete TLS negotiation for channel encryption (recommended) 5. Complete SASL negotiation for authentication 6. Bind a resource to the stream 7. Exchange an unbounded number of XML stanzas with other entities on the network 8. Close the XML stream 9. Close the TCP connection Within XMPP, one server may optionally connect to another server to enable inter-domain or inter-server communication. For this to happen, the two servers must negotiate a connection between themselves and then exchange XML stanzas; the process for doing so is: 1. Determine the hostname and port at which to connect 2. Open a TCP connection 3. Open an XML stream 4. Complete TLS negotiation for channel encryption (recommended) 5. Complete SASL negotiation for authentication * 6. Exchange an unbounded number of XML stanzas both directly for the servers and indirectly on behalf of entities associated with each server (e.g., connected clients) 7. Close the XML stream 8. Close the TCP connection Saint-Andre Expires January 2, 2009 [Page 10] Internet-Draft XMPP Core July 2008 * Note: Depending on local service policies, it is possible that a deployed server will use the older server dialback protocol to provide weak identity verification in cases where SASL negotiation would not result in strong authentication (e.g., because TLS negotiation was not mandated by the peer server, or because the certificate presented by the peer server during TLS negotiation is self-signed and thus provides only weak identity); for details, see [XEP-0220]. In the sections following discussion of XMPP architecture and XMPP addresses, this document specifies how clients connect to servers and specifies the basic semantics of XML stanzas. However, this document does not define the "payloads" of the XML stanzas that might be exchanged once a connection is successfully established; instead, those payloads are defined by various XMPP extensions. For example, [XMPP-IM] defines extensions for basic instant messaging and presence functionality. In addition, various specifications produced in the XSF's XEP series [XEP-0001] define extensions for a wide range of more advanced functionality. 1.3. Conventions The following capitalized keywords are to be interpreted as described in [TERMS]: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL". The term "whitespace" is used to refer to any character that matches production [3] content of [XML]. Following the "XML Notation" used in [IRI] to represent characters that cannot be rendered in ASCII-only documents, some examples in this document use the form "&#x...." as a notational device to represent Unicode characters (e.g., the string "ř" stands for the Unicode character LATIN SMALL LETTER R WITH CARON). In examples, lines have been wrapped for improved readability, "[...]" means elision, and the following prepended strings are used (these prepended strings are not to be sent over the wire): o C: = a client o E: = any XMPP entity o I: = an initiating entity o P: = a peer server o R: = a receiving entity o S: = a server Saint-Andre Expires January 2, 2009 [Page 11] Internet-Draft XMPP Core July 2008 o S1: = server1 o S2: = server2 1.4. Acknowledgements The editor of this document finds it impossible to appropriately acknowledge the feedback he has received publicly and privately regarding the core XMPP protocols. However, thanks are due to the many developers who have provided bug reports, requests for clarification, and suggestions for improvement since the publication of RFC 3920. The editor has endeavored to address all such feedback, but is solely responsible for any remaining errors and ambiguities. 1.5. Discussion Venue The document editor and the broader XMPP developer community welcome discussion and comments related to the topics presented in this document. The preferred forum is the mailing list, for which archives and subscription information are available at <>. 2. Architecture 2.1. Overview XMPP assumes a client-server architecture, wherein a client utilizing XMPP accesses a server (normally over a [TCP] connection) and servers can also communicate with each other over TCP connections. A simplified architectural diagram for a typical deployment is shown here, where the entities have the following significance: o romeo@example.net -- an XMPP user. o example.net -- an XMPP server. o im.example.com -- an XMPP server. o juliet@im.example.com -- an XMPP user. example.net ---------------- im.example.com | | | | romeo@example.net juliet@im.example.com Note: Architectures that employ XML streams (Section 5) and XML stanzas (Section 9) but that establish peer-to-peer connections directly between clients using technologies based on [LINKLOCAL] have been deployed, but such architectures are not XMPP and are Saint-Andre Expires January 2, 2009 [Page 12] Internet-Draft XMPP Core July 2008 best described as "XMPP-like"; for details, see [XEP-0174]. In addition, XML streams can be established end-to-end over any reliable transport, including extensions to XMPP itself; for details, see [XEP-0246]. 2.2. Server A SERVER is an entity whose primary responsibilities are to: o Manage XML streams (Section 5) with local clients and deliver XML stanzas (Section 9) to those clients over the negotiated XML streams. o Subject to local service policies on server-to-server communication, manage XML streams (Section 5) with foreign servers and route XML stanzas (Section 9) to those servers over the negotiated XML streams. Depending on the application, the secondary responsibilities of an XMPP server may include: o Storing XML data that is used by clients (e.g., contact lists for users of XMPP-based instant messaging and presence applications as defined in [XMPP-IM]); in this case, the relevant XML stanza is handled directly by the server itself on behalf of the client and is not routed to a foreign server or delivered to a local entity. o Hosting local services that also use XMPP as the basis for communication but that provide additional functionality beyond that defined in this document or in [XMPP-IM]; examples include multi-user conferencing services as specified in [XEP-0045] and publish-subscribe services as specified in [XEP-0060]. 2.3. Client A CLIENT is an entity that establishes an XML stream with a server by authenticating using the credentials of a local account and that then completes resource binding (Section 8) in order to enable delivery of XML stanzas via the server to the client. A client then uses XMPP to communicate with its server, other clients, and any other accessible entities on a network. Multiple clients may connect simultaneously to a server on behalf of a local account, where each client is differentiated by the resource identifier portion of an XMPP address (e.g., vs. ), as defined under Section 3 and Section 8. The RECOMMENDED port for TCP connections between a client and a server is 5222, as registered with the IANA (see Section 16.9). Saint-Andre Expires January 2, 2009 [Page 13] Internet-Draft XMPP Core July 2008 2.4. Network Because each server is identified by a network address and because server-to-server communication is a straightforward extension of the client-to-server protocol, in practice the system consists of a network of servers that inter-communicate. Thus, for example, is able to exchange messages, presence, and other information with . This pattern is familiar from messaging protocols (such as [SMTP]) that make use of network addressing standards. Communication between any two servers is OPTIONAL. The RECOMMENDED port for TCP connections between servers is 5269, as registered with the IANA (see Section 16.9). 3. Addresses 3.1. Overview An ENTITY is anything that is network-addressable and that can communicate using XMPP. For historical reasons, the native address of an XMPP entity is called a JABBER IDENTIFIER or JID. A valid JID contains a set of ordered elements formed of an XMPP node identifier, domain identifier, and resource identifier. The syntax for a JID is defined as follows using the Augmented Backus-Naur Form as specified in [ABNF]. jid = [ node "@" ] domain [ "/" resource ] node = 1*(nodepoint) ; a "nodepoint" is a UTF-8 encoded Unicode code ; point that satisfies the Nodeprep profile of ; stringprep domain = fqdn / address-literal / idnlabel fqdn = (idnlabel 1*("." idnlabel)) ; an "idnlabel" is an internationalized label ; as described in RFC 3490 address-literal = IPv4address / IPv6address ; the "IPv4address" and "IPv6address" rules are ; defined in Appendix B of RFC 2373 resource = 1*(resourcepoint) ; a "resourcepoint" is a UTF-8 encoded Unicode ; code point that satisfies the Resourceprep ; profile of stringprep Note: The "IPv4address" and "IPv6address" rules are indeed provided in [RFC2373] and were removed from [IPv6], which superseded RFC 2373. Saint-Andre Expires January 2, 2009 [Page 14] Internet-Draft XMPP Core July 2008 All JIDs are based on the foregoing structure. One common use of this structure is to identify a messaging and presence account, the server that hosts the account, and a connected resource (e.g., a specific device) in the form of . However, node types other than clients are possible; for example, a specific chat room offered by a multi-user conference service (see [XEP-0045]) could be addressed as (where "room" is the name of the chat room and "service" is the hostname of the multi-user conference service) and a specific occupant of such a room could be addressed as (where "nick" is the occupant's room nickname). Many other JID types are possible (e.g., could be a server-side script or service). Each allowable portion of a JID (node identifier, domain identifier, and resource identifier) MUST NOT be more than 1023 bytes in length, resulting in a maximum total size (including the '@' and '/' separators) of 3071 bytes. Note: While the format of a JID is consistent with [URI], an entity's address on an XMPP network MUST be represented as a JID (without a URI scheme) and not a [URI] or [IRI] as specified in [XMPP-URI]; the latter specification is provided only for identification and interaction outside the context of the XMPP wire protocol itself. 3.2. Domain Identifier The DOMAIN IDENTIFIER portion of a JID is that portion after the '@' character (if any) and before the '/' character (if any); it is the primary identifier and is the only REQUIRED element of a JID (a mere domain identifier is a valid JID). Typically a domain identifier identifies the "home" server to which clients connect for XML routing and data management functionality. However, it is not necessary for an XMPP domain identifier to identify an entity that provides core XMPP server functionality (e.g., a domain identifier can identity an entity such as a multi-user conference service, a publish-subscribe service, or a user directory). Note: A single server can service multiple domain identifiers, i.e., multiple local domains; this is typically referred to as virtual hosting. The domain identifier for every server or service that will communicate over a network SHOULD be a fully qualified domain name (see [DNS]); while the domain identifier MAY be either an Internet Protocol (IPv4 or IPv6) address or a text label that is resolvable on a local network (commonly called an "unqualified hostname"), it is possible that domain identifiers that are IP addresses will not be Saint-Andre Expires January 2, 2009 [Page 15] Internet-Draft XMPP Core July 2008 acceptable to other services for the sake of interdomain communication. Furthermore, domain identifiers that are unqualified hostnames MUST NOT be used on public networks but MAY be used on private networks. Note: If the domain identifier includes a final character considered to be a label separator (dot) by [IDNA] or [STD13], this character MUST be stripped from the domain identifier before the JID of which it is a part is used for the purpose of routing an XML stanza, comparing against another JID, or constructing an [XMPP-URI]; in particular, the character MUST be stripped before any other canonicalization steps are taken, such as application of the [NAMEPREP] profile of [STRINGPREP] or completion of the ToASCII operation as described in [IDNA]. A domain identifier MUST be an "internationalized domain name" as defined in [IDNA], that is, "a domain name in which every label is an internationalized label". When preparing a text label (consisting of a sequence of Unicode code points) for representation as an internationalized label in the process of constructing an XMPP domain identifier or comparing two XMPP domain identifiers, an application MUST ensure that for each text label it is possible to apply without failing the ToASCII operation specified in [IDNA] with the UseSTD3ASCIIRules flag set (thus forbidding ASCII code points other than letters, digits, and hyphens). If the ToASCII operation can be applied without failing, then the label is an internationalized label. An internationalized domain name (and therefore an XMPP domain identifier) is constructed from its constituent internationalized labels by following the rules specified in [IDNA]. Note: The ToASCII operation includes application of the [NAMEPREP] profile of [STRINGPREP] and encoding using the algorithm specified in [PUNYCODE]; for details, see [IDNA]. Although the output of the ToASCII operation is not used in XMPP, it MUST be possible to apply that operation without failing. 3.3. Node Identifier The NODE IDENTIFIER portion of a JID is an optional secondary identifier placed before the domain identifier and separated from the latter by the '@' character. Typically a node identifier uniquely identifies the entity requesting and using network access provided by a server (i.e., a local account), although it can also represent other kinds of entities (e.g., a chat room associated with a multi- user conference service). The entity represented by an XMPP node identifier is addressed within the context of a specific domain. A node identifier MUST be formatted such that the Nodeprep profile of Saint-Andre Expires January 2, 2009 [Page 16] Internet-Draft XMPP Core July 2008 [STRINGPREP] can be applied without failing (see Appendix A). Before comparing two node identifiers, an application MUST first ensure that the Nodeprep profile has been applied to each identifier (the profile need not be applied each time a comparison is made, as long as it has been applied before comparison). 3.4. Resource Identifier The RESOURCE IDENTIFIER portion of a JID is an optional tertiary identifier placed after the domain identifier and separated from the latter by the '/' character. A resource identifier can modify either a address or a mere address. Typically a resource identifier uniquely identifies a specific connection (e.g., a device or location) or object (e.g., a participant in a multi-user conference room) belonging to the entity associated with an XMPP node identifier at a local domain. When an XMPP address does not include a resource identifier (i.e., when it is of the form or ), it is referred to as a BARE JID. When an XMPP address includes a resource identifier (i.e., when it is of the form or ), is referred to as a FULL JID. A resource identifier MUST be formatted such that the Resourceprep profile of [STRINGPREP] can be applied without failing (see Appendix B). Before comparing two resource identifiers, an application MUST first ensure that the Resourceprep profile has been applied to each identifier (the profile need not be applied each time a comparison is made, as long as it has been applied before comparison). Note: For historical reasons, the term "resource identifier" is used in XMPP to refer to the optional portion of an XMPP address that follows the domain identifier and the "/" separator character; this use of the term "resource identifier" is not to be confused with the meanings of "resource" and "identifier" provided in Section 1.1 of [URI]. XMPP entities SHOULD consider resource identifiers to be opaque strings and SHOULD NOT impute meaning to any given resource identifier. In paticular, the use of the '/' character as a separator between the domain identifier and the resource identifier does not imply that resource identifiers are hierarchical in the say that, say, HTTP addresses are hierarchical; thus for example an XMPP address of the form does not identify a resource "bar" that exists below a resource "foo" in a hierarchy of resources associated with the entity "node@domain". Saint-Andre Expires January 2, 2009 [Page 17] Internet-Draft XMPP Core July 2008 3.5. Determination of Addresses After the parties to an XML stream have completed the appropriate aspects of stream negotiation (typically SASL negotiation (Section 7) and, if appropriate, resource binding (Section 8)) the receiving entity for a stream MUST determine the initiating entity's JID. For server-to-server communication, the initiating server's JID MUST be the authorization identity (as defined by [SASL]), either (1) as directly communicated by the initiating server during SASL negotiation (Section 7) or (2) as derived by the receiving server from the authentication identity if no authorization identity was specified during SASL negotiation (Section 7). (For information about the determination of addresses in the absence of SASL negotiation when the older server dialback protocol is used, see [XEP-0220].) For client-to-server communication, the client's bare JID () MUST be the authorization identity (as defined by [SASL]), either (1) as directly communicated by the client during SASL negotiation (Section 7) or (2) as derived by the server from the authentication identity if no authorization identity was specified during SASL negotiation (Section 7). The resource identifier portion of the full JID () MUST be the resource identifier negotiated by the client and server during resource binding (Section 8). The receiving entity MUST ensure that the resulting JID (including node identifier, domain identifier, resource identifier, and separator characters) conforms to the rules and formats defined earlier in this section; to meet this restriction, the receiving entity MAY replace the JID sent by the initiating entity with the canonicalized JID as determined by the receiving entity. 4. TCP Binding 4.1. Scope As XMPP is defined in this specification, an initiating entity (client or server) MUST open a Transmission Control Protocol [TCP] connection at the receiving entity (server) before it negotiates XML streams with the receiving entity. The rules specified in the following sections apply to the TCP binding. Saint-Andre Expires January 2, 2009 [Page 18] Internet-Draft XMPP Core July 2008 4.2. Hostname Resolution Before opening the TCP connection, the initiating entity first MUST resolve the Domain Name System (DNS) hostname associated with the receiving entity and determine the appropriate TCP port for communication with the receiving entity. The process is: 1. Attempt to resolve the hostname using a [DNS-SRV] Service of "xmpp-client" (for client-to-server connections) or "xmpp-server" (for server-to-server connections) and a Proto of "tcp", resulting in resource records such as "_xmpp- client._tcp.example.net." or "_xmpp-server._tcp.im.example.com.". The result of the SRV lookup will be one or more combinations of a port and hostname; the initiating entity MUST resolve one of the hostnames in order to determine an IP address at which to connect. 2. If the SRV lookup fails, the fallback SHOULD be a normal IPv4 or IPv6 address record resolution to determine the IP address, where the port used is the "xmpp-client" port of 5222 for client-to- server connections or the "xmpp-server" port 5269 for server-to- server connections. 3. For client-to-server connections, the fallback MAY be a [DNS-TXT] lookup for alternative connection methods, for example as described in [XEP-0156]. Note: Many XMPP servers are implemented in such a way that they can host additional services (beyond those defined in this specification and [XMPP-IM]) at hostnames that are subdomains of the hostname of the main XMPP service (e.g., conference.example.net for a [XEP-0045] service associated with the example.net XMPP service) or subdomains of the first-level domain of the underlying host (e.g., muc.example.com for a [XEP-0045] service associated with the im.example.com XMPP service). If an entity from a remote domain wishes to use such additional services, it would generate an appropriate XML stanza and the remote domain itself would attempt to resolve the service's hostname via an SRV lookup on resource records such as "_xmpp-server._tcp.conference.example.net." or "_xmpp- server._tcp.muc.example.com.". Therefore if a service wishes to enable entities from remote domains to access these additional services, it needs to advertise the appropriate "_xmpp-server" SRV records in addition to the "_xmpp-server" record for its main XMPP service. 4.3. Client-to-Server Communication Because a client is subordinate to a server and therefore a client authenticates to the server but the server does not necessarily Saint-Andre Expires January 2, 2009 [Page 19] Internet-Draft XMPP Core July 2008 authenticate to the client, it is necessary to have only one TCP connection between client and server. Thus the server MUST allow the client to share a single TCP connection for XML stanzas sent from client to server and from server to client (i.e., the inital stream and response stream as specified under Section 5). 4.4. Server-to-Server Communication Because two servers are peers and therefore each peer must authenticate with the other, the servers MUST use two TCP connections: one for XML stanzas sent from the first server to the second server and another (initiated by the second server) for XML stanzas from the second server to the first server. This rule applies only to XML stanzas (Section 9). Therefore during STARTTLS negotiation (Section 6) and SASL negotiation (Section 7) the servers would use one TCP connection, but after stream setup that TCP connection would be used only for the initiating server to send XML stanzas to the receiving server. In order for the receiving server to send XML stanzas to the initiating server, the receiving server would need to reverse the roles and negotiate an XML stream from the receiving server to the initiating server. 4.5. Reconnection It can happen that an XMPP server goes offline while servicing TCP connections from local clients and from other servers. Because the number of such connections can be quite large, the reconnection algorithm employed by entities that seek to reconnect can have a significant impact on software and network performance. The following guidelines are RECOMMENDED: o The time to live (TTL) specified in Domain Name System records MUST be honored, even if DNS results are cached; if the TTL has not expired, an entity that seeks to reconnect MUST NOT re-resolve the server hostname before reconnecting. o The time that expires before an entity first seeks to reconnect MUST be randomized (e.g., so that all clients do not attempt to reconnect exactly 30 seconds after being disconnected). o If the first reconnection attempt does not succeed, an entity MUST back off increasingly on the time between subsequent reconnection attempts. Note: Because it is possible that a disconnected entity cannot determine the cause of disconnection (e.g., because there was no explicit stream error) or does not require a new stream for immediate communication (e.g., because the stream was idle and therefore timed out), it SHOULD NOT assume that is needs to Saint-Andre Expires January 2, 2009 [Page 20] Internet-Draft XMPP Core July 2008 reconnect immediately. 4.6. Other Bindings There is no necessary coupling of an XML stream to a TCP connection. For example, two entities could connect to each other via another transport, such as [HTTP] as specified in [XEP-0124] and [XEP-0206]. Although this specification neither encourages nor discourages other bindings, it defines only a binding of XMPP to TCP. 5. XML Streams 5.1. Overview Two fundamental concepts make possible the rapid, asynchronous exchange of relatively small payloads of structured information between presence-aware entities: XML streams and XML stanzas. These terms are defined as follows. Definition of XML Stream: An XML STREAM is a container for the exchange of XML elements between any two entities over a network. The start of an XML stream is denoted unambiguously by an opening STREAM HEADER (i.e., an XML tag with appropriate attributes and namespace declarations), while the end of the XML stream is denoted unambiguously by a closing XML tag. During the life of the stream, the entity that initiated it can send an unbounded number of XML elements over the stream, either elements used to negotiate the stream (e.g., to complete TLS negotiation (Section 6) or SASL negotiation (Section 7)) or XML stanzas. The INITIAL STREAM is negotiated from the initiating entity (typically a client or server) to the receiving entity (typically a server), and can be seen as corresponding to the initiating entity's "connection" or "session" with the receiving entity. The initial stream enables unidirectional communication from the initiating entity to the receiving entity; in order to enable information exchange from the receiving entity to the initiating entity, the receiving entity MUST negotiate a stream in the opposite direction (the RESPONSE STREAM). Definition of XML Stanza: An XML STANZA is a discrete semantic unit of structured information that is sent from one entity to another over an XML stream, and is the basic unit of meaning in XMPP. An XML stanza exists at the direct child level of the root element; the start of any XML stanza is denoted unambiguously by the element start tag at depth=1 of the XML stream (e.g., ), and the end of any XML stanza is denoted unambiguously by the corresponding close tag at depth=1 (e.g., ). The only XML stanzas defined herein are the Saint-Andre Expires January 2, 2009 [Page 21] Internet-Draft XMPP Core July 2008 , , and elements qualified by the default namespace for the stream, as described under Section 9; for example, an XML element sent for the purpose of TLS negotiation (Section 6) or SASL negotiation (Section 7) is not considered to be an XML stanza, nor is a stream error or a stream feature. An XML stanza MAY contain child elements (with accompanying attributes, elements, and XML character data) as necessary in order to convey the desired information, which MAY be qualified by any XML namespace (see [XML-NAMES] as well as Section 9.4 herein). Consider the example of a client's connection to a server. In order to connect to a server, a client initiates an XML stream by sending a stream header to the server, optionally preceded by a text declaration specifying the XML version and the character encoding supported (see Section 12.5 and Section 12.6). Subject to local policies and service provisioning, the server then replies with a second XML stream back to the client, again optionally preceded by a text declaration. Once the client has completed SASL negotiation (Section 7) and resource binding (Section 8), the client can send an unbounded number of XML stanzas over the stream. When the client desires to close the stream, it simply sends a closing tag to the server as further described under Section 5.7. In essence, then, an XML stream acts as an envelope for all the XML stanzas sent during a connection. We can represent this in a simplistic fashion as follows. Saint-Andre Expires January 2, 2009 [Page 22] Internet-Draft XMPP Core July 2008 +--------------------+ | | |--------------------| | | | | | | |--------------------| | | | | | | |--------------------| | | | | | | |--------------------| | | | | | | |--------------------| | [ ... ] | |--------------------| | | +--------------------+ Note: Those who are accustomed to thinking of XML in a document- centric manner may wish to view a client's connection to a server as consisting of two open-ended XML documents: one from the client to the server and one from the server to the client. On this analogy, the two XML streams can be considered equivalent to two "documents" (matching production [1] content of [XML]) that are built up through the accumulation of XML stanzas, the root element can be considered equivalent to the "document entity" for each "document" (as described in Section 4.8 of [XML]), and the XML stanzas sent over the streams can be considered equivalent to "fragments" of the "documents" as described in [XML-FRAG]. However, this perspective is merely an analogy; XMPP does not deal in documents and fragments but in streams and stanzas. 5.2. Stream Security For the purpose of stream security, both Transport Layer Security (see Section 6) and the Simple Authentication and Security Layer (see Section 7) are mandatory to implement. Use of these technologies results in high security as described under Section 15.1. The initial stream and the response stream MUST be secured separately, although security in both directions MAY be established Saint-Andre Expires January 2, 2009 [Page 23] Internet-Draft XMPP Core July 2008 via mechanisms that provide mutual authentication. The initiating entity MUST NOT attempt to send XML stanzas (Section 9) over the stream before the stream has been authenticated. However, if it does attempt to do so, the receiving entity MUST NOT accept such stanzas and MUST return a stream error. This rule applies to XML stanzas only (i.e., , , and elements qualified by the default namespace) and not to XML elements used for stream negotiation (e.g., elements used to complete TLS negotiation (Section 6) or SASL negotiation (Section 7)). 5.3. Stream Attributes The attributes of the root element are defined in the following sections. Note: The attributes of the root element are not prepended by a 'stream:' prefix because, in accordance with Section 5.3 of [XML-NAMES], the default namespace does not apply to attribute names. 5.3.1. from The 'from' attribute communicates an XMPP identity of the entity sending the stream element. Note: It is possible for an entity to have more than one XMPP identity (e.g., in the case of a server that provides virtual hosting). It is also possible that an entity does not know the XMPP identity of the principal controlling the entity (e.g., because the XMPP identity is assigned at a level other than the XMPP application layer, as in the General Security Service Application Program Interface [GSS-API]). For initial stream headers in client-to-server communication, if the client knows the XMPP identity of the principal controlling the client (typically an account name of the form ), then it MUST include the 'from' attribute and MUST set its value to that identity. If the client does not know the XMPP identity of the principal controlling the client, then it MUST NOT include the 'from' attribute. Saint-Andre Expires January 2, 2009 [Page 24] Internet-Draft XMPP Core July 2008 I: For initial stream headers in server-to-server communication, a server MUST include the 'from' attribute and MUST set its value to a hostname serviced by the initiating entity. I: For response stream headers in both client-to-server and server-to- server communication, the receiving entity MUST include the 'from' attribute and MUST set its value to a hostname serviced by the receiving entity (which MAY be a hostname other than that specified in the 'to' attribute of the initial stream header). R: Whether or not the 'from' attribute is included, each entity MUST verify the identity of the other entity before exchanging XML stanzas with it (see Section 15.3 and Section 15.4). Note: It is possible that implementations based on an earlier revision of this specification will not include the 'from' address on stream headers; an entity SHOULD be liberal in accepting such stream headers. Saint-Andre Expires January 2, 2009 [Page 25] Internet-Draft XMPP Core July 2008 5.3.2. to For initial stream headers in both client-to-server and server-to- server communication, the initiating entity MUST include the 'to' attribute and MUST set its value to a hostname that the initiating entity knows or expects the receiving entity to service. I: For response stream headers in client-to-server communication, if the client included a 'from' attribute in the initial stream header then the server MUST include a 'to' attribute in the response stream header and MUST set its value to the bare JID specified in the 'from' attribute of the initial stream header. If the client did not include a 'from' attribute in the initial stream header then the server MUST NOT include a 'to' attribute in the response stream header. R: For response stream headers in server-to-server communication, the receiving entity MUST include a 'to' attribute in the response stream header and MUST set its value to the hostname specified in the 'from' attribute of the initial stream header. R: Whether or not the 'to' attribute is included, each entity MUST verify the identity of the other entity before exchanging XML stanzas with it (see Section 15.3 and Section 15.4). Note: It is possible that implementations based on an earlier revision of this specification will not include the 'from' address on stream headers; an entity SHOULD be liberal in accepting such stream headers. 5.3.3. id The 'id' attribute communicates a unique identifier for the stream. This identifier is called a STREAM ID. The stream ID MUST be generated by the receiving entity when it sends a response stream header, MUST BE unique within the receiving application (normally a server), and MUST be both unpredictable and nonrepeating because it can be security-critical (see [RANDOM] for recommendations regarding randomness for security purposes). For initial stream headers, the initiating entity MUST NOT include the 'id' attribute; however, if the 'id' attribute is included, the receiving entity MUST silently ignore it. For response stream headers, the receiving entity MUST include the 'id' attribute. R: 5.3.4. xml:lang The 'xml:lang' attribute communicates an entity's preferred or default language for any human-readable XML character data to be sent over the stream. The syntax of this attribute is defined in Section 2.12 of [XML]; in particular, the value of the 'xml:lang' attribute MUST conform to the NMTOKEN datatype (as defined in Section 2.3 of [XML]) and MUST conform to the language identifier format defined in [LANGTAGS]. Saint-Andre Expires January 2, 2009 [Page 27] Internet-Draft XMPP Core July 2008 For initial stream headers, the initiating entity SHOULD include the 'xml:lang' attribute. I: For response stream headers, the receiving entity MUST include the 'xml:lang' attribute. If the initiating entity included an 'xml: lang' attribute in its initial stream header and the receiving entity supports that language in the human-readable XML character data that it generates and sends to the initiating entity (e.g., in the element for stream and stanza errors), the value of the 'xml:lang' attribute MUST be identifier for the initiating entity's preferred language; if the receiving entity supports a language that closely matches the initiating entity's preferred language (e.g., "de" instead of "de-CH"), then the value of the 'xml:lang' attribute SHOULD be the identifier for the matching language but MAY be the identifier for the default language of the receiving entity; if the receiving entity does not support the initiating entity's preferred language or a closely matching language (or the initiating entity did not include the 'xml:lang' attribute in its initial stream header), then the value of the 'xml:lang' attribute MUST be the identifier for the default language of the receiving entity. R: If the initiating entity included the 'xml:lang' attribute in its initial stream header, the receiving entity SHOULD remember that value as the default xml:lang for all stanzas sent by the initiating entity. As described under Section 9.1.5, the initiating entity MAY include the 'xml:lang' attribute in any XML stanzas it sends over the stream. If the initiating entity does not include the 'xml:lang' attribute in any such stanza, the receiving entity SHOULD add the 'xml:lang' attribute to the stanza, whose value MUST be the Saint-Andre Expires January 2, 2009 [Page 28] Internet-Draft XMPP Core July 2008 identifier for the language preferred by the initiating entity (even if the receiving entity does not support that language for human- readable XML character data it generates and sends to the initiating entity, such as in stream or stanza errors). If the initiating entity includes the 'xml:lang' attribute in any such stanza, the receiving entity MUST NOT modify or delete it. 5.3.5. version The inclusion of the version attribute set to a value of at least "1.0" signals support for the stream-related protocols defined in this specification, including (TLS negotiation (Section 6), SASL negotiation (Section 7), Section 5.5, and stream errors (Section 5.8). The version of XMPP specified herein is "1.0"; in particular, XMPP 1.0 encapsulates the stream-related protocols as well as the basic semantics of the three defined XML stanza types (, , and ). The numbering scheme for XMPP versions is ".". The major and minor numbers MUST be treated as separate integers and each number MAY be incremented higher than a single digit. Thus, "XMPP 2.4" would be a lower version than "XMPP 2.13", which in turn would be lower than "XMPP 12.3". Leading zeros (e.g., "XMPP 6.01") MUST be ignored by recipients and MUST NOT be sent. The major version number will be incremented only if the stream and stanza formats or required actions have changed so dramatically that an older version entity would not be able to interoperate with a newer version entity if it simply ignored the elements and attributes it did not understand and took the actions specified in the older specification. The minor version number will be incremented only if significant new capabilities have been added to the core protocol (e.g., a newly defined value of the 'type' attribute for message, presence, or IQ stanzas). The minor version number MUST be ignored by an entity with a smaller minor version number, but MAY be used for informational purposes by the entity with the larger minor version number (e.g., the entity with the larger minor version number would simply note that its correspondent would not be able to understand that value of the 'type' attribute and therefore would not send it). The following rules apply to the generation and handling of the 'version' attribute within stream headers: Saint-Andre Expires January 2, 2009 [Page 29] Internet-Draft XMPP Core July 2008 1. The initiating entity MUST set the value of the 'version' attribute in the initial stream header to the highest version number it supports (e.g., if the highest version number it supports is that defined in this specification, it MUST set the value to "1.0"). 2. The receiving entity MUST set the value of the 'version' attribute in the response stream header to either the value supplied by the initiating entity or the highest version number supported by the receiving entity, whichever is lower. The receiving entity MUST perform a numeric comparison on the major and minor version numbers, not a string match on ".". 3. If the version number included in the response stream header is at least one major version lower than the version number included in the initial stream header and newer version entities cannot interoperate with older version entities as described, the initiating entity SHOULD generate an stream error. 4. If either entity receives a stream header with no 'version' attribute, the entity MUST consider the version supported by the other entity to be "0.9" and SHOULD NOT include a 'version' attribute in the response stream header. 5.3.6. Summary of Stream Attributes The following table summarizes the attributes of the root element. +----------+--------------------------+-------------------------+ | | initiating to receiving | receiving to initiating | +----------+--------------------------+-------------------------+ | to | JID of receiver | JID of initiator | | from | JID of initiator | JID of receiver | | id | silently ignored | stream identifier | | xml:lang | default language | default language | | version | XMPP 1.0+ supported | XMPP 1.0+ supported | +----------+--------------------------+-------------------------+ 5.4. Namespace Declarations The stream element MUST possess both a streams namespace declaration and a default namespace declaration (as "namespace declaration" is defined in [XML-NAMES]). For detailed information regarding the streams namespace and default namespace, see Section 12.2. Saint-Andre Expires January 2, 2009 [Page 30] Internet-Draft XMPP Core July 2008 5.5. Stream Features If the initiating entity includes the 'version' attribute set to a value of at least "1.0" in the initial stream header, after sending the response stream header the receiving entity MUST send a child element (prefixed by the streams namespace prefix) to the initiating entity in order to announce any stream-level features that can be negotiated or capabilities that otherwise need to be advertised. R: R: Stream features are used mainly to advertise TLS negotiation (Section 6), SASL negotiation (Section 7), and resource binding (Section 8); however, stream features also can be used to advertise features associated with various XMPP extensions. If an entity does not understand or support a feature that has been advertised, it MUST silently ignore the associated feature advertisement. If it is necessary for a feature to be successfully negotiated before the initiating entity is allowed to proceed with the sending of XML stanzas or with further steps of the stream negotiation, the advertisement of that feature MUST include an empty child element. R: If successful negotiation of a feature is discretionary, the advertisement of that feature MUST include an empty child element. Saint-Andre Expires January 2, 2009 [Page 31] Internet-Draft XMPP Core July 2008 R: Note: Implementations based on an earlier revision of this specification do not include the child element and they include the child element only in the case of the STARTTLS feature. Entities MUST accept stream feature advertisements without the child elements, and SHOULD consider consider negotiation of such features to be discretionary. If it is necessary for a feature to be successfully negotiated before the initiating entity is allowed to proceed with the sending a non- security-related feature or with further steps of the stream negotiation, the receiving entity SHOULD NOT advertise any other stream features until the mandatory feature has been successfully negotiated; however, if the mandatory feature is security-critical (e.g., STARTTLS or SASL) then the receiving entity MUST NOT advertise any other stream features until the security-critical feature has been successfully negotiated. The order of child elements contained in any given element is not significant. After completing negotiation of any stream feature (even stream features that do not require a stream restart), the receiving entity MUST send an updated list of stream features to the initiating entity. However, if there are no features to be advertised then the receiving entity MUST send an empty element. R: R: At any time after stream establishment, the receiving entity MAY send additional or modified stream feature advertisements (e.g., because a new feature has been enabled). Saint-Andre Expires January 2, 2009 [Page 32] Internet-Draft XMPP Core July 2008 5.6. Restarts During Stream Negotiation Certain stream features require the initiating entity to send a new initial stream header on successful negotiation of the feature (e.g., after successful negotiation of TLS or SASL). Both parties MUST consider the previous stream to be replaced on successful feature negotiation but MUST NOT terminate the underlying TCP connection; instead, the parties MUST reuse the existing connection, which might be in a new state (e.g., encrypted as a result of TLS negotiation). When the receiving entity receives the new initial stream header, it MUST generate a new stream ID (instead of re-using the old stream ID) before sending a new response stream header. 5.7. Closing a Stream An XML stream between two entities can be closed because a stream error has occurred or in some cases in the absence of an error. Where feasible, it is preferable to close a stream only if a stream error has occurred. A stream is closed by sending a closing tag over the TCP connection. S: After an entity sends a closing stream tag, it MUST NOT send further data over that stream. 5.7.1. With Stream Error If a stream error has occurred, the entity that detects the error MUST close the stream as described under Section 5.8.1. 5.7.2. Without Stream Error At any time after XML streams have been negotiated between two entities, either entity MAY close its stream to the other party in the absence of a stream error by sending a closing stream tag. P: The entity that sends the closing stream tag SHOULD wait for the other party to also close its stream. S: However, the entity that sends the first closing stream tag MAY consider both streams to be void if the other party does not send its Saint-Andre Expires January 2, 2009 [Page 33] Internet-Draft XMPP Core July 2008 closing stream tag within a reasonable amount of time (where the definition of "reasonable" is a matter of implementation or deployment). After the entity that sent the first closing stream tag receives a reciprocal closing stream tag from the other party (or if it considers the stream to be void after a reasonable amount of time), it MUST terminate the underlying TCP connection or connections. 5.7.3. Handling of Idle Streams An XML stream can become idle, i.e., neither entity has sent XMPP traffic over the stream for some period of time. A server MAY close an idle stream with a local client or remote server, preferably through use of the stream error. The idle timeout period is a matter of implementation and local service policy; however, it is RECOMMENDED to be liberal in accepting idle streams, since experience has shown that doing so improves the reliability of communications over XMPP networks. In particular, it is typically more efficient to maintain a stream between two servers than it is to aggressively timeout such a stream, especially with regard to synchronization of presence information as described in [XMPP-IM]; therefore it is RECOMMENDED to maintain such a stream since experience has shown that server-to-server streams are cyclical and typically need to be re-established every 24 to 48 hours if they are timed out. An XML stream can appear idle at the XMPP level because the undelying TCP connection has become idle (e.g., a client's network connection has been lost). The typical method for detecting an idle TCP connection is to send a space character (U+0020) over the TCP connection between XML stanzas, which is allowed for XML streams as described under Section 12.7. The sending of such a space character is called a WHITESPACE PING. The time between such whitespace pings is a matter of implementation and local service policy; however, it is RECOMMENDED that these pings be sent not more than once every 60 seconds. 5.8. Stream Errors The root stream element MAY contain an child element that is prefixed by the streams namespace prefix. The error child shall be sent by a compliant entity if it perceives that a stream-level error has occurred. Saint-Andre Expires January 2, 2009 [Page 34] Internet-Draft XMPP Core July 2008 5.8.1. Rules The following rules apply to stream-level errors. 5.8.1.1. Stream Errors Are Unrecoverable Stream-level errors are unrecoverable. Therefore, if an error occurs at the level of the stream, the entity that detects the error MUST send a element with an appropriate child element that specifies the error condition and at the same time send a closing tag. C: S: The entity that generates the stream error then SHOULD immediately terminate the underlying TCP connection, although it MAY wait until after it receives a closing tag from the entity to which it sent the stream error. C: 5.8.1.2. Stream Errors Can Occur During Setup If the error is triggered by the initial stream header, the receiving entity MUST still send the opening tag, include the element as a child of the stream element, and send the closing tag (preferably all at the same time). Saint-Andre Expires January 2, 2009 [Page 35] Internet-Draft XMPP Core July 2008 C: S: 5.8.1.3. Stream Errors When the Host is Unspecified or Unknown If the initiating entity provides no 'to' attribute or provides an unknown host in the 'to' attribute and the error occurs during stream setup, the receiving entity MUST provide an authoritative hostname in the 'from' attribute of the stream header sent before termination. Saint-Andre Expires January 2, 2009 [Page 36] Internet-Draft XMPP Core July 2008 C: S: 5.8.2. Syntax The syntax for stream errors is as follows, where "defined-condition" is a placeholder for one of the conditions defined under Section 5.8.3. [ [ ... descriptive text ... ] ] [application-specific condition element] The element: o MUST contain a child element corresponding to one of the defined stream error conditions (Section 5.8.3); this element MUST be qualified by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace. o MAY contain a child element containing XML character data that describes the error in more detail; this element MUST be qualified by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace and SHOULD possess an 'xml:lang' attribute specifying the natural Saint-Andre Expires January 2, 2009 [Page 37] Internet-Draft XMPP Core July 2008 language of the XML character data. o MAY contain a child element for an application-specific error condition; this element MUST be qualified by an application- defined namespace, and its structure is defined by that namespace (see Section 5.8.4). The element is OPTIONAL. If included, it MUST be used only to provide descriptive or diagnostic information that supplements the meaning of a defined condition or application-specific condition. It MUST NOT be interpreted programmatically by an application. It MUST NOT be used as the error message presented to a human user, but MAY be shown in addition to the error message associated with the defined condition element (and, optionally, the application-specific condition element). 5.8.3. Defined Stream Error Conditions The following stream-level error conditions are defined. 5.8.3.1. bad-format The entity has sent XML that cannot be processed. (In the following example, the client sends an XMPP message that is not well-formed XML.) C: No closing body tag! S: This error MAY be used instead of the more specific XML-related errors, such as , , , , and . However, the more specific errors are RECOMMENDED. 5.8.3.2. bad-namespace-prefix The entity has sent a namespace prefix that is unsupported, or has sent no namespace prefix on an element that requires such a prefix (see Section 12.2). (In the following example, the client specifies a namespace prefix of Saint-Andre Expires January 2, 2009 [Page 38] Internet-Draft XMPP Core July 2008 "foobar" for the XML streams namespace.) C: S: 5.8.3.3. conflict The server is either (1) closing the existing stream for this entity because a new stream has been initiated that conflicts with the existing stream, or (2) is refusing a new stream for this entity because allowing the new stream would conflict with an existing stream (e.g., because the server allows only a certain number of connections from the same IP address). Saint-Andre Expires January 2, 2009 [Page 39] Internet-Draft XMPP Core July 2008 C: S: 5.8.3.4. connection-timeout The entity has not generated any traffic over the stream for some period of time (configurable according to a local service policy) and therefore the connection is being dropped. P: 5.8.3.5. host-gone The value of the 'to' attribute provided in the initial stream header corresponds to a hostname that is no longer serviced by the receiving entity. (In the following example, the peer specifies a 'to' address of "foo.im.example.com" when connecting to the "im.example.com" server, but the server no longer hosts a service at that address.) Saint-Andre Expires January 2, 2009 [Page 40] Internet-Draft XMPP Core July 2008 P: S: 5.8.3.6. host-unknown The value of the 'to' attribute provided in the initial stream header does not correspond to a hostname that is serviced by the receiving entity. (In the following example, the peer specifies a 'to' address of "example.org" when connecting to the "im.example.com" server, but the server knows nothing of that address.) Saint-Andre Expires January 2, 2009 [Page 41] Internet-Draft XMPP Core July 2008 P: S: 5.8.3.7. improper-addressing A stanza sent between two servers lacks a 'to' or 'from' attribute, the 'from' or 'to' attribute has no value, or the value is not a valid XMPP address. (In the following example, the peer sends a stanza without a 'to' address.) P: Wherefore art thou? S: 5.8.3.8. internal-server-error The server has experienced a misconfiguration or an otherwise- undefined internal error that prevents it from servicing the stream. Saint-Andre Expires January 2, 2009 [Page 42] Internet-Draft XMPP Core July 2008 S: 5.8.3.9. invalid-from The JID or hostname provided in a 'from' address is not a valid JID or does not match an authorized JID or validated domain as negotiated between servers via SASL or server dialback, or as negotiated between a client and a server via authentication and resource binding. (In the following example, a peer that has authenticated only as "example.net" attempts to send a stanza from an address at "example.org".) P: Neither, fair saint, if either thee dislike. S: 5.8.3.10. invalid-id The stream ID or server dialback ID is invalid or does not match an ID previously provided. (In the following example, the server dialback ID is invalid; see [XEP-0220].) P: S: Saint-Andre Expires January 2, 2009 [Page 43] Internet-Draft XMPP Core July 2008 5.8.3.11. invalid-namespace The streams namespace name is something other than "http://etherx.jabber.org/streams" (see Section 12.2) or the default namespace is not supported (e.g., something other than "jabber: client" or "jabber:server"). (In the following example, the client specifies a streams namespace of 'http://wrong.namespace.example.org/'.) C: S: 5.8.3.12. invalid-xml The entity has sent invalid XML over the stream to a server that performs validation (see Section 12.4). (In the following example, the peer attempts to send an IQ stanza of type "subscribe" but the XML schema defines no such value for the 'type' attribute.) Saint-Andre Expires January 2, 2009 [Page 44] Internet-Draft XMPP Core July 2008 P: S: 5.8.3.13. not-authorized The entity has attempted to send XML stanzas before the stream has been authenticated, or otherwise is not authorized to perform an action related to stream negotiation; the receiving entity MUST NOT process the offending stanza before sending the stream error. (In the following example, the client attempts to send XML stanzas before authenticating with the server.) Saint-Andre Expires January 2, 2009 [Page 45] Internet-Draft XMPP Core July 2008 C: S: Wherefore art thou? S: 5.8.3.14. policy-violation The entity has violated some local service policy (e.g., the stanza exceeds a configured size limit); the server MAY choose to specify the policy in the element or in an application-specific condition element. (In the following example, the client sends an XMPP message that is too large according to the server's local service policy.) C: [ ... the-emacs-manual ... ] S: S: Saint-Andre Expires January 2, 2009 [Page 46] Internet-Draft XMPP Core July 2008 5.8.3.15. remote-connection-failed The server is unable to properly connect to a remote entity that is required for authentication or authorization, such as a remote authentication database or (in server dialback) the authoritative server. C: S: 5.8.3.16. resource-constraint The server lacks the system resources necessary to service the stream. Saint-Andre Expires January 2, 2009 [Page 47] Internet-Draft XMPP Core July 2008 C: S: 5.8.3.17. restricted-xml The entity has attempted to send restricted XML features such as a comment, processing instruction, DTD subset, or XML entity reference (see Section 12.1). (In the following example, the client sends an XMPP message containing an XML comment.) C: This message has no subject. S: 5.8.3.18. see-other-host The server will not provide service to the initiating entity but is redirecting traffic to another host; the XML character data of the element returned by the server SHOULD specify the Saint-Andre Expires January 2, 2009 [Page 48] Internet-Draft XMPP Core July 2008 alternate hostname or IP address at which to connect, which SHOULD be a valid domain identifier but may also include a port number; if no port is specified, the initiating entity SHOULD perform a [DNS-SRV] lookup on the provided domain identifier but MAY assume that it can connect to that domain identifier at the standard XMPP ports (i.e., 5222 for client-to-server connections and 5269 for server-to-server connections). C: S: im.example.com:9090 5.8.3.19. system-shutdown The server is being shut down and all active streams are being closed. S: Saint-Andre Expires January 2, 2009 [Page 49] Internet-Draft XMPP Core July 2008 5.8.3.20. undefined-condition The error condition is not one of those defined by the other conditions in this list; this error condition SHOULD be used only in conjunction with an application-specific condition. S: 5.8.3.21. unsupported-encoding The initiating entity has encoded the stream in an encoding that is not supported by the server (see Section 12.6) or has otherwise improperly encoded the stream (e.g., by violating the rules of the UTF-8 encoding). (In the following example, the client attempts to encode data using UTF-16 instead of UTF-8.) C: S: Saint-Andre Expires January 2, 2009 [Page 50] Internet-Draft XMPP Core July 2008 5.8.3.22. unsupported-stanza-type The initiating entity has sent a first-level child of the stream that is not supported by the server or consistent with the default namespace. (In the following example, the client attempts to send an XML stanza of when the default namespace is "jabber:client".) C: Soliloquy To be, or not to be: that is the question: Whether 'tis nobler in the mind to suffer The slings and arrows of outrageous fortune, Or to take arms against a sea of troubles, And by opposing end them? tag:denmark.lit,2003:entry-32397 2003-12-13T18:30:02Z 2003-12-13T18:30:02Z S: 5.8.3.23. unsupported-version The value of the 'version' attribute provided by the initiating entity in the stream header specifies a version of XMPP that is not supported by the server; the server MAY specify the version(s) it supports in the element. (In the following example, the client specifies an XMPP version of "11.0" but the server supports only version "1.0" and "1.1".) Saint-Andre Expires January 2, 2009 [Page 51] Internet-Draft XMPP Core July 2008 C: S: 1.0, 1.1 5.8.3.24. xml-not-well-formed The initiating entity has sent XML that violates the well-formedness rules of [XML] or [XML-NAMES]. (In the following example, the client sends an XMPP message that is not well-formed XML.) C: No closing body tag! S: Saint-Andre Expires January 2, 2009 [Page 52] Internet-Draft XMPP Core July 2008 5.8.4. Application-Specific Conditions As noted, an application MAY provide application-specific stream error information by including a properly-namespaced child in the error element. The application-specific element SHOULD supplement or further qualify a defined element. Thus the element will contain two or three child elements. C: My keyboard layout is: QWERTYUIOP{}| ASDFGHJKL:" ZXCVBNM<>? S: Some special application diagnostic information! 5.9. Simplified Stream Examples This section contains two simplified examples of a stream-based connection between a client and a server; these examples are included for the purpose of illustrating the concepts introduced thus far. Saint-Andre Expires January 2, 2009 [Page 53] Internet-Draft XMPP Core July 2008 A basic connection: C: [ ... channel encryption ... ] [ ... authentication ... ] [ ... resource binding ... ] C: Art thou not Romeo, and a Montague? S: Neither, fair saint, if either thee dislike. C: S: Saint-Andre Expires January 2, 2009 [Page 54] Internet-Draft XMPP Core July 2008 A connection gone bad: C: S: [ ... channel encryption ... ] [ ... authentication ... ] [ ... resource binding ... ] C: No closing body tag! S: More detailed examples are provided under Section 10. 6. STARTTLS Negotiation Saint-Andre Expires January 2, 2009 [Page 55] Internet-Draft XMPP Core July 2008 6.1. Overview XMPP includes a method for securing the stream from tampering and eavesdropping. This channel encryption method makes use of the Transport Layer Security [TLS] protocol, specifically a "STARTTLS" extension that is modelled after similar extensions for the [IMAP], [POP3], and [ACAP] protocols as described in [USINGTLS]. The XML namespace name for the STARTTLS extension is 'urn:ietf:params:xml:ns:xmpp-tls'. Support for STARTTLS is REQUIRED in XMPP client and server implementations. An administrator of a given deployment MAY require the use of TLS for client-to-server communication, server-to-server communication, or both. A deployed client SHOULD use TLS to secure its stream with a server prior to attempting the completion of SASL negotiation (Section 7), and deployed servers SHOULD use TLS between two domains for the purpose of securing server-to-server communication. 6.2. Rules 6.2.1. Data Formatting During STARTTLS negotiation, the entities MUST NOT send any whitespace within the root stream element as separators between XML elements (i.e., from the last character of the element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace at depth=1 of the stream as sent by the initiating entity until the last character of the element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace at depth=1 of the stream as sent by the receiving entity). This prohibition helps to ensure proper security layer byte precision. Any such whitespace shown in the STARTTLS examples provided in this document is included only for the sake of readability. 6.2.2. Order of Negotiation If the initiating entity chooses to use TLS, STARTTLS negotiation MUST be completed before proceeding to SASL negotiation (Section 7); this order of negotiation is required to help safeguard authentication information sent during SASL negotiation, as well as to make it possible to base the use of the SASL EXTERNAL mechanism on a certificate (or other credentials) provided during prior TLS negotiation. Saint-Andre Expires January 2, 2009 [Page 56] Internet-Draft XMPP Core July 2008 6.3. Process 6.3.1. Exchange of Stream Headers and Stream Features The initiating entity resolves the hostname of the receiving entity as specified under Section 4, opens a TCP connection to the advertised port at the resolved IP address, and sends an initial stream header to the receiving entity; if the initiating entity is capable of STARTTLS negotiation, it MUST include the 'version' attribute set to a value of at least "1.0" in the initial stream header. I: The receiving entity MUST send a response stream header to the initiating entity over the TCP connection opened by the initiating entity; if the receiving entity is capable of STARTTLS negotiation, it MUST include the 'version' attribute set to a value of at least "1.0" in the response stream header. R: element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace. If the receiving entity considers STARTTLS negotiation to be discretionary, the element MUST contain an empty child element. Saint-Andre Expires January 2, 2009 [Page 57] Internet-Draft XMPP Core July 2008 R: If the receiving entity considers STARTTLS negotiation to be mandatory, the element MUST contain an empty child element. R: 6.3.2. Initiation of STARTTLS Negotiation 6.3.2.1. STARTTLS Command In order to begin the STARTTLS negotiation, the initiating entity issues the STARTTLS command (i.e., a element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace) to instruct the receiving entity that it wishes to begin a STARTTLS negotiation to secure the stream. I: The receiving entity MUST reply with either a element (proceed case) or a element (failure case) qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace. 6.3.2.2. Failure Case If the failure case occurs, the receiving entity MUST return a element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace, terminate the XML stream, and terminate the underlying TCP connection. R: R: Causes for the failure case include but are not limited to: 1. The initiating entity has sent a malformed STARTTLS command. Saint-Andre Expires January 2, 2009 [Page 58] Internet-Draft XMPP Core July 2008 2. The receiving entity does not offer STARTTLS negotiation either temporarily or permanently. 3. The receiving entity cannot complete STARTTLS negotiation because of an internal error. Note: STARTTLS failure is not triggered by TLS errors such as bad certificate or unknown certificate authority; those errors are generated and handled during the TLS negotiation itself as described in [TLS]. If the failure case occurs, the initiating entity MAY attempt to reconnect as explained under Section 4.5. 6.3.2.3. Proceed Case If the proceed case occurs, the receiving entity MUST return a element qualified by the 'urn:ietf:params:xml:ns:xmpp-tls' namespace. R: The receiving entity MUST consider the TLS negotiation to have begun immediately after sending the closing '>' character of the element to the initiating entity. The initiating entity MUST consider the TLS negotiation to have begun immediately after receiving the closing '>' character of the element from the receiving entity. The entities now proceed to TLS negotiation as explained in the next section. 6.3.3. TLS Negotiation 6.3.3.1. Rules In order to complete TLS negotiation over the TCP connection, the entities MUST follow the process defined in [TLS]. The following rules apply: 1. The entities MUST NOT send any further XML data until the TLS negotiation has either failed or succeeded. 2. The receiving entity MUST present a certificate. 3. The receiving entity SHOULD send a certificate request to the initiating entity so that mutual authentication will be possible. 4. The initiating entity MUST validate the certificate to determine if the TLS negotiation shall succeed; see Section 15.2.2 regarding certificate validation procedures. Saint-Andre Expires January 2, 2009 [Page 59] Internet-Draft XMPP Core July 2008 5. The receiving entity SHOULD choose which certificate to present based on the 'to' attribute of the initial stream header. Note: See Section 15.7 regarding ciphers that MUST be supported for TLS; naturally, other ciphers MAY be supported as well. 6.3.3.2. TLS Failure If the TLS negotiation results in failure, the receiving entity MUST terminate the TCP connection. The receiving entity MUST NOT send a closing tag before terminating the TCP connection, since the receiving entity and initiating entity MUST consider the original stream to be replaced upon failure of the TLS negotiation. 6.3.3.3. TLS Success If the TLS negotiation is successful, then the entities MUST proceed as follows. 1. The receiving entity MUST discard any knowledge obtained in an insecure manner from the initiating entity before TLS took effect. 2. The initiating entity MUST discard any knowledge obtained in an insecure manner from the receiving entity before TLS took effect. 3. The initiating entity MUST send a new initial stream header to the receiving entity over the encrypted connection. I: Note: The initiating entity MUST NOT send a closing tag before sending the new initial stream header, since the receiving entity and initiating entity MUST consider the original stream to be replaced upon success of the TLS negotiation. 4. The receiving entity MUST respond with a new response stream header over the encrypted connection. Saint-Andre Expires January 2, 2009 [Page 60] Internet-Draft XMPP Core July 2008 R: EXTERNAL PLAIN 7. SASL Negotiation 7.1. Overview XMPP includes a method for authenticating a stream by means of an XMPP-specific profile of the Simple Authentication and Security Layer protocol (see [SASL]). SASL provides a generalized method for adding authentication support to connection-based protocols, and XMPP uses an XML namespace profile of SASL that conforms to the profiling requirements of [SASL]. Support for SASL negotiation is REQUIRED in XMPP client and server implementations. 7.2. Rules 7.2.1. Mechanism Preferences Any entity that will act as a SASL client or a SASL server MUST maintain an ordered list of its preferred SASL mechanisms according to the client or server, where the list is ordered by the perceived strength of the mechanisms. A server MUST offer and a client MUST try SASL mechanisms in the order of their perceived strength. For example, if the server offers the ordered list "PLAIN DIGEST-MD5 GSSAPI" or "DIGEST-MD5 GSSAPI PLAIN" but the client's ordered list is Saint-Andre Expires January 2, 2009 [Page 61] Internet-Draft XMPP Core July 2008 "GSSAPI DIGEST-MD5", the client shall try GSSAPI first and then DIGEST-MD5 but shall never try PLAIN (since PLAIN is not on its list). 7.2.2. Mechanism Offers If the receiving entity considers TLS negotiation (Section 6) to be mandatory before use of a particular SASL authentication mechanism will be acceptable, the receiving entity MUST NOT advertise that mechanism in its list of available SASL authentication mechanisms prior to successful TLS negotiation. If during prior TLS negotiation the initiating entity presented a certificate that is acceptable to the receiving entity for purposes of strong ident