Résumé

  • Le RFC 9948 est bien un RFC officiel, publié le 1er avril 2026 avec le statut Informational dans l’Independent Stream. Son avis de statut exclut le Standards Track, toute appréciation du RFC Editor sur la valeur de déploiement et toute accession à un niveau d’Internet Standard.
  • Le barème des peines imite volontairement l’apparence normative : mots en capitales, numérotation durable, DOI et hébergement officiel. Ces attributs authentifient le document ; ils ne donnent aucun pouvoir disciplinaire au sourcil levé, au froncement de sourcils ou au doigt agité.
  • Lorsqu’une citation produit une conséquence, elle devrait porter un reçu compact réunissant identité, stream, statut, date, rapport aux standards, effet IANA, filiation et indices de genre. Il s’agit de conserver la satire et l’archive, non d’installer une police du rire.

« Officiel » répond à une question, pas à toutes

Le mot officiel est trop souvent employé comme une conclusion complète. Dans le cas du RFC 9948, il répond pourtant à une question étroite et importante : le document fait-il authentiquement partie de la série des RFC ? Oui. Son numéro, son DOI, son texte stable et sa fiche chez le RFC Editor ne sont ni une imitation ni une capture d’écran trompeuse.

Il ne répond pas à la question suivante : que peut imposer ce document ?

La fiche indique une publication au 1er avril 2026, dans l’Independent Stream, avec le statut Informational. L’avis placé dans le RFC affirme qu’il ne s’agit pas d’une spécification de l’Internet Standards Track. La contribution est indépendante des autres streams. Le RFC Editor ne se prononce pas sur sa valeur pour l’implémentation ou le déploiement. Un texte approuvé dans ce cadre ne peut devenir candidat à un niveau d’Internet Standard.

Ces données ne diminuent pas l’authenticité de l’objet. Elles définissent son autorité. Le numéro répond à « quel document ? » ; le stream répond à « par quel processus ? » ; le statut répond à « quel type de résultat ? » ; l’acte local d’adoption répond à « pourquoi ce texte aurait-il un effet ici ? ».

Quand une base ne conserve que le premier champ, elle ne ment pas forcément. Elle rend cependant possible une conclusion que sa donnée ne prouve pas.

La satire emprunte la tenue du règlement

Le RFC 9948 poursuit l’institution imaginaire créée dans le RFC 8962. Les deux textes paraissent un 1er avril dans l’Independent Stream, portent le statut Informational et reproduisent le même avertissement sur l’absence de valeur normative ou de recommandation de déploiement.

Le nouveau barème attribue un sourcil levé aux fautes modestes de rédaction. Le Frown vise des erreurs plus sérieuses ; le Shaking of the Head sanctionne la complexité dissimulée ; le Finger Wag renvoie à un autre RFC du 1er avril ; le Head-in-Hand Gesture demeure presque mythique. Plus loin, des remarques réellement entendues dans le travail de protocole deviennent des formules de « persuasion percussive ». Le texte précise pourtant qu’elles ne constituent pas, en elles-mêmes, des peines, et écarte le recours à une nouille mouillée.

Le mécanisme comique est utile à la gouvernance. Il transforme une expérience sociale familière — la désapprobation experte, la correction informelle, le poids des anciens — en administration grotesque. Le lecteur rit parce qu’il reconnaît à la fois l’absence de police et la réalité de l’influence.

Le RFC 8700 inscrit cette pratique dans l’histoire de la série. Il présente les RFC du 1er avril comme une composante particulière de l’Independent Stream et comme des textes humoristiques. Il rappelle aussi que leur réussite suppose qu’ils ressemblent assez longtemps à un RFC sérieux. La confusion momentanée fait donc partie de la forme ; elle ne devrait pas devenir une erreur durable dans un système de décision.

Une capitale n’a pas de compétence propre

Le RFC 9948 annonce que les termes MUST, MUST NOT, SHOULD et leurs voisins doivent être interprétés selon BCP 14 lorsqu’ils apparaissent en capitales. L’effet est savoureux : le costume grammatical de la spécification vient habiller des gestes de sourcil.

Mais BCP 14 classe la force d’une phrase à l’intérieur d’un texte et de son champ. Il ne choisit ni le stream, ni le statut, ni l’institution compétente, ni le destinataire effectivement engagé. Écrire MUST ne fait pas monter un document Informational de l’Independent Stream vers le Standards Track. Cela ne crée pas davantage un service disciplinaire.

Le RFC 3935 va plus loin : même un standard IETF ne prétend pas imposer son emploi ni policer son usage. Il dit en substance que celui qui déclare suivre le standard doit le faire de la manière décrite. Le RFC 9592 reprend la formule communautaire selon laquelle l’IETF n’est pas la police des protocoles.

Il faut donc lire une exigence avec sa juridiction documentaire. Qui parle ? Dans quel type de publication ? Quel acteur extérieur a choisi de rendre la clause pertinente pour un produit, un contrat ou une politique ? Tant que ce dernier acte n’est pas nommé, la capitale est une syntaxe, pas une sanction.

Le fragment exact peut produire une fausse règle

Le problème ne suppose aucune citation inventée. Une extraction peut être exacte et perdre son sens d’autorité. Un moteur garde « RFC 9948 » et une phrase en capitales. Un graphe classe le numéro sous « IETF ». Une matrice de conformité réduit un passage à obligatoire/facultatif. Un résumé retire l’avis de statut parce qu’il semble répétitif.

Le présent dossier ne montre pas qu’un système précis ait commis cette erreur. Il serait contraire à la méthode d’en raconter un. Le risque est architectural : les identifiants courts et stables survivent mieux au transport que les paragraphes qui les qualifient.

La date ne suffit pas comme antidote. Tous les RFC datés du 1er avril ne sont pas nécessairement satiriques, et l’histoire éditoriale le signale. Le contenu seul n’est pas davantage un test sûr pour une machine : une bonne parodie entretient le sérieux apparent. Ici, la conclusion de genre repose sur un faisceau : date, Independent Stream, statut, avertissement de déploiement, filiation avec le RFC 8962, institution fictive, peines impossibles et histoire officielle de la tradition.

Ce faisceau doit voyager avec la citation lorsqu’elle sort du contexte où un lecteur humain pouvait le reconstruire.

Un reçu de genre et d’autorité

Le reçu proposé n’est pas un nouvel élément du RFC et ne demande aucune modification de l’archive officielle. Il appartient à celui qui réutilise la source dans une décision conséquente.

Son premier volet fixe l’identité : numéro, titre, DOI, empreinte du contenu, date de publication et instant de consultation de la fiche officielle. Le deuxième fixe la provenance institutionnelle : stream, statut, approbateur du stream, relations de mise à jour ou d’obsolescence, errata connus.

Le troisième fixe la portée. Le document est-il Standards Track ou BCP ? Quel avis décrit le consensus et la valeur de déploiement ? Une action IANA existe-t-elle ? Pour le RFC 9948, la réponse à cette dernière question est non. Quel acteur réel transforme ensuite la référence en conséquence : mainteneur qui revendique la conformité, acheteur qui l’intègre au contrat, employeur qui l’inscrit dans une règle interne, autorité publique qui l’incorpore dans un texte ?

Le quatrième volet conserve le genre : indices convergents, document de filiation, passage cité avec son entourage, niveau d’incertitude et besoin d’une lecture humaine lorsque l’ironie ou une référence culturelle porte la limite.

Enfin, le reçu nomme son auteur, sa date de révision, ce qu’il ne démontre pas et la voie de correction. Une erreur corrigée dans la fiche doit atteindre la règle dérivée, pas seulement un commentaire oublié.

Cette structure ne donne pas à un classificateur le droit d’interdire l’humour. Elle oblige l’utilisateur de la citation à montrer comment un texte archivé est devenu une décision présente.

L’Independent Stream ne doit pas disparaître sous l’étiquette IETF

Le RFC 9948 parle de la culture IETF, cite ses pratiques et se trouve dans l’écosystème de la série. Le lien d’annuaire vers l’IETF est donc un contexte, pas une attribution du document à l’IETF Stream.

La page actuelle « What Is an RFC? » du RFC Editor distingue cinq streams. Elle précise que l’Independent Stream publie hors des processus officiels de l’IETF, de l’IAB et de l’IRTF. Le RFC 8729 décrit pour chaque stream un processus propre et confie à l’Independent Submission Stream l’examen d’objets situés hors du périmètre des autres. Le RFC 7841 fournit justement des en-têtes et avis différents afin que cette origine ne disparaisse pas.

Une taxonomie qui ne permet que « officiel » ou « non officiel » échoue. Une autre qui range tout RFC comme « standard IETF » échoue aussi. Le modèle exact contient plusieurs relations : artefact officiel de la série ; publication Independent Stream ; statut Informational ; satire sur des usages IETF ; aucune autorité Standards Track.

Garder le rire, retirer le faux uniforme

Il n’y a rien à réparer dans le texte du RFC 9948. Ses auteurs n’ont pas dissimulé une compétence. L’avis est explicite, l’absence d’action IANA aussi, et la filiation comique est publique. Le document n’a pas à être supprimé, déclassé ou rendu introuvable pour satisfaire les limites d’un outil en aval.

Le devoir commence quand quelqu’un veut agir sur la base d’un fragment. Plus la conséquence est forte — rejet d’un fournisseur, échec d’audit, blocage d’un produit, sanction d’une personne — plus la chaîne d’autorité doit être complète.

Le sourcil levé mérite sa place dans l’histoire officielle. Pour devenir une peine réelle, il lui faudrait encore une institution, une compétence, une procédure, un destinataire et un acte d’adoption. Le RFC ne lui donne rien de tout cela.

Sources

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. RFC Editor — fiche du RFC 9948
  5. RFC 9948 — Internet Protocol Police (IPP): Schedule of Punishments
  6. RFC Editor — fiche du RFC 8962
  7. RFC 8962 — Establishing the Protocol Police
  8. RFC 8700 — Fifty Years of RFCs
  9. RFC Editor — What Is an RFC?
  10. RFC 8729 — The RFC Series and RFC Editor
  11. RFC 7841 — RFC Streams, Headers, and Boilerplates
  12. RFC 3935 — A Mission Statement for the IETF
  13. RFC 9592 — Retiring the Tao of the IETF