</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name=’challenge’ type=’xs:string’/>
<xs:element name=’response’ type=’xs:string’/>
<xs:element name=’abort’ type=’empty’/>
<xs:element name=’success’ type=’empty’/>
<xs:element name=’failure’>
<xs:complexType>
<xs:choice minOccurs=’0’>
<xs:element name=’aborted’ type=’empty’/>
<xs:element name=’incorrect-encoding’ type=’empty’/>
<xs:element name=’invalid-authzid’ type=’empty’/>
<xs:element name=’invalid-mechanism’ type=’empty’/>
<xs:element name=’mechanism-too-weak’ type=’empty’/>
<xs:element name=’not-authorized’ type=’empty’/>
<xs:element name=’temporary-auth-failure’ type=’empty’/>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:simpleType name=’empty’>
<xs:restriction base=’xs:string’>
<xs:enumeration value=’’/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
C.5. Resource binding namespace
<?xml version=’1.0’ encoding=’UTF-8’?>
<xs:schema
xmlns:xs=’http://www.w3.org/2001/XMLSchema’
targetNamespace=’urn:ietf:params:xml:ns:xmpp-bind’
xmlns=’urn:ietf:params:xml:ns:xmpp-bind’
elementFormDefault=’qualified’>
<xs:element name=’bind’>
<xs:complexType>
<xs:choice minOccurs=’0’ maxOccurs=’1’>
<xs:element name=’resource’ type=’xs:string’/>
<xs:element name=’jid’ type=’xs:string’/>
</xs:choice>
</xs:complexType>
</xs:element>
</xs:schema>
C.6. Dialback namespace
<?xml version=’1.0’ encoding=’UTF-8’?>
<xs:schema
xmlns:xs=’http://www.w3.org/2001/XMLSchema’
targetNamespace=’jabber:server:dialback’
xmlns=’jabber:server:dialback’
elementFormDefault=’qualified’>
<xs:element name=’result’>
<xs:complexType>
<xs:simpleContent>
<xs:extension base=’xs:token’>
<xs:attribute name=’from’ type=’xs:string’ use=’required’/>
<xs:attribute name=’to’ type=’xs:string’ use=’required’/>
<xs:attribute name=’type’ use=’optional’>
<xs:simpleType>
<xs:restriction base=’xs:NCName’>
<xs:enumeration value=’invalid’/>
<xs:enumeration value=’valid’/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name=’verify’>
<xs:complexType>
<xs:simpleContent>
<xs:extension base=’xs:token’>
<xs:attribute name=’from’ type=’xs:string’ use=’required’/>
<xs:attribute name=’id’ type=’xs:NMTOKEN’ use=’required’/>
<xs:attribute name=’to’ type=’xs:string’ use=’required’/>
<xs:attribute name=’type’ use=’optional’>
<xs:simpleType>
<xs:restriction base=’xs:NCName’>
<xs:enumeration value=’invalid’/>
<xs:enumeration value=’valid’/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
</xs:schema>
C.7. Stanza error namespace
<?xml version=’1.0’ encoding=’UTF-8’?>
<xs:schema
xmlns:xs=’http://www.w3.org/2001/XMLSchema’
targetNamespace=’urn:ietf:params:xml:ns:xmpp-stanzas’
xmlns=’urn:ietf:params:xml:ns:xmpp-stanzas’
elementFormDefault=’qualified’>
<xs:element name=’bad-request’ type=’empty’/>
<xs:element name=’conflict’ type=’empty’/>
<xs:element name=’feature-not-implemented’ type=’empty’/>
<xs:element name=’forbidden’ type=’empty’/>
<xs:element name=’gone’ type=’xs:string’/>
<xs:element name=’internal-server-error’ type=’empty’/>
<xs:element name=’item-not-found’ type=’empty’/>
<xs:element name=’jid-malformed’ type=’empty’/>
<xs:element name=’not-acceptable’ type=’empty’/>
<xs:element name=’not-allowed’ type=’empty’/>
<xs:element name=’payment-required’ type=’empty’/>
<xs:element name=’recipient-unavailable’ type=’empty’/>
<xs:element name=’redirect’ type=’xs:string’/>
<xs:element name=’registration-required’ type=’empty’/>
<xs:element name=’remote-server-not-found’ type=’empty’/>
<xs:element name=’remote-server-timeout’ type=’empty’/>
<xs:element name=’resource-constraint’ type=’empty’/>
<xs:element name=’service-unavailable’ type=’empty’/>
<xs:element name=’subscription-required’ type=’empty’/>
<xs:element name=’undefined-condition’ type=’empty’/>
<xs:element name=’unexpected-request’ type=’empty’/>
<xs:group name=’stanzaErrorGroup’>
<xs:choice>
<xs:element ref=’bad-request’/>
<xs:element ref=’conflict’/>
<xs:element ref=’feature-not-implemented’/>
<xs:element ref=’forbidden’/>
<xs:element ref=’gone’/>
<xs:element ref=’internal-server-error’/>
<xs:element ref=’item-not-found’/>
<xs:element ref=’jid-malformed’/>
<xs:element ref=’not-acceptable’/>
<xs:element ref=’not-allowed’/>
<xs:element ref=’payment-required’/>
<xs:element ref=’recipient-unavailable’/>
<xs:element ref=’redirect’/>
<xs:element ref=’registration-required’/>
<xs:element ref=’remote-server-not-found’/>
<xs:element ref=’remote-server-timeout’/>
<xs:element ref=’resource-constraint’/>
<xs:element ref=’service-unavailable’/>
<xs:element ref=’subscription-required’/>
<xs:element ref=’undefined-condition’/>
<xs:element ref=’unexpected-request’/>
</xs:choice>
</xs:group>
<xs:element name=’text’>
<xs:complexType>
<xs:simpleContent>
<xs:extension base=’xs:string’>
<xs:attribute ref=’xml:lang’ use=’optional’/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:simpleType name=’empty’>
<xs:restriction base=’xs:string’>
<xs:enumeration value=’’/>
</xs:restriction>
</xs:simpleType>
</xs:schema>
Appendix D. Differences Between Core Jabber Protocols and XMPP
This section is non-normative.
XMPP has been adapted from the protocols originally developed in the
Jabber open-source community, which can be thought of as "XMPP 0.9".
Because there exists a large installed base of Jabber implementations
and deployments, it may be helpful to specify the key differences
between the relevant Jabber protocols and XMPP in order to expedite
and encourage upgrades of those implementations and deployments to
XMPP. This section summarizes the core differences, while the
corresponding section of [XMPP-IM] summarizes the differences that
relate specifically to instant messaging and presence applications.
D.1. Channel Encryption
It was common practice in the Jabber community to use SSL for channel
encryption on ports other than 5222 and 5269 (the convention is to
use ports 5223 and 5270). XMPP uses TLS over the IANA-registered
ports for channel encryption, as defined under Use of TLS (Section 5)
herein.
D.2. Authentication
The client-server authentication protocol developed in the Jabber
community used a basic IQ interaction qualified by the
’jabber:iq:auth’ namespace (documentation of this protocol is
contained in [JEP-0078], published by the Jabber Software Foundation
[JSF]). XMPP uses SASL for authentication, as defined under Use of
SASL (Section 6) herein.
The Jabber community did not develop an authentication protocol for
server-to-server communications, only the Server Dialback (Section 8)
protocol to prevent server spoofing. XMPP supersedes Server Dialback
with a true server-to-server authentication protocol, as defined
under Use of SASL (Section 6) herein.
D.3. Resource Binding
Resource binding in the Jabber community was handled via the
’jabber:iq:auth’ namespace (which was also used for client
authentication with a server). XMPP defines a dedicated namespace
for resource binding as well as the ability for a server to generate
a resource identifier on behalf of a client, as defined under
Resource Binding (Section 7).
D.4. JID Processing
JID processing was somewhat loosely defined by the Jabber community
(documentation of forbidden characters and case handling is contained
in [JEP-0029], published by the Jabber Software Foundation [JSF]).
XMPP specifies the use of [NAMEPREP] for domain identifiers and
supplements Nameprep with two additional [STRINGPREP] profiles for
JID processing: Nodeprep (Appendix A) for node identifiers and
Resourceprep (Appendix B) for resource identifiers.
D.5. Error Handling
Stream-related errors were handled in the Jabber community via XML
character data text in a <stream:error/> element. In XMPP,
stream-related errors are handled via an extensible mechanism defined
under Stream Errors (Section 4.7) herein.
Stanza-related errors were handled in the Jabber community via
HTTP-style error codes. In XMPP, stanza-related errors are handled
via an extensible mechanism defined under Stanza Errors (Section 9.3)
herein. (Documentation of a mapping between Jabber and XMPP error
handling mechanisms is contained in [JEP-0086], published by the
Jabber Software Foundation [JSF].)
D.6. Internationalization
Although use of UTF-8 has always been standard practice within the
Jabber community, the community did not define mechanisms for
specifying the language of human-readable text provided in XML
character data. XMPP specifies the use of the ’xml:lang’ attribute
in such contexts, as defined under Stream Attributes (Section 4.4)
and xml:lang (Section 9.1.5) herein.
D.7. Stream Version Attribute
The Jabber community did not include a ’version’ attribute in stream
headers. XMPP specifies inclusion of that attribute as a way to
signal support for the stream features (authentication, encryption,
etc.) defined under Version Support (Section 4.4.1) herein.
Contributors
Most of the core aspects of the Extensible Messaging and Presence
Protocol were developed originally within the Jabber open-source
community in 1999. This community was founded by Jeremie Miller, who
released source code for the initial version of the jabber server in
January 1999. Major early contributors to the base protocol also
included Ryan Eatmon, Peter Millard, Thomas Muldowney, and Dave
Smith. Work by the XMPP Working Group has concentrated especially on
security and internationalization; in these areas, protocols for the
use of TLS and SASL were originally contributed by Rob Norris, and
stringprep profiles were originally contributed by Joe Hildebrand.
The error code syntax was suggested by Lisa Dusseault.
Acknowledgements
Thanks are due to a number of individuals in addition to the
contributors listed. Although it is difficult to provide a complete
list, the following individuals were particularly helpful in defining
the protocols or in commenting on the specifications in this memo:
Thomas Charron, Richard Dobson, Sam Hartman, Schuyler Heath, Jonathan
Hogg, Cullen Jennings, Craig Kaes, Jacek Konieczny, Alexey Melnikov,
Keith Minkler, Julian Missig, Pete Resnick, Marshall Rose, Alexey
Shchepin, Jean-Louis Seguineau, Iain Shigeoka, Greg Troxel, and David
Waite. Thanks also to members of the XMPP Working Group and the IETF
community for comments and feedback provided throughout the life of
this memo.
Author’s Address
Peter Saint-Andre (editor)
Jabber Software Foundation
EMail: stpeter@jabber.org
Full Copyright Statement
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF’s procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.