Résumé

  • La RFC 7942 autorise une section facultative Implementation Status dans un Internet-Draft. Elle peut rattacher chaque implémentation à son responsable, sa maturité, sa couverture, la version du brouillon, sa licence, ses essais et sa date d’actualisation.
  • L’inscription ne vaut ni validation ni recommandation de l’IETF. Les renseignements proviennent des contributeurs, peuvent être incomplets et vieillissent ; la section et sa référence doivent donc être retirées avant publication en RFC.
  • Le code peut corriger une spécification sans la remplacer. Après la publication, conformité du produit, interopérabilité, activation et résultat opérationnel demandent des preuves nouvelles.

Deux horloges dans un même travail

Une norme cherche la stabilité. Une implémentation change au rythme des commits, des versions, des licences, des équipes et des essais. La contribution de la RFC 7942 consiste à ne pas forcer ces deux horloges dans le même objet documentaire.

Publié en juillet 2016 comme BCP 205, le texte a pour auteurs Yaron Sheffer et Adrian Farrel. Il ne rend pas le code préalable obligatoire pour toutes les RFC. Il rappelle au contraire que des Proposed Standards peuvent paraître sans implémentation et que chaque groupe de travail garde la faculté de fixer des exigences particulières. Le mécanisme proposé est un moyen facultatif d’éclairer la décision, non un permis universel de publier.

Son prédécesseur permet de comprendre cette prudence. La RFC 6982 avait lancé en 2013 une expérience de dix-huit mois. Elle ne demandait pas simplement combien de brouillons ajouteraient la section. Elle voulait savoir si l’information aidait à départager des solutions concurrentes, si le retour d’expérience modifiait réellement les protocoles, si davantage d’essais d’interopérabilité avaient lieu et si des personnes autres que les auteurs examinaient les textes au moyen du code. La RFC 7942 a ensuite remplacé ce document expérimental.

Le processus a donc lui-même été présenté comme une hypothèse limitée avant de devenir une pratique recommandée.

Le contenu d’un reçu, pas celui d’un palmarès

La section peut nommer l’organisation responsable, le logiciel ou sa page publique, donner une courte description et indiquer son degré de maturité. Elle peut préciser les parties de la spécification couvertes, les versions de l’Internet-Draft compatibles, les conditions de licence, l’expérience accumulée, un contact et la date de dernière mise à jour. Les cas d’essai et rapports d’interopérabilité peuvent compléter l’ensemble.

Chacun de ces champs limite une affirmation trop large. Production sans date ne dit pas si l’état est actuel. Un projet qui « implémente le protocole » sans matrice de couverture ne distingue pas les fonctions obligatoires des options. Un dépôt sans révision du brouillon ni identifiant de build ne permet pas de reproduire l’observation. Deux noms commerciaux ne prouvent pas deux bases de code indépendantes. Deux programmes qui passent un seul échange heureux ne prouvent pas l’interopérabilité de toutes les erreurs et options.

La formule d’introduction proposée par la RFC 7942 prévient le lecteur : l’IETF n’endosse pas les implémentations citées, n’a pas vérifié les informations fournies par les contributeurs et ne présente pas un catalogue exhaustif. D’autres implémentations peuvent exister. Les présidents de groupe et les Area Directors doivent en outre empêcher la section de se transformer en support publicitaire.

Cette règle protège aussi la concurrence des idées. L’organisation qui livre la première un prototype peut légitimement vouloir montrer que son approche est réalisable. Elle ne doit pas, pour autant, obtenir une présomption permanente de supériorité. La visibilité du code doit ouvrir des questions—sur la version, l’indépendance, les limites et les échecs—plutôt que fermer le choix par le nombre de logos.

Le retrait comme garantie de précision

La RFC 7942 qualifie l’information d’inévitablement dépendante du temps. Elle demande aux auteurs d’insérer une instruction au RFC Editor pour supprimer la section entière et la référence à la RFC 7942 avant publication. Le mécanisme des errata n’est pas censé maintenir une liste de produits effacée.

Cette disparition empêche un glissement de sens. Une implémentation qualifiée de prototype lors du brouillon peut être abandonnée ; une autre peut rejoindre tardivement le marché ; la licence peut changer ; le texte final peut différer de la version codée. Conservée dans la RFC, la photographie ancienne profiterait de la durée et de l’autorité documentaire de la spécification. Un lecteur pourrait y voir un état courant, une certification ou une préférence institutionnelle que le groupe n’a jamais accordés.

Lorsque l’état reste utile, le BCP propose un support séparé et ouvert, par exemple un wiki du groupe. Les implémenteurs peuvent alors l’actualiser, le détail peut dépasser la taille acceptable dans le brouillon, et l’information peut survivre à la publication sans être figée. Pour produire un effet utile, cette ressource ne devrait exiger ni authentification, ni inscription, ni contrôle d’accès. La continuité n’est donc pas assurée par l’immobilité, mais par une responsabilité explicite de mise à jour.

La primauté du code n’est pas la souveraineté du code

La RFC 3935 rattache le jugement d’ingénierie de l’IETF à l’expérience réelle de l’implémentation et du déploiement. La RFC 7282 rappelle que le rough consensus ne se réduit pas à un vote et que les objets d’ingénierie doivent mettre les théories à l’épreuve. Dans Running-Code Primacy, Heng Lu insiste sur la même séparation : une publication ne crée pas à elle seule la réalité opérationnelle, et la couche commune doit se limiter à ce que des systèmes indépendants doivent réellement partager.

La RFC 7942 rend cette idée praticable sans donner le pouvoir au premier programme venu. Le code peut démontrer qu’une interprétation est réalisable, révéler une ambiguïté, produire des traces et rencontrer un pair. Le BCP précise néanmoins qu’il ne doit jamais remplacer une spécification claire. Il ne fixe pas non plus la préférence que le groupe devrait donner à une proposition accompagnée de code.

Une implémentation ne prouve donc que ce que son reçu permet de reproduire. Elle ne démontre pas automatiquement la sécurité, la montée en charge, l’indépendance par rapport à une autre implémentation, la conformité au texte final, l’adoption par les opérateurs ou la qualité du service. L’implémenteur contrôle son logiciel et son témoignage ; il ne contrôle ni le jugement collectif ni le réseau d’autrui.

La chaîne qui doit traverser la publication

Pour suivre une affirmation, il faut conserver l’identité exacte du brouillon et sa révision, l’auteur et la date de la déclaration, le logiciel et son build, la licence, la couverture fonctionnelle, les essais, les versions des pairs, les résultats négatifs, l’usage qu’en a fait le groupe et, plus tard, l’état du déploiement.

Un code écrit pour la révision 08 n’atteste pas la révision 12. Un test sur la fonction principale n’atteste pas les options. Une modification du brouillon à la suite d’un essai ne prouve pas que le produit a suivi le texte final. Un numéro de RFC ne démontre ni livraison, ni activation, ni trafic, ni absence d’incident. Chaque changement de responsabilité impose un nouveau reçu.

Le profil officiel de l’IETF Datatracker associait, au 1er septembre 2026, 82 RFC et plusieurs fonctions du moment à l’identité publique d’Adrian Farrel. Il établit la personne, sa longue participation et le contexte d’un coauteur. Il ne lui attribue pas la vérification de toutes les déclarations. Le dispositif distribue au contraire les rôles : les implémenteurs déclarent, les auteurs organisent, les responsables de processus contiennent la promotion, le groupe apprécie, le RFC Editor retire, les opérateurs déploient.

La section disparue conserve ainsi son sens. Elle a permis au réel d’entrer dans le texte tant que le texte pouvait changer. Après publication, le réel doit continuer dans une preuve datée, attribuée et corrigeable, plutôt que bénéficier indûment de l’immuabilité de la norme.

Sources