<!ENTITY component "<note>Support can be enabled via an external component or an internal server module/plugin. If claiming compliance using such an addition, the necessary components/modules/plugins MUST be detailed.</note>">
<!ENTITY usecases "<note>Support for the Entity Use Cases and Occupant Use Cases is REQUIRED; support for the remaining use cases is RECOMMENDED.</note>">
<!ENTITY onlyone "<note>Only one of the recommended providers must be implemented for compliance.</note>">
<!ENTITY nocli "<note>Not required for command line or terminal based interfaces.</note>">
<!ENTITY avatar "<note>While 'User Avatars' is more modern, 'vCard-Based Avatars' is more widely deployed. Although it is suggested that to maximise interoperability with existing software a client fully supports both it is sufficient to claim compliance with this suite if the support for 'vCard-Based Avatars' is read-only.</note>">
<!ENTITY pubsubjid "<note>While 'Personal Eventing Protocol' does not require all the features of 'Publish-Subscribe' to be available on the users' JIDs, and nor does this suite, it is desirable for this to be the case and it is expected that this will a requirement of future Compliance Suites.</note>">
<!ENTITY yes "✓">
<!ENTITY no "✕">
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>XMPP Compliance Suites 2021</title>
<abstract>
This document defines XMPP application categories for different use cases
(Core, Web, IM, and Mobile), and specifies the required XEPs that client and
server software needs to implement for compliance with the use cases.
</abstract>
&LEGALNOTICE;
<number>0443</number>
<status>Experimental</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>
<spec>RFC 6120</spec>
<spec>RFC 6121</spec>
<spec>RFC 7395</spec>
<spec>RFC 7590</spec>
<spec>RFC 7622</spec>
<spec>XEP-0030</spec>
<spec>XEP-0045</spec>
<spec>XEP-0048</spec>
<spec>XEP-0049</spec>
<spec>XEP-0084</spec>
<spec>XEP-0085</spec>
<spec>XEP-0114</spec>
<spec>XEP-0115</spec>
<spec>XEP-0124</spec>
<spec>XEP-0163</spec>
<spec>XEP-0191</spec>
<spec>XEP-0198</spec>
<spec>XEP-0206</spec>
<spec>XEP-0223</spec>
<spec>XEP-0249</spec>
<spec>XEP-0280</spec>
<spec>XEP-0313</spec>
<spec>XEP-0352</spec>
<spec>XEP-0368</spec>
</dependencies>
<supersedes>
<spec>XEP-0423</spec>
</supersedes>
<supersededby/>
<shortname>CS2021</shortname>
<author>
<firstname>Georg</firstname>
<surname>Lukas</surname>
<email>georg@op-co.de</email>
<jid>georg@yax.im</jid>
</author>
<revision>
<version>0.1.0</version>
<date>2020-10-06</date>
<initials>XEP Editor (jsc)</initials>
<remark>Accepted by vote of Council on 2020-09-30.</remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2020-09-02</date>
<initials>gl</initials>
<remark>
<p>First draft based on XEP-0423.</p>
</remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>
There is a growing number of XMPP Extension Protocols (XEPs) that provide
different building blocks for XMPP-based applications. XMPP software
developers are confronted with the challenge of finding the right
combination of XEPs for a given application profile. Users need a way to
compare applications without resorting to comparing for individual XEP
numbers.
</p>
<p>
This document defines XMPP application <strong>Categories</strong> based on
typical use cases (Core, Web, IM, Mobile) and <strong>Levels</strong>
(Core, Advanced) based on functionality in the respective category. For
each combination of those, the required XEPs are referenced. As the
protocol landscape changes over time, this document is updated roughly
once a year.
</p>
<p>
For developers, this document provides guidance on which specifications
they need to consider when implementing an application of a certain kind.
By completing a compliance test or performing a self-assessment, they can
advertise their implementation as compliant with a given Category and
Level.
</p>
<p>
For users, this provides an easy way to compare implementations based on
their respective advertised compliance levels and year.
</p>
<p>
Unless explicitly noted, support for the listed specifications is REQUIRED
for compliance purposes.
A feature is considered supported if all comma separated feature providers
listed in the "Providers" column are implemented (unless otherwise noted).
</p>
<section2topic='Changes since 2020'anchor='changes-2020'>
<p>The following changes were made to the Compliance Suites since &xep0423;:</p>
<td>&rfc6120;<note>&rfc7622; is not listed due to the unclear interoperability impact of using PRECIS and Stringprep in the same ecosystem.</note></td>
</tr>
<tr>
<td><strong>TLS</strong></td>
<tdalign='center'>&yes;</td>
<tdalign='center'>&yes;</td>
<tdalign='center'>&yes;</td>
<tdalign='center'>&yes;</td>
<td>&rfc7590;</td>
</tr>
<tr>
<td><strong>Direct TLS</strong></td>
<tdalign='center'>&no;</td>
<tdalign='center'>&no;</td>
<tdalign='center'>&yes;<note>Server support of XEP-0368 means having the ability to accept direct TLS connections.</note></td>
<td>&xep0045;<note>Implementations should take note that future versions of these compliance suites may rely on &xep0369; instead.</note>, &xep0249;</td>
</tr>
<tr>
<td><strong>Advanced Group Chat</strong></td>
<tdalign='center'>&no;</td>
<tdalign='center'>&no;</td>
<tdalign='center'>&yes;&component;</td>
<tdalign='center'>&yes;</td>
<td>&xep0048;, &xep0313;<note>Support for requesting history from a MUC archive as opposed to from the user's account.</note>, &xep0410;, &xep0411;</td>
</tr>
<tr>
<td><strong>Persistent Storage of Private Data via PubSub</strong></td>
<tdalign='center'>&no;</td>
<tdalign='center'>&no;</td>
<tdalign='center'>&yes;&component;</td>
<tdalign='center'>&yes;</td>
<td>&xep0223;</td>
</tr>
<tr>
<td><strong>Private XML Storage</strong></td>
<tdalign='center'>&no;</td>
<tdalign='center'>&no;</td>
<tdalign='center'>&yes;&component;</td>
<tdalign='center'>&yes;</td>
<td>&xep0049; (only recommended for legacy bookmarks support)</td>
<p>This section outlines the protocol specifications that are relevant for
developers, but are not ready yet to be required for Compliance.
Developers are encouraged to implement those and
to share their experience and feedback.</p>
<ul>
<li>Client connection optimizations: &xep0386; and &xep0409;, maybe also &xep0397;</li>
<li>&xep0333;</li>
<li>&xep0369;</li>
<li>End-to-End Encryption (E2EE): &xep0380; for tagging encrypted messages, &xep0420; to protect all payloads; and also one or multiple of the following for actual encryption:
<ul>
<li>&xep0384; and &xep0396;</li>
<li>&xep0374;</li>
</ul>
</li>
<li>&xep0402; to phase out &xep0048;, &xep0049;, and &xep0411;</li>