C’est en 1999 que Jeremie Miller crée Jabberd, serveur open source de messagerie instantanée et de présence. Il appelle le protocole (de fait) sous-jacent « Jabber », terme traduisible directement de l’anglais au français comme un « bavardage ». Puis, le petit protocole au nom sans prétention commença à en avoir. Voulant jouer dans la cour des grands, il fut en effet proposé comme standard auprès de l’IETF avec l’objectif de fournir une véritable interopérabilité dans le monde de la communication instantanée, encore jeune, mais déjà quasi-entièrement sous le contrôle de divers réseaux privés, propriétaires et sans aucune transparence de fonctionnement.
Mais l’Internet est sans pitié pour les jeunes présomptueux, et il fallut plusieurs groupes de travail IETF, brouillons, stabilisation du protocole, la création d’une fondation (Jabber Software Foundation)… pour que finalement, début 2004, 5 ans après la création du protocole, ce dernier soit enfin un standard reconnu. On lui accorda des numéros pour faire le fier comme James Bond : RFC 3920 (le cœur) et RFC 3921 (Messagerie Instantanée et Présence). Petit protocole devenu grand décida alors de changer de nom pour paraître plus sérieux lors d’entretiens d’embauche. Il se fit donc appeler XMPP, pour eXtensible Messaging and Presence Protocol.
À partir de là, la JSF prit plus d’importance, s’organisa davantage et changea à son tour son nom en 2007 pour XSF, XMPP Standards Foundation. Notons l’évolution sémantique : on est passé d’une entité de code (Software) à une autre gérant désormais clairement des Standards. Les rôles sont répartis entre l’IETF et la XSF. L’IETF s’occupe essentiellement du centre névralgique du protocole, ce qui en fait un protocole Internet interopérable. De son côté, la XSF gère en plus les extensions : les XEP (XMPP Extension Protocols). En effet, XMPP a été créé comme un protocole extensible. Par design, il est un triple protocole — comme son nom l’indique : un protocole de Présence (qui de ses contacts est présent ?), un protocole de Messagerie (non forcément lié à la présence : on peut envoyer des messages à des entités dont nous ne connaissons pas la présence, comme pour les e-mails), et enfin, un protocole eXtensible, qui permet donc de créer des sous-protocoles de communication, pour tout usage. XMPP fut défini comme un protocole applicatif extrêmement générique, non limité à la messagerie instantanée.
La XSF s’occupe donc en particulier de cette dernière caractéristique (extensibilité), et travaille en collaboration avec l’IETF sur les deux autres.
Néanmoins, cela fait maintenant 7 années que le cœur de notre petit protocole n’avait pas été soigné, bien que souvent ausculté puisqu’il se faisait vieux. C’est pourquoi, après toutes ces années de traitement, le voilà comme un nouveau né avec ses nouveaux numéros d’identité.
En effet, pour fêter le printemps, le 21 mars 2011 est à noter comme le jour où les RFC de XMPP seront mises à jour : les RFC 3920 et 3921 sont désormais obsolètes et remplacées respectivement par les RFC 6120 et 6121. Enfin, une troisième RFC voit le jour, standardisant séparément le format des adresses XMPP (ce qui était auparavant intégré à la RFC 3920) : la RFC 6122.
Vous prendrez bien un petit rafraîchissement ?
Il est à noter qu’il ne s’agit pas d’un nouveau protocole. Ce n’est pas non plus XMPP 2.0 ou un quelconque autre terme commercialement sexy. Non, il s’agit simplement d’un rafraîchissement de protocole qui fait suite aux années d’expériences et aux centaines d’implémentations (clients, serveurs, modules…).
Un cœur sain pour un protocole sain
XMPP est un protocole à la pointe des dernières innovations informatiques, notamment en terme de sécurité. Parmi les nombreux changements dans la RFC 6120, nous pouvons ainsi relever divers renforcements sécuritaires, en particulier :
- l’usage de TLS a été consolidé avec le passage de TLS 1.0 (RFC 4346) à TLS 1.2 (RFC 5346), ainsi que l’interdiction d’utiliser SSL 2.0 à cause des failles de sécurité désormais connues de cette version du protocole SSL (voir RFC 6176) ;
- le mécanisme SASL préféré est désormais passé du simpliste DIGEST-MD5 au très récent et élaboré SCRAM-SHA1-PLUS, lequel fournit des fonctionnalités repérant des attaques d’« homme du milieu » (channel binding), ainsi que la protection du mot de passe (en particulier, si la communication est interceptée, l’attaquant ne peut reproduire pour autant la moindre identification ; si les données stockées sur l’ordinateur client sont volées, l’attaquant n’a pas accès au mot de passe, ne peut se connecter que sur le serveur spécifique pour lequel ces données étaient stockées et ne peut les réutiliser ailleurs, et ce, même si l’utilisateur réutilise ce mot de passe sur d’autres services ; et enfin, si les données sont volées sur le serveur, l’attaquant ne peut se connecter nulle part, pas même sur le serveur lui-même) ;
- le système historique et extrêmement faillible d’identification des entités en S2S (server to server), Server Dialback Protocol, est rétrogradé au rang de d’extension XEP, gardant ainsi la compatibilité avec les systèmes anciens, tout en mettant l’accent sur TLS et SASL external (qui devient une technologie obligatoire à implémenter en S2S).
Comme on peut le voir, l’accent a été mis sur la sécurité et la clarification d’usage des mécanismes au cœur du protocole, faisant de XMPP une des technologies les plus avancées de l’Internet.
D’autres évolutions que nous regardons de près concernent les récentes extensions de sécurité sur le protocole DNS (DNSSEC), l’une des bases et pourtant l’un des maillons les plus faibles de l’Internet (le DNS actuel a un niveau de sécurité quasi-nul, d’où le fameux « homme du milieu », ce qui n’implique pas forcément un espion de l’empire du Milieu !). Plusieurs brouillons de RFC ont été proposés afin d’apporter des améliorations de la sécurité des connexions XMPP par DNSSEC, bien qu’encore aucun consensus ne soit acquis.
Un Internet global
Alors que de nombreux protocoles et systèmes s’embourbent dans les problèmes de localisation, XMPP avait, dès l’origine, fait le choix de ne supporter que le codage UTF-8 pour forcer une interopérabilité entre tous au niveau du protocole. Toujours dans cet esprit de globalisation, les problématiques de localisation sont un des sujets les plus en vogues, et en particulier l’internationalisation des adresses XMPP est le thème du moment.
Cela a conduit à la séparation de la RFC 3920 en deux RFC distinctes. En effet, donner aux adresses XMPP leur propre RFC 6122 permettra de plus facilement en changer la définition, sans pour autant devoir retoucher l’ensemble du cœur du protocole, alors même que nous réfléchissons au moyen le plus fluide de migrer de l’ancienne technologie d’internationalisation des adresses (IDNA 2003) à la nouvelle (IDNA 2008) qui est basée sur des procédés très différents et incompatibles à plusieurs égards tant technologiques, que vis‐à‐vis des combinaisons de caractères permises.
Un autre travail important qui a eté mis en avant dernièrement, bien qu’il y ait clairement une forte latence ici, est le travail d’interopérabilité qui doit se faire avec SIP/SIMPLE, l’autre protocole standardisé de messagerie et de VoIP.
Évolution des usages et démocratisation
L’évolution des usages conduit aussi à une évolution des protocoles. Alors que les ancêtres comme HTTP et ceux qui l’implémentent refusent encore de s’approcher des nouvelles technologies très utiles, comme les services DNS (SRV records), XMPP a deux services largement utilisés enregistrés par l’IANA (un pour le client, un pour le serveur) depuis déjà la RFC 3920 !
De nombreuses discussions sont en cours pour davantage simplifier, tout en sécurisant, les usages d’hébergement massif de domaines XMPP chez des fournisseurs de services tiers (ce que, par exemple, Google, avec ses fameux Google Apps, contribue à démocratiser de plus en plus) avec des propositions se basant soit sur de nouveaux enregistrements de services DNS, soit sur DNSSEC, ou les deux à la fois. Là encore, aucun consensus n’est encore acquis.
T’es là ?
Enfin, la messagerie instantanée et la présence ne sont pas en reste. Parmi les nombreuses évolutions de la RFC 6121, la plus notable est probablement le versionnement de liste de contact qui est passé du statut de XEP à celui de protocole IETF, par son intégration dans la RFC 6121. Il permet d’éviter le téléchargement d’une liste de contacts à chaque connexion si elle n’a pas changé, ou de ne charger qu’un différentiel, évitant ainsi du trafic inutile, en particulier pour les gens possédant des milliers de contacts.
De même, la gestion des erreurs pour réparer les problèmes de synchronisation de liste de contacts que les utilisateurs ont pu connaître au fil des années, ainsi que le routage des messages, ont été améliorés.
Un autre ajout intéressant est la nouvelle notion de « parentée » des fils de discussions permettant de créer, là encore, une expérience de dialogue améliorée sur les clients adaptant leur interface.
Ces diverses améliorations et quelques autres devraient grandement améliorer l’expérience utilisateur.
Retour vers le présent
De nombreuses autres innovations sont présentes dans ces mises à jour d’un des protocoles majeurs de l’Internet, mais je ne peux évidemment pas résumer plusieurs centaines de pages de RFC en quelques lignes.
Mais surtout : et le présent ? Et les « vraies fonctionnalités », celles que vous voulez tous : la vidéo, le son, le travail collaboratif, le jeu ? C’est pour quand ?
Les extensions
Vous avez probablement trouvé les paragraphes précédents rébartatifs. Si, si, ne niez pas ! La sécurité ? Pfff, tout le monde s’en fiche ! On veut juste échanger des LOL avec des images qui bougent et discuter de vive voix avec Mère-Grand, nous !
C’est vrai, l’IETF ne s’occupe pas de ça pour l’instant. Par contre, la XSF, si (si vous avez suivi la répartition des rôles des deux entités, vous le savez déjà). Alors j’avoue, les divers clients ne sont pas encore parfaits, la VVoIP (Video and Voice over IP) laisse encore parfois à désirer, mais les implémentations principales ont déjà presque toutes le support. Ce n’est qu’une question de temps avant que ces implémentations soient vraiment fiables.
La feuille de route indiquant les priorités de la XSF liste ainsi toutes ces extensions dont vous rêvez : de la vidéoconférence de groupe, des salons de discussion distribués, des tableaux blancs partagés et de l’édition de document en collaboration, et même le combat contre le courrier indésirable, avant même qu’il n’apparaisse…
Et si vous en voulez plus, n’hésitez pas à jeter un œil à la liste actuelle des extensions XMPP.
Participez !
Quoi, ce n’est pas assez ? Sachez que vous êtes libres de venir nous rejoindre pour discuter du cœur du protocole et l’améliorer, des extensions, de l’opération de services XMPP sur vos serveurs auto-hébergés (la grande mode sur LinuxFr !), de vos implémentations, ou même en tant qu’utilisateur sur les divers salons et listes de discussions de la XSF et de la IETF.
Si vous êtes vraiment intéressé, je rappelle aussi que le statut de membre XSF est gratuit et n’est pas restreint à une élite technique. Nous acceptons toute personne intéressée, que ce soit techniquement, pour améliorer le fonctionnement interne de la fondation, faire tourner son infrastructure ou communiquer et promouvoir le protocole et son écosystème. N’hésitez pas à postuler !
Enfin, si vous êtes étudiant, vous êtes fortement invité à vous rapprocher d’une équipe XMPP pour ensuite proposer sous notre houlette un projet de Google Summer of Code où la XSF participe, comme chaque année.
XMPP est le grand théâtre de la messagerie instantanée
La XSF n’est pas connue pour ses qualités de communications et d’auto-publicité, c’est certain (c’est aussi pourquoi nous avons besoin de vous !). Nous passons assez inaperçu. Et pourtant… le protocole que nous développons, lui aussi discret, est bien loin d’être un figurant.
Citons une liste absolument non‐exhaustive d’acteurs du Net ou d’en dehors qui ont un rôle sur la scène XMPP (pour être clair, ce ne sont pas forcément les vrais techniciens de l’ombre, ceux qui font avancer le protocole). Cette liste n’a pour seul but que de citer quelques noms connus, voire incongrus, pour montrer que XMPP n’est plus un protocole de geek et qu’il est désormais la référence dans le monde la messagerie instantanée. Si je devais citer toutes les entités réellement derrière le protocole, je n’en finirais plus) :
Et si vous étiez la prochaine star de XMPP ?
