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' attribute whose value is the bare JID (i.e., <domainpart>)
server as agreed upon during stream negotiation (e.g., based on of the server as agreed upon during stream negotiation (e.g.,
the 'to' attribute of the initial stream header). based on the 'to' attribute of the initial stream header).
3. When the server generates a stanza from the server for delivery 3. When the server generates a stanza from the server for delivery
to the client on behalf of the account of the connected client to the client on behalf of the account of the connected client
(e.g., in the context of data storage services provided by the (e.g., in the context of data storage services provided by the
server on behalf of the client), the stanza MUST either (a) not server on behalf of the client), the stanza MUST either (a) not
include a 'from' attribute or (b) include a 'from' attribute include a 'from' attribute or (b) include a 'from' attribute
whose value is the account's bare JID (<localpart@domainpart>). whose value is the account's bare JID (<localpart@domainpart>).
4. A server MUST NOT send to the client a stanza without a 'from' 4. A server MUST NOT send to the client a stanza without a 'from'
attribute if the stanza was not generated by the server (e.g., if attribute if the stanza was not generated by the server on its
it was generated by another client or another server); therefore, own behalf (e.g., if it was generated by another client or a peer
when a client receives a stanza that does not include a 'from' server and the server is merely delivering it to the client on
attribute, it MUST assume that the stanza is from the user's behalf of some other entity); therefore, when a client receives a
account on the server. stanza that does not include a 'from' attribute, it MUST assume
that the stanza is from the user's account on the server.
8.1.2.2. Server-to-Server Streams 8.1.2.2. Server-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:server' namespace (i.e., server- XML streams qualified by the 'jabber:server' namespace (i.e., server-
to-server streams). to-server streams).
1. A stanza MUST possess a 'from' attribute whose value is an XMPP 1. A stanza MUST possess a 'from' 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 'from' 2. The domainpart of the JID contained in the stanza's 'from'
attribute MUST match the hostname of the sending server (or any attribute MUST match the FQDN of the sending 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 an <invalid-from/> stream error. restriction, it MUST generate an <invalid-from/> stream error.
Enforcement of these rules helps to prevent certain denial of service Enforcement of these rules helps to prevent certain denial of service
attacks as described under Section 13.12. attacks as described under Section 13.12.
8.1.3. id 8.1.3. id
The 'id' attribute is used by the entity that generates a stanza The 'id' attribute is used by the originating entity to track any
("the originating entity") to track any response or error stanza that response or error stanza that it might receive in relation to the
it might receive in relation to the generated stanza from another generated stanza from another entity (such as an intermediate server
entity (such as an intermediate server or the intended recipient). or the intended recipient).
It is up to the originating entity whether the value of the 'id' It is up to the originating entity whether the value of the 'id'
attribute will be unique only within its current stream or unique attribute is unique only within its current stream or unique
globally. globally.
For <message/> and <presence/> stanzas, it is RECOMMENDED for the For <message/> and <presence/> stanzas, it is RECOMMENDED for the
originating entity to include an 'id' attribute; for <iq/> stanzas, originating entity to include an 'id' attribute; for <iq/> stanzas,
it is REQUIRED. it is REQUIRED.
If the generated stanza includes an 'id' attribute then it is If the generated stanza includes an 'id' attribute then it is
REQUIRED for the response or error stanza to also include an 'id' REQUIRED for the response or error stanza to also include an 'id'
attribute, where the value of the 'id' attribute MUST match that of attribute, where the value of the 'id' attribute MUST match that of
the generated stanza. the generated stanza.
The semantics of IQ stanzas impose additional restrictions; see The semantics of IQ stanzas impose additional restrictions as
Section 8.2.3. described under Section 8.2.3.
8.1.4. type 8.1.4. type
The 'type' attribute specifies the purpose or context of the message, The 'type' attribute specifies the purpose or context of the message,
presence, or IQ stanza. The particular allowable values for the presence, or IQ stanza. The particular allowable values for the
'type' attribute vary depending on whether the stanza is a message, 'type' attribute vary depending on whether the stanza is a message,
presence, or IQ stanza. The defined values for message and presence presence, or IQ stanza. The defined values for message and presence
stanzas are specific to instant messaging and presence applications stanzas are specific to instant messaging and presence applications
and therefore are defined in [XMPP-IM], whereas the values for IQ and therefore are defined in [XMPP-IM], whereas the values for IQ
stanzas specify the role of an IQ stanza in a structured request- stanzas specify the part of the semantics for all structured request-
response exchange and therefore are specified under Section 8.2.3. response exchanges (no matter what the payload) and therefore are
The only 'type' value common to all three stanzas is "error"; see specified under Section 8.2.3. The only 'type' value common to all
Section 8.3. three kinds of stanzas is "error" as described under Section 8.3.
8.1.5. xml:lang 8.1.5. xml:lang
A stanza SHOULD possess an 'xml:lang' attribute (as defined in A stanza SHOULD possess an 'xml:lang' attribute (as defined in
Section 2.12 of [XML]) if the stanza contains XML character data that Section 2.12 of [XML]) if the stanza contains XML character data that
is intended to be presented to a human user (as explained in is intended to be presented to a human user (as explained in
[CHARSETS], "internationalization is for humans"). The value of the [CHARSETS], "internationalization is for humans"). The value of the
'xml:lang' attribute specifies the default language of any such 'xml:lang' attribute specifies the default language of any such
human-readable XML character data. human-readable XML character data.
skipping to change at page 100, line 13 skipping to change at page 104, line 32
lang' attribute of a specific child element. lang' attribute of a specific child element.
<presence from='romeo@example.net/orchard' xml:lang='en'> <presence from='romeo@example.net/orchard' xml:lang='en'>
<show>dnd</show> <show>dnd</show>
<status>Wooing Juliet</status> <status>Wooing Juliet</status>
<status xml:lang='cs'>Dvo&#x0159;&#x00ED;m se Julii</status> <status xml:lang='cs'>Dvo&#x0159;&#x00ED;m se Julii</status>
</presence </presence
If an outbound stanza generated by a client does not possess an 'xml: If an outbound stanza generated by a client does not possess an 'xml:
lang' attribute, the client's server SHOULD add an 'xml:lang' lang' attribute, the client's server SHOULD add an 'xml:lang'
attribute whose value is that specified for the stream as defined attribute whose value is that specified for the client's output
under Section 4.6.4. stream as defined under Section 4.7.4.
C: <presence from='romeo@example.net/orchard'> C: <presence from='romeo@example.net/orchard'>
<show>dnd</show> <show>dnd</show>
<status>Wooing Juliet</status> <status>Wooing Juliet</status>
</presence> </presence>
S: <presence from='romeo@example.net/orchard' S: <presence from='romeo@example.net/orchard'
to='juliet@im.example.com' to='juliet@im.example.com'
xml:lang='en'> xml:lang='en'>
<show>dnd</show> <show>dnd</show>
<status>Wooing Juliet</status> <status>Wooing Juliet</status>
</presence> </presence>
If an inbound stanza received by a client or server does not possess If an inbound stanza received by a client or server does not possess
an 'xml:lang' attribute, an implementation MUST assume that the an 'xml:lang' attribute, an implementation MUST assume that the
default language is that specified for the stream as defined under default language is that specified for the entity's input stream as
Section 4.6.4. defined under Section 4.7.4.
The value of the 'xml:lang' attribute MUST conform to the NMTOKEN The value of the 'xml:lang' attribute MUST conform to the NMTOKEN
datatype (as defined in Section 2.3 of [XML]) and MUST conform to the datatype (as defined in Section 2.3 of [XML]) and MUST conform to the
format defined in [LANGTAGS]. format defined in [LANGTAGS].
A server MUST NOT modify or delete 'xml:lang' attributes on stanzas A server MUST NOT modify or delete 'xml:lang' attributes on stanzas
it receives from other entities. it receives from other entities.
8.2. Basic Semantics 8.2. Basic Semantics
8.2.1. Message Semantics 8.2.1. Message Semantics
The <message/> stanza can be seen as a "push" mechanism whereby one The <message/> stanza is a "push" mechanism whereby one entity pushes
entity pushes information to another entity, similar to the information to another entity, similar to the communications that
communications that occur in a system such as email. All message occur in a system such as email. All message stanzas SHOULD possess
stanzas SHOULD possess a 'to' attribute that specifies the intended a 'to' attribute that specifies the intended recipient of the message
recipient of the message; upon receiving such a stanza, a server (see Section 8.1.1 and Section 10.3); upon receiving such a stanza, a
SHOULD route or deliver it to the intended recipient (see Section 10 server SHOULD if possible route or deliver it to the intended
for general routing and delivery rules related to XML stanzas). recipient (see Section 10 for general routing and delivery rules
related to XML stanzas).
8.2.2. Presence Semantics 8.2.2. Presence Semantics
The <presence/> stanza can be seen as a specialized broadcast or The <presence/> stanza is a specialized "broadcast" or "publish-
"publish-subscribe" mechanism, whereby multiple entities receive subscribe" mechanism, whereby multiple entities receive information
information (in this case, network availability information) about an (in this case, network availability information) about an entity to
entity to which they have subscribed. In general, a publishing which they have subscribed. In general, a publishing client SHOULD
entity (client) SHOULD send a presence stanza with no 'to' attribute, send a presence stanza with no 'to' attribute, in which case the
in which case the server to which the entity is connected SHOULD server to which the client is connected will broadcast that stanza to
broadcast that stanza to all subscribed entities. However, a all subscribed entities. However, a publishing client MAY also send
publishing entity MAY also send a presence stanza with a 'to' a presence stanza with a 'to' attribute, in which case the server
attribute, in which case the server SHOULD route or deliver that will route or deliver that stanza to the intended recipient.
stanza to the intended recipient. See Section 10 for general routing Although the <presence/> stanza is most often used by XMPP clients,
and delivery rules related to XML stanzas, and [XMPP-IM] for rules it can also be used by servers, add-on services, and any other kind
specific to presence applications. of XMPP entity. See Section 10 for general routing and delivery
rules related to XML stanzas, and [XMPP-IM] for rules specific to
presence applications.
8.2.3. IQ Semantics 8.2.3. IQ Semantics
Info/Query, or IQ, is a request-response mechanism, similar in some Info/Query, or IQ, is a "request-response" mechanism, similar in some
ways to the Hypertext Transfer Protocol [HTTP]. The semantics of IQ ways to the Hypertext Transfer Protocol [HTTP]. The semantics of IQ
enable an entity to make a request of, and receive a response from, enable an entity to make a request of, and receive a response from,
another entity. The data content of the request and response is another entity. The data content of the request and response is
defined by the schema or other structural definition associated with defined by the schema or other structural definition associated with
the XML namespace that qualifies the direct child element of the IQ the XML namespace that qualifies the direct child element of the IQ
element (see Section 8.4), and the interaction is tracked by the element (see Section 8.4), and the interaction is tracked by the
requesting entity through use of the 'id' attribute. Thus, IQ requesting entity through use of the 'id' attribute. Thus, IQ
interactions follow a common pattern of structured data exchange such interactions follow a common pattern of structured data exchange such
as get/result or set/result (although an error can be returned in as get/result or set/result (although an error can be returned in
reply to a request if appropriate): reply to a request if appropriate):
skipping to change at page 102, line 51 skipping to change at page 107, line 9
data is needed in order to complete further operations, etc. data is needed in order to complete further operations, etc.
* set -- The stanza provides data that is needed for an * set -- The stanza provides data that is needed for an
operation to be completed, sets new values, replaces existing operation to be completed, sets new values, replaces existing
values, etc. values, etc.
* result -- The stanza is a response to a successful get or set * result -- The stanza is a response to a successful get or set
request. request.
* error -- The stanza reports an error that has occurred * error -- The stanza reports an error that has occurred
regarding processing or delivery of a previously-sent get or regarding processing or delivery of a get or set request (see
set request (see Section 8.3). Section 8.3).
3. An entity that receives an IQ request of type "get" or "set" MUST 3. An entity that receives an IQ request of type "get" or "set" MUST
reply with an IQ response of type "result" or "error". The reply with an IQ response of type "result" or "error". The
response MUST preserve the 'id' attribute of the request (or be response MUST preserve the 'id' attribute of the request (or be
empty if the generated stanza did not include an 'id' attribute). empty if the generated stanza did not include an 'id' attribute).
4. An entity that receives a stanza of type "result" or "error" MUST 4. An entity that receives a stanza of type "result" or "error" MUST
NOT respond to the stanza by sending a further IQ response of NOT respond to the stanza by sending a further IQ response of
type "result" or "error"; however, the requesting entity MAY send type "result" or "error"; however, the requesting entity MAY send
another request (e.g., an IQ of type "set" to provide obligatory another request (e.g., an IQ of type "set" to provide obligatory
skipping to change at page 103, line 30 skipping to change at page 107, line 37
6. An IQ stanza of type "result" MUST include zero or one child 6. An IQ stanza of type "result" MUST include zero or one child
elements. elements.
7. An IQ stanza of type "error" MAY include the child element 7. An IQ stanza of type "error" MAY include the child element
contained in the associated "get" or "set" and MUST include an contained in the associated "get" or "set" and MUST include an
<error/> child; for details, see Section 8.3. <error/> child; for details, see Section 8.3.
8.3. Stanza Errors 8.3. Stanza Errors
Stanza-related errors are handled in a manner similar to stream Stanza-related errors are handled in a manner similar to stream
errors (Section 4.8). Unlike stream errors, stanza errors are errors (Section 4.9). Unlike stream errors, stanza errors are
recoverable; therefore they do not result in termination of the XML recoverable; therefore they do not result in termination of the XML
stream and underlying TCP connection. Instead, the entity that stream and underlying TCP connection. Instead, the entity that
discovers the error condition returns an error stanza, which is a discovers the error condition returns an error stanza, which is a
stanza that: stanza that:
o is of the same kind (message, presence, or IQ) as the generated o is of the same kind (message, presence, or IQ) as the generated
stanza that triggered the error stanza that triggered the error
o has a 'type' attribute set to a value of "error" o has a 'type' attribute set to a value of "error"
o swaps the 'from' and 'to' addresses of the generated stanza o typically swaps the 'from' and 'to' addresses of the generated
stanza
o mirrors the 'id' attribute (if any) of the generated stanza that o mirrors the 'id' attribute (if any) of the generated stanza that
triggered the error triggered the error
o contains an <error/> child element that specifies the error o contains an <error/> child element that specifies the error
condition and therefore provides a hint regarding actions that the condition and therefore provides a hint regarding actions that the
sender can take to remedy the error (if possible) sender might be able to take in an effort to remedy the error
(however, it is not always possible to remedy the error)
8.3.1. Rules 8.3.1. Rules
The following rules apply to stanza errors: The following rules apply to stanza errors:
1. The receiving or processing entity that detects an error 1. The receiving or processing entity that detects an error
condition in relation to a stanza SHOULD return an error stanza condition in relation to a stanza SHOULD return an error stanza
(and MUST do so for IQ stanzas). (and MUST do so for IQ stanzas).
2. The error stanza SHOULD simply swap the 'from' and 'to' addresses 2. The error stanza SHOULD simply swap the 'from' and 'to' addresses
from the generated stanza, unless doing so would result in an from the generated stanza, unless doing so would (1) result in an
information leak (see under Section 13.10) or other breach of information leak (see under Section 13.10) or other breach of
security. security, or (2) force the sender of the error stanza to include
a malformed JID in the 'from' or 'to' address of the error
stanza.
3. If the generated stanza was <message/> or <presence/> and 3. If the generated stanza was <message/> or <presence/> and
included an 'id' attribute then it is REQUIRED for the error included an 'id' attribute then it is REQUIRED for the error
stanza to also include an 'id' attribute. If the generated stanza to also include an 'id' attribute. If the generated
stanza was <iq/> then the error stanza MUST include an 'id' stanza was <iq/> then the error stanza MUST include an 'id'
attribute. In all cases, the value of the 'id' attribute MUST attribute. In all cases, the value of the 'id' attribute MUST
match that of the generated stanza (or be empty if the generated match that of the generated stanza (or be empty if the generated
stanza did not include an 'id' attribute). stanza did not include an 'id' attribute).
4. An error stanza MUST contain an <error/> child element. 4. An error stanza MUST contain an <error/> child element.
skipping to change at page 104, line 39 skipping to change at page 108, line 49
the sender of the generated stanza (e.g., for diagnostic or the sender of the generated stanza (e.g., for diagnostic or
tracking purposes) through the addition of a 'by' attribute to tracking purposes) through the addition of a 'by' attribute to
the <error/> child element. the <error/> child element.
6. The entity that returns an error stanza MAY include the original 6. The entity that returns an error stanza MAY include the original
XML sent so that the sender can inspect and, if necessary, XML sent so that the sender can inspect and, if necessary,
correct the XML before attempting to resend (however, this is a correct the XML before attempting to resend (however, this is a
courtesy only and the originating entity MUST NOT depend on courtesy only and the originating entity MUST NOT depend on
receiving the original payload); naturally, the entity MUST NOT receiving the original payload); naturally, the entity MUST NOT
include the original data if it not well-formed XML, violates the include the original data if it not well-formed XML, violates the
XML restrictions of XMPP (see under Section 11.1, or is otherwise XML restrictions of XMPP (see under Section 11.1), or is
harmful (e.g, exceeds a size limit). otherwise harmful (e.g, exceeds a size limit).
7. An <error/> child MUST NOT be included if the 'type' attribute 7. An <error/> child MUST NOT be included if the 'type' attribute
has a value other than "error" (or if there is no 'type' has a value other than "error" (or if there is no 'type'
attribute). attribute).
8. An entity that receives an error stanza MUST NOT respond to the 8. An entity that receives an error stanza MUST NOT respond to the
stanza with a further error stanza; this helps to prevent stanza with a further error stanza; this helps to prevent
looping. looping.
8.3.2. Syntax 8.3.2. Syntax
The syntax for stanza-related errors is as follows, where XML data The syntax for stanza-related errors is as follows, where XML data
shown within the square brackets '[' and ']' is OPTIONAL, 'intended- shown within the square brackets '[' and ']' is OPTIONAL, 'intended-
recipient' is the JID of the entity to which the original stanza was recipient' is the JID of the entity to which the original stanza was
addressed, and 'sender' is the JID of the originating entity. addressed, 'sender' is the JID of the originating entity, and 'error-
generator' is the entity that detects the fact that an error has
occurred and thus returns an error stanza.
<stanza-kind from='intended-recipient' to='sender' type='error'> <stanza-kind from='intended-recipient' to='sender' type='error'>
[OPTIONAL to include sender XML here] [OPTIONAL to include sender XML here]
<error [by='jid'] <error [by='error-generator']
type='error-type'> type='error-type'>
<defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
[<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas' [<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'
xml:lang='langcode'> xml:lang='langcode'>
OPTIONAL descriptive text OPTIONAL descriptive text
</text>] </text>]
[OPTIONAL application-specific condition element] [OPTIONAL application-specific condition element]
</error> </error>
</stanza-kind> </stanza-kind>
skipping to change at page 105, line 36 skipping to change at page 109, line 46
The "error-type" MUST be one of the following: The "error-type" MUST be one of the following:
o auth -- retry after providing credentials o auth -- retry after providing credentials
o cancel -- do not retry (the error cannot be remedied) o cancel -- do not retry (the error cannot be remedied)
o continue -- proceed (the condition was only a warning) o continue -- proceed (the condition was only a warning)
o modify -- retry after changing the data sent o modify -- retry after changing the data sent
o wait -- retry after waiting (the error is temporary) o wait -- retry after waiting (the error is temporary)
The "defined-condition" MUST correspond to one of the stanza error The "defined-condition" MUST correspond to one of the stanza error
conditions defined under Section 8.3.3. conditions defined under Section 8.3.3. If the designers of an XMPP
protocol extension or the developers of an XMPP implementation need
to communicate a stanza 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 defined condition element. o MUST contain a defined condition element.
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-stanzas' namespace qualified by the 'urn:ietf:params:xml:ns:xmpp-stanzas' 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-
specific namespace that defines the syntax and semantics of the specific namespace that defines the syntax and semantics of the
element. element.
The <text/> element is OPTIONAL. If included, it MUST be used only The <text/> element is OPTIONAL. If included, it is to 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 NOT be interpreted programmatically by an application. It
SHOULD NOT be used as the error message presented to a human user, SHOULD 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 but MAY be shown in addition to the error message associated with the
defined condition element (and, optionally, the application-specific defined condition element (and, optionally, the application-specific
condition element). condition element).
Interoperability Note: The syntax defined in [RFC3920] included a Interoperability Note: The syntax defined in [RFC3920] included a
legacy 'code' attribute, whose semantics have been replaced by the legacy 'code' attribute, whose semantics have been replaced by the
defined condition elements; information about mapping defined defined condition elements; information about mapping defined
condition elements to values of the legacy 'code' attribute can be condition elements to values of the legacy 'code' attribute can be
found in [XEP-0086]. found in [XEP-0086].
8.3.3. Defined Conditions 8.3.3. Defined Conditions
The following conditions are defined for use in stanza errors. The following conditions are defined for use in stanza errors.
The error-type value that is RECOMMENDED for each defined condition
is the usual expected type; however, in some circumstances a
different type might be more appropriate.
8.3.3.1. bad-request 8.3.3.1. bad-request
The sender has sent a stanza containing XML that does not conform to The sender has sent a stanza containing XML that does not conform to
the appropriate schema or that cannot be processed (e.g., an IQ the appropriate schema or that cannot be processed (e.g., an IQ
stanza that includes an unrecognized value of the 'type' attribute, stanza that includes an unrecognized value of the 'type' attribute,
or an element that is qualified by a recognized namespace but that or an element that is qualified by a recognized namespace but that
violates the defined syntax for the element); the associated error violates the defined syntax for the element); the associated error
type SHOULD be "modify". type SHOULD be "modify".
C: <iq from='juliet@im.example.com/balcony' C: <iq from='juliet@im.example.com/balcony'
skipping to change at page 109, line 28 skipping to change at page 113, line 39
<error by='example.net' <error by='example.net'
type='cancel'> type='cancel'>
<gone xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'> <gone xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
xmpp:romeo@afterlife.example.net xmpp:romeo@afterlife.example.net
</gone> </gone>
</error> </error>
</message> </message>
8.3.3.6. internal-server-error 8.3.3.6. internal-server-error
The server could not process the stanza because of a misconfiguration The server has experienced a misconfiguration or other internal error
or an otherwise-undefined internal server error; the associated error that prevents it from processing the stanza; the associated error
type SHOULD be "cancel". type SHOULD be "cancel".
C: <presence C: <presence
from='juliet@im.example.com/balcony' from='juliet@im.example.com/balcony'
id='y2bs71v4' id='y2bs71v4'
to='characters@muc.example.com/JulieC'> to='characters@muc.example.com/JulieC'>
<x xmlns='http://jabber.org/protocol/muc'/> <x xmlns='http://jabber.org/protocol/muc'/>
</presence> </presence>
E: <presence E: <presence
skipping to change at page 110, line 23 skipping to change at page 114, line 41
S: <presence from='nosuchroom@conference.example.org/foo' S: <presence from='nosuchroom@conference.example.org/foo'
id='pwb2n78i' id='pwb2n78i'
to='userfoo@example.com/bar' to='userfoo@example.com/bar'
type='error'> type='error'>
<error type='cancel'> <error type='cancel'>
<item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
Security Note: An application MUST NOT return this error if doing Security Warning: An application MUST NOT return this error if
so would provide information about the intended recipient's doing so would provide information about the intended recipient's
network availability to an entity that is not authorized to know network availability to an entity that is not authorized to know
such information (for details, refer to the discussion of presence such information (for a more detailed discussion of presence
subscriptions in [XMPP-IM]); instead it MUST return a <service- authorization, refer to the discussion of presence subscriptions
unavailable/> stanza error. in [XMPP-IM]); instead it MUST return a <service-unavailable/>
stanza error.
8.3.3.8. jid-malformed 8.3.3.8. jid-malformed
The sending entity has provided (e.g., during resource binding) or The sending entity has provided (e.g., during resource binding) or
communicated (e.g., in the 'to' address of a stanza) an XMPP address communicated (e.g., in the 'to' address of a stanza) an XMPP address
or aspect thereof that does not adhere to the syntax defined in or aspect thereof that violates the rules defined in [XMPP-ADDR]; the
[XMPP-ADDR]; the associated error type SHOULD be "modify". associated error type SHOULD be "modify".
C: <presence C: <presence
from='juliet@im.example.com/balcony' from='juliet@im.example.com/balcony'
id='y2bs71v4' id='y2bs71v4'
to='ch@r@cters@muc.example.com/JulieC'> to='ch@r@cters@muc.example.com/JulieC'>
<x xmlns='http://jabber.org/protocol/muc'/> <x xmlns='http://jabber.org/protocol/muc'/>
</presence> </presence>
E: <presence E: <presence
from='ch@r@cters@muc.example.com/JulieC' from='ch@r@cters@muc.example.com/JulieC'
skipping to change at page 113, line 21 skipping to change at page 117, line 21
E: <presence E: <presence
from='characters@muc.example.com/JulieC' from='characters@muc.example.com/JulieC'
id='y2bs71v4' id='y2bs71v4'
to='juliet@im.example.com/balcony'> to='juliet@im.example.com/balcony'>
<error type='auth'> <error type='auth'>
<not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <not-authorized xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</presence> </presence>
8.3.3.12. payment-required 8.3.3.12. policy-violation
The requesting entity is not authorized to access the requested
service because payment is necessary; the associated error type
SHOULD be "auth".
C: <iq from='romeo@example.net/foo'
id='7isf2v4'
to='pubsub.example.com'
type='get'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='my_musings'/>
</pubsub>
</iq>
E: <iq from='pubsub.example.com'
id='7isf2v4'
to='romeo@example.net/foo'
type='error'>
<error type='auth'>
<payment-required
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
8.3.3.13. policy-violation
The entity has violated some local service policy (e.g., a message The entity has violated some local service policy (e.g., a message
contains words that are prohibited by the service); the server MAY contains words that are prohibited by the service) and the server MAY
choose to specify the policy in the <text/> element or in an choose to specify the policy in the <text/> element or in an
application-specific condition element; the associated error type application-specific condition element; the associated error type
SHOULD be "modify" or "wait" depending on the policy being violated. SHOULD be "modify" or "wait" depending on the policy being violated.
(In the following example, the client sends an XMPP message that is (In the following example, the client sends an XMPP message
too large according to the server's local service policy.) containing words that are forbidden according to the server's local
service policy.)
C: <message from='romeo@example.net/foo' C: <message from='romeo@example.net/foo'
to='bill@im.example.com' to='bill@im.example.com'
id='vq71f4nb'> id='vq71f4nb'>
<body>%#&@^!!!</body> <body>%#&@^!!!</body>
</message> </message>
S: <message from='bill@im.example.com' S: <message from='bill@im.example.com'
id='vq71f4nb' id='vq71f4nb'
to='romeo@example.net/foo'> to='romeo@example.net/foo'>
<error by='example.net' type='cancel'> <error by='example.net' type='modify'>
<policy-violation <policy-violation
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</message> </message>
8.3.3.14. recipient-unavailable 8.3.3.13. recipient-unavailable
The intended recipient is temporarily unavailable, undergoing The intended recipient is temporarily unavailable, undergoing
maintenance, etc.; the associated error type SHOULD be "wait". maintenance, etc.; the associated error type SHOULD be "wait".
C: <presence C: <presence
from='juliet@im.example.com/balcony' from='juliet@im.example.com/balcony'
id='y2bs71v4' id='y2bs71v4'
to='characters@muc.example.com/JulieC'> to='characters@muc.example.com/JulieC'>
<x xmlns='http://jabber.org/protocol/muc'/> <x xmlns='http://jabber.org/protocol/muc'/>
</presence> </presence>
skipping to change at page 114, line 45 skipping to change at page 118, line 22
E: <presence E: <presence
from='characters@muc.example.com/JulieC' from='characters@muc.example.com/JulieC'
id='y2bs71v4' id='y2bs71v4'
to='juliet@im.example.com/balcony'> to='juliet@im.example.com/balcony'>
<error type='wait'> <error type='wait'>
<recipient-unavailable <recipient-unavailable
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</presence> </presence>
Security Note: An application MUST NOT return this error if doing Security Warning: An application MUST NOT return this error if
so would provide information about the intended recipient's doing so would provide information about the intended recipient's
network availability to an entity that is not authorized to know network availability to an entity that is not authorized to know
such information (for details, refer to the discussion of presence such information (for a more detailed discussion of presence
subscriptions in [XMPP-IM]); instead it MUST return a <service- authorization, refer to the discussion of presence subscriptions
unavailable/> stanza error. in [XMPP-IM]); instead it MUST return a <service-unavailable/>
stanza error.
8.3.3.15. redirect 8.3.3.14. redirect
The recipient or server is redirecting requests for this information The recipient or server is redirecting requests for this information
to another entity, typically in a temporary fashion (as opposed to to another entity, typically in a temporary fashion (as opposed to
the <gone/> error condition, which is used for permanent addressing the <gone/> error condition, which is used for permanent addressing
failures); the associated error type SHOULD be "modify" and the error failures); the associated error type SHOULD be "modify" and the error
stanza SHOULD contain the alternate address in the XML character data stanza SHOULD contain the alternate address in the XML character data
of the <redirect/> element (which MUST be a URI or IRI with which the of the <redirect/> element (which MUST be a URI or IRI with which the
sender can communicate, typically an XMPP IRI as specified in sender can communicate, typically an XMPP IRI as specified in
[XMPP-URI]). [XMPP-URI]).
skipping to change at page 115, line 35 skipping to change at page 119, line 24
id='y2bs71v4' id='y2bs71v4'
to='juliet@im.example.com/balcony' to='juliet@im.example.com/balcony'
type='error'> type='error'>
<error type='modify'> <error type='modify'>
<redirect xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'> <redirect xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
xmpp:characters@conference.example.org xmpp:characters@conference.example.org
</redirect> </redirect>
</error> </error>
</presence> </presence>
Security Note: An application receiving a stanza-level redirect Security Warning: An application receiving a stanza-level redirect
SHOULD warn a human user of the redirection attempt and request SHOULD warn a human user of the redirection attempt and request
approval before proceeding to communicated with the entity whose approval before proceeding to communicate with the entity whose
URI or IRI is contained in the XML character data of the address is contained in the XML character data of the <redirect/>
<redirect/> element, because that entity might have a different element, because that entity might have a different identity or
identity or might enforce different security policies. However, might enforce different security policies. The end-to-end
the end-to-end authentication or signing of XMPP stanzas could authentication or signing of XMPP stanzas could help to mitigate
help to mitigate this risk, since it would enable the sender to this risk, since it would enable the sender to determine if the
determine if the entity to which it has been redirected has the entity to which it has been redirected has the same identity as
same identity as the entity it originally attempted to contact. the entity it originally attempted to contact. An application MAY
have a policy of following redirects only if it has authenticated
the receiving entity. In addition, an application SHOULD abort
the communication attempt after a certain number of successive
redirects (e.g., at least 2 but no more than 5).
8.3.3.16. registration-required 8.3.3.15. registration-required
The requesting entity is not authorized to access the requested The requesting entity is not authorized to access the requested
service because prior registration is necessary (examples of prior service because prior registration is necessary (examples of prior
registration include members-only rooms in XMPP multi-user chat registration include members-only rooms in XMPP multi-user chat
[XEP-0045] and gateways to non-XMPP instant messaging services, which [XEP-0045] and gateways to non-XMPP instant messaging services, which
traditionally required registration in order to use the gateway traditionally required registration in order to use the gateway
[XEP-0100]); the associated error type SHOULD be "auth". [XEP-0100]); the associated error type SHOULD be "auth".
C: <presence C: <presence
from='juliet@im.example.com/balcony' from='juliet@im.example.com/balcony'
id='y2bs71v4' id='y2bs71v4'
to='characters@muc.example.com/JulieC'> to='characters@muc.example.com/JulieC'>
<x xmlns='http://jabber.org/protocol/muc'/> <x xmlns='http://jabber.org/protocol/muc'/>
</presence> </presence>
E: <presence E: <presence
skipping to change at page 116, line 24 skipping to change at page 120, line 22
E: <presence E: <presence
from='characters@muc.example.com/JulieC' from='characters@muc.example.com/JulieC'
id='y2bs71v4' id='y2bs71v4'
to='juliet@im.example.com/balcony'> to='juliet@im.example.com/balcony'>
<error type='auth'> <error type='auth'>
<registration-required <registration-required
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</presence> </presence>
8.3.3.17. remote-server-not-found 8.3.3.16. remote-server-not-found
A remote server or service specified as part or all of the JID of the A remote server or service specified as part or all of the JID of the
intended recipient does not exist or cannot be resolved (e.g., there intended recipient does not exist or cannot be resolved (e.g., there
is no _xmpp-server._tcp DNS SRV record, the A or AAAA fallback is no _xmpp-server._tcp DNS SRV record, the A or AAAA fallback
resolution fails, or A/AAAA lookup succeeds but there is no response resolution fails, or A/AAAA lookups succeed but there is no response
on the IANA-registered port 5269); the associated error type SHOULD on the IANA-registered port 5269); the associated error type SHOULD
be "cancel". be "cancel".
C: <message C: <message
from='romeo@example.net/home' from='romeo@example.net/home'
id='ud7n1f4h' id='ud7n1f4h'
to='bar@example.org' to='bar@example.org'
type='chat'> type='chat'>
<body>yt?</body> <body>yt?</body>
</message> </message>
skipping to change at page 117, line 5 skipping to change at page 121, line 5
from='bar@example.org' from='bar@example.org'
id='ud7n1f4h' id='ud7n1f4h'
to='romeo@example.net/home' to='romeo@example.net/home'
type='error'> type='error'>
<error type='cancel'> <error type='cancel'>
<remote-server-not-found <remote-server-not-found
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</message> </message>
8.3.3.18. remote-server-timeout 8.3.3.17. remote-server-timeout
A remote server or service specified as part or all of the JID of the A remote server or service specified as part or all of the JID of the
intended recipient (or needed to fulfill a request) was resolved but intended recipient (or needed to fulfill a request) was resolved but
communications could not be established within a reasonable amount of communications could not be established within a reasonable amount of
time (e.g., an XML stream cannot be established at the resolved IP time (e.g., an XML stream cannot be established at the resolved IP
address and port, or an XML stream can be established but stream address and port, or an XML stream can be established but stream
negotiation fails because of problems with TLS, SASL, Server negotiation fails because of problems with TLS, SASL, Server
Dialback, etc.); the associated error type SHOULD be "wait" (unless Dialback, etc.); the associated error type SHOULD be "wait" (unless
the error is of a more permanent nature, e.g., the remote server is the error is of a more permanent nature, e.g., the remote server is
found but it cannot be authenticated or it violates security found but it cannot be authenticated or it violates security
skipping to change at page 117, line 37 skipping to change at page 121, line 37
from='bar@example.org' from='bar@example.org'
id='ud7n1f4h' id='ud7n1f4h'
to='romeo@example.net/home' to='romeo@example.net/home'
type='error'> type='error'>
<error type='wait'> <error type='wait'>
<remote-server-timeout <remote-server-timeout
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</message> </message>
8.3.3.19. resource-constraint 8.3.3.18. resource-constraint
The server or recipient is busy or lacks the system resources The server or recipient is busy or lacks the system resources
necessary to service the request; the associated error type SHOULD be necessary to service the request; the associated error type SHOULD be
"wait". "wait".
C: <iq from='romeo@example.net/foo' C: <iq from='romeo@example.net/foo'
id='kj4vz31m' id='kj4vz31m'
to='pubsub.example.com' to='pubsub.example.com'
type='get'> type='get'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'> <pubsub xmlns='http://jabber.org/protocol/pubsub'>
skipping to change at page 118, line 24 skipping to change at page 122, line 24
E: <iq from='pubsub.example.com' E: <iq from='pubsub.example.com'
id='kj4vz31m' id='kj4vz31m'
to='romeo@example.net/foo' to='romeo@example.net/foo'
type='error'> 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>
8.3.3.20. service-unavailable 8.3.3.19. service-unavailable
The server or recipient does not currently provide the requested The server or recipient does not currently provide the requested
service; the associated error type SHOULD be "cancel". service; the associated error type SHOULD be "cancel".
C: <message from='romeo@example.net/foo' C: <message from='romeo@example.net/foo'
to='juliet@im.example.com'> to='juliet@im.example.com'>
<body>Hello?</body> <body>Hello?</body>
</message> </message>
S: <message from='juliet@im.example.com/foo' S: <message from='juliet@im.example.com/foo'
to='romeo@example.net'> to='romeo@example.net'>
<error type='cancel'> <error type='cancel'>
<service-unavailable <service-unavailable
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</message> </message>
Security Note: An application MUST return a <service-unavailable/> Security Warning: An application MUST return a <service-
stanza error instead of <item-not-found/> or <recipient- unavailable/> stanza error instead of <item-not-found/> or
unavailable/> if sending one of the latter errors would provide <recipient-unavailable/> if sending one of the latter errors would
information about the intended recipient's network availability to provide information about the intended recipient's network
an entity that is not authorized to know such information (for availability to an entity that is not authorized to know such
details, refer to the discussion of presence subscriptions in information (for a more detailed discussion of presence
[XMPP-IM]). authorization, refer to [XMPP-IM]).
8.3.3.21. subscription-required 8.3.3.20. subscription-required
The requesting entity is not authorized to access the requested The requesting entity is not authorized to access the requested
service because a prior subscription is necessary (examples of prior service because a prior subscription is necessary (examples of prior
subscription include authorization to receive presence information as subscription include authorization to receive presence information as
defined in [XMPP-IM] and opt-in data feeds for XMPP publish-subscribe defined in [XMPP-IM] and opt-in data feeds for XMPP publish-subscribe
as defined in [XEP-0060]); the associated error type SHOULD be as defined in [XEP-0060]); the associated error type SHOULD be
"auth". "auth".
C: <message C: <message
from='romeo@example.net/orchard' from='romeo@example.net/orchard'
skipping to change at page 119, line 34 skipping to change at page 123, line 34
from='playwright@shakespeare.example.com' from='playwright@shakespeare.example.com'
id='pa73b4n7' id='pa73b4n7'
to='romeo@example.net/orchard' to='romeo@example.net/orchard'
type='error'> type='error'>
<error type='auth'> <error type='auth'>
<subscription-required <subscription-required
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</message> </message>
8.3.3.22. undefined-condition 8.3.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; any error type can be associated with this conditions in this list; any error type can be associated with this
condition, and it SHOULD be used only in conjunction with an condition, and it SHOULD NOT used except in conjunction with an
application-specific condition. application-specific condition.
C: <message C: <message
from='northumberland@shakespeare.example' from='northumberland@shakespeare.example'
id='richard2-4.1.247' id='richard2-4.1.247'
to='kingrichard@royalty.england.example'> to='kingrichard@royalty.england.example'>
<body>My lord, dispatch; read o'er these articles.</body> <body>My lord, dispatch; read o'er these articles.</body>
<amp xmlns='http://jabber.org/protocol/amp'> <amp xmlns='http://jabber.org/protocol/amp'>
<rule action='notify' <rule action='notify'
condition='deliver' condition='deliver'
skipping to change at page 120, line 39 skipping to change at page 124, line 39
<undefined-condition <undefined-condition
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<failed-rules xmlns='http://jabber.org/protocol/amp#errors'> <failed-rules xmlns='http://jabber.org/protocol/amp#errors'>
<rule action='error' <rule action='error'
condition='deliver' condition='deliver'
value='stored'/> value='stored'/>
</failed-rules> </failed-rules>
</error> </error>
</message> </message>
8.3.3.23. unexpected-request 8.3.3.22. unexpected-request
The recipient or server understood the request but was not expecting The recipient or server understood the request but was not expecting
it at this time (e.g., the request was out of order); the associated it at this time (e.g., the request was out of order); the associated
error type SHOULD be "wait" or "modify". error type SHOULD be "wait" or "modify".
C: <iq from='romeo@example.net/foo' C: <iq from='romeo@example.net/foo'
id='o6hsv25z' id='o6hsv25z'
to='pubsub.example.com' to='pubsub.example.com'
type='set'> type='set'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'> <pubsub xmlns='http://jabber.org/protocol/pubsub'>
skipping to change at page 122, line 40 skipping to change at page 126, line 40
(e.g., an XHTML-formatted version of the message body as described in (e.g., an XHTML-formatted version of the message body as described in
[XEP-0071]), and an IQ stanza of type "get" or "set" MUST contain one [XEP-0071]), and an IQ stanza of type "get" or "set" MUST contain one
such child element. Such a child element MAY have any name and MUST such child element. Such a child element MAY have any name and MUST
possess a namespace declaration (other than "jabber:client", "jabber: possess a namespace declaration (other than "jabber:client", "jabber:
server", or "http://etherx.jabber.org/streams") that defines the data server", or "http://etherx.jabber.org/streams") that defines the data
contained within the child element. Such a child element is called contained within the child element. Such a child element is called
an "extension element". An extension element can be included either an "extension element". An extension element can be included either
at the direct child level of the stanza or in any mix of levels. at the direct child level of the stanza or in any mix of levels.
Similarly, "extension attributes" are allowed. That is: a stanza Similarly, "extension attributes" are allowed. That is: a stanza
itself (i.e., the <iq/>, <message/>, and <presence/> elements itself (i.e., an <iq/>, <message/>, or <presence/> element qualified
qualified by the "jabber:client" or "jabber:server" content by the "jabber:client" or "jabber:server" content namespace) or any
namespace) and any child element of such a stanza (whether an child element of such a stanza (whether an extension element or a
extension element or a child element qualified by the content child element qualified by the content namespace) MAY also include
namespace) MAY also include one or more attributes qualified by XML one or more attributes qualified by XML namespaces other than the
namespaces other than the content namespace or the reserved content namespace or the reserved
"http://www.w3.org/XML/1998/namespace" namespace (including the so- "http://www.w3.org/XML/1998/namespace" namespace (including the so-
called "empty namespace" if the attribute is not prefixed; see called "empty namespace" if the attribute is not prefixed as
[XML-NAMES]). described under [XML-NAMES]).
Interoperability Note: For the sake of backward compatibility and Interoperability Note: For the sake of backward compatibility and
maximum interoperability, an entity that generates a stanza SHOULD maximum interoperability, an entity that generates a stanza SHOULD
NOT include such attributes in the stanza itself or in child NOT include such attributes in the stanza itself or in child
elements of the stanza that are qualified by the content elements of the stanza that are qualified by the content
namespaces "jabber:client" or "jabber:server" (e.g., the <body/> namespaces "jabber:client" or "jabber:server" (e.g., the <body/>
child of the <message/> stanza). child of the <message/> stanza).
An extension element or extension attribute is said to be "extended An extension element or extension attribute is said to be "extended
content" and the namespace name for such an element or attribute is content" and the qualifying namespace for such an element or
said to be an "extended namespace". attribute is said to be an "extended namespace".
Informational Note: Although extended namespaces for XMPP are Informational Note: Although extended namespaces for XMPP are
commonly defined by the XMPP Standards Foundation (XSF) and by the commonly defined by the XMPP Standards Foundation (XSF) and by the
IETF, no specification or IETF standards action is required to IETF, no specification or IETF standards action is necessary to
define extended namespaces, and any individual or organization is define extended namespaces, and any individual or organization is
free to define XMPP extensions. free to define XMPP extensions.
To illustrate these concepts, several examples follow. To illustrate these concepts, several examples follow.
The following stanza contains one direct child element whose extended The following stanza contains one direct child element whose extended
namespace is 'jabber:iq:roster': namespace is 'jabber:iq:roster':
<iq from='juliet@capulet.com/balcony' <iq from='juliet@capulet.com/balcony'
id='h83vxa4c' id='h83vxa4c'
skipping to change at page 124, line 16 skipping to change at page 128, line 16
<body>Hello?</body> <body>Hello?</body>
<html xmlns='http://jabber.org/protocol/xhtml-im'> <html xmlns='http://jabber.org/protocol/xhtml-im'>
<body xmlns='http://www.w3.org/1999/xhtml'> <body xmlns='http://www.w3.org/1999/xhtml'>
<p style='font-weight:bold'>Hello?</t> <p style='font-weight:bold'>Hello?</t>
</body> </body>
</html> </html>
</message> </message>
It is conventional in the XMPP community for implementations to not It is conventional in the XMPP community for implementations to not
generate namespace prefixes for elements that are qualified by generate namespace prefixes for elements that are qualified by
extended namespaces (outside the XMPP community, this convention is extended namespaces (in the XML community, this convention is
sometimes called "prefix-free canonicalization"). However, if an sometimes called "prefix-free canonicalization"). However, if an
implementation generates such namespace prefixes then it MUST include implementation generates such namespace prefixes then it MUST include
the namespace declaration in the stanza itself or a child element of the namespace declaration in the stanza itself or a child element of
the stanza, not in the stream header (see Section 4.7.3). the stanza, not in the stream header (see Section 4.8.4).
Routing entities (typically servers) SHOULD try to maintain prefixes Routing entities (typically servers) SHOULD try to maintain prefixes
when serializing XML stanzas for processing, but receiving entities when serializing XML stanzas for processing, but receiving entities
MUST NOT depend on the prefix strings to have any particular value. MUST NOT depend on the prefix strings to have any particular value
(the allowance for the 'stream' prefix, described under
Section 4.8.5, is an exception to this rule, albeit for streams
rather than stanzas).
Support for any given extended namespace is OPTIONAL on the part of Support for any given extended namespace is OPTIONAL on the part of
any implementation. If an entity does not understand such a any implementation. If an entity does not understand such a
namespace, the entity's expected behavior depends on whether the namespace, the entity's expected behavior depends on whether the
entity is (1) the recipient or (2) a server that is routing or entity is (1) the recipient or (2) a server that is routing or
delivering the stanza to the recipient. delivering the stanza to the recipient.
If a recipient receives a stanza that contains an element or If a recipient receives a stanza that contains an element or
attribute it does not understand, it MUST NOT attempt to process that attribute it does not understand, it MUST NOT attempt to process that
XML data and instead MUST proceed as follows. XML data and instead MUST proceed as follows.
o If an entity receives a message stanza whose only child element is o If an intended recipient receives a message stanza whose only
qualified by a namespace it does not understand, then depending on child element is qualified by a namespace it does not understand,
the XMPP application it MUST either ignore the entire stanza or then depending on the XMPP application it MUST either ignore the
return a stanza error, which SHOULD be <service-unavailable/>. entire stanza or return a stanza error, which SHOULD be <service-
unavailable/>.
o If an entity receives a presence stanza whose only child element o If an intended recipient receives a presence stanza whose only
is qualified by a namespace it does not understand, then it MUST child element is qualified by a namespace it does not understand,
ignore the child element by treating the presence stanza as if it then it MUST ignore the child element by treating the presence
contained no child element. stanza as if it contained no child element.
o If an entity receives a message or presence stanza that contains o If an intended recipient receives a message or presence stanza
XML data qualified by a namespace it does not understand, then it that contains XML data qualified by a namespace it does not
MUST ignore the portion of the stanza qualified by the unknown understand, then it MUST ignore the portion of the stanza
namespace. qualified by the unknown namespace.
o If an entity receives an IQ stanza of type "get" or "set" o If an intended recipient receives an IQ stanza of type "get" or
containing a child element qualified by a namespace it does not "set" containing a child element qualified by a namespace it does
understand, then the entity MUST return an IQ stanza of type not understand, then the entity MUST return an IQ stanza of type
"error" with an error condition of <service-unavailable/>. "error" with an error condition of <service-unavailable/>.
If a server handles a stanza that is intended for delivery to another If a server handles a stanza that is intended for delivery to another
entity and that contains a child element it does not understand, it entity and that contains a child element it does not understand, it
MUST route the stanza unmodified to a remote server or deliver the MUST route the stanza unmodified to a remote server or deliver the
stanza unmodified to a connected client associated with a local stanza unmodified to a connected client associated with a local
account. account.
9. Detailed Examples 9. Detailed Examples
skipping to change at page 126, line 15 skipping to change at page 130, line 15
Step 2: Server responds by sending a response stream header to Step 2: Server responds by sending a response stream header to
client: client:
S: <stream:stream S: <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'>
Step 3: Server sends stream features to client (only the STARTTLS Step 3: Server sends stream features to client (only the STARTTLS
extension at this point): extension at this point, which is mandatory-to-negotiate):
S: <stream:features> S: <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>
Step 4: Client sends STARTTLS command to server: Step 4: Client sends STARTTLS command to server:
C: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> C: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
Step 5: Server informs client that it is allowed to proceed: Step 5: Server informs client that it is allowed to proceed:
S: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> S: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
Step 5 (alt): Server informs client that STARTTLS negotiation has Step 5 (alt): Server informs client that STARTTLS negotiation has
failed and closes both XML stream and TCP connection: failed and closes both the XML stream and the TCP connection (thus
the stream negotiation process ends unsuccessfully and the parties do
not move on to the next step):
S: <failure xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> S: <failure xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
</stream:stream>
S: </stream:stream>
Step 6: Client and server attempt to complete TLS negotiation over Step 6: Client and server attempt to complete TLS negotiation over
the existing TCP connection (see [TLS] for details). the existing TCP connection (see [TLS] for details).
Step 7: If TLS negotiation is successful, client initiates a new Step 7: If TLS negotiation is successful, client initiates a new
stream to server over the TLS-protected TCP connection: stream to server over the TLS-protected TCP connection:
C: <stream:stream C: <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'>
Step 7 (alt): If TLS negotiation is unsuccessful, server closes TCP Step 7 (alt): If TLS negotiation is unsuccessful, server closes TCP
connection. connection (thus the stream negotiation process ends unsuccessfully
and the parties do not move on to the next step):
9.1.2. SASL 9.1.2. SASL
Step 8: Server responds by sending a stream header to client along Step 8: Server responds by sending a stream header to client along
with any available stream features: with any available stream features:
S: <stream:stream S: <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'>
S: <stream:features> S: <stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> <mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>SCRAM-SHA-1-PLUS</mechanism> <mechanism>SCRAM-SHA-1-PLUS</mechanism>
<mechanism>SCRAM-SHA-1</mechanism> <mechanism>SCRAM-SHA-1</mechanism>
<mechanism>PLAIN</mechanism> <mechanism>PLAIN</mechanism>
</mechanisms> </mechanisms>
</stream:features> </stream:features>
Step 9: Client selects an authentication mechanism, in this case Step 9: Client selects an authentication mechanism, in this case
SCRAM-SHA-1, including initial response data: SCRAM-SHA-1, including initial response data:
C: <auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl" C: <auth xmlns="urn:ietf:params:xml:ns:xmpp-sasl"
mechanism="SCRAM-SHA-1"> mechanism="SCRAM-SHA-1">
biwsbj1qdWxpZXQscj1vTXNUQUF3QUFBQU1BQUFBTlAwVEFBQUFBQUJQVTBBQQ== biwsbj1qdWxpZXQscj1vTXNUQUF3QUFBQU1BQUFBTlAwVEFBQUFBQUJQVTBBQQ==
</auth> </auth>
The decoded base64 data is The decoded base 64 data is
"n,,n=juliet,r=oMsTAAwAAAAMAAAANP0TAAAAAABPU0AA". "n,,n=juliet,r=oMsTAAwAAAAMAAAANP0TAAAAAABPU0AA".
Step 10: Server sends a challenge: Step 10: Server sends a challenge:
S: <challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl"> S: <challenge xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
cj1vTXNUQUF3QUFBQU1BQUFBTlAwVEFBQUFBQUJQVTBBQWUxMjQ2OTViLTY5Y cj1vTXNUQUF3QUFBQU1BQUFBTlAwVEFBQUFBQUJQVTBBQWUxMjQ2OTViLTY5Y
TktNGRlNi05YzMwLWI1MWIzODA4YzU5ZSxzPU5qaGtZVE0wTURndE5HWTBaaT TktNGRlNi05YzMwLWI1MWIzODA4YzU5ZSxzPU5qaGtZVE0wTURndE5HWTBaaT
AwTmpkbUxUa3hNbVV0TkRsbU5UTm1ORE5rTURNeixpPTQwOTY= AwTmpkbUxUa3hNbVV0TkRsbU5UTm1ORE5rTURNeixpPTQwOTY=
</challenge> </challenge>
The decoded base64 data is "r=oMsTAAwAAAAMAAAANP0TAAAAAABPU0AAe124695 The decoded base 64 data is "r=oMsTAAwAAAAMAAAANP0TAAAAAABPU0AAe12469
b-69a9-4de6-9c30- 5b-69a9-4de6-9c30-
b51b3808c59e,s=NjhkYTM0MDgtNGY0Zi00NjdmLTkxMmUtNDlmNTNmNDNkMDMz,i=409 b51b3808c59e,s=NjhkYTM0MDgtNGY0Zi00NjdmLTkxMmUtNDlmNTNmNDNkMDMz,i=409
6" (line breaks not included in actual data). 6" (line breaks not included in actual data).
Step 11: Client sends a response: Step 11: Client sends a response:
C: <response xmlns="urn:ietf:params:xml:ns:xmpp-sasl"> C: <response xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
Yz1iaXdzLHI9b01zVEFBd0FBQUFNQUFBQU5QMFRBQUFBQUFCUFUwQUFlMTI0N Yz1iaXdzLHI9b01zVEFBd0FBQUFNQUFBQU5QMFRBQUFBQUFCUFUwQUFlMTI0N
jk1Yi02OWE5LTRkZTYtOWMzMC1iNTFiMzgwOGM1OWUscD1VQTU3dE0vU3ZwQV jk1Yi02OWE5LTRkZTYtOWMzMC1iNTFiMzgwOGM1OWUscD1VQTU3dE0vU3ZwQV
RCa0gyRlhzMFdEWHZKWXc9 RCa0gyRlhzMFdEWHZKWXc9
</response> </response>
The decoded base64 data is "c=biws, r=oMsTAAwAAAAMAAAANP0TAAAAAABPU0A The decoded base 64 data is "c=biws, r=oMsTAAwAAAAMAAAANP0TAAAAAABPU0
Ae124695b-69a9-4de6-9c30-b51b3808c59e, p=UA57tM/ AAe124695b-69a9-4de6-9c30-b51b3808c59e, p=UA57tM/
SvpATBkH2FXs0WDXvJYw=" (line breaks not included in actual data). SvpATBkH2FXs0WDXvJYw=" (line breaks not included in actual data).
Step 12: Server informs client of success, including additional data Step 12: Server informs client of success, including additional data
with success: with success:
S: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> S: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
dj1wTk5ERlZFUXh1WHhDb1NFaVc4R0VaKzFSU289 dj1wTk5ERlZFUXh1WHhDb1NFaVc4R0VaKzFSU289
</success> </success>
The decoded base64 data is "v=pNNDFVEQxuXxCoSEiW8GEZ+1RSo=". The decoded base 64 data is "v=pNNDFVEQxuXxCoSEiW8GEZ+1RSo=".
Step 12 (alt): Server returns error to client: Step 12 (alt): Server returns a SASL error to client (thus the stream
negotiation process ends unsuccessfully and the parties do not move
on to the next step):
S: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> S: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<not-authorized/> <not-authorized/>
</failure> </failure>
</stream>
Step 13: Client initiates a new stream to server: Step 13: Client initiates a new stream to server:
C: <stream:stream C: <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'>
9.1.3. Resource Binding 9.1.3. Resource Binding
Step 14: Server responds by sending a stream header to client along Step 14: Server responds by sending a stream header to client along
with supported features (in this case resource binding): with supported features (in this case resource binding):
S: <stream:stream S: <stream:stream
from='im.example.com' from='im.example.com'
id='gPybzaOzBmaADgxKXu9UClbprp0=' id='gPybzaOzBmaADgxKXu9UClbprp0='
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,
needs to bind a resource to the stream; here we assume that the the client needs to bind a resource to the stream; here we assume
client submits a human-readable text string. that the client submits a human-readable text string.
Step 15: Client binds a resource: Step 15: Client binds a resource:
C: <iq id='yhc13a95' type='set'> C: <iq id='yhc13a95' type='set'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'> <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>balcony</resource> <resource>balcony</resource>
</bind> </bind>
</iq> </iq>
Step 16: Server accepts submitted resourcepart and informs client of Step 16: Server accepts submitted resourcepart and informs client of
successful resource binding: successful resource binding:
S: <iq id='yhc13a95' type='result'> S: <iq id='yhc13a95' 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>
Step 16 (alt): Server returns error to client: Step 16 (alt): Server returns error to client (thus the stream
negotiation process ends unsuccessfully and the parties do not move
on to the next step):
S: <iq id='yhc13a95' type='error'> S: <iq id='yhc13a95' type='error'>
<error type='cancel'> <error type='cancel'>
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error> </error>
</iq> </iq>
9.1.4. Stanza Exchange 9.1.4. Stanza Exchange
Now the client is allowed to send XML stanzas over the negotiated Now the client is allowed to send XML stanzas over the negotiated
skipping to change at page 130, line 45 skipping to change at page 135, line 10
type='chat' type='chat'
xml:lang='en'> xml:lang='en'>
<body>Neither, fair saint, if either thee dislike.</body> <body>Neither, fair saint, if either thee dislike.</body>
</message> </message>
The client can subsequently send and receive an unbounded number of The client can subsequently send and receive an unbounded number of
subsequent XML stanzas over the stream. subsequent XML stanzas over the stream.
9.1.5. Close 9.1.5. Close
Desiring to send no further messages, the client closes the stream Desiring to send no further messages, the client closes its stream to
but waits for incoming data from the server. the server but waits for incoming data from the server.
C: </stream:stream> C: </stream:stream>
Consistent with Section 4.4, the server might send additional data Consistent with Section 4.4, the server might send additional data to
and then closes the stream as well. the client and then closes its stream to the client.
S: </stream:stream> S: </stream:stream>
The client now sends a TLS close_notify alert, receives a responding The client now sends a TLS close_notify alert, receives a responding
close_notify alert from the server, and then terminates the close_notify alert from the server, and then terminates the
underlying TCP connection. underlying TCP connection.
9.2. Server-to-Server Examples 9.2. Server-to-Server Examples
The following examples show the data flow for a server negotiating an The following examples show the data flow for a server negotiating an
XML stream with another server, exchanging XML stanzas, and closing XML stream with a peer server, exchanging XML stanzas, and closing
the negotiated stream. The initiating server ("Server1") is the negotiated stream. The initiating server ("Server1") is
im.example.com; the receiving server ("Server2") is example.net and im.example.com; the receiving server ("Server2") is example.net and
it requires use of TLS; im.example.com presents a certificate and it requires use of TLS; im.example.com presents a certificate and
authenticates via the SASL EXTERNAL mechanism. It is assumed that authenticates via the SASL EXTERNAL mechanism. It is assumed that
before sending the initial stream header, Server1 has already before sending the initial stream header, Server1 has already
resolved an SRV record of _xmpp-server._tcp.example.net and has resolved an SRV record of _xmpp-server._tcp.example.net and has
opened a TCP connection to the advertised port at the resolved IP opened a TCP connection to the advertised port at the resolved IP
address. Note how Server1 declares the content namespace "jabber: address. Note how Server1 declares the content namespace "jabber:
server" as the default namespace and uses prefixes for stream-related server" as the default namespace and uses prefixes for stream-related
elements, whereas Server2 uses prefix-free canonicalization. elements, whereas Server2 uses prefix-free canonicalization.
skipping to change at page 132, line 6 skipping to change at page 136, line 16
Server1: Server1:
S2: <stream S2: <stream
from='example.net' from='example.net'
id='hTiXkW+ih9k2SqdGkk/AZi0OJ/Q=' id='hTiXkW+ih9k2SqdGkk/AZi0OJ/Q='
to='im.example.com' to='im.example.com'
version='1.0' version='1.0'
xmlns='http://etherx.jabber.org/streams'> xmlns='http://etherx.jabber.org/streams'>
Step 3: Server2 sends stream features to Server1 (only the STARTTLS Step 3: Server2 sends stream features to Server1 (only the STARTTLS
extension at this point): extension at this point, which is mandatory-to-negotiate):
S2: <features xmlns='http://etherx.jabber.org/streams'> S2: <features xmlns='http://etherx.jabber.org/streams'>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'> <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<required/> <required/>
</starttls> </starttls>
</features> </features>
Step 4: Server1 sends the STARTTLS command to Server2: Step 4: Server1 sends the STARTTLS command to Server2:
S1: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> S1: <starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
Step 5: Server2 informs Server1 that it is allowed to proceed: Step 5: Server2 informs Server1 that it is allowed to proceed:
S2: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> S2: <proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
Step 5 (alt): Server2 informs Server1 that STARTTLS negotiation has Step 5 (alt): Server2 informs Server1 that STARTTLS negotiation has
failed and closes stream: failed and closes stream (thus the stream negotiation process ends
unsuccessfully and the parties do not move on to the next step):
S2: <failure xmlns='urn:ietf:params:xml:ns:xmpp-tls'/> S2: <failure xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
</stream>
S2: </stream>
Step 6: Server1 and Server2 attempt to complete TLS negotiation via Step 6: Server1 and Server2 attempt to complete TLS negotiation via
TCP (see [TLS] for details). TCP (see [TLS] for details).
Step 7: If TLS negotiation is successful, Server1 initiates a new Step 7: If TLS negotiation is successful, Server1 initiates a new
stream to Server2 over the TLS-protected TCP connection: stream to Server2 over the TLS-protected TCP connection:
S1: <stream:stream S1: <stream:stream
from='im.example.com' from='im.example.com'
to='example.net' to='example.net'
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'>
Step 7 (alt): If TLS negotiation is unsuccessful, Server2 closes TCP Step 7 (alt): If TLS negotiation is unsuccessful, Server2 closes TCP
connection. connection (thus the stream negotiation process ends unsuccessfully
and the parties do not move on to the next step).
9.2.2. SASL 9.2.2. SASL
Step 8: Server2 sends a response stream header to Server1 along with Step 8: Server2 sends a response stream header to Server1 along with
available stream features (including a preference for the SASL available stream features (including a preference for the SASL
EXTERNAL mechanism): EXTERNAL mechanism):
S2: <stream S2: <stream
from='example.net' from='example.net'
id='RChdjlgj/TIBcbT9Keu31zDihH4=' id='RChdjlgj/TIBcbT9Keu31zDihH4='
skipping to change at page 133, line 34 skipping to change at page 137, line 36
Step 9: Server1 selects the EXTERNAL mechanism (including an empty Step 9: Server1 selects the EXTERNAL mechanism (including an empty
response of "="): response of "="):
S1: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' S1: <auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
mechanism='EXTERNAL'/>=</auth> mechanism='EXTERNAL'/>=</auth>
Step 10: Server2 returns success: Step 10: Server2 returns success:
S2: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/> S2: <success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
Step 10 (alt): Server2 informs Server1 of failed authentication: Step 10 (alt): Server2 informs Server1 of failed authentication (thus
the stream negotiation process ends unsuccessfully and the parties do
not move on to the next step):
S2: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'> S2: <failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<not-authorized/> <not-authorized/>
</failure> </failure>
</stream>
S2: </stream>
Step 11: Server1 initiates a new stream to Server2: Step 11: Server1 initiates a new stream to Server2:
S1: <stream:stream S1: <stream:stream
from='im.example.com' from='im.example.com'
to='example.net' to='example.net'
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'>
skipping to change at page 134, line 38 skipping to change at page 138, line 47
S1: <message from='juliet@im.example.com/balcony' S1: <message from='juliet@im.example.com/balcony'
id='ju2ba41c' id='ju2ba41c'
to='romeo@example.net' to='romeo@example.net'
type='chat' type='chat'
xml:lang='en'> xml:lang='en'>
<body>Art thou not Romeo, and a Montague?</body> <body>Art thou not Romeo, and a Montague?</body>
</message> </message>
9.2.4. Close 9.2.4. Close
Desiring to send no further messages, Server1 closes the stream. (In Desiring to send no further messages, Server1 closes its stream to
practice, the stream would most likely remain open for some time, Server2 but waits for incoming data from Server2. (In practice, the
since Server1 and Server2 do not immediately know if the stream will stream would most likely remain open for some time, since Server1 and
be needed for further communication.) Server2 do not immediately know if the stream will be needed for
further communication.)
S1: </stream:stream> S1: </stream:stream>
Consistent with the recommended stream closing handshake, Server2 Consistent with the recommended stream closing handshake, Server2
closes the stream as well: closes the stream as well:
S2: </stream> S2: </stream>
Server1 now sends a TLS close_notify alert, receives a responding Server1 now sends a TLS close_notify alert, receives a responding
close_notify alert from Server2, and then terminates the underlying close_notify alert from Server2, and then terminates the underlying
TCP connection. TCP connection.
skipping to change at page 135, line 20 skipping to change at page 139, line 30
entity (typically a connected client associated with a local entity (typically a connected client associated with a local
account), or handle it directly within the server itself. This account), or handle it directly within the server itself. This
section provides general rules for processing XML stanzas. However, section provides general rules for processing XML stanzas. However,
particular XMPP applications MAY specify delivery rules that modify particular XMPP applications MAY specify delivery rules that modify
or supplement the following rules (e.g., a set of delivery rules for or supplement the following rules (e.g., a set of delivery rules for
instant messaging and presence applications is defined in [XMPP-IM]). instant messaging and presence applications is defined in [XMPP-IM]).
10.1. In-Order Processing 10.1. In-Order Processing
An XMPP server MUST ensure in-order processing of the stanzas and An XMPP server MUST ensure in-order processing of the stanzas and
other XML elements it receives over a given stream from a connected other XML elements it receives over a given input stream from a
client or remote server (for purposes of this section we describe connected client or remote server.
such a stream as an "input stream", in contrast to an "output stream"
that a server would use to deliver data to a connected client or to
route data to a remote server).
In-order processing applies (a) to any XML elements used to negotiate In-order processing applies (a) to any XML elements used to negotiate
and manage XML streams, and (b) to all uses of XML stanzas, including and manage XML streams, and (b) to all uses of XML stanzas, including
but not limited to the following: but not limited to the following:
1. Stanzas sent by a client to its server or to its own bare JID for 1. Stanzas sent by a client to its server or to its own bare JID for
direct processing by the server (e.g., in-order processing of a direct processing by the server (e.g., in-order processing of a
roster get and initial presence as described in [XMPP-IM]). roster get and initial presence as described in [XMPP-IM]).
2. Stanzas sent by a connected client and intended for delivery to 2. Stanzas sent by a connected client and intended for delivery to
another entity associated with a local domain (e.g., stanzas another entity associated with the server (e.g., stanzas
addressed from <juliet@im.example.com> to addressed from <juliet@im.example.com> to
<nurse@im.example.com>). The server MUST ensure that it delivers <nurse@im.example.com>). The server MUST ensure that it delivers
stanzas addressed to the intended recipient in the order it stanzas addressed to the intended recipient in the order it
receives them over the input stream from the sending client, receives them over the input stream from the sending client,
treating stanzas addressed to the bare JID and the full JID of treating stanzas addressed to the bare JID and the full JID of
the intended recipient as equivalent for delivery purposes. the intended recipient as equivalent for delivery purposes.
3. Stanzas sent by a connected client and intended for delivery to 3. Stanzas sent by a connected client and intended for delivery to
an entity located at a remote domain (e.g., stanzas addressed an entity located at a remote domain (e.g., stanzas addressed
from <juliet@im.example.com> to <romeo@example.net>). The from <juliet@im.example.com> to <romeo@example.net>). The
skipping to change at page 136, line 35 skipping to change at page 140, line 46
request. request.
In-order processing applies only to a single input stream. Therefore In-order processing applies only to a single input stream. Therefore
a server is not responsible for ensuring the coherence of data it a server is not responsible for ensuring the coherence of data it
receives across multiple input streams associated with the same local receives across multiple input streams associated with the same local
account (e.g., stanzas received over two different input streams from account (e.g., stanzas received over two different input streams from
<juliet@im.example.com/balcony> and <juliet@im.example.com/chamber>) <juliet@im.example.com/balcony> and <juliet@im.example.com/chamber>)
or the same remote domain (e.g., two different input streams or the same remote domain (e.g., two different input streams
negotiated by a remote domain; however, a server MAY return a negotiated by a remote domain; however, a server MAY return a
<conflict> stream error to a remote server that attempts to negotiate <conflict> stream error to a remote server that attempts to negotiate
more than one stream, as described under Section 4.8.3.3). more than one stream, as described under Section 4.9.3.3).
10.2. General Considerations 10.2. General Considerations
At high level, there are three primary considerations at play in At high level, there are three primary considerations at play in
server processing of XML stanzas, which sometimes are at odds but server processing of XML stanzas, which sometimes are at odds but
need to be managed in a consistent way: need to be managed in a consistent way:
1. It is good to deliver a stanza to the intended recipient if 1. It is good to deliver a stanza to the intended recipient if
possible. possible.
skipping to change at page 137, line 19 skipping to change at page 141, line 28
effective difference between the server's (i) delivering the effective difference between the server's (i) delivering the
stanza or storing it offline for later delivery (see [XMPP-IM]) stanza or storing it offline for later delivery (see [XMPP-IM])
and (ii) silently ignoring it (because an error is not returned and (ii) silently ignoring it (because an error is not returned
immediately in any of those cases); therefore, in scenarios where immediately in any of those cases); therefore, in scenarios where
a server delivers a stanza or places the stanza into offline a server delivers a stanza or places the stanza into offline
storage for later delivery, it needs to silently ignore the storage for later delivery, it needs to silently ignore the
stanza if that account does not exist. stanza if that account does not exist.
2. How a server processes stanzas sent to the bare JID 2. How a server processes stanzas sent to the bare JID
<localpart@domainpart> has implications for directory harvesting, <localpart@domainpart> has implications for directory harvesting,
because if the server responds differently depending on whether because an attacker could determine whether an account exists if
there there is an account registered for that bare JID. the server responds differently depending on whether there there
is an account for a given bare JID.
3. How a server processes stanzas sent to a full JID has 3. How a server processes stanzas sent to a full JID has
implications for presence leaks, because an attacker could send implications for presence leaks, because an attacker could send
requests to multiple full JIDs and receive different replies requests to multiple full JIDs and receive different replies
depending on whether the user has a device currently online at depending on whether the user has a device currently online at
that full JID. The use of randomized resourceparts (whether that full JID. The use of randomized resourceparts (whether
generated by the client or the server) significantly helps to generated by the client or the server as described under
mitigate this attack, so it is of somewhat lesser concern than Section 7) significantly helps to mitigate this attack, so it is
the directory harvesting attack. of somewhat lesser concern than the directory harvesting attack.
Naturally, presence is not leaked if the entity to which a user's Naturally, presence is not leaked if the entity to which a user's
server returns an error already knows the user's presence or is server returns an error already knows the user's presence or is
authorized to do so (e.g., by means of a presence subscription or authorized to do so (e.g., by means of a presence subscription or
directed presence), and a server does not enable a directory directed presence), and a server does not enable a directory
harvesting attack if it returns an error to an entity that already harvesting attack if it returns an error to an entity that already
knows if a user exists (e.g., because the entity is in the user's knows if a user exists (e.g., because the entity is in the user's
contact list); these matters are discussed more fully in [XMPP-IM]. contact list); these matters are discussed more fully in [XMPP-IM].
10.3. No 'to' Address 10.3. No 'to' Address
skipping to change at page 138, line 41 skipping to change at page 142, line 51
sending entity's bare JID to the particular resource of the sending entity's bare JID to the particular resource of the
sending entity that requested the roster. sending entity that requested the roster.
2. If the IQ stanza is of type "get" or "set" and the server does 2. If the IQ stanza is of type "get" or "set" and the server does
not understand the namespace that qualifies the payload, the not understand the namespace that qualifies the payload, the
server MUST return an error to the sending entity, which MUST be server MUST return an error to the sending entity, which MUST be
<service-unavailable/>. <service-unavailable/>.
3. If the IQ stanza is of type "error" or "result", the server MUST 3. If the IQ stanza is of type "error" or "result", the server MUST
handle the error or result in accordance with the payload of the handle the error or result in accordance with the payload of the
associated IQ stanza or type "get" of "set" (if there is no such associated IQ stanza or type "get" or "set" (if there is no such
associated stanza, the server MUST ignore the error or result associated stanza, the server MUST ignore the error or result
stanza). stanza).
10.4. Remote Domain 10.4. Remote Domain
If the domainpart of the JID contained in the 'to' attribute does not If the domainpart of the JID contained in the 'to' attribute does not
match one of the configured hostnames of the server, the server match one of the configured FQDNs of the server, the server SHOULD
SHOULD attempt to route the stanza to the remote domain (subject to attempt to route the stanza to the remote domain (subject to local
local service provisioning and security policies regarding inter- service provisioning and security policies regarding inter-domain
domain communication, since such communication is optional for any communication, since such communication is OPTIONAL for any given
given deployment). As described in the following sections, there are deployment). As described in the following sections, there are two
two possible cases. possible cases.
Security Note: These rules apply only client-to-server streams. Security Warning: These rules apply only client-to-server streams.
As described under Section 8.1.1.2, a server MUST NOT accept a As described under Section 8.1.1.2, a server MUST NOT accept a
stanza over a server-to-server stream if the domainpart of the JID stanza over a server-to-server stream if the domainpart of the JID
in the 'to' attribute does not match a hostname serviced by the in the 'to' attribute does not match an FQDN serviced by the
receiving server. receiving server.
10.4.1. Existing Stream 10.4.1. Existing Stream
If a server-to-server stream already exists between the two domains, If a server-to-server stream already exists between the two domains,
the sender's server will attempt to route the stanza to the the sender's server SHOULD attempt to route the stanza to the
authoritative server for the remote domain over the existing stream. authoritative server for the remote domain over the existing stream.
10.4.2. No Existing Stream 10.4.2. No Existing Stream
If there exists no server-to-server stream between the two domains, If there exists no server-to-server stream between the two domains,
the sender's server will proceed as follows: the sender's server will proceed as follows:
1. Resolve the hostname of the remote domain, as described under 1. Resolve the FQDN of the remote domain (as described under
Section 13.9.2). Section 13.9.2).
2. Negotiate a server-to-server stream between the two domains (as 2. Negotiate a server-to-server stream between the two domains (as
defined under Section 5 and Section 6). defined under Section 5 and Section 6).
3. Route the stanza to the authoritative server for the remote 3. Route the stanza to the authoritative server for the remote
domain over the newly-established stream. domain over the newly-established stream.
10.4.3. Error Handling 10.4.3. Error Handling
skipping to change at page 139, line 49 skipping to change at page 144, line 12
streams cannot be negotiated, the stanza error MUST be <remote- streams cannot be negotiated, the stanza error MUST be <remote-
server-timeout/>. server-timeout/>.
If stream negotiation with the intended recipient's server is If stream negotiation with the intended recipient's server is
successful but the remote server cannot deliver the stanza to the successful but the remote server cannot deliver the stanza to the
recipient, the remote server MUST return an appropriate error to the recipient, the remote server MUST return an appropriate error to the
sender by way of the sender's server. sender by way of the sender's server.
10.5. Local Domain 10.5. Local Domain
If the hostname of the domainpart of the JID contained in the 'to' If the domainpart of the JID contained in the 'to' attribute matches
attribute matches one of the configured hostnames of the server, the one of the configured FQDNs of the server, the server MUST first
server MUST first determine if the hostname is serviced by the server determine if the FQDN is serviced by the server itself or by a
itself or by a specialized local service. If the latter, the server specialized local service. If the latter, the server MUST route the
MUST route the stanza to that service. If the former, the server stanza to that service. If the former, the server MUST proceed as
MUST proceed as follows. However, the server MUST NOT route or follows. However, the server MUST NOT route or "forward" the stanza
"forward" the stanza to another domain because it is the server's to another domain, because it is the server's responsibility to
responsibility to process all stanzas for which the domainpart of the process all stanzas for which the domainpart of the 'to' address
'to' address matches one of the configured hostnames of the server matches one of the configured FQDNs of the server (among other
(among other things, this helps to prevent looping). things, this helps to prevent looping).
10.5.1. Mere Domain 10.5.1. domainpart
If the JID contained in the 'to' attribute is of the form <domain>, If the JID contained in the 'to' attribute is of the form
then the server MUST either (a) handle the stanza as appropriate for <domainpart>, then the server MUST either (a) handle the stanza as
the stanza kind or (b) return an error stanza to the sender. appropriate for the stanza kind or (b) return an error stanza to the
sender.
10.5.2. Domain with Resource 10.5.2. domainpart/resourcepart
If the JID contained in the 'to' attribute is of the form If the JID contained in the 'to' attribute is of the form
<domainpart/resourcepart>, then the server MUST either (a) handle the <domainpart/resourcepart>, then the server MUST either (a) handle the
stanza as appropriate for the stanza kind or (b) return an error stanza as appropriate for the stanza kind or (b) return an error
stanza to the sender. stanza to the sender.
10.5.3. Localpart at Domain 10.5.3. localpart@domainpart
An address of this type is normally associated with an account on the An address of this type is normally associated with an account on the
server. The following rules provide some general guidelines; more server. The following rules provide some general guidelines; more
detailed rules in the context of instant messaging and presence detailed rules in the context of instant messaging and presence
applications are provided in [XMPP-IM]. applications are provided in [XMPP-IM].
10.5.3.1. No Such User 10.5.3.1. No Such User
If there is no local account associated with the If there is no local account associated with the
<localpart@domainpart>, how the stanza is processed depends on the <localpart@domainpart>, how the stanza is processed depends on the
skipping to change at page 140, line 48 skipping to change at page 145, line 11
o For a message stanza, the server MUST either (a) silently ignore o For a message stanza, the server MUST either (a) silently ignore
the stanza or (b) return a <service-unavailable/> stanza error to the stanza or (b) return a <service-unavailable/> stanza error to
the sender. the sender.
o For a presence stanza, the server SHOULD ignore the stanza (or o For a presence stanza, the server SHOULD ignore the stanza (or
behave as described in [XMPP-IM]). behave as described in [XMPP-IM]).
o For an IQ stanza, the server MUST return a <service-unavailable/> o For an IQ stanza, the server MUST return a <service-unavailable/>
stanza error to the sender. stanza error to the sender.
10.5.3.2. Bare JID 10.5.3.2. User Exists
If the JID contained in the 'to' attribute is of the form If the JID contained in the 'to' attribute is of the form
<localpart@domainpart>, how the stanza is processed depends on the <localpart@domainpart>, how the stanza is processed depends on the
stanza type. stanza type.
o For a message stanza, if there exists at least one connected o For a message stanza, if there exists at least one connected
resource for the account the server SHOULD deliver it to at least resource for the account then the server SHOULD deliver it to at
one of the connected resources. If there exists no connected least one of the connected resources. If there exists no
resource, the server MUST either (a) store the message offline for connected resource then the server MUST either (a) store the
delivery when the account next has a connected resource or (b) message offline for delivery when the account next has a connected
return a <service-unavailable/> stanza error. resource or (b) return a <service-unavailable/> stanza error.
o For a presence stanza, if there exists at least one connected o For a presence stanza, if there exists at least one connected
resource that has sent initial presence (i.e., has a "presence resource that has sent initial presence (i.e., has a "presence
session" as defined in [XMPP-IM]), the server SHOULD deliver it to session" as defined in [XMPP-IM]) then the server SHOULD deliver
such resources. If there exists no connected resource, the server it to such resources. If there exists no connected resource then
SHOULD ignore the stanza (or behave as described in [XMPP-IM]). the server SHOULD ignore the stanza (or behave as described in
[XMPP-IM]).
o For an IQ stanza, the server MUST handle it directly on behalf of o For an IQ stanza, the server MUST handle it directly on behalf of
the intended recipient. the intended recipient.
10.5.3.3. Full JID 10.5.4. localpart@domainpart/resourcepart
If the JID contained in the 'to' attribute is of the form If the JID contained in the 'to' attribute is of the form
<localpart@domainpart/resourcepart> and there is no connected <localpart@domainpart/resourcepart> and the user exists but there is
resource that exactly matches the full JID, the stanza SHOULD be no connected resource that exactly matches the full JID, the stanza
processed as if the JID were of the form <localpart@domainpart>. SHOULD be processed as if the JID were of the form
<localpart@domainpart> as described under Section 10.5.3.2.
If the JID contained in the 'to' attribute is of the form If the JID contained in the 'to' attribute is of the form
<localpart@domainpart/resourcepart> and there is a connected resource <localpart@domainpart/resourcepart>, the user exists, and there is a
that exactly matches the full JID, the server MUST deliver the stanza connected resource that exactly matches the full JID, the server MUST
to that connected resource. deliver the stanza to that connected resource.
11. XML Usage 11. XML Usage
11.1. XML Restrictions 11.1. XML Restrictions
XMPP defines a class of data objects called XML streams as well as XMPP defines a class of data objects called XML streams as well as
the behavior of computer programs that process XML streams. XMPP is the behavior of computer programs that process XML streams. XMPP is
an application profile or restricted form of the Extensible Markup an application profile or restricted form of the Extensible Markup
Language [XML], and a complete XML stream (including start and end Language [XML], and a complete XML stream (including start and end
stream tags) is a conforming XML document. stream tags) is a conforming XML document.
However, XMPP does not deal with XML documents but with XML streams. However, XMPP does not deal with XML documents but with XML streams.
Because XMPP does not require the parsing of arbitrary and complete Because XMPP does not require the parsing of arbitrary and complete
skipping to change at page 142, line 32 skipping to change at page 146, line 47
implementations send <bad-format/> instead). implementations send <bad-format/> instead).
11.2. XML Namespace Names and Prefixes 11.2. XML Namespace Names and Prefixes
XML namespaces (see [XML-NAMES]) are used within XMPP streams to XML namespaces (see [XML-NAMES]) are used within XMPP streams to
create strict boundaries of data ownership. The basic function of create strict boundaries of data ownership. The basic function of
namespaces is to separate different vocabularies of XML elements that namespaces is to separate different vocabularies of XML elements that
are structurally mixed together. Ensuring that XMPP streams are are structurally mixed together. Ensuring that XMPP streams are
namespace-aware enables any allowable XML to be structurally mixed namespace-aware enables any allowable XML to be structurally mixed
with any data element within XMPP. XMPP-specific rules for XML with any data element within XMPP. XMPP-specific rules for XML
namespace names and prefixes are defined under Section 4.7 for XML namespace names and prefixes are defined under Section 4.8 for XML
streams and Section 8.4 for XML stanzas. streams and Section 8.4 for XML stanzas.
11.3. Well-Formedness 11.3. Well-Formedness
There are two varieties of well-formedness: In XML, there are two varieties of well-formedness:
o "XML-well-formedness" in accordance with the definition of "well- o "XML-well-formedness" in accordance with the definition of "well-
formed" from Section 2.1 of [XML]. formed" from Section 2.1 of [XML].
o "Namespace-well-formedness" in accordance with the definition of o "Namespace-well-formedness" in accordance with the definition of
"namespace-well-formed" from Section 7 of [XML-NAMES]. "namespace-well-formed" from Section 7 of [XML-NAMES].
The following rules apply. The following rules apply.
An XMPP entity MUST NOT generate data that is not XML-well-formed. 1. An XMPP entity MUST NOT generate data that is not XML-well-
An XMPP entity MUST NOT accept data that is not XML-well-formed; formed.
instead it MUST return a <not-well-formed/> stream error and close
the stream over which the data was received.
An XMPP entity MUST NOT generate data that is not namespace-well- 2. An XMPP entity MUST NOT accept data that is not XML-well-formed;
formed. An XMPP entity MUST NOT accept data that is not namespace- instead it MUST return a <not-well-formed/> stream error and
well-formed (in particular, an XMPP server MUST NOT route or deliver close the stream over which the data was received.
data that is not namespace-well-formed); instead it MUST return
either a stanza error of <not-acceptable/> or a stream error of <not- 3. An XMPP entity MUST NOT generate data that is not namespace-well-
well-formed/> (where it is preferable to return a stream error formed.
because accepting such data can open an entity to certain denial of
service attacks). 4. An XMPP entity MUST NOT accept data that is not namespace-well-
formed (in particular, an XMPP server MUST NOT route or deliver
data that is not namespace-well-formed); instead it MUST return
either a stanza error of <not-acceptable/> or a stream error of
<not-well-formed/> (where it is preferable to return a stream
error because accepting such data can open an entity to certain
denial of service attacks).
Interoperability Note: Because these restrictions were Interoperability Note: Because these restrictions were
underspecified in [RFC3920], it is possible that implementations underspecified in [RFC3920], it is possible that implementations
based on that specification will send data that does not comply based on that specification will send data that does not comply
with these restrictions. with these restrictions.
11.4. Validation 11.4. Validation
A server is not responsible for ensuring that XML data delivered to a A server is not responsible for ensuring that XML data delivered to a
client or routed to another server is valid, in accordance with the connected client or routed to a peer server is valid, in accordance
definition of "valid" provided in Section 2.8 of [XML]. An with the definition of "valid" provided in Section 2.8 of [XML]. An
implementation MAY choose to accept or provide only data that has implementation MAY choose to accept or send only data that has been
been explicitly validated against the schemas provided in this explicitly validated against the schemas provided in this document,
document, but such behavior is OPTIONAL. A client SHOULD NOT rely on but such behavior is OPTIONAL. Clients are advised not to rely on
the ability to send data that does not conform to the schemas, and the ability to send data that does not conform to the schemas, and
SHOULD ignore any non-conformant elements or attributes on the SHOULD ignore any non-conformant elements or attributes on the
incoming XML stream. incoming XML stream.
Informational Note: The terms "valid" and "well-formed" are Informational Note: The terms "valid" and "well-formed" are
distinct in XML. distinct in XML.
11.5. Inclusion of XML Declaration 11.5. Inclusion of XML Declaration
Before sending a stream header, an implementation SHOULD send an XML Before sending a stream header, an implementation SHOULD send an XML
declaration (matching production [23] content of [XML]). declaration (matching the "XMLDecl" production from [XML]).
Applications MUST follow the rules provided in [XML] regarding the Applications MUST follow the rules provided in [XML] regarding the
format of the XML declaration and the circumstances under which the format of the XML declaration and the circumstances under which the
XML declaration is included. XML declaration is included.
Because external markup declarations are prohibited in XMPP (as Because external markup declarations are prohibited in XMPP (as
described under Section 11.1), the standalone document declaration described under Section 11.1), the standalone document declaration
(matching production [32] content of [XML]) would have no meaning and (matching the "SDDecl" production from [XML]) would have no meaning
therefore SHOULD NOT be included in an XML declaration sent over an and therefore MUST NOT be included in an XML declaration sent over an
XML stream. If an XMPP entity receives an XML declaration containing XML stream. If an XMPP entity receives an XML declaration containing
a standalone document declaration set to a value of "no", the entity a standalone document declaration set to a value of "no", the entity
MUST either ignore the standalone document declaration or return a MUST either ignore the standalone document declaration or return a
stream error (which SHOULD be <restricted-xml/>). stream error (which SHOULD be <restricted-xml/>).
11.6. Character Encoding 11.6. Character Encoding
Implementations MUST support the UTF-8 transformation of Universal Implementations MUST support the UTF-8 transformation of Universal
Character Set [UCS2] characters, as needed for conformance with Character Set [UCS2] characters, as needed for conformance with
[CHARSETS] and as defined in [UTF-8]. Implementations MUST NOT [CHARSETS] and as defined in [UTF-8]. Implementations MUST NOT
attempt to use any other encoding. If one party to an XML stream attempt to use any other encoding. If one party to an XML stream
detects that the other party has attempted to send XML data with an detects that the other party has attempted to send XML data with an
encoding other than UTF-8, it MUST return a stream error, which encoding other than UTF-8, it MUST return a stream error, which
SHOULD be <unsupported-encoding/> (although some existing SHOULD be <unsupported-encoding/> (although some existing
implementations send <bad-format/> instead). implementations send <bad-format/> instead).
Implementation Note: Because it is mandatory for an XMPP Because it is mandatory for an XMPP implementation to support all and
implementation to support all and only the UTF-8 encoding and only the UTF-8 encoding and because UTF-8 always has the same byte
because UTF-8 always has the same byte order, an implementation order, an implementation MUST NOT send a byte order mark ("BOM") at
MUST NOT send a byte order mark ("BOM") at the beginning of the the beginning of the data stream. If an entity receives the
data stream. If an entity receives the [UNICODE] character U+FEFF [UNICODE] character U+FEFF anywhere in an XML stream (including as
anywhere in an XML stream (including as the first character of the the first character of the stream), it MUST interpret that character
stream), it MUST interpret that character as a zero width no-break as a zero width no-break space, not as a byte order mark.
space, not as a byte order mark.
11.7. Whitespace 11.7. Whitespace
Except where explicitly disallowed (e.g., during TLS negotiation Except where explicitly disallowed (e.g., during TLS negotiation
(Section 5) and SASL negotiation (Section 6)), either entity MAY send (Section 5) and SASL negotiation (Section 6)), either entity MAY send
whitespace as separators between XML stanzas or between any other whitespace as separators between XML stanzas or between any other
first-level elements sent over the stream. One common use for first-level elements sent over the stream. One common use for
sending such whitespace is explained under Section 4.4. sending such whitespace is explained under Section 4.4.
11.8. XML Versions 11.8. XML Versions
XMPP is an application profile of XML 1.0. A future version of XMPP XMPP is an application profile of XML 1.0. A future version of XMPP
might be defined in terms of higher versions of XML, but this might be defined in terms of higher versions of XML, but this
specification defines XMPP only in terms of XML 1.0. specification defines XMPP only in terms of XML 1.0.
12. Internationalization Considerations 12. Internationalization Considerations
As specified under Section 11.6, XML streams MUST be encoded in As specified under Section 11.6, XML streams MUST be encoded in
UTF-8. UTF-8.
As specified under Section 4.6, an XML stream SHOULD include an 'xml: As specified under Section 4.7, an XML stream SHOULD include an 'xml:
lang' attribute specifying the default language for any XML character lang' attribute specifying the default language for any XML character
data that is intended to be presented to a human user. As specified data that is intended to be presented to a human user. As specified
under Section 8.1.5, an XML stanza SHOULD include an 'xml:lang' under Section 8.1.5, an XML stanza SHOULD include an 'xml:lang'
attribute if the stanza contains XML character data that is intended attribute if the stanza contains XML character data that is intended
to be presented to a human user. A server SHOULD apply the default to be presented to a human user. A server SHOULD apply the default
'xml:lang' attribute to stanzas it routes or delivers on behalf of 'xml:lang' attribute to stanzas it routes or delivers on behalf of
connected entities, and MUST NOT modify or delete 'xml:lang' connected entities, and MUST NOT modify or delete 'xml:lang'
attributes on stanzas it receives from other entities. attributes on stanzas it receives from other entities.
Internationalization of XMPP addresses is specified in [XMPP-ADDR]. Internationalization of XMPP addresses is specified in [XMPP-ADDR].
skipping to change at page 146, line 4 skipping to change at page 150, line 25
communication path. The goal of security for a multi-hop path (cases communication path. The goal of security for a multi-hop path (cases
#3 and #4), although very desirable, is out of scope for this #3 and #4), although very desirable, is out of scope for this
specification. specification.
In accordance with [SEC-GUIDE], this specification covers In accordance with [SEC-GUIDE], this specification covers
communication security (confidentiality, data integrity, and peer communication security (confidentiality, data integrity, and peer
entity authentication), non-repudiation, and systems security entity authentication), non-repudiation, and systems security
(unauthorized usage, inappropriate usage, and denial of service). We (unauthorized usage, inappropriate usage, and denial of service). We
also discuss common security issues such as information leaks, also discuss common security issues such as information leaks,
firewalls, and directory harvesting, as well as best practices firewalls, and directory harvesting, as well as best practices
related to the re-use of technologies such as base64, DNS, related to the re-use of technologies such as base 64, DNS,
cryptographic hash functions, SASL, TLS, UTF-8, and XML. cryptographic hash functions, SASL, TLS, UTF-8, and XML.
13.2. Threat Model 13.2. Threat Model
The threat model for XMPP is in essence the standard "Internet Threat The threat model for XMPP is in essence the standard "Internet Threat
Model" described in [SEC-GUIDE]. Attackers are assumed to be Model" described in [SEC-GUIDE]. Attackers are assumed to be
interested in and capable of launching the following attacks against interested in and capable of launching the following attacks against
unprotected XMPP systems: unprotected XMPP systems:
o Eavesdropping o Eavesdropping
skipping to change at page 146, line 38 skipping to change at page 151, line 14
13.3. Order of Layers 13.3. Order of Layers
The order of layers in which protocols MUST be stacked is as follows: The order of layers in which protocols MUST be stacked is as follows:
1. TCP 1. TCP
2. TLS 2. TLS
3. SASL 3. SASL
4. XMPP 4. XMPP
This order has important security characteristics, as described This order has important security implications, as described
throughout these security considerations. throughout these security considerations.
Within XMPP, XML stanzas are ordered on top of XML streams, as Within XMPP, XML stanzas are further ordered on top of XML streams,
described under Section 4. as described under Section 4.
13.4. Confidentiality and Integrity 13.4. Confidentiality and Integrity
The use of Transport Layer Security (TLS) with appropriate The use of Transport Layer Security (TLS) with appropriate
ciphersuites provides a reliable mechanism to ensure the ciphersuites provides a reliable mechanism to ensure the
confidentiality and integrity of data exchanged between a client and confidentiality and integrity of data exchanged between a client and
a server or between two servers. Therefore TLS can help to protect a server or between two servers. Therefore TLS can help to protect
against eavesdropping, password sniffing, man-in-the-middle attacks, against eavesdropping, password sniffing, man-in-the-middle attacks,
and stanza replays, insertion, deletion, and modification over an XML and stanza replays, insertion, deletion, and modification over an XML
stream. XMPP clients and servers MUST support TLS as defined under stream. XMPP clients and servers MUST support TLS as defined under
Section 5. Section 5.
Informational Note: The confidentiality and integrity of a stream Informational Note: The confidentiality and integrity of a stream
can be ensured by methods other than TLS, e.g. by means of a SASL can be ensured by methods other than TLS, e.g. by means of a SASL
mechanism that involves negotiation of a security layer. mechanism that involves negotiation of a security layer.
Security Note: The use of TLS in XMPP applies to a single stream. Security Warning: The use of TLS in XMPP applies to a single
Because XMPP is typically deployed using a distributed client- stream. Because XMPP is typically deployed using a distributed
server architecture (as explained under Section 2.5), a stanza client-server architecture (as explained under Section 2.5), a
might traverse multiple streams, and not all of those streams stanza might traverse multiple streams, and not all of those
might be TLS-protected. For example, a stanza sent from a client streams might be TLS-protected. For example, a stanza sent from a
with a session at one server (e.g., <romeo@example.net/orchard>) client with a session at one server (e.g.,
and intended for delivery to a client with a session at another <romeo@example.net/orchard>) and intended for delivery to a client
server (e.g., <juliet@example.com/balcony>) will traverse three with a session at another server (e.g.,
streams: the stream from the sender's client to its server, the <juliet@example.com/balcony>) will traverse three streams: (1) the
stream from the sender's server to the recipient's server, and the stream from the sender's client to its server, (2) the stream from
stream from the recipient's server to the recipient's client. the sender's server to the recipient's server, and (3) the stream
from the recipient's server to the recipient's client.
Furthermore, the stanza will be processed as cleartext within the Furthermore, the stanza will be processed as cleartext within the
sender's server and the recipient's server. Therefore, even if sender's server and the recipient's server. Therefore, even if
the stream from the sender's client to its server is protected, the stream from the sender's client to its server is protected,
the confidentiality and integrity of a stanza sent over that the confidentiality and integrity of a stanza sent over that
protected stream cannot be guaranteed when the stanza is processed protected stream cannot be guaranteed when the stanza is processed
by the sender's server, sent from the sender's server to the by the sender's server, sent from the sender's server to the
recipient's server, processed by the recipient's server, or sent recipient's server, processed by the recipient's server, or sent
from the recipient's server to the recipient's client. Only a from the recipient's server to the recipient's client. Only a
robust technology for end-to-end encryption could ensure the robust technology for end-to-end encryption could ensure the
confidentiality and integrity of a stanza as it traverses all of confidentiality and integrity of a stanza as it traverses all of
skipping to change at page 148, line 7 skipping to change at page 152, line 31
clients and servers MUST support SASL as defined under Section 6. clients and servers MUST support SASL as defined under Section 6.
13.6. Strong Security 13.6. Strong Security
[STRONGSEC] defines "strong security" and its importance to [STRONGSEC] defines "strong security" and its importance to
communication over the Internet. For the purpose of XMPP communication over the Internet. For the purpose of XMPP
communication over client-to-server and server-to-server streams, the communication over client-to-server and server-to-server streams, the
term "strong security" refers to the use of security technologies term "strong security" refers to the use of security technologies
that provide both mutual authentication and integrity checking (e.g., that provide both mutual authentication and integrity checking (e.g.,
a combination of TLS encryption and SASL authentication using a combination of TLS encryption and SASL authentication using
appropriate SASL mechanisms). An implementation SHOULD make it appropriate SASL mechanisms).
possible for an end user or service administrator to provision a
deployment with specific trust anchors for the certificate presented
by a connecting entity (either client or server); when an application
is thus provisioned, it MUST NOT use a generic PKI trust store to
authenticate the connecting entity. More detailed rules and
guidelines regarding certificate validation are provided in the next
section.
Implementations MUST support strong security. Service provisioning Implementations MUST support strong security. Service provisioning
SHOULD use strong security. SHOULD use strong security.
An implementation SHOULD make it possible for an end user or service
administrator to provision a deployment with specific trust anchors
for the certificate presented by a connecting entity (either client
or server); when an application is thus provisioned, it MUST NOT use
a generic PKI trust store to authenticate the connecting entity.
More detailed rules and guidelines regarding certificate validation
are provided in the next section.
The initial stream and the response stream MUST be secured The initial stream and the response stream MUST be secured
separately, although security in both directions MAY be established separately, although security in both directions MAY be established
via mechanisms that provide mutual authentication. via mechanisms that provide mutual authentication.
13.7. Certificates 13.7. Certificates
Channel encryption of an XML stream using Transport Layer Security as Channel encryption of an XML stream using Transport Layer Security as
described under Section 5, and in some cases also authentication as described under Section 5, and in some cases also authentication as
described under Section 6, is commonly based on a digital certificate described under Section 6, is commonly based on a digital certificate
presented by the receiving entity (or, in the case of mutual presented by the receiving entity (or, in the case of mutual
skipping to change at page 149, line 37 skipping to change at page 154, line 14
5. For issuers of public key certificates, the issuer's certificate 5. For issuers of public key certificates, the issuer's certificate
MUST contain a basicConstraints extension with the cA boolean set MUST contain a basicConstraints extension with the cA boolean set
to TRUE. to TRUE.
13.7.1.2. Server Certificates 13.7.1.2. Server Certificates
13.7.1.2.1. Rules 13.7.1.2.1. Rules
In a digital certificate to be presented by an XMPP server (i.e., a In a digital certificate to be presented by an XMPP server (i.e., a
SERVER CERTIFICATE), it is RECOMMENDED for the certificate to include "server certificate"), it is RECOMMENDED for the certificate to
one or more JIDs (i.e., domainparts) associated with domains serviced include one or more JIDs (i.e., domainparts) associated with domains
at the server. The rules and guidelines defined in [TLS-CERTS] apply serviced at the server. The rules and guidelines defined in
to XMPP server certificates, with the following supplemental rules [TLS-CERTS] apply to XMPP server certificates, with the following
for XMPP: supplemental rules for XMPP:
o Support for the DNS-ID identifier type [PKIX] is REQUIRED in XMPP o Support for the DNS-ID identifier type [PKIX] is REQUIRED in XMPP
client and server software implementations. Certification client and server software implementations. Certification
authorities that issue XMPP-specific certificates MUST support the authorities that issue XMPP-specific certificates MUST support the
DNS-ID identifier type. Service providers SHOULD include the DNS-ID identifier type. Service providers SHOULD include the
DNS-ID identifier type in certificate requests. DNS-ID identifier type in certificate requests.
o Support for the SRV-ID identifier type [PKIX-SRV] is REQUIRED for o Support for the SRV-ID identifier type [PKIX-SRV] is REQUIRED for
XMPP client and server software implementations (for verification XMPP client and server software implementations (for verification
purposes XMPP client implementations need to support only the purposes XMPP client implementations need to support only the
skipping to change at page 150, line 16 skipping to change at page 154, line 42
certificates SHOULD support the SRV-ID identifier type. Service certificates SHOULD support the SRV-ID identifier type. Service
providers SHOULD include the SRV-ID identifier type in certificate providers SHOULD include the SRV-ID identifier type in certificate
requests. requests.
o Support for the XmppAddr identifier type (specified under o Support for the XmppAddr identifier type (specified under
Section 13.7.1.4) is encouraged in XMPP client and server software Section 13.7.1.4) is encouraged in XMPP client and server software
implementations for the sake of backward-compatibility, but is no implementations for the sake of backward-compatibility, but is no
longer encouraged in certificates issued by certification longer encouraged in certificates issued by certification
authorities or requested by service providers. authorities or requested by service providers.
o DNS domain names in server certificates MAY contain the wildcard
character '*' as the complete left-most label within the
identifier.
13.7.1.2.2. Examples 13.7.1.2.2. Examples
For our first (relatively simple) example, consider a company called For our first (relatively simple) example, consider a company called
"Example Products, Inc." It hosts an XMPP service at "Example Products, Inc." It hosts an XMPP service at
"im.example.com" (i.e., user addresses at the service are of the form "im.example.com" (i.e., user addresses at the service are of the form
"user@im.example.com"), and SRV lookups for the xmpp-client and xmpp- "user@im.example.com"), and SRV lookups for the xmpp-client and xmpp-
server services at "im.example.com" yield one machine, called server services at "im.example.com" yield one machine, called
"x.example.com", as follows: "x.example.com", as follows:
_xmpp-client._tcp.im.example.com. 400 IN SRV 20 0 5222 x.example.com _xmpp-client._tcp.im.example.com. 400 IN SRV 20 0 5222 x.example.com
skipping to change at page 151, line 43 skipping to change at page 156, line 23
string of: "example.net" string of: "example.net"
o An otherName type of XmppAddr (id-on-xmppAddr) containing a UTF-8 o An otherName type of XmppAddr (id-on-xmppAddr) containing a UTF-8
string of: "chat.example.net" string of: "chat.example.net"
o A CN containing an ASCII string of "Example Internet Services" o A CN containing an ASCII string of "Example Internet Services"
13.7.1.3. Client Certificates 13.7.1.3. Client Certificates
In a digital certificate to be presented by an XMPP client controlled In a digital certificate to be presented by an XMPP client controlled
by a human user (i.e., a CLIENT CERTIFICATE), it is RECOMMENDED for by a human user (i.e., a "client certificate"), it is RECOMMENDED for
the certificate to include one or more JIDs associated with an XMPP the certificate to include one or more JIDs associated with an XMPP
user. If included, a JID MUST be represented as an XmppAddr as user. If included, a JID MUST be represented as an XmppAddr as
specified under Section 13.7.1.4. specified under Section 13.7.1.4.
13.7.1.4. XmppAddr Identifier Type 13.7.1.4. XmppAddr Identifier Type
The XmppAddr identifier type is a UTF8String within an otherName The XmppAddr identifier type is a UTF8String within an otherName
entity inside the subjectAltName, using the [ASN.1] Object Identifier entity inside the subjectAltName, using the [ASN.1] Object Identifier
"id-on-xmppAddr" specified below. "id-on-xmppAddr" specified below.
skipping to change at page 153, line 18 skipping to change at page 157, line 50
by the issuing Certificate Authority. by the issuing Certificate Authority.
3. Attempt to validate the full certification path. 3. Attempt to validate the full certification path.
4. Check the rules for end entity public key certificates and 4. Check the rules for end entity public key certificates and
certification authority certificates specified under certification authority certificates specified under
Section 13.7.1.1 for the general case and under either Section 13.7.1.1 for the general case and under either
Section 13.7.1.2 or Section 13.7.1.2 for XMPP server or client Section 13.7.1.2 or Section 13.7.1.2 for XMPP server or client
certificates, respectively. certificates, respectively.
5. Check certificate revocation messages. 5. Check certificate revocation messages via Certificate Revocation
Lists (CRLs), the Online Certificate Status Protocol [OCSP], or
both.
If any of those validation attempts fail, either entity MUST If any of those validation attempts fail, the validating entity MUST
unilaterally terminate the session. unilaterally terminate the session.
The following sections describe the additional identity verification The following sections describe the additional identity verification
rules that apply to server-to-server and client-to-server streams. rules that apply to server-to-server and client-to-server streams.
Once the identity of the stream peer has been validated, the Once the identity of the stream peer has been validated, the
validating entity SHOULD also correlate the validated identity with validating entity SHOULD also correlate the validated identity with
the 'from' address (if any; see Section 4.6.1) of the stream header the 'from' address (if any) of the stream header it received from the
it received from the peer. If the two identities do not match, the peer. If the two identities do not match, the validating entity
validating entity SHOULD terminate the connection attempt. SHOULD terminate the connection attempt (however, there might be good
reasons why the identities do not match, as described under
Section 4.7.1).
13.7.2.1. Server Certificates 13.7.2.1. Server Certificates
For server certificates, the rules and guidelines defined in For server certificates, the rules and guidelines defined in
[TLS-CERTS] apply, with the proviso that the XmppAddr identifier [TLS-CERTS] apply, with the proviso that the XmppAddr identifier
specified under Section 13.7.1.4 is allowed as a reference specified under Section 13.7.1.4 is allowed as a reference
identifier. identifier.
The identities to be checked are set as follows: The identities to be checked are set as follows:
skipping to change at page 154, line 38 skipping to change at page 159, line 25
13.7.2.2.1. Case #1 13.7.2.2.1. Case #1
If the client certificate appears to be certified by a certification If the client certificate appears to be certified by a certification
path terminating in a trust anchor (as described in Section 6.1 of path terminating in a trust anchor (as described in Section 6.1 of
[PKIX]), the server MUST check the certificate for any instances of [PKIX]), the server MUST check the certificate for any instances of
the XmppAddr as described under Section 13.7.1.4. There are three the XmppAddr as described under Section 13.7.1.4. There are three
possible sub-cases: possible sub-cases:
Sub-Case #1: The server finds one XmppAddr for which the domainpart Sub-Case #1: The server finds one XmppAddr for which the domainpart
of the represented JID matches one of the configured hostnames of of the represented JID matches one of the configured FQDNs of the
the server; the server SHOULD use this represented JID as the server; the server SHOULD use this represented JID as the
validated identity of the client. validated identity of the client.
Sub-Case #2: The server finds more than one XmppAddr for which the Sub-Case #2: The server finds more than one XmppAddr for which the
domainpart of the represented JID matches one of the configured domainpart of the represented JID matches one of the configured
hostnames of the server; the server SHOULD use one of these FQDNs of the server; the server SHOULD use one of these
represented JIDs as the validated identity of the client, choosing represented JIDs as the validated identity of the client, choosing
among them according to local service policies or based on the among them based on the bare JID contained in the 'from' address
'to' address of the initial stream header. of the initial stream header (if any), based on the domainpart
contained in the 'to' address of the initial stream header, or in
accordance with local service policies (such as a lookup in a user
database based on other information contained in the client
certificate).
Sub-Case #3: The server finds no XmppAddrs, or finds at least one Sub-Case #3: The server finds no XmppAddrs, or finds at least one
XmppAddr but the domainpart of the represented JID does not match XmppAddr but the domainpart of the represented JID does not match
one of the configured hostnames of the server; the server MUST NOT one of the configured FQDNs of the server; the server MUST NOT use
use the represented JID (if any) as the validated identity of the the represented JID (if any) as the validated identity of the
client but instead MUST validate the identity of the client using client but instead MUST validate the identity of the client using
other means. If the identity cannot be so validated, depending on other means in accordance with local service policies (such as a
local service policy the server MAY abort the validation process lookup in a user database based on other information contained in
and terminate the TLS negotiation. the client certificate). If the identity cannot be so validated,
the server MAY abort the validation process and terminate the TLS
negotiation.
13.7.2.2.2. Case #2 13.7.2.2.2. Case #2
If the client certificate is certified by a Certificate Authority not If the client certificate is certified by a Certificate Authority not
known to the server, the server MUST proceed as under Case #1, Sub- known to the server, the server MUST proceed as under Case #1, Sub-
Case #3. Case #3.
13.7.2.2.3. Case #3 13.7.2.2.3. Case #3
If the client certificate is self-signed, the server MUST proceed as If the client certificate is self-signed, the server MUST proceed as
skipping to change at page 155, line 38 skipping to change at page 160, line 29
certificate presented during stream negotiation might expire or be certificate presented during stream negotiation might expire or be
revoked while the stream is still live (this is especially relevant revoked while the stream is still live (this is especially relevant
in the context of server-to-server streams). Therefore, each party in the context of server-to-server streams). Therefore, each party
to a long-lived stream SHOULD: to a long-lived stream SHOULD:
1. Cache the expiration date of the certificate presented by the 1. Cache the expiration date of the certificate presented by the
other party and any certificates on which that certificate other party and any certificates on which that certificate
depends (such as a root or intermediate certificate for a depends (such as a root or intermediate certificate for a
certification authority), and close the stream when any such certification authority), and close the stream when any such
certificate expires, with a stream error of <reset/> certificate expires, with a stream error of <reset/>
(Section 4.8.3.16). (Section 4.9.3.16).
2. Periodically query the Online Certificate Status Protocol [OCSP] 2. Periodically query the Online Certificate Status Protocol [OCSP]
responder listed in the Authority Information Access (AIA) responder listed in the Authority Information Access (AIA)
extension of the certificate presented by the other party and any extension of the certificate presented by the other party and any
certificates on which that certificate depends (such as a root or certificates on which that certificate depends (such as a root or
intermediate certificate for a certification authority), and intermediate certificate for a certification authority), and
close the stream if any such certificate has been revoked, with a close the stream if any such certificate has been revoked, with a
stream error of <reset/> (Section 4.8.3.16). It is RECOMMENDED stream error of <reset/> (Section 4.9.3.16). It is RECOMMENDED
to query the OSCP responder at or near the time communicated via to query the OSCP responder at or near the time communicated via
the nextUpdate field received in the OCSP response or, if the the nextUpdate field received in the OCSP response or, if the
nextUpdate field is not set, to query every 24 hours. nextUpdate field is not set, to query every 24 hours.
After the stream is closed, the initiating entity from the closed After the stream is closed, the initiating entity from the closed
stream will need to re-connect and the receiving entity will need to stream will need to re-connect and the receiving entity will need to
authenticate the initiating entity based on whatever certificate it authenticate the initiating entity based on whatever certificate it
presents during negotiation of the new stream. presents during negotiation of the new stream.
13.7.2.4. Use of Certificates in XMPP Extensions 13.7.2.4. Use of Certificates in XMPP Extensions
Certificates MAY be used in extensions to XMPP for the purpose of Certificates MAY be used in extensions to XMPP for the purpose of
application-layer encryption or authentication above the level of XML application-layer encryption or authentication above the level of XML
streams (e.g., for end-to-end encryption). Such extensions will streams (e.g., for end-to-end encryption). Such extensions will
define their own certificate handling rules, which at a minimum define their own certificate handling rules. At a minimum, such
SHOULD be consistent with the rules defined in this specification but extensions are encouraged to remain consistent with the rules defined
MAY specify additional rules. in this specification, specifying additional rules only when
necessary.
13.8. Mandatory-to-Implement TLS and SASL Technologies 13.8. Mandatory-to-Implement TLS and SASL Technologies
The following TLS ciphersuites and SASL mechanisms are mandatory-to- The following TLS ciphersuites and SASL mechanisms are mandatory-to-
implement (naturally, implementations MAY support other ciphersuites implement (naturally, implementations MAY support other ciphersuites
and mechanisms as well). For security considerations related to TLS and mechanisms as well). For security considerations related to TLS
ciphersuites, see Section 13.9.4 and [TLS]. For security ciphersuites, see Section 13.9.4 and [TLS]. For security
considerations related to SASL mechanisms, see Section 13.9.4, considerations related to SASL mechanisms, see Section 13.9.4,
[SASL], and specifications for particular SASL mechanisms such as [SASL], and specifications for particular SASL mechanisms such as
[SCRAM], [DIGEST-MD5], and [PLAIN]. [SCRAM], [DIGEST-MD5], and [PLAIN].
13.8.1. For Authentication Only 13.8.1. For Authentication Only
For authentication only, servers and clients MUST support the SASL For authentication only, servers and clients MUST support the SASL
Salted Challenge Response mechanism [SCRAM], in particular the SCRAM- Salted Challenge Response mechanism [SCRAM], in particular the SCRAM-
SHA-1 and SCRAM-SHA-1-PLUS variants. SHA-1 and SCRAM-SHA-1-PLUS variants.
Security Note: Even though it is possible to complete Security Warning: Even though it is possible to complete
authentication only without confidentiality, it is RECOMMENDED for authentication only without confidentiality, it is RECOMMENDED for
servers and clients to protect the stream with TLS before servers and clients to protect the stream with TLS before
attempting authentication with SASL, both to help protect the attempting authentication with SASL, both to help protect the
information exchanged during SASL negotiation and to help prevent information exchanged during SASL negotiation and to help prevent
certain downgrade attacks; see also Section 13.9.4 and certain downgrade attacks as described under Section 13.9.4 and
Section 13.9.5. Even if TLS is used, implementations SHOULD also Section 13.9.5. Even if TLS is used, implementations SHOULD also
enforce channel binding as described under Section 13.9.4. enforce channel binding as described under Section 13.9.4.
Interoperability Note: The SCRAM-SHA-1 or SASL-SCRAM-SHA-1-PLUS Interoperability Note: The SCRAM-SHA-1 or SASL-SCRAM-SHA-1-PLUS
variants of the SCRAM mechanism replace the SASL DIGEST-MD5 variants of the SCRAM mechanism replace the SASL DIGEST-MD5
mechanism as XMPP's mandatory-to-implement password-based method mechanism as XMPP's mandatory-to-implement password-based method
for authentication only. For backward-compatibility with existing for authentication only. For backward-compatibility with existing
deployed infrastructure, implementations are encouraged to deployed infrastructure, implementations are encouraged to
continue supporting the DIGEST-MD5 mechanism as specified in continue supporting the DIGEST-MD5 mechanism as specified in
[DIGEST-MD5]; however, there are known interoperability issues [DIGEST-MD5]; however, there are known interoperability issues
with DIGEST-MD5 that make it impractical in the long term. with DIGEST-MD5 that make it impractical in the long term.
13.8.2. For Confidentiality Only 13.8.2. For Confidentiality Only
For confidentiality only, servers SHOULD support TLS with the For confidentiality only, servers MUST support TLS with the
TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite. TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite.
Security Note: Because a connection with confidentiality only has Security Warning: Because a connection with confidentiality only
weaker security properties than a connection with both has weaker security properties than a connection with both
confidentiality and authentication, it is RECOMMENDED for servers confidentiality and authentication, it is RECOMMENDED for servers
and clients to prefer connections with both qualities (e.g., by and clients to prefer connections with both qualities (e.g., by
protecting the stream with TLS before attempting authentication protecting the stream with TLS before attempting authentication
with SASL). In practice, confidentiality only is employed merely with SASL). In practice, confidentiality only is employed merely
for server-to-server connections when the peer server does not for server-to-server connections when the peer server does not
present a certificate and the servers use Server Dialback present a trusted certificate and the servers use Server Dialback
[XEP-0220] for weak identity verification, but TLS is still [XEP-0220] for weak identity verification, but TLS with
desirable to protect the connection against casual eavesdropping. confidentiality only is still desirable to protect the connection
against casual eavesdropping.
13.8.3. For Confidentiality and Authentication With Passwords 13.8.3. For Confidentiality and Authentication With Passwords
For both confidentiality and authentication with passwords, servers For both confidentiality and authentication with passwords, servers
and clients MUST implement TLS with the TLS_RSA_WITH_AES_128_CBC_SHA and clients MUST implement TLS with the TLS_RSA_WITH_AES_128_CBC_SHA
ciphersuite plus SASL SCRAM, in particular the SCRAM-SHA-1 and SCRAM- ciphersuite plus SASL SCRAM, in particular the SCRAM-SHA-1 and SCRAM-
SHA-1-PLUS variants (with SCRAM-SHA1-PLUS being preferred, as SHA-1-PLUS variants (with SCRAM-SHA1-PLUS being preferred, as
described under Section 13.9.4). described under Section 13.9.4).
As further explained in the following Security Note, in certain As further explained in the following Security Warning, in certain
circumstances a server MAY offer TLS with the circumstances a server MAY offer TLS with the
TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite plus SASL PLAIN when it is TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite plus SASL PLAIN when it is
not possible to offer more secure alternatives; in addition, clients not possible to offer more secure alternatives; in addition, clients
SHOULD implement PLAIN over TLS in order to maximize interoperability SHOULD implement PLAIN over TLS in order to maximize interoperability
with servers that are not able to deploy more secure alternatives. with servers that are not able to deploy more secure alternatives.
Security Note: In practice, many servers offer, and many clients Security Warning: In practice, many servers offer, and many
use, TLS plus SASL PLAIN. The SCRAM-SHA-1 and especially SCRAM- clients use, TLS plus SASL PLAIN. The SCRAM-SHA-1 and especially
SHA-1-PLUS variants of the SCRAM mechanism are strongly preferred SCRAM-SHA-1-PLUS variants of the SCRAM mechanism are strongly
over the PLAIN mechanism because of their superior security preferred over the PLAIN mechanism because of their superior
properties (including for SCRAM-SHA-1-PLUS the ability to enforce security properties (including for SCRAM-SHA-1-PLUS the ability to
channel binding as described under Section 13.9.4). A client enforce channel binding as described under Section 13.9.4). A
SHOULD treat TLS plus SASL PLAIN as a technology of last resort to client SHOULD treat TLS plus SASL PLAIN as a technology of last
be used only when interacting with a server that does not offer resort to be used only when interacting with a server that does
SCRAM (or other alternatives that are more secure than TLS plus not offer SCRAM (or other alternatives that are more secure than
SASL PLAIN), MUST prefer more secure mechanisms (e.g., EXTERNAL, TLS plus SASL PLAIN), MUST prefer more secure mechanisms (e.g.,
SCRAM-SHA-1-PLUS, SCRAM-SHA-1, or the older DIGEST-MD5 mechanism) EXTERNAL, SCRAM-SHA-1-PLUS, SCRAM-SHA-1, or the older DIGEST-MD5
to the PLAIN mechanism, and MUST NOT use the PLAIN mechanism if mechanism) to the PLAIN mechanism, and MUST NOT use the PLAIN
the stream does not at a minimum have confidentiality and mechanism if the stream does not at a minimum have confidentiality
integrity protection via TLS with full certificate validation as and integrity protection via TLS with full certificate validation
described under Section 13.7.2.1. A server MUST NOT offer SASL as described under Section 13.7.2.1. A server MUST NOT offer SASL
PLAIN if the stream is not protected via TLS. A server SHOULD NOT PLAIN if the confidentiality and integrity of the stream are not
offer TLS plus SASL PLAIN unless it is unable to offer some ensured via TLS or an equivalent security layer. A server SHOULD
NOT offer TLS plus SASL PLAIN unless it is unable to offer some
variant of SASL SCRAM (or other alternatives that are more secure variant of SASL SCRAM (or other alternatives that are more secure
than TLS plus SASL PLAIN), e.g., because the XMPP service depends than TLS plus SASL PLAIN), e.g., because the XMPP service depends
for authentication purposes on a database or directory that is not for authentication purposes on a database or directory that is not
under the control of the XMPP administrators, such as Pluggable under the control of the XMPP administrators, such as Pluggable
Authentication Modules (PAM), an LDAP directory [LDAP], or an Authentication Modules (PAM), an LDAP directory [LDAP], or an
Authentication, Authorization, and Accounting (AAA) key management Authentication, Authorization, and Accounting (AAA) key management
protocol (for guidance, refer to [AAA]); however, offering TLS protocol (for guidance, refer to [AAA]); however, offering TLS
plus SASL PLAIN even when the server supports more secure plus SASL PLAIN even when the server supports more secure
alternatives might be appropriate if the server needs to enable alternatives might be appropriate if the server needs to enable
interoperability with an installed base of clients that do not yet interoperability with an installed base of clients that do not yet
skipping to change at page 158, line 26 skipping to change at page 163, line 18
13.8.4. For Confidentiality and Authentication Without Passwords 13.8.4. For Confidentiality and Authentication Without Passwords
For both confidentiality and authentication without passwords, For both confidentiality and authentication without passwords,
servers MUST and clients SHOULD implement TLS with the servers MUST and clients SHOULD implement TLS with the
TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite plus the SASL EXTERNAL TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite plus the SASL EXTERNAL
mechanism (see Appendix A of [SASL]) with PKIX certificates. mechanism (see Appendix A of [SASL]) with PKIX certificates.
13.9. Technology Reuse 13.9. Technology Reuse
13.9.1. Use of base64 in SASL 13.9.1. Use of Base64 in SASL
Both the client and the server MUST verify any base64 data received Both the client and the server MUST verify any base 64 data received
during SASL negotiation (Section 6). An implementation MUST reject during SASL negotiation (Section 6). An implementation MUST reject
(not ignore) any characters that are not explicitly allowed by the (not ignore) any characters that are not explicitly allowed by the
base64 alphabet; this helps to guard against creation of a covert base 64 alphabet; this helps to guard against creation of a covert
channel that could be used to "leak" information. channel that could be used to "leak" information.
An implementation MUST NOT break on invalid input and MUST reject any An implementation MUST NOT break on invalid input and MUST reject any
sequence of base64 characters containing the pad ('=') character if sequence of base 64 characters containing the pad ('=') character if
that character is included as something other than the last character that character is included as something other than the last character
of the data (e.g., "=AAA" or "BBBB=CCC"); this helps to guard against of the data (e.g., "=AAA" or "BBBB=CCC"); this helps to guard against
buffer overflow attacks and other attacks on the implementation. buffer overflow attacks and other attacks on the implementation.
While base 64 encoding visually hides otherwise easily recognized While base 64 encoding visually hides otherwise easily recognized
information (such as passwords), it does not provide any information (such as passwords), it does not provide any
computational confidentiality. computational confidentiality.
All uses of base 64 encoding MUST follow the definition in Section 4 All uses of base 64 encoding MUST follow the definition in Section 4
of [BASE64] and padding bits MUST be set to zero. of [BASE64] and padding bits MUST be set to zero.
13.9.2. Use of DNS 13.9.2. Use of DNS
XMPP typically relies on the Domain Name System (specifically XMPP typically relies on the Domain Name System (specifically
[DNS-SRV] records) to resolve a fully qualified domain name to an IP [DNS-SRV] records) to resolve a fully-qualified domain name to an IP
address before a client connects to a server or before a peer server address before a client connects to a server or before a peer server
connects to another server. Before attempting to negotiate an XML connects to another server. Before attempting to negotiate an XML
stream, the initiating entity MUST NOT proceed until it has resolved stream, the initiating entity MUST NOT proceed until it has resolved
the DNS domain name of the peer server as specified under Section 3 the DNS domain name of the receiving entity as specified under
(although it is not necessary to resolve the DNS domain name before Section 3 (although it is not necessary to resolve the DNS domain
each connection attempt, because DNS resolution results can be name before each connection attempt, because DNS resolution results
temporarily cached in accordance with time-to-live values). However, can be temporarily cached in accordance with time-to-live values).
in the absence of a secure DNS option (e.g., as provided by However, in the absence of a secure DNS option (e.g., as provided by
[DNSSEC]), a malicious attacker with access to the DNS server data, [DNSSEC]), a malicious attacker with access to the DNS server data,
or able to cause spoofed answers to be cached in a recursive or able to cause spoofed answers to be cached in a recursive
resolver, can potentially cause the initiating entity to connect to resolver, can potentially cause the initiating entity to connect to
any XMPP server chosen by the attacker. Deployment and validation of any XMPP server chosen by the attacker. Deployment and validation of
server certificates helps to prevent such attacks. server certificates helps to prevent such attacks.
13.9.3. Use of Hash Functions 13.9.3. Use of Hash Functions
XMPP itself does not directly mandate the use of any particular hash XMPP itself does not directly mandate the use of any particular
function. However, technologies on which XMPP depends (e.g., TLS and cryptographic hash function. However, technologies on which XMPP
particular SASL mechanisms), as well as various XMPP extensions, depends (e.g., TLS and particular SASL mechanisms), as well as
might make use of hash functions. Those who implement XMPP various XMPP extensions, might make use of cryptographic hash
technologies or who develop XMPP extensions are advised to closely functions. Those who implement XMPP technologies or who develop XMPP
monitor the state of the art regarding attacks against cryptographic extensions are advised to closely monitor the state of the art
hashes in Internet protocols as they relate to XMPP. For helpful regarding attacks against cryptographic hash functions in Internet
guidance, refer to [HASHES]. protocols as they relate to XMPP. For helpful guidance, refer to
[HASHES].
13.9.4. Use of SASL 13.9.4. Use of SASL
Because the initiating entity chooses an acceptable SASL mechanism Because the initiating entity chooses an acceptable SASL mechanism
from the list presented by the receiving entity, the initiating from the list presented by the receiving entity, the initiating
entity depends on the receiving entity's list for authentication. entity depends on the receiving entity's list for authentication.
This dependency introduces the possibility of a downgrade attack if This dependency introduces the possibility of a downgrade attack if
an attacker can gain control of the channel and therefore present a an attacker can gain control of the channel and therefore present a
weak list of mechanisms. To mitigate this attack, the parties SHOULD weak list of mechanisms. To mitigate this attack, the parties SHOULD
protect the channel using TLS before attempting SASL negotiation and protect the channel using TLS before attempting SASL negotiation and
skipping to change at page 160, line 16 skipping to change at page 165, line 9
provide a channel binding, then the mechanism cannot provide a way to provide a channel binding, then the mechanism cannot provide a way to
verify that the source and destination end points to which the lower verify that the source and destination end points to which the lower
layer's security is bound are equivalent to the end points that SASL layer's security is bound are equivalent to the end points that SASL
is authenticating; furthermore, if the end points are not identical, is authenticating; furthermore, if the end points are not identical,
then the lower layer's security cannot be trusted to protect data then the lower layer's security cannot be trusted to protect data
transmitted between the SASL-authenticated entities. In such a transmitted between the SASL-authenticated entities. In such a
situation, a SASL security layer SHOULD be negotiated that situation, a SASL security layer SHOULD be negotiated that
effectively ignores the presence of the lower-layer security. effectively ignores the presence of the lower-layer security.
Many deployed XMPP services authenticate client connections by means Many deployed XMPP services authenticate client connections by means
of passwords. It is well-known that most human users choose of passwords. It is well known that most human users choose
relatively weak passwords. Although service provisioning is out of relatively weak passwords. Although service provisioning is out of
scope for this document, XMPP servers that allow password-based scope for this document, XMPP servers that allow password-based
authentication SHOULD enforce minimal criteria for password strength authentication SHOULD enforce minimal criteria for password strength
to help prevent dictionary attacks. Because all password-based to help prevent dictionary attacks. Because all password-based
authentication mechanisms are susceptible to password guessing authentication mechanisms are susceptible to password guessing
attacks, XMPP servers MUST implement common rate-limiting attacks, XMPP servers MUST limit the number of retries allowed during
mitigations. SASL authentication, as described under Section 6.4.5.
Some SASL mechanisms (e.g., [ANONYMOUS]) do not provide strong peer Some SASL mechanisms (e.g., [ANONYMOUS]) do not provide strong peer
entity authentication of the client to the server. Service entity authentication of the client to the server. Service
administrators are advised to enable such mechanisms with caution. administrators are advised to enable such mechanisms with caution.
Best practices for the use of the SASL ANONYMOUS mechanism in XMPP Best practices for the use of the SASL ANONYMOUS mechanism in XMPP
are described in [XEP-0175]. are described in [XEP-0175].
13.9.5. Use of TLS 13.9.5. Use of TLS
Implementations of TLS typically support multiple versions of the Implementations of TLS typically support multiple versions of the
Transport Layer Security protocol as well as the older Secure Sockets Transport Layer Security protocol as well as the older Secure Sockets
Layer (SSL) protocol. Because of known security vulnerabilities, Layer (SSL) protocol. Because of known security vulnerabilities,
XMPP servers and clients MUST NOT request, offer, or use SSL 2.0. XMPP servers and clients MUST NOT request, offer, or use SSL 2.0.
See Appendix E.2 of [TLS] for further details. For further details, see Appendix E.2 of [TLS] along with [TLS-SSL2].
To prevent man-in-the-middle attacks, the TLS client (which might be To prevent man-in-the-middle attacks, the TLS client (which might be
an XMPP client or an XMPP server) MUST verify the certificate of the an XMPP client or an XMPP server) MUST verify the certificate of the
TLS server and MUST check its understanding of the server hostname TLS server and MUST check its understanding of the server FQDN
against the server's identity as presented in the TLS Certificate against the server's identity as presented in the TLS Certificate
message as described under Section 13.7.2.1 (for further details, see message as described under Section 13.7.2.1 (for further details, see
[TLS-CERTS]. [TLS-CERTS].
Support for TLS renegotiation is strictly OPTIONAL. However,
implementations that support TLS renegotiation MUST implement and use
the TLS Renegotiation Extension [TLS-NEG]. Further details are
provided under Section 5.3.5.
13.9.6. Use of UTF-8 13.9.6. Use of UTF-8
The use of UTF-8 makes it possible to transport non-ASCII characters, The use of UTF-8 makes it possible to transport non-ASCII characters,
and thus enables character "spoofing" scenarios, in which a displayed and thus enables character "spoofing" scenarios, in which a displayed
value appears to be something other than it is. Furthermore, there value appears to be something other than it is. Furthermore, there
are known attack scenarios related to the decoding of UTF-8 data. On are known attack scenarios related to the decoding of UTF-8 data. On
both of these points, refer to [UTF-8] for more information. both of these points, refer to [UTF-8] for more information.
13.9.7. Use of XML 13.9.7. Use of XML
skipping to change at page 161, line 21 skipping to change at page 166, line 20
XMPP mitigate the risks described there, such as the prohibitions XMPP mitigate the risks described there, such as the prohibitions
specified under Section 11.1 and the lack of external references to specified under Section 11.1 and the lack of external references to
style sheets or transformations, but these mitigating factors are by style sheets or transformations, but these mitigating factors are by
no means comprehensive. no means comprehensive.
13.10. Information Leaks 13.10. Information Leaks
13.10.1. IP Addresses 13.10.1. IP Addresses
A client's IP address and method of access MUST NOT be made public by A client's IP address and method of access MUST NOT be made public by
a server. a server (e.g., as typically occurs in [IRC]).
13.10.2. Presence Information 13.10.2. Presence Information
One of the core aspects of XMPP is presence: information about the One of the core aspects of XMPP is presence: information about the
network availability of an XMPP entity (i.e., whether the entity is network availability of an XMPP entity (i.e., whether the entity is
currently online or offline). A "presence leak" occurs when an currently online or offline). A "presence leak" occurs when an
entity's network availability is inadvertently and involuntarily entity's network availability is inadvertently and involuntarily
revealed to a second entity that is not authorized to know the first revealed to a second entity that is not authorized to know the first
entity's network availability. entity's network availability.
Although presence is discussed more fully in [XMPP-IM], it is Although presence is discussed more fully in [XMPP-IM], it is
important to note that an XMPP server MUST NOT leak presence. In important to note that an XMPP server MUST NOT leak presence. In
particular at the core XMPP level, real-time addressing and network particular at the core XMPP level, real-time addressing and network
availability is associated with a specific connected resource; availability is associated with a specific connected resource;
therefore, any disclosure of a connected resource's full JID therefore, any disclosure of a connected resource's full JID
comprises a presence leak. To help prevent such a presence leak, a comprises a presence leak. To help prevent such a presence leak, a
server MUST NOT return different stanza errors if a potential server MUST NOT return different stanza errors depending on whether a
attacker sends XML stanzas to the entity's bare JID potential attacker sends XML stanzas to the entity's bare JID
(<localpart@domainpart>) or full JID (<localpart@domainpart>) or full JID
(<localpart@domainpart/resourcepart>). (<localpart@domainpart/resourcepart>).
13.11. Directory Harvesting 13.11. Directory Harvesting
If a server generates an error stanza in response to receiving a If a server generates an error stanza in response to receiving a
stanza for a user account that does not exist, using the <service- stanza for a user account that does not exist, using the <service-
unavailable/> stanza error condition can help protect against unavailable/> stanza error condition can help protect against
directory harvesting attacks, since this is the same error condition directory harvesting attacks, since this is the same error condition
that is returned if, for instance, the namespace of an IQ child that is returned if, for instance, the namespace of an IQ child
skipping to change at page 162, line 35 skipping to change at page 167, line 32
variant on these. variant on these.
Some considerations discussed in this document help to prevent denial Some considerations discussed in this document help to prevent denial
of service attacks (e.g., the mandate that a server MUST NOT process of service attacks (e.g., the mandate that a server MUST NOT process
XML stanzas from clients that have not yet provided appropriate XML stanzas from clients that have not yet provided appropriate
authentication credentials and MUST NOT process XML stanzas from peer authentication credentials and MUST NOT process XML stanzas from peer
servers whose identity it has not either authenticated via SASL or servers whose identity it has not either authenticated via SASL or
weakly verified via Server Dialback). weakly verified via Server Dialback).
In addition, [XEP-0205] provides a detailed discussion of potential In addition, [XEP-0205] provides a detailed discussion of potential
denial of service attacks against XMPP systems and best practices for denial of service attacks against XMPP systems along with best
preventing such attacks. The recommendations include: practices for preventing such attacks. The recommendations include:
1. A server implementation SHOULD enable a server administrator to 1. A server implementation SHOULD enable a server administrator to
limit the number of TCP connections that it will accept from a limit the number of TCP connections that it will accept from a
given IP address at any one time. If an entity attempts to given IP address at any one time. If an entity attempts to
connect but the maximum number of TCP connections has been connect but the maximum number of TCP connections has been
reached, the receiving server MUST NOT allow the new connection reached, the receiving server MUST NOT allow the new connection
to proceed. to proceed.
2. A server implementation SHOULD enable a server administrator to 2. A server implementation SHOULD enable a server administrator to
limit the number of TCP connection attempts that it will accept limit the number of TCP connection attempts that it will accept
skipping to change at page 163, line 16 skipping to change at page 168, line 12
limit the number of connected resources it will allow an account limit the number of connected resources it will allow an account
to bind at any one time. If a client attempts to bind a resource to bind at any one time. If a client attempts to bind a resource
but it has already reached the configured number of allowable but it has already reached the configured number of allowable
resources, the receiving server MUST return a <resource- resources, the receiving server MUST return a <resource-
constraint/> stanza error. constraint/> stanza error.
4. A server implementation SHOULD enable a server administrator to 4. A server implementation SHOULD enable a server administrator to
limit the size of stanzas it will accept from a connected client limit the size of stanzas it will accept from a connected client
or peer server (where "size" is inclusive of all XML markup as or peer server (where "size" is inclusive of all XML markup as
defined in Section 2.4 of [XML], from the opening "<" character defined in Section 2.4 of [XML], from the opening "<" character
of the stanza to the closing ">" character). An entity's maximum of the stanza to the closing ">" character). A deployed server's
stanza size MUST NOT be smaller than 10000 bytes. If a connected maximum stanza size MUST NOT be smaller than 10000 bytes, which
resource or peer server sends a stanza that violates the upper reflects a reasonable compromise between the benefits of
limit, the receiving server MUST either return a <policy- expressiveness for originating entities and the costs of stanza
violation/> stanza error (thus allowing the sender to recover) or processing for servers. A server implementation SHOULD NOT
close the stream with a <policy-violation/> stream error. blindly set 10000 bytes as the default for all deployments but
instead SHOULD enable server administrators to set their own
limits. If a connected resource or peer server sends a stanza
that violates the upper limit, the receiving server MUST either
return a <policy-violation/> stanza error (thus allowing the
sender to recover) or close the stream with a <policy-violation/>
stream error.
5. A server implementation SHOULD enable a server administrator to 5. A server implementation SHOULD enable a server administrator to
limit the number of XML stanzas that a connected client is limit the number of XML stanzas that a connected client is
allowed to send to distinct recipients within a given time allowed to send to distinct recipients within a given time
period. If a connected client sends too many stanzas to distinct period. If a connected client sends too many stanzas to distinct
recipients in a given time period, the receiving server SHOULD recipients in a given time period, the receiving server SHOULD
NOT process the stanza and instead SHOULD return a <policy- NOT process the stanza and instead SHOULD return a <policy-
violation/> stanza error. violation/> stanza error.
6. A server implementation SHOULD enable a server administrator to 6. A server implementation SHOULD enable a server administrator to
skipping to change at page 165, line 12 skipping to change at page 170, line 18
[RFC3920]. This section is to be interpreted according to [RFC3920]. This section is to be interpreted according to
[IANA-GUIDE]. [IANA-GUIDE].
14.1. XML Namespace Name for TLS Data 14.1. XML Namespace Name for TLS Data
A URN sub-namespace for STARTTLS negotiation data in the Extensible A URN sub-namespace for STARTTLS negotiation data in the Extensible
Messaging and Presence Protocol (XMPP) is defined as follows. (This Messaging and Presence Protocol (XMPP) is defined as follows. (This
namespace name adheres to the format defined in [XML-REG].) namespace name adheres to the format defined in [XML-REG].)
URI: urn:ietf:params:xml:ns:xmpp-tls URI: urn:ietf:params:xml:ns:xmpp-tls
Specification: XXXX Specification: RFC XXXX
Description: This is the XML namespace name for STARTTLS negotiation Description: This is the XML namespace name for STARTTLS negotiation
data in the Extensible Messaging and Presence Protocol (XMPP) as data in the Extensible Messaging and Presence Protocol (XMPP) as
defined by XXXX. defined by RFC XXXX.
Registrant Contact: IETF, XMPP Working Group, <xmpp@ietf.org> Registrant Contact: IESG <xmpp@ietf.org>
14.2. XML Namespace Name for SASL Data 14.2. XML Namespace Name for SASL Data
A URN sub-namespace for SASL negotiation data in the Extensible A URN sub-namespace for SASL negotiation data in the Extensible
Messaging and Presence Protocol (XMPP) is defined as follows. (This Messaging and Presence Protocol (XMPP) is defined as follows. (This
namespace name adheres to the format defined in [XML-REG].) namespace name adheres to the format defined in [XML-REG].)
URI: urn:ietf:params:xml:ns:xmpp-sasl URI: urn:ietf:params:xml:ns:xmpp-sasl
Specification: XXXX Specification: RFC XXXX
Description: This is the XML namespace name for SASL negotiation Description: This is the XML namespace name for SASL negotiation
data in the Extensible Messaging and Presence Protocol (XMPP) as data in the Extensible Messaging and Presence Protocol (XMPP) as
defined by XXXX. defined by RFC XXXX.
Registrant Contact: IETF, XMPP Working Group, <xmpp@ietf.org> Registrant Contact: IESG <xmpp@ietf.org>
14.3. XML Namespace Name for Stream Errors 14.3. XML Namespace Name for Stream Errors
A URN sub-namespace for stream error data in the Extensible Messaging A URN sub-namespace for stream error data in the Extensible Messaging
and Presence Protocol (XMPP) is defined as follows. (This namespace and Presence Protocol (XMPP) is defined as follows. (This namespace
name adheres to the format defined in [XML-REG].) name adheres to the format defined in [XML-REG].)
URI: urn:ietf:params:xml:ns:xmpp-streams URI: urn:ietf:params:xml:ns:xmpp-streams
Specification: XXXX Specification: RFC XXXX
Description: This is the XML namespace name for stream error data in Description: This is the XML namespace name for stream error data in
the Extensible Messaging and Presence Protocol (XMPP) as defined the Extensible Messaging and Presence Protocol (XMPP) as defined
by XXXX. by RFC XXXX.
Registrant Contact: IETF, XMPP Working Group, <xmpp@ietf.org> Registrant Contact: IESG <xmpp@ietf.org>
14.4. XML Namespace Name for Resource Binding 14.4. XML Namespace Name for Resource Binding
A URN sub-namespace for resource binding in the Extensible Messaging A URN sub-namespace for resource binding in the Extensible Messaging
and Presence Protocol (XMPP) is defined as follows. (This namespace and Presence Protocol (XMPP) is defined as follows. (This namespace
name adheres to the format defined in [XML-REG].) name adheres to the format defined in [XML-REG].)
URI: urn:ietf:params:xml:ns:xmpp-bind URI: urn:ietf:params:xml:ns:xmpp-bind
Specification: XXXX Specification: RFC XXXX
Description: This is the XML namespace name for resource binding in Description: This is the XML namespace name for resource binding in
the Extensible Messaging and Presence Protocol (XMPP) as defined the Extensible Messaging and Presence Protocol (XMPP) as defined
by XXXX. by RFC XXXX.
Registrant Contact: IETF, XMPP Working Group, <xmpp@ietf.org> Registrant Contact: IESG <xmpp@ietf.org>
14.5. XML Namespace Name for Stanza Errors 14.5. XML Namespace Name for Stanza Errors
A URN sub-namespace for stanza error data in the Extensible Messaging A URN sub-namespace for stanza error data in the Extensible Messaging
and Presence Protocol (XMPP) is defined as follows. (This namespace and Presence Protocol (XMPP) is defined as follows. (This namespace
name adheres to the format defined in [XML-REG].) name adheres to the format defined in [XML-REG].)
URI: urn:ietf:params:xml:ns:xmpp-stanzas URI: urn:ietf:params:xml:ns:xmpp-stanzas
Specification: XXXX Specification: RFC XXXX
Description: This is the XML namespace name for stanza error data in Description: This is the XML namespace name for stanza error data in
the Extensible Messaging and Presence Protocol (XMPP) as defined the Extensible Messaging and Presence Protocol (XMPP) as defined
by XXXX. by RFC XXXX.
Registrant Contact: IETF, XMPP Working Group, <xmpp@ietf.org> Registrant Contact: IESG <xmpp@ietf.org>
14.6. GSSAPI Service Name 14.6. GSSAPI Service Name
The IANA has registered "xmpp" as a [GSS-API] service name, as The IANA has registered "xmpp" as a [GSS-API] service name, as
defined under Section 6.6. defined under Section 6.6.
14.7. Port Numbers and Service Names 14.7. Port Numbers and Service Names
The IANA has registered "xmpp-client" and "xmpp-server" as keywords The IANA has registered "xmpp-client" and "xmpp-server" as keywords
for [TCP] ports 5222 and 5269 respectively. In accordance with for [TCP] ports 5222 and 5269 respectively. In accordance with
[IANA-PORTS], this document updates the existing registration, as [IANA-PORTS], this document updates the existing registration, as
follows. follows.
Service Name: xmpp-client Service Name: xmpp-client
Transport Protocol: TCP Transport Protocol: TCP
Description: A service offering support for connections by XMPP Description: A service offering support for connections by XMPP
client applications client applications
Registrant: IETF XMPP Working Group Registrant: IETF XMPP Working Group
Contact: IESG, <iesg@ietf.org> Contact: IESG <iesg@ietf.org>
Reference: XXXX Reference: RFC XXXX
Port Number: 5222 Port Number: 5222
Service Name: xmpp-server Service Name: xmpp-server
Transport Protocol: TCP Transport Protocol: TCP
Description: A service offering support for connections by XMPP Description: A service offering support for connections by XMPP
server applications server applications
Registrant: IETF XMPP Working Group Registrant: IETF XMPP Working Group
Contact: IESG, <iesg@ietf.org> Contact: IESG <iesg@ietf.org>
Reference: XXXX Reference: RFC XXXX
Port Number: 5269 Port Number: 5269
15. Conformance Requirements 15. Conformance Requirements
This section describes a protocol feature set that summarizes the This section describes a protocol feature set that summarizes the
conformance requirements of this specification. This feature set is conformance requirements of this specification. This feature set is
appropriate for use in software certification, interoperability appropriate for use in software certification, interoperability
testing, and implementation reports. For each feature, this section testing, and implementation reports. For each feature, this section
provides the following information: provides the following information:
skipping to change at page 168, line 24 skipping to change at page 173, line 31
stream. stream.
Section: Section 7 Section: Section 7
Roles: Client MUST, Server MUST. Roles: Client MUST, Server MUST.
Feature: sasl-correlate Feature: sasl-correlate
Description: When authenticating a stream peer using SASL, correlate Description: When authenticating a stream peer using SASL, correlate
the authentication identifier resulting from SASL negotiation with the authentication identifier resulting from SASL negotiation with
the 'from' address (if any) of the stream header it received from the 'from' address (if any) of the stream header it received from
the peer. the peer.
Section: Section 6.4.6 Section: Section 6.4.6
Roles: Client N/A, Server SHOULD. Roles: Client SHOULD, Server SHOULD.
Feature: sasl-errors Feature: sasl-errors
Description: Support SASL errors during the negotiation process. Description: Support SASL errors during the negotiation process.
Section: Section 6.5 Section: Section 6.5
Roles: Client MUST, Server MUST. Roles: Client MUST, Server MUST.
Feature: sasl-mtn Feature: sasl-mtn
Description: Consider SASL as mandatory-to-negotiate. Description: Consider SASL as mandatory-to-negotiate.
Section: Section 6.3.1 Section: Section 6.3.1
Roles: Client MUST, Server MUST. Roles: Client MUST, Server MUST.
skipping to change at page 169, line 18 skipping to change at page 174, line 24
the SCRAM-SHA-1 and SCRAM-SHA-1-PLUS variants). the SCRAM-SHA-1 and SCRAM-SHA-1-PLUS variants).
Section: Section 13.8 Section: Section 13.8
Roles: Client MUST, Server MUST. Roles: Client MUST, Server MUST.
Feature: security-mti-both-external Feature: security-mti-both-external
Description: Support TLS with SASL EXTERNAL for confidentiality and Description: Support TLS with SASL EXTERNAL for confidentiality and
authentication. authentication.
Section: Section 13.8 Section: Section 13.8
Roles: Client SHOULD, Server MUST. Roles: Client SHOULD, Server MUST.
Feature: security-mti-both-plain
Description: Support TLS using the TLS_RSA_WITH_AES_128_CBC_SHA
ciphersuite plus the SASL PLAIN mechanism for confidentiality and
authentication.
Section: Section 13.8
Roles: Client SHOULD, Server MAY.
Feature: security-mti-both-scram Feature: security-mti-both-scram
Description: Support TLS using the TLS_RSA_WITH_AES_128_CBC_SHA Description: Support TLS using the TLS_RSA_WITH_AES_128_CBC_SHA
ciphersuite plus the SASL-SHA-1 and SASL-SHA-1-PLUS variants of ciphersuite plus the SCRAM-SHA-1 and SCRAM-SHA-1-PLUS variants of
the SASL SCRAM mechanism for confidentiality and authentication. the SASL SCRAM mechanism for confidentiality and authentication.
Section: Section 13.8 Section: Section 13.8
Roles: Client MUST, Server MUST. Roles: Client MUST, Server MUST.
Feature: security-mti-confidentiality Feature: security-mti-confidentiality
Description: Support TLS using the TLS_RSA_WITH_AES_128_CBC_SHA Description: Support TLS using the TLS_RSA_WITH_AES_128_CBC_SHA
ciphersuite for confidentiality only. ciphersuite for confidentiality only.
Section: Section 13.8 Section: Section 13.8
Roles: Client N/A, Server SHOULD. Roles: Client N/A, Server SHOULD.
skipping to change at page 169, line 45 skipping to change at page 175, line 13
Roles: Client MUST, Server MUST. Roles: Client MUST, Server MUST.
Feature: stanza-attribute-from-stamp Feature: stanza-attribute-from-stamp
Description: Stamp or rewrite the 'from' address of all stanzas Description: Stamp or rewrite the 'from' address of all stanzas
received from connected clients. received from connected clients.
Section: Section 8.1.2.1 Section: Section 8.1.2.1
Roles: Client N/A, Server MUST. Roles: Client N/A, Server MUST.
Feature: stanza-attribute-from-validate Feature: stanza-attribute-from-validate
Description: Validate the 'from' address of all stanzas received Description: Validate the 'from' address of all stanzas received
from a peer servers. from peer servers.
Section: Section 8.1.2.2 Section: Section 8.1.2.2
Roles: Client N/A, Server MUST. Roles: Client N/A, Server MUST.
Feature: stanza-attribute-id Feature: stanza-attribute-id
Description: Support the common 'id' attribute for all stanza kinds. Description: Support the common 'id' attribute for all stanza kinds.
Section: Section 8.1.3 Section: Section 8.1.3
Roles: Client MUST, Server MUST. Roles: Client MUST, Server MUST.
Feature: stanza-attribute-to Feature: stanza-attribute-to
Description: Support the common 'to' attribute for all stanza kinds. Description: Support the common 'to' attribute for all stanza kinds.
skipping to change at page 172, line 23 skipping to change at page 177, line 35
Roles: Client MUST, Server MUST. Roles: Client MUST, Server MUST.
Feature: stanza-kind-presence Feature: stanza-kind-presence
Description: Support the <presence/> stanza. Description: Support the <presence/> stanza.
Section: Section 8.2.2 Section: Section 8.2.2
Roles: Client MUST, Server MUST. Roles: Client MUST, Server MUST.
Feature: stream-attribute-initial-from Feature: stream-attribute-initial-from
Description: Include a 'from' attribute in the initial stream Description: Include a 'from' attribute in the initial stream
header. header.
Section: Section 4.6.1 Section: Section 4.7.1
Roles: Client SHOULD, Server SHOULD. Roles: Client SHOULD, Server MUST.
Feature: stream-attribute-initial-lang Feature: stream-attribute-initial-lang
Description: Include an 'xml:lang' attribute in the initial stream Description: Include an 'xml:lang' attribute in the initial stream
header. header.
Section: Section 4.6.4 Section: Section 4.7.4
Roles: Client SHOULD, Server SHOULD. Roles: Client SHOULD, Server SHOULD.
Feature: stream-attribute-initial-to Feature: stream-attribute-initial-to
Description: Include a 'to' attribute in the initial stream header. Description: Include a 'to' attribute in the initial stream header.
Section: Section 4.6.2 Section: Section 4.7.2
Roles: Client SHOULD, Server SHOULD. Roles: Client MUST, Server MUST.
Feature: stream-attribute-response-from Feature: stream-attribute-response-from
Description: Include a 'from' attribute in the response stream Description: Include a 'from' attribute in the response stream
header. header.
Section: Section 4.6.1 Section: Section 4.7.1
Roles: Client N/A, Server MUST. Roles: Client N/A, Server MUST.
Feature: stream-attribute-response-id Feature: stream-attribute-response-id
Description: Include an 'id' attribute in the response stream Description: Include an 'id' attribute in the response stream
header. header.
Section: Section 4.6.3 Section: Section 4.7.3
Roles: Client N/A, Server MUST. Roles: Client N/A, Server MUST.
Feature: stream-attribute-response-id-unique Feature: stream-attribute-response-id-unique
Description: Ensure that the 'id' attribute in the response stream Description: Ensure that the 'id' attribute in the response stream
header is unique within the context of the receiving entity. header is unique within the context of the receiving entity.
Section: Section 4.6.3 Section: Section 4.7.3
Roles: Client N/A, Server MUST. Roles: Client N/A, Server MUST.
Feature: stream-attribute-response-to Feature: stream-attribute-response-to
Description: Include a 'to' attribute in the response stream header. Description: Include a 'to' attribute in the response stream header.
Section: Section 4.6.2 Section: Section 4.7.2
Roles: Client N/A, Server SHOULD. Roles: Client N/A, Server SHOULD.
Feature: stream-error-generate Feature: stream-error-generate
Description: Generate a stream error (followed by a closing stream Description: Generate a stream error (followed by a closing stream
tag and termination of the TCP connection) upon detecting a tag and termination of the TCP connection) upon detecting a
stream-related error condition. stream-related error condition.
Section: Section 4.8 Section: Section 4.9
Roles: Client MUST, Server MUST. Roles: Client MUST, Server MUST.
Feature: stream-hostname-resolution Feature: stream-fqdn-resolution
Description: Resolve hostnames before opening a TCP connection. Description: Resolve FQDNs before opening a TCP connection to the
receiving entity.
Section: Section 3.2 Section: Section 3.2
Roles: Client MUST, Server MUST. Roles: Client MUST, Server MUST.
Feature: stream-negotiation-complete Feature: stream-negotiation-complete
Description: Do not consider the stream negotiation process to be Description: Do not consider the stream negotiation process to be
complete until the receiving entity sends a stream features complete until the receiving entity sends a stream features
advertisement that is empty or that contains only voluntary-to- advertisement that is empty or that contains only voluntary-to-
negotiate features. negotiate features.
Section: Section 4.2.5 Section: Section 4.3.5
Roles: Client MUST, Server MUST. Roles: Client MUST, Server MUST.
Feature: stream-negotiation-features Feature: stream-negotiation-features
Description: Send stream features after sending a response stream Description: Send stream features after sending a response stream
header. header.
Section: Section 4.2.2 Section: Section 4.3.2
Roles: Client N/A, Server MUST. Roles: Client N/A, Server MUST.
Feature: stream-negotiation-restart Feature: stream-negotiation-restart
Description: Consider the previous stream to be replaced upon Description: Consider the previous stream to be replaced upon
negotiation of a stream feature that necessitates a stream negotiation of a stream feature that necessitates a stream
restart, and send or receive a new initial stream header after restart, and send or receive a new initial stream header after
negotiation of such a stream feature. negotiation of such a stream feature.
Section: Section 4.2.3 Section: Section 4.3.3
Roles: Client MUST, Server MUST. Roles: Client MUST, Server MUST.
Feature: stream-reconnect Feature: stream-reconnect
Description: Reconnect with exponential backoff if a TCP connection Description: Reconnect with exponential backoff if a TCP connection
is terminated unexpectedly. is terminated unexpectedly.
Section: Section 3.3 Section: Section 3.3
Roles: Client MUST, Server MUST. Roles: Client MUST, Server MUST.
Feature: stream-tcp-binding Feature: stream-tcp-binding
Description: Bind an XML stream to a TCP connection. Description: Bind an XML stream to a TCP connection.
skipping to change at page 174, line 24 skipping to change at page 179, line 38
Roles: Client MUST, Server MUST. Roles: Client MUST, Server MUST.
Feature: tls-certs Feature: tls-certs
Description: Check the identity specified in a certificate that is Description: Check the identity specified in a certificate that is
presented during TLS negotiation. presented during TLS negotiation.
Section: Section 13.7.2 Section: Section 13.7.2
Roles: Client MUST, Server MUST. Roles: Client MUST, Server MUST.
Feature: tls-mtn Feature: tls-mtn
Description: Consider TLS as mandatory-to-negotiate if STARTTLS is Description: Consider TLS as mandatory-to-negotiate if STARTTLS is
the only feature advertised or if the STARTTLS feature includes an the only feature advertised or if the STARTTLS feature
empty <required/> element. advertisement includes an empty <required/> element.
Section: Section 5.3.1 Section: Section 5.3.1
Roles: Client MUST, Server MUST. Roles: Client MUST, Server MUST.
Feature: tls-restart Feature: tls-restart
Description: Initiate or handle a stream restart after TLS Description: Initiate or handle a stream restart after TLS
negotiation. negotiation.
Section: Section 5.3.2 Section: Section 5.3.2
Roles: Client MUST, Server MUST. Roles: Client MUST, Server MUST.
Feature: tls-support Feature: tls-support
skipping to change at page 175, line 5 skipping to change at page 180, line 20
Feature: tls-correlate Feature: tls-correlate
Description: When validating a certificate presented by a stream Description: When validating a certificate presented by a stream
peer during TLS negotiation, correlate the validated identity with peer during TLS negotiation, correlate the validated identity with
the 'from' address (if any) of the stream header it received from the 'from' address (if any) of the stream header it received from
the peer. the peer.
Section: Section 13.7.2 Section: Section 13.7.2
Roles: Client SHOULD, Server SHOULD. Roles: Client SHOULD, Server SHOULD.
Feature: xml-namespace-content-client Feature: xml-namespace-content-client
Description: Support 'jabber:client' as a content namespace. Description: Support 'jabber:client' as a content namespace.
Section: Section 4.7.2 Section: Section 4.8.2
Roles: Client MUST, Server MUST. Roles: Client MUST, Server MUST.
Feature: xml-namespace-content-server Feature: xml-namespace-content-server
Description: Support 'jabber:server' as a content namespace. Description: Support 'jabber:server' as a content namespace.
Section: Section 4.7.2 Section: Section 4.8.2
Roles: Client N/A, Server MUST. Roles: Client N/A, Server MUST.
Feature: xml-namespace-streams-declaration Feature: xml-namespace-streams-declaration
Description: Ensure that there is a namespace declaration for the Description: Ensure that there is a namespace declaration for the
'http://etherx.jabber.org/streams' namespace. 'http://etherx.jabber.org/streams' namespace.
Section: Section 4.7.1 Section: Section 4.8.1
Roles: Client MUST, Server MUST. Roles: Client MUST, Server MUST.
Feature: xml-namespace-streams-prefix Feature: xml-namespace-streams-prefix
Description: Ensure that all elements qualified by the Description: Ensure that all elements qualified by the
'http://etherx.jabber.org/streams' namespace are prefixed by the 'http://etherx.jabber.org/streams' namespace are prefixed by the
prefix defined in the namespace declaration. prefix (if any) defined in the namespace declaration.
Section: Section 4.7.1 Section: Section 4.8.1
Roles: Client MUST, Server MUST. Roles: Client MUST, Server MUST.
Feature: xml-restriction-comment Feature: xml-restriction-comment
Description: Do not generate or accept XML comments. Description: Do not generate or accept XML comments.
Section: Section 11.1 Section: Section 11.1
Roles: Client MUST, Server MUST. Roles: Client MUST, Server MUST.
Feature: xml-restriction-dtd Feature: xml-restriction-dtd
Description: Do not generate or accept internal or external DTD Description: Do not generate or accept internal or external DTD
subsets. subsets.
skipping to change at page 176, line 24 skipping to change at page 181, line 38
Section: Section 11.3 Section: Section 11.3
Roles: Client MUST, Server MUST. Roles: Client MUST, Server MUST.
16. References 16. References
16.1. Normative References 16.1. Normative References
[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data
Encodings", RFC 4648, October 2006. Encodings", RFC 4648, October 2006.
[CHANNEL] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007.
[CHANNEL-TLS]
Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, July 2010.
[CHARSETS] [CHARSETS]
Alvestrand, H., "IETF Policy on Character Sets and Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998. Languages", BCP 18, RFC 2277, January 1998.
[DNS-CONCEPTS]
Mockapetris, P., "Domain names - concepts and facilities",
STD 13, RFC 1034, November 1987.
[DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [DNS-SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[IPv6-ADDR]
Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010.
[KEYWORDS] [KEYWORDS]
Bradner, S., "Key words for use in RFCs to Indicate Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[LANGMATCH]
Phillips, A. and M. Davis, "Matching of Language Tags",
BCP 47, RFC 4647, September 2006.
[LANGTAGS] [LANGTAGS]
Phillips, A. and M. Davis, "Tags for Identifying Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009. Languages", BCP 47, RFC 5646, September 2009.
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999. Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
skipping to change at page 177, line 24 skipping to change at page 183, line 9
[RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006. Security Layer (SASL)", RFC 4422, June 2006.
[SCRAM] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, [SCRAM] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
"Salted Challenge Response Authentication Mechanism "Salted Challenge Response Authentication Mechanism
(SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010. (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010.
[SEC-TERMS]
Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007.
[STRONGSEC]
Schiller, J., "Strong Security Requirements for Internet
Engineering Task Force Standard Protocols", BCP 61,
RFC 3365, August 2002.
[TCP] Postel, J., "Transmission Control Protocol", STD 7, [TCP] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS-CERTS] [TLS-CERTS]
Saint-Andre, P. and J. Hodges, "Representation and Saint-Andre, P. and J. Hodges, "Representation and
Verification of Domain-Based Application Service Identity Verification of Domain-Based Application Service Identity
within Internet Public Key Infrastructure Using X.509 within Internet Public Key Infrastructure Using X.509
(PKIX) Certificates in the Context of Transport Layer (PKIX) Certificates in the Context of Transport Layer
Security (TLS)", draft-saintandre-tls-server-id-check-11 Security (TLS)", draft-saintandre-tls-server-id-check-11
(work in progress), November 2010. (work in progress), November 2010.
[TLS-NEG] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
"Transport Layer Security (TLS) Renegotiation Indication
Extension", RFC 5746, February 2010.
[TLS-SSL2]
Polk, T. and S. Turner, "Prohibiting SSL Version 2.0",
draft-ietf-tls-ssl2-must-not-03 (work in progress),
November 2010.
[UCS2] International Organization for Standardization, [UCS2] International Organization for Standardization,
"Information Technology - Universal Multiple-octet coded "Information Technology - Universal Multiple-octet coded
Character Set (UCS) - Amendment 2: UCS Transformation Character Set (UCS) - Amendment 2: UCS Transformation
Format 8 (UTF-8)", ISO Standard 10646-1 Addendum 2, Format 8 (UTF-8)", ISO Standard 10646-1 Addendum 2,
October 1996. October 1996.
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version [UNICODE] The Unicode Consortium, "The Unicode Standard, Version
3.2.0", 2000. 6.0", 2010,
<http://www.unicode.org/versions/Unicode6.0.0/>.
The Unicode Standard, Version 3.2.0 is defined by The
Unicode Standard, Version 3.0 (Reading, MA, Addison-
Wesley, 2000. ISBN 0-201-61633-5), as amended by the
Unicode Standard Annex #27: Unicode 3.1
(http://www.unicode.org/reports/tr27/) and by the Unicode
Standard Annex #28: Unicode 3.2
(http://www.unicode.org/reports/tr28/).
[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO [UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[X509] International Telecommunications Union, "Information [X509] International Telecommunications Union, "Information
technology - Open Systems Interconnection - The Directory: technology - Open Systems Interconnection - The Directory:
skipping to change at page 178, line 47 skipping to change at page 184, line 42
Web Consortium Recommendation REC-xml-names-20091208, Web Consortium Recommendation REC-xml-names-20091208,
December 2009, December 2009,
<http://www.w3.org/TR/2009/REC-xml-names-20091208>. <http://www.w3.org/TR/2009/REC-xml-names-20091208>.
[XMPP-ADDR] [XMPP-ADDR]
Saint-Andre, P., "Extensible Messaging and Presence Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Address Format", Protocol (XMPP): Address Format",
draft-ietf-xmpp-address-07 (work in progress), draft-ietf-xmpp-address-07 (work in progress),
November 2010. November 2010.
[XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence",
draft-ietf-xmpp-3921bis-17 (work in progress),
November 2010.
16.2. Informative References 16.2. Informative References
[AAA] Housley, R. and B. Aboba, "Guidance for Authentication, [AAA] Housley, R. and B. Aboba, "Guidance for Authentication,
Authorization, and Accounting (AAA) Key Management", Authorization, and Accounting (AAA) Key Management",
BCP 132, RFC 4962, July 2007. BCP 132, RFC 4962, July 2007.
[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, January 2008. Specifications: ABNF", STD 68, RFC 5234, January 2008.
[ACAP] Newman, C. and J. Myers, "ACAP -- Application [ACAP] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997. Configuration Access Protocol", RFC 2244, November 1997.
[ANONYMOUS] [ANONYMOUS]
Zeilenga, K., "Anonymous Simple Authentication and Zeilenga, K., "Anonymous Simple Authentication and
Security Layer (SASL) Mechanism", RFC 4505, June 2006. Security Layer (SASL) Mechanism", RFC 4505, June 2006.
[ASN.1] CCITT, "Recommendation X.208: Specification of Abstract [ASN.1] CCITT, "Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1)", 1988. Syntax Notation One (ASN.1)", 1988.
[CHANNEL] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007.
[CHANNEL-TLS]
Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", RFC 5929, July 2010.
[DIGEST-MD5] [DIGEST-MD5]
Leach, P. and C. Newman, "Using Digest Authentication as a Leach, P. and C. Newman, "Using Digest Authentication as a
SASL Mechanism", RFC 2831, May 2000. SASL Mechanism", RFC 2831, May 2000.
[DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[DNS-TXT] Rosenbaum, R., "Using the Domain Name System To Store [DNS-TXT] Rosenbaum, R., "Using the Domain Name System To Store
Arbitrary String Attributes", RFC 1464, May 1993. Arbitrary String Attributes", RFC 1464, May 1993.
skipping to change at page 180, line 43 skipping to change at page 186, line 37
[IMP-REQS] [IMP-REQS]
Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging
/ Presence Protocol Requirements", RFC 2779, / Presence Protocol Requirements", RFC 2779,
February 2000. February 2000.
[INTEROP] Masinter, L., "Formalizing IETF Interoperability [INTEROP] Masinter, L., "Formalizing IETF Interoperability
Reporting", draft-ietf-newtrk-interop-reports-00 (work in Reporting", draft-ietf-newtrk-interop-reports-00 (work in
progress), October 2005. progress), October 2005.
[IRC] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810,
April 2000.
[IRI] Duerst, M. and M. Suignard, "Internationalized Resource [IRI] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005. Identifiers (IRIs)", RFC 3987, January 2005.
[LDAP] Zeilenga, K., "Lightweight Directory Access Protocol [LDAP] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Technical Specification Road Map", RFC 4510, (LDAP): Technical Specification Road Map", RFC 4510,
June 2006. June 2006.
[LINKLOCAL] [LINKLOCAL]
Cheshire, S., Aboba, B., and E. Guttman, "Dynamic Cheshire, S., Aboba, B., and E. Guttman, "Dynamic
Configuration of IPv4 Link-Local Addresses", RFC 3927, Configuration of IPv4 Link-Local Addresses", RFC 3927,
skipping to change at page 181, line 43 skipping to change at page 187, line 39
and Passwords", RFC 4013, February 2005. and Passwords", RFC 4013, February 2005.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
October 2008. October 2008.
[SEC-GUIDE] [SEC-GUIDE]
Rescorla, E. and B. Korver, "Guidelines for Writing RFC Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
July 2003. July 2003.
[SEC-TERMS]
Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007.
[STRONGSEC]
Schiller, J., "Strong Security Requirements for Internet
Engineering Task Force Standard Protocols", BCP 61,
RFC 3365, August 2002.
[TLS-EXT] 3rd, D., "Transport Layer Security (TLS) Extensions: [TLS-EXT] 3rd, D., "Transport Layer Security (TLS) Extensions:
Extension Definitions", draft-ietf-tls-rfc4366-bis-12 Extension Definitions", draft-ietf-tls-rfc4366-bis-12
(work in progress), September 2010. (work in progress), September 2010.
[TLS-NEG] Rescorla, E., Ray, M., Dispensa, S., and N. Oskov,
"Transport Layer Security (TLS) Renegotiation Indication
Extension", RFC 5746, February 2010.
[TLS-RESUME] [TLS-RESUME]
Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig, Salowey, J., Zhou, H., Eronen, P., and H. Tschofenig,
"Transport Layer Security (TLS) Session Resumption without "Transport Layer Security (TLS) Session Resumption without
Server-Side State", RFC 5077, January 2008. Server-Side State", RFC 5077, January 2008.
[URN-OID] Mealling, M., "A URN Namespace of Object Identifiers", [URN-OID] Mealling, M., "A URN Namespace of Object Identifiers",
RFC 3061, February 2001. RFC 3061, February 2001.
[USINGTLS] [USINGTLS]
Newman, C., "Using TLS with IMAP, POP3 and ACAP", Newman, C., "Using TLS with IMAP, POP3 and ACAP",
skipping to change at page 183, line 11 skipping to change at page 188, line 42
January 2006. January 2006.
[XEP-0086] [XEP-0086]
Norris, R. and P. Saint-Andre, "Error Condition Mappings", Norris, R. and P. Saint-Andre, "Error Condition Mappings",
XSF XEP 0086, February 2004. XSF XEP 0086, February 2004.
[XEP-0100] [XEP-0100]
Saint-Andre, P. and D. Smith, "Gateway Interaction", XSF Saint-Andre, P. and D. Smith, "Gateway Interaction", XSF
XEP 0100, October 2005. XEP 0100, October 2005.
[XEP-0114]
Saint-Andre, P., "Jabber Component Protocol", XSF
XEP 0114, March 2005.
[XEP-0124] [XEP-0124]
Paterson, I., Smith, D., and P. Saint-Andre, Paterson, I., Smith, D., and P. Saint-Andre,
"Bidirectional-streams Over Synchronous HTTP (BOSH)", XSF "Bidirectional-streams Over Synchronous HTTP (BOSH)", XSF
XEP 0124, April 2009. XEP 0124, April 2009.
[XEP-0138] [XEP-0138]
Hildebrand, J. and P. Saint-Andre, "Stream Compression", Hildebrand, J. and P. Saint-Andre, "Stream Compression",
XSF XEP 0138, May 2009. XSF XEP 0138, May 2009.
[XEP-0156] [XEP-0156]
skipping to change at page 184, line 17 skipping to change at page 190, line 5
Service Attacks", XSF XEP 0205, January 2009. Service Attacks", XSF XEP 0205, January 2009.
[XEP-0206] [XEP-0206]
Paterson, I., "XMPP Over BOSH", XSF XEP 0206, Paterson, I., "XMPP Over BOSH", XSF XEP 0206,
October 2008. October 2008.
[XEP-0220] [XEP-0220]
Miller, J., Saint-Andre, P., and P. Hancke, "Server Miller, J., Saint-Andre, P., and P. Hancke, "Server
Dialback", XSF XEP 0220, March 2010. Dialback", XSF XEP 0220, March 2010.
[XEP-0225]
Saint-Andre, P., "Component Connections", XSF XEP 0225,
October 2008.
[XEP-0233]
Miller, M., Saint-Andre, P., and J. Hildebrand, "Domain-
Based Service Names in XMPP SASL Negotiation", XSF
XEP 0233, June 2010.
[XEP-0288] [XEP-0288]
Hancke, P. and D. Cridland, "Bidirectional Server-to- Hancke, P. and D. Cridland, "Bidirectional Server-to-
Server Connections", XSF XEP 0288, October 2010. Server Connections", XSF XEP 0288, October 2010.
[XML-FRAG] [XML-FRAG]
Grosso, P. and D. Veillard, "XML Fragment Interchange", Grosso, P. and D. Veillard, "XML Fragment Interchange",
World Wide Web Consortium CR CR-xml-fragment-20010212, World Wide Web Consortium CR CR-xml-fragment-20010212,
February 2001, February 2001,
<http://www.w3.org/TR/2001/CR-xml-fragment-20010212>. <http://www.w3.org/TR/2001/CR-xml-fragment-20010212>.
[XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[XML-SCHEMA] [XML-SCHEMA]
Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech, Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech,
"XML Schema Part 1: Structures Second Edition", World Wide "XML Schema Part 1: Structures Second Edition", World Wide
Web Consortium Recommendation REC-xmlschema-1-20041028, Web Consortium Recommendation REC-xmlschema-1-20041028,
October 2004, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence",
draft-ietf-xmpp-3921bis-17 (work in progress),
November 2010.
[XMPP-URI] [XMPP-URI]
Saint-Andre, P., "Internationalized Resource Identifiers Saint-Andre, P., "Internationalized Resource Identifiers
(IRIs) and Uniform Resource Identifiers (URIs) for the (IRIs) and Uniform Resource Identifiers (URIs) for the
Extensible Messaging and Presence Protocol (XMPP)", Extensible Messaging and Presence Protocol (XMPP)",
RFC 5122, February 2008. RFC 5122, February 2008.
Appendix A. XML Schemas Appendix A. XML Schemas
The following schemas formally define various namespaces used in this The following schemas formally define various namespaces used in this
document, in conformance with [XML-SCHEMA]. Because validation of document, in conformance with [XML-SCHEMA]. Because validation of
skipping to change at page 202, line 12 skipping to change at page 207, line 12
<xs:element name='conflict' type='empty'/> <xs:element name='conflict' type='empty'/>
<xs:element name='feature-not-implemented' type='empty'/> <xs:element name='feature-not-implemented' type='empty'/>
<xs:element name='forbidden' type='empty'/> <xs:element name='forbidden' type='empty'/>
<xs:element name='gone' type='xs:string'/> <xs:element name='gone' type='xs:string'/>
<xs:element name='internal-server-error' type='empty'/> <xs:element name='internal-server-error' type='empty'/>
<xs:element name='item-not-found' type='empty'/> <xs:element name='item-not-found' type='empty'/>
<xs:element name='jid-malformed' type='empty'/> <xs:element name='jid-malformed' type='empty'/>
<xs:element name='not-acceptable' type='empty'/> <xs:element name='not-acceptable' type='empty'/>
<xs:element name='not-allowed' type='empty'/> <xs:element name='not-allowed' type='empty'/>
<xs:element name='not-authorized' type='empty'/> <xs:element name='not-authorized' type='empty'/>
<xs:element name='payment-required' type='empty'/>
<xs:element name='policy-violation' type='empty'/> <xs:element name='policy-violation' type='empty'/>
<xs:element name='recipient-unavailable' type='empty'/> <xs:element name='recipient-unavailable' type='empty'/>
<xs:element name='redirect' type='xs:string'/> <xs:element name='redirect' type='xs:string'/>
<xs:element name='registration-required' type='empty'/> <xs:element name='registration-required' type='empty'/>
<xs:element name='remote-server-not-found' type='empty'/> <xs:element name='remote-server-not-found' type='empty'/>
<xs:element name='remote-server-timeout' type='empty'/> <xs:element name='remote-server-timeout' type='empty'/>
<xs:element name='resource-constraint' type='empty'/> <xs:element name='resource-constraint' type='empty'/>
<xs:element name='service-unavailable' type='empty'/> <xs:element name='service-unavailable' type='empty'/>
<xs:element name='subscription-required' type='empty'/> <xs:element name='subscription-required' type='empty'/>
<xs:element name='undefined-condition' type='empty'/> <xs:element name='undefined-condition' type='empty'/>
skipping to change at page 202, line 38 skipping to change at page 207, line 37
<xs:element ref='conflict'/> <xs:element ref='conflict'/>
<xs:element ref='feature-not-implemented'/> <xs:element ref='feature-not-implemented'/>
<xs:element ref='forbidden'/> <xs:element ref='forbidden'/>
<xs:element ref='gone'/> <xs:element ref='gone'/>
<xs:element ref='internal-server-error'/> <xs:element ref='internal-server-error'/>
<xs:element ref='item-not-found'/> <xs:element ref='item-not-found'/>
<xs:element ref='jid-malformed'/> <xs:element ref='jid-malformed'/>
<xs:element ref='not-acceptable'/> <xs:element ref='not-acceptable'/>
<xs:element ref='not-authorized'/> <xs:element ref='not-authorized'/>
<xs:element ref='not-allowed'/> <xs:element ref='not-allowed'/>
<xs:element ref='payment-required'/>
<xs:element ref='policy-violation'/> <xs:element ref='policy-violation'/>
<xs:element ref='recipient-unavailable'/> <xs:element ref='recipient-unavailable'/>
<xs:element ref='redirect'/> <xs:element ref='redirect'/>
<xs:element ref='registration-required'/> <xs:element ref='registration-required'/>
<xs:element ref='remote-server-not-found'/> <xs:element ref='remote-server-not-found'/>
<xs:element ref='remote-server-timeout'/> <xs:element ref='remote-server-timeout'/>
<xs:element ref='resource-constraint'/> <xs:element ref='resource-constraint'/>
<xs:element ref='service-unavailable'/> <xs:element ref='service-unavailable'/>
<xs:element ref='subscription-required'/> <xs:element ref='subscription-required'/>
<xs:element ref='undefined-condition'/> <xs:element ref='undefined-condition'/>
skipping to change at page 203, line 24 skipping to change at page 208, line 23
<xs:simpleType name='empty'> <xs:simpleType name='empty'>
<xs:restriction base='xs:string'> <xs:restriction base='xs:string'>
<xs:enumeration value=''/> <xs:enumeration value=''/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
</xs:schema> </xs:schema>
Appendix B. Contact Addresses Appendix B. Contact Addresses
Consistent with [MAILBOXES], an organization that offers an XMPP Consistent with [MAILBOXES], organization that offer XMPP services
service SHOULD provide an Internet mailbox of "XMPP" for inquiries are encouraged to provide an Internet mailbox of "XMPP" for inquiries
related to that service, where the host portion of the resulting related to that service, where the host portion of the resulting
mailto URI MUST be the organization's domain, not the domain of the mailto URI is the organization's domain, not the domain of the XMPP
XMPP service itself (e.g., the XMPP service might be offered at service itself (e.g., the XMPP service might be offered at
im.example.com but the Internet mailbox would be <xmpp@example.com>). im.example.com but the Internet mailbox would be <xmpp@example.com>).
Appendix C. Account Provisioning Appendix C. Account Provisioning
Account provisioning is out of scope for this specification. Account provisioning is out of scope for this specification.
Possible methods for account provisioning include account creation by Possible methods for account provisioning include account creation by
a server administrator and in-band account registration using the a server administrator and in-band account registration using the
'jabber:iq:register' namespace as documented in [XEP-0077]. An XMPP 'jabber:iq:register' namespace as documented in [XEP-0077]. An XMPP
server implementation or administrative function MUST ensure that any server implementation or administrative function MUST ensure that any
JID assigned during account provisioning (including localpart, JID assigned during account provisioning (including localpart,
skipping to change at page 204, line 18 skipping to change at page 209, line 18
stream headers. stream headers.
o More fully specified the stream closing handshake. o More fully specified the stream closing handshake.
o Specified the recommended stream reconnection algorithm. o Specified the recommended stream reconnection algorithm.
o Changed the name of the <xml-not-well-formed/> stream error o Changed the name of the <xml-not-well-formed/> stream error
condition to <not-well-formed/> for compliance with the XML condition to <not-well-formed/> for compliance with the XML
specification. specification.
o Removed the unnecessary and unused <invalid-id/> stream error (see o Removed the unnecessary and unused <invalid-id/> stream error (see
RFC 3920 for historical documentation). RFC 3920 for historical documentation).
o Specified return of the <restricted-xml/> stream error in response o Specified return of the <restricted-xml/> stream error in response
to receipt of prohibited XML features. to receipt of prohibited XML features.
o More completely specified the format and handling of the <see-
other-host/> stream error, including consistency with RFC 3986 and
RFC 5952 with regard to IPv6 addresses (e.g., enclosing the IPv6
address in square brackets '[' and ']').
o Specified that the SASL SCRAM mechanism is a mandatory-to- o Specified that the SASL SCRAM mechanism is a mandatory-to-
implement technology for client-to-server streams. implement technology for client-to-server streams.
o Specified that TLS plus the SASL PLAIN mechanism is a mandatory- o Specified that TLS plus the SASL PLAIN mechanism is a mandatory-
to-implement technology for client-to-server streams. to-implement technology for client-to-server streams.
o Specified that support for the SASL EXTERNAL mechanism is required o Specified that support for the SASL EXTERNAL mechanism is required
for servers but only recommended for clients (since end-user X.509 for servers but only recommended for clients (since end-user X.509
certificates are difficult to obtain and not yet widely deployed). certificates are difficult to obtain and not yet widely deployed).
o Removed the hard two-connection rule for server-to-server streams. o Removed the hard two-connection rule for server-to-server streams.
o More clearly specified the certificate profile for both public key o More clearly specified the certificate profile for both public key
certificates and issuer certificates. certificates and issuer certificates.
o Added the <reset/> streams error condition to handle expired/ o Added the <reset/> stream error condition to handle expired/
revoked certificates or the addition of security-critical features revoked certificates or the addition of security-critical features
to an existing stream. to an existing stream.
o Added the <account-disabled/>, <credentials-expired/>, o Added the <account-disabled/>, <credentials-expired/>,
<encryption-required/>, and <malformed-request/> SASL error <encryption-required/>, and <malformed-request/> SASL error
conditions to handle error flows mistakenly left out of RFC 3920 conditions to handle error flows mistakenly left out of RFC 3920
or discussed in RFC 4422 but not in RFC 2222. or discussed in RFC 4422 but not in RFC 2222.
o Removed unnecessary requirement for escaping of characters that o Removed the unused <payment-required/> stanza error.
map to certain predefined entities, which do not need to be o Removed the unnecessary requirement for escaping of characters
escaped in XML. that map to certain predefined entities, since they do not need to
be escaped in XML.
o Clarified the process of DNS SRV lookups and fallbacks. o Clarified the process of DNS SRV lookups and fallbacks.
o Clarified the handling of SASL security layers. o Clarified the handling of SASL security layers.
o Clarified that a SASL simple user name is the localpart, not the
bare JID.
o Clarified the stream negotiation process and associated flow o Clarified the stream negotiation process and associated flow
chart. chart.
o Clarified the handling of stream features. o Clarified the handling of stream features.
o Added a 'by' attribute to the <error/> element for stanza errors o Added a 'by' attribute to the <error/> element for stanza errors
so that the entity that has detected the error can include its JID so that the entity that has detected the error can include its JID
for diagnostic or tracking purposes. for diagnostic or tracking purposes.
o Clarified the handling of data that violates the well-formedness o Clarified the handling of data that violates the well-formedness
definitions for XML 1.0 and XML namespaces. definitions for XML 1.0 and XML namespaces.
o Specified the security considerations in more detail, especially o Specified the security considerations in more detail, especially
with regard to presence leaks and denial of service attacks. with regard to presence leaks and denial of service attacks.
o Moved documentation of the Server Dialback protocol from this o Moved documentation of the Server Dialback protocol from this
specification to a separate specification maintained by the XMPP specification to a separate specification maintained by the XMPP
Standards Foundation. Standards Foundation.
Appendix E. 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 and Elwyn
Davies for their reviews on behalf of the Security Directorate and
the General Area Review Team, respectively.
The Working Group chairs were Ben Campbell and Joe Hildebrand. The
responsible Area Director was Gonzalo Camarillo.
Author's Address Author's Address
Peter Saint-Andre Peter Saint-Andre
Cisco Cisco
1899 Wyknoop Street, Suite 600 1899 Wyknoop Street, Suite 600
Denver, CO 80202 Denver, CO 80202
USA USA
Phone: +1-303-308-3282 Phone: +1-303-308-3282
Email: psaintan@cisco.com Email: psaintan@cisco.com
 End of changes. 506 change blocks. 
1564 lines changed or deleted 1841 lines changed or added

This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/