Résumé

  • La Final Review des RFC, anciennement AUTH48, intervient après l’approbation d’un Internet-Draft par un flux de publication. Les auteurs contrôlent le contenu complet et les formats puis autorisent la publication; ce contrôle est réel, sans constituer un nouveau vote de l’IETF.
  • À l’entrée dans la file, le RFC Production Center prend la garde de la copie de production. Les corrections éditoriales peuvent y être appliquées, mais tout ajout, retrait ou changement technique dépassant ce périmètre doit être approuvé par le flux d’origine.
  • Le pilote kramdown-rfc et GitHub rend cette séparation visible. Le 27 août 2026, le RFC-to-be 10025 possédait encore une page de Final Review et un dépôt public, alors que sa page d’information RFC n’existait pas encore.
  • Un reçu de Final Review doit relier la version approuvée, la décision du flux, les modifications du RPC, leur qualification, les validations d’auteurs et de flux, les empreintes des formats finaux et l’annonce de publication. Le déploiement reste une preuve distincte.

La pull request prise pour un second scrutin

Un écran public peut donner naissance à une fausse conclusion sans qu’aucune donnée affichée soit fausse. Dans le dépôt d’un futur RFC, une équipe de risque voit une branche RPC-edits, des issues, une pull request et une liste d’auteurs dont toutes les validations ne sont pas encore enregistrées. Le mot « ouvert » devient « contesté »; la validation manquante devient « veto »; le dépôt devient une chambre de vote.

La Final Review occupe pourtant une place plus précise. En amont, l’un des flux de la série RFC a approuvé un Internet-Draft pour publication. En aval, le RPC publiera des fichiers identifiés et une annonce rendra le RFC disponible. Entre les deux, il faut s’assurer que la copie éditée exprime fidèlement ce qui a été approuvé et qu’elle s’affiche correctement dans chaque format.

Ce contrôle n’est pas subalterne. Une erreur dans un extrait de code, une référence instable, une instruction IANA inexacte ou un mot normatif déplacé peut devenir durable dès la publication. Mais la gravité de cette responsabilité ne transforme pas l’équipe éditoriale, les auteurs et les entités GitHub en nouveau corps d’approbation.

Le gain du pilote actuel se trouve donc moins dans le nombre de commentaires que dans leur traçabilité. Le lecteur peut distinguer le texte reçu, la proposition de correction, la question posée, la réponse et l’autorisation exigée. La transparence protège la légitimité seulement si elle ne mélange pas les rôles qu’elle révèle.

L’approbation précède la file de publication

Le guide actuel de publication des RFC commence avant l’intervention des éditeurs. Un document entre dans le processus après approbation par le flux IETF, IAB, IRTF, Independent ou Editorial. Chaque flux dispose de sa propre voie de décision. Le RPC ne reçoit donc pas une proposition sans statut: il reçoit un texte que l’autorité compétente a déjà accepté de publier.

Cette origine détermine la base de comparaison. Après l’entrée dans la file, le RPC contrôle la copie de production. Les auteurs ne remplacent pas librement le fichier approuvé; ils adressent leurs changements au RPC. Si la modification touche la substance ou paraît dépasser l’édition, elle revient au flux d’origine.

Le RFC 9920 formalise cette répartition. L’organe d’approbation de chaque flux répond de son contenu. La fonction RFC Editor assure la production et la distribution. Le RPC édite, conserve la trace de ses interventions et du dialogue avec les auteurs, détecte les effets techniques possibles, demande les éclaircissements nécessaires, établit l’état de préparation et publie.

Il ne s’agit pas d’opposer technique et édition. Une décision de flux sans production contrôlée peut donner un document impropre à servir de référence. Une production parfaite qui modifie silencieusement la substance n’est plus fidèle à la décision reçue. Le premier champ d’un registre sérieux doit donc nommer le fichier approuvé; le second, le flux et l’organe qui l’ont approuvé.

Ce que les auteurs valident réellement

La Final Review ne consiste pas à cliquer sur « OK » après un examen superficiel. Les auteurs doivent répondre aux questions du RPC, vérifier les changements proposés par les coauteurs, relire l’ensemble du texte, contrôler les mentions juridiques et le balisage sémantique, puis examiner les sorties HTML, PDF et texte. Plusieurs échanges et formulations alternatives peuvent être nécessaires.

Dans les instructions du pilote kramdown-rfc, cette charge produit deux validations. La première confirme que le markdown est assez stable pour être converti en RFCXML. La seconde porte sur le contenu et sur tous les formats finaux. Une source correcte peut être mal rendue: indentation, code, tableaux, références ou balises doivent survivre à la conversion.

La validation de l’auteur est donc une attestation d’intégrité et de préparation. Elle relie son nom à une édition déterminée et aux fichiers que le public recevra. Elle ne lui confère pas le pouvoir de substituer une politique technique personnelle à la décision collective déjà prise.

Le régime des auteurs indisponibles confirme cette limite. Le guide prévoit de déplacer la personne vers les remerciements, vers la liste des contributeurs, ou de faire approuver le document à sa place par un responsable du flux. Le crédit peut être préservé sans transformer une boîte de réception inaccessible en droit de blocage perpétuel.

Une validation absente reste un signal sérieux. L’auteur peut être le seul à repérer une déformation. Le reçu doit donc expliquer l’indisponibilité, la voie retenue, le décideur et la date. Ce qui est exclu, c’est un pouvoir implicite dont ni le titulaire ni la procédure de sortie ne seraient identifiables.

La limite qu’un merge GitHub ne peut franchir

Le RPC a lancé le pilote kramdown-rfc le 1er septembre 2025. Il souhaitait travailler dans un format déjà familier à de nombreux auteurs et obtenir des diffs plus lisibles, centrés sur le contenu. Le démarrage prévoyait au moins cinq demandes par mois, avant un élargissement éventuel.

En 2026, les instructions ont adopté le nom Final Review. Il décrit mieux le travail que l’ancien code AUTH48, dont le nombre n’était pas une échéance. GitHub matérialise la garde: une branche sépare les corrections du RPC, les issues attribuent les questions, les pull requests montrent les changements et l’archive conserve les échanges.

Le dépôt du RFC-to-be 10025, consacré à la révision de la spécification des cookies HTTP, fournit un exemple contemporain. Son README précise que le markdown initial reproduit l’Internet-Draft approuvé pour publication. Les corrections du RPC sont isolées. Les auteurs valident contenu et formats. Les Area Directors doivent approuver ce qui dépasse l’édition. Les chairs et le document shepherd sont présents, et un retour au courrier électronique reste possible.

Au 27 août 2026, la page de Final Review et le dépôt répondaient, tandis que la page d’information du RFC 10025 renvoyait 404. Le dépôt affichait quinze issues et une pull request. Ces nombres ne prouvent ni quinze défauts techniques, ni quinze objections, ni un retard imputable à quelqu’un. Ils constatent seulement des objets de travail publics à un instant donné.

Lorsque le statut changera, le nouveau fait devra porter sa propre date. La réservation d’un numéro et l’existence de fichiers préparatoires ne suffisent pas à écrire « publié ».

RFC 9991: le mot normatif soumis à l’Area Director

Un échange archivé montre comment la frontière fonctionne lorsqu’elle est réellement sollicitée.

Pendant la Final Review du document devenu RFC 9991, les auteurs ont proposé d’ajouter un mot-clé BCP 14. Une exigence en majuscules peut modifier la portée normative d’une phrase; ce n’est pas une simple virgule. Dans l’échange public, le RPC a demandé l’approbation de l’Area Director, qui l’a accordée.

Chaque verbe possède son acteur. Les auteurs proposent. Le RPC identifie le franchissement possible de la limite et sollicite le flux. L’Area Director approuve. Le RPC publie ensuite les artefacts finaux. Une base qui ne garde que le numéro du RFC efface toute cette chaîne; une base qui garde seulement l’accord de l’AD ne prouve pas dans quels fichiers la modification autorisée a abouti.

L’escalade ne montre pas que le RPC voulait gouverner le protocole. Elle montre au contraire que l’équipe de production a reconnu l’étendue de sa compétence et transmis la décision à l’autorité adéquate.

Pourquoi 48 n’a jamais été un délai garanti

AUTH48 ressemblait à une promesse de deux jours. L’histoire dément cette lecture.

Le RFC 8963 étudie un échantillon de RFC produits en 2018 et sépare la phase d’édition, AUTH48 et le délai final de publication. Dans cet échantillon, AUTH48 durait en moyenne plus d’un mois et variait fortement. Le rapport la décrit comme une vérification finale, au cours de laquelle les auteurs approuvent la version éditée ou demandent une dernière correction.

Le RFC 8700 rappelle la plaisanterie des « 48 jours » ou « 48 semaines ». Son enseignement institutionnel est plus important: une modification technique à ce stade exige l’accord de l’Area Director ou du responsable de flux compétent.

La durée seule ne désigne pourtant pas une faute. Coordination entre fuseaux horaires, auteur indisponible, action IANA, dépendance normative, Stream Hold ou problème d’outil peuvent expliquer des situations très différentes. Le temps appelle une question; il ne fournit ni le responsable ni le motif.

Le nouveau nom supprime une fausse horloge. Il ne faut pas la remplacer par une fausse urne. La Final Review est une finalisation sous contrôle.

Le reçu de Final Review

Champ Preuve à conserver Fonction
Source approuvée Nom, révision, octets et empreinte du draft Fixe la base acceptée par le flux
Décision du flux Flux, organe, date et URL Nomme l’autorité de publication
Remise au RPC Date d’entrée et état de file Sépare décision et garde de production
Ensemble de modifications Branche, diff et empreinte Rend visibles les changements postérieurs
Questions Auteur, réponse et archive Attribue l’incertitude et sa résolution
Qualification Éditoriale, format, technique ou hors édition Détermine l’autorisation nécessaire
Accord des auteurs Identité, portée et date Lie l’examen aux fichiers finaux
Accord du flux Reçu AD ou responsable de flux Empêche l’édition de devenir autorité de contenu
Blocages externes IANA, cluster, flux ou outil Évite d’accuser le mauvais acteur
Artefacts finaux Empreintes HTML, PDF, TXT et XML Relie l’accord à ce qui sera lu
Publication Annonce, URL et heure Prouve le passage de RFC-to-be à RFC
Adoption Implémentations, essais et déploiements Sépare document et réalité opérationnelle

Ce reçu ne remplace pas le jugement. Il permet d’identifier qui l’a exercé et dans quel périmètre. On peut alors dire « une sortie attend l’accord d’un auteur », « une modification technique attend l’AD » ou « l’action IANA n’est pas terminée », au lieu d’inventer un veto ou une nouvelle élection.

Sources

Les constats relatifs au RFC 10025 sont arrêtés au 27 août 2026. Aucun nombre d’issues n’est transformé en nombre de défauts et aucune date de publication n’est anticipée.