< draft-ietf-xmpp-3920bis-01.txt   draft-ietf-xmpp-3920bis-02.txt >
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft Cisco Internet-Draft Cisco
Obsoletes: 3920 (if approved) August 14, 2009 Obsoletes: 3920 (if approved) September 11, 2009
Intended status: Standards Track Intended status: Standards Track
Expires: February 15, 2010 Expires: March 15, 2010
Extensible Messaging and Presence Protocol (XMPP): Core Extensible Messaging and Presence Protocol (XMPP): Core
draft-ietf-xmpp-3920bis-01 draft-ietf-xmpp-3920bis-02
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on February 15, 2010. This Internet-Draft will expire on March 15, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 27 skipping to change at page 2, line 27
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9 1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2. Functional Summary . . . . . . . . . . . . . . . . . . . 10 1.2. Functional Summary . . . . . . . . . . . . . . . . . . . 10
1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . 11 1.3. Conventions . . . . . . . . . . . . . . . . . . . . . . 11
1.4. Acknowledgements . . . . . . . . . . . . . . . . . . . . 12 1.4. Acknowledgements . . . . . . . . . . . . . . . . . . . . 12
1.5. Discussion Venue . . . . . . . . . . . . . . . . . . . . 12 1.5. Discussion Venue . . . . . . . . . . . . . . . . . . . . 12
2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 12 2. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 12
2.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 12 2.1. Global Addresses . . . . . . . . . . . . . . . . . . . . 13
2.2. Server . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.2. Presence . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3. Client . . . . . . . . . . . . . . . . . . . . . . . . . 13 2.3. Persistent Streams . . . . . . . . . . . . . . . . . . . 13
2.4. Network . . . . . . . . . . . . . . . . . . . . . . . . 14 2.4. Structured Data . . . . . . . . . . . . . . . . . . . . 13
3. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 14 2.5. Distributed Network . . . . . . . . . . . . . . . . . . 14
3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 14 3. Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.2. Domain Identifier . . . . . . . . . . . . . . . . . . . 15 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3. Localpart . . . . . . . . . . . . . . . . . . . . . . . 17 3.2. Domain Identifier . . . . . . . . . . . . . . . . . . . 16
3.4. Resource Identifier . . . . . . . . . . . . . . . . . . 17 3.3. Localpart . . . . . . . . . . . . . . . . . . . . . . . 18
3.5. Determination of Addresses . . . . . . . . . . . . . . . 18 3.4. Resource Identifier . . . . . . . . . . . . . . . . . . 18
4. TCP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.5. Determination of Addresses . . . . . . . . . . . . . . . 19
4.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 19 4. TCP Binding . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2. Hostname Resolution . . . . . . . . . . . . . . . . . . 19 4.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . 20
4.3. Client-to-Server Communication . . . . . . . . . . . . . 20 4.2. Hostname Resolution . . . . . . . . . . . . . . . . . . 20
4.4. Server-to-Server Communication . . . . . . . . . . . . . 21 4.3. Client-to-Server Communication . . . . . . . . . . . . . 21
4.5. Reconnection . . . . . . . . . . . . . . . . . . . . . . 21 4.4. Server-to-Server Communication . . . . . . . . . . . . . 22
4.6. Other Bindings . . . . . . . . . . . . . . . . . . . . . 21 4.5. Reconnection . . . . . . . . . . . . . . . . . . . . . . 22
5. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . . 22 4.6. Reliability . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 22 4.7. Other Bindings . . . . . . . . . . . . . . . . . . . . . 23
5.2. Stream Security . . . . . . . . . . . . . . . . . . . . 24 5. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . . 23
5.3. Stream Attributes . . . . . . . . . . . . . . . . . . . 24 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 23
5.3.1. from . . . . . . . . . . . . . . . . . . . . . . . . 25 5.2. Stream Security . . . . . . . . . . . . . . . . . . . . 25
5.3.2. to . . . . . . . . . . . . . . . . . . . . . . . . . 26 5.3. Stream Attributes . . . . . . . . . . . . . . . . . . . 26
5.3.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 27 5.3.1. from . . . . . . . . . . . . . . . . . . . . . . . . 26
5.3.4. xml:lang . . . . . . . . . . . . . . . . . . . . . . 28 5.3.2. to . . . . . . . . . . . . . . . . . . . . . . . . . 28
5.3.5. version . . . . . . . . . . . . . . . . . . . . . . 29 5.3.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 29
5.3.6. Summary of Stream Attributes . . . . . . . . . . . . 31 5.3.4. xml:lang . . . . . . . . . . . . . . . . . . . . . . 29
5.4. Namespace Declarations . . . . . . . . . . . . . . . . . 31 5.3.5. version . . . . . . . . . . . . . . . . . . . . . . 31
5.5. Stream Features . . . . . . . . . . . . . . . . . . . . 31 5.3.6. Summary of Stream Attributes . . . . . . . . . . . . 32
5.6. Restarts During Stream Negotiation . . . . . . . . . . . 33 5.4. Namespace Declarations . . . . . . . . . . . . . . . . . 32
5.7. Closing a Stream . . . . . . . . . . . . . . . . . . . . 34 5.5. Stream Features . . . . . . . . . . . . . . . . . . . . 33
5.7.1. With Stream Error . . . . . . . . . . . . . . . . . 34 5.6. Restarts During Stream Negotiation . . . . . . . . . . . 35
5.7.2. Without Stream Error . . . . . . . . . . . . . . . . 34 5.7. Closing a Stream . . . . . . . . . . . . . . . . . . . . 35
5.7.3. Handling of Idle Streams . . . . . . . . . . . . . . 34 5.7.1. With Stream Error . . . . . . . . . . . . . . . . . 35
5.8. Stream Errors . . . . . . . . . . . . . . . . . . . . . 35 5.7.2. Without Stream Error . . . . . . . . . . . . . . . . 36
5.8.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 35 5.7.3. Handling of Idle Streams . . . . . . . . . . . . . . 36
5.8.1.1. Stream Errors Are Unrecoverable . . . . . . . . . 36 5.8. Stream Errors . . . . . . . . . . . . . . . . . . . . . 37
5.8.1.2. Stream Errors Can Occur During Setup . . . . . . 36 5.8.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 37
5.8.1.1. Stream Errors Are Unrecoverable . . . . . . . . . 37
5.8.1.2. Stream Errors Can Occur During Setup . . . . . . 38
5.8.1.3. Stream Errors When the Host is Unspecified or 5.8.1.3. Stream Errors When the Host is Unspecified or
Unknown . . . . . . . . . . . . . . . . . . . . . 37 Unknown . . . . . . . . . . . . . . . . . . . . . 38
5.8.1.4. Where Stream Errors Are Sent . . . . . . . . . . 38 5.8.1.4. Where Stream Errors Are Sent . . . . . . . . . . 39
5.8.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 38 5.8.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 39
5.8.3. Defined Stream Error Conditions . . . . . . . . . . 39 5.8.3. Defined Stream Error Conditions . . . . . . . . . . 40
5.8.3.1. bad-format . . . . . . . . . . . . . . . . . . . 39 5.8.3.1. bad-format . . . . . . . . . . . . . . . . . . . 40
5.8.3.2. bad-namespace-prefix . . . . . . . . . . . . . . 40 5.8.3.2. bad-namespace-prefix . . . . . . . . . . . . . . 41
5.8.3.3. conflict . . . . . . . . . . . . . . . . . . . . 41 5.8.3.3. conflict . . . . . . . . . . . . . . . . . . . . 42
5.8.3.4. connection-timeout . . . . . . . . . . . . . . . 41 5.8.3.4. connection-timeout . . . . . . . . . . . . . . . 42
5.8.3.5. host-gone . . . . . . . . . . . . . . . . . . . . 42 5.8.3.5. host-gone . . . . . . . . . . . . . . . . . . . . 43
5.8.3.6. host-unknown . . . . . . . . . . . . . . . . . . 42 5.8.3.6. host-unknown . . . . . . . . . . . . . . . . . . 43
5.8.3.7. improper-addressing . . . . . . . . . . . . . . . 43 5.8.3.7. improper-addressing . . . . . . . . . . . . . . . 44
5.8.3.8. internal-server-error . . . . . . . . . . . . . . 43 5.8.3.8. internal-server-error . . . . . . . . . . . . . . 44
5.8.3.9. invalid-from . . . . . . . . . . . . . . . . . . 44 5.8.3.9. invalid-from . . . . . . . . . . . . . . . . . . 45
5.8.3.10. invalid-id . . . . . . . . . . . . . . . . . . . 44 5.8.3.10. invalid-id . . . . . . . . . . . . . . . . . . . 45
5.8.3.11. invalid-namespace . . . . . . . . . . . . . . . . 45 5.8.3.11. invalid-namespace . . . . . . . . . . . . . . . . 46
5.8.3.12. invalid-xml . . . . . . . . . . . . . . . . . . . 45 5.8.3.12. invalid-xml . . . . . . . . . . . . . . . . . . . 46
5.8.3.13. not-authorized . . . . . . . . . . . . . . . . . 46 5.8.3.13. not-authorized . . . . . . . . . . . . . . . . . 47
5.8.3.14. policy-violation . . . . . . . . . . . . . . . . 47 5.8.3.14. policy-violation . . . . . . . . . . . . . . . . 48
5.8.3.15. remote-connection-failed . . . . . . . . . . . . 48 5.8.3.15. remote-connection-failed . . . . . . . . . . . . 49
5.8.3.16. resource-constraint . . . . . . . . . . . . . . . 48 5.8.3.16. resource-constraint . . . . . . . . . . . . . . . 49
5.8.3.17. restricted-xml . . . . . . . . . . . . . . . . . 49 5.8.3.17. restricted-xml . . . . . . . . . . . . . . . . . 50
5.8.3.18. see-other-host . . . . . . . . . . . . . . . . . 49 5.8.3.18. see-other-host . . . . . . . . . . . . . . . . . 50
5.8.3.19. system-shutdown . . . . . . . . . . . . . . . . . 50 5.8.3.19. system-shutdown . . . . . . . . . . . . . . . . . 51
5.8.3.20. undefined-condition . . . . . . . . . . . . . . . 51 5.8.3.20. undefined-condition . . . . . . . . . . . . . . . 52
5.8.3.21. unsupported-encoding . . . . . . . . . . . . . . 51 5.8.3.21. unsupported-encoding . . . . . . . . . . . . . . 52
5.8.3.22. unsupported-stanza-type . . . . . . . . . . . . . 52 5.8.3.22. unsupported-stanza-type . . . . . . . . . . . . . 53
5.8.3.23. unsupported-version . . . . . . . . . . . . . . . 52 5.8.3.23. unsupported-version . . . . . . . . . . . . . . . 53
5.8.3.24. xml-not-well-formed . . . . . . . . . . . . . . . 53 5.8.3.24. xml-not-well-formed . . . . . . . . . . . . . . . 54
5.8.4. Application-Specific Conditions . . . . . . . . . . 54 5.8.4. Application-Specific Conditions . . . . . . . . . . 55
5.9. Simplified Stream Examples . . . . . . . . . . . . . . . 54 5.9. Simplified Stream Examples . . . . . . . . . . . . . . . 55
6. STARTTLS Negotiation . . . . . . . . . . . . . . . . . . . . 56 6. STARTTLS Negotiation . . . . . . . . . . . . . . . . . . . . 57
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 57 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 58
6.2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . 57 6.2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.2.1. Data Formatting . . . . . . . . . . . . . . . . . . 57 6.2.1. Data Formatting . . . . . . . . . . . . . . . . . . 58
6.2.2. Order of Negotiation . . . . . . . . . . . . . . . . 57 6.2.2. Order of Negotiation . . . . . . . . . . . . . . . . 58
6.3. Process . . . . . . . . . . . . . . . . . . . . . . . . 58 6.3. Process . . . . . . . . . . . . . . . . . . . . . . . . 59
6.3.1. Exchange of Stream Headers and Stream Features . . . 58 6.3.1. Exchange of Stream Headers and Stream Features . . . 59
6.3.2. Initiation of STARTTLS Negotiation . . . . . . . . . 59 6.3.2. Initiation of STARTTLS Negotiation . . . . . . . . . 60
6.3.2.1. STARTTLS Command . . . . . . . . . . . . . . . . 59 6.3.2.1. STARTTLS Command . . . . . . . . . . . . . . . . 60
6.3.2.2. Failure Case . . . . . . . . . . . . . . . . . . 59 6.3.2.2. Failure Case . . . . . . . . . . . . . . . . . . 60
6.3.2.3. Proceed Case . . . . . . . . . . . . . . . . . . 60 6.3.2.3. Proceed Case . . . . . . . . . . . . . . . . . . 61
6.3.3. TLS Negotiation . . . . . . . . . . . . . . . . . . 60 6.3.3. TLS Negotiation . . . . . . . . . . . . . . . . . . 61
6.3.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . 60 6.3.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . 61
6.3.3.2. TLS Failure . . . . . . . . . . . . . . . . . . . 61 6.3.3.2. TLS Failure . . . . . . . . . . . . . . . . . . . 62
6.3.3.3. TLS Success . . . . . . . . . . . . . . . . . . . 61 6.3.3.3. TLS Success . . . . . . . . . . . . . . . . . . . 62
7. SASL Negotiation . . . . . . . . . . . . . . . . . . . . . . 62 7. SASL Negotiation . . . . . . . . . . . . . . . . . . . . . . 63
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 62 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 63
7.2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . 62 7.2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . 63
7.2.1. Mechanism Preferences . . . . . . . . . . . . . . . 62 7.2.1. Mechanism Preferences . . . . . . . . . . . . . . . 63
7.2.2. Mechanism Offers . . . . . . . . . . . . . . . . . . 63 7.2.2. Mechanism Offers . . . . . . . . . . . . . . . . . . 64
7.2.3. Data Formatting . . . . . . . . . . . . . . . . . . 63 7.2.3. Data Formatting . . . . . . . . . . . . . . . . . . 64
7.2.4. Security Layers . . . . . . . . . . . . . . . . . . 64 7.2.4. Security Layers . . . . . . . . . . . . . . . . . . 65
7.2.5. Simple Usernames . . . . . . . . . . . . . . . . . . 64 7.2.5. Simple Usernames . . . . . . . . . . . . . . . . . . 65
7.2.6. Authorization Identities . . . . . . . . . . . . . . 64 7.2.6. Authorization Identities . . . . . . . . . . . . . . 65
7.2.7. Realms . . . . . . . . . . . . . . . . . . . . . . . 65 7.2.7. Realms . . . . . . . . . . . . . . . . . . . . . . . 66
7.2.8. Round Trips . . . . . . . . . . . . . . . . . . . . 65 7.2.8. Round Trips . . . . . . . . . . . . . . . . . . . . 66
7.3. Process . . . . . . . . . . . . . . . . . . . . . . . . 65 7.3. Process . . . . . . . . . . . . . . . . . . . . . . . . 66
7.3.1. Exchange of Stream Headers and Stream Features . . . 65 7.3.1. Exchange of Stream Headers and Stream Features . . . 66
7.3.2. Initiation . . . . . . . . . . . . . . . . . . . . . 67 7.3.2. Initiation . . . . . . . . . . . . . . . . . . . . . 68
7.3.3. Challenge-Response Sequence . . . . . . . . . . . . 67 7.3.3. Challenge-Response Sequence . . . . . . . . . . . . 68
7.3.4. Abort . . . . . . . . . . . . . . . . . . . . . . . 68 7.3.4. Abort . . . . . . . . . . . . . . . . . . . . . . . 69
7.3.5. Failure . . . . . . . . . . . . . . . . . . . . . . 68 7.3.5. Failure . . . . . . . . . . . . . . . . . . . . . . 69
7.3.6. Success . . . . . . . . . . . . . . . . . . . . . . 69 7.3.6. Success . . . . . . . . . . . . . . . . . . . . . . 70
7.4. SASL Errors . . . . . . . . . . . . . . . . . . . . . . 70 7.4. SASL Errors . . . . . . . . . . . . . . . . . . . . . . 71
7.4.1. aborted . . . . . . . . . . . . . . . . . . . . . . 71 7.4.1. aborted . . . . . . . . . . . . . . . . . . . . . . 72
7.4.2. account-disabled . . . . . . . . . . . . . . . . . . 71 7.4.2. account-disabled . . . . . . . . . . . . . . . . . . 72
7.4.3. credentials-expired . . . . . . . . . . . . . . . . 71 7.4.3. credentials-expired . . . . . . . . . . . . . . . . 72
7.4.4. encryption-required . . . . . . . . . . . . . . . . 71 7.4.4. encryption-required . . . . . . . . . . . . . . . . 72
7.4.5. incorrect-encoding . . . . . . . . . . . . . . . . . 72 7.4.5. incorrect-encoding . . . . . . . . . . . . . . . . . 73
7.4.6. invalid-authzid . . . . . . . . . . . . . . . . . . 72 7.4.6. invalid-authzid . . . . . . . . . . . . . . . . . . 73
7.4.7. invalid-mechanism . . . . . . . . . . . . . . . . . 72 7.4.7. invalid-mechanism . . . . . . . . . . . . . . . . . 73
7.4.8. malformed-request . . . . . . . . . . . . . . . . . 73 7.4.8. malformed-request . . . . . . . . . . . . . . . . . 74
7.4.9. mechanism-too-weak . . . . . . . . . . . . . . . . . 73 7.4.9. mechanism-too-weak . . . . . . . . . . . . . . . . . 74
7.4.10. not-authorized . . . . . . . . . . . . . . . . . . . 73 7.4.10. not-authorized . . . . . . . . . . . . . . . . . . . 74
7.4.11. temporary-auth-failure . . . . . . . . . . . . . . . 74 7.4.11. temporary-auth-failure . . . . . . . . . . . . . . . 75
7.4.12. transition-needed . . . . . . . . . . . . . . . . . 74 7.4.12. transition-needed . . . . . . . . . . . . . . . . . 75
7.5. SASL Definition . . . . . . . . . . . . . . . . . . . . 74 7.5. SASL Definition . . . . . . . . . . . . . . . . . . . . 75
8. Resource Binding . . . . . . . . . . . . . . . . . . . . . . 75 8. Resource Binding . . . . . . . . . . . . . . . . . . . . . . 76
8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 75 8.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 76
8.2. Advertising Support . . . . . . . . . . . . . . . . . . 76 8.2. Advertising Support . . . . . . . . . . . . . . . . . . 77
8.3. Generation of Resource Identifiers . . . . . . . . . . . 77 8.3. Generation of Resource Identifiers . . . . . . . . . . . 78
8.4. Server-Generated Resource Identifier . . . . . . . . . . 77 8.4. Server-Generated Resource Identifier . . . . . . . . . . 78
8.4.1. Success Case . . . . . . . . . . . . . . . . . . . . 77 8.4.1. Success Case . . . . . . . . . . . . . . . . . . . . 78
8.4.2. Error Cases . . . . . . . . . . . . . . . . . . . . 78 8.4.2. Error Cases . . . . . . . . . . . . . . . . . . . . 79
8.4.2.1. Resource Constraint . . . . . . . . . . . . . . . 78 8.4.2.1. Resource Constraint . . . . . . . . . . . . . . . 79
8.4.2.2. Not Allowed . . . . . . . . . . . . . . . . . . . 78 8.4.2.2. Not Allowed . . . . . . . . . . . . . . . . . . . 79
8.5. Client-Submitted Resource Identifier . . . . . . . . . . 78 8.5. Client-Submitted Resource Identifier . . . . . . . . . . 79
8.5.1. Success Case . . . . . . . . . . . . . . . . . . . . 78 8.5.1. Success Case . . . . . . . . . . . . . . . . . . . . 79
8.5.2. Error Cases . . . . . . . . . . . . . . . . . . . . 79 8.5.2. Error Cases . . . . . . . . . . . . . . . . . . . . 80
8.5.2.1. Bad Request . . . . . . . . . . . . . . . . . . . 79 8.5.2.1. Bad Request . . . . . . . . . . . . . . . . . . . 80
8.5.2.2. Conflict . . . . . . . . . . . . . . . . . . . . 79 8.5.2.2. Conflict . . . . . . . . . . . . . . . . . . . . 80
8.5.3. Retries . . . . . . . . . . . . . . . . . . . . . . 80 8.5.3. Retries . . . . . . . . . . . . . . . . . . . . . . 81
9. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 81 9. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 82
9.1. Common Attributes . . . . . . . . . . . . . . . . . . . 81 9.1. Common Attributes . . . . . . . . . . . . . . . . . . . 82
9.1.1. to . . . . . . . . . . . . . . . . . . . . . . . . . 81 9.1.1. to . . . . . . . . . . . . . . . . . . . . . . . . . 82
9.1.1.1. Client-to-Server Streams . . . . . . . . . . . . 81 9.1.1.1. Client-to-Server Streams . . . . . . . . . . . . 82
9.1.1.2. Server-to-Server Streams . . . . . . . . . . . . 82 9.1.1.2. Server-to-Server Streams . . . . . . . . . . . . 83
9.1.2. from . . . . . . . . . . . . . . . . . . . . . . . . 82 9.1.2. from . . . . . . . . . . . . . . . . . . . . . . . . 83
9.1.2.1. Client-to-Server Streams . . . . . . . . . . . . 82 9.1.2.1. Client-to-Server Streams . . . . . . . . . . . . 83
9.1.2.2. Server-to-Server Streams . . . . . . . . . . . . 83 9.1.2.2. Server-to-Server Streams . . . . . . . . . . . . 84
9.1.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 83 9.1.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 84
9.1.4. type . . . . . . . . . . . . . . . . . . . . . . . . 84 9.1.4. type . . . . . . . . . . . . . . . . . . . . . . . . 85
9.1.5. xml:lang . . . . . . . . . . . . . . . . . . . . . . 84 9.1.5. xml:lang . . . . . . . . . . . . . . . . . . . . . . 85
9.2. Basic Semantics . . . . . . . . . . . . . . . . . . . . 85 9.2. Basic Semantics . . . . . . . . . . . . . . . . . . . . 86
9.2.1. Message Semantics . . . . . . . . . . . . . . . . . 85 9.2.1. Message Semantics . . . . . . . . . . . . . . . . . 86
9.2.2. Presence Semantics . . . . . . . . . . . . . . . . . 85 9.2.2. Presence Semantics . . . . . . . . . . . . . . . . . 86
9.2.3. IQ Semantics . . . . . . . . . . . . . . . . . . . . 86 9.2.3. IQ Semantics . . . . . . . . . . . . . . . . . . . . 87
9.3. Stanza Errors . . . . . . . . . . . . . . . . . . . . . 87 9.3. Stanza Errors . . . . . . . . . . . . . . . . . . . . . 88
9.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 88 9.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 89
9.3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 88 9.3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 89
9.3.3. Defined Conditions . . . . . . . . . . . . . . . . . 89 9.3.3. Defined Conditions . . . . . . . . . . . . . . . . . 90
9.3.3.1. bad-request . . . . . . . . . . . . . . . . . . . 89 9.3.3.1. bad-request . . . . . . . . . . . . . . . . . . . 90
9.3.3.2. conflict . . . . . . . . . . . . . . . . . . . . 90 9.3.3.2. conflict . . . . . . . . . . . . . . . . . . . . 91
9.3.3.3. feature-not-implemented . . . . . . . . . . . . . 90 9.3.3.3. feature-not-implemented . . . . . . . . . . . . . 91
9.3.3.4. forbidden . . . . . . . . . . . . . . . . . . . . 91 9.3.3.4. forbidden . . . . . . . . . . . . . . . . . . . . 92
9.3.3.5. gone . . . . . . . . . . . . . . . . . . . . . . 91 9.3.3.5. gone . . . . . . . . . . . . . . . . . . . . . . 92
9.3.3.6. internal-server-error . . . . . . . . . . . . . . 92 9.3.3.6. internal-server-error . . . . . . . . . . . . . . 93
9.3.3.7. item-not-found . . . . . . . . . . . . . . . . . 92 9.3.3.7. item-not-found . . . . . . . . . . . . . . . . . 93
9.3.3.8. jid-malformed . . . . . . . . . . . . . . . . . . 93 9.3.3.8. jid-malformed . . . . . . . . . . . . . . . . . . 94
9.3.3.9. not-acceptable . . . . . . . . . . . . . . . . . 93 9.3.3.9. not-acceptable . . . . . . . . . . . . . . . . . 94
9.3.3.10. not-allowed . . . . . . . . . . . . . . . . . . . 94 9.3.3.10. not-allowed . . . . . . . . . . . . . . . . . . . 95
9.3.3.11. not-authorized . . . . . . . . . . . . . . . . . 94 9.3.3.11. not-authorized . . . . . . . . . . . . . . . . . 95
9.3.3.12. not-modified . . . . . . . . . . . . . . . . . . 95 9.3.3.12. not-modified . . . . . . . . . . . . . . . . . . 96
9.3.3.13. payment-required . . . . . . . . . . . . . . . . 96 9.3.3.13. payment-required . . . . . . . . . . . . . . . . 97
9.3.3.14. policy-violation . . . . . . . . . . . . . . . . 96 9.3.3.14. policy-violation . . . . . . . . . . . . . . . . 97
9.3.3.15. recipient-unavailable . . . . . . . . . . . . . . 97 9.3.3.15. recipient-unavailable . . . . . . . . . . . . . . 98
9.3.3.16. redirect . . . . . . . . . . . . . . . . . . . . 97 9.3.3.16. redirect . . . . . . . . . . . . . . . . . . . . 98
9.3.3.17. registration-required . . . . . . . . . . . . . . 98 9.3.3.17. registration-required . . . . . . . . . . . . . . 99
9.3.3.18. remote-server-not-found . . . . . . . . . . . . . 98 9.3.3.18. remote-server-not-found . . . . . . . . . . . . . 99
9.3.3.19. remote-server-timeout . . . . . . . . . . . . . . 99 9.3.3.19. remote-server-timeout . . . . . . . . . . . . . . 100
9.3.3.20. resource-constraint . . . . . . . . . . . . . . . 99 9.3.3.20. resource-constraint . . . . . . . . . . . . . . . 100
9.3.3.21. service-unavailable . . . . . . . . . . . . . . . 100 9.3.3.21. service-unavailable . . . . . . . . . . . . . . . 101
9.3.3.22. subscription-required . . . . . . . . . . . . . . 100 9.3.3.22. subscription-required . . . . . . . . . . . . . . 101
9.3.3.23. undefined-condition . . . . . . . . . . . . . . . 101 9.3.3.23. undefined-condition . . . . . . . . . . . . . . . 102
9.3.3.24. unexpected-request . . . . . . . . . . . . . . . 102 9.3.3.24. unexpected-request . . . . . . . . . . . . . . . 103
9.3.4. Application-Specific Conditions . . . . . . . . . . 103 9.3.4. Application-Specific Conditions . . . . . . . . . . 104
9.4. Extended Content . . . . . . . . . . . . . . . . . . . . 104 9.4. Extended Content . . . . . . . . . . . . . . . . . . . . 105
9.5. Stanza Size . . . . . . . . . . . . . . . . . . . . . . 105 9.5. Stanza Size . . . . . . . . . . . . . . . . . . . . . . 106
10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 106 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 107
10.1. Client-to-Server . . . . . . . . . . . . . . . . . . . . 106 10.1. Client-to-Server . . . . . . . . . . . . . . . . . . . . 107
10.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 106 10.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 107
10.1.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 108 10.1.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 109
10.1.3. Resource Binding . . . . . . . . . . . . . . . . . . 109 10.1.3. Resource Binding . . . . . . . . . . . . . . . . . . 110
10.1.4. Stanza Exchange . . . . . . . . . . . . . . . . . . 109 10.1.4. Stanza Exchange . . . . . . . . . . . . . . . . . . 110
10.1.5. Close . . . . . . . . . . . . . . . . . . . . . . . 110 10.1.5. Close . . . . . . . . . . . . . . . . . . . . . . . 111
10.2. Server-to-Server Examples . . . . . . . . . . . . . . . 110 10.2. Server-to-Server Examples . . . . . . . . . . . . . . . 111
10.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 111 10.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 112
10.2.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 112 10.2.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 113
10.2.3. Stanza Exchange . . . . . . . . . . . . . . . . . . 113 10.2.3. Stanza Exchange . . . . . . . . . . . . . . . . . . 114
10.2.4. Close . . . . . . . . . . . . . . . . . . . . . . . 114 10.2.4. Close . . . . . . . . . . . . . . . . . . . . . . . 115
11. Server Rules for Processing XML Stanzas . . . . . . . . . . . 114 11. Server Rules for Processing XML Stanzas . . . . . . . . . . . 115
11.1. No 'to' Address . . . . . . . . . . . . . . . . . . . . 115 11.1. No 'to' Address . . . . . . . . . . . . . . . . . . . . 116
11.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 115 11.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 116
11.1.2. Message . . . . . . . . . . . . . . . . . . . . . . 115 11.1.2. Message . . . . . . . . . . . . . . . . . . . . . . 116
11.1.3. Presence . . . . . . . . . . . . . . . . . . . . . . 115 11.1.3. Presence . . . . . . . . . . . . . . . . . . . . . . 116
11.1.4. IQ . . . . . . . . . . . . . . . . . . . . . . . . . 115 11.1.4. IQ . . . . . . . . . . . . . . . . . . . . . . . . . 116
11.2. Local Domain . . . . . . . . . . . . . . . . . . . . . . 116 11.2. Local Domain . . . . . . . . . . . . . . . . . . . . . . 117
11.2.1. Mere Domain . . . . . . . . . . . . . . . . . . . . 116 11.2.1. Mere Domain . . . . . . . . . . . . . . . . . . . . 117
11.2.2. Domain with Resource . . . . . . . . . . . . . . . . 116 11.2.2. Domain with Resource . . . . . . . . . . . . . . . . 117
11.2.3. Localpart at Domain . . . . . . . . . . . . . . . . 116 11.2.3. Localpart at Domain . . . . . . . . . . . . . . . . 117
11.2.3.1. No Such User . . . . . . . . . . . . . . . . . . 116 11.2.3.1. No Such User . . . . . . . . . . . . . . . . . . 117
11.2.3.2. Bare JID . . . . . . . . . . . . . . . . . . . . 117 11.2.3.2. Bare JID . . . . . . . . . . . . . . . . . . . . 118
11.2.3.3. Full JID . . . . . . . . . . . . . . . . . . . . 117 11.2.3.3. Full JID . . . . . . . . . . . . . . . . . . . . 118
11.3. Foreign Domain . . . . . . . . . . . . . . . . . . . . . 117 11.3. Remote Domain . . . . . . . . . . . . . . . . . . . . . 118
11.3.1. Existing Stream . . . . . . . . . . . . . . . . . . 117 11.3.1. Existing Stream . . . . . . . . . . . . . . . . . . 118
11.3.2. No Existing Stream . . . . . . . . . . . . . . . . . 118 11.3.2. No Existing Stream . . . . . . . . . . . . . . . . . 119
11.3.3. Error Handling . . . . . . . . . . . . . . . . . . . 118 11.3.3. Error Handling . . . . . . . . . . . . . . . . . . . 119
12. XML Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 118 12. XML Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 119
12.1. Restrictions . . . . . . . . . . . . . . . . . . . . . . 118 12.1. Restrictions . . . . . . . . . . . . . . . . . . . . . . 119
12.2. XML Namespace Names and Prefixes . . . . . . . . . . . . 119 12.2. XML Namespace Names and Prefixes . . . . . . . . . . . . 120
12.2.1. Streams Namespace . . . . . . . . . . . . . . . . . 119 12.2.1. Streams Namespace . . . . . . . . . . . . . . . . . 120
12.2.2. Default Namespace . . . . . . . . . . . . . . . . . 120 12.2.2. Default Namespace . . . . . . . . . . . . . . . . . 121
12.2.3. Extended Namespaces . . . . . . . . . . . . . . . . 121 12.2.3. Extended Namespaces . . . . . . . . . . . . . . . . 122
12.3. Well-Formedness . . . . . . . . . . . . . . . . . . . . 122 12.3. Well-Formedness . . . . . . . . . . . . . . . . . . . . 123
12.4. Validation . . . . . . . . . . . . . . . . . . . . . . . 122 12.4. Validation . . . . . . . . . . . . . . . . . . . . . . . 123
12.5. Inclusion of Text Declaration . . . . . . . . . . . . . 123 12.5. Inclusion of XML Declaration . . . . . . . . . . . . . . 124
12.6. Character Encoding . . . . . . . . . . . . . . . . . . . 123 12.6. Character Encoding . . . . . . . . . . . . . . . . . . . 124
12.7. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 123 12.7. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 124
12.8. XML Versions . . . . . . . . . . . . . . . . . . . . . . 123 12.8. XML Versions . . . . . . . . . . . . . . . . . . . . . . 124
13. Compliance Requirements . . . . . . . . . . . . . . . . . . . 123 13. Compliance Requirements . . . . . . . . . . . . . . . . . . . 124
13.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . 124 13.1. Servers . . . . . . . . . . . . . . . . . . . . . . . . 125
13.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . 124 13.2. Clients . . . . . . . . . . . . . . . . . . . . . . . . 125
14. Internationalization Considerations . . . . . . . . . . . . . 125 14. Internationalization Considerations . . . . . . . . . . . . . 126
15. Security Considerations . . . . . . . . . . . . . . . . . . . 125 15. Security Considerations . . . . . . . . . . . . . . . . . . . 126
15.1. High Security . . . . . . . . . . . . . . . . . . . . . 125 15.1. High Security . . . . . . . . . . . . . . . . . . . . . 126
15.2. Certificates . . . . . . . . . . . . . . . . . . . . . . 126 15.2. Certificates . . . . . . . . . . . . . . . . . . . . . . 127
15.2.1. Certificate Generation . . . . . . . . . . . . . . . 126 15.2.1. Certificate Generation . . . . . . . . . . . . . . . 127
15.2.1.1. Server Certificates . . . . . . . . . . . . . . . 126 15.2.1.1. Server Certificates . . . . . . . . . . . . . . . 127
15.2.1.2. Client Certificates . . . . . . . . . . . . . . . 128 15.2.1.2. Client Certificates . . . . . . . . . . . . . . . 129
15.2.1.3. ASN.1 Object Identifier . . . . . . . . . . . . . 128 15.2.1.3. ASN.1 Object Identifier . . . . . . . . . . . . . 129
15.2.2. Certificate Validation . . . . . . . . . . . . . . . 129 15.2.2. Certificate Validation . . . . . . . . . . . . . . . 130
15.2.2.1. Server Certificates . . . . . . . . . . . . . . . 129 15.2.2.1. Server Certificates . . . . . . . . . . . . . . . 130
15.2.2.2. Client Certificates . . . . . . . . . . . . . . . 131 15.2.2.2. Client Certificates . . . . . . . . . . . . . . . 132
15.2.2.3. Use of Certificates in XMPP Extensions . . . . . 132 15.2.2.3. Use of Certificates in XMPP Extensions . . . . . 133
15.3. Client-to-Server Communication . . . . . . . . . . . . . 132 15.3. Client-to-Server Communication . . . . . . . . . . . . . 133
15.4. Server-to-Server Communication . . . . . . . . . . . . . 133 15.4. Server-to-Server Communication . . . . . . . . . . . . . 134
15.5. Order of Layers . . . . . . . . . . . . . . . . . . . . 133 15.5. Order of Layers . . . . . . . . . . . . . . . . . . . . 134
15.6. Mandatory-to-Implement Technologies . . . . . . . . . . 133 15.6. Mandatory-to-Implement Technologies . . . . . . . . . . 134
15.7. Hash Function Agility . . . . . . . . . . . . . . . . . 134 15.7. Hash Function Agility . . . . . . . . . . . . . . . . . 135
15.8. SASL Downgrade Attacks . . . . . . . . . . . . . . . . . 134 15.8. SASL Downgrade Attacks . . . . . . . . . . . . . . . . . 135
15.9. Lack of SASL Channel Binding to TLS . . . . . . . . . . 134 15.9. Lack of SASL Channel Binding to TLS . . . . . . . . . . 135
15.10. Use of base64 in SASL . . . . . . . . . . . . . . . . . 135 15.10. Use of base64 in SASL . . . . . . . . . . . . . . . . . 136
15.11. Stringprep Profiles . . . . . . . . . . . . . . . . . . 135 15.11. Stringprep Profiles . . . . . . . . . . . . . . . . . . 136
15.12. Address Spoofing . . . . . . . . . . . . . . . . . . . . 136 15.12. Address Spoofing . . . . . . . . . . . . . . . . . . . . 137
15.12.1. Address Forging . . . . . . . . . . . . . . . . . . 136 15.12.1. Address Forging . . . . . . . . . . . . . . . . . . 137
15.12.2. Address Mimicking . . . . . . . . . . . . . . . . . 137 15.12.2. Address Mimicking . . . . . . . . . . . . . . . . . 138
15.13. Firewalls . . . . . . . . . . . . . . . . . . . . . . . 138 15.13. Firewalls . . . . . . . . . . . . . . . . . . . . . . . 139
15.14. Denial of Service . . . . . . . . . . . . . . . . . . . 138 15.14. Denial of Service . . . . . . . . . . . . . . . . . . . 139
15.15. Presence Leaks . . . . . . . . . . . . . . . . . . . . . 139 15.15. Presence Leaks . . . . . . . . . . . . . . . . . . . . . 140
15.16. Directory Harvesting . . . . . . . . . . . . . . . . . . 140 15.16. Directory Harvesting . . . . . . . . . . . . . . . . . . 141
16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 140 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 141
16.1. XML Namespace Name for TLS Data . . . . . . . . . . . . 140 16.1. XML Namespace Name for TLS Data . . . . . . . . . . . . 141
16.2. XML Namespace Name for SASL Data . . . . . . . . . . . . 140 16.2. XML Namespace Name for SASL Data . . . . . . . . . . . . 141
16.3. XML Namespace Name for Stream Errors . . . . . . . . . . 141 16.3. XML Namespace Name for Stream Errors . . . . . . . . . . 142
16.4. XML Namespace Name for Resource Binding . . . . . . . . 141 16.4. XML Namespace Name for Resource Binding . . . . . . . . 142
16.5. XML Namespace Name for Stanza Errors . . . . . . . . . . 141 16.5. XML Namespace Name for Stanza Errors . . . . . . . . . . 142
16.6. Nodeprep Profile of Stringprep . . . . . . . . . . . . . 142 16.6. Nodeprep Profile of Stringprep . . . . . . . . . . . . . 143
16.7. Resourceprep Profile of Stringprep . . . . . . . . . . . 142 16.7. Resourceprep Profile of Stringprep . . . . . . . . . . . 143
16.8. GSSAPI Service Name . . . . . . . . . . . . . . . . . . 142 16.8. GSSAPI Service Name . . . . . . . . . . . . . . . . . . 143
16.9. Port Numbers . . . . . . . . . . . . . . . . . . . . . . 142 16.9. Port Numbers . . . . . . . . . . . . . . . . . . . . . . 143
17. References . . . . . . . . . . . . . . . . . . . . . . . . . 143 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 144
17.1. Normative References . . . . . . . . . . . . . . . . . . 143 17.1. Normative References . . . . . . . . . . . . . . . . . . 144
17.2. Informative References . . . . . . . . . . . . . . . . . 145 17.2. Informative References . . . . . . . . . . . . . . . . . 146
Appendix A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . 149
A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 149 Appendix A. Nodeprep . . . . . . . . . . . . . . . . . . . . . . 150
A.2. Character Repertoire . . . . . . . . . . . . . . . . . . 149 A.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 150
A.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . 150 A.2. Character Repertoire . . . . . . . . . . . . . . . . . . 151
A.4. Normalization . . . . . . . . . . . . . . . . . . . . . 150 A.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . 151
A.5. Prohibited Output . . . . . . . . . . . . . . . . . . . 150 A.4. Normalization . . . . . . . . . . . . . . . . . . . . . 151
A.6. Bidirectional Characters . . . . . . . . . . . . . . . . 150 A.5. Prohibited Output . . . . . . . . . . . . . . . . . . . 151
A.7. Notes . . . . . . . . . . . . . . . . . . . . . . . . . 151 A.6. Bidirectional Characters . . . . . . . . . . . . . . . . 152
Appendix B. Resourceprep . . . . . . . . . . . . . . . . . . . . 151 A.7. Notes . . . . . . . . . . . . . . . . . . . . . . . . . 152
B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 151 Appendix B. Resourceprep . . . . . . . . . . . . . . . . . . . . 152
B.2. Character Repertoire . . . . . . . . . . . . . . . . . . 152 B.1. Introduction . . . . . . . . . . . . . . . . . . . . . . 153
B.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . 152 B.2. Character Repertoire . . . . . . . . . . . . . . . . . . 153
B.4. Normalization . . . . . . . . . . . . . . . . . . . . . 152 B.3. Mapping . . . . . . . . . . . . . . . . . . . . . . . . 153
B.5. Prohibited Output . . . . . . . . . . . . . . . . . . . 152 B.4. Normalization . . . . . . . . . . . . . . . . . . . . . 153
B.6. Bidirectional Characters . . . . . . . . . . . . . . . . 152 B.5. Prohibited Output . . . . . . . . . . . . . . . . . . . 153
Appendix C. XML Schemas . . . . . . . . . . . . . . . . . . . . 153 B.6. Bidirectional Characters . . . . . . . . . . . . . . . . 154
C.1. Streams Namespace . . . . . . . . . . . . . . . . . . . 153 Appendix C. XML Schemas . . . . . . . . . . . . . . . . . . . . 154
C.2. Stream Error Namespace . . . . . . . . . . . . . . . . . 154 C.1. Streams Namespace . . . . . . . . . . . . . . . . . . . 154
C.3. STARTTLS Namespace . . . . . . . . . . . . . . . . . . . 157 C.2. Stream Error Namespace . . . . . . . . . . . . . . . . . 156
C.4. SASL Namespace . . . . . . . . . . . . . . . . . . . . . 157 C.3. STARTTLS Namespace . . . . . . . . . . . . . . . . . . . 158
C.5. Resource Binding Namespace . . . . . . . . . . . . . . . 160 C.4. SASL Namespace . . . . . . . . . . . . . . . . . . . . . 158
C.6. Stanza Error Namespace . . . . . . . . . . . . . . . . . 160 C.5. Resource Binding Namespace . . . . . . . . . . . . . . . 161
Appendix D. Contact Addresses . . . . . . . . . . . . . . . . . 162 C.6. Stanza Error Namespace . . . . . . . . . . . . . . . . . 161
Appendix E. Account Provisioning . . . . . . . . . . . . . . . . 162 Appendix D. Contact Addresses . . . . . . . . . . . . . . . . . 163
Appendix F. Differences From RFC 3920 . . . . . . . . . . . . . 163 Appendix E. Account Provisioning . . . . . . . . . . . . . . . . 163
Appendix G. Copying Conditions . . . . . . . . . . . . . . . . . 164 Appendix F. Differences From RFC 3920 . . . . . . . . . . . . . 164
Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164 Appendix G. Copying Conditions . . . . . . . . . . . . . . . . . 165
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 165 Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 166
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] for application profile of the Extensible Markup Language [XML] for
streaming XML data in close to real time between any two (or more) streaming XML data in close to real time between any two (or more)
network-aware entities. XMPP is typically used to exchange messages, network-aware entities. XMPP is typically used to exchange messages,
share presence information, and engage in structured request-response share presence information, and engage in structured request-response
skipping to change at page 10, line 5 skipping to change at page 10, line 5
o Added the TLS plus the SASL PLAIN mechanism [PLAIN] as a o Added the TLS plus the SASL PLAIN mechanism [PLAIN] as a
mandatory-to-implement technology mandatory-to-implement technology
o Defined of optional support for multiple resources over the same o Defined of optional support for multiple resources over the same
connection connection
o Transferred historical documentation for the server dialback o Transferred historical documentation for the server dialback
protocol from this specification to a separate specification protocol from this specification to a separate specification
Therefore, this document defines the core features of XMPP 1.0, thus Therefore, this document defines the core features of XMPP 1.0, thus
obsoleting RFC 3920. obsoleting RFC 3920.
Note: [xmpp-im] defines the XMPP features needed to provide the Note: [XMPP-IM] defines the XMPP features needed to provide the
basic instant messaging and presence functionality that is basic instant messaging and presence functionality that is
described in [IMP-REQS]. described in [IMP-REQS].
1.2. Functional Summary 1.2. Functional Summary
This non-normative section provides a developer-friendly, functional This non-normative section provides a developer-friendly, functional
summary of XMPP; refer to the sections that follow for a normative summary of XMPP; refer to the sections that follow for a normative
definition of XMPP. definition of XMPP.
The purpose of XMPP is to enable the exchange of relatively small The purpose of XMPP is to enable the exchange of relatively small
skipping to change at page 11, line 19 skipping to change at page 11, line 19
certificate presented by the peer server during TLS negotiation is certificate presented by the peer server during TLS negotiation is
self-signed and thus provides only weak identity); for details, self-signed and thus provides only weak identity); for details,
see [XEP-0220]. see [XEP-0220].
In the sections following discussion of XMPP architecture and XMPP In the sections following discussion of XMPP architecture and XMPP
addresses, this document specifies how clients connect to servers and addresses, this document specifies how clients connect to servers and
specifies the basic semantics of XML stanzas. However, this document specifies the basic semantics of XML stanzas. However, this document
does not define the "payloads" of the XML stanzas that might be does not define the "payloads" of the XML stanzas that might be
exchanged once a connection is successfully established; instead, exchanged once a connection is successfully established; instead,
those payloads are defined by various XMPP extensions. For example, those payloads are defined by various XMPP extensions. For example,
[xmpp-im] defines extensions for basic instant messaging and presence [XMPP-IM] defines extensions for basic instant messaging and presence
functionality. In addition, various specifications produced in the functionality. In addition, various specifications produced in the
XSF's XEP series [XEP-0001] define extensions for a wide range of XSF's XEP series [XEP-0001] define extensions for a wide range of
more advanced functionality. more advanced functionality.
1.3. Conventions 1.3. Conventions
The following capitalized keywords are to be interpreted as described The following capitalized keywords are to be interpreted as described
in [TERMS]: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; in [TERMS]: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT";
"SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY",
"OPTIONAL". "OPTIONAL".
skipping to change at page 12, line 33 skipping to change at page 12, line 33
have who have provided implementation feedback, bug reports, requests have who have provided implementation feedback, bug reports, requests
for clarification, and suggestions for improvement since the for clarification, and suggestions for improvement since the
publication of the RFC this document supersedes. The editor has publication of the RFC this document supersedes. The editor has
endeavored to address all such feedback, but is solely responsible endeavored to address all such feedback, but is solely responsible
for any remaining errors and ambiguities. for any remaining errors and ambiguities.
1.5. Discussion Venue 1.5. Discussion Venue
The document editor and the broader XMPP developer community welcome The document editor and the broader XMPP developer community welcome
discussion and comments related to the topics presented in this discussion and comments related to the topics presented in this
document. The preferred forum is the <standards@xmpp.org> mailing document. The primary and preferred venue is the <xmpp@ietf.org>
list, for which archives and subscription information are available mailing list, for which archives and subscription information are
at <http://mail.jabber.org/mailman/listinfo/standards>. available at <https://www.ietf.org/mailman/listinfo/xmpp>. Related
discussions often occur on the <standards@xmpp.org> mailing list, for
which archives and subscription information are available at
<http://mail.jabber.org/mailman/listinfo/standards>.
2. Architecture 2. Architecture
2.1. Overview XMPP provides a technology for the asynchronous, end-to-end exchange
of structured data by means of direct, persistent XML streams among a
distributed network of globally-addressable, presence-aware clients
and servers. Because this architectural style involves ubiquitous
knowledge of network availability and a conceptually unlimited number
of concurrent information transactions in the context of a given
client-to-server or server-to-server session, we label it
"Availability for Concurrent Transactions" (ACT) to distinguish it
from the "Representational State Transfer" [REST] architectural style
familiar from the World Wide Web. Although the architecture of XMPP
is similar in important ways to that of email (see [EMAIL-ARCH]), it
introduces several modifications to facilitate communication in close
to real time. The salient features of this ACTive architectural
style are as follows.
XMPP assumes a client-server architecture, wherein a client utilizing 2.1. Global Addresses
XMPP accesses a server (normally over a [TCP] connection) and servers
can also communicate with each other over TCP connections.
A simplified architectural diagram for a typical deployment is shown As with email, XMPP uses globally-unique addresses (based on the
here, where the entities have the following significance: Domain Name System) in order to route and deliver messages over the
network. All XMPP entities are addressable on the network, most
particularly clients and servers but also various additional services
that can be accessed by clients and servers. In general, server
addresses are of the form "domain.tld" (e.g., "im.example.com"),
accounts hosted at a server are of the form "localpart@domain.tld"
(e.g., "juliet@im.example.com"), and a particular connected device or
resource that is currently authorized for interaction on behalf of an
account is of the form "localpart@domain.tld/resource" (e.g.,
"juliet@im.example.com/balcony"). XMPP addresses are defined under
Section 3.
o romeo@example.net -- an XMPP user. 2.2. Presence
o example.net -- an XMPP server.
o im.example.com -- an XMPP server. XMPP includes the ability for an entity to advertise its network
o juliet@im.example.com -- an XMPP user. availability or "presence" to other entities. Such availability for
communication is signalled end-to-end via dedicated communication
primitives in XMPP (the <presence/> stanza). Although knowledge of
network availability is not strictly necessary for the exchange of
XMPP messages, it facilitates real-time interaction because the
originator of a message can know before initiating communication that
the intended recipient is online and available. XMPP presence is
defined in [XMPP-IM].
2.3. Persistent Streams
Availability for communication is also built into point-to-point
connections (e.g., a discrete client-to-server or server-to-server
connection) through the use of direct, persistent XML streams between
the entity that initiated the connection (either a client or a
server) and the entity that received the connection (a server). Thus
either party to a stream knows that it can immediately push data to
the other party for immediate routing or delivery. XML streams are
defined under Section 5.
2.4. Structured Data
The basic unit of meaning in XMPP is not an XML stream (which simply
provides the transport for point-to-point communication) but an XML
"stanza", which is essentially a fragment of XML that is sent over a
stream. The root element of a stanza includes routing attributes
(such as "from" and "to" addresses) and the child elements of the
stanza contain a payload for delivery to the intended recipient. XML
stanzas are defined under Section 9.
2.5. Distributed Network
In practice, XMPP consists of a network of clients and servers that
inter-communicate (however, communication between any two given
deployed servers is strictly OPTIONAL). Thus, for example, the user
<juliet@im.example.com> associated with the server <im.example.com>
might be able to exchange messages, presence, and other structured
data with the user <romeo@example.net> associated with the server
<example.net>. This pattern is familiar from messaging protocols
that make use of global addresses, such as the email network (see
[SMTP] and [EMAIL-ARCH]). As a result, end-to-end communication in
XMPP is logically peer-to-peer but physically client-to-server-to-
server-to-client, as illustrated in the following diagram.
example.net ---------------- im.example.com example.net ---------------- im.example.com
| | | |
| | | |
romeo@example.net juliet@im.example.com romeo@example.net juliet@im.example.com
Note: Architectures that employ XML streams (Section 5) and XML Note: Architectures that employ XML streams (Section 5) and XML
stanzas (Section 9) but that establish peer-to-peer connections stanzas (Section 9) but that establish peer-to-peer connections
directly between clients using technologies based on [LINKLOCAL] directly between clients using technologies based on [LINKLOCAL]
have been deployed, but such architectures are not XMPP and are have been deployed, but such architectures are not described in
best described as "XMPP-like"; for details, see [XEP-0174]. In this specification and are best described as "XMPP-like"; for
addition, XML streams can be established end-to-end over any details, see [XEP-0174]. In addition, XML streams can be
reliable transport, including extensions to XMPP itself; however, established end-to-end over any reliable transport, including
such methods are out of scope for this specification. extensions to XMPP itself; however, such methods are out of scope
for this specification.
2.2. Server The following paragraphs describe the responsibilities of clients and
servers on the network.
A CLIENT is an entity that establishes an XML stream with a server by
authenticating using the credentials of a local account and that then
completes resource binding (Section 8) in order to enable delivery of
XML stanzas between the server and the client over the negotiated
stream. The client then uses XMPP to communicate with its server,
other clients, and any other entities on the network, where the
server is responsible for delivering stanzas to local entities or
routing them to remote entities. Multiple clients can connect
simultaneously to a server on behalf of the same local account, where
each client is differentiated by the resource identifier portion of
an XMPP address (e.g., <localpart@domain/home> vs.
<localpart@domain/work>), as defined under Section 3 and Section 8.
A SERVER is an entity whose primary responsibilities are to: A SERVER is an entity whose primary responsibilities are to:
o Manage XML streams (Section 5) with local clients and deliver XML o Manage XML streams (Section 5) with local clients and deliver XML
stanzas (Section 9) to those clients over the negotiated XML stanzas (Section 9) to those clients over the negotiated streams;
streams. this includes responsibility for ensuring that a client needs to
authenticate with the server before being granted access to the
XMPP network.
o Subject to local service policies on server-to-server o Subject to local service policies on server-to-server
communication, manage XML streams (Section 5) with foreign servers communication, manage XML streams (Section 5) with remote servers
and route XML stanzas (Section 9) to those servers over the and route XML stanzas (Section 9) to those servers over the
negotiated XML streams. negotiated streams.
Depending on the application, the secondary responsibilities of an Depending on the application, the secondary responsibilities of an
XMPP server can include: XMPP server can include:
o Storing XML data that is used by clients (e.g., contact lists for o Storing XML data that is used by clients (e.g., contact lists for
users of XMPP-based instant messaging and presence applications as users of XMPP-based instant messaging and presence applications as
defined in [xmpp-im]); in this case, the relevant XML stanza is defined in [XMPP-IM]); in this case, the relevant XML stanza is
handled directly by the server itself on behalf of the client and handled directly by the server itself on behalf of the client and
is not routed to a foreign server or delivered to a local entity. is not routed to a remote server or delivered to a local entity.
o Hosting local services that also use XMPP as the basis for o Hosting local services that also use XMPP as the basis for
communication but that provide additional functionality beyond communication but that provide additional functionality beyond
that defined in this document or in [xmpp-im]; examples include that defined in this document or in [XMPP-IM]; examples include
multi-user conferencing services as specified in [XEP-0045] and multi-user conferencing services as specified in [XEP-0045] and
publish-subscribe services as specified in [XEP-0060]. publish-subscribe services as specified in [XEP-0060].
2.3. Client
A CLIENT is an entity that establishes an XML stream with a server by
authenticating using the credentials of a local account and that then
completes resource binding (Section 8) in order to enable delivery of
XML stanzas via the server to the client. A client then uses XMPP to
communicate with its server, other clients, and any other accessible
entities on a network. Multiple clients can connect simultaneously
to a server on behalf of a local account, where each client is
differentiated by the resource identifier portion of an XMPP address
(e.g., <localpart@domain/home> vs. <localpart@domain/work>), as
defined under Section 3 and Section 8. The RECOMMENDED port for TCP
connections between a client and a server is 5222, as registered with
the IANA (see Section 16.9).
2.4. Network
Because each server is identified by a network address and because
server-to-server communication is a straightforward extension of the
client-to-server protocol, in practice the system consists of a
network of servers that inter-communicate. Thus, for example,
<juliet@im.example.com> is able to exchange messages, presence, and
other information with <romeo@example.net>. This pattern is familiar
from messaging protocols (such as [SMTP]) that make use of network
addressing standards. Communication between any two servers is
OPTIONAL. The RECOMMENDED port for TCP connections between servers
is 5269, as registered with the IANA (see Section 16.9).
3. Addresses 3. Addresses
3.1. Overview 3.1. Overview
An ENTITY is anything that is network-addressable and that can An ENTITY is anything that is network-addressable and that can
communicate using XMPP. For historical reasons, the native address communicate using XMPP. For historical reasons, the native address
of an XMPP entity is called a JABBER IDENTIFIER or JID. A valid JID of an XMPP entity is called a JABBER IDENTIFIER or JID. A valid JID
contains a set of ordered elements formed of an XMPP localpart, contains a set of ordered elements formed of an XMPP localpart,
domain identifier, and resource identifier. domain identifier, and resource identifier.
skipping to change at page 19, line 21 skipping to change at page 20, line 21
the JID sent by the initiating entity with the canonicalized JID as the JID sent by the initiating entity with the canonicalized JID as
determined by the receiving entity. determined by the receiving entity.
4. TCP Binding 4. TCP Binding
4.1. Scope 4.1. Scope
As XMPP is defined in this specification, an initiating entity As XMPP is defined in this specification, an initiating entity
(client or server) MUST open a Transmission Control Protocol [TCP] (client or server) MUST open a Transmission Control Protocol [TCP]
connection at the receiving entity (server) before it negotiates XML connection at the receiving entity (server) before it negotiates XML
streams with the receiving entity. The rules specified in the streams with the receiving entity. The parties then maintain that
following sections apply to the TCP binding. TCP connection for as long as the XML streams are in use. The rules
specified in the following sections apply to the TCP binding.
4.2. Hostname Resolution 4.2. Hostname Resolution
Before opening the TCP connection, the initiating entity first MUST Before opening the TCP connection, the initiating entity first MUST
resolve the Domain Name System (DNS) hostname associated with the resolve the Domain Name System (DNS) hostname associated with the
receiving entity and determine the appropriate TCP port for receiving entity and determine the appropriate TCP port for
communication with the receiving entity. The process is: communication with the receiving entity. The process is:
1. Attempt to resolve the hostname using (a) a [DNS-SRV] Service of 1. Attempt to resolve the hostname using (a) a [DNS-SRV] Service of
"xmpp-client" (for client-to-server connections) or "xmpp-server" "xmpp-client" (for client-to-server connections) or "xmpp-server"
skipping to change at page 20, line 4 skipping to change at page 21, line 5
SHOULD attempt a fallback resolution as described below). The SHOULD attempt a fallback resolution as described below). The
initiating entity uses the IP address(es) from the first initiating entity uses the IP address(es) from the first
successfully resolved hostname (with the corresponding port successfully resolved hostname (with the corresponding port
number returned by the SRV lookup) in order to connect to the number returned by the SRV lookup) in order to connect to the
receiving entity. If the initiating entity fails to connect receiving entity. If the initiating entity fails to connect
using one of the IP addresses, the initiating entity uses the using one of the IP addresses, the initiating entity uses the
next resolved IP address to connect. If the initiating entity next resolved IP address to connect. If the initiating entity
fails to connect using all resolved IP addresses, then the fails to connect using all resolved IP addresses, then the
initiating entity repeats the process of resolution and initiating entity repeats the process of resolution and
connection for the next hostname returned by the SRV lookup. connection for the next hostname returned by the SRV lookup.
2. If the SRV lookup aborts or fails, the fallback SHOULD be a 2. If the SRV lookup aborts or fails, the fallback SHOULD be a
normal IPv4 or IPv6 address record resolution to determine the IP normal IPv4 or IPv6 address record resolution to determine the IP
address, where the port used is the "xmpp-client" port of 5222 address, where the port used is the "xmpp-client" port of 5222
for client-to-server connections or the "xmpp-server" port 5269 for client-to-server connections or the "xmpp-server" port 5269
for server-to-server connections. for server-to-server connections.
3. For client-to-server connections, the fallback MAY be a [DNS-TXT] 3. For client-to-server connections, the fallback MAY be a [DNS-TXT]
lookup for alternative connection methods, for example as lookup for alternative connection methods, for example as
described in [XEP-0156]. described in [XEP-0156].
Note: If the initiating entity has been explicitly configured to Note: If the initiating entity has been explicitly configured to
associate a particular hostname (and potentially port) with the associate a particular hostname (and potentially port) with the
original hostname of the receiving entity (say, to "hardcode" an original hostname of the receiving entity (say, to "hardcode" an
association between an original hostname of example.net and a association between an original hostname of example.net and a
configured hostname and of webcm.example.com:80), the initiating configured hostname and of webcm.example.com:80), the initiating
entity SHALL use the configured name instead of performing the entity SHALL use the configured name instead of performing the
foregoing resolution process on the original name. foregoing resolution process on the original name.
Note: Many XMPP servers are implemented in such a way that they Note: Many XMPP servers are implemented in such a way that they
can host additional services (beyond those defined in this can host additional services (beyond those defined in this
specification and [xmpp-im]) at hostnames that are subdomains of specification and [XMPP-IM]) at hostnames that are subdomains of
the hostname of the main XMPP service (e.g., the hostname of the main XMPP service (e.g.,
conference.example.net for a [XEP-0045] service associated with conference.example.net for a [XEP-0045] service associated with
the example.net XMPP service) or subdomains of the first-level the example.net XMPP service) or subdomains of the first-level
domain of the underlying host (e.g., muc.example.com for a domain of the underlying host (e.g., muc.example.com for a
[XEP-0045] service associated with the im.example.com XMPP [XEP-0045] service associated with the im.example.com XMPP
service). If an entity from a remote domain wishes to use such service). If an entity from a remote domain wishes to use such
additional services, it would generate an appropriate XML stanza additional services, it would generate an appropriate XML stanza
and the remote domain itself would attempt to resolve the and the remote domain itself would attempt to resolve the
service's hostname via an SRV lookup on resource records such as service's hostname via an SRV lookup on resource records such as
"_xmpp-server._tcp.conference.example.net." or "_xmpp- "_xmpp-server._tcp.conference.example.net." or "_xmpp-
skipping to change at page 21, line 49 skipping to change at page 22, line 49
back off increasingly on the time between subsequent reconnection back off increasingly on the time between subsequent reconnection
attempts. attempts.
Note: Because it is possible that a disconnected entity cannot Note: Because it is possible that a disconnected entity cannot
determine the cause of disconnection (e.g., because there was no determine the cause of disconnection (e.g., because there was no
explicit stream error) or does not require a new stream for explicit stream error) or does not require a new stream for
immediate communication (e.g., because the stream was idle and immediate communication (e.g., because the stream was idle and
therefore timed out), it SHOULD NOT assume that is needs to therefore timed out), it SHOULD NOT assume that is needs to
reconnect immediately. reconnect immediately.
4.6. Other Bindings 4.6. Reliability
The use of long-lived TCP connections in XMPP implies that the
sending of XML stanzas over XML streams can be unreliable, since the
parties to a long-lived TCP connection might not discover a
connectivity disruption in a timely manner. At the XMPP application
layer, long connectivity disruptions can result in undelivered
stanzas. Although the core XMPP technology defined in this
specification does not contain features to overcome this lack of
reliability, there exist XMPP extensions for doing so (e.g.,
[XEP-0198]).
4.7. Other Bindings
There is no necessary coupling of an XML stream to a TCP connection. There is no necessary coupling of an XML stream to a TCP connection.
For example, two entities could connect to each other via another For example, two entities could connect to each other via another
transport, such as [HTTP] as specified in [XEP-0124] and [XEP-0206]. transport, such as [HTTP] as specified in [XEP-0124] and [XEP-0206].
Although this specification neither encourages nor discourages other Although this specification neither encourages nor discourages other
bindings, it defines only a binding of XMPP to TCP. bindings, it defines only a binding of XMPP to TCP.
5. XML Streams 5. XML Streams
5.1. Overview 5.1. Overview
skipping to change at page 35, line 10 skipping to change at page 36, line 39
5.7.3. Handling of Idle Streams 5.7.3. Handling of Idle Streams
An XML stream can become idle, i.e., neither entity has sent XMPP An XML stream can become idle, i.e., neither entity has sent XMPP
traffic over the stream for some period of time. The idle timeout traffic over the stream for some period of time. The idle timeout
period is a matter of implementation and local service policy; period is a matter of implementation and local service policy;
however, it is RECOMMENDED to be liberal in accepting idle streams, however, it is RECOMMENDED to be liberal in accepting idle streams,
since experience has shown that doing so improves the reliability of since experience has shown that doing so improves the reliability of
communications over XMPP networks. In particular, it is typically communications over XMPP networks. In particular, it is typically
more efficient to maintain a stream between two servers than it is to more efficient to maintain a stream between two servers than it is to
aggressively timeout such a stream, especially with regard to aggressively timeout such a stream, especially with regard to
synchronization of presence information as described in [xmpp-im]; synchronization of presence information as described in [XMPP-IM];
therefore it is RECOMMENDED to maintain such a stream since therefore it is RECOMMENDED to maintain such a stream since
experience has shown that server-to-server streams are cyclical and experience has shown that server-to-server streams are cyclical and
typically need to be re-established every 24 to 48 hours if they are typically need to be re-established every 24 to 48 hours if they are
timed out. timed out.
An XML stream can appear idle at the XMPP level because the An XML stream can appear idle at the XMPP level because the
underlying TCP connection has become idle (e.g., a client's network underlying TCP connection has become idle (e.g., a client's network
connection has been lost). One common method for preventing a TCP connection has been lost). One common method for preventing a TCP
connection from going idle or for detecting an idle TCP connection is connection from going idle or for detecting an idle TCP connection is
to send a space character (U+0020) over the TCP connection between to send a space character (U+0020) over the TCP connection between
skipping to change at page 81, line 15 skipping to change at page 82, line 15
9. XML Stanzas 9. XML Stanzas
After a client has connected to a server or two servers have After a client has connected to a server or two servers have
connected to each other, either party can send XML stanzas over the connected to each other, either party can send XML stanzas over the
negotiated stream. Three kinds of XML stanza are defined for the negotiated stream. Three kinds of XML stanza are defined for the
'jabber:client' and 'jabber:server' namespaces: <message/>, 'jabber:client' and 'jabber:server' namespaces: <message/>,
<presence/>, and <iq/>. In addition, there are five common <presence/>, and <iq/>. In addition, there are five common
attributes for these stanza types. These common attributes, as well attributes for these stanza types. These common attributes, as well
as the basic semantics of the three stanza types, are defined herein; as the basic semantics of the three stanza types, are defined herein;
more detailed information regarding the syntax of XML stanzas for more detailed information regarding the syntax of XML stanzas for
instant messaging and presence applications is provided in [xmpp-im], instant messaging and presence applications is provided in [XMPP-IM],
and for other applications in the relevant XMPP extension and for other applications in the relevant XMPP extension
specifications. specifications.
A server MUST NOT process a partial stanza and MUST NOT attach A server MUST NOT process a partial stanza and MUST NOT attach
meaning to the transmission timing of any part of a stanza (before meaning to the transmission timing of any part of a stanza (before
receipt of the close tag). receipt of the close tag).
Support for the XML stanza syntax and semantics defined herein is Support for the XML stanza syntax and semantics defined herein is
REQUIRED in XMPP client and server implementations. REQUIRED in XMPP client and server implementations.
skipping to change at page 82, line 47 skipping to change at page 83, line 47
XML streams qualified by the 'jabber:client' namespace (i.e., client- XML streams qualified by the 'jabber:client' namespace (i.e., client-
to-server streams). to-server streams).
1. When the server receives an XML stanza from a client and the 1. When the server receives an XML stanza from a client and the
stanza does not include a 'from' attribute, the server MUST add a stanza does not include a 'from' attribute, the server MUST add a
'from' attribute to the stanza, where the value of the 'from' 'from' attribute to the stanza, where the value of the 'from'
attribute is the full JID (<localpart@domain/resource>) attribute is the full JID (<localpart@domain/resource>)
determined by the server for the connected resource that determined by the server for the connected resource that
generated the stanza (see Section 3.5), or the bare JID generated the stanza (see Section 3.5), or the bare JID
(<localpart@domain>) in the case of subscription-related presence (<localpart@domain>) in the case of subscription-related presence
stanzas (see [xmpp-im]). stanzas (see [XMPP-IM]).
2. When the server receives an XML stanza from a client and the 2. When the server receives an XML stanza from a client and the
stanza includes a 'from' attribute, the server MUST either (a) stanza includes a 'from' attribute, the server MUST either (a)
validate that the value of the 'from' attribute provided by the validate that the value of the 'from' attribute provided by the
client is that of a connected resource for the associated entity client is that of a connected resource for the associated entity
or (b) override the provided 'from' attribute by adding a 'from' or (b) override the provided 'from' attribute by adding a 'from'
attribute as specified under Rule #1. attribute as specified under Rule #1.
3. When the server generates a stanza from the server for delivery 3. When the server generates a stanza from the server for delivery
to the client on behalf of the account of the connected client to the client on behalf of the account of the connected client
(e.g., in the context of data storage services provided by the (e.g., in the context of data storage services provided by the
server on behalf of the client), the stanza MUST either (a) not server on behalf of the client), the stanza MUST either (a) not
skipping to change at page 84, line 24 skipping to change at page 85, line 24
Note: The semantics of IQ stanzas impose additional restrictions; see Note: The semantics of IQ stanzas impose additional restrictions; see
Section 9.2.3. Section 9.2.3.
9.1.4. type 9.1.4. type
The 'type' attribute specifies the purpose or context of the message, The 'type' attribute specifies the purpose or context of the message,
presence, or IQ stanza. The particular allowable values for the presence, or IQ stanza. The particular allowable values for the
'type' attribute vary depending on whether the stanza is a message, 'type' attribute vary depending on whether the stanza is a message,
presence, or IQ stanza. The defined values for message and presence presence, or IQ stanza. The defined values for message and presence
stanzas are specific to instant messaging and presence applications stanzas are specific to instant messaging and presence applications
and therefore are specified in [xmpp-im], whereas the values for IQ and therefore are specified in [XMPP-IM], whereas the values for IQ
stanzas specify the role of an IQ stanza in a structured request- stanzas specify the role of an IQ stanza in a structured request-
response exchange and therefore are specified under Section 9.2.3. response exchange and therefore are specified under Section 9.2.3.
The only 'type' value common to all three stanzas is "error"; see The only 'type' value common to all three stanzas is "error"; see
Section 9.3. Section 9.3.
9.1.5. xml:lang 9.1.5. xml:lang
A stanza SHOULD possess an 'xml:lang' attribute (as defined in A stanza SHOULD possess an 'xml:lang' attribute (as defined in
Section 2.12 of [XML]) if the stanza contains XML character data that Section 2.12 of [XML]) if the stanza contains XML character data that
is intended to be presented to a human user (as explained in is intended to be presented to a human user (as explained in
skipping to change at page 86, line 9 skipping to change at page 87, line 9
The <presence/> stanza can be seen as a specialized broadcast or The <presence/> stanza can be seen as a specialized broadcast or
"publish-subscribe" mechanism, whereby multiple entities receive "publish-subscribe" mechanism, whereby multiple entities receive
information (in this case, network availability information) about an information (in this case, network availability information) about an
entity to which they have subscribed. In general, a publishing entity to which they have subscribed. In general, a publishing
entity (client) SHOULD send a presence stanza with no 'to' attribute, entity (client) SHOULD send a presence stanza with no 'to' attribute,
in which case the server to which the entity is connected SHOULD in which case the server to which the entity is connected SHOULD
broadcast that stanza to all subscribed entities. However, a broadcast that stanza to all subscribed entities. However, a
publishing entity MAY also send a presence stanza with a 'to' publishing entity MAY also send a presence stanza with a 'to'
attribute, in which case the server SHOULD route or deliver that attribute, in which case the server SHOULD route or deliver that
stanza to the intended recipient. See Section 11 for general routing stanza to the intended recipient. See Section 11 for general routing
and delivery rules related to XML stanzas, and [xmpp-im] for rules and delivery rules related to XML stanzas, and [XMPP-IM] for rules
specific to presence applications. specific to presence applications.
9.2.3. IQ Semantics 9.2.3. IQ Semantics
Info/Query, or IQ, is a request-response mechanism, similar in some Info/Query, or IQ, is a request-response mechanism, similar in some
ways to the Hypertext Transfer Protocol [HTTP]. The semantics of IQ ways to the Hypertext Transfer Protocol [HTTP]. The semantics of IQ
enable an entity to make a request of, and receive a response from, enable an entity to make a request of, and receive a response from,
another entity. The data content of the request and response is another entity. The data content of the request and response is
defined by the schema or other structural definition associated with defined by the schema or other structural definition associated with
the XML namespace that qualifies the direct child element of the IQ the XML namespace that qualifies the direct child element of the IQ
skipping to change at page 114, line 37 skipping to change at page 115, line 37
S2: </stream:stream> S2: </stream:stream>
Server1 now terminates the underlying TCP connection. Server1 now terminates the underlying TCP connection.
11. Server Rules for Processing XML Stanzas 11. Server Rules for Processing XML Stanzas
An XMPP server MUST ensure in-order processing of XML stanzas between An XMPP server MUST ensure in-order processing of XML stanzas between
any two entities. This includes stanzas sent by a client to its any two entities. This includes stanzas sent by a client to its
server for direct processing by the server (e.g., in-order processing server for direct processing by the server (e.g., in-order processing
of a roster get and initial presence as described in [xmpp-im]). of a roster get and initial presence as described in [XMPP-IM]).
Beyond the requirement for in-order processing, each server Beyond the requirement for in-order processing, each server
implementation will contain its own logic for processing stanzas it implementation will contain its own logic for processing stanzas it
receives. Such logic determines whether the server needs to ROUTE a receives. Such logic determines whether the server needs to ROUTE a
given stanza to another domain, DELIVER it to a local entity given stanza to another domain, DELIVER it to a local entity
(typically a connected client associated with a local account), or (typically a connected client associated with a local account), or
HANDLE it directly within the server itself. The following rules HANDLE it directly within the server itself. The following rules
apply. apply.
Note: Particular XMPP applications MAY specify delivery rules that Note: Particular XMPP applications MAY specify delivery rules that
modify or supplement the following rules; for example, a set of modify or supplement the following rules; for example, a set of
delivery rules for instant messaging and presence applications is delivery rules for instant messaging and presence applications is
defined in [xmpp-im]. defined in [XMPP-IM].
11.1. No 'to' Address 11.1. No 'to' Address
11.1.1. Overview 11.1.1. Overview
If the stanza possesses no 'to' attribute, the server MUST handle it If the stanza possesses no 'to' attribute, the server MUST handle it
directly on behalf of the entity that sent it, where the meaning of directly on behalf of the entity that sent it, where the meaning of
"handle it directly" depends on whether the stanza is message, "handle it directly" depends on whether the stanza is message,
presence, or IQ. Because all stanzas received from other servers presence, or IQ. Because all stanzas received from other servers
MUST possess a 'to' attribute, this rule applies only to stanzas MUST possess a 'to' attribute, this rule applies only to stanzas
skipping to change at page 115, line 27 skipping to change at page 116, line 27
11.1.2. Message 11.1.2. Message
If the server receives a message stanza with no 'to' attribute, it If the server receives a message stanza with no 'to' attribute, it
MUST treat the message as if the 'to' address were the bare JID MUST treat the message as if the 'to' address were the bare JID
<localpart@domain> of the sending entity. <localpart@domain> of the sending entity.
11.1.3. Presence 11.1.3. Presence
If the server receives a presence stanza with no 'to' attribute, it If the server receives a presence stanza with no 'to' attribute, it
MUST broadcast it to the entities that are subscribed to the sending MUST broadcast it to the entities that are subscribed to the sending
entity's presence, if applicable ([xmpp-im] defines the semantics of entity's presence, if applicable ([XMPP-IM] defines the semantics of
such broadcasting for presence applications). such broadcasting for presence applications).
11.1.4. IQ 11.1.4. IQ
If the server receives an IQ stanza with no 'to' attribute, it MUST If the server receives an IQ stanza with no 'to' attribute, it MUST
process the stanza on behalf of the account from which received the process the stanza on behalf of the account from which received the
stanza, as follows: stanza, as follows:
1. If the IQ stanza is of type "get" or "set" and the server 1. If the IQ stanza is of type "get" or "set" and the server
understands the namespace that qualifies the payload, the server understands the namespace that qualifies the payload, the server
MUST handle the stanza on behalf of the sending entity or return MUST handle the stanza on behalf of the sending entity or return
an appropriate error to the sending entity. While the meaning of an appropriate error to the sending entity. While the meaning of
"handle" is determined by the semantics of the qualifying "handle" is determined by the semantics of the qualifying
namespace, in general the server shall respond to the IQ stanza namespace, in general the server shall respond to the IQ stanza
of type "get" or "set" by returning an appropriate IQ stanza of of type "get" or "set" by returning an appropriate IQ stanza of
type "result" or "error", responding as if the server were the type "result" or "error", responding as if the server were the
bare JID of the sending entity. As an example, if the sending bare JID of the sending entity. As an example, if the sending
entity sends an IQ stanza of type "get" where the payload is entity sends an IQ stanza of type "get" where the payload is
qualified by the 'jabber:iq:roster' namespace (as described in qualified by the 'jabber:iq:roster' namespace (as described in
[xmpp-im]), then the server shall return the roster associated [XMPP-IM]), then the server shall return the roster associated
with the sending entity's bare JID to the particular resource of with the sending entity's bare JID to the particular resource of
the sending entity that requested the roster. the sending entity that requested the roster.
2. If the IQ stanza is of type "get" or "set" and the server does 2. If the IQ stanza is of type "get" or "set" and the server does
not understand the namespace that qualifies the payload, the not understand the namespace that qualifies the payload, the
server MUST return an error to the sending entity, which MUST be server MUST return an error to the sending entity, which MUST be
<service-unavailable/>. <service-unavailable/>.
3. If the IQ stanza is of type "error" or "result", the server MUST 3. If the IQ stanza is of type "error" or "result", the server MUST
handle the error or result as appropriate for the request- handle the error or result as appropriate for the request-
response interaction, responding as if the server were the bare response interaction, responding as if the server were the bare
JID of the sending entity. JID of the sending entity.
skipping to change at page 116, line 36 skipping to change at page 117, line 36
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/
resource>, then the server MUST either handle the stanza as resource>, then the server MUST either handle the stanza as
appropriate for the stanza kind or return an error stanza to the appropriate for the stanza kind or return an error stanza to the
sender. sender.
11.2.3. Localpart at Domain 11.2.3. Localpart at Domain
Note: For addresses of this type, more detailed rules in the Note: For addresses of this type, more detailed rules in the
context of instant messaging and presence applications are context of instant messaging and presence applications are
provided in [xmpp-im]. provided in [XMPP-IM].
11.2.3.1. No Such User 11.2.3.1. No Such User
If there is no local account associated with the <localpart@domain>, If there is no local account associated with the <localpart@domain>,
how the stanza shall be processed depends on the stanza type. how the stanza shall be processed depends on the stanza type.
o For a message stanza, the server MUST return a <service- o For a message stanza, the server MUST return a <service-
unavailable/> stanza error to the sender. unavailable/> stanza error to the sender.
o For a presence stanza, the server SHOULD silently discard the o For a presence stanza, the server SHOULD silently discard the
stanza. stanza.
skipping to change at page 117, line 36 skipping to change at page 118, line 36
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@domain/resource> and there is no connected resource that <localpart@domain/resource> and there is no connected resource that
exactly matches the full JID, the stanza shall be processed as if the exactly matches the full JID, the stanza shall be processed as if the
JID were of the form <localpart@domain>. JID were of the form <localpart@domain>.
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@domain/resource> and there is a connected resource that <localpart@domain/resource> and there is a connected resource that
exactly matches the full JID, the server SHOULD deliver the stanza to exactly matches the full JID, the server SHOULD deliver the stanza to
that connected resource. that connected resource.
11.3. Foreign Domain 11.3. Remote Domain
If the hostname of the domain identifier portion of the JID contained If the hostname of the domain identifier portion of the JID contained
in the 'to' attribute does not match one of the configured hostnames in the 'to' attribute does not match one of the configured hostnames
of the server itself, the server SHOULD attempt to route the stanza of the server itself, the server SHOULD attempt to route the stanza
to the foreign domain (subject to local service provisioning and to the remote domain (subject to local service provisioning and
security policies regarding inter-domain communication, since such security policies regarding inter-domain communication, since such
communication is optional for any given deployment). There are two communication is optional for any given deployment). There are two
possible cases. possible cases.
11.3.1. Existing Stream 11.3.1. Existing Stream
If a server-to-server stream already exists between the two domains, If a server-to-server stream already exists between the two domains,
the sender's server shall attempt to route the stanza to the the sender's server shall attempt to route the stanza to the
authoritative server for the foreign domain over the existing stream. authoritative server for the remote domain over the existing stream.
11.3.2. No Existing Stream 11.3.2. No Existing Stream
If there exists no server-to-server stream between the two domains, If there exists no server-to-server stream between the two domains,
the sender's server shall proceed as follows: the sender's server shall proceed as follows:
1. Resolve the hostname of the foreign domain (as defined under 1. Resolve the hostname of the remote domain (as defined under
Section 15.4). Section 15.4).
2. Negotiate a server-to-server stream between the two domains (as 2. Negotiate a server-to-server stream between the two domains (as
defined under Section 6 and Section 7). defined under Section 6 and Section 7).
3. Route the stanza to the authoritative server for the foreign 3. Route the stanza to the authoritative server for the remote
domain over the newly-established stream. domain over the newly-established stream.
11.3.3. Error Handling 11.3.3. Error Handling
If routing of a stanza to the intended recipient's server is If routing of a stanza to the intended recipient's server is
unsuccessful, the sender's server MUST return an error to the sender. unsuccessful, the sender's server MUST return an error to the sender.
If resolution of the foreign domain is unsuccessful, the stanza error If resolution of the remote domain is unsuccessful, the stanza error
MUST be <remote-server-not-found/>. If resolution succeeds but MUST be <remote-server-not-found/>. If resolution succeeds but
streams cannot be negotiated, the stanza error MUST be <remote- streams cannot be negotiated, the stanza error MUST be <remote-
server-timeout/>. server-timeout/>.
If stream negotiation with the intended recipient's server is If stream negotiation with the intended recipient's server is
successful but the foreign server cannot deliver the stanza to the successful but the remote server cannot deliver the stanza to the
recipient, the foreign server shall return an appropriate error to recipient, the remote server shall return an appropriate error to the
the sender by way of the sender's server. sender by way of the sender's server.
12. XML Usage 12. XML Usage
12.1. Restrictions 12.1. Restrictions
The Extensible Messaging and Presence Protocol (XMPP) defines a class The Extensible Messaging and Presence Protocol (XMPP) defines a class
of data objects called XML streams as well as the behavior of of data objects called XML streams as well as the behavior of
computer programs that process XML streams. XMPP is an application computer programs that process XML streams. XMPP is an application
profile or restricted form of the Extensible Markup Language [XML], profile or restricted form of the Extensible Markup Language [XML],
and a complete XML stream (including start and end stream tags) is a and a complete XML stream (including start and end stream tags) is a
skipping to change at page 123, line 7 skipping to change at page 124, line 7
client or routed to another server is valid, in accordance with the client or routed to another server is valid, in accordance with the
definition of "valid" provided in Section 2.8 of [XML]. An definition of "valid" provided in Section 2.8 of [XML]. An
implementation MAY choose to accept or provide only validated data, implementation MAY choose to accept or provide only validated data,
but such behavior is OPTIONAL. A client SHOULD NOT rely on the but such behavior is OPTIONAL. A client SHOULD NOT rely on the
ability to send data that does not conform to the schemas, and SHOULD ability to send data that does not conform to the schemas, and SHOULD
ignore any non-conformant elements or attributes on the incoming XML ignore any non-conformant elements or attributes on the incoming XML
stream. stream.
Note: The terms "valid" and "well-formed" are distinct in XML. Note: The terms "valid" and "well-formed" are distinct in XML.
12.5. Inclusion of Text Declaration 12.5. Inclusion of XML Declaration
Implementations SHOULD send a text declaration before sending a Before sending a stream header, an implementation SHOULD send an XML
stream header. Applications MUST follow the rules provided in [XML] declaration (matching production [23] content of [XML]).
regarding the circumstances under which a text declaration is Applications MUST follow the rules provided in [XML] regarding the
included. format of the XML declaration and the circumstances under which the
XML declaration is included.
12.6. Character Encoding 12.6. Character Encoding
Implementations MUST support the UTF-8 transformation of Universal Implementations MUST support the UTF-8 transformation of Universal
Character Set [UCS2] characters, as required by [CHARSET] and defined Character Set [UCS2] characters, as required by [CHARSET] and defined
in [UTF-8]. Implementations MUST NOT attempt to use any other in [UTF-8]. Implementations MUST NOT attempt to use any other
encoding. If one party to an XML stream detects that the other party encoding. If one party to an XML stream detects that the other party
has attempted to send XML data with an encoding other than UTF-8, it has attempted to send XML data with an encoding other than UTF-8, it
MUST return a stream error, which SHOULD be <unsupported-encoding/> MUST return a stream error, which SHOULD be <unsupported-encoding/>
but MAY be <bad-format/>. but MAY be <bad-format/>.
skipping to change at page 124, line 13 skipping to change at page 125, line 14
clients in order to be considered compliant implementations, as well clients in order to be considered compliant implementations, as well
as additional protocol aspects that SHOULD be supported. For as additional protocol aspects that SHOULD be supported. For
compliance purposes, we draw a distinction between core protocols compliance purposes, we draw a distinction between core protocols
(which MUST be supported by any server or client, regardless of the (which MUST be supported by any server or client, regardless of the
specific application) and instant messaging and presence protocols specific application) and instant messaging and presence protocols
(which MUST be supported only by instant messaging and presence (which MUST be supported only by instant messaging and presence
applications built on top of the core protocols). Compliance applications built on top of the core protocols). Compliance
requirements that apply to all servers and clients are specified in requirements that apply to all servers and clients are specified in
this section; compliance requirements for instant messaging and this section; compliance requirements for instant messaging and
presence applications are specified in the corresponding section of presence applications are specified in the corresponding section of
[xmpp-im]. [XMPP-IM].
13.1. Servers 13.1. Servers
A server MUST support the following core protocols in order to be A server MUST support the following core protocols in order to be
considered compliant: considered compliant:
o Conformance with [IDNA] for domain identifiers, the Nodeprep o Conformance with [IDNA] for domain identifiers, the Nodeprep
(Appendix A) profile of [STRINGPREP] for localparts, and the (Appendix A) profile of [STRINGPREP] for localparts, and the
Resourceprep (Appendix B) profile of [STRINGPREP] for resource Resourceprep (Appendix B) profile of [STRINGPREP] for resource
identifiers, as well as enforcement thereof for clients that identifiers, as well as enforcement thereof for clients that
skipping to change at page 126, line 44 skipping to change at page 127, line 45
A server's domain identifier SHOULD be represented as an SRVName, A server's domain identifier SHOULD be represented as an SRVName,
i.e., as an otherName field of type "id-on-dnsSRV" as specified in i.e., as an otherName field of type "id-on-dnsSRV" as specified in
[X509-SRV]. [X509-SRV].
15.2.1.1.2. dNSName 15.2.1.1.2. dNSName
A server's domain identifier SHOULD be represented as a dNSName, A server's domain identifier SHOULD be represented as a dNSName,
i.e., as a subjectAltName extension of type dNSName. i.e., as a subjectAltName extension of type dNSName.
The dNSName MAY contain the wildcard character '*'. The wildcard The dNSName MAY contain the wildcard character '*'. The wildcard
character applies only to the left-most domain name component or character applies only to the left-most domain name component and
component fragment and matches any single component or component matches any single component (thus a dNSName of *.example.com matches
fragment. For instance, a dNSName of *.example.com matches foo.example.com but not bar.foo.example.com or example.com itself).
foo.example.com but not bar.foo.example.com or example.com itself; The wildcard character is not allowed in component fragments (thus a
similarly, a dNSName of im*.example.net matches im1.example.net and dNSName of im*.example.net is not allowed and shall not be taken to
im2.example.net but not chat.example.net or example.net itself. match im1.example.net and im2.example.net).
15.2.1.1.3. XmppAddr 15.2.1.1.3. XmppAddr
A server's domain identifier MAY be represented as an XmppAddr, i.e., A server's domain identifier MAY be represented as an XmppAddr, i.e.,
as a UTF8String within an otherName entity inside the subjectAltName, as a UTF8String within an otherName entity inside the subjectAltName,
using the [ASN.1] Object Identifier "id-on-xmppAddr" specified under using the [ASN.1] Object Identifier "id-on-xmppAddr" specified under
Section 15.2.1.3. In server certificates, this representation is Section 15.2.1.3. In server certificates, this representation is
included only for the sake of backward-compatibility. included only for the sake of backward-compatibility.
15.2.1.1.4. Common Name 15.2.1.1.4. Common Name
skipping to change at page 128, line 9 skipping to change at page 129, line 9
and "x2.example.net"), as follows: and "x2.example.net"), as follows:
_xmpp-client._tcp.example.net. 68400 IN SRV 20 0 5222 x1.example.net. _xmpp-client._tcp.example.net. 68400 IN SRV 20 0 5222 x1.example.net.
_xmpp-client._tcp.example.net. 68400 IN SRV 20 0 5222 x2.example.net. _xmpp-client._tcp.example.net. 68400 IN SRV 20 0 5222 x2.example.net.
_xmpp-server._tcp.example.net. 68400 IN SRV 20 0 5269 x1.example.net. _xmpp-server._tcp.example.net. 68400 IN SRV 20 0 5269 x1.example.net.
_xmpp-server._tcp.example.net. 68400 IN SRV 20 0 5269 x2.example.net. _xmpp-server._tcp.example.net. 68400 IN SRV 20 0 5269 x2.example.net.
Example Internet Services also hosts chatrooms at chat.example.net, Example Internet Services also hosts chatrooms at chat.example.net,
and provides an xmpp-server SRV record for that service as well (thus and provides an xmpp-server SRV record for that service as well (thus
enabling entity from foreign domains to access that service). It enabling entity from remote domains to access that service). It also
also might provide other such services in the future, so it wishes to might provide other such services in the future, so it wishes to
represent a wildcard in its certificate to handle such growth. represent a wildcard in its certificate to handle such growth.
The certificate presented by either x1.example.net or x2.example.net The certificate presented by either x1.example.net or x2.example.net
contains the following representations: contains the following representations:
o An otherName type of SRVName (id-on-dnsSRV) containing an o An otherName type of SRVName (id-on-dnsSRV) containing an
IA5String (ASCII) string of: "_xmpp-client.example.net" IA5String (ASCII) string of: "_xmpp-client.example.net"
o An otherName type of SRVName (id-on-dnsSRV) containing an o An otherName type of SRVName (id-on-dnsSRV) containing an
IA5String (ASCII) string of: "_xmpp-server.example.net" IA5String (ASCII) string of: "_xmpp-server.example.net"
o An otherName type of SRVName (id-on-dnsSRV) containing an o An otherName type of SRVName (id-on-dnsSRV) containing an
skipping to change at page 139, line 50 skipping to change at page 140, line 50
15.15. Presence Leaks 15.15. Presence Leaks
One of the core aspects of XMPP is presence: information about the One of the core aspects of XMPP is presence: information about the
network availability of an XMPP entity (i.e., whether the entity is network availability of an XMPP entity (i.e., whether the entity is
currently online or offline). A PRESENCE LEAK occurs when an currently online or offline). A PRESENCE LEAK occurs when an
entity's network availability is inadvertently and involuntarily entity's network availability is inadvertently and involuntarily
revealed to a second entity that is not authorized to know the first revealed to a second entity that is not authorized to know the first
entity's network availability. entity's network availability.
Although presence is discussed more fully in [xmpp-im], it is Although presence is discussed more fully in [XMPP-IM], it is
important to note that an XMPP server MUST NOT leak presence. In important to note that an XMPP server MUST NOT leak presence. In
particular at the core XMPP level, real-time addressing and network particular at the core XMPP level, real-time addressing and network
availability is associated with a specific connected resource; availability is associated with a specific connected resource;
therefore, any disclosure of a connected resource's full JID therefore, any disclosure of a connected resource's full JID
comprises a presence leak. To help prevent such a presence leak, a comprises a presence leak. To help prevent such a presence leak, a
server MUST NOT return different stanza errors if a potential server MUST NOT return different stanza errors if a potential
attacker sends XML stanzas to the entity's bare JID attacker sends XML stanzas to the entity's bare JID
(<localpart@domain>) or full JID (<localpart@domain/resource>). (<localpart@domain>) or full JID (<localpart@domain/resource>).
15.16. Directory Harvesting 15.16. Directory Harvesting
skipping to change at page 145, line 47 skipping to change at page 146, line 47
[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.
[EMAIL-ARCH]
Crocker, D., "Internet Mail Architecture", RFC 5598,
July 2009.
[GSS-API] Linn, J., "Generic Security Service Application Program [GSS-API] Linn, J., "Generic Security Service Application Program
Interface Version 2, Update 1", RFC 2743, January 2000. Interface Version 2, Update 1", RFC 2743, January 2000.
[HASHES] Hoffman, P. and B. Schneier, "Attacks on Cryptographic [HASHES] Hoffman, P. and B. Schneier, "Attacks on Cryptographic
Hashes in Internet Protocols", RFC 4270, November 2005. Hashes in Internet Protocols", RFC 4270, November 2005.
[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.
skipping to change at page 146, line 37 skipping to change at page 147, line 41
FUNCTIONS", RFC 2142, May 1997. FUNCTIONS", RFC 2142, May 1997.
[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", [POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3",
STD 53, RFC 1939, May 1996. STD 53, RFC 1939, May 1996.
[PUNYCODE] [PUNYCODE]
Costello, A., "Punycode: A Bootstring encoding of Unicode Costello, A., "Punycode: A Bootstring encoding of Unicode
for Internationalized Domain Names in Applications for Internationalized Domain Names in Applications
(IDNA)", RFC 3492, March 2003. (IDNA)", RFC 3492, March 2003.
[REST] Fielding, R., "Architectural Styles and the Design of
Network-based Software Architectures", 2000.
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence [RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004. Protocol (XMPP): Core", RFC 3920, October 2004.
[RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence [RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence", Protocol (XMPP): Instant Messaging and Presence",
RFC 3921, October 2004. RFC 3921, October 2004.
[SECTERMS] [SECTERMS]
Shirey, R., "Internet Security Glossary, Version 2", Shirey, R., "Internet Security Glossary, Version 2",
RFC 4949, August 2007. RFC 4949, August 2007.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
April 2001. October 2008.
[URN-OID] Mealling, M., "A URN Namespace of Object Identifiers", [URN-OID] Mealling, M., "A URN Namespace of Object Identifiers",
RFC 3061, February 2001. RFC 3061, February 2001.
[USINGTLS] [USINGTLS]
Newman, C., "Using TLS with IMAP, POP3 and ACAP", Newman, C., "Using TLS with IMAP, POP3 and ACAP",
RFC 2595, June 1999. RFC 2595, June 1999.
[XEP-0001] [XEP-0001]
Saint-Andre, P., "XMPP Extension Protocols", XSF XEP 0001, Saint-Andre, P., "XMPP Extension Protocols", XSF XEP 0001,
skipping to change at page 148, line 22 skipping to change at page 149, line 31
February 2007. February 2007.
[XEP-0191] [XEP-0191]
Saint-Andre, P., "Simple Communications Blocking", XSF Saint-Andre, P., "Simple Communications Blocking", XSF
XEP 0191, February 2007. XEP 0191, February 2007.
[XEP-0198] [XEP-0198]
Karneges, J., Hildebrand, J., Saint-Andre, P., and F. Karneges, J., Hildebrand, J., Saint-Andre, P., and F.
Forno, "Stream Management", XSF XEP 0198, June 2009. Forno, "Stream Management", XSF XEP 0198, June 2009.
[XEP-0199]
Saint-Andre, P., "XMPP Ping", XSF XEP 0199, June 2009.
[XEP-0205] [XEP-0205]
Saint-Andre, P., "Best Practices to Discourage Denial of Saint-Andre, P., "Best Practices to Discourage Denial of
Service Attacks", XSF XEP 0205, January 2009. Service Attacks", XSF XEP 0205, January 2009.
[XEP-0199]
Saint-Andre, P., "XMPP Ping", XSF XEP 0199, June 2009.
[XEP-0206] [XEP-0206]
Paterson, I., "XMPP Over BOSH", XSF XEP 0206, Paterson, I., "XMPP Over BOSH", XSF XEP 0206,
October 2008. October 2008.
[XEP-0220] [XEP-0220]
Saint-Andre, P. and J. Miller, "Server Dialback", XSF Saint-Andre, P. and J. Miller, "Server Dialback", XSF
XEP 0220, October 2008. XEP 0220, October 2008.
[XEP-0271] [XEP-0271]
Saint-Andre, P., "XMPP Nodes", XSF XEP 0271, June 2009. Saint-Andre, P., "XMPP Nodes", XSF XEP 0271, June 2009.
skipping to change at page 149, line 7 skipping to change at page 150, line 17
[XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, [XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004. January 2004.
[XML-SCHEMA] [XML-SCHEMA]
Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech, Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech,
"XML Schema Part 1: Structures Second Edition", World Wide "XML Schema Part 1: Structures Second Edition", World Wide
Web Consortium Recommendation REC-xmlschema-1-20041028, Web Consortium Recommendation REC-xmlschema-1-20041028,
October 2004, October 2004,
<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>. <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[xmpp-im] Saint-Andre, P., "Extensible Messaging and Presence [XMPP-IM] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Instant Messaging and Presence", Protocol (XMPP): Instant Messaging and Presence",
draft-ietf-xmpp-3921bis-01 (work in progress), draft-ietf-xmpp-3921bis-01 (work in progress),
August 2009. August 2009.
[XMPP-URI] [XMPP-URI]
Saint-Andre, P., "Internationalized Resource Identifiers Saint-Andre, P., "Internationalized Resource Identifiers
(IRIs) and Uniform Resource Identifiers (URIs) for the (IRIs) and Uniform Resource Identifiers (URIs) for the
Extensible Messaging and Presence Protocol (XMPP)", Extensible Messaging and Presence Protocol (XMPP)",
RFC 5122, February 2008. RFC 5122, February 2008.
skipping to change at page 153, line 14 skipping to change at page 154, line 30
Appendix C. XML Schemas Appendix C. XML Schemas
Because validation of XML streams and stanzas is optional, the Because validation of XML streams and stanzas is optional, the
following XML schemas are provided for descriptive purposes only. following XML schemas are provided for descriptive purposes only.
These schemas are not normative. These schemas are not normative.
The following schemas formally define various XML namespaces used in The following schemas formally define various XML namespaces used in
the core XMPP protocols, in conformance with [XML-SCHEMA]. For the core XMPP protocols, in conformance with [XML-SCHEMA]. For
schemas defining the 'jabber:client' and 'jabber:server' namespaces, schemas defining the 'jabber:client' and 'jabber:server' namespaces,
refer to [xmpp-im]. refer to [XMPP-IM].
C.1. Streams Namespace C.1. Streams Namespace
<?xml version='1.0' encoding='UTF-8'?> <?xml version='1.0' encoding='UTF-8'?>
<xs:schema <xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema' xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://etherx.jabber.org/streams' targetNamespace='http://etherx.jabber.org/streams'
xmlns='http://etherx.jabber.org/streams' xmlns='http://etherx.jabber.org/streams'
elementFormDefault='unqualified'> elementFormDefault='unqualified'>
skipping to change at page 164, line 20 skipping to change at page 165, line 20
its use. The author grants irrevocable permission to anyone to use, its use. The author grants irrevocable permission to anyone to use,
modify, and distribute it in any way that does not diminish the modify, and distribute it in any way that does not diminish the
rights of anyone else to use, modify, and distribute it, provided rights of anyone else to use, modify, and distribute it, provided
that redistributed derivative works do not contain misleading author that redistributed derivative works do not contain misleading author
or version information. Derivative works need not be licensed under or version information. Derivative works need not be licensed under
similar terms. similar terms.
Index Index
B B
Bare JID 17 Bare JID 18
C C
Connected Resource 75 Connected Resource 76
D D
Domain Identifier 15 Domain Identifier 16
E E
Entity 14 Entity 15
Error Stanza 87 Error Stanza 88
Extended Content 104 Extended Content 105
F F
Full JID 17 Full JID 18
I I
Initial Stream 22 Initial Stream 23
IQ Stanza 86 IQ Stanza 87
J J
Jabber Identifier 14 Jabber Identifier 15
L L
Localpart 17 Localpart 18
M M
Message Stanza 85 Message Stanza 86
P P
Presence Stanza 85 Presence Stanza 86
R R
Resource Identifier 17 Resource Identifier 18
Response Stream 22 Response Stream 23
S S
Stream ID 27 Stream ID 29
W W
Whitespace Keepalive 35 Whitespace Keepalive 36
X X
XML Stanza 22 XML Stanza 24
XML Stream 22 XML Stream 23
Author's Address Author's Address
Peter Saint-Andre Peter Saint-Andre
Cisco Cisco
Email: psaintan@cisco.com Email: Peter.SaintAndre@WebEx.com
 End of changes. 72 change blocks. 
414 lines changed or deleted 491 lines changed or added

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