draft-ietf-xmpp-3920bis-17.txt.1   draft-ietf-xmpp-3920bis-18.txt 
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft Cisco Internet-Draft Cisco
Obsoletes: 3920 (if approved) October 6, 2010 Obsoletes: 3920 (if approved) October 20, 2010
Intended status: Standards Track Intended status: Standards Track
Expires: April 9, 2011 Expires: April 23, 2011
Extensible Messaging and Presence Protocol (XMPP): Core Extensible Messaging and Presence Protocol (XMPP): Core
draft-ietf-xmpp-3920bis-17 draft-ietf-xmpp-3920bis-18
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
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 April 9, 2011. This Internet-Draft will expire on April 23, 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 31 skipping to change at page 2, line 31
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 . . . . . . . 14 2.5. Distributed Network of Clients and Servers . . . . . . . 14
3. TCP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 16 3. TCP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 16 3.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.2. Hostname Resolution . . . . . . . . . . . . . . . . . . 16 3.2. Hostname Resolution . . . . . . . . . . . . . . . . . . 16
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 . . . . . . . . . . . . . . . . . . . . . . 18 3.3. Reconnection . . . . . . . . . . . . . . . . . . . . . . 19
3.4. Reliability . . . . . . . . . . . . . . . . . . . . . . 19 3.4. Reliability . . . . . . . . . . . . . . . . . . . . . . 19
4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . . 19 4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. Stream Fundamentals . . . . . . . . . . . . . . . . . . 19 4.1. Stream Fundamentals . . . . . . . . . . . . . . . . . . 19
4.2. Stream Negotiation . . . . . . . . . . . . . . . . . . . 22 4.2. Stream Negotiation . . . . . . . . . . . . . . . . . . . 22
4.2.1. Basic Concepts . . . . . . . . . . . . . . . . . . . 22 4.2.1. Basic Concepts . . . . . . . . . . . . . . . . . . . 22
4.2.2. Stream Features Format . . . . . . . . . . . . . . . 22 4.2.2. Stream Features Format . . . . . . . . . . . . . . . 23
4.2.3. Restarts . . . . . . . . . . . . . . . . . . . . . . 24 4.2.3. Restarts . . . . . . . . . . . . . . . . . . . . . . 25
4.2.4. Resending Features . . . . . . . . . . . . . . . . . 25 4.2.4. Resending Features . . . . . . . . . . . . . . . . . 25
4.2.5. Completion of Stream Negotiation . . . . . . . . . . 25 4.2.5. Completion of Stream Negotiation . . . . . . . . . . 25
4.2.6. Determination of Addresses . . . . . . . . . . . . . 26 4.2.6. Determination of Addresses . . . . . . . . . . . . . 26
4.2.7. Flow Chart . . . . . . . . . . . . . . . . . . . . . 26 4.2.7. Flow Chart . . . . . . . . . . . . . . . . . . . . . 27
4.3. Directionality . . . . . . . . . . . . . . . . . . . . . 28 4.3. Directionality . . . . . . . . . . . . . . . . . . . . . 29
4.4. Closing a Stream . . . . . . . . . . . . . . . . . . . . 29 4.4. Closing a Stream . . . . . . . . . . . . . . . . . . . . 30
4.5. Handling of Silent Peers . . . . . . . . . . . . . . . . 30 4.5. Handling of Silent Peers . . . . . . . . . . . . . . . . 31
4.5.1. Dead Connection . . . . . . . . . . . . . . . . . . 30 4.5.1. Dead Connection . . . . . . . . . . . . . . . . . . 31
4.5.2. Broken Stream . . . . . . . . . . . . . . . . . . . 31 4.5.2. Broken Stream . . . . . . . . . . . . . . . . . . . 32
4.5.3. Idle Peer . . . . . . . . . . . . . . . . . . . . . 31 4.5.3. Idle Peer . . . . . . . . . . . . . . . . . . . . . 32
4.5.4. Use of Checking Methods . . . . . . . . . . . . . . 31 4.5.4. Use of Checking Methods . . . . . . . . . . . . . . 32
4.6. Stream Attributes . . . . . . . . . . . . . . . . . . . 32 4.6. Stream Attributes . . . . . . . . . . . . . . . . . . . 33
4.6.1. from . . . . . . . . . . . . . . . . . . . . . . . . 32 4.6.1. from . . . . . . . . . . . . . . . . . . . . . . . . 33
4.6.2. to . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.6.2. to . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.6.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 35 4.6.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.6.4. xml:lang . . . . . . . . . . . . . . . . . . . . . . 35 4.6.4. xml:lang . . . . . . . . . . . . . . . . . . . . . . 36
4.6.5. version . . . . . . . . . . . . . . . . . . . . . . 37 4.6.5. version . . . . . . . . . . . . . . . . . . . . . . 38
4.6.6. Summary of Stream Attributes . . . . . . . . . . . . 38 4.6.6. Summary of Stream Attributes . . . . . . . . . . . . 39
4.7. Namespaces . . . . . . . . . . . . . . . . . . . . . . . 39 4.7. Namespaces . . . . . . . . . . . . . . . . . . . . . . . 40
4.7.1. Streams Namespace . . . . . . . . . . . . . . . . . 39 4.7.1. Streams Namespace . . . . . . . . . . . . . . . . . 40
4.7.2. Content Namespace . . . . . . . . . . . . . . . . . 39 4.7.2. Content Namespace . . . . . . . . . . . . . . . . . 40
4.7.3. Other Namespaces . . . . . . . . . . . . . . . . . . 40 4.7.3. Other Namespaces . . . . . . . . . . . . . . . . . . 41
4.7.4. Namespace Declarations and Prefixes . . . . . . . . 41 4.7.4. Namespace Declarations and Prefixes . . . . . . . . 42
4.7.5. Mandatory-to-Implement Content Namespaces . . . . . 41 4.7.5. Mandatory-to-Implement Content Namespaces . . . . . 42
4.8. Stream Errors . . . . . . . . . . . . . . . . . . . . . 42 4.8. Stream Errors . . . . . . . . . . . . . . . . . . . . . 43
4.8.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 43 4.8.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 44
4.8.1.1. Stream Errors Are Unrecoverable . . . . . . . . . 43 4.8.1.1. Stream Errors Are Unrecoverable . . . . . . . . . 44
4.8.1.2. Stream Errors Can Occur During Setup . . . . . . 43 4.8.1.2. Stream Errors Can Occur During Setup . . . . . . 44
4.8.1.3. Stream Errors When the Host is Unspecified or 4.8.1.3. Stream Errors When the Host is Unspecified or
Unknown . . . . . . . . . . . . . . . . . . . . . 44 Unknown . . . . . . . . . . . . . . . . . . . . . 45
4.8.1.4. Where Stream Errors Are Sent . . . . . . . . . . 45 4.8.1.4. Where Stream Errors Are Sent . . . . . . . . . . 46
4.8.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 45 4.8.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 46
4.8.3. Defined Stream Error Conditions . . . . . . . . . . 46 4.8.3. Defined Stream Error Conditions . . . . . . . . . . 47
4.8.3.1. bad-format . . . . . . . . . . . . . . . . . . . 46 4.8.3.1. bad-format . . . . . . . . . . . . . . . . . . . 47
4.8.3.2. bad-namespace-prefix . . . . . . . . . . . . . . 47 4.8.3.2. bad-namespace-prefix . . . . . . . . . . . . . . 48
4.8.3.3. conflict . . . . . . . . . . . . . . . . . . . . 48 4.8.3.3. conflict . . . . . . . . . . . . . . . . . . . . 49
4.8.3.4. connection-timeout . . . . . . . . . . . . . . . 48 4.8.3.4. connection-timeout . . . . . . . . . . . . . . . 49
4.8.3.5. host-gone . . . . . . . . . . . . . . . . . . . . 49 4.8.3.5. host-gone . . . . . . . . . . . . . . . . . . . . 50
4.8.3.6. host-unknown . . . . . . . . . . . . . . . . . . 50 4.8.3.6. host-unknown . . . . . . . . . . . . . . . . . . 51
4.8.3.7. improper-addressing . . . . . . . . . . . . . . . 50 4.8.3.7. improper-addressing . . . . . . . . . . . . . . . 51
4.8.3.8. internal-server-error . . . . . . . . . . . . . . 51 4.8.3.8. internal-server-error . . . . . . . . . . . . . . 52
4.8.3.9. invalid-from . . . . . . . . . . . . . . . . . . 51 4.8.3.9. invalid-from . . . . . . . . . . . . . . . . . . 52
4.8.3.10. invalid-namespace . . . . . . . . . . . . . . . . 51 4.8.3.10. invalid-namespace . . . . . . . . . . . . . . . . 52
4.8.3.11. invalid-xml . . . . . . . . . . . . . . . . . . . 52 4.8.3.11. invalid-xml . . . . . . . . . . . . . . . . . . . 53
4.8.3.12. not-authorized . . . . . . . . . . . . . . . . . 53 4.8.3.12. not-authorized . . . . . . . . . . . . . . . . . 54
4.8.3.13. policy-violation . . . . . . . . . . . . . . . . 53 4.8.3.13. policy-violation . . . . . . . . . . . . . . . . 54
4.8.3.14. remote-connection-failed . . . . . . . . . . . . 54 4.8.3.14. remote-connection-failed . . . . . . . . . . . . 55
4.8.3.15. reset . . . . . . . . . . . . . . . . . . . . . . 54 4.8.3.15. reset . . . . . . . . . . . . . . . . . . . . . . 55
4.8.3.16. resource-constraint . . . . . . . . . . . . . . . 55 4.8.3.16. resource-constraint . . . . . . . . . . . . . . . 56
4.8.3.17. restricted-xml . . . . . . . . . . . . . . . . . 55 4.8.3.17. restricted-xml . . . . . . . . . . . . . . . . . 56
4.8.3.18. see-other-host . . . . . . . . . . . . . . . . . 56 4.8.3.18. see-other-host . . . . . . . . . . . . . . . . . 57
4.8.3.19. system-shutdown . . . . . . . . . . . . . . . . . 57 4.8.3.19. system-shutdown . . . . . . . . . . . . . . . . . 58
4.8.3.20. undefined-condition . . . . . . . . . . . . . . . 57 4.8.3.20. undefined-condition . . . . . . . . . . . . . . . 58
4.8.3.21. unsupported-encoding . . . . . . . . . . . . . . 58 4.8.3.21. unsupported-encoding . . . . . . . . . . . . . . 59
4.8.3.22. unsupported-feature . . . . . . . . . . . . . . . 58 4.8.3.22. unsupported-feature . . . . . . . . . . . . . . . 59
4.8.3.23. unsupported-stanza-type . . . . . . . . . . . . . 59 4.8.3.23. unsupported-stanza-type . . . . . . . . . . . . . 60
4.8.3.24. unsupported-version . . . . . . . . . . . . . . . 60 4.8.3.24. unsupported-version . . . . . . . . . . . . . . . 61
4.8.3.25. xml-not-well-formed . . . . . . . . . . . . . . . 61 4.8.3.25. xml-not-well-formed . . . . . . . . . . . . . . . 62
4.8.4. Application-Specific Conditions . . . . . . . . . . 61 4.8.4. Application-Specific Conditions . . . . . . . . . . 62
4.9. Simplified Stream Examples . . . . . . . . . . . . . . . 62 4.9. Simplified Stream Examples . . . . . . . . . . . . . . . 63
5. STARTTLS Negotiation . . . . . . . . . . . . . . . . . . . . 64 5. STARTTLS Negotiation . . . . . . . . . . . . . . . . . . . . 65
5.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 65 5.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 66
5.2. Support . . . . . . . . . . . . . . . . . . . . . . . . 65 5.2. Support . . . . . . . . . . . . . . . . . . . . . . . . 66
5.3. Stream Negotiation Rules . . . . . . . . . . . . . . . . 65 5.3. Stream Negotiation Rules . . . . . . . . . . . . . . . . 66
5.3.1. Mandatory-to-Negotiate . . . . . . . . . . . . . . . 65 5.3.1. Mandatory-to-Negotiate . . . . . . . . . . . . . . . 66
5.3.2. Restart . . . . . . . . . . . . . . . . . . . . . . 65 5.3.2. Restart . . . . . . . . . . . . . . . . . . . . . . 66
5.3.3. Data Formatting . . . . . . . . . . . . . . . . . . 65 5.3.3. Data Formatting . . . . . . . . . . . . . . . . . . 66
5.3.4. Order of TLS and SASL Negotiations . . . . . . . . . 66 5.3.4. Order of TLS and SASL Negotiations . . . . . . . . . 67
5.3.5. TLS Renegotiation . . . . . . . . . . . . . . . . . 66 5.3.5. TLS Renegotiation . . . . . . . . . . . . . . . . . 67
5.3.6. TLS Extensions . . . . . . . . . . . . . . . . . . . 67 5.3.6. TLS Extensions . . . . . . . . . . . . . . . . . . . 68
5.4. Process . . . . . . . . . . . . . . . . . . . . . . . . 67 5.4. Process . . . . . . . . . . . . . . . . . . . . . . . . 68
5.4.1. Exchange of Stream Headers and Stream Features . . . 67 5.4.1. Exchange of Stream Headers and Stream Features . . . 68
5.4.2. Initiation of STARTTLS Negotiation . . . . . . . . . 68 5.4.2. Initiation of STARTTLS Negotiation . . . . . . . . . 69
5.4.2.1. STARTTLS Command . . . . . . . . . . . . . . . . 68 5.4.2.1. STARTTLS Command . . . . . . . . . . . . . . . . 69
5.4.2.2. Failure Case . . . . . . . . . . . . . . . . . . 68 5.4.2.2. Failure Case . . . . . . . . . . . . . . . . . . 69
5.4.2.3. Proceed Case . . . . . . . . . . . . . . . . . . 69 5.4.2.3. Proceed Case . . . . . . . . . . . . . . . . . . 70
5.4.3. TLS Negotiation . . . . . . . . . . . . . . . . . . 69 5.4.3. TLS Negotiation . . . . . . . . . . . . . . . . . . 70
5.4.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . 69 5.4.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . 70
5.4.3.2. TLS Failure . . . . . . . . . . . . . . . . . . . 70 5.4.3.2. TLS Failure . . . . . . . . . . . . . . . . . . . 71
5.4.3.3. TLS Success . . . . . . . . . . . . . . . . . . . 70 5.4.3.3. TLS Success . . . . . . . . . . . . . . . . . . . 71
6. SASL Negotiation . . . . . . . . . . . . . . . . . . . . . . 72 6. SASL Negotiation . . . . . . . . . . . . . . . . . . . . . . 73
6.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 72 6.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 73
6.2. Support . . . . . . . . . . . . . . . . . . . . . . . . 72 6.2. Support . . . . . . . . . . . . . . . . . . . . . . . . 73
6.3. Stream Negotiation Rules . . . . . . . . . . . . . . . . 72 6.3. Stream Negotiation Rules . . . . . . . . . . . . . . . . 73
6.3.1. Mandatory-to-Negotiate . . . . . . . . . . . . . . . 72 6.3.1. Mandatory-to-Negotiate . . . . . . . . . . . . . . . 73
6.3.2. Restart . . . . . . . . . . . . . . . . . . . . . . 72 6.3.2. Restart . . . . . . . . . . . . . . . . . . . . . . 73
6.3.3. Mechanism Preferences . . . . . . . . . . . . . . . 72 6.3.3. Mechanism Preferences . . . . . . . . . . . . . . . 73
6.3.4. Mechanism Offers . . . . . . . . . . . . . . . . . . 73 6.3.4. Mechanism Offers . . . . . . . . . . . . . . . . . . 74
6.3.5. Data Formatting . . . . . . . . . . . . . . . . . . 74 6.3.5. Data Formatting . . . . . . . . . . . . . . . . . . 75
6.3.6. Security Layers . . . . . . . . . . . . . . . . . . 74 6.3.6. Security Layers . . . . . . . . . . . . . . . . . . 75
6.3.7. Simple User Name . . . . . . . . . . . . . . . . . . 74 6.3.7. Simple User Name . . . . . . . . . . . . . . . . . . 75
6.3.8. Authorization Identity . . . . . . . . . . . . . . . 75 6.3.8. Authorization Identity . . . . . . . . . . . . . . . 76
6.3.9. Realms . . . . . . . . . . . . . . . . . . . . . . . 75 6.3.9. Realms . . . . . . . . . . . . . . . . . . . . . . . 76
6.3.10. Round Trips . . . . . . . . . . . . . . . . . . . . 75 6.3.10. Round Trips . . . . . . . . . . . . . . . . . . . . 76
6.4. Process . . . . . . . . . . . . . . . . . . . . . . . . 76 6.4. Process . . . . . . . . . . . . . . . . . . . . . . . . 77
6.4.1. Exchange of Stream Headers and Stream Features . . . 76 6.4.1. Exchange of Stream Headers and Stream Features . . . 77
6.4.2. Initiation . . . . . . . . . . . . . . . . . . . . . 77 6.4.2. Initiation . . . . . . . . . . . . . . . . . . . . . 78
6.4.3. Challenge-Response Sequence . . . . . . . . . . . . 78 6.4.3. Challenge-Response Sequence . . . . . . . . . . . . 79
6.4.4. Abort . . . . . . . . . . . . . . . . . . . . . . . 78 6.4.4. Abort . . . . . . . . . . . . . . . . . . . . . . . 79
6.4.5. SASL Failure . . . . . . . . . . . . . . . . . . . . 79 6.4.5. SASL Failure . . . . . . . . . . . . . . . . . . . . 80
6.4.6. SASL Success . . . . . . . . . . . . . . . . . . . . 80 6.4.6. SASL Success . . . . . . . . . . . . . . . . . . . . 81
6.5. SASL Errors . . . . . . . . . . . . . . . . . . . . . . 81 6.5. SASL Errors . . . . . . . . . . . . . . . . . . . . . . 82
6.5.1. aborted . . . . . . . . . . . . . . . . . . . . . . 81 6.5.1. aborted . . . . . . . . . . . . . . . . . . . . . . 82
6.5.2. account-disabled . . . . . . . . . . . . . . . . . . 81 6.5.2. account-disabled . . . . . . . . . . . . . . . . . . 82
6.5.3. credentials-expired . . . . . . . . . . . . . . . . 82 6.5.3. credentials-expired . . . . . . . . . . . . . . . . 83
6.5.4. encryption-required . . . . . . . . . . . . . . . . 82 6.5.4. encryption-required . . . . . . . . . . . . . . . . 83
6.5.5. incorrect-encoding . . . . . . . . . . . . . . . . . 82 6.5.5. incorrect-encoding . . . . . . . . . . . . . . . . . 83
6.5.6. invalid-authzid . . . . . . . . . . . . . . . . . . 83 6.5.6. invalid-authzid . . . . . . . . . . . . . . . . . . 84
6.5.7. invalid-mechanism . . . . . . . . . . . . . . . . . 83 6.5.7. invalid-mechanism . . . . . . . . . . . . . . . . . 84
6.5.8. malformed-request . . . . . . . . . . . . . . . . . 83 6.5.8. malformed-request . . . . . . . . . . . . . . . . . 84
6.5.9. mechanism-too-weak . . . . . . . . . . . . . . . . . 84 6.5.9. mechanism-too-weak . . . . . . . . . . . . . . . . . 85
6.5.10. not-authorized . . . . . . . . . . . . . . . . . . . 84 6.5.10. not-authorized . . . . . . . . . . . . . . . . . . . 85
6.5.11. temporary-auth-failure . . . . . . . . . . . . . . . 84 6.5.11. temporary-auth-failure . . . . . . . . . . . . . . . 85
6.5.12. transition-needed . . . . . . . . . . . . . . . . . 85 6.5.12. transition-needed . . . . . . . . . . . . . . . . . 86
6.6. SASL Definition . . . . . . . . . . . . . . . . . . . . 85 6.6. SASL Definition . . . . . . . . . . . . . . . . . . . . 86
7. Resource Binding . . . . . . . . . . . . . . . . . . . . . . 86 7. Resource Binding . . . . . . . . . . . . . . . . . . . . . . 87
7.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 86 7.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 87
7.2. Support . . . . . . . . . . . . . . . . . . . . . . . . 87 7.2. Support . . . . . . . . . . . . . . . . . . . . . . . . 88
7.3. Stream Negotiation Rules . . . . . . . . . . . . . . . . 87 7.3. Stream Negotiation Rules . . . . . . . . . . . . . . . . 88
7.3.1. Mandatory-to-Negotiate . . . . . . . . . . . . . . . 87 7.3.1. Mandatory-to-Negotiate . . . . . . . . . . . . . . . 88
7.3.2. Restart . . . . . . . . . . . . . . . . . . . . . . 87 7.3.2. Restart . . . . . . . . . . . . . . . . . . . . . . 88
7.4. Advertising Support . . . . . . . . . . . . . . . . . . 87 7.4. Advertising Support . . . . . . . . . . . . . . . . . . 88
7.5. Generation of Resource Identifiers . . . . . . . . . . . 88 7.5. Generation of Resource Identifiers . . . . . . . . . . . 89
7.6. Server-Generated Resource Identifier . . . . . . . . . . 88 7.6. Server-Generated Resource Identifier . . . . . . . . . . 89
7.6.1. Success Case . . . . . . . . . . . . . . . . . . . . 88 7.6.1. Success Case . . . . . . . . . . . . . . . . . . . . 89
7.6.2. Error Cases . . . . . . . . . . . . . . . . . . . . 89 7.6.2. Error Cases . . . . . . . . . . . . . . . . . . . . 90
7.6.2.1. Resource Constraint . . . . . . . . . . . . . . . 89 7.6.2.1. Resource Constraint . . . . . . . . . . . . . . . 90
7.6.2.2. Not Allowed . . . . . . . . . . . . . . . . . . . 89 7.6.2.2. Not Allowed . . . . . . . . . . . . . . . . . . . 90
7.7. Client-Submitted Resource Identifier . . . . . . . . . . 89 7.7. Client-Submitted Resource Identifier . . . . . . . . . . 90
7.7.1. Success Case . . . . . . . . . . . . . . . . . . . . 89 7.7.1. Success Case . . . . . . . . . . . . . . . . . . . . 90
7.7.2. Error Cases . . . . . . . . . . . . . . . . . . . . 90 7.7.2. Error Cases . . . . . . . . . . . . . . . . . . . . 91
7.7.2.1. Bad Request . . . . . . . . . . . . . . . . . . . 90 7.7.2.1. Bad Request . . . . . . . . . . . . . . . . . . . 91
7.7.2.2. Conflict . . . . . . . . . . . . . . . . . . . . 91 7.7.2.2. Conflict . . . . . . . . . . . . . . . . . . . . 92
7.7.3. Retries . . . . . . . . . . . . . . . . . . . . . . 92 7.7.3. Retries . . . . . . . . . . . . . . . . . . . . . . 93
8. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 93 8. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 94
8.1. Common Attributes . . . . . . . . . . . . . . . . . . . 93 8.1. Common Attributes . . . . . . . . . . . . . . . . . . . 94
8.1.1. to . . . . . . . . . . . . . . . . . . . . . . . . . 93 8.1.1. to . . . . . . . . . . . . . . . . . . . . . . . . . 94
8.1.1.1. Client-to-Server Streams . . . . . . . . . . . . 93 8.1.1.1. Client-to-Server Streams . . . . . . . . . . . . 94
8.1.1.2. Server-to-Server Streams . . . . . . . . . . . . 94 8.1.1.2. Server-to-Server Streams . . . . . . . . . . . . 95
8.1.2. from . . . . . . . . . . . . . . . . . . . . . . . . 94 8.1.2. from . . . . . . . . . . . . . . . . . . . . . . . . 96
8.1.2.1. Client-to-Server Streams . . . . . . . . . . . . 94 8.1.2.1. Client-to-Server Streams . . . . . . . . . . . . 96
8.1.2.2. Server-to-Server Streams . . . . . . . . . . . . 95 8.1.2.2. Server-to-Server Streams . . . . . . . . . . . . 97
8.1.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 95 8.1.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 97
8.1.4. type . . . . . . . . . . . . . . . . . . . . . . . . 96 8.1.4. type . . . . . . . . . . . . . . . . . . . . . . . . 97
8.1.5. xml:lang . . . . . . . . . . . . . . . . . . . . . . 96 8.1.5. xml:lang . . . . . . . . . . . . . . . . . . . . . . 98
8.2. Basic Semantics . . . . . . . . . . . . . . . . . . . . 97 8.2. Basic Semantics . . . . . . . . . . . . . . . . . . . . 99
8.2.1. Message Semantics . . . . . . . . . . . . . . . . . 97 8.2.1. Message Semantics . . . . . . . . . . . . . . . . . 99
8.2.2. Presence Semantics . . . . . . . . . . . . . . . . . 98 8.2.2. Presence Semantics . . . . . . . . . . . . . . . . . 99
8.2.3. IQ Semantics . . . . . . . . . . . . . . . . . . . . 98 8.2.3. IQ Semantics . . . . . . . . . . . . . . . . . . . . 99
8.3. Stanza Errors . . . . . . . . . . . . . . . . . . . . . 100 8.3. Stanza Errors . . . . . . . . . . . . . . . . . . . . . 101
8.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 101 8.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 102
8.3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 101 8.3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 102
8.3.3. Defined Conditions . . . . . . . . . . . . . . . . . 103 8.3.3. Defined Conditions . . . . . . . . . . . . . . . . . 104
8.3.3.1. bad-request . . . . . . . . . . . . . . . . . . . 103 8.3.3.1. bad-request . . . . . . . . . . . . . . . . . . . 104
8.3.3.2. conflict . . . . . . . . . . . . . . . . . . . . 103 8.3.3.2. conflict . . . . . . . . . . . . . . . . . . . . 104
8.3.3.3. feature-not-implemented . . . . . . . . . . . . . 104 8.3.3.3. feature-not-implemented . . . . . . . . . . . . . 105
8.3.3.4. forbidden . . . . . . . . . . . . . . . . . . . . 104 8.3.3.4. forbidden . . . . . . . . . . . . . . . . . . . . 105
8.3.3.5. gone . . . . . . . . . . . . . . . . . . . . . . 105 8.3.3.5. gone . . . . . . . . . . . . . . . . . . . . . . 106
8.3.3.6. internal-server-error . . . . . . . . . . . . . . 106 8.3.3.6. internal-server-error . . . . . . . . . . . . . . 107
8.3.3.7. item-not-found . . . . . . . . . . . . . . . . . 106 8.3.3.7. item-not-found . . . . . . . . . . . . . . . . . 107
8.3.3.8. jid-malformed . . . . . . . . . . . . . . . . . . 107 8.3.3.8. jid-malformed . . . . . . . . . . . . . . . . . . 108
8.3.3.9. not-acceptable . . . . . . . . . . . . . . . . . 107 8.3.3.9. not-acceptable . . . . . . . . . . . . . . . . . 108
8.3.3.10. not-allowed . . . . . . . . . . . . . . . . . . . 108 8.3.3.10. not-allowed . . . . . . . . . . . . . . . . . . . 109
8.3.3.11. not-authorized . . . . . . . . . . . . . . . . . 108 8.3.3.11. not-authorized . . . . . . . . . . . . . . . . . 109
8.3.3.12. payment-required . . . . . . . . . . . . . . . . 109 8.3.3.12. payment-required . . . . . . . . . . . . . . . . 110
8.3.3.13. policy-violation . . . . . . . . . . . . . . . . 109 8.3.3.13. policy-violation . . . . . . . . . . . . . . . . 110
8.3.3.14. recipient-unavailable . . . . . . . . . . . . . . 110 8.3.3.14. recipient-unavailable . . . . . . . . . . . . . . 111
8.3.3.15. redirect . . . . . . . . . . . . . . . . . . . . 111 8.3.3.15. redirect . . . . . . . . . . . . . . . . . . . . 112
8.3.3.16. registration-required . . . . . . . . . . . . . . 111 8.3.3.16. registration-required . . . . . . . . . . . . . . 112
8.3.3.17. remote-server-not-found . . . . . . . . . . . . . 112 8.3.3.17. remote-server-not-found . . . . . . . . . . . . . 113
8.3.3.18. remote-server-timeout . . . . . . . . . . . . . . 113 8.3.3.18. remote-server-timeout . . . . . . . . . . . . . . 114
8.3.3.19. resource-constraint . . . . . . . . . . . . . . . 113 8.3.3.19. resource-constraint . . . . . . . . . . . . . . . 114
8.3.3.20. service-unavailable . . . . . . . . . . . . . . . 114 8.3.3.20. service-unavailable . . . . . . . . . . . . . . . 115
8.3.3.21. subscription-required . . . . . . . . . . . . . . 114 8.3.3.21. subscription-required . . . . . . . . . . . . . . 115
8.3.3.22. undefined-condition . . . . . . . . . . . . . . . 115 8.3.3.22. undefined-condition . . . . . . . . . . . . . . . 116
8.3.3.23. unexpected-request . . . . . . . . . . . . . . . 116 8.3.3.23. unexpected-request . . . . . . . . . . . . . . . 117
8.3.4. Application-Specific Conditions . . . . . . . . . . 117 8.3.4. Application-Specific Conditions . . . . . . . . . . 118
8.4. Extended Content . . . . . . . . . . . . . . . . . . . . 118 8.4. Extended Content . . . . . . . . . . . . . . . . . . . . 119
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 121 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 122
9.1. Client-to-Server Examples . . . . . . . . . . . . . . . 121 9.1. Client-to-Server Examples . . . . . . . . . . . . . . . 122
9.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 121 9.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 122
9.1.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 123 9.1.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 124
9.1.3. Resource Binding . . . . . . . . . . . . . . . . . . 125 9.1.3. Resource Binding . . . . . . . . . . . . . . . . . . 126
9.1.4. Stanza Exchange . . . . . . . . . . . . . . . . . . 126 9.1.4. Stanza Exchange . . . . . . . . . . . . . . . . . . 127
9.1.5. Close . . . . . . . . . . . . . . . . . . . . . . . 126 9.1.5. Close . . . . . . . . . . . . . . . . . . . . . . . 127
9.2. Server-to-Server Examples . . . . . . . . . . . . . . . 127 9.2. Server-to-Server Examples . . . . . . . . . . . . . . . 128
9.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 127 9.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 128
9.2.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 128 9.2.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 129
9.2.3. Stanza Exchange . . . . . . . . . . . . . . . . . . 129 9.2.3. Stanza Exchange . . . . . . . . . . . . . . . . . . 130
9.2.4. Close . . . . . . . . . . . . . . . . . . . . . . . 130 9.2.4. Close . . . . . . . . . . . . . . . . . . . . . . . 131
10. Server Rules for Processing XML Stanzas . . . . . . . . . . . 130 10. Server Rules for Processing XML Stanzas . . . . . . . . . . . 131
10.1. In-Order Processing . . . . . . . . . . . . . . . . . . 130 10.1. In-Order Processing . . . . . . . . . . . . . . . . . . 131
10.2. General Considerations . . . . . . . . . . . . . . . . . 132 10.2. General Considerations . . . . . . . . . . . . . . . . . 133
10.3. No 'to' Address . . . . . . . . . . . . . . . . . . . . 133 10.3. No 'to' Address . . . . . . . . . . . . . . . . . . . . 134
10.3.1. Message . . . . . . . . . . . . . . . . . . . . . . 133 10.3.1. Message . . . . . . . . . . . . . . . . . . . . . . 134
10.3.2. Presence . . . . . . . . . . . . . . . . . . . . . . 133 10.3.2. Presence . . . . . . . . . . . . . . . . . . . . . . 134
10.3.3. IQ . . . . . . . . . . . . . . . . . . . . . . . . . 133 10.3.3. IQ . . . . . . . . . . . . . . . . . . . . . . . . . 134
10.4. Remote Domain . . . . . . . . . . . . . . . . . . . . . 134 10.4. Remote Domain . . . . . . . . . . . . . . . . . . . . . 135
10.4.1. Existing Stream . . . . . . . . . . . . . . . . . . 134 10.4.1. Existing Stream . . . . . . . . . . . . . . . . . . 135
10.4.2. No Existing Stream . . . . . . . . . . . . . . . . . 134 10.4.2. No Existing Stream . . . . . . . . . . . . . . . . . 135
10.4.3. Error Handling . . . . . . . . . . . . . . . . . . . 135 10.4.3. Error Handling . . . . . . . . . . . . . . . . . . . 136
10.5. Local Domain . . . . . . . . . . . . . . . . . . . . . . 135 10.5. Local Domain . . . . . . . . . . . . . . . . . . . . . . 136
10.5.1. Mere Domain . . . . . . . . . . . . . . . . . . . . 135 10.5.1. Mere Domain . . . . . . . . . . . . . . . . . . . . 136
10.5.2. Domain with Resource . . . . . . . . . . . . . . . . 135 10.5.2. Domain with Resource . . . . . . . . . . . . . . . . 136
10.5.3. Localpart at Domain . . . . . . . . . . . . . . . . 135 10.5.3. Localpart at Domain . . . . . . . . . . . . . . . . 136
10.5.3.1. No Such User . . . . . . . . . . . . . . . . . . 136 10.5.3.1. No Such User . . . . . . . . . . . . . . . . . . 137
10.5.3.2. Bare JID . . . . . . . . . . . . . . . . . . . . 136 10.5.3.2. Bare JID . . . . . . . . . . . . . . . . . . . . 137
10.5.3.3. Full JID . . . . . . . . . . . . . . . . . . . . 136 10.5.3.3. Full JID . . . . . . . . . . . . . . . . . . . . 137
11. XML Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 137 11. XML Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 138
11.1. Restrictions . . . . . . . . . . . . . . . . . . . . . . 137 11.1. Restrictions . . . . . . . . . . . . . . . . . . . . . . 138
11.2. XML Namespace Names and Prefixes . . . . . . . . . . . . 137 11.2. XML Namespace Names and Prefixes . . . . . . . . . . . . 138
11.3. Well-Formedness . . . . . . . . . . . . . . . . . . . . 138 11.3. Well-Formedness . . . . . . . . . . . . . . . . . . . . 139
11.4. Validation . . . . . . . . . . . . . . . . . . . . . . . 138 11.4. Validation . . . . . . . . . . . . . . . . . . . . . . . 139
11.5. Inclusion of XML Declaration . . . . . . . . . . . . . . 139 11.5. Inclusion of XML Declaration . . . . . . . . . . . . . . 140
11.6. Character Encoding . . . . . . . . . . . . . . . . . . . 139 11.6. Character Encoding . . . . . . . . . . . . . . . . . . . 140
11.7. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 139 11.7. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 140
11.8. XML Versions . . . . . . . . . . . . . . . . . . . . . . 140 11.8. XML Versions . . . . . . . . . . . . . . . . . . . . . . 141
12. Internationalization Considerations . . . . . . . . . . . . . 140 12. Internationalization Considerations . . . . . . . . . . . . . 141
13. Security Considerations . . . . . . . . . . . . . . . . . . . 140 13. Security Considerations . . . . . . . . . . . . . . . . . . . 141
13.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 140 13.1. Fundamentals . . . . . . . . . . . . . . . . . . . . . . 141
13.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 141 13.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 142
13.3. Order of Layers . . . . . . . . . . . . . . . . . . . . 142 13.3. Order of Layers . . . . . . . . . . . . . . . . . . . . 143
13.4. Confidentiality and Integrity . . . . . . . . . . . . . 142 13.4. Confidentiality and Integrity . . . . . . . . . . . . . 143
13.5. Peer Entity Authentication . . . . . . . . . . . . . . . 142 13.5. Peer Entity Authentication . . . . . . . . . . . . . . . 144
13.6. Strong Security . . . . . . . . . . . . . . . . . . . . 142 13.6. Strong Security . . . . . . . . . . . . . . . . . . . . 144
13.7. Certificates . . . . . . . . . . . . . . . . . . . . . . 143 13.7. Certificates . . . . . . . . . . . . . . . . . . . . . . 144
13.7.1. Certificate Generation . . . . . . . . . . . . . . . 143 13.7.1. Certificate Generation . . . . . . . . . . . . . . . 145
13.7.1.1. General Considerations . . . . . . . . . . . . . 143 13.7.1.1. General Considerations . . . . . . . . . . . . . 145
13.7.1.2. Server Certificates . . . . . . . . . . . . . . . 144 13.7.1.2. Server Certificates . . . . . . . . . . . . . . . 146
13.7.1.3. Client Certificates . . . . . . . . . . . . . . . 146 13.7.1.3. Client Certificates . . . . . . . . . . . . . . . 148
13.7.1.4. XmppAddr Identifier Type . . . . . . . . . . . . 146 13.7.1.4. XmppAddr Identifier Type . . . . . . . . . . . . 148
13.7.2. Certificate Validation . . . . . . . . . . . . . . . 147 13.7.2. Certificate Validation . . . . . . . . . . . . . . . 149
13.7.2.1. Server Certificates . . . . . . . . . . . . . . . 147 13.7.2.1. Server Certificates . . . . . . . . . . . . . . . 149
13.7.2.2. Client Certificates . . . . . . . . . . . . . . . 148 13.7.2.2. Client Certificates . . . . . . . . . . . . . . . 149
13.7.2.3. Checking of Certificates in Long-Lived Streams . 149 13.7.2.3. Checking of Certificates in Long-Lived Streams . 150
13.7.2.4. Use of Certificates in XMPP Extensions . . . . . 149 13.7.2.4. Use of Certificates in XMPP Extensions . . . . . 151
13.8. Mandatory-to-Implement Technologies . . . . . . . . . . 149 13.8. Mandatory-to-Implement Technologies . . . . . . . . . . 151
13.9. Technology Reuse . . . . . . . . . . . . . . . . . . . . 150 13.9. Technology Reuse . . . . . . . . . . . . . . . . . . . . 152
13.9.1. Use of base64 in SASL . . . . . . . . . . . . . . . 150 13.9.1. Use of base64 in SASL . . . . . . . . . . . . . . . 152
13.9.2. Use of DNS . . . . . . . . . . . . . . . . . . . . . 151 13.9.2. Use of DNS . . . . . . . . . . . . . . . . . . . . . 153
13.9.3. Use of Hash Functions . . . . . . . . . . . . . . . 151 13.9.3. Use of Hash Functions . . . . . . . . . . . . . . . 153
13.9.4. Use of SASL . . . . . . . . . . . . . . . . . . . . 151 13.9.4. Use of SASL . . . . . . . . . . . . . . . . . . . . 153
13.9.5. Use of TLS . . . . . . . . . . . . . . . . . . . . . 152 13.9.5. Use of TLS . . . . . . . . . . . . . . . . . . . . . 154
13.9.6. Use of UTF-8 . . . . . . . . . . . . . . . . . . . . 153 13.9.6. Use of UTF-8 . . . . . . . . . . . . . . . . . . . . 155
13.9.7. Use of XML . . . . . . . . . . . . . . . . . . . . . 153 13.9.7. Use of XML . . . . . . . . . . . . . . . . . . . . . 155
13.10. Information Leaks . . . . . . . . . . . . . . . . . . . 153 13.10. Information Leaks . . . . . . . . . . . . . . . . . . . 155
13.10.1. IP Addresses . . . . . . . . . . . . . . . . . . . . 153 13.10.1. IP Addresses . . . . . . . . . . . . . . . . . . . . 155
13.10.2. Presence Information . . . . . . . . . . . . . . . . 153 13.10.2. Presence Information . . . . . . . . . . . . . . . . 155
13.11. Directory Harvesting . . . . . . . . . . . . . . . . . . 154 13.11. Directory Harvesting . . . . . . . . . . . . . . . . . . 156
13.12. Denial of Service . . . . . . . . . . . . . . . . . . . 154 13.12. Denial of Service . . . . . . . . . . . . . . . . . . . 156
13.13. Firewalls . . . . . . . . . . . . . . . . . . . . . . . 156 13.13. Firewalls . . . . . . . . . . . . . . . . . . . . . . . 158
13.14. Interdomain Federation . . . . . . . . . . . . . . . . . 156 13.14. Interdomain Federation . . . . . . . . . . . . . . . . . 158
13.15. Non-Repudiation . . . . . . . . . . . . . . . . . . . . 156 13.15. Non-Repudiation . . . . . . . . . . . . . . . . . . . . 158
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 157 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 159
14.1. XML Namespace Name for TLS Data . . . . . . . . . . . . 157 14.1. XML Namespace Name for TLS Data . . . . . . . . . . . . 159
14.2. XML Namespace Name for SASL Data . . . . . . . . . . . . 157 14.2. XML Namespace Name for SASL Data . . . . . . . . . . . . 159
14.3. XML Namespace Name for Stream Errors . . . . . . . . . . 157 14.3. XML Namespace Name for Stream Errors . . . . . . . . . . 159
14.4. XML Namespace Name for Resource Binding . . . . . . . . 158 14.4. XML Namespace Name for Resource Binding . . . . . . . . 160
14.5. XML Namespace Name for Stanza Errors . . . . . . . . . . 158 14.5. XML Namespace Name for Stanza Errors . . . . . . . . . . 160
14.6. GSSAPI Service Name . . . . . . . . . . . . . . . . . . 158 14.6. GSSAPI Service Name . . . . . . . . . . . . . . . . . . 160
14.7. Port Numbers . . . . . . . . . . . . . . . . . . . . . . 158 14.7. Port Numbers and Service Names . . . . . . . . . . . . . 160
15. Conformance Requirements . . . . . . . . . . . . . . . . . . 158 15. Conformance Requirements . . . . . . . . . . . . . . . . . . 161
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 167 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 170
16.1. Normative References . . . . . . . . . . . . . . . . . . 167 16.1. Normative References . . . . . . . . . . . . . . . . . . 170
16.2. Informative References . . . . . . . . . . . . . . . . . 170 16.2. Informative References . . . . . . . . . . . . . . . . . 173
Appendix A. XML Schemas . . . . . . . . . . . . . . . . . . . . 175 Appendix A. XML Schemas . . . . . . . . . . . . . . . . . . . . 178
A.1. Streams Namespace . . . . . . . . . . . . . . . . . . . 175 A.1. Streams Namespace . . . . . . . . . . . . . . . . . . . 178
A.2. Stream Error Namespace . . . . . . . . . . . . . . . . . 177 A.2. Stream Error Namespace . . . . . . . . . . . . . . . . . 180
A.3. STARTTLS Namespace . . . . . . . . . . . . . . . . . . . 180 A.3. STARTTLS Namespace . . . . . . . . . . . . . . . . . . . 182
A.4. SASL Namespace . . . . . . . . . . . . . . . . . . . . . 180 A.4. SASL Namespace . . . . . . . . . . . . . . . . . . . . . 183
A.5. Resource Binding Namespace . . . . . . . . . . . . . . . 183 A.5. Resource Binding Namespace . . . . . . . . . . . . . . . 185
A.6. Stanza Error Namespace . . . . . . . . . . . . . . . . . 183 A.6. Stanza Error Namespace . . . . . . . . . . . . . . . . . 185
Appendix B. Contact Addresses . . . . . . . . . . . . . . . . . 185 Appendix B. Contact Addresses . . . . . . . . . . . . . . . . . 187
Appendix C. Account Provisioning . . . . . . . . . . . . . . . . 185 Appendix C. Account Provisioning . . . . . . . . . . . . . . . . 187
Appendix D. Differences from RFC 3920 . . . . . . . . . . . . . 185 Appendix D. Differences from RFC 3920 . . . . . . . . . . . . . 187
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 187 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 189
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,
skipping to change at page 11, line 10 skipping to change at page 11, line 10
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.
1.4. Terminology 1.4. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"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",
skipping to change at page 14, line 6 skipping to change at page 14, line 6
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 <domain.tld> (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>), and a particular connected device or
resource that is currently authorized for interaction on behalf of an resource that is currently authorized for interaction on behalf of an
account is of the form <localpart@domainpart/resource> (e.g., account is of the form <localpart@domainpart/resourcepart> (e.g.,
<juliet@im.example.com/balcony>). For historical reasons, XMPP <juliet@im.example.com/balcony>). For historical reasons, XMPP
addresses are often called Jabber IDs or JIDs. Because the formal addresses are often called Jabber IDs or JIDs. Because the formal
specification of the XMPP address format depends on specification of the XMPP address format depends on
internationalization technologies that are in flux at the time of internationalization technologies that are in flux at the time of
writing, the format is defined in [XMPP-ADDR] instead of this writing, the format is defined in [XMPP-ADDR] instead of this
document. document.
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
skipping to change at page 18, line 32 skipping to change at page 18, line 32
of the receiving entity (say, to "hardcode" an association from an of 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 hostname of
webcm.example.com:80), the initiating entity SHOULD use the webcm.example.com:80), the initiating entity SHOULD use the
configured name instead of performing the preferred SRV resolution configured name instead of performing the preferred SRV resolution
process on the origin name. process on the origin name.
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 hostnames that typically are subdomains of the hostname [XMPP-IM]) at DNS domain names that typically are "subdomains" of the
of the main XMPP service (e.g., conference.example.net for a main XMPP service (e.g., conference.example.net for a [XEP-0045]
[XEP-0045] service associated with the example.net XMPP service) or service associated with the example.net XMPP service) or "subdomains"
subdomains of the first-level domain of the underlying host (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 from a remote domain im.example.com XMPP service). If an entity associated with a remote
wishes to use such add-on services, it would generate an appropriate XMPP server wishes to use such an add-on service, it would generate
XML stanza and the remote domain itself would attempt to resolve the an appropriate XML stanza and the remote server would attempt to
service's hostname via an SRV lookup on resource records such as resolve the add-on service's DNS domain name via an SRV lookup on
"_xmpp-server._tcp.conference.example.net." or "_xmpp- resource records such as "_xmpp-server._tcp.conference.example.net."
server._tcp.muc.example.com.". Therefore if a service wishes to or "_xmpp-server._tcp.muc.example.com.". Therefore if the
enable entities from remote domains to access these add-on services, administrators of an XMPP service wish to enable entities associated
it needs to advertise the appropriate "_xmpp-server" SRV records in with remote servers to access such add-on services, they need to
addition to the "_xmpp-server" record for its main XMPP service. The advertise the appropriate "_xmpp-server" SRV records in addition to
same fallback methods apply in case SRV records are not available. the "_xmpp-server" record for their main XMPP service. In case SRV
records are not available, the fallback methods described under
Section 3.2.2 can 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 local clients and from other 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:
skipping to change at page 20, line 38 skipping to change at page 20, line 42
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 optionally 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, an XML stream acts as an envelope for all the XML In essence, then, one XML stream functions as an envelope for the XML
stanzas sent during a connection. We can represent this in a stanzas sent during a session and another XML stream functions as an
simplistic fashion as follows. envelope for the XML stanzas received during a session. We can
represent this in a simplistic fashion as follows.
+--------------------+ +--------------------+--------------------+
| <stream> | | INITIAL STREAM | RESPONSE STREAM |
|--------------------| +--------------------+--------------------+
| <presence> | | <stream> | |
| <show/> | |--------------------|--------------------|
| </presence> | | | <stream> |
|--------------------| |--------------------|--------------------|
| <message to='foo'> | | <presence> | |
| <body/> | | <show/> | |
| </message> | | </presence> | |
|--------------------| |--------------------|--------------------|
| <iq to='bar'> | | <message to='foo'> | |
| <query/> | | <body/> | |
| </iq> | | </message> | |
|--------------------| |--------------------|--------------------|
| <iq from='bar'> | | <iq to='bar' | |
| <query/> | | type='get'> | |
| </iq> | | <query/> | |
|--------------------| | </iq> | |
| [ ... ] | |--------------------|--------------------|
|--------------------| | | <iq from='bar' |
| </stream> | | | type='result'> |
+--------------------+ | | <query/> |
| | </iq> |
|--------------------|--------------------|
| [ ... ] | |
|--------------------|--------------------|
| | [ ... ] |
|--------------------|--------------------|
| </stream> | |
|--------------------|--------------------|
| | </stream> |
+--------------------+--------------------+
Figure 2: A Simplified Stream 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 production
[1] content of [XML]) that are built up through the accumulation [1] content of [XML]) that are built up through the accumulation
of XML stanzas. 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
skipping to change at page 26, line 19 skipping to change at page 26, line 29
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
during SASL negotiation (Section 6) or (2) as derived by the server during SASL negotiation (Section 6) or (2) as derived by the server
from the authentication identity if no authorization identity was from the authentication identity if no authorization identity was
specified during SASL negotiation. The resourcepart of the full JID specified during SASL negotiation. The resourcepart of the full JID
(<localpart@domainpart/resource>) MUST be the resource negotiated by (<localpart@domainpart/resourcepart>) MUST be the resource negotiated
the client and server during resource binding (Section 7). A client by the client and server during resource binding (Section 7). A
MUST NOT attempt to guess at its JID but instead MUST consider its client MUST NOT attempt to guess at its JID but instead MUST consider
JID to be whatever the server returns to it during resource binding. its JID to be whatever the server returns to it during resource
The server MUST ensure that the resulting JID (including localpart, binding. The server MUST ensure that the resulting JID (including
domainpart, resourcepart, and separator characters) conforms to the localpart, domainpart, resourcepart, and separator characters)
canonical format for XMPP addresses defined in [XMPP-ADDR]; to meet conforms to the canonical format for XMPP addresses defined in
this restriction, the server MAY replace the JID sent by the client [XMPP-ADDR]; to meet this restriction, the server MAY replace the JID
with the canonicalized JID as determined by the server and sent by the client with the canonicalized JID as determined by the
communicate that JID to the client during resource binding. server and communicate that JID to the client during resource
binding.
For server-to-server communication, the initiating server's JID For server-to-server communication, the initiating server's 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/>
skipping to change at page 29, line 6 skipping to change at page 30, line 6
STARTTLS negotiation (Section 5) and SASL negotiation (Section 6) two STARTTLS negotiation (Section 5) and SASL negotiation (Section 6) two
servers would use one TCP connection, but after the stream servers would use one TCP connection, but after the stream
negotiation process is done that original TCP connection would be negotiation process is done that original TCP connection would be
used only for the initiating server to send XML stanzas to the used only for the initiating server to send XML stanzas to the
receiving server. In order for the receiving server to send XML receiving server. In order for the receiving server to send XML
stanzas to the initiating server, the receiving server would need to stanzas to the initiating server, the receiving server would need to
reverse the roles and negotiate an XML stream from the receiving reverse the roles and negotiate an XML stream from the receiving
server to the initiating server over a separate TCP connection. server to the initiating server over a separate TCP connection.
Implementation Note: For historical reasons, a server-to-server Implementation Note: For historical reasons, a server-to-server
session always uses two TCP connections. Although extensions such session always uses two TCP connections. While that approach
as [XEP-0288] allow servers to use a single TCP connection after remains the standard behavior described in this document,
negotiation of a suitable feature, definition of such a feature is extensions such as [XEP-0288] enable servers to negotiate the use
out of scope for this document. of a single TCP connection for bidirectional stanza exchange.
Informational Note: Although XMPP developers sometimes apply the Informational Note: Although XMPP developers sometimes apply the
terms "unidirectional" and "bidirectional" to the underlying TCP terms "unidirectional" and "bidirectional" to the underlying TCP
connection (e.g., calling the TCP connection for a client-to- connection (e.g., calling the TCP connection for a client-to-
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
skipping to change at page 93, line 44 skipping to change at page 94, line 44
<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 The following rules apply to inclusion of the 'to' attribute in
context of XML streams qualified by the 'jabber:client' namespace stanzas sent from the client to the server over an XML stream
(i.e., client-to-server streams). qualified by the 'jabber:client' namespace.
1. A stanza with a specific intended recipient MUST possess a 'to' 1. A stanza with a specific intended recipient (e.g., a conversation
partner, a remote service, the server itself, even another
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 as described in [XMPP-IM] for rosters (e.g., presence
sent to the server for broadcasting to other entities) MUST NOT sent to the server for broadcasting to other entities) MUST NOT
possess a 'to' attribute. possess a 'to' attribute.
The following rules apply to inclusion of the 'to' attribute in
stanzas sent from the server to the client over an XML stream
qualified by the 'jabber:client' namespace.
1. If the server has received the stanza from another connected
client or from another server, the server MUST NOT modify the
'to' address before delivering the stanza to the client.
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
not include a 'to' address), the stanza MAY include a 'to'
address, which MUST be the full JID of the client; however, if
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
client's full JID.
Implementation Note: It is the server's responsibility to deliver
only stanzas that are addressed to the client's full JID or the
user's bare JID; thus there is no need for the client to check the
'to' address of incoming stanzas. However, if the client does
check the 'to' address then it is suggested to check at most the
bare JID portion (not the full JID), since the 'to' address might
be the user's bare JID, the client's current full JID, or even a
full JID with a different resourcepart (e.g., in the case of so-
called "offline messages" as described in [XEP-0160]).
8.1.1.2. Server-to-Server Streams 8.1.1.2. Server-to-Server Streams
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.
skipping to change at page 124, line 24 skipping to change at page 125, line 24
The decoded base64 data is "c=biws, r=oMsTAAwAAAAMAAAANP0TAAAAAABPU0A The decoded base64 data is "c=biws, r=oMsTAAwAAAAMAAAANP0TAAAAAABPU0A
Ae124695b-69a9-4de6-9c30-b51b3808c59e, p=UA57tM/ Ae124695b-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 base64 data is "v=pNNDFVEQxuXxCoSEiW8GEZ+1RSo=".
Step 12 (alt): Server returns error to client: Step 12 (alt): Server returns error to client:
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>
Step 13: Client initiates a new stream to server: Step 13: Client initiates a new stream to server:
skipping to change at page 127, line 21 skipping to change at page 128, line 21
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 another 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 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.
9.2.1. TLS 9.2.1. TLS
Step 1: Server1 initiates stream to Server2: Step 1: Server1 initiates 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'
skipping to change at page 135, line 42 skipping to change at page 136, line 42
MUST proceed as follows. MUST proceed as follows.
10.5.1. Mere Domain 10.5.1. Mere Domain
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 <domain>,
then the server MUST either (a) handle the stanza as appropriate for then the server MUST either (a) handle the stanza as appropriate for
the stanza kind or (b) return an error stanza to the sender. the stanza kind or (b) return an error stanza to the sender.
10.5.2. Domain with Resource 10.5.2. Domain with Resource
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
resource>, then the server MUST either (a) handle the stanza as <domainpart/resourcepart>, then the server MUST either (a) handle the
appropriate for the stanza kind or (b) return an error stanza to the stanza as appropriate for the stanza kind or (b) return an error
sender. stanza to the sender.
10.5.3. Localpart at Domain 10.5.3. Localpart at Domain
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
skipping to change at page 136, line 46 skipping to change at page 137, line 46
session" as defined in [XMPP-IM]), the server SHOULD deliver it to session" as defined in [XMPP-IM]), the server SHOULD deliver it to
such resources. If there exists no connected resource, the server such resources. If there exists no connected resource, the server
SHOULD ignore the stanza (or behave as described in [XMPP-IM]). 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.3.3. Full JID
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/resource> and there is no connected resource <localpart@domainpart/resourcepart> and there is no connected
that exactly matches the full JID, the stanza SHOULD be processed as resource that exactly matches the full JID, the stanza SHOULD be
if the JID were of the form <localpart@domainpart>. processed as if the JID were of the form <localpart@domainpart>.
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/resource> and there is a connected resource <localpart@domainpart/resourcepart> and there is a connected resource
that exactly matches the full JID, the server MUST deliver the stanza that exactly matches the full JID, the server MUST deliver the stanza
to that connected resource. to that connected resource.
11. XML Usage 11. XML Usage
11.1. Restrictions 11.1. 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
XML documents, there is no requirement that XMPP needs to support the XML documents, there is no requirement that XMPP needs to support the
full feature set of [XML]. In particular, the following features of full feature set of [XML]. Furthermore, XMPP uses XML to define
protocol data structures and extensions for the purpose of structured
interactions between network entities and therefore adheres to the
recommendations provided in [XML-GUIDE] regarding restrictions on the
use of XML in IETF protocols. As a result, the following features of
XML are prohibited in XMPP: XML are prohibited in XMPP:
o comments (as defined in Section 2.5 of [XML]) o comments (as defined in Section 2.5 of [XML])
o processing instructions (Section 2.6 therein) o processing instructions (Section 2.6 therein)
o internal or external DTD subsets (Section 2.8 therein) o internal or external DTD subsets (Section 2.8 therein)
o internal or external entity references (Section 4.2 therein) with o internal or external entity references (Section 4.2 therein) with
the exception of the predefined entities (Section 4.6 therein) the exception of the predefined entities (Section 4.6 therein)
An XMPP implementation MUST behave as follows with regard to these An XMPP implementation MUST behave as follows with regard to these
features: features:
skipping to change at page 142, line 31 skipping to change at page 143, line 31
The use of Transport Layer Security (TLS) with non-null cipher suites The use of Transport Layer Security (TLS) with non-null cipher suites
provides a reliable mechanism for the ensuring the confidentiality provides a reliable mechanism for the ensuring the confidentiality
and integrity of data exchanged between a client and a server or and integrity of data exchanged between a client and a server or
between two servers. Therefore TLS helps to protect against between two servers. Therefore TLS helps to protect against
eavesdropping, password sniffing, man-in-the-middle attacks, and eavesdropping, password sniffing, man-in-the-middle attacks, and
stanza replays, insertion, deletion, and modification over an XML 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.
Security Note: The confidentiality and integrity of a stream can Informational Note: The confidentiality and integrity of a stream
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.
Because XMPP is typically deployed using a distributed client-
server architecture (as explained under Section 2.5), a stanza
might traverse multiple streams, and not all of those streams
might be TLS-protected. For example, a stanza sent from a client
with a session at one server (e.g., <romeo@example.net/orchard>)
and intended for delivery to a client with a session at another
server (e.g., <juliet@example.com/balcony>) will traverse three
streams: the stream from the sender's client to its server, the
stream from the sender's server to the recipient's server, and the
stream from the recipient's server to the recipient's client.
Furthermore, the stanza will be processed as cleartext within the
sender's server and the recipient's server. Therefore, even if
the stream from the sender's client to its server is protected,
the confidentiality and integrity of a stanza sent over that
protected stream cannot be guaranteed when the stanza is processed
by the sender's server, sent from the sender's server to the
recipient's server, processed by the recipient's server, or sent
from the recipient's server to the recipient's client. Only a
robust technology for end-to-end encryption could ensure the
confidentiality and integrity of a stanza as it traverses all of
the "hops" along a communication path (e.g., a technology that
meets the requirements defined in [E2E-REQS]). Unfortunately, the
XMPP community has so far failed to produce an end-to-end
encryption technology that might be suitable for widespread
implementation and deployment, and definition of such a technology
is out of scope for this document.
13.5. Peer Entity Authentication 13.5. Peer Entity Authentication
The use of the Simple Authentication and Security Layer (SASL) for The use of the Simple Authentication and Security Layer (SASL) for
authentication provides a reliable mechanism for peer entity authentication provides a reliable mechanism for peer entity
authentication. Therefore SASL helps to protect against user authentication. Therefore SASL helps to protect against user
spoofing, unauthorized usage, and man-in-the middle attacks. XMPP spoofing, unauthorized usage, and man-in-the middle attacks. XMPP
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
skipping to change at page 144, line 33 skipping to change at page 146, line 13
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 include
one or more JIDs (i.e., domainparts) associated with domains serviced one or more JIDs (i.e., domainparts) associated with domains serviced
at the server. The rules and guidelines defined in [TLS-CERTS] apply at the server. The rules and guidelines defined in [TLS-CERTS] apply
to XMPP server certificates. XMPP client and server software to XMPP server certificates, with the following supplemental rules
implementations MUST be able to validate both the SRV-ID and DNS-ID for XMPP:
identifier types described in [TLS-CERTS]. Certification authorities
that issue XMPP-specific certificates MUST support the DNS-ID o Support for the DNS-ID identifier type [PKIX] is REQUIRED in XMPP
identifier type and SHOULD support the SRV-ID identifier type. client and server software implementations. Certification
Service providers SHOULD request and prefer certificates that include authorities that issue XMPP-specific certificates MUST support the
the SRV-ID identifier type. Support for the XmppAddr identifier type DNS-ID identifier type. Service providers SHOULD include the
(specified under Section 13.7.1.4) and the CN-ID identifier type DNS-ID identifier type in certificate requests.
(described in [TLS-CERTS]) is encouraged for the sake of backward-
compatibility. o Support for the SRV-ID identifier type [PKIX-SRV] is REQUIRED for
XMPP client and server software implementations (XMPP client
implementations need to support only the "_xmpp-client" service
type, whereas XMPP server implementations need to support both the
"_xmpp-client" and "_xmpp-server" service types). Certification
authorities that issue XMPP-specific certificates SHOULD support
the SRV-ID identifier type. Service providers SHOULD include the
SRV-ID identifier type in certificate requests.
o Support for the XmppAddr identifier type (specified under
Section 13.7.1.4) is encouraged in XMPP client and server software
implementations for the sake of backward-compatibility, but is no
longer encouraged in certificates issued by certification
authorities or requested by service providers.
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:
skipping to change at page 153, line 51 skipping to change at page 155, line 50
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 if a potential
attacker sends XML stanzas to the entity's bare JID attacker sends XML stanzas to the entity's bare JID
(<localpart@domainpart>) or full JID (<localpart@domainpart>) or full JID
(<localpart@domainpart/resource>). (<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
element is not understood, or if offline message storage or message element is not understood, or if "offline message storage"
forwarding is not enabled for a domain. However, subtle differences ([XEP-0160]) or message forwarding is not enabled for a domain.
in the exact XML of error stanzas, as well as in the timing with However, subtle differences in the exact XML of error stanzas, as
which such errors are returned, can enable an attacker to determine well as in the timing with which such errors are returned, can enable
the network presence of a user when more advanced blocking an attacker to determine the network presence of a user when more
technologies are not used (see for instance [XEP-0016] and advanced blocking technologies are not used (see for instance
[XEP-0191]). Therefore, a server that exercises a higher level of [XEP-0016] and [XEP-0191]). Therefore, a server that exercises a
caution might not return any error at all in response to certain higher level of caution might not return any error at all in response
kinds of received stanzas, so that a non-existent user appears to to certain kinds of received stanzas, so that a non-existent user
behave like a user that has no interest in conversing with the appears to behave like a user that has no interest in conversing with
sender. the sender.
13.12. Denial of Service 13.12. Denial of Service
[DOS] defines denial of service as follows: [DOS] defines denial of service as follows:
A Denial-of-Service (DoS) attack is an attack in which one or more A Denial-of-Service (DoS) attack is an attack in which one or more
machines target a victim and attempt to prevent the victim from machines target a victim and attempt to prevent the victim from
doing useful work. The victim can be a network server, client or doing useful work. The victim can be a network server, client or
router, a network link or an entire network, an individual router, a network link or an entire network, an individual
Internet user or a company doing business using the Internet, an Internet user or a company doing business using the Internet, an
skipping to change at page 157, line 7 skipping to change at page 159, line 7
13.15. Non-Repudiation 13.15. Non-Repudiation
Systems that provide both peer entity authentication and data Systems that provide both peer entity authentication and data
integrity have the potential to enable an entity to prove to a third integrity have the potential to enable an entity to prove to a third
party that another entity intended to send particular data. Although party that another entity intended to send particular data. Although
XMPP systems can provide both peer entity authentication and data XMPP systems can provide both peer entity authentication and data
integrity, XMPP was never designed to provide non-repudiation. integrity, XMPP was never designed to provide non-repudiation.
14. IANA Considerations 14. IANA Considerations
The following sections update the registrations provided in The following subsections update the registrations provided in
[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
skipping to change at page 158, line 36 skipping to change at page 160, line 36
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 XXXX.
Registrant Contact: IETF, XMPP Working Group, <xmpp@ietf.org> Registrant Contact: IETF, XMPP Working Group, <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 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. for [TCP] ports 5222 and 5269 respectively. In accordance with
[IANA-PORTS], this document updates the existing registration, as
follows.
These ports SHOULD be used for client-to-server and server-to-server Service Name: xmpp-client
communications respectively, but other ports MAY be used. Transport Protocol: TCP
Description: A service offering support for connections by XMPP
client applications
Registrant: IETF XMPP Working Group
Contact: IESG, <iesg@ietf.org>
Reference: XXXX
Port Number: 5222
Service Name: xmpp-server
Transport Protocol: TCP
Description: A service offering support for connections by XMPP
server applications
Registrant: IETF XMPP Working Group
Contact: IESG, <iesg@ietf.org>
Reference: XXXX
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:
o A human-readable name o A human-readable name
skipping to change at page 171, line 11 skipping to change at page 173, line 38
[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.
[DOS] Handley, M., Rescorla, E., and IAB, "Internet Denial-of- [DOS] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-
Service Considerations", RFC 4732, December 2006. Service Considerations", RFC 4732, December 2006.
[E2E-REQS]
Saint-Andre, P., "Requirements for End-to-End Encryption
in the Extensible Messaging and Presence Protocol (XMPP)",
draft-ietf-xmpp-e2e-requirements-01 (work in progress),
March 2010.
[EMAIL-ARCH] [EMAIL-ARCH]
Crocker, D., "Internet Mail Architecture", RFC 5598, Crocker, D., "Internet Mail Architecture", RFC 5598,
July 2009. July 2009.
[ETHERNET] [ETHERNET]
"Information technology - Telecommunications and "Information technology - Telecommunications and
information exchange between systems - Local and information exchange between systems - Local and
metropolitan area networks - Specific requirements - Part metropolitan area networks - Specific requirements - Part
3: Carrier sense multiple access with collision detection 3: Carrier sense multiple access with collision detection
(CSMA/CD) access method and physical layer (CSMA/CD) access method and physical layer
skipping to change at page 171, line 38 skipping to change at page 174, line 22
[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[IANA-GUIDE] [IANA-GUIDE]
Narten, T. and H. Alvestrand, "Guidelines for Writing an Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[IANA-PORTS]
Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S.
Cheshire, "Internet Assigned Numbers Authority (IANA)
Procedures for the Management of the Transport Protocol
Port Number and Service Name Registry",
draft-ietf-tsvwg-iana-ports-07 (work in progress),
October 2010.
[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION [IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
4rev1", RFC 3501, March 2003. 4rev1", RFC 3501, March 2003.
[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
skipping to change at page 174, line 19 skipping to change at page 177, line 11
[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]
Hildebrand, J. and P. Saint-Andre, "Discovering Hildebrand, J. and P. Saint-Andre, "Discovering
Alternative XMPP Connection Methods", XSF XEP 0156, Alternative XMPP Connection Methods", XSF XEP 0156,
June 2007. June 2007.
[XEP-0160]
Saint-Andre, P., "Best Practices for Handling Offline
Messages", XSF XEP 0160, January 2006.
[XEP-0174] [XEP-0174]
Saint-Andre, P., "Link-Local Messaging", XSF XEP 0174, Saint-Andre, P., "Link-Local Messaging", XSF XEP 0174,
November 2008. November 2008.
[XEP-0175] [XEP-0175]
Saint-Andre, P., "Best Practices for Use of SASL Saint-Andre, P., "Best Practices for Use of SASL
ANONYMOUS", XSF XEP 0175, November 2007. ANONYMOUS", XSF XEP 0175, November 2007.
[XEP-0178] [XEP-0178]
Saint-Andre, P. and P. Millard, "Best Practices for Use of Saint-Andre, P. and P. Millard, "Best Practices for Use of
 End of changes. 39 change blocks. 
380 lines changed or deleted 503 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/