draft-ietf-xmpp-3920bis-19.txt   draft-ietf-xmpp-3920bis-20.txt 
XMPP P. Saint-Andre XMPP P. Saint-Andre
Internet-Draft Cisco Internet-Draft Cisco
Obsoletes: 3920 (if approved) November 17, 2010 Obsoletes: 3920 (if approved) December 6, 2010
Intended status: Standards Track Intended status: Standards Track
Expires: May 21, 2011 Expires: June 9, 2011
Extensible Messaging and Presence Protocol (XMPP): Core Extensible Messaging and Presence Protocol (XMPP): Core
draft-ietf-xmpp-3920bis-19 draft-ietf-xmpp-3920bis-20
Abstract Abstract
The Extensible Messaging and Presence Protocol (XMPP) is an The Extensible Messaging and Presence Protocol (XMPP) is an
application profile of the Extensible Markup Language (XML) that application profile of the Extensible Markup Language (XML) that
enables the near-real-time exchange of structured yet extensible data enables the near-real-time exchange of structured yet extensible data
between any two or more network entities. This document defines between any two or more network entities. This document defines
XMPP's core protocol methods: setup and teardown of XML streams, XMPP's core protocol methods: setup and teardown of XML streams,
channel encryption, authentication, error handling, and communication channel encryption, authentication, error handling, and communication
primitives for messaging, network availability ("presence"), and primitives for messaging, network availability ("presence"), and
request-response interactions. request-response interactions. This document obsoletes RFC 3920.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 21, 2011. This Internet-Draft will expire on June 9, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 16 skipping to change at page 2, line 16
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2. History . . . . . . . . . . . . . . . . . . . . . . . . 9 1.2. History . . . . . . . . . . . . . . . . . . . . . . . . 9
1.3. Functional Summary . . . . . . . . . . . . . . . . . . . 9 1.3. Functional Summary . . . . . . . . . . . . . . . . . . . 9
1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . 11 1.4. Terminology . . . . . . . . . . . . . . . . . . . . . . 11
1.5. Acknowledgements . . . . . . . . . . . . . . . . . . . . 13
1.6. Discussion Venue . . . . . . . . . . . . . . . . . . . . 13
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 13 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 13
2.1. Global Addresses . . . . . . . . . . . . . . . . . . . . 14 2.1. Global Addresses . . . . . . . . . . . . . . . . . . . . 13
2.2. Presence . . . . . . . . . . . . . . . . . . . . . . . . 14 2.2. Presence . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3. Persistent Streams . . . . . . . . . . . . . . . . . . . 14 2.3. Persistent Streams . . . . . . . . . . . . . . . . . . . 14
2.4. Structured Data . . . . . . . . . . . . . . . . . . . . 14 2.4. Structured Data . . . . . . . . . . . . . . . . . . . . 14
2.5. Distributed Network of Clients and Servers . . . . . . . 15 2.5. Distributed Network of Clients and Servers . . . . . . . 15
3. TCP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 16 3. TCP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Hostname Resolution . . . . . . . . . . . . . . . . . . 17 3.2. Resolution of Fully Qualified Domain Names . . . . . . . 17
3.2.1. Preferred Process: SRV Lookup . . . . . . . . . . . 17 3.2.1. Preferred Process: SRV Lookup . . . . . . . . . . . 17
3.2.2. Fallback Processes . . . . . . . . . . . . . . . . . 18 3.2.2. Fallback Processes . . . . . . . . . . . . . . . . . 18
3.2.3. When Not to Use SRV . . . . . . . . . . . . . . . . 18 3.2.3. When Not to Use SRV . . . . . . . . . . . . . . . . 18
3.2.4. Use of SRV Records with Add-On Services . . . . . . 18 3.2.4. Use of SRV Records with Add-On Services . . . . . . 18
3.3. Reconnection . . . . . . . . . . . . . . . . . . . . . . 19 3.3. Reconnection . . . . . . . . . . . . . . . . . . . . . . 19
3.4. Reliability . . . . . . . . . . . . . . . . . . . . . . 19 3.4. Reliability . . . . . . . . . . . . . . . . . . . . . . 19
4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . . 20 4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.1. Stream Fundamentals . . . . . . . . . . . . . . . . . . 20 4.1. Stream Fundamentals . . . . . . . . . . . . . . . . . . 20
4.2. Stream Negotiation . . . . . . . . . . . . . . . . . . . 23 4.2. Opening a Stream . . . . . . . . . . . . . . . . . . . . 23
4.2.1. Basic Concepts . . . . . . . . . . . . . . . . . . . 23 4.3. Stream Negotiation . . . . . . . . . . . . . . . . . . . 24
4.2.2. Stream Features Format . . . . . . . . . . . . . . . 24 4.3.1. Basic Concepts . . . . . . . . . . . . . . . . . . . 24
4.2.3. Restarts . . . . . . . . . . . . . . . . . . . . . . 26 4.3.2. Stream Features Format . . . . . . . . . . . . . . . 24
4.2.4. Resending Features . . . . . . . . . . . . . . . . . 26 4.3.3. Restarts . . . . . . . . . . . . . . . . . . . . . . 27
4.2.5. Completion of Stream Negotiation . . . . . . . . . . 26 4.3.4. Resending Features . . . . . . . . . . . . . . . . . 27
4.2.6. Determination of Addresses . . . . . . . . . . . . . 27 4.3.5. Completion of Stream Negotiation . . . . . . . . . . 27
4.2.7. Flow Chart . . . . . . . . . . . . . . . . . . . . . 28 4.3.6. Determination of Addresses . . . . . . . . . . . . . 28
4.3. Directionality . . . . . . . . . . . . . . . . . . . . . 30 4.3.7. Flow Chart . . . . . . . . . . . . . . . . . . . . . 29
4.4. Closing a Stream . . . . . . . . . . . . . . . . . . . . 31 4.4. Closing a Stream . . . . . . . . . . . . . . . . . . . . 31
4.5. Handling of Silent Peers . . . . . . . . . . . . . . . . 32 4.5. Directionality . . . . . . . . . . . . . . . . . . . . . 31
4.5.1. Dead Connection . . . . . . . . . . . . . . . . . . 33 4.6. Handling of Silent Peers . . . . . . . . . . . . . . . . 33
4.5.2. Broken Stream . . . . . . . . . . . . . . . . . . . 33 4.6.1. Dead Connection . . . . . . . . . . . . . . . . . . 34
4.5.3. Idle Peer . . . . . . . . . . . . . . . . . . . . . 33 4.6.2. Broken Stream . . . . . . . . . . . . . . . . . . . 34
4.5.4. Use of Checking Methods . . . . . . . . . . . . . . 34 4.6.3. Idle Peer . . . . . . . . . . . . . . . . . . . . . 34
4.6. Stream Attributes . . . . . . . . . . . . . . . . . . . 34 4.6.4. Use of Checking Methods . . . . . . . . . . . . . . 35
4.6.1. from . . . . . . . . . . . . . . . . . . . . . . . . 34 4.7. Stream Attributes . . . . . . . . . . . . . . . . . . . 35
4.6.2. to . . . . . . . . . . . . . . . . . . . . . . . . . 36 4.7.1. from . . . . . . . . . . . . . . . . . . . . . . . . 35
4.6.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 37 4.7.2. to . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.6.4. xml:lang . . . . . . . . . . . . . . . . . . . . . . 38 4.7.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.6.5. version . . . . . . . . . . . . . . . . . . . . . . 39 4.7.4. xml:lang . . . . . . . . . . . . . . . . . . . . . . 39
4.6.6. Summary of Stream Attributes . . . . . . . . . . . . 41 4.7.5. version . . . . . . . . . . . . . . . . . . . . . . 41
4.7. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 41 4.7.6. Summary of Stream Attributes . . . . . . . . . . . . 42
4.7.1. Stream Namespace . . . . . . . . . . . . . . . . . . 41 4.8. XML Namespaces . . . . . . . . . . . . . . . . . . . . . 42
4.7.2. Content Namespace . . . . . . . . . . . . . . . . . 41 4.8.1. Stream Namespace . . . . . . . . . . . . . . . . . . 42
4.7.3. Other Namespaces . . . . . . . . . . . . . . . . . . 43 4.8.2. Content Namespace . . . . . . . . . . . . . . . . . 43
4.7.4. Namespace Declarations and Prefixes . . . . . . . . 43 4.8.3. XMPP Content Namespaces . . . . . . . . . . . . . . 44
4.7.5. XMPP Content Namespaces . . . . . . . . . . . . . . 44 4.8.4. Other Namespaces . . . . . . . . . . . . . . . . . . 45
4.8. Stream Errors . . . . . . . . . . . . . . . . . . . . . 46 4.8.5. Namespace Declarations and Prefixes . . . . . . . . 46
4.8.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 46 4.9. Stream Errors . . . . . . . . . . . . . . . . . . . . . 47
4.8.1.1. Stream Errors Are Unrecoverable . . . . . . . . . 46 4.9.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 48
4.8.1.2. Stream Errors Can Occur During Setup . . . . . . 46 4.9.1.1. Stream Errors Are Unrecoverable . . . . . . . . . 48
4.8.1.3. Stream Errors When the Host is Unspecified or 4.9.1.2. Stream Errors Can Occur During Setup . . . . . . 48
Unknown . . . . . . . . . . . . . . . . . . . . . 47 4.9.1.3. Stream Errors When the Host is Unspecified or
4.8.1.4. Where Stream Errors Are Sent . . . . . . . . . . 48 Unknown . . . . . . . . . . . . . . . . . . . . . 49
4.8.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 48 4.9.1.4. Where Stream Errors Are Sent . . . . . . . . . . 50
4.8.3. Defined Stream Error Conditions . . . . . . . . . . 49 4.9.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 50
4.8.3.1. bad-format . . . . . . . . . . . . . . . . . . . 49 4.9.3. Defined Stream Error Conditions . . . . . . . . . . 51
4.8.3.2. bad-namespace-prefix . . . . . . . . . . . . . . 50 4.9.3.1. bad-format . . . . . . . . . . . . . . . . . . . 52
4.8.3.3. conflict . . . . . . . . . . . . . . . . . . . . 51 4.9.3.2. bad-namespace-prefix . . . . . . . . . . . . . . 52
4.8.3.4. connection-timeout . . . . . . . . . . . . . . . 51 4.9.3.3. conflict . . . . . . . . . . . . . . . . . . . . 53
4.8.3.5. host-gone . . . . . . . . . . . . . . . . . . . . 52 4.9.3.4. connection-timeout . . . . . . . . . . . . . . . 54
4.8.3.6. host-unknown . . . . . . . . . . . . . . . . . . 53 4.9.3.5. host-gone . . . . . . . . . . . . . . . . . . . . 55
4.8.3.7. improper-addressing . . . . . . . . . . . . . . . 53 4.9.3.6. host-unknown . . . . . . . . . . . . . . . . . . 55
4.8.3.8. internal-server-error . . . . . . . . . . . . . . 54 4.9.3.7. improper-addressing . . . . . . . . . . . . . . . 56
4.8.3.9. invalid-from . . . . . . . . . . . . . . . . . . 54 4.9.3.8. internal-server-error . . . . . . . . . . . . . . 56
4.8.3.10. invalid-namespace . . . . . . . . . . . . . . . . 54 4.9.3.9. invalid-from . . . . . . . . . . . . . . . . . . 57
4.8.3.11. invalid-xml . . . . . . . . . . . . . . . . . . . 55 4.9.3.10. invalid-namespace . . . . . . . . . . . . . . . . 57
4.8.3.12. not-authorized . . . . . . . . . . . . . . . . . 56 4.9.3.11. invalid-xml . . . . . . . . . . . . . . . . . . . 58
4.8.3.13. not-well-formed . . . . . . . . . . . . . . . . . 56 4.9.3.12. not-authorized . . . . . . . . . . . . . . . . . 59
4.8.3.14. policy-violation . . . . . . . . . . . . . . . . 57 4.9.3.13. not-well-formed . . . . . . . . . . . . . . . . . 59
4.8.3.15. remote-connection-failed . . . . . . . . . . . . 57 4.9.3.14. policy-violation . . . . . . . . . . . . . . . . 60
4.8.3.16. reset . . . . . . . . . . . . . . . . . . . . . . 58 4.9.3.15. remote-connection-failed . . . . . . . . . . . . 60
4.8.3.17. resource-constraint . . . . . . . . . . . . . . . 58 4.9.3.16. reset . . . . . . . . . . . . . . . . . . . . . . 61
4.8.3.18. restricted-xml . . . . . . . . . . . . . . . . . 59 4.9.3.17. resource-constraint . . . . . . . . . . . . . . . 61
4.8.3.19. see-other-host . . . . . . . . . . . . . . . . . 59 4.9.3.18. restricted-xml . . . . . . . . . . . . . . . . . 62
4.8.3.20. system-shutdown . . . . . . . . . . . . . . . . . 61 4.9.3.19. see-other-host . . . . . . . . . . . . . . . . . 62
4.8.3.21. undefined-condition . . . . . . . . . . . . . . . 61 4.9.3.20. system-shutdown . . . . . . . . . . . . . . . . . 64
4.8.3.22. unsupported-encoding . . . . . . . . . . . . . . 61 4.9.3.21. undefined-condition . . . . . . . . . . . . . . . 64
4.8.3.23. unsupported-feature . . . . . . . . . . . . . . . 62 4.9.3.22. unsupported-encoding . . . . . . . . . . . . . . 64
4.8.3.24. unsupported-stanza-type . . . . . . . . . . . . . 63 4.9.3.23. unsupported-feature . . . . . . . . . . . . . . . 65
4.8.3.25. unsupported-version . . . . . . . . . . . . . . . 63 4.9.3.24. unsupported-stanza-type . . . . . . . . . . . . . 66
4.8.4. Application-Specific Conditions . . . . . . . . . . 64 4.9.3.25. unsupported-version . . . . . . . . . . . . . . . 66
4.9. Simplified Stream Examples . . . . . . . . . . . . . . . 65 4.9.4. Application-Specific Conditions . . . . . . . . . . 67
4.10. Simplified Stream Examples . . . . . . . . . . . . . . . 68
5. STARTTLS Negotiation . . . . . . . . . . . . . . . . . . . . 70
5.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 70
5.2. Support . . . . . . . . . . . . . . . . . . . . . . . . 71
5.3. Stream Negotiation Rules . . . . . . . . . . . . . . . . 71
5.3.1. Mandatory-to-Negotiate . . . . . . . . . . . . . . . 71
5.3.2. Restart . . . . . . . . . . . . . . . . . . . . . . 71
5.3.3. Data Formatting . . . . . . . . . . . . . . . . . . 71
5.3.4. Order of TLS and SASL Negotiations . . . . . . . . . 71
5.3.5. TLS Renegotiation . . . . . . . . . . . . . . . . . 72
5.3.6. TLS Extensions . . . . . . . . . . . . . . . . . . . 73
5.4. Process . . . . . . . . . . . . . . . . . . . . . . . . 73
5.4.1. Exchange of Stream Headers and Stream Features . . . 73
5.4.2. Initiation of STARTTLS Negotiation . . . . . . . . . 74
5.4.2.1. STARTTLS Command . . . . . . . . . . . . . . . . 74
5.4.2.2. Failure Case . . . . . . . . . . . . . . . . . . 74
5.4.2.3. Proceed Case . . . . . . . . . . . . . . . . . . 75
5.4.3. TLS Negotiation . . . . . . . . . . . . . . . . . . 75
5.4.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . 75
5.4.3.2. TLS Failure . . . . . . . . . . . . . . . . . . . 76
5.4.3.3. TLS Success . . . . . . . . . . . . . . . . . . . 77
6. SASL Negotiation . . . . . . . . . . . . . . . . . . . . . . 78
6.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 78
6.2. Support . . . . . . . . . . . . . . . . . . . . . . . . 78
6.3. Stream Negotiation Rules . . . . . . . . . . . . . . . . 78
6.3.1. Mandatory-to-Negotiate . . . . . . . . . . . . . . . 78
6.3.2. Restart . . . . . . . . . . . . . . . . . . . . . . 78
6.3.3. Mechanism Preferences . . . . . . . . . . . . . . . 78
6.3.4. Mechanism Offers . . . . . . . . . . . . . . . . . . 79
6.3.5. Data Formatting . . . . . . . . . . . . . . . . . . 80
6.3.6. Security Layers . . . . . . . . . . . . . . . . . . 80
6.3.7. Simple User Name . . . . . . . . . . . . . . . . . . 81
6.3.8. Authorization Identity . . . . . . . . . . . . . . . 81
6.3.9. Realms . . . . . . . . . . . . . . . . . . . . . . . 81
6.3.10. Round Trips . . . . . . . . . . . . . . . . . . . . 82
6.4. Process . . . . . . . . . . . . . . . . . . . . . . . . 82
6.4.1. Exchange of Stream Headers and Stream Features . . . 82
6.4.2. Initiation . . . . . . . . . . . . . . . . . . . . . 84
6.4.3. Challenge-Response Sequence . . . . . . . . . . . . 84
6.4.4. Abort . . . . . . . . . . . . . . . . . . . . . . . 85
6.4.5. SASL Failure . . . . . . . . . . . . . . . . . . . . 85
6.4.6. SASL Success . . . . . . . . . . . . . . . . . . . . 86
6.5. SASL Errors . . . . . . . . . . . . . . . . . . . . . . 88
6.5.1. aborted . . . . . . . . . . . . . . . . . . . . . . 88
6.5.2. account-disabled . . . . . . . . . . . . . . . . . . 88
6.5.3. credentials-expired . . . . . . . . . . . . . . . . 89
6.5.4. encryption-required . . . . . . . . . . . . . . . . 89
6.5.5. incorrect-encoding . . . . . . . . . . . . . . . . . 89
6.5.6. invalid-authzid . . . . . . . . . . . . . . . . . . 90
6.5.7. invalid-mechanism . . . . . . . . . . . . . . . . . 90
6.5.8. malformed-request . . . . . . . . . . . . . . . . . 90
6.5.9. mechanism-too-weak . . . . . . . . . . . . . . . . . 91
6.5.10. not-authorized . . . . . . . . . . . . . . . . . . . 91
6.5.11. temporary-auth-failure . . . . . . . . . . . . . . . 91
6.6. SASL Definition . . . . . . . . . . . . . . . . . . . . 92
7. Resource Binding . . . . . . . . . . . . . . . . . . . . . . 93
7.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 93
7.2. Support . . . . . . . . . . . . . . . . . . . . . . . . 93
7.3. Stream Negotiation Rules . . . . . . . . . . . . . . . . 94
7.3.1. Mandatory-to-Negotiate . . . . . . . . . . . . . . . 94
7.3.2. Restart . . . . . . . . . . . . . . . . . . . . . . 94
7.4. Advertising Support . . . . . . . . . . . . . . . . . . 94
7.5. Generation of Resource Identifiers . . . . . . . . . . . 94
7.6. Server-Generated Resource Identifier . . . . . . . . . . 95
7.6.1. Success Case . . . . . . . . . . . . . . . . . . . . 95
7.6.2. Error Cases . . . . . . . . . . . . . . . . . . . . 95
7.6.2.1. Resource Constraint . . . . . . . . . . . . . . . 96
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 . . . . . . . . . . . . . . . . . . . . 98
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 . . . . . . . . . . . . 102
8.1.2.2. Server-to-Server Streams . . . . . . . . . . . . 102
8.1.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 103
8.1.4. type . . . . . . . . . . . . . . . . . . . . . . . . 103
8.1.5. xml:lang . . . . . . . . . . . . . . . . . . . . . . 104
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 . . . . . . . . . . . . . 120
8.3.3.17. remote-server-timeout . . . . . . . . . . . . . . 121
8.3.3.18. resource-constraint . . . . . . . . . . . . . . . 121
8.3.3.19. service-unavailable . . . . . . . . . . . . . . . 122
8.3.3.20. subscription-required . . . . . . . . . . . . . . 123
8.3.3.21. undefined-condition . . . . . . . . . . . . . . . 123
8.3.3.22. unexpected-request . . . . . . . . . . . . . . . 124
8.3.4. Application-Specific Conditions . . . . . . . . . . 125
8.4. Extended Content . . . . . . . . . . . . . . . . . . . . 126
9. Detailed Examples . . . . . . . . . . . . . . . . . . . . . . 129
9.1. Client-to-Server Examples . . . . . . . . . . . . . . . 129
9.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 129
9.1.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 131
9.1.3. Resource Binding . . . . . . . . . . . . . . . . . . 133
9.1.4. Stanza Exchange . . . . . . . . . . . . . . . . . . 134
9.1.5. Close . . . . . . . . . . . . . . . . . . . . . . . 135
9.2. Server-to-Server Examples . . . . . . . . . . . . . . . 135
9.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 135
9.2.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 137
9.2.3. Stanza Exchange . . . . . . . . . . . . . . . . . . 138
9.2.4. Close . . . . . . . . . . . . . . . . . . . . . . . 138
10. Server Rules for Processing XML Stanzas . . . . . . . . . . . 139
10.1. In-Order Processing . . . . . . . . . . . . . . . . . . 139
10.2. General Considerations . . . . . . . . . . . . . . . . . 140
10.3. No 'to' Address . . . . . . . . . . . . . . . . . . . . 141
10.3.1. Message . . . . . . . . . . . . . . . . . . . . . . 142
10.3.2. Presence . . . . . . . . . . . . . . . . . . . . . . 142
10.3.3. IQ . . . . . . . . . . . . . . . . . . . . . . . . . 142
10.4. Remote Domain . . . . . . . . . . . . . . . . . . . . . 143
10.4.1. Existing Stream . . . . . . . . . . . . . . . . . . 143
10.4.2. No Existing Stream . . . . . . . . . . . . . . . . . 143
10.4.3. Error Handling . . . . . . . . . . . . . . . . . . . 143
10.5. Local Domain . . . . . . . . . . . . . . . . . . . . . . 144
10.5.1. domainpart . . . . . . . . . . . . . . . . . . . . . 144
10.5.2. domainpart/resourcepart . . . . . . . . . . . . . . 144
10.5.3. localpart@domainpart . . . . . . . . . . . . . . . . 144
10.5.3.1. No Such User . . . . . . . . . . . . . . . . . . 144
10.5.3.2. User Exists . . . . . . . . . . . . . . . . . . . 145
5. STARTTLS Negotiation . . . . . . . . . . . . . . . . . . . . 67 10.5.4. localpart@domainpart/resourcepart . . . . . . . . . 145
5.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 68 11. XML Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 145
5.2. Support . . . . . . . . . . . . . . . . . . . . . . . . 68 11.1. XML Restrictions . . . . . . . . . . . . . . . . . . . . 146
5.3. Stream Negotiation Rules . . . . . . . . . . . . . . . . 68 11.2. XML Namespace Names and Prefixes . . . . . . . . . . . . 146
5.3.1. Mandatory-to-Negotiate . . . . . . . . . . . . . . . 68 11.3. Well-Formedness . . . . . . . . . . . . . . . . . . . . 147
5.3.2. Restart . . . . . . . . . . . . . . . . . . . . . . 68 11.4. Validation . . . . . . . . . . . . . . . . . . . . . . . 147
5.3.3. Data Formatting . . . . . . . . . . . . . . . . . . 68 11.5. Inclusion of XML Declaration . . . . . . . . . . . . . . 148
5.3.4. Order of TLS and SASL Negotiations . . . . . . . . . 69 11.6. Character Encoding . . . . . . . . . . . . . . . . . . . 148
5.3.5. TLS Renegotiation . . . . . . . . . . . . . . . . . 69 11.7. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 148
5.3.6. TLS Extensions . . . . . . . . . . . . . . . . . . . 70 11.8. XML Versions . . . . . . . . . . . . . . . . . . . . . . 149
5.4. Process . . . . . . . . . . . . . . . . . . . . . . . . 70 12. Internationalization Considerations . . . . . . . . . . . . . 149
5.4.1. Exchange of Stream Headers and Stream Features . . . 70 13. Security Considerations . . . . . . . . . . . . . . . . . . . 149
5.4.2. Initiation of STARTTLS Negotiation . . . . . . . . . 71 13.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 149
5.4.2.1. STARTTLS Command . . . . . . . . . . . . . . . . 71 13.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 150
5.4.2.2. Failure Case . . . . . . . . . . . . . . . . . . 71 13.3. Order of Layers . . . . . . . . . . . . . . . . . . . . 151
5.4.2.3. Proceed Case . . . . . . . . . . . . . . . . . . 72 13.4. Confidentiality and Integrity . . . . . . . . . . . . . 151
5.4.3. TLS Negotiation . . . . . . . . . . . . . . . . . . 72 13.5. Peer Entity Authentication . . . . . . . . . . . . . . . 152
5.4.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . 72 13.6. Strong Security . . . . . . . . . . . . . . . . . . . . 152
5.4.3.2. TLS Failure . . . . . . . . . . . . . . . . . . . 73 13.7. Certificates . . . . . . . . . . . . . . . . . . . . . . 152
5.4.3.3. TLS Success . . . . . . . . . . . . . . . . . . . 73 13.7.1. Certificate Generation . . . . . . . . . . . . . . . 153
6. SASL Negotiation . . . . . . . . . . . . . . . . . . . . . . 75 13.7.1.1. General Considerations . . . . . . . . . . . . . 153
6.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 75 13.7.1.2. Server Certificates . . . . . . . . . . . . . . . 154
6.2. Support . . . . . . . . . . . . . . . . . . . . . . . . 75 13.7.1.3. Client Certificates . . . . . . . . . . . . . . . 156
6.3. Stream Negotiation Rules . . . . . . . . . . . . . . . . 75 13.7.1.4. XmppAddr Identifier Type . . . . . . . . . . . . 156
6.3.1. Mandatory-to-Negotiate . . . . . . . . . . . . . . . 75 13.7.2. Certificate Validation . . . . . . . . . . . . . . . 157
6.3.2. Restart . . . . . . . . . . . . . . . . . . . . . . 75 13.7.2.1. Server Certificates . . . . . . . . . . . . . . . 158
6.3.3. Mechanism Preferences . . . . . . . . . . . . . . . 75 13.7.2.2. Client Certificates . . . . . . . . . . . . . . . 158
6.3.4. Mechanism Offers . . . . . . . . . . . . . . . . . . 75 13.7.2.3. Checking of Certificates in Long-Lived Streams . 160
6.3.5. Data Formatting . . . . . . . . . . . . . . . . . . 76 13.7.2.4. Use of Certificates in XMPP Extensions . . . . . 160
6.3.6. Security Layers . . . . . . . . . . . . . . . . . . 77 13.8. Mandatory-to-Implement TLS and SASL Technologies . . . . 161
6.3.7. Simple User Name . . . . . . . . . . . . . . . . . . 77 13.8.1. For Authentication Only . . . . . . . . . . . . . . 161
6.3.8. Authorization Identity . . . . . . . . . . . . . . . 77 13.8.2. For Confidentiality Only . . . . . . . . . . . . . . 161
6.3.9. Realms . . . . . . . . . . . . . . . . . . . . . . . 78
6.3.10. Round Trips . . . . . . . . . . . . . . . . . . . . 78
6.4. Process . . . . . . . . . . . . . . . . . . . . . . . . 79
6.4.1. Exchange of Stream Headers and Stream Features . . . 79
6.4.2. Initiation . . . . . . . . . . . . . . . . . . . . . 80
6.4.3. Challenge-Response Sequence . . . . . . . . . . . . 80
6.4.4. Abort . . . . . . . . . . . . . . . . . . . . . . . 81
6.4.5. SASL Failure . . . . . . . . . . . . . . . . . . . . 81
6.4.6. SASL Success . . . . . . . . . . . . . . . . . . . . 82
6.5. SASL Errors . . . . . . . . . . . . . . . . . . . . . . 84
6.5.1. aborted . . . . . . . . . . . . . . . . . . . . . . 84
6.5.2. account-disabled . . . . . . . . . . . . . . . . . . 84
6.5.3. credentials-expired . . . . . . . . . . . . . . . . 85
6.5.4. encryption-required . . . . . . . . . . . . . . . . 85
6.5.5. incorrect-encoding . . . . . . . . . . . . . . . . . 85
6.5.6. invalid-authzid . . . . . . . . . . . . . . . . . . 85
6.5.7. invalid-mechanism . . . . . . . . . . . . . . . . . 86
6.5.8. malformed-request . . . . . . . . . . . . . . . . . 86
6.5.9. mechanism-too-weak . . . . . . . . . . . . . . . . . 86
6.5.10. not-authorized . . . . . . . . . . . . . . . . . . . 87
6.5.11. temporary-auth-failure . . . . . . . . . . . . . . . 87
6.6. SASL Definition . . . . . . . . . . . . . . . . . . . . 87
7. Resource Binding . . . . . . . . . . . . . . . . . . . . . . 88
7.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 88
7.2. Support . . . . . . . . . . . . . . . . . . . . . . . . 89
7.3. Stream Negotiation Rules . . . . . . . . . . . . . . . . 89
7.3.1. Mandatory-to-Negotiate . . . . . . . . . . . . . . . 89
7.3.2. Restart . . . . . . . . . . . . . . . . . . . . . . 89
7.4. Advertising Support . . . . . . . . . . . . . . . . . . 89
7.5. Generation of Resource Identifiers . . . . . . . . . . . 90
7.6. Server-Generated Resource Identifier . . . . . . . . . . 90
7.6.1. Success Case . . . . . . . . . . . . . . . . . . . . 90
7.6.2. Error Cases . . . . . . . . . . . . . . . . . . . . 91
7.6.2.1. Resource Constraint . . . . . . . . . . . . . . . 91
7.6.2.2. Not Allowed . . . . . . . . . . . . . . . . . . . 91
7.7. Client-Submitted Resource Identifier . . . . . . . . . . 92
7.7.1. Success Case . . . . . . . . . . . . . . . . . . . . 92
7.7.2. Error Cases . . . . . . . . . . . . . . . . . . . . 93
7.7.2.1. Bad Request . . . . . . . . . . . . . . . . . . . 93
7.7.2.2. Conflict . . . . . . . . . . . . . . . . . . . . 93
7.7.3. Retries . . . . . . . . . . . . . . . . . . . . . . 95
8. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 95
8.1. Common Attributes . . . . . . . . . . . . . . . . . . . 95
8.1.1. to . . . . . . . . . . . . . . . . . . . . . . . . . 96
8.1.1.1. Client-to-Server Streams . . . . . . . . . . . . 96
8.1.1.2. Server-to-Server Streams . . . . . . . . . . . . 97
8.1.2. from . . . . . . . . . . . . . . . . . . . . . . . . 97
8.1.2.1. Client-to-Server Streams . . . . . . . . . . . . 97
8.1.2.2. Server-to-Server Streams . . . . . . . . . . . . 98
8.1.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 98
8.1.4. type . . . . . . . . . . . . . . . . . . . . . . . . 99
8.1.5. xml:lang . . . . . . . . . . . . . . . . . . . . . . 99
8.2. Basic Semantics . . . . . . . . . . . . . . . . . . . . 100
8.2.1. Message Semantics . . . . . . . . . . . . . . . . . 100
8.2.2. Presence Semantics . . . . . . . . . . . . . . . . . 101
8.2.3. IQ Semantics . . . . . . . . . . . . . . . . . . . . 101
8.3. Stanza Errors . . . . . . . . . . . . . . . . . . . . . 103
8.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 104
8.3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 105
8.3.3. Defined Conditions . . . . . . . . . . . . . . . . . 106
8.3.3.1. bad-request . . . . . . . . . . . . . . . . . . . 106
8.3.3.2. conflict . . . . . . . . . . . . . . . . . . . . 107
8.3.3.3. feature-not-implemented . . . . . . . . . . . . . 107
8.3.3.4. forbidden . . . . . . . . . . . . . . . . . . . . 108
8.3.3.5. gone . . . . . . . . . . . . . . . . . . . . . . 108
8.3.3.6. internal-server-error . . . . . . . . . . . . . . 109
8.3.3.7. item-not-found . . . . . . . . . . . . . . . . . 110
8.3.3.8. jid-malformed . . . . . . . . . . . . . . . . . . 110
8.3.3.9. not-acceptable . . . . . . . . . . . . . . . . . 111
8.3.3.10. not-allowed . . . . . . . . . . . . . . . . . . . 112
8.3.3.11. not-authorized . . . . . . . . . . . . . . . . . 112
8.3.3.12. payment-required . . . . . . . . . . . . . . . . 113
8.3.3.13. policy-violation . . . . . . . . . . . . . . . . 113
8.3.3.14. recipient-unavailable . . . . . . . . . . . . . . 114
8.3.3.15. redirect . . . . . . . . . . . . . . . . . . . . 115
8.3.3.16. registration-required . . . . . . . . . . . . . . 115
8.3.3.17. remote-server-not-found . . . . . . . . . . . . . 116
8.3.3.18. remote-server-timeout . . . . . . . . . . . . . . 117
8.3.3.19. resource-constraint . . . . . . . . . . . . . . . 117
8.3.3.20. service-unavailable . . . . . . . . . . . . . . . 118
8.3.3.21. subscription-required . . . . . . . . . . . . . . 119
8.3.3.22. undefined-condition . . . . . . . . . . . . . . . 119
8.3.3.23. unexpected-request . . . . . . . . . . . . . . . 120
8.3.4. Application-Specific Conditions . . . . . . . . . . 121
8.4. Extended Content . . . . . . . . . . . . . . . . . . . . 122
9. Detailed Examples . . . . . . . . . . . . . . . . . . . . . . 125
9.1. Client-to-Server Examples . . . . . . . . . . . . . . . 125
9.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 125
9.1.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 127
9.1.3. Resource Binding . . . . . . . . . . . . . . . . . . 129
9.1.4. Stanza Exchange . . . . . . . . . . . . . . . . . . 130
9.1.5. Close . . . . . . . . . . . . . . . . . . . . . . . 130
9.2. Server-to-Server Examples . . . . . . . . . . . . . . . 131
9.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 131
9.2.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 133
9.2.3. Stanza Exchange . . . . . . . . . . . . . . . . . . 134
9.2.4. Close . . . . . . . . . . . . . . . . . . . . . . . 134
10. Server Rules for Processing XML Stanzas . . . . . . . . . . . 135
10.1. In-Order Processing . . . . . . . . . . . . . . . . . . 135
10.2. General Considerations . . . . . . . . . . . . . . . . . 136
10.3. No 'to' Address . . . . . . . . . . . . . . . . . . . . 137
10.3.1. Message . . . . . . . . . . . . . . . . . . . . . . 137
10.3.2. Presence . . . . . . . . . . . . . . . . . . . . . . 138
10.3.3. IQ . . . . . . . . . . . . . . . . . . . . . . . . . 138
10.4. Remote Domain . . . . . . . . . . . . . . . . . . . . . 138
10.4.1. Existing Stream . . . . . . . . . . . . . . . . . . 139
10.4.2. No Existing Stream . . . . . . . . . . . . . . . . . 139
10.4.3. Error Handling . . . . . . . . . . . . . . . . . . . 139
10.5. Local Domain . . . . . . . . . . . . . . . . . . . . . . 139
10.5.1. Mere Domain . . . . . . . . . . . . . . . . . . . . 140
10.5.2. Domain with Resource . . . . . . . . . . . . . . . . 140
10.5.3. Localpart at Domain . . . . . . . . . . . . . . . . 140
10.5.3.1. No Such User . . . . . . . . . . . . . . . . . . 140
10.5.3.2. Bare JID . . . . . . . . . . . . . . . . . . . . 140
10.5.3.3. Full JID . . . . . . . . . . . . . . . . . . . . 141
11. XML Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 141
11.1. XML Restrictions . . . . . . . . . . . . . . . . . . . . 141
11.2. XML Namespace Names and Prefixes . . . . . . . . . . . . 142
11.3. Well-Formedness . . . . . . . . . . . . . . . . . . . . 142
11.4. Validation . . . . . . . . . . . . . . . . . . . . . . . 143
11.5. Inclusion of XML Declaration . . . . . . . . . . . . . . 143
11.6. Character Encoding . . . . . . . . . . . . . . . . . . . 144
11.7. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 144
11.8. XML Versions . . . . . . . . . . . . . . . . . . . . . . 144
12. Internationalization Considerations . . . . . . . . . . . . . 144
13. Security Considerations . . . . . . . . . . . . . . . . . . . 145
13.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 145
13.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 146
13.3. Order of Layers . . . . . . . . . . . . . . . . . . . . 146
13.4. Confidentiality and Integrity . . . . . . . . . . . . . 146
13.5. Peer Entity Authentication . . . . . . . . . . . . . . . 147
13.6. Strong Security . . . . . . . . . . . . . . . . . . . . 147
13.7. Certificates . . . . . . . . . . . . . . . . . . . . . . 148
13.7.1. Certificate Generation . . . . . . . . . . . . . . . 148
13.7.1.1. General Considerations . . . . . . . . . . . . . 148
13.7.1.2. Server Certificates . . . . . . . . . . . . . . . 149
13.7.1.3. Client Certificates . . . . . . . . . . . . . . . 151
13.7.1.4. XmppAddr Identifier Type . . . . . . . . . . . . 151
13.7.2. Certificate Validation . . . . . . . . . . . . . . . 152
13.7.2.1. Server Certificates . . . . . . . . . . . . . . . 153
13.7.2.2. Client Certificates . . . . . . . . . . . . . . . 154
13.7.2.3. Checking of Certificates in Long-Lived Streams . 155
13.7.2.4. Use of Certificates in XMPP Extensions . . . . . 156
13.8. Mandatory-to-Implement TLS and SASL Technologies . . . . 156
13.8.1. For Authentication Only . . . . . . . . . . . . . . 156
13.8.2. For Confidentiality Only . . . . . . . . . . . . . . 157
13.8.3. For Confidentiality and Authentication With 13.8.3. For Confidentiality and Authentication With
Passwords . . . . . . . . . . . . . . . . . . . . . 157 Passwords . . . . . . . . . . . . . . . . . . . . . 162
13.8.4. For Confidentiality and Authentication Without 13.8.4. For Confidentiality and Authentication Without
Passwords . . . . . . . . . . . . . . . . . . . . . 158 Passwords . . . . . . . . . . . . . . . . . . . . . 163
13.9. Technology Reuse . . . . . . . . . . . . . . . . . . . . 158 13.9. Technology Reuse . . . . . . . . . . . . . . . . . . . . 163
13.9.1. Use of base64 in SASL . . . . . . . . . . . . . . . 158 13.9.1. Use of Base64 in SASL . . . . . . . . . . . . . . . 163
13.9.2. Use of DNS . . . . . . . . . . . . . . . . . . . . . 158 13.9.2. Use of DNS . . . . . . . . . . . . . . . . . . . . . 163
13.9.3. Use of Hash Functions . . . . . . . . . . . . . . . 159 13.9.3. Use of Hash Functions . . . . . . . . . . . . . . . 164
13.9.4. Use of SASL . . . . . . . . . . . . . . . . . . . . 159 13.9.4. Use of SASL . . . . . . . . . . . . . . . . . . . . 164
13.9.5. Use of TLS . . . . . . . . . . . . . . . . . . . . . 160 13.9.5. Use of TLS . . . . . . . . . . . . . . . . . . . . . 165
13.9.6. Use of UTF-8 . . . . . . . . . . . . . . . . . . . . 160 13.9.6. Use of UTF-8 . . . . . . . . . . . . . . . . . . . . 165
13.9.7. Use of XML . . . . . . . . . . . . . . . . . . . . . 161 13.9.7. Use of XML . . . . . . . . . . . . . . . . . . . . . 166
13.10. Information Leaks . . . . . . . . . . . . . . . . . . . 161 13.10. Information Leaks . . . . . . . . . . . . . . . . . . . 166
13.10.1. IP Addresses . . . . . . . . . . . . . . . . . . . . 161 13.10.1. IP Addresses . . . . . . . . . . . . . . . . . . . . 166
13.10.2. Presence Information . . . . . . . . . . . . . . . . 161 13.10.2. Presence Information . . . . . . . . . . . . . . . . 166
13.11. Directory Harvesting . . . . . . . . . . . . . . . . . . 161 13.11. Directory Harvesting . . . . . . . . . . . . . . . . . . 166
13.12. Denial of Service . . . . . . . . . . . . . . . . . . . 162 13.12. Denial of Service . . . . . . . . . . . . . . . . . . . 167
13.13. Firewalls . . . . . . . . . . . . . . . . . . . . . . . 163 13.13. Firewalls . . . . . . . . . . . . . . . . . . . . . . . 169
13.14. Interdomain Federation . . . . . . . . . . . . . . . . . 164 13.14. Interdomain Federation . . . . . . . . . . . . . . . . . 169
13.15. Non-Repudiation . . . . . . . . . . . . . . . . . . . . 164 13.15. Non-Repudiation . . . . . . . . . . . . . . . . . . . . 169
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 164 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 170
14.1. XML Namespace Name for TLS Data . . . . . . . . . . . . 165 14.1. XML Namespace Name for TLS Data . . . . . . . . . . . . 170
14.2. XML Namespace Name for SASL Data . . . . . . . . . . . . 165 14.2. XML Namespace Name for SASL Data . . . . . . . . . . . . 170
14.3. XML Namespace Name for Stream Errors . . . . . . . . . . 165 14.3. XML Namespace Name for Stream Errors . . . . . . . . . . 170
14.4. XML Namespace Name for Resource Binding . . . . . . . . 165 14.4. XML Namespace Name for Resource Binding . . . . . . . . 171
14.5. XML Namespace Name for Stanza Errors . . . . . . . . . . 166 14.5. XML Namespace Name for Stanza Errors . . . . . . . . . . 171
14.6. GSSAPI Service Name . . . . . . . . . . . . . . . . . . 166 14.6. GSSAPI Service Name . . . . . . . . . . . . . . . . . . 171
14.7. Port Numbers and Service Names . . . . . . . . . . . . . 166 14.7. Port Numbers and Service Names . . . . . . . . . . . . . 171
15. Conformance Requirements . . . . . . . . . . . . . . . . . . 167 15. Conformance Requirements . . . . . . . . . . . . . . . . . . 172
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 176 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 181
16.1. Normative References . . . . . . . . . . . . . . . . . . 176 16.1. Normative References . . . . . . . . . . . . . . . . . . 181
16.2. Informative References . . . . . . . . . . . . . . . . . 178 16.2. Informative References . . . . . . . . . . . . . . . . . 184
Appendix A. XML Schemas . . . . . . . . . . . . . . . . . . . . 184 Appendix A. XML Schemas . . . . . . . . . . . . . . . . . . . . 190
A.1. Stream Namespace . . . . . . . . . . . . . . . . . . . . 185 A.1. Stream Namespace . . . . . . . . . . . . . . . . . . . . 190
A.2. Stream Error Namespace . . . . . . . . . . . . . . . . . 186 A.2. Stream Error Namespace . . . . . . . . . . . . . . . . . 192
A.3. STARTTLS Namespace . . . . . . . . . . . . . . . . . . . 189 A.3. STARTTLS Namespace . . . . . . . . . . . . . . . . . . . 194
A.4. SASL Namespace . . . . . . . . . . . . . . . . . . . . . 189 A.4. SASL Namespace . . . . . . . . . . . . . . . . . . . . . 195
A.5. Client Namespace . . . . . . . . . . . . . . . . . . . . 191 A.5. Client Namespace . . . . . . . . . . . . . . . . . . . . 196
A.6. Server Namespace . . . . . . . . . . . . . . . . . . . . 195 A.6. Server Namespace . . . . . . . . . . . . . . . . . . . . 201
A.7. Resource Binding Namespace . . . . . . . . . . . . . . . 201 A.7. Resource Binding Namespace . . . . . . . . . . . . . . . 206
A.8. Stanza Error Namespace . . . . . . . . . . . . . . . . . 201 A.8. Stanza Error Namespace . . . . . . . . . . . . . . . . . 206
Appendix B. Contact Addresses . . . . . . . . . . . . . . . . . 203 Appendix B. Contact Addresses . . . . . . . . . . . . . . . . . 208
Appendix C. Account Provisioning . . . . . . . . . . . . . . . . 203 Appendix C. Account Provisioning . . . . . . . . . . . . . . . . 208
Appendix D. Differences from RFC 3920 . . . . . . . . . . . . . 203 Appendix D. Differences from RFC 3920 . . . . . . . . . . . . . 208
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 205 Appendix E. Acknowledgements . . . . . . . . . . . . . . . . . . 210
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 210
1. Introduction 1. Introduction
1.1. Overview 1.1. Overview
The Extensible Messaging and Presence Protocol (XMPP) is an The Extensible Messaging and Presence Protocol (XMPP) is an
application profile of the Extensible Markup Language [XML] that application profile of the Extensible Markup Language [XML] that
enables the near-real-time exchange of structured yet extensible data enables the near-real-time exchange of structured yet extensible data
between any two or more network entities. This document defines between any two or more network entities. This document defines
XMPP's core protocol methods: setup and teardown of XML streams, XMPP's core protocol methods: setup and teardown of XML streams,
channel encryption, authentication, error handling, and communication channel encryption, authentication, error handling, and communication
primitives for messaging, network availability ("presence"), and primitives for messaging, network availability ("presence"), and
request-response interactions. request-response interactions.
1.2. History 1.2. History
The basic syntax and semantics of XMPP were developed originally The basic syntax and semantics of XMPP were developed originally
within the Jabber open-source community, mainly in 1999. In late within the Jabber open-source community, mainly in 1999. In late
2002, the XMPP Working Group was chartered with developing an 2002, the XMPP Working Group was chartered with developing an
adaptation of the core Jabber protocol that would be suitable as an adaptation of the base Jabber protocol that would be suitable as an
IETF instant messaging (IM) and presence technology in accordance IETF instant messaging (IM) and presence technology in accordance
with [IMP-REQS]. In October 2004, [RFC3920] and [RFC3921] were with [IMP-REQS]. In October 2004, [RFC3920] and [RFC3921] were
published, representing the most complete definition of XMPP at that published, representing the most complete definition of XMPP at that
time. time.
Since 2004 the Internet community has gained extensive implementation Since 2004 the Internet community has gained extensive implementation
and deployment experience with XMPP, including formal and deployment experience with XMPP, including formal
interoperability testing carried out under the auspices of the XMPP interoperability testing carried out under the auspices of the XMPP
Standards Foundation (XSF). This document incorporates comprehensive Standards Foundation (XSF). This document incorporates comprehensive
feedback from software developers and service providers, including a feedback from software developers and service providers, including a
skipping to change at page 10, line 6 skipping to change at page 10, line 6
The purpose of XMPP is to enable the exchange of relatively small The purpose of XMPP is to enable the exchange of relatively small
pieces of structured data (called "XML stanzas") over a network pieces of structured data (called "XML stanzas") over a network
between any two (or more) entities. XMPP is typically implemented between any two (or more) entities. XMPP is typically implemented
using a distributed client-server architecture, wherein a client using a distributed client-server architecture, wherein a client
needs to connect to a server in order to gain access to the network 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 and thus be allowed to exchange XML stanzas with other entities
(which can be associated with other servers). The process whereby a (which can be associated with other servers). The process whereby a
client connects to a server, exchanges XML stanzas, and ends the client connects to a server, exchanges XML stanzas, and ends the
connection is: connection is:
1. Determine the hostname and port at which to connect 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 2. Open a Transmission Control Protocol [TCP] connection
3. Open an XML stream over TCP 3. Open an XML stream over TCP (Section 4.2)
4. Negotiate Transport Layer Security [TLS] for channel encryption 4. Preferably negotiate Transport Layer Security [TLS] for channel
(recommended) encryption (Section 5)
5. Authenticate using a Simple Authentication and Security Layer 5. Authenticate using a Simple Authentication and Security Layer
[SASL] mechanism [SASL] mechanism (Section 6)
6. Bind a resource to the stream 6. Bind a resource to the stream (Section 7)
7. Exchange an unbounded number of XML stanzas with other entities 7. Exchange an unbounded number of XML stanzas with other entities
on the network on the network (Section 8)
8. Close the XML stream 8. Close the XML stream (Section 4.4)
9. Close the TCP connection 9. Close the TCP connection
Within XMPP, one server can optionally connect to another server to Within XMPP, one server can optionally connect to another server to
enable inter-domain or inter-server communication. For this to enable inter-domain or inter-server communication. For this to
happen, the two servers need to negotiate a connection between happen, the two servers need to negotiate a connection between
themselves and then exchange XML stanzas; the process for doing so themselves and then exchange XML stanzas; the process for doing so
is: is:
1. Determine the hostname and port at which to connect 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 2. Open a TCP connection
3. Open an XML stream 3. Open an XML stream (Section 4.2)
4. Negotiate TLS for channel encryption (recommended) 4. Preferably negotiate TLS for channel encryption (Section 5)
5. Authenticate using a Simple Authentication and Security Layer 5. Authenticate using a Simple Authentication and Security Layer
[SASL] mechanism * [SASL] mechanism (Section 6) *
6. Exchange an unbounded number of XML stanzas both directly for the 6. Exchange an unbounded number of XML stanzas both directly for the
servers and indirectly on behalf of entities associated with each servers and indirectly on behalf of entities associated with each
server (e.g., connected clients) server, such as connected clients (Section 8)
7. Close the XML stream 7. Close the XML stream (Section 4.4)
8. Close the TCP connection 8. Close the TCP connection
* Interoperability Note: At the time of writing, most deployed * Interoperability Note: At the time of writing, most deployed
servers use the Server Dialback protocol [XEP-0220] to provide servers still use the Server Dialback protocol [XEP-0220] to
weak identity verification instead of using SASL to provide strong provide weak identity verification instead of using SASL with PKIX
authentication, especially in cases where SASL negotiation would certificates to provide strong authentication, especially in cases
not result in strong authentication anyway (e.g., because TLS where SASL negotiation would not result in strong authentication
negotiation was not mandated by the peer server, or because the anyway (e.g., because TLS negotiation was not mandated by the peer
PKIX certificate presented by the peer server during TLS server, or because the PKIX certificate presented by the peer
negotiation is self-signed and has not been previously accepted); server during TLS negotiation is self-signed and has not been
for details, see [XEP-0220]. The solutions specified in this previously accepted); for details, see [XEP-0220]. The solutions
document offer a significantly stronger level of security (see specified in this document offer a significantly stronger level of
also Section 13.6). security (see also Section 13.6).
This document specifies how clients connect to servers and specifies This document specifies how clients connect to servers and specifies
the basic semantics of XML stanzas. However, this document does not the basic semantics of XML stanzas. However, this document does not
define the "payloads" of the XML stanzas that might be exchanged once define the "payloads" of the XML stanzas that might be exchanged once
a connection is successfully established; instead, those payloads are a connection is successfully established; instead, those payloads are
defined by various XMPP extensions. For example, [XMPP-IM] defines defined by various XMPP extensions. For example, [XMPP-IM] defines
extensions for basic instant messaging and presence functionality. extensions for basic instant messaging and presence functionality.
In addition, various specifications produced in the XSF's XEP series In addition, various specifications produced in the XSF's XEP series
[XEP-0001] define extensions for a wide range of applications. [XEP-0001] define extensions for a wide range of applications.
skipping to change at page 11, line 24 skipping to change at page 11, line 28
"OPTIONAL" in this document are to be interpreted as described in "OPTIONAL" in this document are to be interpreted as described in
[KEYWORDS]. [KEYWORDS].
Certain security-related terms are to be understood in the sense Certain security-related terms are to be understood in the sense
defined in [SEC-TERMS]; such terms include, but are not limited to, defined in [SEC-TERMS]; such terms include, but are not limited to,
"assurance", "attack", "authentication", "authorization", "assurance", "attack", "authentication", "authorization",
"certificate", "certification authority", "certification path", "certificate", "certification authority", "certification path",
"confidentiality", "credential", "downgrade", "encryption", "confidentiality", "credential", "downgrade", "encryption",
"fingerprint", "hash value", "identity", "integrity", "signature", "fingerprint", "hash value", "identity", "integrity", "signature",
"security perimeter", "self-signed certificate", "sign", "spoof", "security perimeter", "self-signed certificate", "sign", "spoof",
"tamper", "trust", "trust anchor", "trust chain", "validate", "tamper", "trust", "trust anchor", "trust chain", "validate", and
"verify". "verify".
Certain terms related to certificates, domains, and application Certain terms related to certificates, domains, and application
service identity are to be understood in the sense defined in service identity are to be understood in the sense defined in
[TLS-CERTS]; these include, but are not limited to, "PKIX [TLS-CERTS]; these include, but are not limited to, "PKIX
certificate", "source domain", "derived domain", and the identifier certificate", "source domain", "derived domain", and the identifier
types "CN-ID", "DNS-ID", and "SRV-ID". types "CN-ID", "DNS-ID", and "SRV-ID".
Other security-related terms are to be understood in the sense Other security-related terms are to be understood in the sense
defined in the referenced specifications (for example, "denial of defined in the referenced specifications (for example, "denial of
service" as described in [DOS] or "end entity certificate" as service" as described in [DOS] or "end entity certificate" as
described in [PKIX]). described in [PKIX]).
The term "whitespace" is used to refer to any character that matches The term "whitespace" is used to refer to any character or characters
production [3] content of [XML], i.e., any instance of the SP, HTAB, matching the "S" production from [XML], i.e., one or more instances
CR, or LF rules defined in [ABNF]. 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
Section 8.2.1, Section 8.2.2, and Section 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 The term "input stream" designates an XML stream over which a server
receives data from a connected client or remote server, and the term receives data from a connected client or remote server, and the term
"output stream" designates an XML stream over which a server sends "output stream" designates an XML stream over which a server sends
data to a connected client or remote server. The following terms data to a connected client or remote server. The following terms
designate some of the actions that a server can perform when designate some of the actions that a server can perform when
processing data received over an input stream: processing data received over an input stream:
route: pass the data to a remote server for direct processing by route: pass the data to a remote server for direct processing by
the remote server or eventual delivery to a client associated the remote server or eventual delivery to a client associated
with the remote server) with the remote server
deliver: pass the data to a connected client deliver: pass the data to a connected client
ignore: discard the data without acting upon it or returning an ignore: discard the data without acting upon it or returning an
error to the sender error to the sender
When the term "ignore" is used with regard to client processing of When the term "ignore" is used with regard to client processing of
data it receives, the phrase "without acting upon it" explicitly data it receives, the phrase "without acting upon it" explicitly
includes not presenting the data to a human user. 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 "&#x0159;" 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 Indentifiers, XMPP addresses in running text are enclosed
between '<' and '>' (although natively they are not URIs).
In examples, lines have been wrapped for improved readability, In examples, lines have been wrapped for improved readability,
"[...]" means elision, and the following prepended strings are used "[...]" means elision, and the following prepended strings are used
(these prepended strings are not to be sent over the wire): (these prepended strings are not to be sent over the wire):
o C: = a client o C: = a client
o E: = any XMPP entity o E: = any XMPP entity
o I: = an initiating entity o I: = an initiating entity
o P: = a peer server o P: = a peer server
o R: = a receiving entity o R: = a receiving entity
o S: = a server o S: = a server
o S1: = server1 o S1: = server1
o S2: = server2 o S2: = server2
Readers need to be aware that the examples are not exhaustive and Readers need to be aware that the examples are not exhaustive and
that, in examples for some protocol flows, the alternate steps shown that, in examples for some protocol flows, the alternate steps shown
would not necessarily be triggered by the exact data sent in the would not necessarily be triggered by the exact data sent in the
previous step; in all cases the protocol definitions specified in previous step; in all cases the protocol definitions specified in
this document or in normatively referenced documents rule over any this document or in normatively referenced documents rule over any
examples provided here. examples provided here. All examples are fictional and the
information exchanged (e.g., usernames and passwords) does not
Following the "XML Notation" used in [IRI] to represent characters represent any existing users or servers.
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 "&#x0159;" 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.
In adherence to the convention used in [URI] to represent Uniform
Resource Indentifiers, XMPP addresses in running text are enclosed
between '<' and '>' (despite the fact that natively they are not
URIs).
1.5. Acknowledgements
This document is an update to, and derived from, RFC 3920. This
document would have been impossible without the work of the
contributors and commenters acknowledged there.
Hundreds of people have provided implementation feedback, bug
reports, requests for clarification, and suggestions for improvement
since publication of RFC 3920. Although the document editor has
endeavored to address all such feedback, he is solely responsible for
any remaining errors and ambiguities.
Special thanks are due to Kevin Smith, Matthew Wild, Dave Cridland,
Philipp Hancke, Waqas Hussain, Florian Zeitz, Ben Campbell, Jehan
Pages, Paul Aurich, Justin Karneges, Kurt Zeilenga, Simon Josefsson,
Ralph Meijer, Curtis King, and others for their comments during
Working Group Last Call. Thanks also to Yaron Sheffer for his review
on behalf of the Security Directorate.
The Working Group chairs were Ben Campbell and Joe Hildebrand.
The responsible Area Director was Gonzalo Camarillo.
1.6. Discussion Venue
The document editor and the broader XMPP developer community welcome
discussion and comments related to the topics presented in this
document. The primary and preferred venue is the <xmpp@ietf.org>
mailing list, for which archives and subscription information are
available at <https://www.ietf.org/mailman/listinfo/xmpp>. Related
discussions often occur on the <standards@xmpp.org> mailing list, for
which archives and subscription information are available at
<http://mail.jabber.org/mailman/listinfo/standards>.
2. Architecture 2. Architecture
XMPP provides a technology for the asynchronous, end-to-end exchange XMPP provides a technology for the asynchronous, end-to-end exchange
of structured data by means of direct, persistent XML streams among a of structured data by means of direct, persistent XML streams among a
distributed network of globally-addressable, presence-aware clients distributed network of globally-addressable, presence-aware clients
and servers. Because this architectural style involves ubiquitous and servers. Because this architectural style involves ubiquitous
knowledge of network availability and a conceptually unlimited number knowledge of network availability and a conceptually unlimited number
of concurrent information transactions in the context of a given of concurrent information transactions in the context of a given
client-to-server or server-to-server session, we label it client-to-server or server-to-server session, we label it
skipping to change at page 14, line 15 skipping to change at page 14, line 6
to real time. The salient features of this ACTive architectural to real time. The salient features of this ACTive architectural
style are as follows. style are as follows.
2.1. Global Addresses 2.1. Global Addresses
As with email, XMPP uses globally-unique addresses (based on the As with email, XMPP uses globally-unique addresses (based on the
Domain Name System) in order to route and deliver messages over the Domain Name System) in order to route and deliver messages over the
network. All XMPP entities are addressable on the network, most network. All XMPP entities are addressable on the network, most
particularly clients and servers but also various additional services particularly clients and servers but also various additional services
that can be accessed by clients and servers. In general, server that can be accessed by clients and servers. In general, server
addresses are of the form <domain.tld> (e.g., <im.example.com>), addresses are of the form <domainpart> (e.g., <im.example.com>),
accounts hosted at a server are of the form <localpart@domainpart> accounts hosted at a server are of the form <localpart@domainpart>
(e.g., <juliet@im.example.com>), and a particular connected device or (e.g., <juliet@im.example.com>, called a "bare JID"), and a
resource that is currently authorized for interaction on behalf of an particular connected device or resource that is currently authorized
account is of the form <localpart@domainpart/resourcepart> (e.g., for interaction on behalf of an account is of the form
<juliet@im.example.com/balcony>). For historical reasons, XMPP <localpart@domainpart/resourcepart> (e.g.,
addresses are often called Jabber IDs or JIDs. Because the formal <juliet@im.example.com/balcony>, called a "full JID"). For
specification of the XMPP address format depends on historical reasons, XMPP addresses are often called Jabber IDs or
internationalization technologies that are in flux at the time of JIDs. Because the formal specification of the XMPP address format
writing, the format is defined in [XMPP-ADDR] instead of this depends on internationalization technologies that are in flux at the
document. time of writing, the format is defined in [XMPP-ADDR] instead of this
document. The terms "localpart", "domainpart", and "resourcepart"
are defined more formally in [XMPP-ADDR].
2.2. Presence 2.2. Presence
XMPP includes the ability for an entity to advertise its network XMPP includes the ability for an entity to advertise its network
availability or "presence" to other entities. Such availability for availability or "presence" to other entities. In XMPP, this
communication is signalled end-to-end via dedicated communication availability for communication is signalled end-to-end by means of a
primitives in XMPP (the <presence/> stanza). Although knowledge of dedicated communication primitive: the <presence/> stanza. Although
network availability is not strictly necessary for the exchange of knowledge of network availability is not strictly necessary for the
XMPP messages, it facilitates real-time interaction because the exchange of XMPP messages, it facilitates real-time interaction
originator of a message can know before initiating communication that because the originator of a message can know before initiating
the intended recipient is online and available. End-to-end presence communication that the intended recipient is online and available.
is defined in [XMPP-IM]. End-to-end presence is defined in [XMPP-IM].
2.3. Persistent Streams 2.3. Persistent Streams
Availability for communication is also built into a point-to-point Availability for communication is also built into each point-to-point
"hop" through the use of persistent XML streams over long-lived TCP "hop" through the use of persistent XML streams over long-lived TCP
connections. These "always-on" client-to-server or server-to-server connections. These "always-on" client-to-server and server-to-server
streams enable each party to push data to the other party at any time streams enable each party to push data to the other party at any time
for immediate routing or delivery. XML streams are defined under for immediate routing or delivery. XML streams are defined under
Section 4. Section 4.
2.4. Structured Data 2.4. Structured Data
The basic protocol data unit in XMPP is not an XML stream (which The basic protocol data unit in XMPP is not an XML stream (which
simply provides the transport for point-to-point communication) but simply provides the transport for point-to-point communication) but
an XML "stanza", which is essentially a fragment of XML that is sent an XML "stanza", which is essentially a fragment of XML that is sent
over a stream. The root element of a stanza includes routing over a stream. The root element of a stanza includes routing
attributes (such as "from" and "to" addresses) and the child elements attributes (such as "from" and "to" addresses) and the child elements
of the stanza contain a payload for delivery to the intended of the stanza contain a payload for delivery to the intended
recipient. XML stanzas are defined under Section 8. recipient. XML stanzas are defined under Section 8.
2.5. Distributed Network of Clients and Servers 2.5. Distributed Network of Clients and Servers
In practice, XMPP consists of a network of clients and servers that In practice, XMPP consists of a network of clients and servers that
inter-communicate (however, communication between any two given inter-communicate (however, communication between any two given
deployed servers is strictly OPTIONAL). Thus, for example, the user deployed servers is strictly discretionary and a matter of local
<juliet@im.example.com> associated with the server <im.example.com> service policy). Thus, for example, the user <juliet@im.example.com>
might be able to exchange messages, presence, and other structured associated with the server <im.example.com> might be able to exchange
data with the user <romeo@example.net> associated with the server messages, presence, and other structured data with the user
<example.net>. This pattern is familiar from messaging protocols <romeo@example.net> associated with the server <example.net>. This
that make use of global addresses, such as the email network (see pattern is familiar from messaging protocols that make use of global
[SMTP] and [EMAIL-ARCH]). As a result, end-to-end communication in addresses, such as the email network (see [SMTP] and [EMAIL-ARCH]).
XMPP is logically peer-to-peer but physically client-to-server-to- As a result, end-to-end communication in XMPP is logically peer-to-
server-to-client, as illustrated in the following diagram. peer but physically client-to-server-to-server-to-client, as
illustrated in the following diagram.
example.net ---------------- im.example.com example.net <--------------> im.example.com
| | ^ ^
| | | |
v v
romeo@example.net juliet@im.example.com romeo@example.net juliet@im.example.com
Figure 1: Distributed Client-Server Architecture Figure 1: Distributed Client-Server Architecture
Informational Note: Architectures that employ XML streams Informational Note: Architectures that employ XML streams
(Section 4) and XML stanzas (Section 8) but that establish peer- (Section 4) and XML stanzas (Section 8) but that establish peer-
to-peer connections directly between clients using technologies to-peer connections directly between clients using technologies
based on [LINKLOCAL] have been deployed, but such architectures based on [LINKLOCAL] have been deployed, but such architectures
are not defined in this specification and are best described as are not defined in this specification and are best described as
"XMPP-like"; for details, see [XEP-0174]. In addition, XML "XMPP-like"; for details, see [XEP-0174]. In addition, XML
streams can be established end-to-end over any reliable transport, streams can be established end-to-end over any reliable transport,
including extensions to XMPP itself; however, such methods are out including extensions to XMPP itself; however, such methods are out
of scope for this specification. of scope for this specification.
The following paragraphs describe the responsibilities of clients and The following paragraphs describe the responsibilities of clients and
servers on the network. servers on the network.
A client is an entity that establishes an XML stream with a server by 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 authenticating using the credentials of a registered account and that
completes resource binding (Section 7) in order to enable delivery of then completes resource binding (Section 7) in order to enable
XML stanzas between the server and the client over the negotiated delivery of XML stanzas between the server and the client over the
stream. The client then uses XMPP to communicate with its server, negotiated stream. The client then uses XMPP to communicate with its
other clients, and any other entities on the network, where the server, other clients, and any other entities on the network, where
server is responsible for delivering stanzas to local entities or the server is responsible for delivering stanzas to other connected
routing them to remote entities. Multiple clients can connect clients at the same server or routing them to remote servers.
simultaneously to a server on behalf of the same local account, where Multiple clients can connect simultaneously to a server on behalf of
each client is differentiated by the resourcepart of an XMPP address the same registered account, where each client is differentiated by
(e.g., <juliet@im.example.com/balcony> vs. the resourcepart of an XMPP address (e.g.,
<juliet@im.example.com/chamber>), as defined under [XMPP-ADDR] and <juliet@im.example.com/balcony> vs. <juliet@im.example.com/chamber>),
Section 7. as defined under [XMPP-ADDR] and Section 7.
A server is an entity whose primary responsibilities are to: A server is an entity whose primary responsibilities are to:
o Manage XML streams (Section 4) with local clients and deliver XML o Manage XML streams (Section 4) with connected clients and deliver
stanzas (Section 8) to those clients over the negotiated streams; XML stanzas (Section 8) to those clients over the negotiated
this includes responsibility for ensuring that a client streams; this includes responsibility for ensuring that a client
authenticates with the server before being granted access to the authenticates with the server before being granted access to the
XMPP network. XMPP network.
o Subject to local service policies on server-to-server o Subject to local service policies on server-to-server
communication, manage XML streams (Section 4) with remote servers communication, manage XML streams (Section 4) with remote servers
and route XML stanzas (Section 8) to those servers over the and route XML stanzas (Section 8) to those servers over the
negotiated streams. negotiated streams.
Depending on the application, the secondary responsibilities of an Depending on the application, the secondary responsibilities of an
XMPP server can include: XMPP server can include:
o Storing data that is used by clients (e.g., contact lists for o Storing data that is used by clients (e.g., contact lists for
users of XMPP-based instant messaging and presence applications as users of XMPP-based instant messaging and presence applications as
defined in [XMPP-IM]); in this case, the relevant XML stanza is defined in [XMPP-IM]); in this case, the relevant XML stanza is
handled directly by the server itself on behalf of the client and handled directly by the server itself on behalf of the client and
is not routed to a remote server or delivered to a local entity. is not routed to a remote server or delivered to a connected
client.
o Hosting local services that also use XMPP as the basis for o Hosting add-on services that also use XMPP as the basis for
communication but that provide additional functionality beyond communication but that provide additional functionality beyond
that defined in this document or in [XMPP-IM]; examples include that defined in this document or in [XMPP-IM]; examples include
multi-user conferencing services as specified in [XEP-0045] and multi-user conferencing services as specified in [XEP-0045] and
publish-subscribe services as specified in [XEP-0060]. publish-subscribe services as specified in [XEP-0060].
3. TCP Binding 3. TCP Binding
3.1. Scope 3.1. Scope
As XMPP is defined in this specification, an initiating entity As XMPP is defined in this specification, an initiating entity
skipping to change at page 17, line 11 skipping to change at page 17, line 6
streams with the receiving entity. The parties then maintain that streams with the receiving entity. The parties then maintain that
TCP connection for as long as the XML streams are in use. The rules TCP connection for as long as the XML streams are in use. The rules
specified in the following sections apply to the TCP binding. specified in the following sections apply to the TCP binding.
Informational Note: There is no necessary coupling of XML streams Informational Note: There is no necessary coupling of XML streams
to TCP, and other transports are possible. For example, two to TCP, and other transports are possible. For example, two
entities could connect to each other by means of [HTTP] as entities could connect to each other by means of [HTTP] as
specified in [XEP-0124] and [XEP-0206]. However, this specified in [XEP-0124] and [XEP-0206]. However, this
specification defines only a binding of XMPP to TCP. specification defines only a binding of XMPP to TCP.
3.2. Hostname Resolution 3.2. Resolution of Fully Qualified Domain Names
Because XML streams are sent over TCP, the initiating entity needs to Because XML streams are sent over TCP, the initiating entity needs to
determine the IPv4 or IPv6 address (and port) of the receiving determine the IPv4 or IPv6 address (and port) of the receiving entity
entity's "origin domain" before it can attempt to connect to the XMPP before it can attempt to open an XML stream. Typically this is done
network. by resolving the receiving entity's fully-qualified domain name or
"FDQN" (see [DNS-CONCEPTS]).
3.2.1. Preferred Process: SRV Lookup 3.2.1. Preferred Process: SRV Lookup
The preferred process for hostname resolution is to use [DNS-SRV] The preferred process for FQDN resolution is to use [DNS-SRV] records
records as follows: as follows:
1. The initiating entity constructs a DNS SRV query whose inputs 1. The initiating entity constructs a DNS SRV query whose inputs
are: are:
* a Service of "xmpp-client" (for client-to-server connections) * a Service of "xmpp-client" (for client-to-server connections)
or "xmpp-server" (for server-to-server connections) or "xmpp-server" (for server-to-server connections)
* a Proto of "tcp" * a Proto of "tcp"
* a Name corresponding to the "origin domain" of the XMPP * a Name corresponding to the "origin domain" [TLS-CERTS] of the
service to which the initiating entity wishes to connect XMPP service to which the initiating entity wishes to connect
(e.g., "example.net" or "im.example.com") (e.g., "example.net" or "im.example.com")
2. The resulting is a query such as "_xmpp-client._tcp.example.net." 2. The result is a query such as "_xmpp-client._tcp.example.net." or
or "_xmpp-server._tcp.im.example.com.". "_xmpp-server._tcp.im.example.com.".
3. If a response is received, it will contain one or more 3. If a response is received, it will contain one or more
combinations of a port and hostname, each of which is weighted combinations of a port and FDQN, each of which is weighted and
and prioritized as described in [DNS-SRV]. However, if the prioritized as described in [DNS-SRV].
result of the SRV lookup is a single resource record with a
Target of ".", i.e. the root domain, then the initiating entity
MUST abort SRV processing at this point (but SHOULD attempt the
fallback process described in the next section).
4. The initiating entity chooses at least one of the returned (However, if the result of the SRV lookup is a single resource
hostnames to resolve (following the rules in [DNS-SRV]), which it record with a Target of ".", i.e. the root domain, then the
does by using a DNS "A" or "AAAA" lookup on the hostname; this initiating entity MUST abort SRV processing at this point because
will result in an IPv4 or IPv6 address. according to [DNS-SRV] such a Target "means that the service is
decidedly not available at this domain".)
5. The initiating entity uses the IP address(es) from the first 4. The initiating entity chooses at least one of the returned FQDNs
successfully resolved hostname (with the corresponding port to resolve (following the rules in [DNS-SRV]), which it does by
number returned by the SRV lookup) as the connection address for performing DNS "A" or "AAAA" lookups on the FDQN; this will
the receiving entity. result in an IPv4 or IPv6 address.
5. The initiating entity uses the IP address(es) from the
successfully resolved FDQN (with the corresponding port number
returned by the SRV lookup) as the connection address for the
receiving entity.
6. If the initiating entity fails to connect using that IP address 6. If the initiating entity fails to connect using that IP address
but the "A" or "AAAA" lookup returned more than one IP address, but the "A" or "AAAA" lookups returned more than one IP address,
then the initiating entity uses the next resolved IP address for then the initiating entity uses the next resolved IP address for
that hostname as the connection address. that FDQN as the connection address.
7. If the initiating entity fails to connect using all resolved IP 7. If the initiating entity fails to connect using all resolved IP
addresses for a given hostname, then it repeats the process of addresses for a given FDQN, then it repeats the process of
resolution and connection for the next hostname returned by the resolution and connection for the next FQDN returned by the SRV
SRV lookup. lookup based on the priority and weight as defined in [DNS-SRV].
8. If the initiating entity fails to connect using any hostname 8. If the initiating entity receives a response to its SRV query but
returned by the SRV lookup, then it can either abort the it is not able to establish an XMPP connection using the data
connection attempt or use the fallback process described in the received in the response, it SHOULD NOT attempt the fallback
process described in the next section (this helps to prevent a
state mismatch between inbound and outbound connections).
9. If the initiating entity does not receive a response to its SRV
query, it SHOULD attempt the fallback process described in the
next section. next section.
3.2.2. Fallback Processes 3.2.2. Fallback Processes
The fallback process SHOULD be a normal "A" or "AAAA" address record The fallback process SHOULD be a normal "A" or "AAAA" address record
resolution to determine the IPv4 or IPv6 address of the origin resolution to determine the IPv4 or IPv6 address of the origin
domain, where the port used is the "xmpp-client" port of 5222 for domain, where the port used is the "xmpp-client" port of 5222 for
client-to-server connections or the "xmpp-server" port 5269 for client-to-server connections or the "xmpp-server" port of 5269 for
server-to-server connections. server-to-server connections (these are the default ports as
registered with the IANA as described under Section 14.7).
For client-to-server connections, the fallback MAY be a [DNS-TXT] If connections via TCP are unsuccessful, the initiating entity might
lookup for alternative connection methods, for example as described attempt to find and use alternative connection methods such as the
in [XEP-0156]. HTTP binding (see [XEP-0124] and [XEP-0206]), which might be
discovered using [DNS-TXT] records as described in [XEP-0156].
3.2.3. When Not to Use SRV 3.2.3. When Not to Use SRV
If the initiating entity has been explicitly configured to associate If the initiating entity has been explicitly configured to associate
a particular hostname (and potentially port) with the origin domain a particular FQDN (and potentially port) with the origin domain of
of the receiving entity (say, to "hardcode" an association from an the receiving entity (say, to "hardcode" an association from an
origin domain of example.net to a configured hostname of origin domain of example.net to a configured FQDN of
webcm.example.com:80), the initiating entity SHOULD use the apps.example.com), the initiating entity SHOULD use the configured
configured name instead of performing the preferred SRV resolution name instead of performing the preferred SRV resolution process on
process on the origin name. the origin domain.
3.2.4. Use of SRV Records with Add-On Services 3.2.4. Use of SRV Records with Add-On Services
Many XMPP servers are implemented in such a way that they can host Many XMPP servers are implemented in such a way that they can host
add-on services (beyond those defined in this specification and add-on services (beyond those defined in this specification and
[XMPP-IM]) at DNS domain names that typically are "subdomains" of the [XMPP-IM]) at DNS domain names that typically are "subdomains" of the
main XMPP service (e.g., conference.example.net for a [XEP-0045] main XMPP service (e.g., conference.example.net for a [XEP-0045]
service associated with the example.net XMPP service) or "subdomains" service associated with the example.net XMPP service) or "subdomains"
of the first-level domain of the underlying service (e.g., of the first-level domain of the underlying service (e.g.,
muc.example.com for a [XEP-0045] service associated with the muc.example.com for a [XEP-0045] service associated with the
im.example.com XMPP service). If an entity associated with a remote im.example.com XMPP service). If an entity associated with a remote
XMPP server wishes to use such an add-on service, it would generate XMPP server wishes to communicate with such an add-on service, it
an appropriate XML stanza and the remote server would attempt to would generate an appropriate XML stanza and the remote server would
resolve the add-on service's DNS domain name via an SRV lookup on attempt to resolve the add-on service's DNS domain name via an SRV
resource records such as "_xmpp-server._tcp.conference.example.net." lookup on resource records such as "_xmpp-
or "_xmpp-server._tcp.muc.example.com.". Therefore if the server._tcp.conference.example.net." or "_xmpp-
administrators of an XMPP service wish to enable entities associated server._tcp.muc.example.com.". Therefore if the administrators of an
with remote servers to access such add-on services, they need to XMPP service wish to enable entities associated with remote servers
advertise the appropriate "_xmpp-server" SRV records in addition to to access such add-on services, they need to advertise the
the "_xmpp-server" record for their main XMPP service. In case SRV appropriate "_xmpp-server" SRV records in addition to the "_xmpp-
records are not available, the fallback methods described under server" record for their main XMPP service. In case SRV records are
Section 3.2.2 can be used to resolve the DNS domain names of add-on not available, the fallback methods described under Section 3.2.2 can
services. be used to resolve the DNS domain names of add-on services.
3.3. Reconnection 3.3. Reconnection
It can happen that an XMPP server goes offline while servicing TCP It can happen that an XMPP server goes offline while servicing TCP
connections from local clients and from other servers. Because the connections from connected clients and remote servers. Because the
number of such connections can be quite large, the reconnection number of such connections can be quite large, the reconnection
algorithm employed by entities that seek to reconnect can have a algorithm employed by entities that seek to reconnect can have a
significant impact on software and network performance. If an entity significant impact on software and network performance. If an entity
chooses to reconnect, the following guidelines are RECOMMENDED: chooses to reconnect, the following guidelines are RECOMMENDED:
o The number of seconds that expire before an entity first seeks to o The number of seconds that expire before an entity first seeks to
reconnect SHOULD be an unpredictable number between 0 and 60 reconnect SHOULD be an unpredictable number between 0 and 60
(e.g., so that all clients do not attempt to reconnect exactly 30 (e.g., so that all entities do not attempt to reconnect exactly 30
seconds after being disconnected). seconds after being disconnected).
o If the first reconnection attempt does not succeed, an entity o If the first reconnection attempt does not succeed, an entity
SHOULD back off increasingly on the time between subsequent SHOULD back off increasingly on the time between subsequent
reconnection attempts (e.g., in accordance with "truncated binary reconnection attempts (e.g., in accordance with "truncated binary
exponential backoff" as described in [ETHERNET]). exponential backoff" as described in [ETHERNET]).
It is RECOMMENDED to make use of TLS session resumption [TLS-RESUME] It is RECOMMENDED to make use of TLS session resumption [TLS-RESUME]
when reconnecting. A future version of this document, or a separate when reconnecting. A future version of this document, or a separate
specification, might provide more detailed guidelines regarding specification, might provide more detailed guidelines regarding
skipping to change at page 21, line 5 skipping to change at page 21, line 12
depth other than one (e.g., a <message/> element contained within depth other than one (e.g., a <message/> element contained within
an extension element (Section 8.4) for reporting purposes), nor is an extension element (Section 8.4) for reporting purposes), nor is
a <message/>, <presence/>, or <iq/> element that is qualified by a a <message/>, <presence/>, or <iq/> element that is qualified by a
namespace other than 'jabber:client' or 'jabber:server'. An XML namespace other than 'jabber:client' or 'jabber:server'. An XML
stanza typically contains one or more child elements (with stanza typically contains one or more child elements (with
accompanying attributes, elements, and XML character data) as accompanying attributes, elements, and XML character data) as
necessary in order to convey the desired information, which MAY be necessary in order to convey the desired information, which MAY be
qualified by any XML namespace (see [XML-NAMES] as well as qualified by any XML namespace (see [XML-NAMES] as well as
Section 8.4 in this specification). Section 8.4 in this specification).
There are three kinds of stanzas: message, presence, and IQ (short
for "Info/Query"). These stanza types provide three different
communication primitives: a "push" mechanism for generalized
messaging, a specialized "publish-subscribe" mechanism for
broadcasting information about network availability, and a "request-
response" mechanism for more structured exchanges of data (similar to
[HTTP]). Further explanations are provided under Section 8.2.1,
Section 8.2.2, and Section 8.2.3, respectively.
Consider the example of a client's connection to a server. The Consider the example of a client's connection to a server. The
client initiates an XML stream by sending a stream header to the client initiates an XML stream by sending a stream header to the
server, optionally preceded by an XML declaration specifying the XML server, preferably preceded by an XML declaration specifying the XML
version and the character encoding supported (see Section 11.5 and version and the character encoding supported (see Section 11.5 and
Section 11.6). Subject to local policies and service provisioning, Section 11.6). Subject to local policies and service provisioning,
the server then replies with a second XML stream back to the client, the server then replies with a second XML stream back to the client,
again optionally preceded by an XML declaration. Once the client has again preferably preceded by an XML declaration. Once the client has
completed SASL negotiation (Section 6) and resource binding completed SASL negotiation (Section 6) and resource binding
(Section 7), the client can send an unbounded number of XML stanzas (Section 7), the client can send an unbounded number of XML stanzas
over the stream. When the client desires to close the stream, it over the stream. When the client desires to close the stream, it
simply sends a closing </stream> tag to the server as further simply sends a closing </stream> tag to the server as further
described under Section 4.4. described under Section 4.4.
In essence, then, one XML stream functions as an envelope for the XML In essence, then, one XML stream functions as an envelope for the XML
stanzas sent during a session and another XML stream functions as an stanzas sent during a session and another XML stream functions as an
envelope for the XML stanzas received during a session. We can envelope for the XML stanzas received during a session. We can
represent this in a simplistic fashion as follows. represent this in a simplistic fashion as follows.
skipping to change at page 22, line 44 skipping to change at page 22, line 44
| </stream> | | | </stream> | |
|--------------------|--------------------| |--------------------|--------------------|
| | </stream> | | | </stream> |
+--------------------+--------------------+ +--------------------+--------------------+
Figure 2: A Simplistic View of Two Streams Figure 2: A Simplistic View of Two Streams
Those who are accustomed to thinking of XML in a document-centric Those who are accustomed to thinking of XML in a document-centric
manner might find the following analogies useful: manner might find the following analogies useful:
o The two XML streams are like two "documents" (matching production o The two XML streams are like two "documents" (matching the
[1] content of [XML]) that are built up through the accumulation "document" production from [XML]) that are built up through the
of XML stanzas. accumulation of XML stanzas.
o The root <stream/> element is like the "document entity" for each o The root <stream/> element is like the "document entity" for each
"document" (as described in Section 4.8 of [XML]). "document" (as described in Section 4.8 of [XML]).
o The XML stanzas sent over the streams are like "fragments" of the o The XML stanzas sent over the streams are like "fragments" of the
"documents" (as described in [XML-FRAG]). "documents" (as described in [XML-FRAG]).
However, these analogies are merely that, because XMPP does not deal However, these descriptions are merely analogies, because XMPP does
in documents and fragments but in streams and stanzas. not deal in documents and fragments but in streams and stanzas.
The remainder of this section defines the following aspects of XML The remainder of this section defines the following aspects of XML
streams: streams (along with related topics):
o The stream negotation process o How to open a stream (Section 4.2)
o How to close a stream o The stream negotation process (Section 4.3)
o How to handle peers that are silent o How to close a stream (Section 4.4)
o The XML attributes of a stream o The directionality of XML streams (Section 4.5)
o The XML namespaces of a stream o How to handle peers that are silent (Section 4.6)
o The XML attributes of a stream (Section 4.7)
o The XML namespaces of a stream (Section 4.8)
o Error handling related to XML streams (Section 4.9)
4.2. Stream Negotiation 4.2. Opening a Stream
4.2.1. Basic Concepts After connecting to the appropriate IP address and port of the
receiving entity, the initiating entity opens a stream by sending a
stream header (the "initial stream header") to the receiving entity.
I: <?xml version='1.0'?>
<stream:stream
from='juliet@im.example.com'
to='im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
The receiving entity then replies by sending a stream header of its
own (the "response stream header") to the initiating entity.
R: <?xml version='1.0'?>
<stream:stream
from='im.example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
The entities can then proceed with the remainder of the stream
negotiation process.
4.3. Stream Negotiation
4.3.1. Basic Concepts
Because the receiving entity for a stream acts as a gatekeeper to the Because the receiving entity for a stream acts as a gatekeeper to the
domains it services, it imposes certain conditions for connecting as domains it services, it imposes certain conditions for connecting as
a client or as a peer server. At a minimum, the initiating entity a client or as a peer server. At a minimum, the initiating entity
needs to authenticate with the receiving entity before it is allowed needs to authenticate with the receiving entity before it is allowed
to send stanzas to the receiving entity, typically using SASL as to send stanzas to the receiving entity, typically using SASL as
described under Section 6. However, the receiving entity can described under Section 6. However, the receiving entity can
consider conditions other than authentication to be mandatory, such consider conditions other than authentication to be mandatory-to-
as encryption using TLS as described under Section 5. The receiving negotiate, such as encryption using TLS as described under Section 5.
entity informs the initiating entity about such conditions by The receiving entity informs the initiating entity about such
communicating "stream features": the set of particular protocol conditions by communicating "stream features": the set of particular
interactions that are mandatory for the initiating entity to complete protocol interactions that the initiating entity needs to complete
before the receiving entity will accept XML stanzas from the before the receiving entity will accept XML stanzas from the
initiating entity (e.g., authentication), as well as any protocol initiating entity, as well as any protocol interactions that are
interactions that are voluntary but that might improve the handling voluntary-to-negotiate but that might improve the handling of an XML
of an XML stream (e.g., establishment of application-layer stream (e.g., establishment of application-layer compression as
compression as described in [XEP-0138]). described in [XEP-0138]).
The existence of conditions for connecting implies that streams need The existence of conditions for connecting implies that streams need
to be negotiated. The order of layers (TCP, then TLS, then SASL, to be negotiated. The order of layers (TCP, then TLS, then SASL,
then XMPP; see Section 13.3) implies that stream negotiation is a then XMPP as described under Section 13.3) implies that stream
multi-stage process. Further structure is imposed by two factors: negotiation is a multi-stage process. Further structure is imposed
(1) a given stream feature might be offered only to certain entities by two factors: (1) a given stream feature might be offered only to
or only after certain other features have been negotiated (e.g., certain entities or only after certain other features have been
resource binding is offered only after SASL authentication), and (2) negotiated (e.g., resource binding is offered only after SASL
stream features can be either mandatory-to-negotiate or voluntary-to- authentication), and (2) stream features can be either mandatory-to-
negotiate. Finally, for security reasons the parties to a stream negotiate or voluntary-to-negotiate. Finally, for security reasons
need to discard knowledge that they gained during the negotiation the parties to a stream need to discard knowledge that they gained
process after successfully completing the protocol interactions during the negotiation process after successfully completing the
defined for certain features (e.g., TLS in all cases and SASL in the protocol interactions defined for certain features (e.g., TLS in all
case when a security layer might be established, as defined in the cases and SASL in the case when a security layer might be
specification for the relevant SASL mechanism); this is done by established, as defined in the specification for the relevant SASL
flushing the old stream context and exchanging new stream headers mechanism); this is done by flushing the old stream context and
over the existing TCP connection. exchanging new stream headers over the existing TCP connection.
4.2.2. Stream Features Format 4.3.2. Stream Features Format
If the initiating entity includes the 'version' attribute set to a If the initiating entity includes in the initial stream header the
value of at least "1.0" in the initial stream header, after sending 'version' attribute set to a value of at least "1.0" (see
the response stream header the receiving entity MUST send a Section 4.7.5), after sending the response stream header the
<features/> child element (prefixed by the stream namespace prefix) receiving entity MUST send a <features/> child element (typically
to the initiating entity in order to announce any conditions for prefixed by the stream namespace prefix as described under
continuation of the stream negotiation process. Each condition takes Section 4.8.5) to the initiating entity in order to announce any
the form of a child element of the <features/> element, qualified by conditions for continuation of the stream negotiation process. Each
a namespace that is different from the stream namespace and the condition takes the form of a child element of the <features/>
content namespace. The <features/> element can contain one child, element, qualified by a namespace that is different from the stream
contain multiple children, or be empty. namespace and the content namespace. The <features/> element can
contain one child, contain multiple children, or be empty.
Implementation Note: The order of child elements contained in any Implementation Note: The order of child elements contained in any
given <features/> element is not significant. given <features/> element is not significant.
If a particular stream feature is or can be mandatory-to-negotiate, If a particular stream feature is or can be mandatory-to-negotiate,
the definition of that feature needs to do one of the following: the definition of that feature needs to do one of the following:
1. Declare that the feature is always mandatory-to-negotiate (e.g., 1. Declare that the feature is always mandatory-to-negotiate (e.g.,
this is true of resource binding for XMPP clients); or this is true of resource binding for XMPP clients); or
2. Specify a way for the receiving entity to flag the feature as 2. Specify a way for the receiving entity to flag the feature as
mandatory-to-negotiate for this interaction (e.g., this is done mandatory-to-negotiate for this interaction (e.g., for STARTTLS,
for TLS by including an empty <required/> element in the this is done by including an empty <required/> element in the
advertisement for that stream feature); it is RECOMMENDED that advertisement for that stream feature, but that is not a generic
stream feature definitions for mandatory-to-negotiate features do format for all stream features); it is RECOMMENDED that stream
so by including an empty <required/> element as is done for TLS. feature definitions for new mandatory-to-negotiate features do so
by including an empty <required/> element as is done for
STARTTLS.
Informational Note: Because there is no generic format for Informational Note: Because there is no generic format for
indicating that a feature is mandatory-to-negotiate, it is indicating that a feature is mandatory-to-negotiate, it is
possible that a feature which is not understood by the initiating possible that a feature which is not understood by the initiating
entity might be considered mandatory-to-negotiate by the receiving entity might be considered mandatory-to-negotiate by the receiving
entity, resulting in failure of the stream negotiation process. entity, resulting in failure of the stream negotiation process.
Although such an outcome would be undesirable, the working group Although such an outcome would be undesirable, the working group
deemed it rare enough that a generic format was not needed. deemed it rare enough that a generic format was not needed.
For security reasons, certain stream features necessitate the For security reasons, certain stream features necessitate the
initiating entity to send a new initial stream header upon successful initiating entity to send a new initial stream header upon successful
negotiation of the feature (e.g., TLS in all cases and SASL in the negotiation of the feature (e.g., TLS in all cases and SASL in the
case when a security layer might be established). If this is true of case when a security layer might be established). If this is true of
a given stream feature, the definition of that feature needs to a given stream feature, the definition of that feature needs to
declare that a stream restart is expected after negotiation of the specify that a stream restart is expected after negotiation of the
feature. feature.
A <features/> element that contains at least one mandatory-to- A <features/> element that contains at least one mandatory-to-
negotiate feature indicates that the stream negotiation is not negotiate feature indicates that the stream negotiation is not
complete and that the initiating entity MUST negotiate further complete and that the initiating entity MUST negotiate further
features. features.
R: <stream:features> R: <stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'> <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<required/> <required/>
</starttls> </starttls>
</stream:features> </stream:features>
A <features/> element MAY contain more than one mandatory feature. A <features/> element MAY contain more than one mandatory-to-
This means that the initiating entity can choose among the mandatory negotiate feature. This means that the initiating entity can choose
features. For example, perhaps a future technology will perform among the mandatory-to-negotiate features at this stage of the stream
roughly the same function as TLS, so the receiving entity might negotiation process. As an example, perhaps a future technology will
advertise support for both TLS and the future technology. perform roughly the same function as TLS, so the receiving entity
might advertise support for both TLS and the future technology at the
same stage of the stream negotiation process. However, this applies
only at a given stage of the stream negotiation process and does not
apply to features that are mandatory-to-negotiate at different stages
(e.g., the receiving entity would not advertise both STARTTLS and
SASL as mandatory-to-negotiate, or both SASL and resource binding as
mandatory-to-negotiate, because TLS would need to be negotiated
before SASL and because SASL would need to be negotiated before
resource binding).
A <features/> element that contains both mandatory and voluntary A <features/> element that contains both mandatory-to-negotiate and
features indicates that the negotiation is not complete but that the voluntary-to-negotiate features indicates that the negotiation is not
initiating entity MAY complete the voluntary feature(s) before it complete but that the initiating entity MAY complete the voluntary-
attempts to negotiate the mandatory feature(s). to-negotiate feature(s) before it attempts to negotiate the
mandatory-to-negotiate feature(s).
R: <stream:features> R: <stream:features>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/> <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
<compression xmlns='http://jabber.org/features/compress'> <compression xmlns='http://jabber.org/features/compress'>
<method>zlib</method> <method>zlib</method>
<method>lzw</method> <method>lzw</method>
</compression> </compression>
</stream:features> </stream:features>
A <features/> element that contains only voluntary features indicates A <features/> element that contains only voluntary-to-negotiate
that the stream negotiation is complete and that the initiating features indicates that the stream negotiation is complete and that
entity is cleared to send XML stanzas, but that the initiating entity the initiating entity is cleared to send XML stanzas, but that the
MAY negotiate further features if desired. initiating entity MAY negotiate further features if desired.
R: <stream:features> R: <stream:features>
<compression xmlns='http://jabber.org/features/compress'> <compression xmlns='http://jabber.org/features/compress'>
<method>zlib</method> <method>zlib</method>
<method>lzw</method> <method>lzw</method>
</compression> </compression>
</stream:features> </stream:features>
An empty <features/> element indicates that the stream negotiation is An empty <features/> element indicates that the stream negotiation is
complete and that the initiating entity is cleared to send XML complete and that the initiating entity is cleared to send XML
stanzas. stanzas.
R: <stream:features/> R: <stream:features/>
4.2.3. Restarts 4.3.3. Restarts
On successful negotiation of a feature that necessitates a stream On successful negotiation of a feature that necessitates a stream
restart, both parties MUST consider the previous stream to be restart, both parties MUST consider the previous stream to be
replaced but MUST NOT terminate the underlying TCP connection; replaced but MUST NOT send a closing </stream> tag and MUST NOT
instead, the parties MUST reuse the existing connection, which might terminate the underlying TCP connection; instead, the parties MUST
be in a new state (e.g., encrypted as a result of TLS negotiation). reuse the existing connection, which might be in a new state (e.g.,
The initiating entity then MUST send a new initial stream header, encrypted as a result of TLS negotiation). The initiating entity
which SHOULD be preceded by an XML declaration as described under then MUST send a new initial stream header, which SHOULD be preceded
Section 11.5. When the receiving entity receives the new initial by an XML declaration as described under Section 11.5. When the
stream header, it MUST generate a new stream ID (instead of re-using receiving entity receives the new initial stream header, it MUST
the old stream ID) before sending a new response stream header (which generate a new stream ID (instead of re-using the old stream ID)
SHOULD be preceded by an XML declaration as described under before sending a new response stream header (which SHOULD be preceded
Section 11.5). by an XML declaration as described under Section 11.5).
4.2.4. Resending Features 4.3.4. Resending Features
The receiving entity MUST send an updated list of stream features to The receiving entity MUST send an updated list of stream features to
the initiating entity after a stream restart, and MAY do so after the initiating entity after a stream restart. The list of updated
completing negotiation of a stream feature that does not require a features MAY be empty if there are no further features to be
stream restart. The list of updated features MAY be empty if there advertised or MAY include any combination of features.
are no further features to be advertised or MAY include any
combination of features.
4.2.5. Completion of Stream Negotiation 4.3.5. Completion of Stream Negotiation
The receiving entity indicates completion of the stream negotiation The receiving entity indicates completion of the stream negotiation
process by sending to the initiating entity either an empty process by sending to the initiating entity either an empty
<features/> element or a <features/> element that contains only <features/> element or a <features/> element that contains only
voluntary features. After doing so, the receiving entity MAY send an voluntary-to-negotiate features. After doing so, the receiving
empty <features/> element (e.g., after negotiation of such voluntary entity MAY send an empty <features/> element (e.g., after negotiation
features) but MUST NOT send additional stream features to the of such voluntary-to-negotiate features) but MUST NOT send additional
initiating entity (if the receiving entity has new features to offer, stream features to the initiating entity (if the receiving entity has
preferably limited to mandatory-to-negotiate or security-critical new features to offer, preferably limited to mandatory-to-negotiate
features, it can simply close the stream using a <reset/> stream or security-critical features, it can simply close the stream using a
error and then advertise the new features when the initiating entity <reset/> stream error and then advertise the new features when the
reconnects, preferably closing existing streams in a staggered way so initiating entity reconnects, preferably closing existing streams in
that not all of the initiating entities reconnect at once). Once a staggered way so that not all of the initiating entities reconnect
stream negotiation is complete, the initiating entity is cleared to at once). Once stream negotiation is complete, the initiating entity
send XML stanzas over the stream for as long as the stream is is cleared to send XML stanzas over the stream for as long as the
maintained by both parties. stream is maintained by both parties.
Informational Note: Resource binding as specified under Section 7 Informational Note: Resource binding as specified under Section 7
is an historical exception to the foregoing rule, since it is is an historical exception to the foregoing rule, since it is
mandatory-to-negotiate for clients but uses XML stanzas for mandatory-to-negotiate for clients but uses XML stanzas for
negotiation purposes. negotiation purposes.
The initiating entity MUST NOT attempt to send XML stanzas The initiating entity MUST NOT attempt to send XML stanzas
(Section 8) to entities other than itself (i.e., the client's (Section 8) to entities other than itself (i.e., the client's
connected resource or any other authenticated resource of the connected resource or any other authenticated resource of the
client's account) or the server to which it is connected until stream client's account) or the server to which it is connected until stream
negotiation has been completed. Even if the initiating entity does negotiation has been completed. Even if the initiating entity does
attempt to do so, the receiving entity MUST NOT accept such stanzas attempt to do so, the receiving entity MUST NOT accept such stanzas
and MUST return a <not-authorized/> stream error. This rule applies and MUST return a <not-authorized/> stream error. This rule applies
to XML stanzas only (i.e., <message/>, <presence/>, and <iq/> to XML stanzas only (i.e., <message/>, <presence/>, and <iq/>
elements qualified by the content namespace) and not to XML elements elements qualified by the content namespace) and not to XML elements
used for stream negotiation (e.g., elements used to complete TLS used for stream negotiation (e.g., elements used to complete TLS
negotiation (Section 5) or SASL negotiation (Section 6)). negotiation (Section 5) or SASL negotiation (Section 6)).
4.2.6. Determination of Addresses 4.3.6. Determination of Addresses
After the parties to an XML stream have completed the appropriate After the parties to an XML stream have completed the appropriate
aspects of stream negotiation (typically SASL negotiation (Section 6) aspects of stream negotiation (typically SASL negotiation (Section 6)
and, for client-to-server streams, resource binding (Section 7)) the and, for client-to-server streams, resource binding (Section 7)) the
receiving entity for a stream MUST determine the initiating entity's receiving entity for a stream MUST determine the initiating entity's
JID. JID.
For client-to-server communication, the client's bare JID For client-to-server communication, the client's bare JID
(<localpart@domainpart>) MUST be the authorization identity (as (<localpart@domainpart>) MUST be the authorization identity (as
defined by [SASL]), either (1) as directly communicated by the client defined by [SASL]), either (1) as directly communicated by the client
skipping to change at page 27, line 41 skipping to change at page 28, line 39
client MUST NOT attempt to guess at its JID but instead MUST consider client MUST NOT attempt to guess at its JID but instead MUST consider
its JID to be whatever the server returns to it during resource its JID to be whatever the server returns to it during resource
binding. The server MUST ensure that the resulting JID (including binding. The server MUST ensure that the resulting JID (including
localpart, domainpart, resourcepart, and separator characters) localpart, domainpart, resourcepart, and separator characters)
conforms to the canonical format for XMPP addresses defined in conforms to the canonical format for XMPP addresses defined in
[XMPP-ADDR]; to meet this restriction, the server MAY replace the JID [XMPP-ADDR]; to meet this restriction, the server MAY replace the JID
sent by the client with the canonicalized JID as determined by the sent by the client with the canonicalized JID as determined by the
server and communicate that JID to the client during resource server and communicate that JID to the client during resource
binding. binding.
For server-to-server communication, the initiating server's JID For server-to-server communication, the initiating server's bare JID
(<domainpart>) MUST be the authorization identity (as defined by (<domainpart>) MUST be the authorization identity (as defined by
[SASL]), either (1) as directly communicated by the initiating server [SASL]), either (1) as directly communicated by the initiating server
during SASL negotiation (Section 6) or (2) as derived by the during SASL negotiation (Section 6) or (2) as derived by the
receiving server from the authentication identity if no authorization receiving server from the authentication identity if no authorization
identity was specified during SASL negotiation; in the absence of identity was specified during SASL negotiation; in the absence of
SASL negotiation, the receiving server MAY consider the authorization SASL negotiation, the receiving server MAY consider the authorization
identity to be an identity negotiated within the relevant identity to be an identity negotiated within the relevant
verification protocol (e.g., the 'from' attribute of the <result/> verification protocol (e.g., the 'from' attribute of the <result/>
element in Server Dialback [XEP-0220]). element in Server Dialback [XEP-0220]).
Security Note: Because it is possible for a third party to tamper Security Warning: Because it is possible for a third party to
with information that is sent over the stream before a security tamper with information that is sent over the stream before a
layer such as TLS is successfully negotiated, it is advisable for security layer such as TLS is successfully negotiated, it is
the receiving server to treat any such unprotected information advisable for the receiving server to treat any such unprotected
with caution. information with caution; this applies especially to the 'from'
and 'to' addresses on the first initial stream header sent by the
initiating entity.
4.2.7. Flow Chart 4.3.7. Flow Chart
We summarize the foregoing rules in the following non-normative flow We summarize the foregoing rules in the following non-normative flow
chart for the stream negotiation process, presented from the chart for the stream negotiation process, presented from the
perspective of the initiating entity. perspective of the initiating entity.
+------------+ +---------------------+
| open TCP | | open TCP connection |
| connection | +---------------------+
+------------+
| |
v v
+---------------+ +---------------+
| send initial |<-------------------------+ | send initial |<-------------------------+
| stream header | ^ | stream header | ^
+---------------+ | +---------------+ |
| | | |
v | v |
+------------------+ | +------------------+ |
| receive response | | | receive response | |
| stream header | | | stream header | |
+------------------+ | +------------------+ |
| | | |
v | v |
+----------------+ | +----------------+ |
| receive stream | | | receive stream | |
+------------------>| features | | +------------------>| features | |
^ +----------------+ | ^ {OPTIONAL} +----------------+ |
| | | | | |
| v | | v |
| +<-----------------+ | | +<-----------------+ |
| | | | | |
| {empty?} ----> {all voluntary?} ----> {some mandatory?} | | {empty?} ----> {all voluntary?} ----> {some mandatory?} |
| | no | no | | | | no | no | |
| | yes | yes | yes | | | yes | yes | yes |
| | v v | | | v v |
| | +---------------+ +----------------+ | | | +---------------+ +----------------+ |
| | | MAY negotiate | | MUST negotiate | | | | | MAY negotiate | | MUST negotiate | |
| | | any or none | | one feature | | | | | any or none | | one feature | |
| | +---------------+ +----------------+ | | | +---------------+ +----------------+ |
| | | | | | v | | |
| v v | | | +---------+ v | |
| +----------+ +-----------+ | | | | DONE |<----- {negotiate?} | |
| | process |<-----| negotiate | | | | +---------+ no | | |
| | complete | no | a feature | | |
| +----------+ +-----------+ | |
| | | |
| yes | | | | yes | | |
| v v | | v v |
| +--------->+<---------+ | | +--------->+<---------+ |
| | | | | |
| v | | v |
+<-------------------------- {restart mandatory?} ------------>+ +<-------------------------- {restart mandatory?} ------------>+
no yes no yes
Figure 3: Stream Negotiation Flow Chart Figure 3: Stream Negotiation Flow Chart
4.3. Directionality 4.4. Closing a Stream
An XML stream from one entity to another can be closed at any time,
either because a specific stream error has occurred or in the absence
of an error (e.g., when a client simply ends its session).
A stream is closed by sending a closing </stream> tag.
E: </stream:stream>
If the parties are using either two streams over a single TCP
connection or two streams over two TCP connections, the entity that
sends the closing stream tag MUST behave as follows:
1. Wait for the other party to also close its outbound stream before
terminating the underlying TCP connection(s); this gives the
other party an opportunity to finish transmitting any outbound
data to the closing entity before the TCP connection(s) is
terminated.
2. Refrain from sending any further data over its outbound stream to
the other entity, but continue to process data received from the
other entity (and, if necessary, process such data).
3. Consider both streams to be void if the other party does not send
its closing stream tag within a reasonable amount of time (where
the definition of "reasonable" is a matter of implementation or
deployment).
4. After receiving a reciprocal closing stream tag from the other
party or waiting a reasonable amount of time with no response,
terminate the underlying TCP connection(s).
Security Warning: In accordance with Section 7.2.1 of [TLS], to
help prevent a truncation attack the party that is closing the
stream MUST send a TLS close_notify alert and MUST receive a
responding close_notify alert from the other party before
terminating the underlying TCP connection(s).
If the parties are using multiple streams over multiple TCP
connections, there is no defined pairing of streams and therefore the
behavior is a matter for implementation.
4.5. Directionality
An XML stream is always unidirectional, by which is meant that XML An XML stream is always unidirectional, by which is meant that XML
stanzas can be sent in only one direction over the stream (either stanzas can be sent in only one direction over the stream (either
from the initiating entity to the receiving entity or from the from the initiating entity to the receiving entity or from the
receiving entity to the initiating entity). receiving entity to the initiating entity).
Depending on the type of session that has been negotiated and the Depending on the type of session that has been negotiated and the
nature of the entities involved, the entities might use: nature of the entities involved, the entities might use:
o Two streams over a single TCP connection, where the security o Two streams over a single TCP connection, where the security
skipping to change at page 30, line 38 skipping to change at page 32, line 31
server sessions. server sessions.
o Multiple streams over two or more TCP connections, where each o Multiple streams over two or more TCP connections, where each
stream is separately secured. This approach is sometimes used for stream is separately secured. This approach is sometimes used for
server-to-server communication between two large XMPP service server-to-server communication between two large XMPP service
providers; however, this can make it difficult to maintain providers; however, this can make it difficult to maintain
coherence of data received over multiple streams in situations coherence of data received over multiple streams in situations
described under Section 10.1, which is why a server MAY return a described under Section 10.1, which is why a server MAY return a
<conflict> stream error to a remote server that attempts to <conflict> stream error to a remote server that attempts to
negotiate more than one stream (as described under negotiate more than one stream (as described under
Section 4.8.3.3). Section 4.9.3.3).
This concept of directionality applies only to stanzas and explicitly This concept of directionality applies only to stanzas and explicitly
does not apply to first-level children of the stream root that are does not apply to first-level children of the stream root that are
used to bootstrap or manage the stream (e.g., first-level elements used to bootstrap or manage the stream (e.g., first-level elements
used for TLS negotiation, SASL negotiation, Server Dialback used for TLS negotiation, SASL negotiation, Server Dialback
[XEP-0220], and Stream Management [XEP-0198]). [XEP-0220], and Stream Management [XEP-0198]).
The foregoing considerations imply that while completing STARTTLS The foregoing considerations imply that while completing STARTTLS
negotiation (Section 5) and SASL negotiation (Section 6) two servers negotiation (Section 5) and SASL negotiation (Section 6) two servers
would use one TCP connection, but after the stream negotiation would use one TCP connection, but after the stream negotiation
skipping to change at page 31, line 29 skipping to change at page 33, line 24
server session "bidirectional" and the TCP connection for a server session "bidirectional" and the TCP connection for a
server-to-server session "unidirectional"), strictly speaking a server-to-server session "unidirectional"), strictly speaking a
stream is always unidirectional (because the initiating entity and stream is always unidirectional (because the initiating entity and
receiving entity always have a minimum of two streams, one in each receiving entity always have a minimum of two streams, one in each
direction) and a TCP connection is always bidirectional (because direction) and a TCP connection is always bidirectional (because
TCP traffic can be sent in both directions). Directionality TCP traffic can be sent in both directions). Directionality
applies to the application-layer traffic sent over the TCP applies to the application-layer traffic sent over the TCP
connection, not to the transport-layer traffic sent over the TCP connection, not to the transport-layer traffic sent over the TCP
connection itself. connection itself.
4.4. Closing a Stream 4.6. Handling of Silent Peers
An XML stream between two entities can be closed at any time, either
because a specific stream error has occurred or in the absence of an
error (e.g., when a client simply ends its session).
A stream is closed by sending a closing </stream> tag.
S: </stream:stream>
If the parties are using either two streams over a single TCP
connection or two streams over two TCP connections, the entity that
sends the closing stream tag SHOULD behave as follows:
1. Wait for the other party to also close its stream before
terminating the underlying TCP connection(s); this gives the
other party an opportunity to finish transmitting any data in the
opposite direction before the TCP connection(s) is terminated.
2. Refrain from initiating the sending of further data over that
stream but continue to process data sent by the other entity
(and, if necessary, react to such data).
3. Consider both streams to be void if the other party does not send
its closing stream tag within a reasonable amount of time (where
the definition of "reasonable" is a matter of implementation or
deployment).
4. After receiving a reciprocal closing stream tag from the other
party or waiting a reasonable amount of time with no response,
terminate the underlying TCP connection(s).
Security Note: In accordance with Section 7.2.1 of [TLS], to help
prevent a truncation attack the party that is closing the stream
MUST send a TLS close_notify alert and MUST receive a responding
close_notify alert from the other party before terminating the
underlying TCP connection(s).
If the parties are using multiple streams over multiple TCP
connections, there is no defined pairing of streams and therefore the
behavior is a matter for implementation.
4.5. Handling of Silent Peers
When an entity that is a party to a stream has not received any XMPP When an entity that is a party to a stream has not received any XMPP
traffic from its stream peer for some period of time, the peer might traffic from its stream peer for some period of time, the peer might
appear to be silent. There are several reasons why this might appear to be silent. There are several reasons why this might
happen: happen:
1. The underlying TCP connection is dead. 1. The underlying TCP connection is dead.
2. The XML stream is broken despite the fact that the underlying TCP 2. The XML stream is broken despite the fact that the underlying TCP
connection is alive. connection is alive.
3. The peer is idle and simply has not sent any XMPP traffic over 3. The peer is idle and simply has not sent any XMPP traffic over
its XML stream to the entity. its XML stream to the entity.
These three conditions are best handled separately, as described in These three conditions are best handled separately, as described in
the following sections. the following sections.
Implementation Note: For the purpose of handling silent peers, we Implementation Note: For the purpose of handling silent peers, we
treat a two unidirectional TCP connections as conceptually treat a two unidirectional TCP connections as conceptually
equivalent to a single bidirectional TCP connection (see equivalent to a single bidirectional TCP connection (see
Section 4.3); however, implementers need to be aware that, in the Section 4.5); however, implementers need to be aware that, in the
case of two unidirectional TCP connections, responses to traffic case of two unidirectional TCP connections, responses to traffic
at the XMPP application layer will come back from the peer on the at the XMPP application layer will come back from the peer on the
second TCP connection. In addition, the use of multiple streams second TCP connection. In addition, the use of multiple streams
in each direction (which is a common deployment choice for server- in each direction (which is a somewhat frequent deployment choice
to-server connectivity among large XMPP service providers) further for server-to-server connectivity among large XMPP service
complicates application-level checking of XMPP streams and their providers) further complicates application-level checking of XMPP
underlying TCP connections, because there is no necessary streams and their underlying TCP connections, because there is no
correlation between any given initial stream and any given necessary correlation between any given initial stream and any
response stream. given response stream.
4.5.1. Dead Connection 4.6.1. Dead Connection
If the underlying TCP connection is dead, stream-level checks (e.g., If the underlying TCP connection is dead, stream-level checks (e.g.,
[XEP-0199] and [XEP-0198]) are ineffective. Therefore it is [XEP-0199] and [XEP-0198]) are ineffective. Therefore it is
unnecessary to close the stream with or without an error, and it is unnecessary to close the stream with or without an error, and it is
appropriate instead to simply terminate the TCP connection. appropriate instead to simply terminate the TCP connection.
One common method for checking the TCP connection is to send a space One common method for checking the TCP connection is to send a space
character (U+0020) between XML stanzas, which is allowed for XML character (U+0020) between XML stanzas, which is allowed for XML
streams as described under Section 11.7; the sending of such a space streams as described under Section 11.7; the sending of such a space
character is properly called a "whitespace keepalive" (the term character is properly called a "whitespace keepalive" (the term
"whitespace ping" is often used, despite the fact that it is not a "whitespace ping" is often used, despite the fact that it is not a
ping since no "pong" is possible). ping since no "pong" is possible). However, this is not allowed
during TLS negotiation or SASL negotiation, as described under
Section 5.3.3 and Section 6.3.5.
4.5.2. Broken Stream 4.6.2. Broken Stream
Even if the underlying TCP connection is alive, the peer might never Even if the underlying TCP connection is alive, the peer might never
respond to XMPP traffic that the entity sends, whether normal stanzas respond to XMPP traffic that the entity sends, whether normal stanzas
or specialized stream-checking traffic such as the application-level or specialized stream-checking traffic such as the application-level
pings defined in [XEP-0199] or the more comprehensive Stream pings defined in [XEP-0199] or the more comprehensive Stream
Management protocol defined in [XEP-0198]. In this case, it is Management protocol defined in [XEP-0198]. In this case, it is
appropriate for the entity to close a broken stream using the appropriate for the entity to close a broken stream using the
<connection-timeout/> stream error described under Section 4.8.3.4. <connection-timeout/> stream error described under Section 4.9.3.4.
4.5.3. Idle Peer 4.6.3. Idle Peer
Even if the underlying TCP connection is alive and the stream is not Even if the underlying TCP connection is alive and the stream is not
broken, the peer might have sent no stanzas for a certain period of broken, the peer might have sent no stanzas for a certain period of
time. In this case, the peer SHOULD close the stream using the time. In this case, the peer itself MAY close the stream (as
handshake described under Section 4.4. If the idle peer does not described under Section 4.4) rather than leaving an unused stream
close the stream, the other party MAY either close the stream using open. If the idle peer does not close the stream, the other party
the handshake described under Section 4.4 or return a stream error MAY either close the stream using the handshake described under
(e.g., <resource-constraint/> if the entity has reached a limit on Section 4.4 or return a stream error (e.g., <resource-constraint/> if
the number of open TCP connections or <policy-violation/> if the the entity has reached a limit on the number of open TCP connections
connection has exceeded a local timeout policy). However, consistent or <policy-violation/> if the connection has exceeded a local timeout
with the order of layers (specified under Section 13.3), the other policy). However, consistent with the order of layers (specified
party is advised to verify that the underlying TCP connection is under Section 13.3), the other party is advised to verify that the
alive and the stream is unbroken (as described above) before underlying TCP connection is alive and the stream is unbroken (as
concluding that the peer is idle. Furthermore, it is preferable to described above) before concluding that the peer is idle.
be liberal in accepting idle peers, since experience has shown that Furthermore, it is preferable to be liberal in accepting idle peers,
doing so improves the reliability of communication over XMPP networks since experience has shown that doing so improves the reliability of
and that it is typically more efficient to maintain a stream between communication over XMPP networks and that it is typically more
two servers than to aggressively timeout such a stream. efficient to maintain a stream between two servers than to
aggressively timeout such a stream.
4.5.4. Use of Checking Methods 4.6.4. Use of Checking Methods
Implementers are advised to support whichever stream-checking and Implementers are advised to support whichever stream-checking and
connection-checking methods they deem appropriate, but to carefully connection-checking methods they deem appropriate, but to carefully
weigh the network impact of such methods against the benefits of weigh the network impact of such methods against the benefits of
discovering broken streams and dead TCP connections in a timely discovering broken streams and dead TCP connections in a timely
manner. The length of time between the use of any particular check manner. The length of time between the use of any particular check
is very much a matter of local service policy and depends strongly on is very much a matter of local service policy and depends strongly on
the network environment and usage scenarios of a given deployment and the network environment and usage scenarios of a given deployment and
connection type; at the time of writing, it is RECOMMENDED that any connection type; at the time of writing, it is RECOMMENDED that any
such check be performed not more than once every 5 minutes and that, such check be performed not more than once every 5 minutes and that,
ideally, such checks will be initiated by clients rather than ideally, such checks will be initiated by clients rather than
servers. Those who implement XMPP software and deploy XMPP services servers. Those who implement XMPP software and deploy XMPP services
are encouraged to seek additional advice regarding appropriate timing are encouraged to seek additional advice regarding appropriate timing
of stream-checking and connection-checking methods, particularly when of stream-checking and connection-checking methods, particularly when
power-constrained devices are being used (e.g., in mobile power-constrained devices are being used (e.g., in mobile
environments). environments).
4.6. Stream Attributes 4.7. Stream Attributes
The attributes of the root <stream/> element are defined in the The attributes of the root <stream/> element are defined in the
following sections. following sections.
Security Note: Until and unless the confidentiality and integrity Security Warning: Until and unless the confidentiality and
of a stream header is ensured via Transport Layer Security as integrity of the stream are ensured via Transport Layer Security
described under Section 5, the attributes provided in a stream as described under Section 5 or an equivalent security layer (such
as the SASL GSSAPI mechanism), the attributes provided in a stream
header could be tampered with by an attacker. header could be tampered with by an attacker.
Implementation Note: The attributes of the root <stream/> element Implementation Note: The attributes of the root <stream/> element
are not prepended by a namespace prefix because, as explained in are not prepended by a namespace prefix because, as explained in
[XML-NAMES], "[d]efault namespace declarations do not apply [XML-NAMES], "[d]efault namespace declarations do not apply
directly to attribute names; the interpretation of unprefixed directly to attribute names; the interpretation of unprefixed
attributes is determined by the element on which they appear." attributes is determined by the element on which they appear."
4.6.1. from 4.7.1. from
The 'from' attribute communicates an XMPP identity of the entity The 'from' attribute communicates an XMPP identity of the entity
sending the stream element. sending the stream element.
Security Warning: Notwithstanding the recommendations in the
remainder of this section, the initiating entity SHOULD NOT
include a 'from' address on the initial stream header it sends
before the confidentiality and integrity of the stream are ensured
via TLS or an equivalent security layer (such as the SASL GSSAPI
mechanism), since doing so would expose the initiating entity's
identity to eavesdroppers.
For initial stream headers in client-to-server communication, if the For initial stream headers in client-to-server communication, if the
client knows the XMPP identity of the principal controlling the client knows the XMPP identity of the principal controlling the
client (typically an account name of the form client (typically an account name of the form
<localpart@domainpart>), then it SHOULD include the 'from' attribute <localpart@domainpart>), then it SHOULD include the 'from' attribute
and set its value to that identity once the stream is in a state in and set its value to that identity once the stream is in a state in
which it is willing to perform authentication, e.g. once TLS has been which it is willing to perform authentication, e.g. once TLS has been
negotiated. However, because the client might not know the XMPP negotiated. However, the client might not know the XMPP identity of
identity of the principal controlling the entity (e.g., because the the principal controlling the entity (e.g., because the XMPP identity
XMPP identity is assigned at a level other than the XMPP application is assigned at a level other than the XMPP application layer, as in
layer, as in the General Security Service Application Program the General Security Service Application Program Interface
Interface [GSS-API]), inclusion of the 'from' address is OPTIONAL. [GSS-API]).
Security Note: Including the XMPP identity before the stream is
protected via TLS can expose that identity to eavesdroppers.
I: <?xml version='1.0'?> I: <?xml version='1.0'?>
<stream:stream <stream:stream
from='juliet@im.example.com' from='juliet@im.example.com'
to='im.example.com' to='im.example.com'
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
For initial stream headers in server-to-server communication, a For initial stream headers in server-to-server communication, a
server MUST include the 'from' attribute and MUST set the value to server MUST include the 'from' attribute and MUST set its value to
the domainpart of the 'from' attribute of the stanza that caused the the domainpart of the 'from' attribute of the stanza that caused the
stream to be established (because the initiating entity might have stream to be established (because the initiating entity might have
more than one XMPP identity, e.g., in the case of a server that more than one XMPP identity, e.g., in the case of a server that
provides virtual hosting, it will need to choose an identity that is provides virtual hosting, it will need to choose an identity that is
associated with this stream). associated with this stream).
I: <?xml version='1.0'?> I: <?xml version='1.0'?>
<stream:stream <stream:stream
from='example.net' from='example.net'
to='im.example.com' to='im.example.com'
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:server' xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
For response stream headers in both client-to-server and server-to- For response stream headers in both client-to-server and server-to-
server communication, the receiving entity MUST include the 'from' server communication, the receiving entity MUST include the 'from'
attribute and MUST set the value to one of the receiving entity's attribute and MUST set its value to one of the receiving entity's
hostnames (which MAY be a hostname other than that specified in the FQDNs (which MAY be an FQDN other than that specified in the 'to'
'to' attribute of the initial stream header; see Section 4.8.1.3 and attribute of the initial stream header, as described under
Section 4.8.3.6). Section 4.9.1.3 and Section 4.9.3.6).
R: <?xml version='1.0'?> R: <?xml version='1.0'?>
<stream:stream <stream:stream
from='im.example.com' from='im.example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y=' id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@im.example.com' to='juliet@im.example.com'
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
Whether or not the 'from' attribute is included, each entity MUST Whether or not the 'from' attribute is included, each entity MUST
verify the identity of the other entity before exchanging XML stanzas verify the identity of the other entity before exchanging XML stanzas
with it, as described under Section 13.5. with it, as described under Section 13.5.
Interoperability Note: It is possible that implementations based Interoperability Note: It is possible that implementations based
on [RFC3920] will not include the 'from' address on stream on [RFC3920] will not include the 'from' address on stream
headers; an entity SHOULD be liberal in accepting such stream headers; an entity SHOULD be liberal in accepting such stream
headers. headers.
4.6.2. to 4.7.2. to
For initial stream headers in both client-to-server and server-to- For initial stream headers in both client-to-server and server-to-
server communication, the initiating entity MUST include the 'to' server communication, the initiating entity MUST include the 'to'
attribute and MUST set its value to a hostname that the initiating attribute and MUST set its value to a domainpart that the initiating
entity knows or expects the receiving entity to service. (The same entity knows or expects the receiving entity to service. (The same
information can be provided in other ways, such as a server name information can be provided in other ways, such as a Server Name
indication during TLS negotiation as described in [TLS-EXT].) Indication during TLS negotiation as described in [TLS-EXT].)
I: <?xml version='1.0'?> I: <?xml version='1.0'?>
<stream:stream <stream:stream
from='juliet@im.example.com' from='juliet@im.example.com'
to='im.example.com' to='im.example.com'
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
skipping to change at page 37, line 4 skipping to change at page 38, line 17
from='im.example.com' from='im.example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y=' id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@im.example.com' to='juliet@im.example.com'
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
For response stream headers in server-to-server communication, the For response stream headers in server-to-server communication, the
receiving entity MUST include a 'to' attribute in the response stream receiving entity MUST include a 'to' attribute in the response stream
header and MUST set its value to the hostname specified in the 'from' header and MUST set its value to the domainpart specified in the
attribute of the initial stream header. 'from' attribute of the initial stream header.
R: <?xml version='1.0'?> R: <?xml version='1.0'?>
<stream:stream <stream:stream
from='im.example.com' from='im.example.com'
id='g4qSvGvBxJ+xeAd7QKezOQJFFlw=' id='g4qSvGvBxJ+xeAd7QKezOQJFFlw='
to='example.net' to='example.net'
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:server' xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
Whether or not the 'to' attribute is included, each entity MUST Whether or not the 'to' attribute is included, each entity MUST
verify the identity of the other entity before exchanging XML stanzas verify the identity of the other entity before exchanging XML stanzas
with it, as described under Section 13.5. with it, as described under Section 13.5.
Interoperability Note: It is possible that implementations based Interoperability Note: It is possible that implementations based
on [RFC3920] will not include the 'to' address on stream headers; on [RFC3920] will not include the 'to' address on stream headers;
an entity SHOULD be liberal in accepting such stream headers. an entity SHOULD be liberal in accepting such stream headers.
4.6.3. id 4.7.3. id
The 'id' attribute communicates a unique identifier for the stream, The 'id' attribute communicates a unique identifier for the stream,
called a "stream ID". The stream ID MUST be generated by the called a "stream ID". The stream ID MUST be generated by the
receiving entity when it sends a response stream header and MUST BE receiving entity when it sends a response stream header and MUST BE
unique within the receiving application (normally a server). unique within the receiving application (normally a server).
Security Note: The stream ID MUST be both unpredictable and non- Security Warning: The stream ID MUST be both unpredictable and
repeating because it can be security-critical when re-used by an non-repeating because it can be security-critical when re-used by
authentication mechanisms, as is the case for Server Dialback an authentication mechanisms, as is the case for Server Dialback
[XEP-0220] and the "XMPP 0.9" authentication mechanism used before [XEP-0220] and the "XMPP 0.9" authentication mechanism used before
RFC 3920 defined the use of SASL in XMPP; for recommendations RFC 3920 defined the use of SASL in XMPP; for recommendations
regarding randomness for security purposes, see [RANDOM]. regarding randomness for security purposes, see [RANDOM].
For initial stream headers, the initiating entity MUST NOT include For initial stream headers, the initiating entity MUST NOT include
the 'id' attribute; however, if the 'id' attribute is included, the the 'id' attribute; however, if the 'id' attribute is included, the
receiving entity MUST ignore it. receiving entity MUST ignore it.
For response stream headers, the receiving entity MUST include the For response stream headers, the receiving entity MUST include the
'id' attribute. 'id' attribute.
skipping to change at page 38, line 19 skipping to change at page 39, line 24
to='juliet@im.example.com' to='juliet@im.example.com'
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
Interoperability Note: In RFC 3920, the text regarding inclusion Interoperability Note: In RFC 3920, the text regarding inclusion
of the 'id' attribute was ambiguous, leading some implementations of the 'id' attribute was ambiguous, leading some implementations
to leave the attribute off the response stream header. to leave the attribute off the response stream header.
4.6.4. xml:lang 4.7.4. xml:lang
The 'xml:lang' attribute communicates an entity's preferred or The 'xml:lang' attribute communicates an entity's preferred or
default language for any human-readable XML character data to be sent default language for any human-readable XML character data to be sent
over the stream (an XML stanza can also possess an 'xml:lang' over the stream (an XML stanza can also possess an 'xml:lang'
attribute, as discussed under Section 8.1.5). The syntax of this attribute, as discussed under Section 8.1.5). The syntax of this
attribute is defined in Section 2.12 of [XML]; in particular, the attribute is defined in Section 2.12 of [XML]; in particular, the
value of the 'xml:lang' attribute MUST conform to the NMTOKEN 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 datatype (as defined in Section 2.3 of [XML]) and MUST conform to the
language identifier format defined in [LANGTAGS]. language identifier format defined in [LANGTAGS].
skipping to change at page 39, line 5 skipping to change at page 40, line 13
'xml:lang' attribute. The following rules apply: 'xml:lang' attribute. The following rules apply:
o If the initiating entity included an 'xml:lang' attribute in its o If the initiating entity included an 'xml:lang' attribute in its
initial stream header and the receiving entity supports that initial stream header and the receiving entity supports that
language in the human-readable XML character data that it language in the human-readable XML character data that it
generates and sends to the initiating entity (e.g., in the <text/> generates and sends to the initiating entity (e.g., in the <text/>
element for stream and stanza errors), the value of the 'xml:lang' element for stream and stanza errors), the value of the 'xml:lang'
attribute MUST be the identifier for the initiating entity's attribute MUST be the identifier for the initiating entity's
preferred language (e.g., "de-CH"). preferred language (e.g., "de-CH").
o If the receiving entity supports a language that closely matches o If the receiving entity supports a language that matches the
the initiating entity's preferred language (e.g., "de" instead of initiating entity's preferred language according to the "lookup
"de-CH"), then the value of the 'xml:lang' attribute SHOULD be the scheme" specified in Section 3.4 of [LANGMATCH] (e.g., "de"
identifier for the matching language (e.g., "de") but MAY be the instead of "de-CH"), then the value of the 'xml:lang' attribute
identifier for the default language of the receiving entity (e.g., SHOULD be the identifier for the matching language.
"en").
o If the receiving entity does not support the initiating entity's o If the receiving entity does not support the initiating entity's
preferred language or a closely matching language (or if the preferred language or a matching language according to the lookup
initiating entity did not include the 'xml:lang' attribute in its scheme (or if the initiating entity did not include the 'xml:lang'
initial stream header), then the value of the 'xml:lang' attribute attribute in its initial stream header), then the value of the
MUST be the identifier for the default language of the receiving 'xml:lang' attribute MUST be the identifier for the default
entity (e.g., "en"). language of the receiving entity (e.g., "en").
R: <?xml version='1.0'?> R: <?xml version='1.0'?>
<stream:stream <stream:stream
from='im.example.com' from='im.example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y=' id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@im.example.com' to='juliet@im.example.com'
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
skipping to change at page 39, line 44 skipping to change at page 41, line 5
include the 'xml:lang' attribute in any such stanza, the receiving include the 'xml:lang' attribute in any such stanza, the receiving
entity SHOULD add the 'xml:lang' attribute to the stanza, where the entity SHOULD add the 'xml:lang' attribute to the stanza, where the
value of the attribute MUST be the identifier for the language value of the attribute MUST be the identifier for the language
preferred by the initiating entity (even if the receiving entity does preferred by the initiating entity (even if the receiving entity does
not support that language for human-readable XML character data it not support that language for human-readable XML character data it
generates and sends to the initiating entity, such as in stream or generates and sends to the initiating entity, such as in stream or
stanza errors). If the initiating entity includes the 'xml:lang' stanza errors). If the initiating entity includes the 'xml:lang'
attribute in any such stanza, the receiving entity MUST NOT modify or attribute in any such stanza, the receiving entity MUST NOT modify or
delete it. delete it.
4.6.5. version 4.7.5. version
The inclusion of the version attribute set to a value of at least The inclusion of the version attribute set to a value of at least
"1.0" signals support for the stream-related protocols defined in "1.0" signals support for the stream-related protocols defined in
this specification, including TLS negotiation (Section 5), SASL this specification, including TLS negotiation (Section 5), SASL
negotiation (Section 6), stream features (Section 4.2.2), and stream negotiation (Section 6), stream features (Section 4.3.2), and stream
errors (Section 4.8). errors (Section 4.9).
The version of XMPP specified in this specification is "1.0"; in The version of XMPP specified in this specification is "1.0"; in
particular, XMPP 1.0 encapsulates the stream-related protocols as particular, XMPP 1.0 encapsulates the stream-related protocols as
well as the basic semantics of the three defined XML stanza types well as the basic semantics of the three defined XML stanza types
(<message/>, <presence/>, and <iq/>). (<message/>, <presence/>, and <iq/> as described under Section 8.2.1,
Section 8.2.2, and Section 8.2.3, respectively).
The numbering scheme for XMPP versions is "<major>.<minor>". The The numbering scheme for XMPP versions is "<major>.<minor>". The
major and minor numbers MUST be treated as separate integers and each major and minor numbers MUST be treated as separate integers and each
number MAY be incremented higher than a single digit. Thus, "XMPP 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 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 be lower than "XMPP 12.3". Leading zeros (e.g., "XMPP 6.01") MUST be
ignored by recipients and MUST NOT be sent. ignored by recipients and MUST NOT be sent.
The major version number will be incremented only if the stream and The major version number will be incremented only if the stream and
stanza formats or obligatory actions have changed so dramatically stanza formats or obligatory actions have changed so dramatically
skipping to change at page 41, line 13 skipping to change at page 42, line 25
in the initial stream header and newer version entities cannot in the initial stream header and newer version entities cannot
interoperate with older version entities as described, the interoperate with older version entities as described, the
initiating entity SHOULD generate an <unsupported-version/> initiating entity SHOULD generate an <unsupported-version/>
stream error. stream error.
4. If either entity receives a stream header with no 'version' 4. If either entity receives a stream header with no 'version'
attribute, the entity MUST consider the version supported by the attribute, the entity MUST consider the version supported by the
other entity to be "0.9" and SHOULD NOT include a 'version' other entity to be "0.9" and SHOULD NOT include a 'version'
attribute in the response stream header. attribute in the response stream header.
4.6.6. Summary of Stream Attributes 4.7.6. Summary of Stream Attributes
The following table summarizes the attributes of the root <stream/> The following table summarizes the attributes of the root <stream/>
element. element.
+----------+--------------------------+-------------------------+ +----------+--------------------------+-------------------------+
| | initiating to receiving | receiving to initiating | | | initiating to receiving | receiving to initiating |
+----------+--------------------------+-------------------------+ +----------+--------------------------+-------------------------+
| to | JID of receiver | JID of initiator | | to | JID of receiver | JID of initiator |
| from | JID of initiator | JID of receiver | | from | JID of initiator | JID of receiver |
| id | ignored | stream identifier | | id | ignored | stream identifier |
| xml:lang | default language | default language | | xml:lang | default language | default language |
| version | XMPP 1.0+ supported | XMPP 1.0+ supported | | version | XMPP 1.0+ supported | XMPP 1.0+ supported |
+----------+--------------------------+-------------------------+ +----------+--------------------------+-------------------------+
Figure 4: Stream Attributes Figure 4: Stream Attributes
4.7. XML Namespaces 4.8. XML Namespaces
Readers are referred to the specification of XML namespaces Readers are referred to the specification of XML namespaces
[XML-NAMES] for a full understanding of the concepts used in this [XML-NAMES] for a full understanding of the concepts used in this
section, especially the concept of a "default namespace" as provided section, especially the concept of a "default namespace" as provided
in Section 3 and Section 6.2 of that specification. in Section 3 and Section 6.2 of that specification.
4.7.1. Stream Namespace 4.8.1. Stream Namespace
The root <stream/> element ("stream header") MUST be qualified by the The root <stream/> element ("stream header") MUST be qualified by the
namespace 'http://etherx.jabber.org/streams' (the "stream namespace 'http://etherx.jabber.org/streams' (the "stream
namespace"). If this rule is violated, the entity that receives the namespace"). If this rule is violated, the entity that receives the
offending stream header MUST return a stream error to the sending offending stream header MUST return a stream error to the sending
entity, which SHOULD be <invalid-namespace/> (although some existing entity, which SHOULD be <invalid-namespace/> (although some existing
implementations send <bad-format/> instead). implementations send <bad-format/> instead).
4.7.2. Content Namespace 4.8.2. Content Namespace
An entity MAY declare a "content namespace" as the default namespace An entity MAY declare a "content namespace" as the default namespace
for data sent over the stream (i.e., data other than elements for data sent over the stream (i.e., data other than elements
qualified by the stream namespace). If so, (1) the content namespace qualified by the stream namespace). If so, (1) the content namespace
MUST be other than the stream namespace, and (2) the content MUST be other than the stream namespace, and (2) the content
namespace MUST be the same for the initial stream and the response namespace MUST be the same for the initial stream and the response
stream so that both streams are qualified consistently. The content stream so that both streams are qualified consistently. The content
namespace applies to all first-level child elements sent over the namespace applies to all first-level child elements sent over the
stream unless explicitly qualified by another namespace (i.e., the stream unless explicitly qualified by another namespace (i.e., the
content namespace is the default namespace). content namespace is the default namespace).
skipping to change at page 42, line 44 skipping to change at page 44, line 14
<stream <stream
from='juliet@im.example.com' from='juliet@im.example.com'
to='im.example.com' to='im.example.com'
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='http://etherx.jabber.org/streams'> xmlns='http://etherx.jabber.org/streams'>
<message xmlns='jabber:client'> <message xmlns='jabber:client'>
<body>foo</body> <body>foo</body>
</message> </message>
</stream:stream> </stream>
Historically, most XMPP implementations have used the content- Traditionally, most XMPP implementations have used the content-
namespace-as-default-namespace style rather than the prefix-free namespace-as-default-namespace style rather than the prefix-free
canonicalization style for stream headers; however, both styles are canonicalization style for stream headers; however, both styles are
acceptable since they are semantically equivalent. acceptable since they are semantically equivalent.
4.7.3. Other Namespaces 4.8.3. XMPP Content Namespaces
XMPP as defined in this specification uses two content namespaces:
'jabber:client' and 'jabber:server'. These namespaces are nearly
identical but are used in different contexts (client-to-server
communication for 'jabber:client' and server-to-server communication
for 'jabber:server'). The only difference between the two is that
the 'to' and 'from' attributes are OPTIONAL on stanzas sent over XML
streams qualified by the 'jabber:client' namespace, whereas they are
REQUIRED on stanzas sent over XML streams qualified by the 'jabber:
server' namespace. Support for these content namespaces implies
support for the common attributes (Section 8.1) and basic semantics
(Section 8.2) of all three core stanza types (message, presence, and
IQ).
An implementation MAY support content namespaces other than 'jabber:
client' or 'jabber:server'. However, because such namespaces would
define applications other than XMPP, they are to be defined in
separate specifications.
An implementation MAY refuse to support any other content namespaces
as default namespaces. If an entity receives a first-level child
element qualified by a content namespace it does not support, it MUST
return an <invalid-namespace/> stream error.
Client implementations MUST support the 'jabber:client' content
namespace as a default namespace. The 'jabber:server' content
namespace is out of scope for an XMPP client, and a client MUST NOT
send stanzas qualified by the 'jabber:server' namespace.
Server implementations MUST support as default content namespaces
both the 'jabber:client' namespace (when the stream is used for
communication between a client and a server) and the 'jabber:server'
namespace (when the stream is used for communication between two
servers). When communicating with a connected client, a server MUST
NOT send stanzas qualified by the 'jabber:server' namespace; when
communicating with a peer server, a server MUST NOT send stanzas
qualified by the 'jabber:client' namespace.
Implementation Note: Because a client sends stanzas over a stream
whose content namespace is 'jabber:client', if a server routes to
a peer server a stanza it has received from a connected client
then it needs to "re-scope" the stanza so that its content
namespace is 'jabber:server'. Similarly, if a server delivers to
a connected client a stanza it has received from a peer server
then it needs to "re-scope" the stanza so that its content
namespace is 'jabber:client'. This rule applies to XML stanzas as
defined under Section 4.1 (i.e., a first-level <message/>,
<presence/>, or <iq/> element qualified by the 'jabber:client' or
'jabber:server' namespace), and by namespace inheritance to all
child elements of a stanza; however the rule does not apply to
elements qualified by namespaces other than 'jabber:client' and
'jabber:server' nor to any children of such elements (e.g., a
<message/> element contained within an extension element
(Section 8.4) for reporting purposes). Although it is not
forbidden for an entity to generate stanzas in which an extension
element contains a child element qualified by the 'jabber:client'
or 'jabber:server' namespace, existing implementations handle such
stanzas inconsistently; therefore implementers are advised to
weigh the likely lack of interoperability against the possible
utility of such stanzas. Finally, servers are advised to apply
stanza re-scoping to other stream connection methods and
alternative XMPP connection methods, such as those specified in
[XEP-0124], [XEP-0206], [XEP-0114], and [XEP-0225].
4.8.4. Other Namespaces
Either party to a stream MAY send data qualified by namespaces other Either party to a stream MAY send data qualified by namespaces other
than the content namespace and the stream namespace. For example, than the content namespace and the stream namespace. For example,
this is how data related to TLS negotiation and SASL negotiation are this is how data related to TLS negotiation and SASL negotiation are
exchanged, as well as XMPP extensions such as Stream Management exchanged, as well as XMPP extensions such as Stream Management
[XEP-0198] and Server Dialback [XEP-0220]. (For historical reasons, [XEP-0198] and Server Dialback [XEP-0220].
some server implementations expect a declaration of the 'jabber:
server:dialback' namespace on server-to-server streams, as explained Interoperability Note: For historical reasons, some server
in [XEP-0220].) implementations expect a declaration of the 'jabber:server:
dialback' namespace on server-to-server streams, as explained in
[XEP-0220].
However, an XMPP server MUST NOT route or deliver data received over However, an XMPP server MUST NOT route or deliver data received over
an input stream if that data is (a) qualified by another namespace an input stream if that data is (a) qualified by another namespace
and (b) addressed to an entity other than the server, unless the and (b) addressed to an entity other than the server, unless the
other party to the output stream over which the server would send the other party to the output stream over which the server would send the
data has explicitly negotiated or advertised support for receiving data has explicitly negotiated or advertised support for receiving
arbitrary data from the server. This rule is included because XMPP arbitrary data from the server. This rule is included because XMPP
is designed for the exchange of XML stanzas (not arbitrary XML data), is designed for the exchange of XML stanzas (not arbitrary XML data),
and because allowing an entity to send arbitrary data to other and because allowing an entity to send arbitrary data to other
entities could significantly increase the potential for exchanging entities could significantly increase the potential for exchanging
skipping to change at page 43, line 37 skipping to change at page 46, line 23
level XML element from <romeo@example.net> to <juliet@example.com>: level XML element from <romeo@example.net> to <juliet@example.com>:
<ns1:foo xmlns:ns1='http://example.org/ns1' <ns1:foo xmlns:ns1='http://example.org/ns1'
from='romeo@example.net/resource1' from='romeo@example.net/resource1'
to='juliet@example.com'> to='juliet@example.com'>
<ns1:bar/> <ns1:bar/>
</ns1:foo> </ns1:foo>
This rule also applies to first-level elements that look like stanzas This rule also applies to first-level elements that look like stanzas
but that are improperly namespaced and therefore really are not but that are improperly namespaced and therefore really are not
stanzas at all (see also Section 4.7.4), for example: stanzas at all (see also Section 4.8.5), for example:
<ns2:message xmlns:pre='http://example.org/ns2' <ns2:message xmlns:ns2='http://example.org/ns2'
from='romeo@example.net/resource1' from='romeo@example.net/resource1'
to='juliet@example.com'> to='juliet@example.com'>
<body>hi</body> <body>hi</body>
</ns2:message> </ns2:message>
Upon receiving arbitrary first-level XML elements over an input Upon receiving arbitrary first-level XML elements over an input
stream, a server MUST either ignore the data or return a stream stream, a server MUST either ignore the data or return a stream
error, which SHOULD be <unsupported-stanza-type/>. error, which SHOULD be <unsupported-stanza-type/>.
4.7.4. Namespace Declarations and Prefixes 4.8.5. Namespace Declarations and Prefixes
Because the content namespace is other than the stream namespace, if Because the content namespace is other than the stream namespace, if
a content namespace is declared as the default namespace then the a content namespace is declared as the default namespace then the
following statements are true: following statements are true:
1. The stream header needs to contain a namespace declaration for 1. The stream header needs to contain a namespace declaration for
both the content namespace and the stream namespace. both the content namespace and the stream namespace.
2. The stream namespace declaration needs to include a namespace 2. The stream namespace declaration needs to include a namespace
prefix for the stream namespace. prefix for the stream namespace.
Interoperability Note: For historical reasons, an implementation Interoperability Note: For historical reasons, an implementation
MAY accept only the prefix 'stream' for the stream namespace MAY accept only the prefix 'stream' for the stream namespace
(resulting in prefixed names such as <stream:stream> and <stream: (resulting in prefixed names such as <stream:stream> and <stream:
features>). If an entity receives a stream header with a stream features>); this specification retains that allowance from
[RFC3920] for the purpose of backward compatibility.
Implementations are advised that using a prefix other than
'stream' for the stream namespace might result in interoperability
problems. If an entity receives a stream header with a stream
namespace prefix it does not accept, it MUST return a stream error namespace prefix it does not accept, it MUST return a stream error
to the sending entity, which SHOULD be <bad-namespace-prefix/> to the sending entity, which SHOULD be <bad-namespace-prefix/>
(although some existing implementations send <bad-format/> (although some existing implementations send <bad-format/>
instead). instead).
An implementation MUST NOT generate namespace prefixes for elements An implementation MUST NOT generate namespace prefixes for elements
qualified by the content namespace if the content namespace is qualified by the content namespace (i.e., the default namespace for
'jabber:client' or 'jabber:server' (e.g., <foo:presence/>). An XMPP data sent over the stream) if the content namespace is 'jabber:
entity MUST NOT accept data that violates this rule (in particular, client' or 'jabber:server'. For example, the following is illegal:
an XMPP server MUST NOT route or deliver such data to another
entity); instead it MUST either ignore the data or return a stream <stream:stream
error (which SHOULD be <bad-namespace-prefix/>). from='juliet@im.example.com'
to='im.example.com'
version='1.0'
xml:lang='en'
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'>
<foo:message xmlns:foo='jabber:client'>
<foo:body>foo</foo:body>
</foo:message>
An XMPP entity MUST NOT accept data that violates this rule (in
particular, an XMPP server MUST NOT route or deliver such data to
another entity); instead it MUST either ignore the data or return a
stream error (which SHOULD be <bad-namespace-prefix/>).
Namespaces declared in a stream header MUST apply only to that stream Namespaces declared in a stream header MUST apply only to that stream
(e.g., the 'jabber:server:dialback' namespace used in Server Dialback (e.g., the 'jabber:server:dialback' namespace used in Server Dialback
[XEP-0220]). In particular, because XML stanzas intended for routing [XEP-0220]). In particular, because XML stanzas intended for routing
or delivery over streams with other entities will lose the namespace or delivery over streams with other entities will lose the namespace
context declared in the header of the stream in which those stanzas context declared in the header of the stream in which those stanzas
originated, namespaces for extended content within such stanzas MUST originated, namespaces for extended content within such stanzas MUST
NOT be declared in that stream header (see also Section 8.4). If NOT be declared in that stream header (see also Section 8.4). If
either party to a stream declares such namespaces, the other party to either party to a stream declares such namespaces, the other party to
the stream SHOULD close the stream with a stream error of <invalid- the stream SHOULD close the stream with a stream error of <invalid-
namespace/>. In any case, an entity MUST ensure that such namespaces namespace/>. In any case, an entity MUST ensure that such namespaces
are properly declared (according to this section) when routing or are properly declared (according to this section) when routing or
delivering stanzas originating from such a stream over streams with delivering stanzas from an input stream to an output stream.
other entities.
4.7.5. XMPP Content Namespaces
XMPP as defined in this specification uses two content namespaces:
'jabber:client' and 'jabber:server'. These namespaces are nearly
identical but are used in different contexts (client-to-server
communication for 'jabber:client' and server-to-server communication
for 'jabber:server'). The only difference between the two is that
the 'to' and 'from' attributes are OPTIONAL on stanzas sent over XML
streams qualified by the 'jabber:client' namespace, whereas they are
REQUIRED on stanzas sent over XML streams qualified by the 'jabber:
server' namespace. Support for these content namespaces implies
support for the common attributes (Section 8.1) and basic semantics
(Section 8.2) of all three core stanza types (message, presence, and
IQ).
An implementation MAY support content namespaces other than 'jabber:
client' or 'jabber:server'. However, because such namespaces would
define applications other than XMPP, they are to be defined in
separate specifications.
An implementation MAY refuse to support any other content namespaces
as default namespaces. If an entity receives a first-level child
element qualified by a content namespace it does not support, it MUST
return an <invalid-namespace/> stream error.
Client implementations MUST support the 'jabber:client' content
namespace as a default namespace. The 'jabber:server' content
namespace is out of scope for an XMPP client, and a client MUST NOT
send stanzas qualified by the 'jabber:server' namespace.
Server implementations MUST support as default content namespaces
both the 'jabber:client' namespace (when the stream is used for
communication between a client and a server) and the 'jabber:server'
namespace (when the stream is used for communication between two
servers). When communicating with a connected client, a server MUST
NOT send stanzas qualified by the 'jabber:server' namespace; when
communicating with a peer server, a server MUST NOT send stanzas
qualified by the 'jabber:client' namespace.
Implementation Note: Because a client sends stanzas over a stream
whose content namespace is 'jabber:client', if a server routes to
a peer server a stanza it has received from a connected client
then it needs to "re-scope" the stanza so that its content
namespace is 'jabber:server'. Similarly, if a server delivers to
a connected client a stanza it has received from a peer server
then it needs to "re-scope" the stanza so that its content
namespace is 'jabber:client'. This rule applies to XML stanzas as
defined under Section 4.1 (i.e., a first-level <message/>,
<presence/>, or <iq/> element qualified by the 'jabber:client' or
'jabber:server' namespace), and by namespace inheritance to all
child elements of a stanza; however the rule does not apply to
elements qualified by namespaces other than 'jabber:client' and
'jabber:server' nor to any children of such elements (e.g., a
<message/> element contained within an extension element
(Section 8.4) for reporting purposes). Although it is not
forbidden for an entity to generate stanzas in which an extension
element contains a child element qualified by the 'jabber:client'
or 'jabber:server' namespace, existing implementations handle such
stanzas inconsistently; therefore implementers are advised to
weigh the likely lack of interoperability against the possible
utility of such stanzas.
4.8. Stream Errors 4.9. Stream Errors
The root stream element MAY contain an <error/> child element that is The root stream element MAY contain an <error/> child element that is
prefixed by the stream namespace prefix. The error child SHALL be qualified by the stream namespace. The error child SHALL be sent by
sent by a compliant entity if it perceives that a stream-level error a compliant entity if it perceives that a stream-level error has
has occurred. occurred.
4.8.1. Rules 4.9.1. Rules
The following rules apply to stream-level errors. The following rules apply to stream-level errors.
4.8.1.1. Stream Errors Are Unrecoverable 4.9.1.1. Stream Errors Are Unrecoverable
Stream-level errors are unrecoverable. Therefore, if an error occurs Stream-level errors are unrecoverable. Therefore, if an error occurs
at the level of the stream, the entity that detects the error MUST at the level of the stream, the entity that detects the error MUST
send an <error/> element with an appropriate child element that send an <error/> element with an appropriate child element specifying
specifies the error condition and immediately close the stream as the error condition and then immediately close the stream as
described under Section 4.4. described under Section 4.4.
C: <message><body>No closing tag!</message> C: <message><body>No closing tag!</message>
S: <stream:error> S: <stream:error>
<not-well-formed <not-well-formed
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
The entity that generates the stream error then shall close the The entity that receives the stream error then shall close the stream
stream as explained under Section 4.4. as explained under Section 4.4.
C: </stream:stream> C: </stream:stream>
4.8.1.2. Stream Errors Can Occur During Setup 4.9.1.2. Stream Errors Can Occur During Setup
If the error is triggered by the initial stream header, the receiving If the error is triggered by the initial stream header, the receiving
entity MUST still send the opening <stream> tag, include the <error/> entity MUST still send the opening <stream> tag, include the <error/>
element as a child of the stream element, and send the closing element as a child of the stream element, and send the closing
</stream> tag (preferably all at the same time). </stream> tag (preferably in the same TCP packet).
C: <?xml version='1.0'?> C: <?xml version='1.0'?>
<stream:stream <stream:stream
from='juliet@im.example.com' from='juliet@im.example.com'
to='im.example.com' to='im.example.com'
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://wrong.namespace.example.org/'> xmlns:stream='http://wrong.namespace.example.org/'>
skipping to change at page 47, line 29 skipping to change at page 49, line 29
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error> <stream:error>
<invalid-namespace <invalid-namespace
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
4.8.1.3. Stream Errors When the Host is Unspecified or Unknown 4.9.1.3. Stream Errors When the Host is Unspecified or Unknown
If the initiating entity provides no 'to' attribute or provides an If the initiating entity provides no 'to' attribute or provides an
unknown host in the 'to' attribute and the error occurs during stream unknown host in the 'to' attribute and the error occurs during stream
setup, the value of the 'from' attribute returned by the receiving setup, the value of the 'from' attribute returned by the receiving
entity in the stream header sent before closing the stream MUST be entity in the stream header sent before closing the stream MUST be
either an authoritative hostname for the receiving entity or the either an authoritative FQDN for the receiving entity or the empty
empty string. string.
C: <?xml version='1.0'?> C: <?xml version='1.0'?>
<stream:stream <stream:stream
from='juliet@im.example.com' from='juliet@im.example.com'
to='unknown.host.example.com' to='unknown.host.example.com'
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
skipping to change at page 48, line 29 skipping to change at page 50, line 29
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error> <stream:error>
<host-unknown <host-unknown
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
4.8.1.4. Where Stream Errors Are Sent 4.9.1.4. Where Stream Errors Are Sent
When two TCP connections are used between the initiating entity and When two TCP connections are used between the initiating entity and
the receiving entity (one in each direction) rather than using a the receiving entity (one in each direction) rather than using a
single bidirectional connection, the following rules apply: single bidirectional connection, the following rules apply:
o Stream-level errors related to the initial stream are returned by o Stream-level errors related to the initial stream are returned by
the receiving entity on the response stream via the same TCP the receiving entity on the response stream via the same TCP
connection. connection.
o Stanza errors triggered by outbound stanzas sent from the o Stanza errors triggered by outbound stanzas sent from the
initiating entity over the initial stream via the same TCP initiating entity over the initial stream via the same TCP
connection are returned by the receiving entity on the response connection are returned by the receiving entity on the response
stream via the other, return TCP connection (since they are stream via the other ("return") TCP connection, since they are
inbound stanzas from the perspective of the initiating entity). inbound stanzas from the perspective of the initiating entity.
4.8.2. Syntax 4.9.2. Syntax
The syntax for stream errors is as follows, where "defined-condition" The syntax for stream errors is as follows, where XML data shown
is a placeholder for one of the conditions defined under within the square brackets '[' and ']' is OPTIONAL.
Section 4.8.3 and XML data shown within the square brackets '[' and
']' is OPTIONAL.
<stream:error> <stream:error>
<defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> <defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
[<text xmlns='urn:ietf:params:xml:ns:xmpp-streams' [<text xmlns='urn:ietf:params:xml:ns:xmpp-streams'
xml:lang='langcode'> xml:lang='langcode'>
[ ... descriptive text ... ] OPTIONAL descriptive text
</text>] </text>]
[application-specific condition element] [OPTIONAL application-specific condition element]
</stream:error> </stream:error>
The "defined-condition" MUST correspond to one of the stream error
conditions defined under Section 4.9.3. If the designers of an XMPP
protocol extension or the developers of an XMPP implementation need
to communicate a stream error condition that is not defined in this
specification, they can do so by defining an application-specific
error condition element qualified by an application-specific
namespace.
The <error/> element: The <error/> element:
o MUST contain a child element corresponding to one of the defined o MUST contain a child element corresponding to one of the defined
stream error conditions (Section 4.8.3); this element MUST be stream error conditions (Section 4.9.3); this element MUST be
qualified by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace. qualified by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace.
o MAY contain a <text/> child element containing XML character data o MAY contain a <text/> child element containing XML character data
that describes the error in more detail; this element MUST be that describes the error in more detail; this element MUST be
qualified by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace qualified by the 'urn:ietf:params:xml:ns:xmpp-streams' namespace
and SHOULD possess an 'xml:lang' attribute specifying the natural and SHOULD possess an 'xml:lang' attribute specifying the natural
language of the XML character data. language of the XML character data.
o MAY contain a child element for an application-specific error o MAY contain a child element for an application-specific error
condition; this element MUST be qualified by an application- condition; this element MUST be qualified by an application-
defined namespace, and its structure is defined by that namespace defined namespace, and its structure is defined by that namespace
(see Section 4.8.4). (see Section 4.9.4).
The <text/> element is OPTIONAL. If included, it MUST be used only The <text/> element is OPTIONAL. If included, it MUST be used only
to provide descriptive or diagnostic information that supplements the to provide descriptive or diagnostic information that supplements the
meaning of a defined condition or application-specific condition. It meaning of a defined condition or application-specific condition. It
MUST NOT be interpreted programmatically by an application. It MUST MUST NOT be interpreted programmatically by an application. It MUST
NOT be used as the error message presented to a human user, but MAY 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 be shown in addition to the error message associated with the defined
condition element (and, optionally, the application-specific condition element (and, optionally, the application-specific
condition element). condition element).
4.8.3. Defined Stream Error Conditions 4.9.3. Defined Stream Error Conditions
The following stream-level error conditions are defined. The following stream-level error conditions are defined.
4.8.3.1. bad-format 4.9.3.1. bad-format
The entity has sent XML that cannot be processed. The entity has sent XML that cannot be processed.
(In the following example, the client sends an XMPP message that is (In the following example, the client sends an XMPP message that is
not well-formed XML, which alternatively might trigger a <not-well- not well-formed XML, which alternatively might trigger a <not-well-
formed/> stream error.) formed/> stream error.)
C: <message> C: <message>
<body>No closing tag! <body>No closing tag!
</message> </message>
S: <stream:error> S: <stream:error>
<bad-format <bad-format
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
skipping to change at page 50, line 14 skipping to change at page 52, line 23
C: <message> C: <message>
<body>No closing tag! <body>No closing tag!
</message> </message>
S: <stream:error> S: <stream:error>
<bad-format <bad-format
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
This error MAY be used instead of the more specific XML-related This error can be used instead of the more specific XML-related
errors, such as <bad-namespace-prefix/>, <invalid-xml/>, <not-well- errors, such as <bad-namespace-prefix/>, <invalid-xml/>, <not-well-
formed/>, <restricted-xml/>, and <unsupported-encoding/>. However, formed/>, <restricted-xml/>, and <unsupported-encoding/>. However,
the more specific errors are RECOMMENDED. the more specific errors are RECOMMENDED.
4.8.3.2. bad-namespace-prefix 4.9.3.2. bad-namespace-prefix
The entity has sent a namespace prefix that is unsupported, or has The entity has sent a namespace prefix that is unsupported, or has
sent no namespace prefix on an element that needs such a prefix (see sent no namespace prefix on an element that needs such a prefix (see
Section 11.2). Section 11.2).
(In the following example, the client specifies a namespace prefix of (In the following example, the client specifies a namespace prefix of
"foobar" for the XML stream namespace.) "foobar" for the XML stream namespace.)
C: <?xml version='1.0'?> C: <?xml version='1.0'?>
<foobar:stream <foobar:stream
from='juliet@im.example.com' from='juliet@im.example.com'
to='im.example.com' to='im.example.com'
version='1.0' version='1.0'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:foobar='http://etherx.jabber.org/streams'> xmlns:foobar='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?> S: <?xml version='1.0'?>
<stream:stream <stream:stream
skipping to change at page 51, line 5 skipping to change at page 53, line 27
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error> <stream:error>
<bad-namespace-prefix <bad-namespace-prefix
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
4.8.3.3. conflict 4.9.3.3. conflict
The server either (1) is closing the existing stream for this entity The server either (1) is closing the existing stream for this entity
because a new stream has been initiated that conflicts with the because a new stream has been initiated that conflicts with the
existing stream, or (2) is refusing a new stream for this entity existing stream, or (2) is refusing a new stream for this entity
because allowing the new stream would conflict with an existing because allowing the new stream would conflict with an existing
stream (e.g., because the server allows only a certain number of stream (e.g., because the server allows only a certain number of
connections from the same IP address or allows only one server-to- connections from the same IP address or allows only one server-to-
server stream for a given domain pair as a way of helping to ensure server stream for a given domain pair as a way of helping to ensure
in-order processing as described under Section 10.1). in-order processing as described under Section 10.1).
skipping to change at page 51, line 45 skipping to change at page 54, line 34
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
If a client receives a <conflict/> stream error, during the resource If a client receives a <conflict/> stream error, during the resource
binding aspect of its reconnection attempt it MUST NOT blindly binding aspect of its reconnection attempt it MUST NOT blindly
request the resourcepart it used during the former session but request the resourcepart it used during the former session but
instead MUST choose a different resourcepart; details are provided instead MUST choose a different resourcepart; details are provided
under Section 7. under Section 7.
4.8.3.4. connection-timeout 4.9.3.4. connection-timeout
One party is closing the stream because it has reason to believe that One party is closing the stream because it has reason to believe that
the other party has permanently lost the ability to communicate over the other party has permanently lost the ability to communicate over
the stream. The lack of ability to communicate can be discovered the stream. The lack of ability to communicate can be discovered
using various methods, such as whitespace keepalives as specified using various methods, such as whitespace keepalives as specified
under Section 4.4, XMPP-level pings as defined in [XEP-0199], and under Section 4.4, XMPP-level pings as defined in [XEP-0199], and
XMPP Stream Management as defined in [XEP-0198]. XMPP Stream Management as defined in [XEP-0198].
P: <stream:error> P: <stream:error>
<connection-timeout <connection-timeout
skipping to change at page 52, line 18 skipping to change at page 55, line 7
</stream:error> </stream:error>
</stream:stream> </stream:stream>
Interoperability Note: RFC 3920 specified that the <connection- Interoperability Note: RFC 3920 specified that the <connection-
timeout/> stream error is to be used if the peer has not generated timeout/> stream error is to be used if the peer has not generated
any traffic over the stream for some period of time. That any traffic over the stream for some period of time. That
behavior is no longer recommended; instead, the error SHOULD be behavior is no longer recommended; instead, the error SHOULD be
used only if the connected client or peer server has not responded used only if the connected client or peer server has not responded
to data sent over the stream. to data sent over the stream.
4.8.3.5. host-gone 4.9.3.5. host-gone
The value of the 'to' attribute provided in the initial stream header The value of the 'to' attribute provided in the initial stream header
corresponds to a hostname that is no longer serviced by the receiving corresponds to an FQDN that is no longer serviced by the receiving
entity. entity.
(In the following example, the peer specifies a 'to' address of (In the following example, the peer specifies a 'to' address of
"foo.im.example.com" when connecting to the "im.example.com" server, "foo.im.example.com" when connecting to the "im.example.com" server,
but the server no longer hosts a service at that address.) but the server no longer hosts a service at that address.)
P: <?xml version='1.0'?> P: <?xml version='1.0'?>
<stream:stream <stream:stream
from='example.net' from='example.net'
to='foo.im.example.com' to='foo.im.example.com'
skipping to change at page 53, line 5 skipping to change at page 55, line 40
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:server' xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error> <stream:error>
<host-gone <host-gone
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
4.8.3.6. host-unknown 4.9.3.6. host-unknown
The value of the 'to' attribute provided in the initial stream header The value of the 'to' attribute provided in the initial stream header
does not correspond to a hostname that is serviced by the receiving does not correspond to an FQDN that is serviced by the receiving
entity. entity.
(In the following example, the peer specifies a 'to' address of (In the following example, the peer specifies a 'to' address of
"example.org" when connecting to the "im.example.com" server, but the "example.org" when connecting to the "im.example.com" server, but the
server knows nothing of that address.) server knows nothing of that address.)
P: <?xml version='1.0'?> P: <?xml version='1.0'?>
<stream:stream <stream:stream
from='example.net' from='example.net'
to='example.org' to='example.org'
version='1.0' version='1.0'
xmlns='jabber:server' xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?> S: <?xml version='1.0'?>
<stream:stream <stream:stream
skipping to change at page 53, line 38 skipping to change at page 56, line 27
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:server' xmlns='jabber:server'
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error> <stream:error>
<host-unknown <host-unknown
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
4.8.3.7. improper-addressing 4.9.3.7. improper-addressing
A stanza sent between two servers lacks a 'to' or 'from' attribute, 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 the 'from' or 'to' attribute has no value, or the value violates the
valid XMPP address. rules for XMPP addresses [XMPP-ADDR].
(In the following example, the peer sends a stanza without a 'to' (In the following example, the peer sends a stanza without a 'to'
address over a server-to-server stream.) address over a server-to-server stream.)
P: <message from='juliet@im.example.com'> P: <message from='juliet@im.example.com'>
<body>Wherefore art thou?</body> <body>Wherefore art thou?</body>
</message> </message>
S: <stream:error> S: <stream:error>
<improper-addressing <improper-addressing
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
skipping to change at page 54, line 14 skipping to change at page 56, line 46
P: <message from='juliet@im.example.com'> P: <message from='juliet@im.example.com'>
<body>Wherefore art thou?</body> <body>Wherefore art thou?</body>
</message> </message>
S: <stream:error> S: <stream:error>
<improper-addressing <improper-addressing
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
4.8.3.8. internal-server-error 4.9.3.8. internal-server-error
The server has experienced a misconfiguration or an otherwise- The server has experienced a misconfiguration or other internal error
undefined internal error that prevents it from servicing the stream. that prevents it from servicing the stream.
S: <stream:error> S: <stream:error>
<internal-server-error <internal-server-error
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
4.8.3.9. invalid-from 4.9.3.9. invalid-from
The JID or hostname provided in a 'from' address is not a valid JID The data provided in a 'from' attribute does not match an authorized
or does not match an authorized JID or validated domain as negotiated JID or validated domain as negotiated (1) between two servers using
between servers via SASL or Server Dialback, or as negotiated between SASL or Server Dialback, or (2) between a client and a server via
a client and a server via authentication and resource binding. authentication and resource binding.
(In the following example, a peer that has authenticated only as (In the following example, a peer that has authenticated only as
"example.net" attempts to send a stanza from an address at "example.net" attempts to send a stanza from an address at
"example.org".) "example.org".)
P: <message from='romeo@example.org' to='juliet@im.example.com'> P: <message from='romeo@example.org' to='juliet@im.example.com'>
<body>Neither, fair saint, if either thee dislike.</body> <body>Neither, fair saint, if either thee dislike.</body>
</message> </message>
S: <stream:error> S: <stream:error>
<invalid-from <invalid-from
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
4.8.3.10. invalid-namespace 4.9.3.10. invalid-namespace
The stream namespace name is something other than The stream namespace name is something other than
"http://etherx.jabber.org/streams" (see Section 11.2) or the content "http://etherx.jabber.org/streams" (see Section 11.2) or the content
namespace is not supported (e.g., something other than "jabber: namespace declared as the default namespace is not supported (e.g.,
client" or "jabber:server"). something other than "jabber:client" or "jabber:server").
(In the following example, the client specifies a namespace of (In the following example, the client specifies a namespace of
'http://wrong.namespace.example.org/' for the stream.) 'http://wrong.namespace.example.org/' for the stream.)
C: <?xml version='1.0'?> C: <?xml version='1.0'?>
<stream:stream <stream:stream
from='juliet@im.example.com' from='juliet@im.example.com'
to='im.example.com' to='im.example.com'
version='1.0' version='1.0'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://wrong.namespace.example.org/'> xmlns:stream='http://wrong.namespace.example.org/'>
S: <?xml version='1.0'?> S: <?xml version='1.0'?>
<stream:stream <stream:stream
skipping to change at page 55, line 31 skipping to change at page 58, line 27
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error> <stream:error>
<invalid-namespace <invalid-namespace
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
4.8.3.11. invalid-xml 4.9.3.11. invalid-xml
The entity has sent invalid XML over the stream to a server that The entity has sent invalid XML over the stream to a server that
performs validation (see Section 11.4). performs validation (see Section 11.4).
(In the following example, the peer attempts to send an IQ stanza of (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 "subscribe" but the XML schema defines no such value for the
'type' attribute.) 'type' attribute.)
P: <iq from='example.net' P: <iq from='example.net'
id='l3b1vs75' id='l3b1vs75'
skipping to change at page 56, line 5 skipping to change at page 59, line 5
type='subscribe'> type='subscribe'>
<ping xmlns='urn:xmpp:ping'/> <ping xmlns='urn:xmpp:ping'/>
</iq> </iq>
S: <stream:error> S: <stream:error>
<invalid-xml <invalid-xml
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
4.8.3.12. not-authorized 4.9.3.12. not-authorized
The entity has attempted to send XML stanzas or other outbound data The entity has attempted to send XML stanzas or other outbound data
before the stream has been authenticated, or otherwise is not before the stream has been authenticated, or otherwise is not
authorized to perform an action related to stream negotiation; the authorized to perform an action related to stream negotiation; the
receiving entity MUST NOT process the offending stanza before sending receiving entity MUST NOT process the offending data before sending
the stream error. the stream error.
(In the following example, the client attempts to send XML stanzas (In the following example, the client attempts to send XML stanzas
before authenticating with the server.) before authenticating with the server.)
C: <?xml version='1.0'?> C: <?xml version='1.0'?>
<stream:stream <stream:stream
from='juliet@im.example.com' from='juliet@im.example.com'
to='im.example.com' to='im.example.com'
version='1.0' version='1.0'
skipping to change at page 56, line 32 skipping to change at page 59, line 32
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?> S: <?xml version='1.0'?>
<stream:stream <stream:stream
from='im.example.com' from='im.example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y=' id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@im.example.com' to='juliet@im.example.com'
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'>
C: <message to='romeo@example.net'> C: <message to='romeo@example.net'>
<body>Wherefore art thou?</body> <body>Wherefore art thou?</body>
</message> </message>
S: <stream:error> S: <stream:error>
<not-authorized <not-authorized
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
4.8.3.13. not-well-formed 4.9.3.13. not-well-formed
The initiating entity has sent XML that violates the well-formedness The initiating entity has sent XML that violates the well-formedness
rules of [XML] or [XML-NAMES]. rules of [XML] or [XML-NAMES].
(In the following example, the client sends an XMPP message that is (In the following example, the client sends an XMPP message that is
not namespace-well-formed.) not namespace-well-formed.)
C: <message> C: <message>
<foo:body>What is this foo?</foo:body> <foo:body>What is this foo?</foo:body>
</message> </message>
skipping to change at page 57, line 22 skipping to change at page 60, line 22
</stream:stream> </stream:stream>
Interoperability Note: In RFC 3920, the name of this error Interoperability Note: In RFC 3920, the name of this error
condition was "xml-not-well-formed" instead of "not-well-formed". condition was "xml-not-well-formed" instead of "not-well-formed".
The name was changed because the element name <xml-not-well- The name was changed because the element name <xml-not-well-
formed/> violates the constraint from Section 3 of [XML] that formed/> violates the constraint from Section 3 of [XML] that
"names beginning with a match to (('X'|'x')('M'|'m')('L'|'l')) are "names beginning with a match to (('X'|'x')('M'|'m')('L'|'l')) are
reserved for standardization in this or future versions of this reserved for standardization in this or future versions of this
specification". specification".
4.8.3.14. policy-violation 4.9.3.14. policy-violation
The entity has violated some local service policy (e.g., the stanza The entity has violated some local service policy (e.g., a stanza
exceeds a configured size limit); the server MAY choose to specify exceeds a configured size limit); the server MAY choose to specify
the policy in the <text/> element or in an application-specific the policy in the <text/> element or in an application-specific
condition element. condition element.
(In the following example, the client sends an XMPP message that is (In the following example, the client sends an XMPP message that is
too large according to the server's local service policy.) too large according to the server's local service policy.)
C: <message to='juliet@im.example.com' id='foo'> C: <message to='juliet@im.example.com' id='foo'>
<body>[ ... the-emacs-manual ... ]</body> <body>[ ... the-emacs-manual ... ]</body>
</message> </message>
S: <stream:error> S: <stream:error>
<policy-violation <policy-violation
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
<stanza-too-big xmlns='urn:xmpp:errors'/> <stanza-too-big xmlns='urn:xmpp:errors'/>
</stream:error> </stream:error>
S: </stream:stream> S: </stream:stream>
4.8.3.15. remote-connection-failed 4.9.3.15. remote-connection-failed
The server is unable to properly connect to a remote entity that is The server is unable to properly connect to a remote entity that is
needed for authentication or authorization (e.g., in certain needed for authentication or authorization (e.g., in certain
scenarios related to Server Dialback [XEP-0220]); this condition is scenarios related to Server Dialback [XEP-0220]); this condition is
not to be used when the cause of the error is within the not to be used when the cause of the error is within the
administrative domain of the XMPP service provider, in which case the administrative domain of the XMPP service provider, in which case the
<internal-server-error/> condition is more appropriate. <internal-server-error/> condition is more appropriate.
C: <?xml version='1.0'?> C: <?xml version='1.0'?>
<stream:stream <stream:stream
skipping to change at page 58, line 28 skipping to change at page 61, line 28
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error> <stream:error>
<remote-connection-failed <remote-connection-failed
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
4.8.3.16. reset 4.9.3.16. reset
The server is closing the stream because it has new (typically The server is closing the stream because it has new (typically
security-critical) features to offer, because the keys or security-critical) features to offer, because the keys or
certificates used to establish a secure context for the stream have certificates used to establish a secure context for the stream have
expired or have been revoked during the life of the stream expired or have been revoked during the life of the stream
(Section 13.7.2.3), because the TLS sequence number has wrapped (Section 13.7.2.3), because the TLS sequence number has wrapped
(Section 5.3.5), etc. The reset applies to the stream and to any (Section 5.3.5), etc. The reset applies to the stream and to any
security context established for that stream (e.g., via TLS and security context established for that stream (e.g., via TLS and
SASL), which means that encryption and authentication need to be SASL), which means that encryption and authentication need to be
negotiated again for the new stream (e.g., TLS session resumption negotiated again for the new stream (e.g., TLS session resumption
cannot be used). cannot be used).
S: <stream:error> S: <stream:error>
<reset <reset
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
4.8.3.17. resource-constraint 4.9.3.17. resource-constraint
The server lacks the system resources necessary to service the The server lacks the system resources necessary to service the
stream. stream.
C: <?xml version='1.0'?> C: <?xml version='1.0'?>
<stream:stream <stream:stream
from='juliet@im.example.com' from='juliet@im.example.com'
to='im.example.com' to='im.example.com'
version='1.0' version='1.0'
xmlns='jabber:client' xmlns='jabber:client'
skipping to change at page 59, line 28 skipping to change at page 62, line 28
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error> <stream:error>
<resource-constraint <resource-constraint
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
4.8.3.18. restricted-xml 4.9.3.18. restricted-xml
The entity has attempted to send restricted XML features such as a The entity has attempted to send restricted XML features such as a
comment, processing instruction, DTD subset, or XML entity reference comment, processing instruction, DTD subset, or XML entity reference
(see Section 11.1). (see Section 11.1).
(In the following example, the client sends an XMPP message (In the following example, the client sends an XMPP message
containing an XML comment.) containing an XML comment.)
C: <message to='juliet@im.example.com'> C: <message to='juliet@im.example.com'>
<!--<subject/>--> <!--<subject/>-->
<body>This message has no subject.</body> <body>This message has no subject.</body>
</message> </message>
S: <stream:error> S: <stream:error>
<restricted-xml <restricted-xml
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
4.8.3.19. see-other-host 4.9.3.19. see-other-host
The server will not provide service to the initiating entity but is The server will not provide service to the initiating entity but is
redirecting traffic to another host under the administrative control redirecting traffic to another host under the administrative control
of the same service provider. The XML character data of the <see- of the same service provider. The XML character data of the <see-
other-host/> element returned by the server MUST specify the other-host/> element returned by the server MUST specify the
alternate hostname or IP address at which to connect, which MUST be a alternate FQDN or IP address at which to connect, which MUST be a
valid domainpart or a domainpart plus port number (separated by the valid domainpart or a domainpart plus port number (separated by the
':' character in the form "domainpart:port"). If the domainpart is ':' character in the form "domainpart:port"). If the domainpart is
the same as the source domain, derived domain, or resolved IP address the same as the source domain, derived domain, or resolved IPv4 or
to which the initiating entity originally connected (differing only IPv6 address to which the initiating entity originally connected
by the port number), then the initiating entity SHOULD simply attempt (differing only by the port number), then the initiating entity
to reconnect at that address. Otherwise, the initiating entity MUST SHOULD simply attempt to reconnect at that address. (The format of
resolve the hostname specified in the <see-other-host/> element as an IPv6 address MUST follow [IPv6-ADDR], which includes the enclosing
described under Section 3.2. the IPv6 address in square brackets '[' and ']' as originally defined
by [URI].) Otherwise, the initiating entity MUST resolve the FQDN
specified in the <see-other-host/> element as described under
Section 3.2.
C: <?xml version='1.0'?> C: <?xml version='1.0'?>
<stream:stream <stream:stream
from='juliet@im.example.com' from='juliet@im.example.com'
to='im.example.com' to='im.example.com'
version='1.0' version='1.0'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?> S: <?xml version='1.0'?>
skipping to change at page 60, line 46 skipping to change at page 63, line 49
</see-other-host> </see-other-host>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
When negotiating a stream with the host to which it has been When negotiating a stream with the host to which it has been
redirected, the initiating entity MUST apply the same policies it redirected, the initiating entity MUST apply the same policies it
would have applied to the original connection attempt (e.g., a policy would have applied to the original connection attempt (e.g., a policy
requiring TLS), MUST specify the same 'to' address on the initial requiring TLS), MUST specify the same 'to' address on the initial
stream header, and MUST verify the identity of the new host using the stream header, and MUST verify the identity of the new host using the
same reference identifier(s) it would have used for the original same reference identifier(s) it would have used for the original
connection attempt (in accordance with [TLS-CERTS]. Even if connection attempt (in accordance with [TLS-CERTS]). Even if the
receiving entity returns a <see-other-host/> error before the receiving entity returns a <see-other-host/> error before the
confidentiality and integrity of the stream have been established confidentiality and integrity of the stream have been established
(thus introducing the possibility of a denial of service attack), the (thus introducing the possibility of a denial of service attack), the
fact that the initiating entity needs to verify the identity of the fact that the initiating entity needs to verify the identity of the
XMPP service based on the same reference identifiers implies that the XMPP service based on the same reference identifiers implies that the
initiating entity will not connect to a malicious entity; however, to initiating entity will not connect to a malicious entity. To reduce
reduce the possibility of a denial of service attack, the receiving the possibility of a denial of service attack, (a) the receiving
entity SHOULD NOT return a <see-other-host/> error until after the entity SHOULD NOT return a <see-other-host/> error until after the
stream has been protected (e.g., via TLS) and the receiving entity confidentiality and integrity of the stream have been ensured via TLS
MAY have a policy of following redirects only if it has authenticated or an equivalent security layer (such as the SASL GSSAPI mechanism)
the receiving entity. In addition, the initiating entity SHOULD give and (b) the receiving entity MAY have a policy of following redirects
up after a certain number of successive redirects (e.g., at least 2 only if it has authenticated the receiving entity. In addition, the
but no more than 5). initiating entity SHOULD abort the connection attempt after a certain
number of successive redirects (e.g., at least 2 but no more than 5).
4.8.3.20. system-shutdown 4.9.3.20. system-shutdown
The server is being shut down and all active streams are being The server is being shut down and all active streams are being
closed. closed.
S: <stream:error> S: <stream:error>
<system-shutdown <system-shutdown
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
4.8.3.21. undefined-condition 4.9.3.21. undefined-condition
The error condition is not one of those defined by the other The error condition is not one of those defined by the other
conditions in this list; this error condition SHOULD be used only in conditions in this list; this error condition SHOULD NOT be used
conjunction with an application-specific condition. except in conjunction with an application-specific condition.
S: <stream:error> S: <stream:error>
<undefined-condition <undefined-condition
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
<app-error xmlns='http://example.org/ns'/> <app-error xmlns='http://example.org/ns'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
4.8.3.22. unsupported-encoding 4.9.3.22. unsupported-encoding
The initiating entity has encoded the stream in an encoding that is The initiating entity has encoded the stream in an encoding that is
not supported by the server (see Section 11.6) or has otherwise not supported by the server (see Section 11.6) or has otherwise
improperly encoded the stream (e.g., by violating the rules of the improperly encoded the stream (e.g., by violating the rules of the
[UTF-8] encoding). [UTF-8] encoding).
(In the following example, the client attempts to encode data using (In the following example, the client attempts to encode data using
UTF-16 instead of UTF-8.) UTF-16 instead of UTF-8.)
C: <?xml version='1.0' encoding='UTF-16'?> C: <?xml version='1.0' encoding='UTF-16'?>
<stream:stream <stream:stream
skipping to change at page 62, line 20 skipping to change at page 65, line 20
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?> S: <?xml version='1.0'?>
<stream:stream <stream:stream
from='im.example.com' from='im.example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y=' id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@im.example.com' to='juliet@im.example.com'
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error> <stream:error>
<unsupported-encoding <unsupported-encoding
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
4.8.3.23. unsupported-feature 4.9.3.23. unsupported-feature
The receiving entity has advertised a mandatory stream feature that The receiving entity has advertised a mandatory-to-negotiate stream
the initiating entity does not support, and has offered no other feature that the initiating entity does not support, and has offered
mandatory feature alongside the unsupported feature. no other mandatory-to-negotiate feature alongside the unsupported
feature.
(In the following example, the receiving entity requires negotiation (In the following example, the receiving entity requires negotiation
of an example feature but the initiating entity does not support the of an example feature but the initiating entity does not support the
feature.) feature.)
R: <stream:features> R: <stream:features>
<example xmlns='urn:xmpp:example'> <example xmlns='urn:xmpp:example'>
<required/> <required/>
</example> </example>
</stream:features> </stream:features>
I: <stream:error> I: <stream:error>
<unsupported-feature <unsupported-feature
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
4.8.3.24. unsupported-stanza-type 4.9.3.24. unsupported-stanza-type
The initiating entity has sent a first-level child of the stream that The initiating entity has sent a first-level child of the stream that
is not supported by the server, either because the receiving entity is not supported by the server, either because the receiving entity
does not understand the namespace or because the receiving entity does not understand the namespace or because the receiving entity
does not understand the element name for the applicable namespace does not understand the element name for the applicable namespace
(which might be the content namespace declared as the default (which might be the content namespace declared as the default
namespace). namespace).
(In the following example, the client attempts to send a first-level (In the following example, the client attempts to send a first-level
child element of <pubsub/> qualified by the 'jabber:client' child element of <pubsub/> qualified by the 'jabber:client'
skipping to change at page 63, line 47 skipping to change at page 66, line 47
</item> </item>
</publish> </publish>
</pubsub> </pubsub>
S: <stream:error> S: <stream:error>
<unsupported-stanza-type <unsupported-stanza-type
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
4.8.3.25. unsupported-version 4.9.3.25. unsupported-version
The value of the 'version' attribute provided by the initiating The 'version' attribute provided by the initiating entity in the
entity in the stream header specifies a version of XMPP that is not stream header specifies a version of XMPP that is not supported by
supported by the server. the server.
C: <?xml version='1.0'?> C: <?xml version='1.0'?>
<stream:stream <stream:stream
from='juliet@im.example.com' from='juliet@im.example.com'
to='im.example.com' to='im.example.com'
version='11.0' version='11.0'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
S: <?xml version='1.0'?> S: <?xml version='1.0'?>
<stream:stream <stream:stream
from='im.example.com' from='im.example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y=' id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@im.example.com' to='juliet@im.example.com'
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'>
<stream:error> <stream:error>
<unsupported-version <unsupported-version
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
4.8.4. Application-Specific Conditions 4.9.4. Application-Specific Conditions
As noted, an application MAY provide application-specific stream As noted, an application MAY provide application-specific stream
error information by including a properly-namespaced child in the error information by including a properly-namespaced child in the
error element. The application-specific element SHOULD supplement or error element. The application-specific element SHOULD supplement or
further qualify a defined element. Thus the <error/> element will further qualify a defined element. Thus the <error/> element will
contain two or three child elements. contain two or three child elements.
C: <message> C: <message>
<body> <body>
My keyboard layout is: My keyboard layout is:
skipping to change at page 65, line 25 skipping to change at page 68, line 25
S: <stream:error> S: <stream:error>
<not-well-formed <not-well-formed
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
<text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'> <text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
Some special application diagnostic information! Some special application diagnostic information!
</text> </text>
<escape-your-data xmlns='http://example.org/ns'/> <escape-your-data xmlns='http://example.org/ns'/>
</stream:error> </stream:error>
</stream:stream> </stream:stream>
4.9. Simplified Stream Examples 4.10. Simplified Stream Examples
This section contains two highly simplified examples of a stream- This section contains two highly simplified examples of a stream-
based connection between a client and a server; these examples are based connection between a client and a server; these examples are
included for the purpose of illustrating the concepts introduced thus included for the purpose of illustrating the concepts introduced thus
far, but the reader needs to be aware that these examples elide many far, but the reader needs to be aware that these examples elide many
details (see Section 9 for more complete examples). details (see Section 9 for more complete examples).
A basic connection: A basic connection:
C: <?xml version='1.0'?> C: <?xml version='1.0'?>
skipping to change at page 67, line 25 skipping to change at page 70, line 25
S: <?xml version='1.0'?> S: <?xml version='1.0'?>
<stream:stream <stream:stream
from='im.example.com' from='im.example.com'
id='++TR84Sm6A3hnt3Q065SnAbbk3Y=' id='++TR84Sm6A3hnt3Q065SnAbbk3Y='
to='juliet@im.example.com' to='juliet@im.example.com'
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
[ ... channel encryption ... ] [ ... stream negotiation ... ]
[ ... authentication ... ]
[ ... resource binding ... ]
C: <message from='juliet@im.example.com/balcony' C: <message from='juliet@im.example.com/balcony'
to='romeo@example.net' to='romeo@example.net'
xml:lang='en'> xml:lang='en'>
<body>No closing tag! <body>No closing tag!
</message> </message>
S: <stream:error> S: <stream:error>
<not-well-formed <not-well-formed
xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
skipping to change at page 68, line 18 skipping to change at page 71, line 11
Transport Layer Security [TLS] protocol, specifically a "STARTTLS" Transport Layer Security [TLS] protocol, specifically a "STARTTLS"
extension that is modelled after similar extensions for the [IMAP], extension that is modelled after similar extensions for the [IMAP],
[POP3], and [ACAP] protocols as described in [USINGTLS]. The XML [POP3], and [ACAP] protocols as described in [USINGTLS]. The XML
namespace name for the STARTTLS extension is namespace name for the STARTTLS extension is
'urn:ietf:params:xml:ns:xmpp-tls'. 'urn:ietf:params:xml:ns:xmpp-tls'.
5.2. Support 5.2. Support
Support for STARTTLS is REQUIRED in XMPP client and server Support for STARTTLS is REQUIRED in XMPP client and server
implementations. An administrator of a given deployment MAY specify implementations. An administrator of a given deployment MAY specify
that TLS is obligatory for client-to-server communication, server-to- that TLS is mandatory-to-negotiate for client-to-server
server communication, or both. An initiating entity SHOULD use TLS communication, server-to-server communication, or both. An
to secure its stream with the receiving entity before proceeding with initiating entity SHOULD use TLS to secure its stream with the
SASL authentication. receiving entity before proceeding with SASL authentication.
5.3. Stream Negotiation Rules 5.3. Stream Negotiation Rules
5.3.1. Mandatory-to-Negotiate 5.3.1. Mandatory-to-Negotiate
If the receiving entity advertises only the STARTTLS feature or if If the receiving entity advertises only the STARTTLS feature or if
the receiving entity includes the <required/> child element as the receiving entity includes the <required/> child element as
explained under Section 5.4.1, the parties MUST consider TLS as explained under Section 5.4.1, the parties MUST consider TLS as
mandatory-to-negotiate. If TLS is mandatory-to-negotiate, the mandatory-to-negotiate. If TLS is mandatory-to-negotiate, the
receiving entity SHOULD NOT advertise support for any stream feature receiving entity SHOULD NOT advertise support for any stream feature
skipping to change at page 69, line 34 skipping to change at page 72, line 27
2. Wrapping the TLS sequence number as explained in Section 6.1 of 2. Wrapping the TLS sequence number as explained in Section 6.1 of
[TLS]. [TLS].
3. Protecting client credentials by completing server authentication 3. Protecting client credentials by completing server authentication
first and then completing client authentication over the first and then completing client authentication over the
protected channel. protected channel.
Because it is relatively inexpensive to establish streams in XMPP, Because it is relatively inexpensive to establish streams in XMPP,
for the first two cases it is preferable to use an XMPP stream reset for the first two cases it is preferable to use an XMPP stream reset
(as described under Section 4.8.3.16) instead of performing TLS (as described under Section 4.9.3.16) instead of performing TLS
renegotiation. renegotiation.
The third case has improved security characteristics when the TLS The third case has improved security characteristics when the TLS
client (which might be an XMPP server) presents credentials to the client (which might be an XMPP server) presents credentials to the
TLS server. If communicating such credentials to an unauthenticated TLS server. If communicating such credentials to an unauthenticated
TLS server might leak private information, it can be appropriate to TLS server might leak private information, it can be appropriate to
complete TLS negotiation for the purpose of authenticating the TLS complete TLS negotiation for the purpose of authenticating the TLS
server to the TLS client and then attempt TLS renegotiation for the server to the TLS client and then attempt TLS renegotiation for the
purpose of authenticating the TLS client to the TLS server. purpose of authenticating the TLS client to the TLS server. However,
this case is extremely rare because the credentials presented by an
XMPP server or XMPP client acting as a TLS client are almost always
public (i.e., a PKIX certificate) and therefore providing those
credentials before authenticating the XMPP server acting as a TLS
server would not in general leak private information.
However, the third case is sufficiently rare that XMPP entities As a result, implementers are encouraged to carefully weigh the costs
SHOULD NOT blindly attempt TLS renegotiation. and benefits of TLS renegotiation before supporting it in their
software, and XMPP entities that act as TLS clients are discouraged
from attempting TLS renegotiation unless the certificate (or other
credential information) sent during TLS negotiation is known to be
private.
Support for TLS renegotiation is strictly OPTIONAL. However,
implementations that support TLS renegotiation MUST implement and use
the TLS Renegotiation Extension [TLS-NEG].
If an entity that does not support TLS renegotiation detects a If an entity that does not support TLS renegotiation detects a
renegotiation attempt, then it MUST immediately close the underlying renegotiation attempt, then it MUST immediately close the underlying
TCP connection without returning a stream error (since the violation TCP connection without returning a stream error (since the violation
has occurred at the TLS layer, not the XMPP layer; see Section 13.3). has occurred at the TLS layer, not the XMPP layer, as described under
Section 13.3).
If an entity that supports TLS renegotiation detects a TLS If an entity that supports TLS renegotiation detects a TLS
renegotiation attempt that does not use the TLS Renegotiation renegotiation attempt that does not use the TLS Renegotiation
Extension [TLS-NEG], then it MUST immediately close the underlying Extension [TLS-NEG], then it MUST immediately close the underlying
TCP connection without returning a stream error (since the violation TCP connection without returning a stream error (since the violation
has occurred at the TLS layer, not the XMPP layer; see Section 13.3). has occurred at the TLS layer, not the XMPP layer as described under
Section 13.3).
Support for TLS renegotiation is strictly OPTIONAL. However,
implementations that support TLS renegotiation MUST implement and use
the TLS Renegotiation Extension [TLS-NEG].
5.3.6. TLS Extensions 5.3.6. TLS Extensions
Either party to a stream MAY include any TLS extension during the TLS Either party to a stream MAY include any TLS extension during the TLS
negotiation itself. This is a matter for the TLS layer, not the XMPP negotiation itself. This is a matter for the TLS layer, not the XMPP
layer. layer.
5.4. Process 5.4. Process
5.4.1. Exchange of Stream Headers and Stream Features 5.4.1. Exchange of Stream Headers and Stream Features
The initiating entity resolves the hostname of the receiving entity The initiating entity resolves the FQDN of the receiving entity as
as specified under Section 3, opens a TCP connection to the specified under Section 3, opens a TCP connection to the advertised
advertised port at the resolved IP address, and sends an initial port at the resolved IP address, and sends an initial stream header
stream header to the receiving entity. to the receiving entity.
I: <stream:stream I: <stream:stream
from='juliet@im.example.com' from='juliet@im.example.com'
to='im.example.com' to='im.example.com'
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
The receiving entity MUST send a response stream header to the The receiving entity MUST send a response stream header to the
initiating entity over the TCP connection opened by the initiating initiating entity over the TCP connection opened by the initiating
entity. entity.
R: <stream:stream R: <stream:stream
from='im.example.com' from='im.example.com'
id='t7AMCin9zjMNwQKDnplntZPIDEI=' id='t7AMCin9zjMNwQKDnplntZPIDEI='
to='juliet@im.example.com' to='juliet@im.example.com'
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'>
The receiving entity then MUST send stream features to the initiating The receiving entity then MUST send stream features to the initiating
entity. If the receiving entity supports TLS, the stream features entity. If the receiving entity supports TLS, the stream features
MUST include an advertisement for support of STARTTLS negotiation, MUST include an advertisement for support of STARTTLS negotiation,
i.e., a <starttls/> element qualified by the i.e., a <starttls/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-tls' namespace. 'urn:ietf:params:xml:ns:xmpp-tls' namespace.
If the receiving entity considers STARTTLS negotiation to be If the receiving entity considers STARTTLS negotiation to be
mandatory, the <starttls/> element SHOULD contain an empty mandatory-to-negotiate, the <starttls/> element MUST contain an empty
<required/> child element. <required/> child element.
R: <stream:features> R: <stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'> <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<required/> <required/>
</starttls> </starttls>
</stream:features> </stream:features>
5.4.2. Initiation of STARTTLS Negotiation 5.4.2. Initiation of STARTTLS Negotiation
skipping to change at page 73, line 7 skipping to change at page 76, line 18
2. When using any of the mandatory-to-implement (MTI) ciphersuites 2. When using any of the mandatory-to-implement (MTI) ciphersuites
specified under Section 13.8, the receiving entity MUST present a specified under Section 13.8, the receiving entity MUST present a
certificate. certificate.
3. So that mutual certificate authentication will be possible, the 3. So that mutual certificate authentication will be possible, the
receiving entity SHOULD send a certificate request to the receiving entity SHOULD send a certificate request to the
initiating entity and the initiating entity SHOULD send a initiating entity and the initiating entity SHOULD send a
certificate (if available) to the receiving entity. certificate (if available) to the receiving entity.
4. The receiving entity SHOULD choose which certificate to present 4. The receiving entity SHOULD choose which certificate to present
based on the 'to' attribute of the initial stream header. based on the domainpart contained in the 'to' attribute of the
initial stream header (in essence, this domainpart is
functionally equivalent to the Server Name Indication defined for
TLS in [TLS-EXT]).
5. To determine if the TLS negotiation will succeed, the initiating 5. To determine if the TLS negotiation will succeed, the initiating
entity MUST attempt to validate the receiving entity's entity MUST attempt to validate the receiving entity's
certificate in accordance with the certificate validation certificate in accordance with the certificate validation
procedures specified under Section 13.7.2. procedures specified under Section 13.7.2.
6. If the initiating entity presents a certificate, the receiving 6. If the initiating entity presents a certificate, the receiving
entity too MUST attempt to validate the initiating entity's entity too MUST attempt to validate the initiating entity's
certificate in accordance with the certificate validation certificate in accordance with the certificate validation
procedures specified under Section 13.7.2. procedures specified under Section 13.7.2.
7. Following successful TLS negotiation, all further data 7. Following successful TLS negotiation, all further data
transmitted by either party MUST be encrypted. transmitted by either party MUST be protected with the negotiated
algorithms, keys, and secrets (i.e., encrypted, integrity-
protected, or both depending on the ciphersuite used).
Security Note: See Section 13.8 regarding ciphersuites that MUST Security Warning: See Section 13.8 regarding ciphersuites that
be supported for TLS; naturally, other ciphersuites MAY be MUST be supported for TLS; naturally, other ciphersuites MAY be
supported as well. supported as well.
5.4.3.2. TLS Failure 5.4.3.2. TLS Failure
If the TLS negotiation results in failure, the receiving entity MUST If the TLS negotiation results in failure, the receiving entity MUST
terminate the TCP connection. terminate the TCP connection.
The receiving entity MUST NOT send a closing </stream> tag before The receiving entity MUST NOT send a closing </stream> tag before
terminating the TCP connection, since the receiving entity and terminating the TCP connection (since the failure has occurred at the
initiating entity MUST consider the original stream to be replaced TLS layer, not the XMPP layer as described under Section 13.3).
upon failure of the TLS negotiation.
The initiating entity MAY attempt to reconnect as explained under The initiating entity MAY attempt to reconnect as explained under
Section 3.3, with or without attempting TLS negotiation (in Section 3.3, with or without attempting TLS negotiation (in
accordance with local service policy, user-configured preferences, accordance with local service policy, user-configured preferences,
etc.). etc.).
5.4.3.3. TLS Success 5.4.3.3. TLS Success
If the TLS negotiation is successful, then the entities MUST proceed If the TLS negotiation is successful, then the entities MUST proceed
as follows. as follows.
skipping to change at page 74, line 11 skipping to change at page 77, line 24
insecure manner before TLS took effect (e.g., the receiving insecure manner before TLS took effect (e.g., the receiving
entity's 'from' address or the stream ID and stream features entity's 'from' address or the stream ID and stream features
received from the receiving entity). received from the receiving entity).
2. The receiving entity MUST discard any information transmitted in 2. The receiving entity MUST discard any information transmitted in
layers above TCP that it obtained from the initiating entity in layers above TCP that it obtained from the initiating entity in
an insecure manner before TLS took effect (e.g., the initiating an insecure manner before TLS took effect (e.g., the initiating
entity's 'from' address). entity's 'from' address).
3. The initiating entity MUST send a new initial stream header to 3. The initiating entity MUST send a new initial stream header to
the receiving entity over the encrypted connection. the receiving entity over the encrypted connection (as specified
under Section 4.3.3, the initiating entity MUST NOT send a
closing </stream> 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).
I: <stream:stream I: <stream:stream
from='juliet@im.example.com' from='juliet@im.example.com'
to='im.example.com' to='im.example.com'
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
Implementation Note: The initiating entity MUST NOT send a
closing </stream> 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 4. The receiving entity MUST respond with a new response stream
header over the encrypted connection (for which it MUST generate header over the encrypted connection (for which it MUST generate
a new stream ID instead of re-using the old stream ID). a new stream ID instead of re-using the old stream ID).
R: <stream:stream R: <stream:stream
from='im.example.com' from='im.example.com'
id='vgKi/bkYME8OAj4rlXMkpucAqe4=' id='vgKi/bkYME8OAj4rlXMkpucAqe4='
to='juliet@im.example.com' to='juliet@im.example.com'
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'>
5. The receiving entity also MUST send stream features to the 5. The receiving entity also MUST send stream features to the
initiating entity, which MUST NOT include the STARTTLS feature initiating entity, which MUST NOT include the STARTTLS feature
but which SHOULD include the SASL stream feature as described but which SHOULD include the SASL stream feature as described
under Section 6. under Section 6.
R: <stream:features> R: <stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>EXTERNAL</mechanism> <mechanism>EXTERNAL</mechanism>
<mechanism>SCRAM-SHA-1-PLUS</mechanism>
<mechanism>SCRAM-SHA-1</mechanism>
<mechanism>PLAIN</mechanism> <mechanism>PLAIN</mechanism>
</mechanisms> </mechanisms>
</stream:features> </stream:features>
6. SASL Negotiation 6. SASL Negotiation
6.1. Fundamentals 6.1. Fundamentals
XMPP includes a method for authenticating a stream by means of an XMPP includes a method for authenticating a stream by means of an
XMPP-specific profile of the Simple Authentication and Security Layer XMPP-specific profile of the Simple Authentication and Security Layer
skipping to change at page 75, line 38 skipping to change at page 79, line 4
6.3.2. Restart 6.3.2. Restart
After SASL negotiation, the parties MUST restart the stream. After SASL negotiation, the parties MUST restart the stream.
6.3.3. Mechanism Preferences 6.3.3. Mechanism Preferences
Any entity that will act as a SASL client or a SASL server MUST Any entity that will act as a SASL client or a SASL server MUST
maintain an ordered list of its preferred SASL mechanisms according maintain an ordered list of its preferred SASL mechanisms according
to the client or server, where the list is ordered according to local to the client or server, where the list is ordered according to local
policy or user configuration (which SHOULD be in order of perceived policy or user configuration (which SHOULD be in order of perceived
strength to enable the strongest authentication possible). A server strength to enable the strongest authentication possible). The
MUST offer and a client MUST try SASL mechanisms in preference order. initiating entity MUST maintain its own preference order independent
For example, if the server offers the ordered list "PLAIN SCRAM-SHA-1 of the preference order of the receiving entity. A server MUST offer
and a client MUST try SASL mechanisms in preference order. For
example, if the server offers the ordered list "PLAIN SCRAM-SHA-1
GSSAPI" or "SCRAM-SHA-1 GSSAPI PLAIN" but the client's ordered list GSSAPI" or "SCRAM-SHA-1 GSSAPI PLAIN" but the client's ordered list
is "GSSAPI SCRAM-SHA-1", the client MUST try GSSAPI first and then is "GSSAPI SCRAM-SHA-1", the client MUST try GSSAPI first and then
SCRAM-SHA-1 but MUST NOT try PLAIN (since PLAIN is not on its list). SCRAM-SHA-1 but MUST NOT try PLAIN (since PLAIN is not on its list).
6.3.4. Mechanism Offers 6.3.4. Mechanism Offers
If the receiving entity considers TLS negotiation (Section 5) to be If the receiving entity considers TLS negotiation (Section 5) to be
mandatory before it will accept authentication with a particular SASL mandatory-to-negotiate before it will accept authentication with a
mechanism, it MUST NOT advertise that mechanism in its list of particular SASL mechanism, it MUST NOT advertise that mechanism in
available SASL mechanisms before TLS negotiation has been completed. its list of available SASL mechanisms before TLS negotiation has been
completed.
The receiving entity SHOULD offer the SASL EXTERNAL mechanism if both The receiving entity SHOULD offer the SASL EXTERNAL mechanism if both
of the following conditions hold: of the following conditions hold:
1. During TLS negotiation the initiating entity presented a 1. During TLS negotiation the initiating entity presented a
certificate that is acceptable to the receiving entity for certificate that is acceptable to the receiving entity for
purposes of strong identity verification in accordance with local purposes of strong identity verification in accordance with local
service policies (e.g., because said certificate is unexpired, is service policies (e.g., because said certificate is unexpired, is
unrevoked, and is anchored to a root trusted by the receiving unrevoked, and is anchored to a root trusted by the receiving
entity). entity).
skipping to change at page 76, line 36 skipping to change at page 80, line 6
for access to an XMPP network. for access to an XMPP network.
However, the receiving entity MAY offer the SASL EXTERNAL mechanism However, the receiving entity MAY offer the SASL EXTERNAL mechanism
under other circumstances, as well. under other circumstances, as well.
When the receiving entity offers the SASL EXTERNAL mechanism, the When the receiving entity offers the SASL EXTERNAL mechanism, the
receiving entity SHOULD list the EXTERNAL mechanism first among its receiving entity SHOULD list the EXTERNAL mechanism first among its
offered SASL mechanisms and the initiating entity SHOULD attempt SASL offered SASL mechanisms and the initiating entity SHOULD attempt SASL
negotiation using the EXTERNAL mechanism first (this preference will negotiation using the EXTERNAL mechanism first (this preference will
tend to increase the likelihood that the parties can negotiate mutual tend to increase the likelihood that the parties can negotiate mutual
authentication). certificate authentication).
Section 13.8 specifies SASL mechanisms that MUST be supported; Section 13.8 specifies SASL mechanisms that MUST be supported;
naturally, other SASL mechanisms MAY be supported as well. naturally, other SASL mechanisms MAY be supported as well.
Informational Note: Best practices for the use of SASL in the Informational Note: Best practices for the use of SASL in the
context of XMPP are described in [XEP-0175] for the ANONYMOUS context of XMPP are described in [XEP-0175] for the ANONYMOUS
mechanism and in [XEP-0178] for the EXTERNAL mechanism. mechanism and in [XEP-0178] for the EXTERNAL mechanism.
6.3.5. Data Formatting 6.3.5. Data Formatting
skipping to change at page 77, line 14 skipping to change at page 80, line 32
the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace as sent by the the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace as sent by the
initiating entity, until the last character of the first-level initiating entity, until the last character of the first-level
<success/> element qualified by the <success/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-sasl' namespace as sent by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace as sent by the
receiving entity). This prohibition helps to ensure proper receiving entity). This prohibition helps to ensure proper
security layer byte precision. Any such whitespace shown in the security layer byte precision. Any such whitespace shown in the
SASL examples provided in this document is included only for the SASL examples provided in this document is included only for the
sake of readability. sake of readability.
2. Any XML character data contained within the XML elements MUST be 2. Any XML character data contained within the XML elements MUST be
encoded using base64, where the encoding adheres to the encoded using base 64, where the encoding adheres to the
definition in Section 4 of [BASE64] and where the padding bits definition in Section 4 of [BASE64] and where the padding bits
are set to zero. are set to zero.
3. As formally specified in the XML schema for the 3. As formally specified in the XML schema for the
'urn:ietf:params:xml:ns:xmpp-sasl' namespace under Appendix A.4, 'urn:ietf:params:xml:ns:xmpp-sasl' namespace under Appendix A.4,
the receiving entity MAY include one or more application-specific the receiving entity MAY include one or more application-specific
child elements inside the <mechanisms/> element to provide child elements inside the <mechanisms/> element to provide
information that might be needed by the initiating entity in information that might be needed by the initiating entity in
order to complete successful SASL negotiation using one or more order to complete successful SASL negotiation using one or more
of the offered mechanisms; however, the syntax and semantics of of the offered mechanisms; however, the syntax and semantics of
all such elements are out of scope for this specification. all such elements are out of scope for this specification (see
[XEP-0233] for one example).
6.3.6. Security Layers 6.3.6. Security Layers
Upon successful SASL negotiation that involves negotiation of a Upon successful SASL negotiation that involves negotiation of a
security layer, both the initiating entity and the receiving MUST security layer, both the initiating entity and the receiving MUST
discard any application-layer state (i.e, state from the XMPP layer, discard any application-layer state (i.e, state from the XMPP layer,
excluding state from the TLS negotiation or SASL negotiation). excluding state from the TLS negotiation or SASL negotiation).
6.3.7. Simple User Name 6.3.7. Simple User Name
skipping to change at page 77, line 50 skipping to change at page 81, line 21
particular mechanism or deployment thereof is a local matter, and a particular mechanism or deployment thereof is a local matter, and a
simple user name does not necessarily map to an application simple user name does not necessarily map to an application
identifier such as a JID or JID component (e.g., a localpart). identifier such as a JID or JID component (e.g., a localpart).
However, in the absence of local information provided by the server, However, in the absence of local information provided by the server,
an XMPP client SHOULD assume that the authentication identity for an XMPP client SHOULD assume that the authentication identity for
such a SASL mechanism is a simple user name equal to the localpart of such a SASL mechanism is a simple user name equal to the localpart of
the user's JID. the user's JID.
6.3.8. Authorization Identity 6.3.8. Authorization Identity
An authorization identity is an optional identity specified by the An authorization identity is an OPTIONAL identity included by the
initiating entity; in client-to-server streams it is typically used initiating entity to specify an identity to act as (see Section 2 of
by an administrator to perform some management task on behalf of [SASL]). In client-to-server streams it would most likely be used by
another user, whereas in server-to-server streams it is typically an administrator to perform some management task on behalf of another
used to specify a particular application at a service (e.g., a multi- user, whereas in server-to-server streams it would most likely be
user chat server at conference.example.com that is hosted by the used to specify a particular add-on service at an XMPP service (e.g.,
example.com XMPP service). If the initiating entity wishes to act on a multi-user chat server at conference.example.com that is hosted by
behalf of another entity and the selected SASL mechanism supports the example.com XMPP service). If the initiating entity wishes to
transmission of an authorization identity, the initiating entity act on behalf of another entity and the selected SASL mechanism
SHOULD provide an authorization identity during SASL negotiation. If supports transmission of an authorization identity, the initiating
the initiating entity does not wish to act on behalf of another entity MUST provide an authorization identity during SASL
entity, it SHOULD NOT provide an authorization identity. negotiation. If the initiating entity does not wish to act on behalf
of another entity, it MUST NOT provide an authorization identity.
In the case of client-to-server communication, the value of an In the case of client-to-server communication, the value of an
authorization identity MUST be a bare JID (<localpart@domainpart>) authorization identity MUST be a bare JID (<localpart@domainpart>)
and not a full JID (<localpart@domainpart/resourcepart>). rather than a full JID (<localpart@domainpart/resourcepart>).
In the case of server-to-server communication, the value of an In the case of server-to-server communication, the value of an
authorization identity MUST be a domainpart only (<domainpart>). authorization identity MUST be a domainpart only (<domainpart>).
If the initiating entity provides an authorization identity during If the initiating entity provides an authorization identity during
SASL negotiation, the receiving entity is responsible for verifying SASL negotiation, the receiving entity is responsible for verifying
that the initiating entity is in fact allowed to assume the specified that the initiating entity is in fact allowed to assume the specified
authorization identity; if not, the receiving entity MUST return an authorization identity; if not, the receiving entity MUST return an
<invalid-authzid/> SASL error as described under Section 6.5.6. <invalid-authzid/> SASL error as described under Section 6.5.6.
6.3.9. Realms 6.3.9. Realms
The receiving entity MAY include a realm when negotiating certain The receiving entity MAY include a realm when negotiating certain
SASL mechanisms. If the receiving entity does not communicate a SASL mechanisms (e.g., both the GSSAPI and DIGEST-MD5 mechanisms
realm, the initiating entity MUST NOT assume that any realm exists. allow the authentication exchange to include a realm, though in
The realm MUST be used only for the purpose of authentication; in different ways, whereas the EXTERNAL, SCRAM, and PLAIN mechanisms do
particular, an initiating entity MUST NOT attempt to derive an XMPP not). If the receiving entity does not communicate a realm, the
hostname from the realm information provided by the receiving entity. initiating entity MUST NOT assume that any realm exists. The realm
MUST be used only for the purpose of authentication; in particular,
an initiating entity MUST NOT attempt to derive an XMPP domainpart
from the realm information provided by the receiving entity.
6.3.10. Round Trips 6.3.10. Round Trips
[SASL] specifies that a using protocol such as XMPP can define two [SASL] specifies that a using protocol such as XMPP can define two
methods by which the protocol can save round trips where allowed for methods by which the protocol can save round trips where allowed for
the SASL mechanism: the SASL mechanism:
1. When the SASL client (the XMPP "initiating entity") requests an 1. When the SASL client (the XMPP "initiating entity") requests an
authentication exchange, it can include "initial response" data authentication exchange, it can include "initial response" data
with its request if appropriate for the SASL mechanism in use. with its request if appropriate for the SASL mechanism in use.
skipping to change at page 79, line 18 skipping to change at page 82, line 40
servers to support these methods and RECOMMENDED to use them; however servers to support these methods and RECOMMENDED to use them; however
clients and servers MUST support the less efficient modes as well. clients and servers MUST support the less efficient modes as well.
6.4. Process 6.4. Process
The process for SASL negotiation is as follows. The process for SASL negotiation is as follows.
6.4.1. Exchange of Stream Headers and Stream Features 6.4.1. Exchange of Stream Headers and Stream Features
If SASL negotiation follows successful STARTTLS negotiation If SASL negotiation follows successful STARTTLS negotiation
(Section 5), then the SASL negotiation occurs over the encrypted (Section 5), then the SASL negotiation occurs over the protected
stream that has already been negotiated. If not, the initiating stream that has already been negotiated. If not, the initiating
entity resolves the hostname of the receiving entity as specified entity resolves the FQDN of the receiving entity as specified under
under Section 3, opens a TCP connection to the advertised port at the Section 3, opens a TCP connection to the advertised port at the
resolved IP address, and sends an initial stream header to the resolved IP address, and sends an initial stream header to the
receiving entity. receiving entity. In either case, the receiving entity will receive
an initial stream from the initiating entity.
I: <stream:stream I: <stream:stream
from='juliet@im.example.com' from='juliet@im.example.com'
to='im.example.com' to='im.example.com'
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
The receiving entity MUST send a response stream header to the When the receiving entity processes an initial stream header from the
initiating entity (for which it MUST generate a new stream ID instead initiating entity, it MUST send a response stream header to the
of re-using the old stream ID). initiating entity (for which it MUST generate a unique stream ID; if
TLS negotiation has already succeeded then this stream ID MUST be
different from the stream ID sent before TLS negotiation succeeded).
R: <stream:stream R: <stream:stream
from='im.example.com' from='im.example.com'
id='vgKi/bkYME8OAj4rlXMkpucAqe4=' id='vgKi/bkYME8OAj4rlXMkpucAqe4='
to='juliet@im.example.com' to='juliet@im.example.com'
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'>
The receiving entity also MUST send stream features to the initiating The receiving entity also MUST send stream features to the initiating
entity. If the receiving entity supports SASL, the stream features entity. The stream features SHOULD include an advertisement for
SHOULD include an advertisement for support of SASL negotiation, support of SASL negotiation, i.e., a <mechanisms/> element qualified
i.e., a <mechanisms/> element qualified by the by the 'urn:ietf:params:xml:ns:xmpp-sasl' namespace. Typically there
'urn:ietf:params:xml:ns:xmpp-sasl' namespace; typically the only case are only three cases in which support for SASL negotiation would not
in which support for SASL negotiation would not be advertised here is be advertised here:
before STARTTLS negotiation when TLS is required.
o TLS negotiation needs to happen before SASL can be offered (i.e.,
TLS is required and the receiving entity is responding to the very
first initial stream header it has received for this connection
attempt).
o SASL negotiation is impossible for a server-to-server connection
(i.e., the initiating server has not provided a certificate that
would enable strong authentication and therefore the receiving
server is falling back to weak identity verification using the
Server Dialback protocol [XEP-0220]).
o SASL has already been negotiated (i.e., the receiving entity is
responding to an initial stream header sent as a stream restart
after successful SASL negotiation).
The <mechanisms/> element MUST contain one <mechanism/> child element The <mechanisms/> element MUST contain one <mechanism/> child element
for each authentication mechanism the receiving entity offers to the for each authentication mechanism the receiving entity offers to the
initiating entity. The order of <mechanism/> elements in the XML initiating entity. As noted, the order of <mechanism/> elements in
indicates the preference order of the SASL mechanisms according to the XML indicates the preference order of the SASL mechanisms
the receiving entity; however the initiating entity MUST maintain its according to the receiving entity (which is not necessarily the
own preference order independent of the preference order of the preference order according to the initiating entity).
receiving entity.
R: <stream:features> R: <stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>EXTERNAL</mechanism> <mechanism>EXTERNAL</mechanism>
<mechanism>SCRAM-SHA-1-PLUS</mechanism>
<mechanism>SCRAM-SHA-1</mechanism>
<mechanism>PLAIN</mechanism> <mechanism>PLAIN</mechanism>
</mechanisms> </mechanisms>
</stream:features> </stream:features>
6.4.2. Initiation 6.4.2. Initiation
In order to begin the SASL negotiation, the initiating entity sends In order to begin the SASL negotiation, the initiating entity sends
an <auth/> element qualified by the an <auth/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-sasl' namespace and includes an 'urn:ietf:params:xml:ns:xmpp-sasl' namespace and includes an
appropriate value for the 'mechanism' attribute, thus starting the appropriate value for the 'mechanism' attribute, thus starting the
skipping to change at page 80, line 38 skipping to change at page 84, line 34
MAY contain XML character data (in SASL terminology, the "initial MAY contain XML character data (in SASL terminology, the "initial
response") if the mechanism supports or requires it; if the response") if the mechanism supports or requires it; if the
initiating entity needs to send a zero-length initial response, it initiating entity needs to send a zero-length initial response, it
MUST transmit the response as a single equals sign character ("="), MUST transmit the response as a single equals sign character ("="),
which indicates that the response is present but contains no data. which indicates that the response is present but contains no data.
I: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' I: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='PLAIN'>AGp1bGlldAByMG0zMG15cjBtMzA=</auth> mechanism='PLAIN'>AGp1bGlldAByMG0zMG15cjBtMzA=</auth>
If the initiating entity subsequently sends another <auth/> element If the initiating entity subsequently sends another <auth/> element
(even if the ongoing authentication handshake has not yet completed), and the ongoing authentication handshake has not yet completed, the
the server SHOULD discard the ongoing handshake and begin a new receiving entity MUST discard the ongoing handshake and MUST process
handshake for the subsequently requested SASL mechanism. a new handshake for the subsequently requested SASL mechanism.
6.4.3. Challenge-Response Sequence 6.4.3. Challenge-Response Sequence
If necessary, the receiving entity challenges the initiating entity If necessary, the receiving entity challenges the initiating entity
by sending a <challenge/> element qualified by the by sending a <challenge/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-sasl' namespace; this element MAY 'urn:ietf:params:xml:ns:xmpp-sasl' namespace; this element MAY
contain XML character data (which MUST be generated in accordance contain XML character data (which MUST be generated in accordance
with the definition of the SASL mechanism chosen by the initiating with the definition of the SASL mechanism chosen by the initiating
entity). entity).
skipping to change at page 82, line 15 skipping to change at page 86, line 10
Where appropriate for the chosen SASL mechanism, the receiving entity Where appropriate for the chosen SASL mechanism, the receiving entity
SHOULD allow a configurable but reasonable number of retries (at SHOULD allow a configurable but reasonable number of retries (at
least 2 and no more than 5); this enables the initiating entity least 2 and no more than 5); this enables the initiating entity
(e.g., an end-user client) to tolerate incorrectly-provided (e.g., an end-user client) to tolerate incorrectly-provided
credentials (e.g., a mistyped password) without being forced to credentials (e.g., a mistyped password) without being forced to
reconnect. reconnect.
If the initiating entity attempts a reasonable number of retries with If the initiating entity attempts a reasonable number of retries with
the same SASL mechanism and all attempts fail, it MAY fall back to the same SASL mechanism and all attempts fail, it MAY fall back to
the next mechanism in its ordered list by sending a new <auth/> the next mechanism in its ordered list by sending a new <auth/>
request to the receiving entity, this starting a new handshake for request to the receiving entity, thus starting a new handshake for
that authentication mechanism. If all handshakes fail and there are that authentication mechanism. If all handshakes fail and there are
no remaining mechanisms in the initiating entity's list of supported no remaining mechanisms in the initiating entity's list of supported
and acceptable mechanisms, the initiating entity SHOULD simply close and acceptable mechanisms, the initiating entity SHOULD simply close
the stream. the stream.
If the initiating entity exceeds the number of retries, the receiving If the initiating entity exceeds the number of retries, the receiving
entity MUST return a stream error, which SHOULD be <policy- entity MUST return a stream error, which SHOULD be <policy-
violation/> (although some existing implementations send <not- violation/> (although some existing implementations send <not-
authorized/> instead). authorized/> instead).
skipping to change at page 82, line 38 skipping to change at page 86, line 33
other SASL mechanism based on the security context established other SASL mechanism based on the security context established
during TLS negotiation, the receiving entity MAY attempt to during TLS negotiation, the receiving entity MAY attempt to
complete weak identity verification using the Server Dialback complete weak identity verification using the Server Dialback
protocol [XEP-0220]; however, if according to local service protocol [XEP-0220]; however, if according to local service
policies weak identity verification is insufficient then the policies weak identity verification is insufficient then the
receiving entity SHOULD instead close the stream with a <policy- receiving entity SHOULD instead close the stream with a <policy-
violation/> stream error. violation/> stream error.
6.4.6. SASL Success 6.4.6. SASL Success
Before considering the SASL handshake to be a success, the receiving Before considering the SASL handshake to be a success, if the
entity SHOULD correlate the authentication identity resulting from initiating entity provided a 'from' attribute on an initial stream
the SASL negotiation with the 'from' address (if any; see header whose confidentiality and integrity were ensured via TLS or an
Section 4.6.1) of the stream header it received from the initiating equivalent security layer (such as the SASL GSSAPI mechanism) then
entity. If the two identities do not match, the receiving entity the receiving entity SHOULD correlate the authentication identity
SHOULD terminate the connection attempt. resulting from the SASL negotiation with that 'from' address; if the
two identities do not match then the receiving entity SHOULD
terminate the connection attempt (however, the receiving entity might
have legitimate reasons not to terminate the connection attempt, for
example because it has overridden a connecting client's address to
correct the JID format or assign a JID based on information presented
in an end-user certificate).
The receiving entity reports success of the handshake by sending a The receiving entity reports success of the handshake by sending a
<success/> element qualified by the <success/> element qualified by the
'urn:ietf:params:xml:ns:xmpp-sasl' namespace; this element MAY 'urn:ietf:params:xml:ns:xmpp-sasl' namespace; this element MAY
contain XML character data (in SASL terminology, "additional data contain XML character data (in SASL terminology, "additional data
with success") if the chosen SASL mechanism supports or requires it; with success") if the chosen SASL mechanism supports or requires it;
if the receiving entity needs to send additional data of zero length, if the receiving entity needs to send additional data of zero length,
it MUST transmit the data as a single equals sign character ("="). it MUST transmit the data as a single equals sign character ("=").
R: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/> R: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Informational Note: The authorization identity communicated during Informational Note: For client-to-server streams, the
SASL negotiation is used to determine the canonical address for authorization identity communicated during SASL negotiation is
the initiating client according to the receiving server, as used to determine the canonical address for the initiating client
described under Section 4.2.6. according to the receiving server, as described under
Section 4.3.6.
Upon receiving the <success/> element, the initiating entity MUST Upon receiving the <success/> element, the initiating entity MUST
initiate a new stream over the existing TCP connection by sending a initiate a new stream over the existing TCP connection by sending a
new initial stream header to the receiving entity. new initial stream header to the receiving entity (as specified under
Section 4.3.3, the initiating entity MUST NOT send a closing
</stream> 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 SASL negotiation).
I: <stream:stream I: <stream:stream
from='juliet@im.example.com' from='juliet@im.example.com'
to='im.example.com' to='im.example.com'
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams' xmlns:stream='http://etherx.jabber.org/streams'>
Implementation Note: The initiating entity MUST NOT send a closing
</stream> tag before sending the new initial stream header, since
the receiving entity and initiating entity MUST consider the
original stream to be replaced upon sending or receiving the
<success/> element.
Upon receiving the new initial stream header from the initiating Upon receiving the new initial stream header from the initiating
entity, the receiving entity MUST respond by sending a new response entity, the receiving entity MUST respond by sending a new response
stream header to the initiating entity (for which it MUST generate a stream header to the initiating entity (for which it MUST generate a
new stream ID instead of re-using the old stream ID). new stream ID instead of re-using the old stream ID).
R: <stream:stream R: <stream:stream
from='im.example.com' from='im.example.com'
id='gPybzaOzBmaADgxKXu9UClbprp0=' id='gPybzaOzBmaADgxKXu9UClbprp0='
to='juliet@im.example.com' to='juliet@im.example.com'
skipping to change at page 84, line 7 skipping to change at page 88, line 7
The receiving entity MUST also send stream features, containing any The receiving entity MUST also send stream features, containing any
further available features or containing no features (via an empty further available features or containing no features (via an empty
<features/> element). <features/> element).
R: <stream:features> R: <stream:features>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/> <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
</stream:features> </stream:features>
6.5. SASL Errors 6.5. SASL Errors
The syntax of SASL errors is as follows, where "defined-condition" is The syntax of SASL errors is as follows , where the XML data shown
one of the SASL-related error conditions defined in the following within the square brackets '[' and ']' is OPTIONAL.
sections and XML data shown within the square brackets '[' and ']' is
OPTIONAL.
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<defined-condition/> <defined-condition/>
[<text xml:lang='langcode'> [<text xml:lang='langcode'>
OPTIONAL descriptive text OPTIONAL descriptive text
</text>] </text>]
</failure> </failure>
Inclusion of a defined condition is REQUIRED. The "defined-condition" MUST be one of the SASL-related error
conditions defined in the following sections.
Inclusion of the <text/> element is OPTIONAL, and can be used to Inclusion of the <text/> element is OPTIONAL, and can be used to
provide application-specific information about the error condition, provide application-specific information about the error condition,
which information MAY be displayed to a human but only as a which information MAY be displayed to a human but only as a
supplement to the defined condition. supplement to the defined condition.
Because XMPP itself defines an application profile of SASL and there
is no expectation that more specialized XMPP applications will be
built on top of SASL, the SASL error format does not provide
extensibility for application-specific error conditions as is done
for XML streams (Section 4.9.4) and XML stanzas (Section 8.3.4).
6.5.1. aborted 6.5.1. aborted
The receiving entity acknowledges an <abort/> element sent by the The receiving entity acknowledges that the authentication handshake
initiating entity; sent in reply to the <abort/> element. has been aborted by the initiating entity; sent in reply to the
<abort/> element.
I: <abort xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/> I: <abort xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
R: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> R: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<aborted/> <aborted/>
</failure> </failure>
6.5.2. account-disabled 6.5.2. account-disabled
The account of the initiating entity has been temporarily disabled; The account of the initiating entity has been temporarily disabled;
skipping to change at page 85, line 22 skipping to change at page 89, line 30
[ ... ] [ ... ]
</response> </response>
R: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> R: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<credentials-expired/> <credentials-expired/>
</failure> </failure>
6.5.4. encryption-required 6.5.4. encryption-required
The mechanism requested by the initiating entity cannot be used The mechanism requested by the initiating entity cannot be used
unless the underlying stream is encrypted; sent in reply to an unless the confidentiality and integrity of the underlying stream are
<auth/> element (with or without initial response data). ensured (typically via TLS); sent in reply to an <auth/> element
(with or without initial response data).
I: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' I: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='PLAIN'>AGp1bGlldAByMG0zMG15cjBtMzA=</auth> mechanism='PLAIN'>AGp1bGlldAByMG0zMG15cjBtMzA=</auth>
R: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> R: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<encryption-required/> <encryption-required/>
</failure> </failure>
6.5.5. incorrect-encoding 6.5.5. incorrect-encoding
The data provided by the initiating entity could not be processed The data provided by the initiating entity could not be processed
because the [BASE64] encoding is incorrect (e.g., because the because the Base64 encoding is incorrect (e.g., because the encoding
encoding does not adhere to the definition in Section 4 of [BASE64]); does not adhere to the definition in Section 4 of [BASE64]); sent in
sent in reply to a <response/> element or an <auth/> element with reply to a <response/> element or an <auth/> element with initial
initial response data. response data.
I: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' I: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='DIGEST-MD5'>[ ... ]</auth> mechanism='DIGEST-MD5'>[ ... ]</auth>
R: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> R: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<incorrect-encoding/> <incorrect-encoding/>
</failure> </failure>
6.5.6. invalid-authzid 6.5.6. invalid-authzid
skipping to change at page 86, line 15 skipping to change at page 90, line 29
I: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> I: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
[ ... ] [ ... ]
</response> </response>
R: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> R: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<invalid-authzid/> <invalid-authzid/>
</failure> </failure>
6.5.7. invalid-mechanism 6.5.7. invalid-mechanism
The initiating entity did not provide a mechanism or requested a The initiating entity did not specify a mechanism, or requested a
mechanism that is not supported by the receiving entity; sent in mechanism that is not supported by the receiving entity; sent in
reply to an <auth/> element. reply to an <auth/> element.
I: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' I: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='CRAM-MD5'/> mechanism='CRAM-MD5'/>
R: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> R: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<invalid-mechanism/> <invalid-mechanism/>
</failure> </failure>
skipping to change at page 87, line 15 skipping to change at page 91, line 27
I: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' I: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='PLAIN'>AGp1bGlldAByMG0zMG15cjBtMzA=</auth> mechanism='PLAIN'>AGp1bGlldAByMG0zMG15cjBtMzA=</auth>
R: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> R: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism-too-weak/> <mechanism-too-weak/>
</failure> </failure>
6.5.10. not-authorized 6.5.10. not-authorized
The authentication failed because the initiating entity did not The authentication failed because the initiating entity did not
provide proper credentials or the receiving entity has detected an provide proper credentials or because the receiving entity has
attack but wishes to disclose as little information as possible to detected an attack but wishes to disclose as little information as
the attacker; sent in reply to a <response/> element or an <auth/> possible to the attacker; sent in reply to a <response/> element or
element with initial response data. an <auth/> element with initial response data.
I: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> I: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
[ ... ] [ ... ]
</response> </response>
R: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> R: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<not-authorized/> <not-authorized/>
</failure> </failure>
Security Note: This error condition includes but is not limited to Security Warning: This error condition includes but is not limited
the case of incorrect credentials or a nonexistent username. In to the case of incorrect credentials or a nonexistent username.
order to discourage directory harvest attacks, no differentiation In order to discourage directory harvest attacks, no
is made between incorrect credentials and a nonexistent username. differentiation is made between incorrect credentials and a
nonexistent username.
6.5.11. temporary-auth-failure 6.5.11. temporary-auth-failure
The authentication failed because of a temporary error condition The authentication failed because of a temporary error condition
within the receiving entity, and it is advisable for the initiating within the receiving entity, and it is advisable for the initiating
entity to try again later; sent in reply to an <auth/> element or a entity to try again later; sent in reply to an <auth/> element or a
<response/> element. <response/> element.
I: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> I: <response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
[ ... ] [ ... ]
skipping to change at page 88, line 45 skipping to change at page 93, line 17
7.1. Fundamentals 7.1. Fundamentals
After a client authenticates with a server, it MUST bind a specific After a client authenticates with a server, it MUST bind a specific
resource to the stream so that the server can properly address the resource to the stream so that the server can properly address the
client. That is, there MUST be an XMPP resource associated with the client. That is, there MUST be an XMPP resource associated with the
bare JID (<localpart@domainpart>) of the client, so that the address bare JID (<localpart@domainpart>) of the client, so that the address
for use over that stream is a full JID of the form for use over that stream is a full JID of the form
<localpart@domainpart/resource> (including the resourcepart). This <localpart@domainpart/resource> (including the resourcepart). This
ensures that the server can deliver XML stanzas to and receive XML ensures that the server can deliver XML stanzas to and receive XML
stanzas from the client in relation to entities other than the server stanzas from the client in relation to entities other than the server
itself or the client's account, as explained under Section 10 (the itself or the client's account, as explained under Section 10.
client could exchange stanzas with the server itself or the client's
account before binding a resource since the full JID is needed only Informational Note: The client could exchange stanzas with the
for addressing outside the context of the stream negotiated between server itself or the client's account before binding a resource
the client and the server, but this is not commonly done). since the full JID is needed only for addressing outside the
context of the stream negotiated between the client and the
server, but this is not commonly done.
After a client has bound a resource to the stream, it is referred to After a client has bound a resource to the stream, it is referred to
as a "connected resource". A server SHOULD allow an entity to as a "connected resource". A server SHOULD allow an entity to
maintain multiple connected resources simultaneously, where each maintain multiple connected resources simultaneously, where each
connected resource is associated with a distinct XML stream and connected resource is associated with a distinct XML stream and is
differentiated from the other connected resources by a distinct differentiated from the other connected resources by a distinct
resourcepart. resourcepart.
Security Note: A server SHOULD enable the administrator of an XMPP Security Warning: A server SHOULD enable the administrator of an
service to limit the number of connected resources in order to XMPP service to limit the number of connected resources in order
prevent certain denial of service attacks as described under to prevent certain denial of service attacks as described under
Section 13.12. Section 13.12.
If, before completing the resource binding step, the client attempts If, before completing the resource binding step, the client attempts
to send an XML stanza to an entity other than the server itself or to send an XML stanza to an entity other than the server itself or
the client's account, the server MUST NOT process the stanza and MUST the client's account, the server MUST NOT process the stanza and MUST
return a <not-authorized/> stream error to the client. return a <not-authorized/> stream error to the client.
The XML namespace name for the resource binding extension is The XML namespace name for the resource binding extension is
'urn:ietf:params:xml:ns:xmpp-bind'. 'urn:ietf:params:xml:ns:xmpp-bind'.
skipping to change at page 90, line 18 skipping to change at page 94, line 40
to='juliet@im.example.com' to='juliet@im.example.com'
version='1.0' version='1.0'
xml:lang='en' xml:lang='en'
xmlns='jabber:client' xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'> xmlns:stream='http://etherx.jabber.org/streams'>
S: <stream:features> S: <stream:features>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/> <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
</stream:features> </stream:features>
Upon being informed that resource binding is mandatory, the client Upon being informed that resource binding is mandatory-to-negotiate,
MUST bind a resource to the stream as described in the following the client MUST bind a resource to the stream as described in the
sections. following sections.
7.5. Generation of Resource Identifiers 7.5. Generation of Resource Identifiers
A resourcepart MUST at a minimum be unique among the connected A resourcepart MUST at a minimum be unique among the connected
resources for that <localpart@domainpart>. Enforcement of this resources for that <localpart@domainpart>. Enforcement of this
policy is the responsibility of the server. policy is the responsibility of the server.
Security Note: A resourcepart can be security-critical. For Security Warning: A resourcepart can be security-critical. For
example, if a malicious entity can guess a client's resourcepart example, if a malicious entity can guess a client's resourcepart
then it might be able to determine if the client (and therefore then it might be able to determine if the client (and therefore
the controlling principal) is online or offline, thus resulting in the controlling principal) is online or offline, thus resulting in
a presence leak as described under Section 13.10.2. To prevent a presence leak as described under Section 13.10.2. To prevent
that possibility, a client can either (1) generate a random that possibility, a client can either (1) generate a random
resourcepart on its own or (2) ask the server to generate a resourcepart on its own or (2) ask the server to generate a
resourcepart on its behalf, which MUST be random (see [RANDOM]). resourcepart on its behalf. One method for ensuring that the
One method for ensuring that the resourcepart is random is to resourcepart is random is to generate a Universally Unique
generate a Universally Unique Identifier (UUID) as specified in Identifier (UUID) as specified in [UUID].
[UUID].
7.6. Server-Generated Resource Identifier 7.6. Server-Generated Resource Identifier
A server MUST be able to generate an XMPP resourcepart on behalf of a A server MUST be able to generate an XMPP resourcepart on behalf of a
client. client. The resourcepart generated by the server MUST be random (see
[RANDOM]).
7.6.1. Success Case 7.6.1. Success Case
A client requests a server-generated resourcepart by sending an IQ A client requests a server-generated resourcepart by sending an IQ
stanza of type "set" (see Section 8.2.3) containing an empty <bind/> stanza of type "set" (see Section 8.2.3) containing an empty <bind/>
element qualified by the 'urn:ietf:params:xml:ns:xmpp-bind' element qualified by the 'urn:ietf:params:xml:ns:xmpp-bind'
namespace. namespace.
C: <iq id='tn281v37' type='set'> C: <iq id='tn281v37' type='set'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/> <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
skipping to change at page 91, line 25 skipping to change at page 95, line 45
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'> <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<jid> <jid>
juliet@im.example.com/4db06f06-1ea4-11dc-aca3-000bcd821bfb juliet@im.example.com/4db06f06-1ea4-11dc-aca3-000bcd821bfb
</jid> </jid>
</bind> </bind>
</iq> </iq>
7.6.2. Error Cases 7.6.2. Error Cases
When a client asks the server to generate a resourcepart during When a client asks the server to generate a resourcepart during
resource binding, the following stanza error conditions are defined resource binding, the following stanza error conditions are defined:
(and others not specified here are possible; see under Section 8.3):
o The account has reached a limit on the number of simultaneous o The account has reached a limit on the number of simultaneous
connected resources allowed. connected resources allowed.
o The client is otherwise not allowed to bind a resource to the o The client is otherwise not allowed to bind a resource to the
stream. stream.
Naturally, it is possible that error conditions not specified here
might occur, as described under under Section 8.3.
7.6.2.1. Resource Constraint 7.6.2.1. Resource Constraint
If the account has reached a limit on the number of simultaneous If the account has reached a limit on the number of simultaneous
connected resources allowed, the server MUST return a <resource- connected resources allowed, the server MUST return a <resource-
constraint/> stanza error. constraint/> stanza error.
S: <iq id='wy2xa82b4' type='error'> S: <iq id='tn281v37' type='error'>
<error type='wait'> <error type='wait'>
<resource-constraint <resource-constraint
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
7.6.2.2. Not Allowed 7.6.2.2. Not Allowed
If the client is otherwise not allowed to bind a resource to the If the client is otherwise not allowed to bind a resource to the
stream, the server MUST return a <not-allowed/> stanza error. stream, the server MUST return a <not-allowed/> stanza error.
S: <iq id='wy2xa82b4' type='error'> S: <iq id='tn281v37' type='error'>
<error type='cancel'> <error type='cancel'>
<not-allowed <not-allowed
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
7.7. Client-Submitted Resource Identifier 7.7. Client-Submitted Resource Identifier
Instead of asking the server to generate a resourcepart on its Instead of asking the server to generate a resourcepart on its
behalf, a client MAY attempt to submit a resourcepart that it has behalf, a client MAY attempt to submit a resourcepart that it has
skipping to change at page 93, line 4 skipping to change at page 97, line 25
Alternatively, in accordance with local service policies the server Alternatively, in accordance with local service policies the server
MAY refuse the client-submitted resourcepart and override it with a MAY refuse the client-submitted resourcepart and override it with a
resourcepart that the server generates. resourcepart that the server generates.
S: <iq id='wy2xa82b4' type='result'> S: <iq id='wy2xa82b4' type='result'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'> <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<jid> <jid>
juliet@im.example.com/balcony 4db06f06-1ea4-11dc-aca3-000bcd821bfb juliet@im.example.com/balcony 4db06f06-1ea4-11dc-aca3-000bcd821bfb
</jid> </jid>
</bind> </bind>
</iq> </iq>
7.7.2. Error Cases 7.7.2. Error Cases
When a client attempts to submit its own XMPP resourcepart during When a client attempts to submit its own XMPP resourcepart during
resource binding, the following stanza error conditions are defined resource binding, the following stanza error conditions are defined
in addition to those described under Section 7.6.2 (and others not in addition to those described under Section 7.6.2:
specified here are possible; see under Section 8.3):
o The provided resourcepart cannot be processed by the server. o The provided resourcepart cannot be processed by the server.
o The provided resourcepart is already in use. o The provided resourcepart is already in use.
Naturally, it is possible that error conditions not specified here
might occur, as described under under Section 8.3.
7.7.2.1. Bad Request 7.7.2.1. Bad Request
If the provided resourcepart cannot be processed by the server (e.g. If the provided resourcepart cannot be processed by the server (e.g.
because it is of zero length or because it is not in accordance with because it is of zero length or because it otherwise violates the
the Resourceprep profile of stringprep specified in [XMPP-ADDR]), the rules for resourceparts specified in [XMPP-ADDR]), the server can
server MAY return a <bad-request/> stanza error (but SHOULD instead return a <bad-request/> stanza error (but SHOULD instead process the
apply the Resourceprep profile or otherwise process the resourcepart resourcepart so that it is in conformance).
so that it is in conformance).
S: <iq id='wy2xa82b4' type='error'> S: <iq id='wy2xa82b4' type='error'>
<error type='modify'> <error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
7.7.2.2. Conflict 7.7.2.2. Conflict
If there is a currently-connected client whose session has the If there is a currently-connected client whose session has the
skipping to change at page 93, line 52 skipping to change at page 98, line 25
This behavior is encouraged, because it simplifies the resource This behavior is encouraged, because it simplifies the resource
binding process for client implementations. binding process for client implementations.
2. Disallow the resource binding attempt of the newly-connecting 2. Disallow the resource binding attempt of the newly-connecting
client and maintain the session of the currently-connected client and maintain the session of the currently-connected
client. client.
This behavior is neither encouraged nor discouraged, despite the This behavior is neither encouraged nor discouraged, despite the
fact that it was implicitly encouraged in RFC 3920; however, note fact that it was implicitly encouraged in RFC 3920; however, note
that handling of the <conflict/> error described below is that handling of the <conflict/> error is unevenly supported
unevenly supported among existing client implementations, which among existing client implementations, which often treat it as an
often treat it as an authentication error and have been observed authentication error and have been observed to discard cached
to discard cached credentials when receiving it. credentials when receiving it.
3. Terminate the session of the currently-connected client and allow 3. Terminate the session of the currently-connected client and allow
the resource binding attempt of the newly-connecting client. the resource binding attempt of the newly-connecting client.
Although this was the traditional behavior of early XMPP server Although this was the traditional behavior of early XMPP server
implementations, it is now discouraged because it can lead to a implementations, it is now discouraged because it can lead to a
neverending cycle of two clients effectively disconnecting each neverending cycle of two clients effectively disconnecting each
other; however, note that this behavior can be appropriate in other; however, note that this behavior can be appropriate in
some deployment scenarios or if the server knows that the some deployment scenarios or if the server knows that the
currently-connected client has a dead connection or broken stream currently-connected client has a dead connection or broken stream
as described under Section 4.5. as described under Section 4.6.
If the server follows behavior #1, it returns an <iq/> stanza of type If the server follows behavior #1, it returns an <iq/> stanza of type
"result" to the newly-connecting client, where the <jid/> child of "result" to the newly-connecting client, where the <jid/> child of
the <bind/> element contains XML character data that indicates the the <bind/> element contains XML character data that indicates the
full JID of the client, including the resourcepart that was generated full JID of the client, including the resourcepart that was generated
by the server. by the server.
S: <iq id='wy2xa82b4' type='result'> S: <iq id='wy2xa82b4' type='result'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'> <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<jid> <jid>
skipping to change at page 94, line 48 skipping to change at page 99, line 22
different resourcepart before making another attempt to bind a different resourcepart before making another attempt to bind a
resource). resource).
S: <iq id='wy2xa82b4' type='error'> S: <iq id='wy2xa82b4' type='error'>
<error type='modify'> <error type='modify'>
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
If the server follows behavior #3, it sends a <conflict/> stream If the server follows behavior #3, it sends a <conflict/> stream
error to the currently-connected client and returns an IQ stanza of error to the currently-connected client (as described under
type "result" (indicating success) in response to the resource Section 4.9.3.3) and returns an IQ stanza of type "result"
binding attempt of the newly-connecting client. (indicating success) in response to the resource binding attempt of
the newly-connecting client.
S: <iq id='wy2xa82b4' type='result'> S: <iq id='wy2xa82b4' type='result'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'> <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<jid> <jid>
juliet@im.example.com/balcony juliet@im.example.com/balcony
</jid> </jid>
</bind> </bind>
</iq> </iq>
7.7.3. Retries 7.7.3. Retries
skipping to change at page 95, line 40 skipping to change at page 100, line 14
are five common attributes for these stanza types. These common are five common attributes for these stanza types. These common
attributes, as well as the basic semantics of the three stanza types, attributes, as well as the basic semantics of the three stanza types,
are defined in this specification; more detailed information are defined in this specification; more detailed information
regarding the syntax of XML stanzas for instant messaging and regarding the syntax of XML stanzas for instant messaging and
presence applications is provided in [XMPP-IM], and for other presence applications is provided in [XMPP-IM], and for other
applications in the relevant XMPP extension specifications. applications in the relevant XMPP extension specifications.
Support for the XML stanza syntax and semantics defined in this Support for the XML stanza syntax and semantics defined in this
specification is REQUIRED in XMPP client and server implementations. specification is REQUIRED in XMPP client and server implementations.
Security Note: A server MUST NOT process a partial stanza and MUST Security Warning: A server MUST NOT process a partial stanza and
NOT attach meaning to the transmission timing of any part of a MUST NOT attach meaning to the transmission timing of any part of
stanza (before receipt of the close tag). a stanza (before receipt of the close tag).
8.1. Common Attributes 8.1. Common Attributes
The following five attributes are common to message, presence, and IQ The following five attributes are common to message, presence, and IQ
stanzas. stanzas.
8.1.1. to 8.1.1. to
The 'to' attribute specifies the JID of the intended recipient for The 'to' attribute specifies the JID of the intended recipient for
the stanza. the stanza.
skipping to change at page 96, line 20 skipping to change at page 100, line 38
<message to='romeo@example.net'> <message to='romeo@example.net'>
<body>Art thou not Romeo, and a Montague?</body> <body>Art thou not Romeo, and a Montague?</body>
</message> </message>
For information about server processing of inbound and outbound XML For information about server processing of inbound and outbound XML
stanzas based on the 'to' address, refer to Section 10. stanzas based on the 'to' address, refer to Section 10.
8.1.1.1. Client-to-Server Streams 8.1.1.1. Client-to-Server Streams
The following rules apply to inclusion of the 'to' attribute in The following rules apply to inclusion of the 'to' attribute in
stanzas sent from the client to the server over an XML stream stanzas sent from a connected client to its server over an XML stream
qualified by the 'jabber:client' namespace. qualified by the 'jabber:client' namespace.
1. A stanza with a specific intended recipient (e.g., a conversation 1. A stanza with a specific intended recipient (e.g., a conversation
partner, a remote service, the server itself, even another partner, a remote service, the server itself, even another
resource associated with the user's bare JID) MUST possess a 'to' resource associated with the user's bare JID) MUST possess a 'to'
attribute whose value is an XMPP address. attribute whose value is an XMPP address.
2. A stanza sent from a client to a server for direct processing by 2. A stanza sent from a client to a server for direct processing by
the server as described in [XMPP-IM] for rosters (e.g., presence the server (e.g., roster processing as described in [XMPP-IM] or
sent to the server for broadcasting to other entities) MUST NOT presence sent to the server for broadcasting to other entities)
possess a 'to' attribute. MUST NOT possess a 'to' attribute.
The following rules apply to inclusion of the 'to' attribute in The following rules apply to inclusion of the 'to' attribute in
stanzas sent from the server to the client over an XML stream stanzas sent from a server to a connected client over an XML stream
qualified by the 'jabber:client' namespace. qualified by the 'jabber:client' namespace.
1. If the server has received the stanza from another connected 1. If the server has received the stanza from another connected
client or from another server, the server MUST NOT modify the client or from a peer server, the server MUST NOT modify the 'to'
'to' address before delivering the stanza to the client. address before delivering the stanza to the client.
2. If the server has itself generated the stanza (e.g., a response 2. If the server has itself generated the stanza (e.g., a response
to an IQ stanza of type "get" or "set", even if the stanza did to an IQ stanza of type "get" or "set", even if the stanza did
not include a 'to' address), the stanza MAY include a 'to' not include a 'to' address), the stanza MAY include a 'to'
address, which MUST be the full JID of the client; however, if address, which MUST be the full JID of the client; however, if
the stanza does not include a 'to' address then the client MUST the stanza does not include a 'to' address then the client MUST
treat it as if the 'to' address were included with a value of the treat it as if the 'to' address were included with a value of the
client's full JID. client's full JID.
Implementation Note: It is the server's responsibility to deliver Implementation Note: It is the server's responsibility to deliver
skipping to change at page 97, line 22 skipping to change at page 101, line 41
The following rules apply to inclusion of the 'to' attribute in the The following rules apply to inclusion of the 'to' attribute in the
context of XML streams qualified by the 'jabber:server' namespace context of XML streams qualified by the 'jabber:server' namespace
(i.e., server-to-server streams). (i.e., server-to-server streams).
1. A stanza MUST possess a 'to' attribute whose value is an XMPP 1. A stanza MUST possess a 'to' attribute whose value is an XMPP
address; if a server receives a stanza that does not meet this address; if a server receives a stanza that does not meet this
restriction, it MUST generate an <improper-addressing/> stream restriction, it MUST generate an <improper-addressing/> stream
error. error.
2. The domainpart of the JID contained in the stanza's 'to' 2. The domainpart of the JID contained in the stanza's 'to'
attribute MUST match the hostname of the receiving server (or any attribute MUST match the FQDN of the receiving server (or any
validated domain thereof) as communicated via SASL negotiation validated domain thereof) as communicated via SASL negotiation
(see Section 6), Server Dialback (see [XEP-0220]), or similar (see Section 6), Server Dialback (see [XEP-0220]), or similar
means; if a server receives a stanza that does not meet this means; if a server receives a stanza that does not meet this
restriction, it MUST generate a <host-unknown/> or <host-gone/> restriction, it MUST generate a <host-unknown/> or <host-gone/>
stream error. stream error.
8.1.2. from 8.1.2. from
The 'from' attribute specifies the JID of the sender. The 'from' attribute specifies the JID of the sender.
skipping to change at page 97, line 44 skipping to change at page 102, line 16
to='romeo@example.net'> to='romeo@example.net'>
<body>Art thou not Romeo, and a Montague?</body> <body>Art thou not Romeo, and a Montague?</body>
</message> </message>
8.1.2.1. Client-to-Server Streams 8.1.2.1. Client-to-Server Streams
The following rules apply to the 'from' attribute in the context of The following rules apply to the 'from' attribute in the context of
XML streams qualified by the 'jabber:client' namespace (i.e., client- XML streams qualified by the 'jabber:client' namespace (i.e., client-
to-server streams). to-server streams).
1. When the server receives an XML stanza from a client, the server 1. When a server receives an XML stanza from a connected client, the
MUST add a 'from' attribute to the stanza or override the 'from' server MUST add a 'from' attribute to the stanza or override the
attribute specified by the client, where the value of the 'from' 'from' attribute specified by the client, where the value of the
attribute is the full JID (<localpart@domainpart/resource>) 'from' attribute MUST be the full JID
determined by the server for the connected resource that (<localpart@domainpart/resource>) determined by the server for
generated the stanza (see Section 4.2.6), or the bare JID the connected resource that generated the stanza (see
(<localpart@domainpart>) in the case of subscription-related Section 4.3.6), or the bare JID (<localpart@domainpart>) in the
presence stanzas (see [XMPP-IM]). case of subscription-related presence stanzas (see [XMPP-IM]).
2. When the server generates a stanza from the server itself for 2. When the server generates a stanza on its own behalf for delivery
delivery to the client, the stanza MUST include a 'from' to the client from the server itself, the stanza MUST include a
attribute whose value is the bare JID (i.e., <domain>) of the 'from'