Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.
The Extensible Messaging and Presence Protocol (XMPP) is an application profile
of the Extensible Markup Language (XML) that enables the near-real-time exchange
of structured yet extensible data between any two or more network entities.
This document defines XMPP's core protocol methods: setup and teardown of XML
streams, channel encryption, authentication, error handling, and communication
primitives for messaging, network availability ("presence"), and request-
response interactions.
Since 2004 the Internet community has gained extensive implementation and
deployment experience with XMPP, including formal interoperability testing
carried out under the auspices of the XMPP Standards Foundation (XSF). This
document incorporates comprehensive feedback from software developers and
service providers, including a number of backward-compatible modifications. As
a result, this document reflects the rough consensus of the Internet community
regarding the core features of XMPP 1.0, thus obsoleting RFC 3920.
Working Group Summary
Was there anything in the WG process that is worth noting?
For example, was there controversy about particular points
or were there decisions where the consensus was
particularly rough?
There is strong consensus in the working group to publish this document.
There has been controversy over the use of dialback authentication in XMPP. RFC
3920 recommended against the use of dialback, but included it for backwards
compatibility reasons. Since dialback continues to be in common use among XMPP
implementations, some working group participants wished to keep it in this
draft. Others believed that we should further discourage its use by removing it.
The working group reached a rough consensus to remove it from this draft, but
mention it (referencing XEP-0220) as something many implementations do, and
allowed at a MAY level for interworking with implementations that are unable to
use stronger authentication.
There were concerns that the XMPP addressing format (aka JID) depend on
internationalization technologies (stringprep) that are currently in flux, and
may be in flux for some time. Rather than block progress on this draft, the
working group chose to remove the JID definition to a separate draft (draft-
ietf-xmpp-address-03). The referenced draft continues to use stringprep, but was
separated out to make it easier to update in a "modular" fashion once work on a
new internationalization approach is complete.
Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type, or other Expert Review,
what was its course (briefly)? In the case of a Media Type
Review, on what date was the request posted?
There are at least 25 server implementations, 50 library implementations, and
100 client implementations of the XMPP RFCs; a partial list is located at
<http://xmpp.org/xmpp-software/> (that list does not include "software as a
service" implementations hosted by service providers such as Google Talk).
Several downloadable software
implementations in each category have been closely
tracking the changes between RFC 3920 and draft-ietf-xmpp-3920bis, and many
others are currently being upgraded or are waiting until the replacement RFC is
published before including the modifications in released software.
Interoperability is continually being verified among implementation teams, over
the XMPP network, and at more formal interoperability
testing events sponsored
by the XMPP Standards Foundation. It is expected that official implementation
reports will be submitted within a year after publication of the revised XMPP
RFCs.
Personnel
Who is the Document Shepherd for this document? Who is the
Responsible Area Director? If the document requires IANA
experts(s), insert 'The IANA Expert(s) for the registries
in this document are <to be="" added="" by="" the="" ad="">.'
The document shepherd for this document is Ben Campbell.
The responsible Area Director is Gonzalo Camarillo.