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.

This document defines XMPP application Categories based on typical use cases (Core, Web, IM, Mobile) and Levels (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.

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.

For users, this provides an easy way to compare implementations based on their respective advertised compliance levels and year.

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).

This section outlines the protocol specifications that will become relevant for developers in the future, but are not ready for production yet. THIS IS A VERY ROUGH TEMPORARY LIST MEANT FOR DISCUSSION!

• &xep0369; and related specifications
• &xep0386; and &xep0409;
• &xep0384; and &xep0380; and &xep0396;
• &xep0385;
• &xep0402;

Some of the protocol specifications referenced herein have their own dependencies; developers need to consult the relevant specifications for further information.

This document introduces no additional security considerations above and beyond those defined in the documents on which it depends.

This document requires no interaction with &IANA;.

This document requires no interaction with the ®ISTRAR;.

The author would like to thank Guus der Kinderen, Dele Olajide, Marc Laporte, Dave Cridland, Daniel Gultsch, Florian Schmaus, Tobias Markmann, and Jonas Schäfer for their suggestions.