draft-ietf-xmpp-3920bis-10.txt   draft-ietf-xmpp-3920bis-11.txt 
Network Working Group P. Saint-Andre Network Working Group P. Saint-Andre
Internet-Draft Cisco Systems, Inc. Internet-Draft Cisco
Obsoletes: 3920 (if approved) July 7, 2010 Obsoletes: 3920 (if approved) July 26, 2010
Intended status: Standards Track Intended status: Standards Track
Expires: January 8, 2011 Expires: January 27, 2011
Extensible Messaging and Presence Protocol (XMPP): Core Extensible Messaging and Presence Protocol (XMPP): Core
draft-ietf-xmpp-3920bis-10 draft-ietf-xmpp-3920bis-11
Abstract Abstract
The Extensible Messaging and Presence Protocol (XMPP) is an The Extensible Messaging and Presence Protocol (XMPP) is an
application profile of the Extensible Markup Language (XML) that application profile of the Extensible Markup Language (XML) that
enables the near-real-time exchange of structured yet extensible data enables the near-real-time exchange of structured yet extensible data
between any two or more network entities. This document defines between any two or more network entities. This document defines
XMPP's core protocol methods: setup and teardown of XML streams, XMPP's core protocol methods: setup and teardown of XML streams,
channel encryption, authentication, error handling, and communication channel encryption, authentication, error handling, and communication
primitives for messaging, network availability ("presence"), and primitives for messaging, network availability ("presence"), and
skipping to change at page 1, line 38 skipping to change at page 1, line 38
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 8, 2011. This Internet-Draft will expire on January 27, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 43 skipping to change at page 2, line 43
3.5. Reliability . . . . . . . . . . . . . . . . . . . . . . 19 3.5. Reliability . . . . . . . . . . . . . . . . . . . . . . 19
4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . . 19 4. XML Streams . . . . . . . . . . . . . . . . . . . . . . . . . 19
4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 19 4.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 19
4.2. Stream Negotiation . . . . . . . . . . . . . . . . . . . 22 4.2. Stream Negotiation . . . . . . . . . . . . . . . . . . . 22
4.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 22 4.2.1. Overview . . . . . . . . . . . . . . . . . . . . . . 22
4.2.2. Stream Features Format . . . . . . . . . . . . . . . 22 4.2.2. Stream Features Format . . . . . . . . . . . . . . . 22
4.2.3. Restarts . . . . . . . . . . . . . . . . . . . . . . 24 4.2.3. Restarts . . . . . . . . . . . . . . . . . . . . . . 24
4.2.4. Resending Features . . . . . . . . . . . . . . . . . 25 4.2.4. Resending Features . . . . . . . . . . . . . . . . . 25
4.2.5. Completion of Stream Negotiation . . . . . . . . . . 25 4.2.5. Completion of Stream Negotiation . . . . . . . . . . 25
4.2.6. Determination of Addresses . . . . . . . . . . . . . 26 4.2.6. Determination of Addresses . . . . . . . . . . . . . 26
4.2.7. Flow Chart . . . . . . . . . . . . . . . . . . . . . 26 4.2.7. Flow Chart . . . . . . . . . . . . . . . . . . . . . 27
4.3. Closing a Stream . . . . . . . . . . . . . . . . . . . . 28 4.3. Closing a Stream . . . . . . . . . . . . . . . . . . . . 29
4.4. Handling of Silent Peers . . . . . . . . . . . . . . . . 28 4.4. Handling of Silent Peers . . . . . . . . . . . . . . . . 29
4.4.1. Idle Peer . . . . . . . . . . . . . . . . . . . . . 29 4.4.1. Idle Peer . . . . . . . . . . . . . . . . . . . . . 30
4.4.2. Broken Stream . . . . . . . . . . . . . . . . . . . 29 4.4.2. Broken Stream . . . . . . . . . . . . . . . . . . . 30
4.4.3. Dead Connection . . . . . . . . . . . . . . . . . . 29 4.4.3. Dead Connection . . . . . . . . . . . . . . . . . . 30
4.4.4. Use of Checking Methods . . . . . . . . . . . . . . 29 4.4.4. Use of Checking Methods . . . . . . . . . . . . . . 31
4.5. Stream Attributes . . . . . . . . . . . . . . . . . . . 30 4.5. Stream Attributes . . . . . . . . . . . . . . . . . . . 31
4.5.1. from . . . . . . . . . . . . . . . . . . . . . . . . 30 4.5.1. from . . . . . . . . . . . . . . . . . . . . . . . . 31
4.5.2. to . . . . . . . . . . . . . . . . . . . . . . . . . 32 4.5.2. to . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.5.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 33 4.5.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 34
4.5.4. xml:lang . . . . . . . . . . . . . . . . . . . . . . 34 4.5.4. xml:lang . . . . . . . . . . . . . . . . . . . . . . 35
4.5.5. version . . . . . . . . . . . . . . . . . . . . . . 35 4.5.5. version . . . . . . . . . . . . . . . . . . . . . . 36
4.5.6. Summary of Stream Attributes . . . . . . . . . . . . 36 4.5.6. Summary of Stream Attributes . . . . . . . . . . . . 38
4.6. Namespaces . . . . . . . . . . . . . . . . . . . . . . . 37 4.6. Namespaces . . . . . . . . . . . . . . . . . . . . . . . 38
4.6.1. Streams Namespace . . . . . . . . . . . . . . . . . 37 4.6.1. Streams Namespace . . . . . . . . . . . . . . . . . 38
4.6.2. Default Namespace . . . . . . . . . . . . . . . . . 37 4.6.2. Default Namespace . . . . . . . . . . . . . . . . . 38
4.6.3. Other Namespaces . . . . . . . . . . . . . . . . . . 38 4.6.3. Other Namespaces . . . . . . . . . . . . . . . . . . 39
4.6.4. Namespace Declarations and Prefixes . . . . . . . . 38 4.6.4. Namespace Declarations and Prefixes . . . . . . . . 40
4.6.5. Mandatory-to-Implement Default Namespaces . . . . . 39 4.6.5. Mandatory-to-Implement Default Namespaces . . . . . 40
4.7. Stream Errors . . . . . . . . . . . . . . . . . . . . . 40 4.7. Stream Errors . . . . . . . . . . . . . . . . . . . . . 41
4.7.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 40 4.7.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 42
4.7.1.1. Stream Errors Are Unrecoverable . . . . . . . . . 40 4.7.1.1. Stream Errors Are Unrecoverable . . . . . . . . . 42
4.7.1.2. Stream Errors Can Occur During Setup . . . . . . 41 4.7.1.2. Stream Errors Can Occur During Setup . . . . . . 42
4.7.1.3. Stream Errors When the Host is Unspecified or 4.7.1.3. Stream Errors When the Host is Unspecified or
Unknown . . . . . . . . . . . . . . . . . . . . . 42 Unknown . . . . . . . . . . . . . . . . . . . . . 43
4.7.1.4. Where Stream Errors Are Sent . . . . . . . . . . 42 4.7.1.4. Where Stream Errors Are Sent . . . . . . . . . . 44
4.7.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 43 4.7.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 44
4.7.3. Defined Stream Error Conditions . . . . . . . . . . 43 4.7.3. Defined Stream Error Conditions . . . . . . . . . . 45
4.7.3.1. bad-format . . . . . . . . . . . . . . . . . . . 44 4.7.3.1. bad-format . . . . . . . . . . . . . . . . . . . 45
4.7.3.2. bad-namespace-prefix . . . . . . . . . . . . . . 44 4.7.3.2. bad-namespace-prefix . . . . . . . . . . . . . . 46
4.7.3.3. conflict . . . . . . . . . . . . . . . . . . . . 45 4.7.3.3. conflict . . . . . . . . . . . . . . . . . . . . 47
4.7.3.4. connection-timeout . . . . . . . . . . . . . . . 46 4.7.3.4. connection-timeout . . . . . . . . . . . . . . . 47
4.7.3.5. host-gone . . . . . . . . . . . . . . . . . . . . 47 4.7.3.5. host-gone . . . . . . . . . . . . . . . . . . . . 48
4.7.3.6. host-unknown . . . . . . . . . . . . . . . . . . 47 4.7.3.6. host-unknown . . . . . . . . . . . . . . . . . . 48
4.7.3.7. improper-addressing . . . . . . . . . . . . . . . 48 4.7.3.7. improper-addressing . . . . . . . . . . . . . . . 49
4.7.3.8. internal-server-error . . . . . . . . . . . . . . 48 4.7.3.8. internal-server-error . . . . . . . . . . . . . . 50
4.7.3.9. invalid-from . . . . . . . . . . . . . . . . . . 49 4.7.3.9. invalid-from . . . . . . . . . . . . . . . . . . 50
4.7.3.10. invalid-namespace . . . . . . . . . . . . . . . . 49 4.7.3.10. invalid-namespace . . . . . . . . . . . . . . . . 50
4.7.3.11. invalid-xml . . . . . . . . . . . . . . . . . . . 50 4.7.3.11. invalid-xml . . . . . . . . . . . . . . . . . . . 51
4.7.3.12. not-authorized . . . . . . . . . . . . . . . . . 51 4.7.3.12. not-authorized . . . . . . . . . . . . . . . . . 52
4.7.3.13. policy-violation . . . . . . . . . . . . . . . . 51 4.7.3.13. policy-violation . . . . . . . . . . . . . . . . 52
4.7.3.14. remote-connection-failed . . . . . . . . . . . . 52 4.7.3.14. remote-connection-failed . . . . . . . . . . . . 53
4.7.3.15. reset . . . . . . . . . . . . . . . . . . . . . . 52 4.7.3.15. reset . . . . . . . . . . . . . . . . . . . . . . 53
4.7.3.16. resource-constraint . . . . . . . . . . . . . . . 53 4.7.3.16. resource-constraint . . . . . . . . . . . . . . . 54
4.7.3.17. restricted-xml . . . . . . . . . . . . . . . . . 53 4.7.3.17. restricted-xml . . . . . . . . . . . . . . . . . 54
4.7.3.18. see-other-host . . . . . . . . . . . . . . . . . 54 4.7.3.18. see-other-host . . . . . . . . . . . . . . . . . 55
4.7.3.19. system-shutdown . . . . . . . . . . . . . . . . . 55 4.7.3.19. system-shutdown . . . . . . . . . . . . . . . . . 56
4.7.3.20. undefined-condition . . . . . . . . . . . . . . . 55 4.7.3.20. undefined-condition . . . . . . . . . . . . . . . 56
4.7.3.21. unsupported-encoding . . . . . . . . . . . . . . 56 4.7.3.21. unsupported-encoding . . . . . . . . . . . . . . 57
4.7.3.22. unsupported-feature . . . . . . . . . . . . . . . 56 4.7.3.22. unsupported-feature . . . . . . . . . . . . . . . 57
4.7.3.23. unsupported-stanza-type . . . . . . . . . . . . . 57 4.7.3.23. unsupported-stanza-type . . . . . . . . . . . . . 58
4.7.3.24. unsupported-version . . . . . . . . . . . . . . . 58 4.7.3.24. unsupported-version . . . . . . . . . . . . . . . 59
4.7.3.25. xml-not-well-formed . . . . . . . . . . . . . . . 59 4.7.3.25. xml-not-well-formed . . . . . . . . . . . . . . . 60
4.7.4. Application-Specific Conditions . . . . . . . . . . 59 4.7.4. Application-Specific Conditions . . . . . . . . . . 60
4.8. Simplified Stream Examples . . . . . . . . . . . . . . . 60 4.8. Simplified Stream Examples . . . . . . . . . . . . . . . 61
5. STARTTLS Negotiation . . . . . . . . . . . . . . . . . . . . 62 5. STARTTLS Negotiation . . . . . . . . . . . . . . . . . . . . 63
5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 63 5.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 64
5.2. Stream Negotiation Rules . . . . . . . . . . . . . . . . 63 5.2. Stream Negotiation Rules . . . . . . . . . . . . . . . . 64
5.2.1. Mandatory-to-Negotiate . . . . . . . . . . . . . . . 63 5.2.1. Mandatory-to-Negotiate . . . . . . . . . . . . . . . 64
5.2.2. Restart . . . . . . . . . . . . . . . . . . . . . . 63 5.2.2. Restart . . . . . . . . . . . . . . . . . . . . . . 64
5.2.3. Data Formatting . . . . . . . . . . . . . . . . . . 63 5.2.3. Data Formatting . . . . . . . . . . . . . . . . . . 64
5.2.4. Order of TLS and SASL Negotiations . . . . . . . . . 64 5.2.4. Order of TLS and SASL Negotiations . . . . . . . . . 65
5.2.5. TLS Renegotiation . . . . . . . . . . . . . . . . . 64 5.2.5. TLS Renegotiation . . . . . . . . . . . . . . . . . 65
5.2.6. TLS Extensions . . . . . . . . . . . . . . . . . . . 65 5.2.6. TLS Extensions . . . . . . . . . . . . . . . . . . . 66
5.3. Process . . . . . . . . . . . . . . . . . . . . . . . . 65 5.3. Process . . . . . . . . . . . . . . . . . . . . . . . . 66
5.3.1. Exchange of Stream Headers and Stream Features . . . 65 5.3.1. Exchange of Stream Headers and Stream Features . . . 66
5.3.2. Initiation of STARTTLS Negotiation . . . . . . . . . 66 5.3.2. Initiation of STARTTLS Negotiation . . . . . . . . . 67
5.3.2.1. STARTTLS Command . . . . . . . . . . . . . . . . 66 5.3.2.1. STARTTLS Command . . . . . . . . . . . . . . . . 67
5.3.2.2. Failure Case . . . . . . . . . . . . . . . . . . 66 5.3.2.2. Failure Case . . . . . . . . . . . . . . . . . . 67
5.3.2.3. Proceed Case . . . . . . . . . . . . . . . . . . 67 5.3.2.3. Proceed Case . . . . . . . . . . . . . . . . . . 68
5.3.3. TLS Negotiation . . . . . . . . . . . . . . . . . . 67 5.3.3. TLS Negotiation . . . . . . . . . . . . . . . . . . 68
5.3.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . 67 5.3.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . 68
5.3.3.2. TLS Failure . . . . . . . . . . . . . . . . . . . 68 5.3.3.2. TLS Failure . . . . . . . . . . . . . . . . . . . 69
5.3.3.3. TLS Success . . . . . . . . . . . . . . . . . . . 68 5.3.3.3. TLS Success . . . . . . . . . . . . . . . . . . . 69
6. SASL Negotiation . . . . . . . . . . . . . . . . . . . . . . 70 6. SASL Negotiation . . . . . . . . . . . . . . . . . . . . . . 71
6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 70 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 71
6.2. Stream Negotiation Rules . . . . . . . . . . . . . . . . 70 6.2. Stream Negotiation Rules . . . . . . . . . . . . . . . . 71
6.2.1. Mandatory-to-Negotiate . . . . . . . . . . . . . . . 70 6.2.1. Mandatory-to-Negotiate . . . . . . . . . . . . . . . 71
6.2.2. Restart . . . . . . . . . . . . . . . . . . . . . . 70 6.2.2. Restart . . . . . . . . . . . . . . . . . . . . . . 71
6.2.3. Mechanism Preferences . . . . . . . . . . . . . . . 70 6.2.3. Mechanism Preferences . . . . . . . . . . . . . . . 71
6.2.4. Mechanism Offers . . . . . . . . . . . . . . . . . . 71 6.2.4. Mechanism Offers . . . . . . . . . . . . . . . . . . 72
6.2.5. Data Formatting . . . . . . . . . . . . . . . . . . 71 6.2.5. Data Formatting . . . . . . . . . . . . . . . . . . 72
6.2.6. Security Layers . . . . . . . . . . . . . . . . . . 72 6.2.6. Security Layers . . . . . . . . . . . . . . . . . . 73
6.2.7. Simple Username . . . . . . . . . . . . . . . . . . 72 6.2.7. Simple Username . . . . . . . . . . . . . . . . . . 73
6.2.8. Authorization Identity . . . . . . . . . . . . . . . 72 6.2.8. Authorization Identity . . . . . . . . . . . . . . . 73
6.2.9. Realms . . . . . . . . . . . . . . . . . . . . . . . 73 6.2.9. Realms . . . . . . . . . . . . . . . . . . . . . . . 74
6.2.10. Round Trips . . . . . . . . . . . . . . . . . . . . 73 6.2.10. Round Trips . . . . . . . . . . . . . . . . . . . . 74
6.3. Process . . . . . . . . . . . . . . . . . . . . . . . . 74 6.3. Process . . . . . . . . . . . . . . . . . . . . . . . . 75
6.3.1. Exchange of Stream Headers and Stream Features . . . 74 6.3.1. Exchange of Stream Headers and Stream Features . . . 75
6.3.2. Initiation . . . . . . . . . . . . . . . . . . . . . 75 6.3.2. Initiation . . . . . . . . . . . . . . . . . . . . . 76
6.3.3. Challenge-Response Sequence . . . . . . . . . . . . 75 6.3.3. Challenge-Response Sequence . . . . . . . . . . . . 76
6.3.4. Abort . . . . . . . . . . . . . . . . . . . . . . . 76 6.3.4. Abort . . . . . . . . . . . . . . . . . . . . . . . 77
6.3.5. Failure . . . . . . . . . . . . . . . . . . . . . . 76 6.3.5. Failure . . . . . . . . . . . . . . . . . . . . . . 77
6.3.6. Success . . . . . . . . . . . . . . . . . . . . . . 77 6.3.6. Success . . . . . . . . . . . . . . . . . . . . . . 78
6.4. SASL Errors . . . . . . . . . . . . . . . . . . . . . . 78 6.4. SASL Errors . . . . . . . . . . . . . . . . . . . . . . 79
6.4.1. aborted . . . . . . . . . . . . . . . . . . . . . . 79 6.4.1. aborted . . . . . . . . . . . . . . . . . . . . . . 80
6.4.2. account-disabled . . . . . . . . . . . . . . . . . . 79 6.4.2. account-disabled . . . . . . . . . . . . . . . . . . 80
6.4.3. credentials-expired . . . . . . . . . . . . . . . . 79 6.4.3. credentials-expired . . . . . . . . . . . . . . . . 80
6.4.4. encryption-required . . . . . . . . . . . . . . . . 79 6.4.4. encryption-required . . . . . . . . . . . . . . . . 80
6.4.5. incorrect-encoding . . . . . . . . . . . . . . . . . 80 6.4.5. incorrect-encoding . . . . . . . . . . . . . . . . . 81
6.4.6. invalid-authzid . . . . . . . . . . . . . . . . . . 80 6.4.6. invalid-authzid . . . . . . . . . . . . . . . . . . 81
6.4.7. invalid-mechanism . . . . . . . . . . . . . . . . . 80 6.4.7. invalid-mechanism . . . . . . . . . . . . . . . . . 81
6.4.8. malformed-request . . . . . . . . . . . . . . . . . 81 6.4.8. malformed-request . . . . . . . . . . . . . . . . . 82
6.4.9. mechanism-too-weak . . . . . . . . . . . . . . . . . 81 6.4.9. mechanism-too-weak . . . . . . . . . . . . . . . . . 82
6.4.10. not-authorized . . . . . . . . . . . . . . . . . . . 81 6.4.10. not-authorized . . . . . . . . . . . . . . . . . . . 82
6.4.11. temporary-auth-failure . . . . . . . . . . . . . . . 82 6.4.11. temporary-auth-failure . . . . . . . . . . . . . . . 83
6.4.12. transition-needed . . . . . . . . . . . . . . . . . 82 6.4.12. transition-needed . . . . . . . . . . . . . . . . . 83
6.5. SASL Definition . . . . . . . . . . . . . . . . . . . . 83 6.5. SASL Definition . . . . . . . . . . . . . . . . . . . . 84
7. Resource Binding . . . . . . . . . . . . . . . . . . . . . . 83 7. Resource Binding . . . . . . . . . . . . . . . . . . . . . . 84
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 83 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 84
7.2. Stream Negotiation Rules . . . . . . . . . . . . . . . . 84 7.2. Stream Negotiation Rules . . . . . . . . . . . . . . . . 85
7.2.1. Mandatory-to-Negotiate . . . . . . . . . . . . . . . 84 7.2.1. Mandatory-to-Negotiate . . . . . . . . . . . . . . . 85
7.2.2. Restart . . . . . . . . . . . . . . . . . . . . . . 84 7.2.2. Restart . . . . . . . . . . . . . . . . . . . . . . 85
7.3. Advertising Support . . . . . . . . . . . . . . . . . . 84 7.3. Advertising Support . . . . . . . . . . . . . . . . . . 85
7.4. Generation of Resource Identifiers . . . . . . . . . . . 85 7.4. Generation of Resource Identifiers . . . . . . . . . . . 86
7.5. Server-Generated Resource Identifier . . . . . . . . . . 85 7.5. Server-Generated Resource Identifier . . . . . . . . . . 86
7.5.1. Success Case . . . . . . . . . . . . . . . . . . . . 85 7.5.1. Success Case . . . . . . . . . . . . . . . . . . . . 86
7.5.2. Error Cases . . . . . . . . . . . . . . . . . . . . 86 7.5.2. Error Cases . . . . . . . . . . . . . . . . . . . . 87
7.5.2.1. Resource Constraint . . . . . . . . . . . . . . . 86 7.5.2.1. Resource Constraint . . . . . . . . . . . . . . . 87
7.5.2.2. Not Allowed . . . . . . . . . . . . . . . . . . . 86 7.5.2.2. Not Allowed . . . . . . . . . . . . . . . . . . . 87
7.6. Client-Submitted Resource Identifier . . . . . . . . . . 87 7.6. Client-Submitted Resource Identifier . . . . . . . . . . 88
7.6.1. Success Case . . . . . . . . . . . . . . . . . . . . 87 7.6.1. Success Case . . . . . . . . . . . . . . . . . . . . 88
7.6.2. Error Cases . . . . . . . . . . . . . . . . . . . . 88 7.6.2. Error Cases . . . . . . . . . . . . . . . . . . . . 89
7.6.2.1. Bad Request . . . . . . . . . . . . . . . . . . . 88 7.6.2.1. Bad Request . . . . . . . . . . . . . . . . . . . 89
7.6.2.2. Conflict . . . . . . . . . . . . . . . . . . . . 88 7.6.2.2. Conflict . . . . . . . . . . . . . . . . . . . . 89
7.6.3. Retries . . . . . . . . . . . . . . . . . . . . . . 89 7.6.3. Retries . . . . . . . . . . . . . . . . . . . . . . 90
8. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 89 8. XML Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 90
8.1. Common Attributes . . . . . . . . . . . . . . . . . . . 90 8.1. Common Attributes . . . . . . . . . . . . . . . . . . . 91
8.1.1. to . . . . . . . . . . . . . . . . . . . . . . . . . 90 8.1.1. to . . . . . . . . . . . . . . . . . . . . . . . . . 91
8.1.1.1. Client-to-Server Streams . . . . . . . . . . . . 90 8.1.1.1. Client-to-Server Streams . . . . . . . . . . . . 91
8.1.1.2. Server-to-Server Streams . . . . . . . . . . . . 91 8.1.1.2. Server-to-Server Streams . . . . . . . . . . . . 92
8.1.2. from . . . . . . . . . . . . . . . . . . . . . . . . 91 8.1.2. from . . . . . . . . . . . . . . . . . . . . . . . . 92
8.1.2.1. Client-to-Server Streams . . . . . . . . . . . . 91 8.1.2.1. Client-to-Server Streams . . . . . . . . . . . . 92
8.1.2.2. Server-to-Server Streams . . . . . . . . . . . . 92 8.1.2.2. Server-to-Server Streams . . . . . . . . . . . . 93
8.1.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 92 8.1.3. id . . . . . . . . . . . . . . . . . . . . . . . . . 93
8.1.4. type . . . . . . . . . . . . . . . . . . . . . . . . 93 8.1.4. type . . . . . . . . . . . . . . . . . . . . . . . . 94
8.1.5. xml:lang . . . . . . . . . . . . . . . . . . . . . . 93 8.1.5. xml:lang . . . . . . . . . . . . . . . . . . . . . . 94
8.2. Basic Semantics . . . . . . . . . . . . . . . . . . . . 94 8.2. Basic Semantics . . . . . . . . . . . . . . . . . . . . 95
8.2.1. Message Semantics . . . . . . . . . . . . . . . . . 94 8.2.1. Message Semantics . . . . . . . . . . . . . . . . . 95
8.2.2. Presence Semantics . . . . . . . . . . . . . . . . . 94 8.2.2. Presence Semantics . . . . . . . . . . . . . . . . . 95
8.2.3. IQ Semantics . . . . . . . . . . . . . . . . . . . . 95 8.2.3. IQ Semantics . . . . . . . . . . . . . . . . . . . . 96
8.3. Stanza Errors . . . . . . . . . . . . . . . . . . . . . 96 8.3. Stanza Errors . . . . . . . . . . . . . . . . . . . . . 97
8.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 97 8.3.1. Rules . . . . . . . . . . . . . . . . . . . . . . . 98
8.3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 98 8.3.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . 99
8.3.3. Defined Conditions . . . . . . . . . . . . . . . . . 99 8.3.3. Defined Conditions . . . . . . . . . . . . . . . . . 100
8.3.3.1. bad-request . . . . . . . . . . . . . . . . . . . 99 8.3.3.1. bad-request . . . . . . . . . . . . . . . . . . . 100
8.3.3.2. conflict . . . . . . . . . . . . . . . . . . . . 100 8.3.3.2. conflict . . . . . . . . . . . . . . . . . . . . 101
8.3.3.3. feature-not-implemented . . . . . . . . . . . . . 100 8.3.3.3. feature-not-implemented . . . . . . . . . . . . . 101
8.3.3.4. forbidden . . . . . . . . . . . . . . . . . . . . 101 8.3.3.4. forbidden . . . . . . . . . . . . . . . . . . . . 102
8.3.3.5. gone . . . . . . . . . . . . . . . . . . . . . . 102 8.3.3.5. gone . . . . . . . . . . . . . . . . . . . . . . 103
8.3.3.6. internal-server-error . . . . . . . . . . . . . . 102 8.3.3.6. internal-server-error . . . . . . . . . . . . . . 103
8.3.3.7. item-not-found . . . . . . . . . . . . . . . . . 103 8.3.3.7. item-not-found . . . . . . . . . . . . . . . . . 104
8.3.3.8. jid-malformed . . . . . . . . . . . . . . . . . . 103 8.3.3.8. jid-malformed . . . . . . . . . . . . . . . . . . 104
8.3.3.9. not-acceptable . . . . . . . . . . . . . . . . . 104 8.3.3.9. not-acceptable . . . . . . . . . . . . . . . . . 105
8.3.3.10. not-allowed . . . . . . . . . . . . . . . . . . . 105 8.3.3.10. not-allowed . . . . . . . . . . . . . . . . . . . 106
8.3.3.11. not-authorized . . . . . . . . . . . . . . . . . 105 8.3.3.11. not-authorized . . . . . . . . . . . . . . . . . 106
8.3.3.12. payment-required . . . . . . . . . . . . . . . . 106 8.3.3.12. payment-required . . . . . . . . . . . . . . . . 107
8.3.3.13. policy-violation . . . . . . . . . . . . . . . . 106 8.3.3.13. policy-violation . . . . . . . . . . . . . . . . 107
8.3.3.14. recipient-unavailable . . . . . . . . . . . . . . 107 8.3.3.14. recipient-unavailable . . . . . . . . . . . . . . 108
8.3.3.15. redirect . . . . . . . . . . . . . . . . . . . . 108 8.3.3.15. redirect . . . . . . . . . . . . . . . . . . . . 109
8.3.3.16. registration-required . . . . . . . . . . . . . . 108 8.3.3.16. registration-required . . . . . . . . . . . . . . 109
8.3.3.17. remote-server-not-found . . . . . . . . . . . . . 109 8.3.3.17. remote-server-not-found . . . . . . . . . . . . . 110
8.3.3.18. remote-server-timeout . . . . . . . . . . . . . . 110 8.3.3.18. remote-server-timeout . . . . . . . . . . . . . . 111
8.3.3.19. resource-constraint . . . . . . . . . . . . . . . 110 8.3.3.19. resource-constraint . . . . . . . . . . . . . . . 111
8.3.3.20. service-unavailable . . . . . . . . . . . . . . . 111 8.3.3.20. service-unavailable . . . . . . . . . . . . . . . 112
8.3.3.21. subscription-required . . . . . . . . . . . . . . 111 8.3.3.21. subscription-required . . . . . . . . . . . . . . 112
8.3.3.22. undefined-condition . . . . . . . . . . . . . . . 112 8.3.3.22. undefined-condition . . . . . . . . . . . . . . . 113
8.3.3.23. unexpected-request . . . . . . . . . . . . . . . 113 8.3.3.23. unexpected-request . . . . . . . . . . . . . . . 114
8.3.4. Application-Specific Conditions . . . . . . . . . . 114 8.3.4. Application-Specific Conditions . . . . . . . . . . 115
8.4. Extended Content . . . . . . . . . . . . . . . . . . . . 115 8.4. Extended Content . . . . . . . . . . . . . . . . . . . . 116
9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 118 9. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 119
9.1. Client-to-Server Examples . . . . . . . . . . . . . . . 118 9.1. Client-to-Server Examples . . . . . . . . . . . . . . . 119
9.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 118 9.1.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 119
9.1.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 120 9.1.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 121
9.1.3. Resource Binding . . . . . . . . . . . . . . . . . . 122 9.1.3. Resource Binding . . . . . . . . . . . . . . . . . . 123
9.1.4. Stanza Exchange . . . . . . . . . . . . . . . . . . 123 9.1.4. Stanza Exchange . . . . . . . . . . . . . . . . . . 124
9.1.5. Close . . . . . . . . . . . . . . . . . . . . . . . 123 9.1.5. Close . . . . . . . . . . . . . . . . . . . . . . . 124
9.2. Server-to-Server Examples . . . . . . . . . . . . . . . 124 9.2. Server-to-Server Examples . . . . . . . . . . . . . . . 125
9.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 124 9.2.1. TLS . . . . . . . . . . . . . . . . . . . . . . . . 125
9.2.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 125 9.2.2. SASL . . . . . . . . . . . . . . . . . . . . . . . . 126
9.2.3. Stanza Exchange . . . . . . . . . . . . . . . . . . 126 9.2.3. Stanza Exchange . . . . . . . . . . . . . . . . . . 127
9.2.4. Close . . . . . . . . . . . . . . . . . . . . . . . 127 9.2.4. Close . . . . . . . . . . . . . . . . . . . . . . . 128
10. Server Rules for Processing XML Stanzas . . . . . . . . . . . 127 10. Server Rules for Processing XML Stanzas . . . . . . . . . . . 128
10.1. No 'to' Address . . . . . . . . . . . . . . . . . . . . 128 10.1. No 'to' Address . . . . . . . . . . . . . . . . . . . . 129
10.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 128 10.1.1. Overview . . . . . . . . . . . . . . . . . . . . . . 129
10.1.2. Message . . . . . . . . . . . . . . . . . . . . . . 128 10.1.2. Message . . . . . . . . . . . . . . . . . . . . . . 129
10.1.3. Presence . . . . . . . . . . . . . . . . . . . . . . 128 10.1.3. Presence . . . . . . . . . . . . . . . . . . . . . . 129
10.1.4. IQ . . . . . . . . . . . . . . . . . . . . . . . . . 128 10.1.4. IQ . . . . . . . . . . . . . . . . . . . . . . . . . 129
10.2. Remote Domain . . . . . . . . . . . . . . . . . . . . . 129 10.2. Remote Domain . . . . . . . . . . . . . . . . . . . . . 130
10.2.1. Existing Stream . . . . . . . . . . . . . . . . . . 129 10.2.1. Existing Stream . . . . . . . . . . . . . . . . . . 130
10.2.2. No Existing Stream . . . . . . . . . . . . . . . . . 129 10.2.2. No Existing Stream . . . . . . . . . . . . . . . . . 130
10.2.3. Error Handling . . . . . . . . . . . . . . . . . . . 130 10.2.3. Error Handling . . . . . . . . . . . . . . . . . . . 131
10.3. Local Domain . . . . . . . . . . . . . . . . . . . . . . 130 10.3. Local Domain . . . . . . . . . . . . . . . . . . . . . . 131
10.3.1. Mere Domain . . . . . . . . . . . . . . . . . . . . 130 10.3.1. Mere Domain . . . . . . . . . . . . . . . . . . . . 131
10.3.2. Domain with Resource . . . . . . . . . . . . . . . . 130 10.3.2. Domain with Resource . . . . . . . . . . . . . . . . 131
10.3.3. Localpart at Domain . . . . . . . . . . . . . . . . 130 10.3.3. Localpart at Domain . . . . . . . . . . . . . . . . 131
10.3.3.1. No Such User . . . . . . . . . . . . . . . . . . 130 10.3.3.1. No Such User . . . . . . . . . . . . . . . . . . 131
10.3.3.2. Bare JID . . . . . . . . . . . . . . . . . . . . 131 10.3.3.2. Bare JID . . . . . . . . . . . . . . . . . . . . 132
10.3.3.3. Full JID . . . . . . . . . . . . . . . . . . . . 131 10.3.3.3. Full JID . . . . . . . . . . . . . . . . . . . . 132
11. XML Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 131 11. XML Usage . . . . . . . . . . . . . . . . . . . . . . . . . . 132
11.1. Restrictions . . . . . . . . . . . . . . . . . . . . . . 132 11.1. Restrictions . . . . . . . . . . . . . . . . . . . . . . 133
11.2. XML Namespace Names and Prefixes . . . . . . . . . . . . 132 11.2. XML Namespace Names and Prefixes . . . . . . . . . . . . 133
11.3. Well-Formedness . . . . . . . . . . . . . . . . . . . . 132 11.3. Well-Formedness . . . . . . . . . . . . . . . . . . . . 133
11.4. Validation . . . . . . . . . . . . . . . . . . . . . . . 133 11.4. Validation . . . . . . . . . . . . . . . . . . . . . . . 134
11.5. Inclusion of XML Declaration . . . . . . . . . . . . . . 133 11.5. Inclusion of XML Declaration . . . . . . . . . . . . . . 134
11.6. Character Encoding . . . . . . . . . . . . . . . . . . . 134 11.6. Character Encoding . . . . . . . . . . . . . . . . . . . 135
11.7. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 134 11.7. Whitespace . . . . . . . . . . . . . . . . . . . . . . . 135
11.8. XML Versions . . . . . . . . . . . . . . . . . . . . . . 134 11.8. XML Versions . . . . . . . . . . . . . . . . . . . . . . 135
12. Internationalization Considerations . . . . . . . . . . . . . 134 12. Internationalization Considerations . . . . . . . . . . . . . 135
13. Security Considerations . . . . . . . . . . . . . . . . . . . 135 13. Security Considerations . . . . . . . . . . . . . . . . . . . 136
13.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 135 13.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 136
13.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 136 13.2. Threat Model . . . . . . . . . . . . . . . . . . . . . . 137
13.3. Order of Layers . . . . . . . . . . . . . . . . . . . . 136 13.3. Order of Layers . . . . . . . . . . . . . . . . . . . . 137
13.4. Confidentiality and Integrity . . . . . . . . . . . . . 136 13.4. Confidentiality and Integrity . . . . . . . . . . . . . 137
13.5. Peer Entity Authentication . . . . . . . . . . . . . . . 137 13.5. Peer Entity Authentication . . . . . . . . . . . . . . . 138
13.6. Strong Security . . . . . . . . . . . . . . . . . . . . 137 13.6. Strong Security . . . . . . . . . . . . . . . . . . . . 138
13.7. Certificates . . . . . . . . . . . . . . . . . . . . . . 137 13.7. Certificates . . . . . . . . . . . . . . . . . . . . . . 138
13.7.1. Certificate Generation . . . . . . . . . . . . . . . 138 13.7.1. Certificate Generation . . . . . . . . . . . . . . . 139
13.7.1.1. General Considerations . . . . . . . . . . . . . 138 13.7.1.1. General Considerations . . . . . . . . . . . . . 139
13.7.1.2. Server Certificates . . . . . . . . . . . . . . . 138 13.7.1.2. Server Certificates . . . . . . . . . . . . . . . 139
13.7.1.3. Client Certificates . . . . . . . . . . . . . . . 141 13.7.1.3. Client Certificates . . . . . . . . . . . . . . . 142
13.7.1.4. XmppAddr Identifier Type . . . . . . . . . . . . 141 13.7.1.4. XmppAddr Identifier Type . . . . . . . . . . . . 142
13.7.2. Certificate Validation . . . . . . . . . . . . . . . 142 13.7.2. Certificate Validation . . . . . . . . . . . . . . . 143
13.7.2.1. Server Certificates . . . . . . . . . . . . . . . 142 13.7.2.1. Server Certificates . . . . . . . . . . . . . . . 143
13.7.2.2. Client Certificates . . . . . . . . . . . . . . . 142 13.7.2.2. Client Certificates . . . . . . . . . . . . . . . 143
13.7.2.3. Checking of Certificates in Long-Lived Streams . 143 13.7.2.3. Checking of Certificates in Long-Lived Streams . 144
13.7.2.4. Use of Certificates in XMPP Extensions . . . . . 144 13.7.2.4. Use of Certificates in XMPP Extensions . . . . . 145
13.8. Mandatory-to-Implement Technologies . . . . . . . . . . 144 13.8. Mandatory-to-Implement Technologies . . . . . . . . . . 145
13.9. Technology Reuse . . . . . . . . . . . . . . . . . . . . 145 13.9. Technology Reuse . . . . . . . . . . . . . . . . . . . . 146
13.9.1. Use of base64 in SASL . . . . . . . . . . . . . . . 145 13.9.1. Use of base64 in SASL . . . . . . . . . . . . . . . 146
13.9.2. Use of DNS . . . . . . . . . . . . . . . . . . . . . 145 13.9.2. Use of DNS . . . . . . . . . . . . . . . . . . . . . 146
13.9.3. Use of Hash Functions . . . . . . . . . . . . . . . 146 13.9.3. Use of Hash Functions . . . . . . . . . . . . . . . 147
13.9.4. Use of SASL . . . . . . . . . . . . . . . . . . . . 146 13.9.4. Use of SASL . . . . . . . . . . . . . . . . . . . . 147
13.9.5. Use of TLS . . . . . . . . . . . . . . . . . . . . . 147 13.9.5. Use of TLS . . . . . . . . . . . . . . . . . . . . . 148
13.9.6. Use of UTF-8 . . . . . . . . . . . . . . . . . . . . 147 13.9.6. Use of UTF-8 . . . . . . . . . . . . . . . . . . . . 148
13.9.7. Use of XML . . . . . . . . . . . . . . . . . . . . . 148 13.9.7. Use of XML . . . . . . . . . . . . . . . . . . . . . 149
13.10. Information Leaks . . . . . . . . . . . . . . . . . . . 148 13.10. Information Leaks . . . . . . . . . . . . . . . . . . . 149
13.10.1. IP Addresses . . . . . . . . . . . . . . . . . . . . 148 13.10.1. IP Addresses . . . . . . . . . . . . . . . . . . . . 149
13.10.2. Presence Information . . . . . . . . . . . . . . . . 148 13.10.2. Presence Information . . . . . . . . . . . . . . . . 149
13.11. Directory Harvesting . . . . . . . . . . . . . . . . . . 148 13.11. Directory Harvesting . . . . . . . . . . . . . . . . . . 149
13.12. Denial of Service . . . . . . . . . . . . . . . . . . . 149 13.12. Denial of Service . . . . . . . . . . . . . . . . . . . 150
13.13. Firewalls . . . . . . . . . . . . . . . . . . . . . . . 150 13.13. Firewalls . . . . . . . . . . . . . . . . . . . . . . . 151
13.14. Interdomain Federation . . . . . . . . . . . . . . . . . 151 13.14. Interdomain Federation . . . . . . . . . . . . . . . . . 152
13.15. Non-Repudiation . . . . . . . . . . . . . . . . . . . . 151 13.15. Non-Repudiation . . . . . . . . . . . . . . . . . . . . 152
14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 151 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 152
14.1. XML Namespace Name for TLS Data . . . . . . . . . . . . 151 14.1. XML Namespace Name for TLS Data . . . . . . . . . . . . 152
14.2. XML Namespace Name for SASL Data . . . . . . . . . . . . 152 14.2. XML Namespace Name for SASL Data . . . . . . . . . . . . 153
14.3. XML Namespace Name for Stream Errors . . . . . . . . . . 152 14.3. XML Namespace Name for Stream Errors . . . . . . . . . . 153
14.4. XML Namespace Name for Resource Binding . . . . . . . . 152 14.4. XML Namespace Name for Resource Binding . . . . . . . . 153
14.5. XML Namespace Name for Stanza Errors . . . . . . . . . . 153 14.5. XML Namespace Name for Stanza Errors . . . . . . . . . . 154
14.6. GSSAPI Service Name . . . . . . . . . . . . . . . . . . 153 14.6. GSSAPI Service Name . . . . . . . . . . . . . . . . . . 154
14.7. Port Numbers . . . . . . . . . . . . . . . . . . . . . . 153 14.7. Port Numbers . . . . . . . . . . . . . . . . . . . . . . 154
15. Conformance Requirements . . . . . . . . . . . . . . . . . . 153 15. Conformance Requirements . . . . . . . . . . . . . . . . . . 154
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 162 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 163
16.1. Normative References . . . . . . . . . . . . . . . . . . 162 16.1. Normative References . . . . . . . . . . . . . . . . . . 163
16.2. Informative References . . . . . . . . . . . . . . . . . 165 16.2. Informative References . . . . . . . . . . . . . . . . . 166
Appendix A. XML Schemas . . . . . . . . . . . . . . . . . . . . 170 Appendix A. XML Schemas . . . . . . . . . . . . . . . . . . . . 171
A.1. Streams Namespace . . . . . . . . . . . . . . . . . . . 170 A.1. Streams Namespace . . . . . . . . . . . . . . . . . . . 171
A.2. Stream Error Namespace . . . . . . . . . . . . . . . . . 172 A.2. Stream Error Namespace . . . . . . . . . . . . . . . . . 173
A.3. STARTTLS Namespace . . . . . . . . . . . . . . . . . . . 174 A.3. STARTTLS Namespace . . . . . . . . . . . . . . . . . . . 175
A.4. SASL Namespace . . . . . . . . . . . . . . . . . . . . . 174 A.4. SASL Namespace . . . . . . . . . . . . . . . . . . . . . 175
A.5. Resource Binding Namespace . . . . . . . . . . . . . . . 177 A.5. Resource Binding Namespace . . . . . . . . . . . . . . . 178
A.6. Stanza Error Namespace . . . . . . . . . . . . . . . . . 177 A.6. Stanza Error Namespace . . . . . . . . . . . . . . . . . 178
Appendix B. Contact Addresses . . . . . . . . . . . . . . . . . 179 Appendix B. Contact Addresses . . . . . . . . . . . . . . . . . 180
Appendix C. Account Provisioning . . . . . . . . . . . . . . . . 179 Appendix C. Account Provisioning . . . . . . . . . . . . . . . . 180
Appendix D. Differences from RFC 3920 . . . . . . . . . . . . . 179 Appendix D. Differences from RFC 3920 . . . . . . . . . . . . . 180
Appendix E. Copying Conditions . . . . . . . . . . . . . . . . . 181 Appendix E. Copying Conditions . . . . . . . . . . . . . . . . . 182
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 181 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 182
1. Introduction 1. Introduction
1.1. Overview 1.1. Overview
The Extensible Messaging and Presence Protocol (XMPP) is an The Extensible Messaging and Presence Protocol (XMPP) is an
application profile of the Extensible Markup Language [XML] that application profile of the Extensible Markup Language [XML] that
enables the near-real-time exchange of structured yet extensible data enables the near-real-time exchange of structured yet extensible data
between any two or more network entities. This document defines between any two or more network entities. This document defines
XMPP's core protocol methods: setup and teardown of XML streams, XMPP's core protocol methods: setup and teardown of XML streams,
skipping to change at page 18, line 21 skipping to change at page 18, line 21
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-
server._tcp.muc.example.com.". Therefore if a service wishes to server._tcp.muc.example.com.". Therefore if a service wishes to
enable entities from remote domains to access these add-on services, enable entities from remote domains to access these add-on services,
it needs to advertise the appropriate "_xmpp-server" SRV records in it needs to advertise the appropriate "_xmpp-server" SRV records in
addition to the "_xmpp-server" record for its main XMPP service. The addition to the "_xmpp-server" record for its main XMPP service. The
same fallback methods apply in case SRV records are not available. same fallback methods apply in case SRV records are not available.
3.3. Directionality 3.3. Directionality
An XML Stream is either bidirectional, allowing stanzas to be sent in The TCP connection underlying an XML stream is either bidirectional
either direction at any time, or unidirectional, allowing stanzas to (allowing stanzas to be sent in either direction at any time) or
be send only in one, fixed, direction. unidirectional (allowing stanzas to be send only in one, fixed,
direction).
Clients establish a single, bidirectional link to a server for a Clients establish a single, bidirectional TCP connection to a server
session, allowing XML stanzas to be sent from client to server and for a session, allowing XML stanzas to be sent from client to server
server to client. Servers, for historical reasons, establish two and server to client. Servers, for historical reasons, establish two
unidirectional connections between each other, one in each direction. unidirectional tCP connections between each other, one in each
A future extension might allow servers to establish bidirectional direction. A future extension might allow servers to establish
links given suitable feature negotiation; however, definition of such bidirectional connections given suitable feature negotiation;
a feature is out of scope for this document. however, definition of such a feature is out of scope for this
document.
The directionality of a stream applies only to XML stanzas The directionality of TCP connection applies only to XML stanzas
(Section 8). Therefore during STARTTLS negotiation (Section 5) and (Section 8) sent at the application layer. Therefore during STARTTLS
SASL negotiation (Section 6) two servers would use one TCP negotiation (Section 5) and SASL negotiation (Section 6) two servers
connection, but after stream setup that TCP connection would be used would use one TCP connection, but after stream setup that TCP
only for the initiating server to send XML stanzas to the receiving connection would be used only for the initiating server to send XML
server. In order for the receiving server to send XML stanzas to the stanzas to the receiving server. In order for the receiving server
initiating server, the receiving server would need to reverse the to send XML stanzas to the initiating server, the receiving server
roles and negotiate an XML stream from the receiving server to the would need to reverse the roles and negotiate an XML stream from the
initiating server. receiving server to the initiating server over a separate TCP
connection.
3.4. Reconnection 3.4. Reconnection
It can happen that an XMPP server goes offline while servicing TCP It can happen that an XMPP server goes offline while servicing TCP
connections from local clients and from other servers. Because the connections from local clients and from other servers. Because the
number of such connections can be quite large, the reconnection number of such connections can be quite large, the reconnection
algorithm employed by entities that seek to reconnect can have a algorithm employed by entities that seek to reconnect can have a
significant impact on software and network performance. If an entity significant impact on software and network performance. If an entity
chooses to reconnect, the following guidelines are RECOMMENDED: chooses to reconnect, the following guidelines are RECOMMENDED:
skipping to change at page 21, line 48 skipping to change at page 21, line 48
"documents" (as described in [XML-FRAG]). "documents" (as described in [XML-FRAG]).
However, these analogies are merely that, because XMPP does not deal However, these analogies are merely that, because XMPP does not deal
in documents and fragments but in streams and stanzas. in documents and fragments but in streams and stanzas.
The remainder of this section defines the following aspects of XML The remainder of this section defines the following aspects of XML
streams: streams:
o The stream negotation process o The stream negotation process
o How to close a stream o How to close a stream
o How to handle peers that are silent
o The XML attributes of a stream o The XML attributes of a stream
o The XML namespaces of a stream o The XML namespaces of a stream
Implementation Note: Although this specification speaks of a
single stream in each direction, nothing prevents implementations
from negotiating multiple streams in each direction (and, in
practice, large XMPP service providers often use multiple streams
for server-to-server connectivity).
4.2. Stream Negotiation 4.2. Stream Negotiation
4.2.1. Overview 4.2.1. Overview
Because the receiving entity for a stream acts as a gatekeeper to the Because the receiving entity for a stream acts as a gatekeeper to the
domains it services, it imposes certain conditions for connecting as domains it services, it imposes certain conditions for connecting as
a client or as a peer server. At a minimum, the initiating entity a client or as a peer server. At a minimum, the initiating entity
needs to authenticate with the receiving entity before it is allowed needs to authenticate with the receiving entity before it is allowed
to send stanzas to the receiving entity, typically using SASL as to send stanzas to the receiving entity, typically using SASL as
skipping to change at page 28, line 44 skipping to change at page 29, line 44
MUST terminate the underlying TCP connection. MUST terminate the underlying TCP connection.
4.4. Handling of Silent Peers 4.4. Handling of Silent Peers
When an entity that is a party to a stream has not received any XMPP When an entity that is a party to a stream has not received any XMPP
traffic from its stream peer for some period of time, the peer might traffic from its stream peer for some period of time, the peer might
appear to be silent. There are several reasons why this might appear to be silent. There are several reasons why this might
happen: happen:
1. The peer is idle and simply has not sent any XMPP traffic over 1. The peer is idle and simply has not sent any XMPP traffic over
the XML stream. its XML stream to the entity.
2. The XML stream is broken despite the fact that the underlying TCP 2. The XML stream is broken despite the fact that the underlying TCP
connection is alive. connection is alive.
3. The underlying TCP connection is dead. 3. The underlying TCP connection is dead.
These three conditions are best handled separately, as described in These three conditions are best handled separately, as described in
the following sections. the following sections.
Implementation Note: For the purpose of handling silent peers, we
treat a two unidirectional TCP connections as conceptually
equivalent to a single bidirectional TCP connection (see
Section 3.3); however, implementers need to be aware that, in the
case of two unidirectional TCP connections, responses to traffic
at the XMPP application layer will come back from the peer on the
second TCP connection. In addition, the use of multiple streams
in each direction (which is a common deployment choice for server-
to-server connectivity among large XMPP service providers) further
complicates application-level checking of XMPP streams and their
underlying TCP connections, because there is no necessary
correlation between any given initial stream and any given
response stream.
4.4.1. Idle Peer 4.4.1. Idle Peer
If the stream peer is idle at the XMPP application layer, it is If the stream peer is idle at the XMPP application layer, it is
appropriate for the entity to simply close the stream using the acceptable for the entity to ieither close the stream using the
handshake described under Section 4.3. The timeout period is a handshake described under Section 4.3 or to return a stream error
matter of implementation and local service policy; however, it is (e.g., <resource-constraint/> if the entity has reached a limit on
the number of open TCP connections or <policy-violation/> if the
connection has exceeded a local timeout policy). However, it is
RECOMMENDED to be liberal in accepting idle peers, since experience RECOMMENDED to be liberal in accepting idle peers, since experience
has shown that doing so improves the reliability of communication has shown that doing so improves the reliability of communication
over XMPP networks. In particular, it is typically more efficient to over XMPP networks and that it is typically more efficient to
maintain a stream between two servers than it is to aggressively maintain a stream between two servers than to aggressively timeout
timeout such a stream, especially with regard to synchronization of such a stream.
presence information as described in [XMPP-IM]; therefore it is
RECOMMENDED to maintain such a stream since experience has shown that
server-to-server streams are cyclical and typically need to be re-
established fairly frequently (e.g. at least every 24 hours) if they
are timed out because the peer is idle.
4.4.2. Broken Stream 4.4.2. Broken Stream
In this case, the peer never responds to XMPP traffic that the entity In this case, the peer never responds to XMPP traffic that the entity
sends, whether normal stanzas or specialized stream-checking traffic sends, whether normal stanzas or specialized stream-checking traffic
such as the application-level pings defined in [XEP-0199] or the more such as the application-level pings defined in [XEP-0199] or the more
comprehensive stream management protocol defined in [XEP-0198]. It comprehensive stream management protocol defined in [XEP-0198]. It
is appropriate for the entity to terminate a broken stream using the is appropriate for the entity to terminate a broken stream using the
<connection-timeout/> stream error described under Section 4.7.3.4. <connection-timeout/> stream error described under Section 4.7.3.4.
skipping to change at page 137, line 51 skipping to change at page 138, line 51
Channel encryption of an XML stream using Transport Layer Security as Channel encryption of an XML stream using Transport Layer Security as
described under Section 5, and in some cases also authentication as described under Section 5, and in some cases also authentication as
described under Section 6, is commonly based on a digital certificate described under Section 6, is commonly based on a digital certificate
presented by the receiving entity (or, in the case of mutual presented by the receiving entity (or, in the case of mutual
authentication, both the receiving entity and the initiating entity). authentication, both the receiving entity and the initiating entity).
This section describes best practices regarding the generation of This section describes best practices regarding the generation of
digital certificates to be presented by XMPP entities and the digital certificates to be presented by XMPP entities and the
verification of digital certificates presented by XMPP entities. verification of digital certificates presented by XMPP entities.
In general, the following sections rely on and extend the rules and In general, the following sections rely on and extend the rules and
guidelines provided in [X509] and [TLS-CERTS]. The reader is guidelines provided in the [PKIX] profile of [X509], and in
referred to those specifications for a detailed understanding of [TLS-CERTS]. The reader is referred to those specifications for a
certificates and their use in TLS. detailed understanding of PKIX certificates and their use in TLS.
13.7.1. Certificate Generation 13.7.1. Certificate Generation
13.7.1.1. General Considerations 13.7.1.1. General Considerations
The following rules apply to public key certificates that are issued The following rules apply to public key certificates that are issued
to XMPP entities: to XMPP entities:
1. The certificate MUST conform to [X509]. 1. The certificate MUST conform to [PKIX].
2. The certificate MUST NOT contain a basicConstraints extension 2. The certificate MUST NOT contain a basicConstraints extension
with the cA boolean set to TRUE. with the cA boolean set to TRUE.
3. The subject field MUST NOT be null. 3. The subject field MUST NOT be null.
4. The hash algorithm for the signature SHOULD be SHA-256 as defined 4. The hash algorithm for the signature SHOULD be SHA-256 as defined
by [X509-ALGO]. by [PKIX-ALGO].
5. The certificate SHOULD include an Authority Information Access 5. The certificate SHOULD include an Authority Information Access
(AIA) extension that specifies the address of an Online (AIA) extension that specifies the address of an Online
Certificate Status Protocol [OCSP] responder. Certificate Status Protocol [OCSP] responder.
The following rules apply to issuers of XMPP certificates: The following rules apply to issuers of XMPP certificates:
1. The certificate MUST conform to [X509]. 1. The certificate MUST conform to [PKIX].
2. The certificate MUST contain a keyUsage extension with the 2. The certificate MUST contain a keyUsage extension with the
digitalSignature bit set. digitalSignature bit set.
3. The subject field MUST NOT be null. 3. The subject field MUST NOT be null.
4. The hash algorithm for the signature SHOULD be SHA-256 as defined 4. The hash algorithm for the signature SHOULD be SHA-256 as defined
by [X509-ALGO]. by [PKIX-ALGO].
5. For issuers of public key certificates, the issuer's certificate 5. For issuers of public key certificates, the issuer's certificate
MUST contain a basicConstraints extension with the cA boolean set MUST contain a basicConstraints extension with the cA boolean set
to TRUE. to TRUE.
6. For issuers of access certificates, the issuer's certificate MUST 6. For issuers of access certificates, the issuer's certificate MUST
NOT contain a basicConstraints extension with the cA boolean set NOT contain a basicConstraints extension with the cA boolean set
to TRUE. to TRUE.
13.7.1.2. Server Certificates 13.7.1.2. Server Certificates
13.7.1.2.1. Rules 13.7.1.2.1. Rules
In a digital certificate to be presented by an XMPP server (i.e., a In a digital certificate to be presented by an XMPP server (i.e., a
SERVER CERTIFICATE), it is RECOMMENDED for the certificate to include SERVER CERTIFICATE), it is RECOMMENDED for the certificate to include
one or more JIDs (i.e., domainparts) associated with domains serviced one or more JIDs (i.e., domainparts) associated with domains serviced
at the server. The rules and guidelines defined in [TLS-CERTS] apply at the server. The rules and guidelines defined in [TLS-CERTS] apply
to XMPP server certificates. The following preference order of to XMPP server certificates. The following preference order of
identifiers is RECOMMENDED, where the identifier types are as identifiers is RECOMMENDED, where the identifier types are as
described in [TLS-CERTS] unless otherwise noted. described in [TLS-CERTS] unless otherwise noted.
1. SRV-ID (see also [X509-SRV]) 1. SRV-ID (see also [PKIX-SRV])
2. DNS-ID 2. DNS-ID
3. XmppAddr as specified under Section 13.7.1.4 3. XmppAddr as specified under Section 13.7.1.4
4. CN-ID 4. CN-ID
XMPP client and server software implementations MUST be able to XMPP client and server software implementations MUST be able to
validate both the SRV-ID and DNS-ID identifier types. Certification validate both the SRV-ID and DNS-ID identifier types. Certification
authorities that issue XMPP-specific certificates MUST support the authorities that issue XMPP-specific certificates MUST support the
DNS-ID identifier type and SHOULD support the SRV-ID identifier type. DNS-ID identifier type and SHOULD support the SRV-ID identifier type.
Service providers SHOULD request and prefer certificates that include Service providers SHOULD request and prefer certificates that include
an SRV-ID identifier type. Support for the XmppAddr and CN-ID an SRV-ID identifier type. Support for the XmppAddr and CN-ID
skipping to change at page 141, line 51 skipping to change at page 142, line 51
URN notation: subjectAltName=otherName:urn:oid: URN notation: subjectAltName=otherName:urn:oid:
1.3.6.1.5.5.7.8.5;UTF8:juliet@im.example.com 1.3.6.1.5.5.7.8.5;UTF8:juliet@im.example.com
Use of the "id-on-xmppAddr" format is RECOMMENDED in the generation Use of the "id-on-xmppAddr" format is RECOMMENDED in the generation
of certificates, but all three formats MUST be supported for the of certificates, but all three formats MUST be supported for the
purpose of certificate validation. purpose of certificate validation.
The "id-on-xmppAddr" object identifier MAY be used on conjuction with The "id-on-xmppAddr" object identifier MAY be used on conjuction with
the extended key usage extension specified in Section 4.2.1.12 of the extended key usage extension specified in Section 4.2.1.12 of
[X509] in order to explicitly define and limit the intended use of a [PKIX] in order to explicitly define and limit the intended use of a
certificate to the XMPP network. certificate to the XMPP network.
13.7.2. Certificate Validation 13.7.2. Certificate Validation
When an XMPP entity is presented with a server certificate or client When an XMPP entity is presented with a server certificate or client
certificate by a peer for the purpose of encryption or authentication certificate by a peer for the purpose of encryption or authentication
of XML streams as described under Section 5 and Section 6, the entity of XML streams as described under Section 5 and Section 6, the entity
MUST attempt to validate the certificate to determine if the MUST attempt to validate the certificate to determine if the
certificate will be considered a TRUSTED CERTIFICATE, i.e., a certificate will be considered a TRUSTED CERTIFICATE, i.e., a
certificate that is acceptable for encryption and/or authentication certificate that is acceptable for encryption and/or authentication
skipping to change at page 142, line 37 skipping to change at page 143, line 37
The following sections describe certificate validation rules for The following sections describe certificate validation rules for
server-to-server and client-to-server streams. server-to-server and client-to-server streams.
13.7.2.1. Server Certificates 13.7.2.1. Server Certificates
For server certificates, the rules and guidelines defined in For server certificates, the rules and guidelines defined in
[TLS-CERTS] apply. The following preference order of identifiers is [TLS-CERTS] apply. The following preference order of identifiers is
RECOMMENDED, where the identifier types are as described in RECOMMENDED, where the identifier types are as described in
[TLS-CERTS] unless otherwise noted. [TLS-CERTS] unless otherwise noted.
1. SRV-ID (see also [X509-SRV]) 1. SRV-ID (see also [PKIX-SRV])
2. DNS-ID 2. DNS-ID
3. XmppAddr as specified under Section 13.7.1.4 3. XmppAddr as specified under Section 13.7.1.4
4. CN-ID 4. CN-ID
13.7.2.2. Client Certificates 13.7.2.2. Client Certificates
When an XMPP server validates a certificate presented by a client, When an XMPP server validates a certificate presented by a client,
there are three possible cases, as discussed in the following there are three possible cases, as discussed in the following
sections. sections.
13.7.2.2.1. Case #1 13.7.2.2.1. Case #1
If the client certificate appears to be certified by a certification If the client certificate appears to be certified by a certification
path terminating in a trust anchor (as described in Section 6.1 of path terminating in a trust anchor (as described in Section 6.1 of
[X509]), the server MUST check the certificate for any instances of [PKIX]), the server MUST check the certificate for any instances of
the XmppAddr as described under Section 13.7.1.4. There are three the XmppAddr as described under Section 13.7.1.4. There are three
possible sub-cases: possible sub-cases:
Sub-Case #1: The server finds one XmppAddr for which the domainpart Sub-Case #1: The server finds one XmppAddr for which the domainpart
of the represented JID matches one of the configured hostnames of of the represented JID matches one of the configured hostnames of
the server; the server SHOULD use this represented JID as the the server; the server SHOULD use this represented JID as the
validated identity of the client. validated identity of the client.
Sub-Case #2: The server finds more than one XmppAddr for which the Sub-Case #2: The server finds more than one XmppAddr for which the
domainpart of the represented JID matches one of the configured domainpart of the represented JID matches one of the configured
skipping to change at page 163, line 21 skipping to change at page 164, line 21
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[LANGTAGS] [LANGTAGS]
Phillips, A. and M. Davis, "Tags for Identifying Phillips, A. and M. Davis, "Tags for Identifying
Languages", BCP 47, RFC 5646, September 2009. Languages", BCP 47, RFC 5646, September 2009.
[OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C. [OCSP] Myers, M., Ankney, R., Malpani, A., Galperin, S., and C.
Adams, "X.509 Internet Public Key Infrastructure Online Adams, "X.509 Internet Public Key Infrastructure Online
Certificate Status Protocol - OCSP", RFC 2560, June 1999. Certificate Status Protocol - OCSP", RFC 2560, June 1999.
[PKIX] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, May 2008.
[PKIX-ALGO]
Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[PKIX-SRV]
Santesson, S., "Internet X.509 Public Key Infrastructure
Subject Alternative Name for Expression of Service Name",
RFC 4985, August 2007.
[PLAIN] Zeilenga, K., "The PLAIN Simple Authentication and [PLAIN] Zeilenga, K., "The PLAIN Simple Authentication and
Security Layer (SASL) Mechanism", RFC 4616, August 2006. Security Layer (SASL) Mechanism", RFC 4616, August 2006.
[RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness [RANDOM] Eastlake, D., Schiller, J., and S. Crocker, "Randomness
Requirements for Security", BCP 106, RFC 4086, June 2005. Requirements for Security", BCP 106, RFC 4086, June 2005.
[SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and [SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and
Security Layer (SASL)", RFC 4422, June 2006. Security Layer (SASL)", RFC 4422, June 2006.
[SCRAM] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams, [SCRAM] Newman, C., Menon-Sen, A., Melnikov, A., and N. Williams,
"Salted Challenge Response (SCRAM) SASL and GSS-API "Salted Challenge Response Authentication Mechanism
Mechanism", draft-ietf-sasl-scram-11 (work in progress), (SCRAM) SASL and GSS-API Mechanisms", RFC 5802, July 2010.
February 2010.
[TCP] Postel, J., "Transmission Control Protocol", STD 7, [TCP] Postel, J., "Transmission Control Protocol", STD 7,
RFC 793, September 1981. RFC 793, September 1981.
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security [TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008. (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS-CERTS] [TLS-CERTS]
Saint-Andre, P. and J. Hodges, "Representation and Saint-Andre, P. and J. Hodges, "Representation and
Verification of Application Server Identity in Verification of Application Server Identity in
Certificates Used with Transport Layer Security (TLS)", Certificates Used with Transport Layer Security (TLS)",
draft-saintandre-tls-server-id-check-07 (work in draft-saintandre-tls-server-id-check-08 (work in
progress), June 2010. progress), July 2010.
[UCS2] International Organization for Standardization, [UCS2] International Organization for Standardization,
"Information Technology - Universal Multiple-octet coded "Information Technology - Universal Multiple-octet coded
Character Set (UCS) - Amendment 2: UCS Transformation Character Set (UCS) - Amendment 2: UCS Transformation
Format 8 (UTF-8)", ISO Standard 10646-1 Addendum 2, Format 8 (UTF-8)", ISO Standard 10646-1 Addendum 2,
October 1996. October 1996.
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version [UNICODE] The Unicode Consortium, "The Unicode Standard, Version
3.2.0", 2000. 3.2.0", 2000.
skipping to change at page 164, line 27 skipping to change at page 165, line 41
10646", STD 63, RFC 3629, November 2003. 10646", STD 63, RFC 3629, November 2003.
[UUID] Leach, P., Mealling, M., and R. Salz, "A Universally [UUID] Leach, P., Mealling, M., and R. Salz, "A Universally
Unique IDentifier (UUID) URN Namespace", RFC 4122, Unique IDentifier (UUID) URN Namespace", RFC 4122,
July 2005. July 2005.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, January 2005. RFC 3986, January 2005.
[X509] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [X509] International Telecommunications Union, "Information
Housley, R., and W. Polk, "Internet X.509 Public Key technology - Open Systems Interconnection - The Directory:
Infrastructure Certificate and Certificate Revocation List Public-key and attribute certificate frameworks", ITU-
(CRL) Profile", RFC 5280, May 2008. T Recommendation X.509, ISO Standard 9594-8, March 2000.
[X509-ALGO]
Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003.
[X509-SRV]
Santesson, S., "Internet X.509 Public Key Infrastructure
Subject Alternative Name for Expression of Service Name",
RFC 4985, August 2007.
[XML] Maler, E., Yergeau, F., Sperberg-McQueen, C., Paoli, J., [XML] Maler, E., Yergeau, F., Sperberg-McQueen, C., Paoli, J.,
and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth
Edition)", World Wide Web Consortium Recommendation REC- Edition)", World Wide Web Consortium Recommendation REC-
xml-20081126, November 2008, xml-20081126, November 2008,
<http://www.w3.org/TR/2008/REC-xml-20081126>. <http://www.w3.org/TR/2008/REC-xml-20081126>.
[XML-GUIDE] [XML-GUIDE]
Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for Hollenbeck, S., Rose, M., and L. Masinter, "Guidelines for
the Use of Extensible Markup Language (XML) the Use of Extensible Markup Language (XML)
skipping to change at page 165, line 19 skipping to change at page 166, line 24
[XML-NAMES] [XML-NAMES]
Thompson, H., Hollander, D., Layman, A., Bray, T., and R. Thompson, H., Hollander, D., Layman, A., Bray, T., and R.
Tobin, "Namespaces in XML 1.0 (Third Edition)", World Wide Tobin, "Namespaces in XML 1.0 (Third Edition)", World Wide
Web Consortium Recommendation REC-xml-names-20091208, Web Consortium Recommendation REC-xml-names-20091208,
December 2009, December 2009,
<http://www.w3.org/TR/2009/REC-xml-names-20091208>. <http://www.w3.org/TR/2009/REC-xml-names-20091208>.
[XMPP-ADDR] [XMPP-ADDR]
Saint-Andre, P., "Extensible Messaging and Presence Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Address Format", Protocol (XMPP): Address Format",
draft-ietf-xmpp-address-01 (work in progress), July 2010. draft-ietf-xmpp-address-02 (work in progress), July 2010.
16.2. Informative References 16.2. Informative References
[ACAP] Newman, C. and J. Myers, "ACAP -- Application [ACAP] Newman, C. and J. Myers, "ACAP -- Application
Configuration Access Protocol", RFC 2244, November 1997. Configuration Access Protocol", RFC 2244, November 1997.
[ANONYMOUS] [ANONYMOUS]
Zeilenga, K., "Anonymous Simple Authentication and Zeilenga, K., "Anonymous Simple Authentication and
Security Layer (SASL) Mechanism", RFC 4505, June 2006. Security Layer (SASL) Mechanism", RFC 4505, June 2006.
[ASN.1] CCITT, "Recommendation X.208: Specification of Abstract [ASN.1] CCITT, "Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1)", 1988. Syntax Notation One (ASN.1)", 1988.
[CHANNEL] Williams, N., "On the Use of Channel Bindings to Secure [CHANNEL] Williams, N., "On the Use of Channel Bindings to Secure
Channels", RFC 5056, November 2007. Channels", RFC 5056, November 2007.
[CHANNEL-TLS] [CHANNEL-TLS]
Altman, J., Williams, N., and L. Zhu, "Channel Bindings Altman, J., Williams, N., and L. Zhu, "Channel Bindings
for TLS", draft-altman-tls-channel-bindings-10 (work in for TLS", RFC 5929, July 2010.
progress), March 2010.
[DIGEST-MD5] [DIGEST-MD5]
Leach, P. and C. Newman, "Using Digest Authentication as a Leach, P. and C. Newman, "Using Digest Authentication as a
SASL Mechanism", RFC 2831, May 2000. SASL Mechanism", RFC 2831, May 2000.
[DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. [DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements", Rose, "DNS Security Introduction and Requirements",
RFC 4033, March 2005. RFC 4033, March 2005.
[DNS-TXT] Rosenbaum, R., "Using the Domain Name System To Store [DNS-TXT] Rosenbaum, R., "Using the Domain Name System To Store
skipping to change at page 170, line 10 skipping to change at page 171, line 15
[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-07 (work in progress), July 2010. draft-ietf-xmpp-3921bis-08 (work in progress), July 2010.
[XMPP-URI] [XMPP-URI]
Saint-Andre, P., "Internationalized Resource Identifiers Saint-Andre, P., "Internationalized Resource Identifiers
(IRIs) and Uniform Resource Identifiers (URIs) for the (IRIs) and Uniform Resource Identifiers (URIs) for the
Extensible Messaging and Presence Protocol (XMPP)", Extensible Messaging and Presence Protocol (XMPP)",
RFC 5122, February 2008. RFC 5122, February 2008.
Appendix A. XML Schemas Appendix A. XML Schemas
Because validation of XML streams and stanzas is optional, the Because validation of XML streams and stanzas is optional, the
skipping to change at page 181, line 19 skipping to change at page 182, line 19
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.
Author's Address Author's Address
Peter Saint-Andre Peter Saint-Andre
Cisco Systems, Inc. Cisco
1899 Wyknoop Street, Suite 600 1899 Wyknoop Street, Suite 600
Denver, CO 80202 Denver, CO 80202
USA USA
Phone: +1-303-308-3282 Phone: +1-303-308-3282
Email: psaintan@cisco.com Email: psaintan@cisco.com
 End of changes. 34 change blocks. 
339 lines changed or deleted 362 lines changed or added

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