xeps/xep-0073.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
  <!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
  <title>Basic IM Protocol Suite</title>
  <abstract>This document defines a recommended suite of Jabber/XMPP protocols to be supported by basic instant messaging and presence applications.</abstract>
  &LEGALNOTICE;
  <number>0073</number>
  <status>Draft</status>
  <type>Standards Track</type>
  <jig>Standards JIG</jig>
  <dependencies>
    <spec>XMPP Core</spec>
    <spec>XMPP IM</spec>
    <spec>XEP-0030</spec>
    <spec>XEP-0077</spec>
    <spec>XEP-0078</spec>
    <spec>XEP-0086</spec>
  </dependencies>
  <supersedes/>
  <supersededby/>
  <shortname>N/A</shortname>
  &stpeter;
  <revision>
    <version>1.0</version>
    <date>2004-12-09</date>
    <initials>psa</initials>
    <remark>Per a vote of the Jabber Council, advanced status to Active.</remark>
  </revision>
  <revision>
    <version>0.10</version>
    <date>2004-12-06</date>
    <initials>psa</initials>
    <remark>Per feedback from the Jabber Council, made all of RFC 3920 mandatory (no loophole allowing certain client platforms to not support TLS and SASL).</remark>
  </revision>
  <revision>
    <version>0.9</version>
    <date>2004-12-01</date>
    <initials>psa</initials>
    <remark>Removed reference to deployments and moved historical paragraph to a footnote.</remark>
  </revision>
  <revision>
    <version>0.8</version>
    <date>2004-11-18</date>
    <initials>psa</initials>
    <remark>Updated references to reflect publication of RFCs 3920 and 3921.</remark>
  </revision>
  <revision>
    <version>0.7</version>
    <date>2004-08-18</date>
    <initials>psa</initials>
    <remark>Changed In-Band Registration to recommended for clients; added note about SSL communications over port 5223; clarified wording throughout.</remark>
  </revision>
  <revision>
    <version>0.6</version>
    <date>2004-03-24</date>
    <initials>psa</initials>
    <remark>Updated to reflect approval of XMPP Core and XMPP IM.</remark>
  </revision>
  <revision>
    <version>0.5</version>
    <date>2003-11-24</date>
    <initials>psa</initials>
    <remark>Updated to reflect work by the XMPP WG; changed status to Deferred.</remark>
  </revision>
  <revision>
    <version>0.4</version>
    <date>2003-08-13</date>
    <initials>psa</initials>
    <remark>Renamed.</remark>
  </revision>
  <revision>
    <version>0.3</version>
    <date>2003-05-20</date>
    <initials>psa</initials>
    <remark>Slight editorial revisions.</remark>
  </revision>
  <revision>
    <version>0.2</version>
    <date>2003-04-06</date>
    <initials>psa</initials>
    <remark>Limited scope to definition of "Jabber IM Basic".</remark>
  </revision>
  <revision>
    <version>0.1</version>
    <date>2003-03-04</date>
    <initials>psa</initials>
    <remark>Initial version.</remark>
  </revision>
</header>
<section1 topic='Introduction' anchor='intro'>
  <p>Given the large number of Jabber/XMPP protocols, 
    <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 &JSF; 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 JSF has continued to develop additional protocols on top of XMPP in order to address functionality areas (such as file transfer) that were 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>
</section1>
<section1 topic='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>
  </ul>
  <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>
</section1>
<section1 topic='Definition' anchor='def'>
  <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. 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. In particular, the following are REQUIRED herein in order to ensure compatibility with the large deployed base of older Jabber software: 
    <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); while support for this behavior is OPTIONAL, it may be quite desirable in order to interoperate with older software and deployments.</note>
  </p>
  <ul>
    <li>Support for &xep0078; as a fallback method for authentication.</li>
    <li>Support for the error 'code' attribute specified in &xep0086;.</li>
  </ul>
  <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, privacy lists (whitelisting/blacklisting), and routing and delivery guidelines for clients and servers.</p>
  <p>However, Jabber instant messaging and presence applications have traditionally also included 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. (The original such protocol was &xep0094;, but that protocol has been superseded by &xep0030;.) Support for Service Discovery is therefore REQUIRED by this protocol suite, as well.</p>
  <p>Traditionally, Jabber servers (and some services) have also offered the ability for clients to register accounts "in-band" (i.e., over Jabber/XMPP) in order to bootstrap participation on the network; this protocol is defined in &xep0077; and support for it is REQUIRED for servers but RECOMMENDED for clients (however, any given server deployment MAY disable in-band registration as a matter of service provisioning).</p>
  <p>Thus we define the Basic IM Protocol Suite as follows:</p>
  <table caption='Required and Recommended Specifications'>
    <tr>
      <th>Specification</th>
      <th>Requirement Level</th>
    </tr>
    <tr>
      <td><strong>RFC 3920: XMPP Core</strong></td>
      <td>REQUIRED</td>
    </tr>
    <tr>
      <td><strong>RFC 3921: XMPP IM</strong></td>
      <td>REQUIRED</td>
    </tr>
    <tr>
      <td><strong>XEP-0078: Non-SASL Authentication</strong></td>
      <td>REQUIRED</td>
    </tr>
    <tr>
      <td><strong>XEP-0086: Error Condition Mappings</strong></td>
      <td>REQUIRED for servers; RECOMMENDED for clients</td>
    </tr>
    <tr>
      <td><strong>XEP-0030: Service Discovery</strong></td>
      <td>REQUIRED</td>
    </tr>
    <tr>
      <td><strong>XEP-0077: In-Band Registration</strong></td>
      <td>REQUIRED for servers; RECOMMENDED for clients</td>
    </tr>
  </table>
</section1>
<section1 topic='Security Considerations' anchor='security'>
  <p>RFC 3920 requires support for SASL and TLS as must-implement protocols, and that support is not modified herein. Refer to <cite>XEP-0078: Non-SASL Authentication</cite> for an explanation of the older authentication method still in use by various existing client and server implementations and deployments, as well as the proper order of precedence between SASL authentication (RFC 3920) and non-SASL authentication (XEP-0078).</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
  <p>This document requires no interaction with &IANA;.</p> 
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
  <p>No namespaces or parameters need to be registered with the &REGISTRAR; as a result of this document.</p>
</section1>
</xep>