RFC 6120
Extensible Messaging and Presence Protocol (XMPP): Core
Pages: 211
Proposed Standard
→ Errata
Obsoletes: 3920
Updated by: 7590 8553
Proposed Standard
→ Errata
Obsoletes: 3920
Updated by: 7590 8553
Part 1 of 9 – Pages 1 to 13
Internet Engineering Task Force (IETF) P. Saint-Andre Request for Comments: 6120 Cisco Obsoletes: 3920 March 2011 Category: Standards Track ISSN: 2070-1721 Extensible Messaging and Presence Protocol (XMPP): CoreAbstract
The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920. Status of This Memo This is an Internet Standards Track document. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741. Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6120. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 8 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8 1.2. History . . . . . . . . . . . . . . . . . . . . . . . . 8 1.3. Functional Summary . . . . . . . . . . . . . . . . . . . 9 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . 11 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 13 2.1. Global Addresses . . . . . . . . . . . . . . . . . . . . 13 2.2. Presence . . . . . . . . . . . . . . . . . . . . . . . . 14 2.3. Persistent Streams . . . . . . . . . . . . . . . . . . . 14 2.4. Structured Data . . . . . . . . . . . . . . . . . . . . 14 2.5. Distributed Network of Clients and Servers . . . . . . . 14 3. TCP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.2. Resolution of Fully Qualified Domain Names . . . . . . . 17 3.2.1. Preferred Process: SRV Lookup . . . . . . . . . . . 17 3.2.2. Fallback Processes . . . . . . . . . . . . . . . . . 18 3.2.3. When Not to Use SRV . . . . . . . . . . . . . . . . 18 3.2.4. Use of SRV Records with Add-On Services . . . . . . 19 3.3. Reconnection . . . . . . . . . . . . . . . . . . . . . . 19 3.4. Reliability . . . . . . . . . . . . . . . . . . . . . . 20 4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.1. Stream Fundamentals . . . . . . . . . . . . . . . . . . 20 4.2. Opening a Stream . . . . . . . . . . . . . . . . . . . . 23 4.3. Stream Negotiation . . . . . . . . . . . . . . . . . . . 24 4.3.1. Basic Concepts . . . . . . . . . . . . . . . . . . . 24 4.3.2. Stream Features Format . . . . . . . . . . . . . . . 25 4.3.3. Restarts . . . . . . . . . . . . . . . . . . . . . . 27 4.3.4. Resending Features . . . . . . . . . . . . . . . . . 27 4.3.5. Completion of Stream Negotiation . . . . . . . . . . 27 4.3.6. Determination of Addresses . . . . . . . . . . . . . 28 4.3.7. Flow Chart . . . . . . . . . . . . . . . . . . . . . 29 4.4. Closing a Stream . . . . . . . . . . . . . . . . . . . . 31 4.5. Directionality . . . . . . . . . . . . . . . . . . . . . 32 4.6. Handling of Silent Peers . . . . . . . . . . . . . . . . 33 4.6.1. Dead Connection . . . . . . . . . . . . . . . . . . 34 4.6.2. Broken Stream . . . . . . . . . . . . . . . . . . . 34 4.6.3. Idle Peer . . . . . . . . . . . . . . . . . . . . . 34 4.6.4. Use of Checking Methods . . . . . . . . . . . . . . 35 4.7. Stream Attributes . . . . . . . . . . . . . . . . . . . 35 4.7.1. from . . . . . . . . . . . . . . . . . . . . . . . . 35 4.7.2. to . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.7.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 38 4.7.4. xml:lang . . . . . . . . . . . . . . . . . . . . . . 39 4.7.5. version . . . . . . . . . . . . . . . . . . . . . . 41 4.7.6. Summary of Stream Attributes . . . . . . . . . . . . 43 4.8. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 43
4.8.1. Stream Namespace . . . . . . . . . . . . . . . . . . 43
4.8.2. Content Namespace . . . . . . . . . . . . . . . . . 43
4.8.3. XMPP Content Namespaces . . . . . . . . . . . . . . 44
4.8.4. Other Namespaces . . . . . . . . . . . . . . . . . . 46
4.8.5. Namespace Declarations and Prefixes . . . . . . . . 47
4.9. Stream Errors . . . . . . . . . . . . . . . . . . . . . 48
4.9.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 48
4.9.1.1. Stream Errors Are Unrecoverable . . . . . . . . . 48
4.9.1.2. Stream Errors Can Occur During Setup . . . . . . 49
4.9.1.3. Stream Errors When the Host Is Unspecified or
Unknown . . . . . . . . . . . . . . . . . . . . . 50
4.9.1.4. Where Stream Errors Are Sent . . . . . . . . . . 50
4.9.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 51
4.9.3. Defined Stream Error Conditions . . . . . . . . . . 52
4.9.3.1. bad-format . . . . . . . . . . . . . . . . . . . 52
4.9.3.2. bad-namespace-prefix . . . . . . . . . . . . . . 52
4.9.3.3. conflict . . . . . . . . . . . . . . . . . . . . 53
4.9.3.4. connection-timeout . . . . . . . . . . . . . . . 54
4.9.3.5. host-gone . . . . . . . . . . . . . . . . . . . . 54
4.9.3.6. host-unknown . . . . . . . . . . . . . . . . . . 55
4.9.3.7. improper-addressing . . . . . . . . . . . . . . . 56
4.9.3.8. internal-server-error . . . . . . . . . . . . . . 56
4.9.3.9. invalid-from . . . . . . . . . . . . . . . . . . 56
4.9.3.10. invalid-namespace . . . . . . . . . . . . . . . . 57
4.9.3.11. invalid-xml . . . . . . . . . . . . . . . . . . . 57
4.9.3.12. not-authorized . . . . . . . . . . . . . . . . . 58
4.9.3.13. not-well-formed . . . . . . . . . . . . . . . . . 59
4.9.3.14. policy-violation . . . . . . . . . . . . . . . . 59
4.9.3.15. remote-connection-failed . . . . . . . . . . . . 60
4.9.3.16. reset . . . . . . . . . . . . . . . . . . . . . . 60
4.9.3.17. resource-constraint . . . . . . . . . . . . . . . 61
4.9.3.18. restricted-xml . . . . . . . . . . . . . . . . . 61
4.9.3.19. see-other-host . . . . . . . . . . . . . . . . . 62
4.9.3.20. system-shutdown . . . . . . . . . . . . . . . . . 64
4.9.3.21. undefined-condition . . . . . . . . . . . . . . . 64
4.9.3.22. unsupported-encoding . . . . . . . . . . . . . . 64
4.9.3.23. unsupported-feature . . . . . . . . . . . . . . . 65
4.9.3.24. unsupported-stanza-type . . . . . . . . . . . . . 65
4.9.3.25. unsupported-version . . . . . . . . . . . . . . . 66
4.9.4. Application-Specific Conditions . . . . . . . . . . 67
4.10. Simplified Stream Examples . . . . . . . . . . . . . . . 68
5. STARTTLS Negotiation . . . . . . . . . . . . . . . . . . . . 69
5.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 69
5.2. Support . . . . . . . . . . . . . . . . . . . . . . . . 70
5.3. Stream Negotiation Rules . . . . . . . . . . . . . . . . 70
5.3.1. Mandatory-to-Negotiate . . . . . . . . . . . . . . . 70
5.3.2. Restart . . . . . . . . . . . . . . . . . . . . . . 70
5.3.3. Data Formatting . . . . . . . . . . . . . . . . . . 70
5.3.4. Order of TLS and SASL Negotiations . . . . . . . . . 71
5.3.5. TLS Renegotiation . . . . . . . . . . . . . . . . . 71
5.3.6. TLS Extensions . . . . . . . . . . . . . . . . . . . 72
5.4. Process . . . . . . . . . . . . . . . . . . . . . . . . 72
5.4.1. Exchange of Stream Headers and Stream Features . . . 72
5.4.2. Initiation of STARTTLS Negotiation . . . . . . . . . 73
5.4.2.1. STARTTLS Command . . . . . . . . . . . . . . . . 73
5.4.2.2. Failure Case . . . . . . . . . . . . . . . . . . 73
5.4.2.3. Proceed Case . . . . . . . . . . . . . . . . . . 74
5.4.3. TLS Negotiation . . . . . . . . . . . . . . . . . . 74
5.4.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . 74
5.4.3.2. TLS Failure . . . . . . . . . . . . . . . . . . . 75
5.4.3.3. TLS Success . . . . . . . . . . . . . . . . . . . 76
6. SASL Negotiation . . . . . . . . . . . . . . . . . . . . . . 77
6.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 77
6.2. Support . . . . . . . . . . . . . . . . . . . . . . . . 77
6.3. Stream Negotiation Rules . . . . . . . . . . . . . . . . 77
6.3.1. Mandatory-to-Negotiate . . . . . . . . . . . . . . . 77
6.3.2. Restart . . . . . . . . . . . . . . . . . . . . . . 78
6.3.3. Mechanism Preferences . . . . . . . . . . . . . . . 78
6.3.4. Mechanism Offers . . . . . . . . . . . . . . . . . . 78
6.3.5. Data Formatting . . . . . . . . . . . . . . . . . . 79
6.3.6. Security Layers . . . . . . . . . . . . . . . . . . 80
6.3.7. Simple User Name . . . . . . . . . . . . . . . . . . 80
6.3.8. Authorization Identity . . . . . . . . . . . . . . . 80
6.3.9. Realms . . . . . . . . . . . . . . . . . . . . . . . 81
6.3.10. Round Trips . . . . . . . . . . . . . . . . . . . . 81
6.4. Process . . . . . . . . . . . . . . . . . . . . . . . . 82
6.4.1. Exchange of Stream Headers and Stream Features . . . 82
6.4.2. Initiation . . . . . . . . . . . . . . . . . . . . . 83
6.4.3. Challenge-Response Sequence . . . . . . . . . . . . 84
6.4.4. Abort . . . . . . . . . . . . . . . . . . . . . . . 84
6.4.5. SASL Failure . . . . . . . . . . . . . . . . . . . . 85
6.4.6. SASL Success . . . . . . . . . . . . . . . . . . . . 86
6.5. SASL Errors . . . . . . . . . . . . . . . . . . . . . . 87
6.5.1. aborted . . . . . . . . . . . . . . . . . . . . . . 88
6.5.2. account-disabled . . . . . . . . . . . . . . . . . . 88
6.5.3. credentials-expired . . . . . . . . . . . . . . . . 88
6.5.4. encryption-required . . . . . . . . . . . . . . . . 89
6.5.5. incorrect-encoding . . . . . . . . . . . . . . . . . 89
6.5.6. invalid-authzid . . . . . . . . . . . . . . . . . . 89
6.5.7. invalid-mechanism . . . . . . . . . . . . . . . . . 90
6.5.8. malformed-request . . . . . . . . . . . . . . . . . 90
6.5.9. mechanism-too-weak . . . . . . . . . . . . . . . . . 90
6.5.10. not-authorized . . . . . . . . . . . . . . . . . . . 91
6.5.11. temporary-auth-failure . . . . . . . . . . . . . . . 91
6.6. SASL Definition . . . . . . . . . . . . . . . . . . . . 91
7. Resource Binding . . . . . . . . . . . . . . . . . . . . . . 92
7.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 92
7.2. Support . . . . . . . . . . . . . . . . . . . . . . . . 93
7.3. Stream Negotiation Rules . . . . . . . . . . . . . . . . 93
7.3.1. Mandatory-to-Negotiate . . . . . . . . . . . . . . . 93
7.3.2. Restart . . . . . . . . . . . . . . . . . . . . . . 93
7.4. Advertising Support . . . . . . . . . . . . . . . . . . 93
7.5. Generation of Resource Identifiers . . . . . . . . . . . 94
7.6. Server-Generated Resource Identifier . . . . . . . . . . 94
7.6.1. Success Case . . . . . . . . . . . . . . . . . . . . 94
7.6.2. Error Cases . . . . . . . . . . . . . . . . . . . . 95
7.6.2.1. Resource Constraint . . . . . . . . . . . . . . . 95
7.6.2.2. Not Allowed . . . . . . . . . . . . . . . . . . . 96
7.7. Client-Submitted Resource Identifier . . . . . . . . . . 96
7.7.1. Success Case . . . . . . . . . . . . . . . . . . . . 96
7.7.2. Error Cases . . . . . . . . . . . . . . . . . . . . 97
7.7.2.1. Bad Request . . . . . . . . . . . . . . . . . . . 97
7.7.2.2. Conflict . . . . . . . . . . . . . . . . . . . . 97
7.7.3. Retries . . . . . . . . . . . . . . . . . . . . . . 99
8. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 99
8.1. Common Attributes . . . . . . . . . . . . . . . . . . . 100
8.1.1. to . . . . . . . . . . . . . . . . . . . . . . . . . 100
8.1.1.1. Client-to-Server Streams . . . . . . . . . . . . 100
8.1.1.2. Server-to-Server Streams . . . . . . . . . . . . 101
8.1.2. from . . . . . . . . . . . . . . . . . . . . . . . . 101
8.1.2.1. Client-to-Server Streams . . . . . . . . . . . . 101
8.1.2.2. Server-to-Server Streams . . . . . . . . . . . . 102
8.1.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 103
8.1.4. type . . . . . . . . . . . . . . . . . . . . . . . . 103
8.1.5. xml:lang . . . . . . . . . . . . . . . . . . . . . . 103
8.2. Basic Semantics . . . . . . . . . . . . . . . . . . . . 105
8.2.1. Message Semantics . . . . . . . . . . . . . . . . . 105
8.2.2. Presence Semantics . . . . . . . . . . . . . . . . . 105
8.2.3. IQ Semantics . . . . . . . . . . . . . . . . . . . . 105
8.3. Stanza Errors . . . . . . . . . . . . . . . . . . . . . 107
8.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 108
8.3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 109
8.3.3. Defined Conditions . . . . . . . . . . . . . . . . . 110
8.3.3.1. bad-request . . . . . . . . . . . . . . . . . . . 110
8.3.3.2. conflict . . . . . . . . . . . . . . . . . . . . 111
8.3.3.3. feature-not-implemented . . . . . . . . . . . . . 111
8.3.3.4. forbidden . . . . . . . . . . . . . . . . . . . . 112
8.3.3.5. gone . . . . . . . . . . . . . . . . . . . . . . 113
8.3.3.6. internal-server-error . . . . . . . . . . . . . . 113
8.3.3.7. item-not-found . . . . . . . . . . . . . . . . . 114
8.3.3.8. jid-malformed . . . . . . . . . . . . . . . . . . 114
8.3.3.9. not-acceptable . . . . . . . . . . . . . . . . . 115
8.3.3.10. not-allowed . . . . . . . . . . . . . . . . . . . 116
8.3.3.11. not-authorized . . . . . . . . . . . . . . . . . 116
8.3.3.12. policy-violation . . . . . . . . . . . . . . . . 117
8.3.3.13. recipient-unavailable . . . . . . . . . . . . . . 117
8.3.3.14. redirect . . . . . . . . . . . . . . . . . . . . 118
8.3.3.15. registration-required . . . . . . . . . . . . . . 119
8.3.3.16. remote-server-not-found . . . . . . . . . . . . . 119
8.3.3.17. remote-server-timeout . . . . . . . . . . . . . . 120
8.3.3.18. resource-constraint . . . . . . . . . . . . . . . 121
8.3.3.19. service-unavailable . . . . . . . . . . . . . . . 121
8.3.3.20. subscription-required . . . . . . . . . . . . . . 122
8.3.3.21. undefined-condition . . . . . . . . . . . . . . . 123
8.3.3.22. unexpected-request . . . . . . . . . . . . . . . 123
8.3.4. Application-Specific Conditions . . . . . . . . . . 124
8.4. Extended Content . . . . . . . . . . . . . . . . . . . . 125
9. Detailed Examples . . . . . . . . . . . . . . . . . . . . . . 128
9.1. Client-to-Server Examples . . . . . . . . . . . . . . . 128
9.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 128
9.1.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 130
9.1.3. Resource Binding . . . . . . . . . . . . . . . . . . 132
9.1.4. Stanza Exchange . . . . . . . . . . . . . . . . . . 133
9.1.5. Close . . . . . . . . . . . . . . . . . . . . . . . 134
9.2. Server-to-Server Examples . . . . . . . . . . . . . . . 134
9.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 134
9.2.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 136
9.2.3. Stanza Exchange . . . . . . . . . . . . . . . . . . 137
9.2.4. Close . . . . . . . . . . . . . . . . . . . . . . . 137
10. Server Rules for Processing XML Stanzas . . . . . . . . . . . 138
10.1. In-Order Processing . . . . . . . . . . . . . . . . . . 138
10.2. General Considerations . . . . . . . . . . . . . . . . . 140
10.3. No 'to' Address . . . . . . . . . . . . . . . . . . . . 141
10.3.1. Message . . . . . . . . . . . . . . . . . . . . . . 141
10.3.2. Presence . . . . . . . . . . . . . . . . . . . . . . 141
10.3.3. IQ . . . . . . . . . . . . . . . . . . . . . . . . . 141
10.4. Remote Domain . . . . . . . . . . . . . . . . . . . . . 142
10.4.1. Existing Stream . . . . . . . . . . . . . . . . . . 142
10.4.2. No Existing Stream . . . . . . . . . . . . . . . . . 142
10.4.3. Error Handling . . . . . . . . . . . . . . . . . . . 143
10.5. Local Domain . . . . . . . . . . . . . . . . . . . . . . 143
10.5.1. domainpart . . . . . . . . . . . . . . . . . . . . . 143
10.5.2. domainpart/resourcepart . . . . . . . . . . . . . . 143
10.5.3. localpart@domainpart . . . . . . . . . . . . . . . . 143
10.5.3.1. No Such User . . . . . . . . . . . . . . . . . . 144
10.5.3.2. User Exists . . . . . . . . . . . . . . . . . . . 144
10.5.4. localpart@domainpart/resourcepart . . . . . . . . . 144
11. XML Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 145
11.1. XML Restrictions . . . . . . . . . . . . . . . . . . . . 145
11.2. XML Namespace Names and Prefixes . . . . . . . . . . . . 146
11.3. Well-Formedness . . . . . . . . . . . . . . . . . . . . 146
11.4. Validation . . . . . . . . . . . . . . . . . . . . . . . 147
11.5. Inclusion of XML Declaration . . . . . . . . . . . . . . 147
11.6. Character Encoding . . . . . . . . . . . . . . . . . . . 147
11.7. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 148
11.8. XML Versions . . . . . . . . . . . . . . . . . . . . . . 148
12. Internationalization Considerations . . . . . . . . . . . . . 148
13. Security Considerations . . . . . . . . . . . . . . . . . . . 148
13.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 148
13.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 149
13.3. Order of Layers . . . . . . . . . . . . . . . . . . . . 150
13.4. Confidentiality and Integrity . . . . . . . . . . . . . 150
13.5. Peer Entity Authentication . . . . . . . . . . . . . . . 151
13.6. Strong Security . . . . . . . . . . . . . . . . . . . . 151
13.7. Certificates . . . . . . . . . . . . . . . . . . . . . . 152
13.7.1. Certificate Generation . . . . . . . . . . . . . . . 152
13.7.1.1. General Considerations . . . . . . . . . . . . . 152
13.7.1.2. Server Certificates . . . . . . . . . . . . . . . 153
13.7.1.3. Client Certificates . . . . . . . . . . . . . . . 156
13.7.1.4. XmppAddr Identifier Type . . . . . . . . . . . . 156
13.7.2. Certificate Validation . . . . . . . . . . . . . . . 157
13.7.2.1. Server Certificates . . . . . . . . . . . . . . . 158
13.7.2.2. Client Certificates . . . . . . . . . . . . . . . 158
13.7.2.3. Checking of Certificates in Long-Lived Streams . 160
13.7.2.4. Use of Certificates in XMPP Extensions . . . . . 160
13.8. Mandatory-to-Implement TLS and SASL Technologies . . . . 160
13.8.1. For Authentication Only . . . . . . . . . . . . . . 161
13.8.2. For Confidentiality Only . . . . . . . . . . . . . . 161
13.8.3. For Confidentiality and Authentication with
Passwords . . . . . . . . . . . . . . . . . . . . . 162
13.8.4. For Confidentiality and Authentication without
Passwords . . . . . . . . . . . . . . . . . . . . . 163
13.9. Technology Reuse . . . . . . . . . . . . . . . . . . . . 163
13.9.1. Use of Base 64 in SASL . . . . . . . . . . . . . . . 163
13.9.2. Use of DNS . . . . . . . . . . . . . . . . . . . . . 163
13.9.3. Use of Hash Functions . . . . . . . . . . . . . . . 164
13.9.4. Use of SASL . . . . . . . . . . . . . . . . . . . . 164
13.9.5. Use of TLS . . . . . . . . . . . . . . . . . . . . . 165
13.9.6. Use of UTF-8 . . . . . . . . . . . . . . . . . . . . 165
13.9.7. Use of XML . . . . . . . . . . . . . . . . . . . . . 166
13.10. Information Leaks . . . . . . . . . . . . . . . . . . . 166
13.10.1. IP Addresses . . . . . . . . . . . . . . . . . . . . 166
13.10.2. Presence Information . . . . . . . . . . . . . . . . 166
13.11. Directory Harvesting . . . . . . . . . . . . . . . . . . 166
13.12. Denial of Service . . . . . . . . . . . . . . . . . . . 167
13.13. Firewalls . . . . . . . . . . . . . . . . . . . . . . . 169
13.14. Interdomain Federation . . . . . . . . . . . . . . . . . 169
13.15. Non-Repudiation . . . . . . . . . . . . . . . . . . . . 169
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 170
14.1. XML Namespace Name for TLS Data . . . . . . . . . . . . 170
14.2. XML Namespace Name for SASL Data . . . . . . . . . . . . 170
14.3. XML Namespace Name for Stream Errors . . . . . . . . . . 170
14.4. XML Namespace Name for Resource Binding . . . . . . . . 171
14.5. XML Namespace Name for Stanza Errors . . . . . . . . . . 171
14.6. GSSAPI Service Name . . . . . . . . . . . . . . . . . . 171
14.7. Port Numbers and Service Names . . . . . . . . . . . . . 171
15. Conformance Requirements . . . . . . . . . . . . . . . . . . 172
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 181
16.1. Normative References . . . . . . . . . . . . . . . . . . 181
16.2. Informative References . . . . . . . . . . . . . . . . . 184
Appendix A. XML Schemas . . . . . . . . . . . . . . . . . . . . 190
A.1. Stream Namespace . . . . . . . . . . . . . . . . . . . . 190
A.2. Stream Error Namespace . . . . . . . . . . . . . . . . . 192
A.3. STARTTLS Namespace . . . . . . . . . . . . . . . . . . . 193
A.4. SASL Namespace . . . . . . . . . . . . . . . . . . . . . 194
A.5. Client Namespace . . . . . . . . . . . . . . . . . . . . 196
A.6. Server Namespace . . . . . . . . . . . . . . . . . . . . 201
A.7. Resource Binding Namespace . . . . . . . . . . . . . . . 206
A.8. Stanza Error Namespace . . . . . . . . . . . . . . . . . 206
Appendix B. Contact Addresses . . . . . . . . . . . . . . . . . 208
Appendix C. Account Provisioning . . . . . . . . . . . . . . . . 208
Appendix D. Differences from RFC 3920 . . . . . . . . . . . . . 208
Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 210
1. Introduction
1.1. Overview
The Extensible Messaging and Presence Protocol (XMPP) is an
application profile of the Extensible Markup Language [XML] that
enables the near-real-time exchange of structured yet extensible data
between any two or more network entities. This document defines
XMPP's core protocol methods: setup and teardown of XML streams,
channel encryption, authentication, error handling, and communication
primitives for messaging, network availability ("presence"), and
request-response interactions.
1.2. History
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 base Jabber protocol that would be suitable as an
IETF instant messaging (IM) and presence technology in accordance
with [IMP-REQS]. In October 2004, [RFC3920] and [RFC3921] were
published, representing the most complete definition of XMPP at that
time.
Since 2004 the Internet community has gained extensive implementation and deployment experience with XMPP, including formal interoperability testing carried out under the auspices of the XMPP Standards Foundation (XSF). This document incorporates comprehensive feedback from software developers and XMPP service providers, including a number of backward-compatible modifications summarized under Appendix D. As a result, this document reflects the rough consensus of the Internet community regarding the core features of XMPP 1.0, thus obsoleting RFC 3920.1.3. 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 typically implemented using a distributed client-server architecture, wherein a client needs to connect to a server in order to gain access to the network and thus be allowed to exchange XML stanzas with other entities (which can 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 IP address and port at which to connect, typically based on resolution of a fully qualified domain name (Section 3.2) 2. Open a Transmission Control Protocol [TCP] connection 3. Open an XML stream over TCP (Section 4.2) 4. Preferably negotiate Transport Layer Security [TLS] for channel encryption (Section 5) 5. Authenticate using a Simple Authentication and Security Layer [SASL] mechanism (Section 6) 6. Bind a resource to the stream (Section 7) 7. Exchange an unbounded number of XML stanzas with other entities on the network (Section 8) 8. Close the XML stream (Section 4.4) 9. Close the TCP connection
Within XMPP, one server can optionally connect to another server to
enable inter-domain or inter-server communication. For this to
happen, the two servers need to negotiate a connection between
themselves and then exchange XML stanzas; the process for doing so
is:
1. Determine the IP address and port at which to connect, typically
based on resolution of a fully qualified domain name
(Section 3.2)
2. Open a TCP connection
3. Open an XML stream (Section 4.2)
4. Preferably negotiate TLS for channel encryption (Section 5)
5. Authenticate using a Simple Authentication and Security Layer
[SASL] mechanism (Section 6) *
6. Exchange an unbounded number of XML stanzas both directly for the
servers and indirectly on behalf of entities associated with each
server, such as connected clients (Section 8)
7. Close the XML stream (Section 4.4)
8. Close the TCP connection
* Interoperability Note: At the time of writing, most deployed
servers still use the Server Dialback protocol [XEP-0220] to
provide weak identity verification instead of using SASL with PKIX
certificates to provide strong authentication, especially in cases
where SASL negotiation would not result in strong authentication
anyway (e.g., because TLS negotiation was not mandated by the peer
server, or because the PKIX certificate presented by the peer
server during TLS negotiation is self-signed and has not been
previously accepted); for details, see [XEP-0220]. The solutions
specified in this document offer a significantly stronger level of
security (see also Section 13.6).
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 applications.
1.4. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS]. Certain security-related terms are to be understood in the sense defined in [SEC-TERMS]; such terms include, but are not limited to, "assurance", "attack", "authentication", "authorization", "certificate", "certification authority", "certification path", "confidentiality", "credential", "downgrade", "encryption", "hash value", "identity", "integrity", "signature", "self-signed certificate", "sign", "spoof", "tamper", "trust", "trust anchor", "validate", and "verify". Certain terms related to certificates, domains, and application service identity are to be understood in the sense defined in [TLS-CERTS]; these include, but are not limited to, "PKIX certificate", "source domain", "derived domain", and the identifier types "CN-ID", "DNS-ID", and "SRV-ID". Other security-related terms are to be understood in the sense defined in the referenced specifications (for example, "denial of service" as described in [DOS] or "end entity certificate" as described in [PKIX]). The term "whitespace" is used to refer to any character or characters matching the "S" production from [XML], i.e., one or more instances of the SP, HTAB, CR, or LF rules defined in [ABNF]. The terms "localpart", "domainpart", and "resourcepart" are defined in [XMPP-ADDR]. The term "bare JID" refers to an XMPP address of the form <localpart@domainpart> (for an account at a server) or of the form <domainpart> (for a server). The term "full JID" refers to an XMPP address of the form <localpart@domainpart/resourcepart> (for a particular authorized client or device associated with an account) or of the form <domainpart/resourcepart> (for a particular resource or script associated with a server). The term "XML stream" (also "stream") is defined under Section 4.1.
The term "XML stanza" (also "stanza") is defined under Section 4.1. There are three kinds of stanzas: message, presence, and IQ (short for "Info/Query"). These communication primitives are defined under Sections 8.2.1, 8.2.2, and 8.2.3, respectively. The term "originating entity" refers to the entity that first generates a stanza that is sent over an XMPP network (e.g., a connected client, an add-on service, or a server). The term "generated stanza" refers to the stanza so generated. The term "input stream" designates an XML stream over which a server receives data from a connected client or remote server, and the term "output stream" designates an XML stream over which a server sends data to a connected client or remote server. The following terms designate some of the actions that a server can perform when processing data received over an input stream: route: pass the data to a remote server for direct processing by the remote server or eventual delivery to a client associated with the remote server deliver: pass the data to a connected client ignore: discard the data without acting upon it or returning an error to the sender When the term "ignore" is used with regard to client processing of data it receives, the phrase "without acting upon it" explicitly includes not presenting the data to a human user. 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); this form is definitely not to be sent over the wire in XMPP systems. Consistent with the convention used in [URI] to represent Uniform Resource Identifiers, XMPP addresses in running text are enclosed between '<' and '>' (although natively they are not URIs). 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 o S1: = server1 o S2: = server2 Readers need to be aware that the examples are not exhaustive and that, in examples for some protocol flows, the alternate steps shown would not necessarily be triggered by the exact data sent in the previous step; in all cases the protocol definitions specified in this document or in normatively referenced documents rule over any examples provided here. All examples are fictional and the information exchanged (e.g., usernames and passwords) does not represent any existing users or servers.
(page 13 continued on part 2)