<abstract>This document defines a recommended suite of Jabber/XMPP protocols to be supported by basic instant messaging and presence applications. Note: This protocol suite has been obsoleted by XEP-0211 and XEP-0212.</abstract>
<remark><p>Changed support for XEP-0077 from required for servers and recommended for clients to recommended for both servers and clients; changed support for XEP-0078 from required for both servers and clients to recommended for servers and not recommended for clients; changed support for XEP-0086 from required for servers and recommended for clients to recommended for both servers and clients; added XEP-0115 as required for clients.</p></remark>
<remark><p>Per feedback from the Jabber Council, made all of RFC 3920 mandatory (no loophole allowing certain client platforms to not support TLS and SASL).</p></remark>
<remark><p>Changed In-Band Registration to recommended for clients; added note about SSL communications over port 5223; clarified wording throughout.</p></remark>
<note>The protocols developed by the Jabber community have matured considerably since 1999. The core protocols were originally created by a small group of developers who worked on early Jabber-related open-source software projects such as the &jabberd; server, the Winjab, Gabber, and Jarl clients, the Net::Jabber and Jabberbeans libraries, and gateways to consumer IM services. In the summer of 2001, the &XSF; was founded to institute a formal standards process within the growing Jabber community (codified in &xep0001;). In late 2002, the &IETF; formed the &XMPPWG;, which formalized the core Jabber protocols under the name Extensible Messaging and Presence Protocol (XMPP). In early 2004, the IETF approved the main XMPP specifications as Proposed Standards within the Internet Standards Process defined by &rfc2026;, resulting in publication of <cite>RFC 3920</cite> (&xmppcore;) and <cite>RFC 3921</cite> (&xmppim;). In the meantime, the XSF has continued to develop additional protocols on top of XMPP in order to address functionality areas that are too application-specific for consideration within the IETF.</note>
it is not always clear to developers exactly which protocols they need to implement in order to interoperate over Jabber/XMPP networks. This document attempts to assist developers by defining a protocol suite for basic instant messaging and presence.</p>
<section1topic='Requirements and Approach'anchor='reqs'>
<p>Defining a protocol suite provides a high-level "bucket" into which we can place specific functionality areas for development and compliance testing. A baseline is provided by RFCs 3920 and 3921, which define XML streams, JID processing, channel encryption, authentication, the three primary XML stanza types (&MESSAGE;, &PRESENCE;, and &IQ;), namespace handling, presence subscriptions, roster management, and privacy lists (whitelisting/blacklisting). However, basic Jabber instant messaging and presence applications should support several additional protocols that were not included in the XMPP specifications for either of the following reasons:</p>
<ul>
<li>They were not required to meet the requirements of &rfc2779; (e.g, service discovery)</li>
<li>They were and remain in common use within the Jabber community but did not meet the more stringent requirements of the IETF (e.g., old-style, non-SASL authentication)</li>
<p>The Basic IM Protocol Suite does not include more advanced IM functionality, such as groupchat or HTML message formatting; see &xep0117; for such features.</p>
<p>The software developed in the Jabber community is built on the foundation of XML streams, a consistent addressing scheme (JIDs), channel encryption, authentication of an entity (client or server) with a server, three core data elements (&MESSAGE;, &PRESENCE;, and &IQ;), and proper handling of XML namespaces. These foundational building blocks have been formalized within RFC 3920, support for which is REQUIRED by this protocol suite.</p>
<p>However, XMPP Core is not fully congruent with the core of what has traditionally been known as "Jabber", and this divergence needs to be captured in the Basic IM Protocol Suite. For the sake of backward compatibility, support for &xep0078; is RECOMMENDED for servers (but not clients) as a fallback method of authentication by older deployed clients. <note>Older software also used port 5223 for SSL-enabled communications between a client and a server, rather than upgrading port 5222 as is done during TLS negotiation (the equivalent for server-to-server communications was never implemented). Support for this behavior is OPTIONAL on the part of servers for backwards-compatibility with older deployed clients.</note> In addition, support for the error 'code' attribute specified in &xep0086; is RECOMMENDED for both clients and servers.</p>
<p>RFC 3920 does not define everything that is normally expected of even a minimal instant messaging and presence application (in effect, it defines the transport layer rather than the IM and presence application layer). Much of this IM and presence functionality is defined in RFC 3921 in order to meet the requirements of RFC 2779. In particular, RFC 3921 defines roster management, presence subscriptions, and routing and delivery guidelines for clients and servers. Therefore, support for <cite>RFC 3921</cite> is REQUIRED.</p>
<p>Furthermore, Jabber instant messaging and presence applications typically include the ability to discover information about other entities on the network, and to reply to queries for information. This behavior is extremely helpful because it ensures that entities on the network can determine each other's capabilities and thus understand how to communicate together. Therefore, support for &xep0030; is REQUIRED by this protocol suite, as is (for clients) the dynamic profile of service discovery specified in &xep0115;.</p>
<p>Traditionally, Jabber servers (and some services) have also offered the ability for clients to register accounts "in-band" (see &xep0077;) in order to bootstrap participation on the network; support for that protocol is RECOMMENDED but any given server deployment MAY disable in-band registration as a matter of service provisioning.</p>
<p>RFC 3920 requires support for SASL and TLS as must-implement protocols, and that support is not modified herein. The older authentication method specified in <cite>XEP-0078: Non-SASL Authentication</cite> is now deprecated; however, support for it is still recommended in server implementations for the sake of backward compatibility (see <cite>XEP-0078</cite> regarding the proper order of precedence between SASL authentication and non-SASL authentication).</p>
