Résumé

  • La RFC 9720 autorise le RFC Production Center à rééditer, pour des raisons limitées, la version définitive XML et les versions HTML, texte ou PDF, sans prétendre que toute différence est dépourvue de risque sémantique.
  • L’archive, la date et la justification de réédition forment ensemble un reçu : le fichier actuel ne suffit pas à établir ce qu’un ingénieur ou un contrat a effectivement utilisé auparavant.

Sortir du faux choix

Dire qu’un RFC publié ne change jamais protège contre une forme évidente de pouvoir : modifier l’histoire après que des personnes ont implémenté, cité ou acheté sur sa base. Mais cette formule devient fragile lorsque la série n’est plus un unique fichier ASCII. Une erreur dans le XML, une évolution du vocabulaire RFCXML ou un changement de l’outil de rendu peuvent exiger un entretien réel. À l’inverse, dire « ce n’est que de la mise en forme » transforme l’archive en autorité discrétionnaire.

La RFC 9720, publiée en janvier 2025 sur l’Editorial Stream, ne choisit ni l’immobilité ni l’excuse. Paul Hoffman et Heather Flanagan y remplacent la polysémie de « canonical format » par quatre catégories. Le format définitif est RFCXML ; la version définitive est le RFC publié dans ce format. HTML, texte et PDF sont des formats de publication ; chacune de leurs incarnations est une version de publication. Cette séparation évite qu’un rendu soit pris pour la source complète, et qu’une source maintenable soit présentée comme un droit de réviser librement le document.

Le statut compte également. La RFC 9720 est informative, issue du processus de politique de la série RFC. Ce n’est pas une spécification Internet Standards Track, ni l’assurance qu’un changement de fichier est automatiquement sans incidence pour un déploiement précis.

Une permission étroite

La version définitive peut être rééditée quand le schéma RFCXML évolue, quand une erreur XML est découverte ou quand le changement d’outillage le justifie. La règle impose de préserver autant que possible le contenu sémantique. Elle ne promet pas une absence magique de risque : le texte reconnaît qu’une modification orientée syntaxe peut introduire un effet inattendu. Il demande plutôt de comprendre ce risque, de le limiter et de laisser un tiers l’examiner.

Les versions de publication peuvent elles aussi être rééditées, mais ce n’est jamais une obligation. Le centre de production doit soupeser la cohérence de la série et le danger d’une altération du sens. Cette asymétrie est saine. Un lecteur ne doit pas déduire d’un même numéro RFC que le PDF récupéré aujourd’hui est l’octet exact consulté il y a trois ans ; le producteur ne peut pas non plus qualifier chaque préférence visuelle de maintenance nécessaire.

La règle commune est donc minimale mais ferme. Elle fixe l’invariant à protéger, le sens, et laisse aux opérateurs de l’archive le choix des outils et des méthodes de localisation. La RFC ne prescrit pas la manière de trouver les documents historiques. Elle refuse ainsi de faire passer une politique de formats pour une constitution complète du stockage.

Sans l’ancien fichier, la transparence n’est qu’une promesse

La contrepartie décisive est l’archive. La RFC 9720 exige des ensembles archivés des anciennes versions définitives et de publication, accessibles par les mêmes méthodes que les fichiers courants. Chaque ensemble doit porter sa date de création ou de réédition. Pour les rééditions de la version définitive, le RFC Production Center doit en outre laisser une trace publique et une courte explication.

Ces éléments transforment la confiance en vérification. La page HTML du jour ne tranche pas seule un litige sur une référence, un diagramme, un exemple de code ou un caractère non ASCII. Il faut comparer les versions, lire le motif déclaré et relier le changement au système qui dépendait de l’ancienne forme. Une différence de ligne, de police ou d’image peut être sans portée. Une modification d’un mot normatif, d’une référence, d’un élément de modèle de données ou d’un exemple interprété par un outil peut ne pas l’être.

L’archive distribue aussi les responsabilités. Le processus d’auteur et d’approbation porte le sens voulu. La production entretient la représentation dans une limite documentée. L’implémenteur ou l’opérateur décide encore quelle version il adopte et comment il la vérifie. Avoir servi le fichier le plus récent ne donne à aucun de ces rôles le mandat de parler pour les autres.

Le profil IETF de Heather Flanagan indique qu’elle a été RFC Series Editor de 2012 à 2019, qu’elle est aujourd’hui principale de Spherical Cow Consulting et qu’elle préside notamment SPICE et HotRFC. Cela situe la personne. Cela ne lui attribue ni l’écriture solitaire de la politique, ni la direction actuelle du RFC Production Center, ni la décision sur toutes les rééditions futures.

Le numéro est un index, pas une preuve complète

La RFC 9920, publiée en février 2026, a remplacé la RFC 9280 et met à jour la RFC 9720 parmi d’autres textes de la série. Ce fait montre que la politique elle-même a une histoire ; il ne rend pas toutes les modifications bénignes. La bonne question demeure concrète : quelle version était utilisée, quelle différence existe, et cette différence change-t-elle ce dont dépendait l’implémentation ou l’engagement ?

Une organisation devrait conserver le numéro RFC, mais aussi les identifiants et dates des versions définitive et de publication, les URL et empreintes de récupération, le motif public de réédition, un diff visuel et un diff sémantique, la chaîne d’outils quand elle est connue, le composant dépendant et le réviseur responsable. L’adoption doit pouvoir revenir à la version antérieure, elle-même encore récupérable.

Cette discipline applique une idée plus large des notes de Heng Lu : une trace n’est pas un mandat. Le fait qu’un producteur explique une réédition est une information importante ; il ne peut pas, par cette explication, obliger un opérateur à mettre à jour une dépendance. Celui qui porte le risque doit conserver le droit de tester, d’accepter ou de revenir en arrière.

Sources