Cher journal,
En ces temps ou un certain nombre d'entre vous n'ont pas l'air d'avoir envie de tout partager avec leur gouvernement. Voici une annonce qui améliore un peu la sécurité du HTTPS. Tu n'es pas sans ignorer que le modèle actuel de TLS souffre un gros problème. N'importe quelle autorité de confiance peut signer un certificat pour n'importe quel domaine, même si le propriétaire actuel du nom de domaine a déjà demandé à une autre autorité de le faire (…)
LISP (Locator/ID Separation Protocol) n'a rien à voir avec le langage de programmation du même nom. C'est un protocole de séparation de l'identificateur et du localisateur visant à résoudre le problème de la croissance de la taille des tables de routage sur l'Internet. Il est testé depuis des années mais les RFCs le décrivant viennent juste de sortir.
Le RFC principal est le 6830. Un résumé en français :
http://www.bortzmeyer.org/6830.html
Le site officiel des tests (notamment avec Facebook) : http://www.lisp4.net/
L'IETF avait créé en 2004 un groupe de travail nommé MARID, qui avait pour tâche de normaliser un mécanisme d'authentification faible du courrier électronique par le biais de la publication dans le DNS des serveurs autorisés à envoyer du courrier pour un domaine. Deux propositions étaient sur la table, SPF et Sender ID. Microsoft avait pratiqué une intense obstruction contre SPF, pour promouvoir sa propre solution, Sender ID. Six ans après est publié le RFC 6686 qui conclut enfin officiellement (…)
Ce RFC met officiellement fin à une amusante tradition, qui était un des charmes des protocoles TCP/IP mais qui, en pratique, a causé quelques ennuis, justifiant son abandon. Cette tradition concernait le nommage des paramètres dans les protocoles. Normalement, ces noms étaient enregistrés à l'IANA pour éviter des collisions (par exemple, il ne doit y avoir qu'un seul champ nommé User-Agent: dans une requête HTTP). Comme cet enregistrement nécessitait une procédure, parfois lente et lourde, cela contrariait les gens qui (…)
La lutte contre le spam est un domaine où les certitudes (souvent assénées avec conviction) sont plus fortes que les faits. Prenez n'importe quel forum, en ligne ou ailleurs, où on discute des mesures qui pourraient limiter les conséquences du spam, vous y lirez et entendrez des affirmations radicales, par exemple sur l'efficacité du greylisting, sans que les affirmateurs ne se soucient d'appuyer leurs déclarations sur des mesures concrètes, faites dans la réalité. Comme le note le tout nouveau RFC (…)
Linux se tire plutôt bien de cette amusante expérience.
La plupart des RFC décrivent, de façon normative, un protocole ou un format qui sera ensuite déployé sur l'Internet. Mais ce document est différent : c'est un récit d'expérience, celle de deux courageux chercheurs qui, au péril de leur usage de Facebook et dans l'intérêt de la science, ont coupé IPv4 et n'ont accédé à l'Internet que via IPv6 pendant la durée de l'expérience. Les machines de l'expérience n'avaient plus du (…)
Constatant l'absence d'un codec entièrement libre (pas plombé par des brevets, pas contrôlé par une société unique, implémentable en logiciel libre), l'IETF s'est lancée dans la spécification d'un codec satisfaisant. Le RFC 6366 donnait le cahier des charges technique du futur codec (le produit final) et ce nouveau RFC, le 6569, donne les considérations portant sur le processus de développement (processus déjà bien entamé) : méthodologie d'évaluation des propositions, mécanisme de vérification de la compatibilité des implémentations, questions de propriété intellectuelle. (…)
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 e*Xtensible **Messaging and **Presence **P*rotocol.
À 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 e*X*tensible, 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.