XMPP, héritier de Jabber : stanzas, JID et serveurs

Une ouverture de session XMPP commence par l'échange de flux XML entre le client et son serveur, puis par une authentification SASL et l'établissement d'une session liée à une ressource. Une fois cette session ouverte, le client envoie et reçoit trois types de stanzas : message pour le contenu, presence pour l'état de disponibilité, iq pour les requêtes et réponses de gestion. Ces trois stanzas, définies dans les RFC de 2004, forment le socle du protocole hérité de Jabber.

Comment se déroule une ouverture de session XMPP et à quoi servent les trois stanzas message, presence et iq ?

L'ouverture de session se fait en plusieurs temps. Le client ouvre un flux XML vers le serveur, qui répond par un autre flux et déclare les fonctionnalités disponibles. Le client s'authentifie ensuite par SASL, généralement avec un mot de passe, puis demande à lier la session à une ressource, par exemple un nom de téléphone ou d'ordinateur. Le serveur confirme, et le client peut alors envoyer son premier presence pour signaler qu'il est en ligne.

Les trois stanzas ont des rôles distincts. La stanza message transporte un contenu destiné à un contact, avec un type qui indique s'il s'agit d'une conversation, d'une erreur ou d'une notification. La stanza presence informe le serveur et les contacts abonnés de l'état de disponibilité, en ligne, absent ou occupé, et sert aussi aux souscriptions. La stanza iq, pour info/query, fonctionne par paires requête et réponse : elle sert à la gestion du roster, aux demandes de version, aux commandes de configuration et à d'autres échanges structurés. Un client qui reçoit une iq doit y répondre, ce qui distingue cette stanza des deux autres.

Le détail de ces échanges, la construction des JID et le rôle des rosters sont documentés dans le protocole XMPP expliqué, un guide éditorial en anglais qui reprend les textes de référence et la chronologie du protocole.

Comment se construit une adresse JID et à quoi sert un roster ?

Un JID, pour Jabber ID, ressemble à une adresse électronique mais obéit à une syntaxe propre. Il se compose d'une partie locale, d'un domaine et, éventuellement, d'une ressource, sous la forme utilisateur@domaine/ressource. La partie locale identifie le compte sur le domaine, le domaine désigne le serveur XMPP, et la ressource distingue les sessions d'un même compte, par exemple deux appareils connectés en parallèle. Un JID sans partie locale, comme domaine seul, peut désigner un service ou un composant du serveur.

Le roster est la liste de contacts associée à un compte. Il est stocké côté serveur, ce qui permet de le retrouver depuis n'importe quel client. Chaque entrée du roster porte un JID, un nom affiché et un état d'abonnement. La souscription fonctionne par autorisation mutuelle : pour voir la presence d'un contact, il faut lui envoyer une demande de souscription, qu'il accepte ou refuse. Le roster ne se limite donc pas à un carnet d'adresses, il gère les droits de visibilité entre comptes.

Quelle chronologie mène de jabberd aux RFC de 2004 et au processus des XEP ?

Jabber apparaît à la fin des années 1990 comme un protocole de messagerie ouvert, porté par un serveur libre nommé jabberd. Le nom Jabber a ensuite été déposé, et son usage est encadré par une licence et des conditions d'usage précisées par le détenteur de la marque. Le protocole lui-même a été repris par l'IETF, qui a publié en 2004 les RFC fondatrices de XMPP, dont la RFC 3920 pour le cœur du protocole et la RFC 3921 pour la messagerie et la presence instantanées. Ces textes ont été révisés en 2011 par les RFC 6120 et 6121, qui restent les références du protocole.

En parallèle, le développement des extensions se fait par des XEP, pour XMPP Extension Protocols. Chaque XEP est un document numéroté, proposé puis discuté au sein de la communauté, avec des états qui vont de l'expérimental au final. Ce processus permet d'ajouter des fonctions comme le chiffrement OMEMO, les salons MUC ou les salons MIX sans modifier le cœur du protocole. La chronologie complète, de jabberd aux RFC de 2004 puis aux XEP, est retracée dans le guide Presence & Protocol.

Que faut-il prévoir pour monter un serveur XMPP fédéré, entre ejabberd, Prosody et Openfire ?

Un serveur XMPP fédéré doit d'abord être joignable par un nom de domaine. Cela suppose d'enregistrer des enregistrements DNS de type A ou AAAA pour l'adresse du serveur, et un enregistrement SRV pour indiquer le service XMPP, ce qui permet aux autres domaines de trouver le serveur. Sans ces enregistrements, la fédération ne fonctionne pas, même si le serveur tourne correctement en local.

Le chiffrement TLS est également nécessaire. Il repose sur un certificat valide pour le domaine, délivré par une autorité de certification reconnue. Le serveur présente ce certificat aux clients et aux autres serveurs lors des connexions, ce qui protège les échanges et permet aux correspondants distants d'accepter la connexion. Les certificats renouvelés automatiquement simplifient cette partie.

Trois serveurs libres sont couramment cités. ejabberd est écrit en Erlang, réputé pour sa robustesse et sa gestion de nombreux comptes. Prosody est écrit en Lua, plus léger, souvent choisi pour de petites installations. Openfire est écrit en Java et dispose d'une interface d'administration graphique, ce qui facilite la configuration pour un public moins technique. Le choix dépend de la charge attendue, des compétences disponibles et des modules souhaités.

Quels clients choisir et comment vérifier un point technique ?

Le choix du client dépend de l'appareil. Sur ordinateur, plusieurs clients libres prennent en charge le chiffrement OMEMO et les salons MUC. Sur mobile, les contraintes sont différentes : gestion de l'énergie, notifications, stockage des conversations chiffrées. Un client mobile doit souvent être autorisé à fonctionner en arrière-plan pour recevoir les messages, ce qui n'est pas toujours possible selon le système.

Pour vérifier un point technique, la méthode consiste à revenir aux textes de référence. Les RFC décrivent le cœur du protocole, les XEP précisent les extensions, et les guides éditoriaux en anglais reprennent ces sources pour expliquer la construction des JID, le fonctionnement des rosters ou la configuration d'un serveur. Cette mémoire du réseau inclut aussi le répertoire JabberPowered, créé en 2003, qui recense des serveurs et des clients et dont la licence et les conditions d'usage sont précisées par ses mainteneurs.

Ce qu'il faut retenir

XMPP hérite de Jabber et repose sur un flux XML, une authentification SASL et trois stanzas : message, presence et iq. Un JID se construit en utilisateur@domaine/ressource, et le roster stocke les contacts avec leurs souscriptions. Les RFC de 2004, révisées en 2011, fixent le cœur du protocole, tandis que les XEP ajoutent des extensions comme OMEMO ou MUC. Monter un serveur fédéré suppose des enregistrements DNS, un certificat TLS et le choix d'un logiciel comme ejabberd, Prosody ou Openfire. La documentation anglophone reste la voie la plus directe pour vérifier un détail technique.

Sources

https://www.rfc-editor.org/rfc/rfc6120