Appendix A. XML Schemas
The following schemas formally define various namespaces used in this
document, in conformance with [XML-SCHEMA]. Because validation of
XML streams and stanzas is optional, these schemas are not normative
and are provided for descriptive purposes only.
A.1. Stream Namespace
<?xml version='1.0' encoding='UTF-8'?>
<xs:choice minOccurs='0' maxOccurs='1'>
<xs:choice minOccurs='0' maxOccurs='unbounded'>
<xs:attribute ref='xml:lang' use='optional'/>
Appendix B. Contact Addresses
Consistent with [MAILBOXES], organization that offer XMPP services
are encouraged to provide an Internet mailbox of "XMPP" for inquiries
related to that service, where the host portion of the resulting
mailto URI is the organization's domain, not the domain of the XMPP
service itself (e.g., the XMPP service might be offered at
im.example.com but the Internet mailbox would be <email@example.com>).
Appendix C. Account Provisioning
Account provisioning is out of scope for this specification.
Possible methods for account provisioning include account creation by
a server administrator and in-band account registration using the
'jabber:iq:register' namespace as documented in [XEP-0077]. An XMPP
server implementation or administrative function MUST ensure that any
JID assigned during account provisioning (including localpart,
domainpart, resourcepart, and separator characters) conforms to the
canonical format for XMPP addresses defined in [XMPP-ADDR].
Appendix D. Differences from RFC 3920
Based on consensus derived from implementation and deployment
experience as well as formal interoperability testing, the following
substantive modifications were made from RFC 3920 (in addition to
numerous changes of an editorial nature).
o Moved specification of the XMPP address format to a separate
o Recommended or mandated use of the 'from' and 'to' attributes on
o More fully specified the stream closing handshake.
o Specified the recommended stream reconnection algorithm.
o Changed the name of the <xml-not-well-formed/> stream error
condition to <not-well-formed/> for compliance with the XML
o Removed the unnecessary and unused <invalid-id/> stream error (see
RFC 3920 for historical documentation).
o Specified return of the <restricted-xml/> stream error in response
to receipt of prohibited XML features.
o More completely specified the format and handling of the <see-
other-host/> stream error, including consistency with RFC 3986 and
RFC 5952 with regard to IPv6 addresses (e.g., enclosing the IPv6
address in square brackets '[' and ']').
o Specified that the SASL SCRAM mechanism is a mandatory-to-
implement technology for client-to-server streams.
o Specified that TLS plus the SASL PLAIN mechanism is a mandatory-
to-implement technology for client-to-server streams.
o Specified that support for the SASL EXTERNAL mechanism is required
for servers but only recommended for clients (since end-user X.509
certificates are difficult to obtain and not yet widely deployed).
o Removed the hard two-connection rule for server-to-server streams.
o More clearly specified the certificate profile for both public key
certificates and issuer certificates.
o Added the <reset/> stream error (Section 188.8.131.52) condition to
handle expired/revoked certificates or the addition of security-
critical features to an existing stream.
o Added the <account-disabled/>, <credentials-expired/>,
<encryption-required/>, and <malformed-request/> SASL error
conditions to handle error flows mistakenly left out of RFC 3920
or discussed in RFC 4422 but not in RFC 2222.
o Removed the unused <payment-required/> stanza error.
o Removed the unnecessary requirement for escaping of characters
that map to certain predefined entities, since they do not need to
be escaped in XML.
o Clarified the process of DNS SRV lookups and fallbacks.
o Clarified the handling of SASL security layers.
o Clarified that a SASL simple user name is the localpart, not the
o Clarified the stream negotiation process and associated flow
o Clarified the handling of stream features.
o Added a 'by' attribute to the <error/> element for stanza errors
so that the entity that has detected the error can include its JID
for diagnostic or tracking purposes.
o Clarified the handling of data that violates the well-formedness
definitions for XML 1.0 and XML namespaces.
o Specified the security considerations in more detail, especially
with regard to presence leaks and denial-of-service attacks.
o Moved documentation of the Server Dialback protocol from this
specification to a separate specification maintained by the XMPP
Appendix E. Acknowledgements
This document is an update to, and derived from, RFC 3920. This
document would have been impossible without the work of the
contributors and commenters acknowledged there.
Hundreds of people have provided implementation feedback, bug
reports, requests for clarification, and suggestions for improvement
since publication of RFC 3920. Although the document editor has
endeavored to address all such feedback, he is solely responsible for
any remaining errors and ambiguities.
Special thanks are due to Kevin Smith, Matthew Wild, Dave Cridland,
Philipp Hancke, Waqas Hussain, Florian Zeitz, Ben Campbell, Jehan
Pages, Paul Aurich, Justin Karneges, Kurt Zeilenga, Simon Josefsson,
Ralph Meijer, Curtis King, and others for their comments during
Working Group Last Call.
Thanks also to Yaron Sheffer and Elwyn Davies for their reviews on
behalf of the Security Directorate and the General Area Review Team,
The Working Group chairs were Ben Campbell and Joe Hildebrand. The
responsible Area Director was Gonzalo Camarillo.
1899 Wyknoop Street, Suite 600
Denver, CO 80202