Résumé

  • Le statut Verified indique qu’un erratum a été examiné et jugé exact. Le RFC Editor précise néanmoins que sa correction n’est pas intégrée aux versions TXT, PDF ou XML ordinaires du RFC.
  • Un erratum répare une erreur présente lors de la publication. Il ne peut servir à introduire une idée nouvelle, à modifier le consensus initial ou à éviter la publication d’un RFC de mise à jour.

Deux documents, deux dates, deux autorités

Lorsqu’une équipe découvre un erratum Verified, elle voit souvent deux formulations : celle du RFC et celle du rapport. Pour livrer un produit fiable, elle peut devoir appliquer la seconde. Pour expliquer d’où vient la règle, elle doit pourtant conserver la première.

Le RFC est l’archive d’une approbation collective située dans le temps. L’erratum est une décision ultérieure et plus étroite : une personne a signalé un défaut, puis l’autorité du flux de publication a classé ce signalement. Les confondre effacerait la chronologie qui permet d’auditer la norme.

Le système du RFC Editor ne cache pas cette couture. Il relie les errata à la page du RFC et rend visibles le texte original, la correction, le type, l’état, les dates et le vérificateur. La correction Verified mérite l’attention des développeurs, mais elle demeure dans cette couche adjacente.

La séparation n’est donc pas un refus de corriger. C’est une manière de corriger sans attribuer à un formulaire postérieur le même mandat qu’au processus ayant adopté le document.

Les quatre états ne sont pas des synonymes

Reported signifie qu’une affirmation est entrée dans la file. Ni sa justesse ni son importance ne sont encore établies. Un fournisseur ne devrait pas présenter ce statut comme la nouvelle lecture officielle.

Verified signifie que le rapport est valide et utile aux personnes qui implémentent ou déploient le RFC. Cette validation est forte, mais bornée : elle confirme une correction conforme à l’intention initiale, pas une révision générale du protocole.

Rejected ferme cette voie. Le rapport peut être faux ou proposer une évolution trop substantielle. Dans ce dernier cas, l’IESG renvoie la question vers une discussion technique et un nouveau RFC qui met à jour ou remplace le précédent.

Held for Document Update conserve un point qui n’exige pas de correction immédiate. Une future révision pourra l’examiner de nouveau. Le statut ne dit ni que le texte proposé est en vigueur, ni que sa formulation a déjà reçu le consensus nécessaire.

Une base de conformité qui transforme ces quatre états en un seul champ « corrigé » crée donc sa propre norme. Elle convertit une déclaration, un rejet et une réserve pour l’avenir en obligations équivalentes.

Le flux du RFC détermine le vérificateur

La série RFC n’est pas produite par une seule procédure. Les flux IETF, IAB, IRTF, Independent Submission et Editorial reposent sur des autorités d’approbation différentes. Le choix du vérificateur suit cette origine.

Pour un erratum technique du flux IETF, les auteurs, les présidents du groupe de travail et les Area Directors sont informés. Les Area Directors restent responsables du traitement, même s’ils peuvent déléguer l’examen. Les erreurs éditoriales passent d’abord par le RFC Editor, avec recours à un Area Director lorsque la question dépasse l’édition évidente.

Cette répartition évite qu’une fonction de production devienne, par possession de l’outil, l’autorité sur le contenu du protocole. Elle évite également qu’un spécialiste technique modifie la mémoire publique sans trace de la décision éditoriale et du flux concerné.

Pour l’utilisateur professionnel, le mot Verified ne suffit donc pas. Il faut aussi connaître le flux, la personne ou l’organe ayant vérifié, la date et la raison. Sans ces éléments, l’étiquette est séparée de la compétence qui lui donne sa valeur.

L’intention initiale fixe la limite

La déclaration active de l’IESG de 2021 est précise. Un erratum porte sur une erreur qui existait au moment de la publication. Une capacité apparue plus tard, une préférence technique nouvelle ou un désaccord avec le choix approuvé appartient à un autre débat.

Une solution technique claire et conforme à l’intention d’origine peut être Verified. Si la solution demande une discussion ou si l’intention demeure incertaine, le rapport doit rester Held. Une modification qui change le fonctionnement du protocole par rapport au consensus doit normalement être Rejected. Le même principe vaut pour une procédure, par exemple une politique d’enregistrement IANA.

La longueur du changement ne mesure pas son pouvoir. Remplacer un verbe normatif, déplacer une valeur par défaut ou ouvrir une plage de codes peut bouleverser l’interopérabilité. Le vérificateur doit regarder le contexte, les discussions du groupe, le Last Call, les positions de l’IESG et l’algorithme entier.

Lorsque ces preuves ne donnent pas une réponse nette, conserver l’incertitude est plus honnête que fabriquer une correction définitive. Le canal d’errata n’est pas une séance de rattrapage du consensus.

Rééditer la forme sans changer le sens

RFC 9720 a modernisé la politique de publication. La version définitive RFCXML et les rendus peuvent être réémis pour des motifs étroits : évolution du schéma, erreur XML ou changement des outils de production. Les anciennes versions doivent rester archivées et la réémission doit avoir une date et une justification publiques.

RFC 9920, publié en février 2026 et remplaçant RFC 9280, conserve la stabilité comme propriété historique de la série tout en reconnaissant cette possibilité. La règle centrale reste la préservation du contenu sémantique.

Réparer un rendu tronqué n’est pas adopter une nouvelle conduite de protocole. Régénérer un PDF cohérent n’est pas intégrer tous les errata au texte normatif. La réédition entretient le support de publication ; l’erratum documente une correction ; un RFC ultérieur porte l’autorité d’une évolution approuvée.

Cette distinction donne une réponse vérifiable à une question souvent négligée lors d’un incident : deux équipes ont-elles appliqué des règles différentes, ou ont-elles seulement consulté deux rendus du même sens ?

Une méthode de référence pour les implémentations

Une équipe ne devrait pas écrire seulement « conforme à RFC 1234 ». Son dossier doit préciser la version de publication consultée, les RFC qui la mettent à jour ou l’obsolètent, la date de consultation des errata et la liste des corrections Verified retenues.

Les tests peuvent alors associer une correction à un comportement observable. Si des pairs déployés suivent encore le texte non corrigé, la note de version peut décrire le risque de compatibilité. Pour une faute de sécurité, une mitigation rapide peut être nécessaire même si l’archive n’est pas modifiée.

Les éléments Held nourrissent la revue de conception, mais ne deviennent pas automatiquement des échecs de conformité. Les éléments Rejected gardent aussi une valeur historique : ils montrent qu’une interprétation a été examinée et qu’elle n’a pas obtenu ce statut.

Cette discipline évite l’infaillibilité fictive de l’archive et le pouvoir fictif de l’administrateur de correction. Le corpus utile est composé de couches identifiables, pas d’un texte fusionné dont personne ne peut expliquer l’origine.

Le registre commun minimal

La doctrine de Heng Lu propose un socle commun étroit, des décisions futures prises par les acteurs compétents et l’adoption volontaire des améliorations. Le système d’errata illustre ce principe lorsqu’il se limite à des prédicats vérifiables.

Le registre commun peut dire quel passage a été contesté, quelle correction a été proposée, qui l’a classée, quand et pourquoi. Il ne peut pas prouver que tous les logiciels l’ont adoptée, qu’un rapport Held crée une obligation ou que le silence d’un groupe fermé équivaut à un accord.

En gardant ces propositions séparées, l’IETF peut améliorer le code en fonctionnement sans perdre la mémoire de sa décision. La légitimité vient de la précision du dossier et de la limite du mandat, non d’une illusion de texte éternellement parfait.

Sources