Résumé

  • L’IESG recueille jusqu’au 28 septembre les commentaires sur la promotion de la RFC 7405. Le Datatracker affichait encore « AD Review » lors du gel des sources.
  • Depuis 2014, cette courte RFC ajoute à l’ABNF la forme %s pour les chaînes sensibles à la casse et %i pour rendre explicite l’insensibilité à la casse.
  • La demande recense 20 RFC qui la citaient normativement au deuxième trimestre 2026, mentionne HTTP/1.1 et YANG, ainsi qu’un large support par les outils ABNF.
  • Ce faisceau atteste une diffusion dans les spécifications. Il ne rend pas visible, dans le dossier public, le passage vers les cinq éléments du premier critère de la RFC 6410.
  • Un reçu léger peut nommer des exemples vérifiables sans rétablir le rapport formel d’interopérabilité que la RFC 6410 a supprimé.

Une promotion sans nouveau texte

L’ABNF sert à décrire la grammaire de nombreux formats et protocoles Internet. La RFC 5234, qui constitue aujourd’hui STD 68, interprète par défaut une chaîne entre guillemets sans tenir compte de la casse. Pour exiger exactement des minuscules ou des majuscules, les rédacteurs devaient auparavant écrire les caractères sous forme numérique.

La RFC 7405 simplifie ce travail. %s"false" n’accepte que la forme indiquée ; %i"aBc" indique explicitement une comparaison insensible à la casse ; l’absence de préfixe conserve le comportement historique. Le changement tient en quatre pages et met à jour deux passages de la RFC 5234.

La procédure engagée ne publiera pas une nouvelle RFC. La RFC 6410 autorise l’IESG, après un Last Call d’au moins quatre semaines, à reclasser le texte existant. L’avis du 31 août indique qu’un participant individuel a saisi l’IESG et qu’une décision est envisagée dans les semaines suivantes. Le 28 septembre marque la fin des commentaires, pas une date d’adoption garantie.

Cette chronologie empêche une confusion fréquente. La demande décrit pourquoi une promotion serait justifiée. Le Last Call permet de tester cette description. Seule la décision ultérieure modifiera le statut.

Les indices d’adoption sont sérieux

Le dossier compte 20 références normatives dans des RFC au deuxième trimestre 2026. La page actuelle du Datatracker en montre dans des domaines variés : HTTP, YANG, courrier électronique, média, CDDL et DNS. Elle avertit toutefois que la liste est extraite par heuristique.

YANG 1.1 fournit un exemple concret au niveau du texte normatif. La RFC 7950 emploie %s pour une longue série de mots-clés sensibles à la casse, dont module, container, leaf et rpc. La demande cite aussi HTTP/1.1 et affirme que les outils ABNF prennent désormais largement en charge l’extension.

Un détail renforce l’intérêt de l’intégration à STD 68. En 2024, la RFC 9535 a encore codé true, false et null avec des octets hexadécimaux. Ce choix ne prouve ni une panne ni une incompatibilité. Il montre que l’autorité documentaire de la petite extension n’est pas toujours perçue comme allant de soi.

Pour les autres critères, le dossier est direct. Une proposition d’erratum qui préférait les apostrophes a été rejetée. Aucun erratum bloquant l’interopérabilité n’est signalé. La fonctionnalité est unique, n’ajoute pas une grande complexité inutilisée et ne dépend pas d’une technologie brevetée annoncée.

Une référence n’est pas un déploiement

Le premier critère de la RFC 6410 combine cinq constats : au moins deux implémentations, leur indépendance, leur interopérabilité, un déploiement étendu et une expérience opérationnelle réussie. La demande répond par des indicateurs agrégés. Elle ne nomme pas publiquement deux logiciels et leurs versions, n’explique pas l’indépendance des bases de code, ne fournit pas de corpus commun, ne décrit pas les environnements observés et ne fixe ni durée ni résultat opérationnel.

Cette absence dans le document n’autorise pas à conclure que les implémentations manquent. Les spécialistes peuvent connaître plusieurs parseurs. Des opérateurs peuvent utiliser la syntaxe depuis des années. Les preuves peuvent être dispersées entre dépôts, listes de diffusion et mémoire des mainteneurs.

Il faut néanmoins conserver la nature de chaque indice. Une référence normative prouve qu’une spécification dépend de la règle. Elle ne prouve pas automatiquement que chaque logiciel déployé analyse cette partie de la grammaire. L’affirmation « aucun problème connu » devient plus informative lorsqu’elle précise quels systèmes et quels usages auraient permis de voir une divergence.

La RFC 6410 refuse déjà la bureaucratie excessive

La meilleure défense de la demande se trouve dans la règle invoquée. La RFC 6410 a supprimé l’obligation d’un rapport formel de tests d’interopérabilité. Elle considère que le déploiement et l’usage peuvent suffire. Imposer un nouvel événement de laboratoire à une syntaxe ancienne et étroite transformerait facilement la preuve en cérémonie.

Le reçu proposé n’est donc pas un nouveau verrou. Pour deux exemples au moins, il relierait un nom et une version d’implémentation, la base de son indépendance, la forme RFC 7405 exercée, un corpus ou un correspondant, une classe de déploiement, une période d’observation, le résultat et les limites connues. Une description bornée peut préserver les informations commerciales ou de sécurité.

L’IESG pourrait ensuite expliquer pourquoi l’ensemble représente un déploiement étendu et une expérience réussie. Les objections substantielles du Last Call recevraient une disposition, sans être converties en scrutin. Le pouvoir de décision resterait exactement là où la procédure le place.

Le code doit laisser une piste attribuable

Le principe du « running code » défendu par Heng Lu n’est pas une formule magique. Il sert à confronter une affirmation technique à l’exécution. Sans nom, version, entrée et résultat, le code invoqué risque de devenir un argument d’autorité aussi abstrait que le texte qu’il était censé discipliner.

Les rôles doivent donc demeurer distincts. Les mainteneurs apportent l’expérience ; les auteurs de RFC montrent la diffusion normative ; les participants au Last Call objectent ou complètent ; l’IESG juge. La promotion peut être pleinement méritée tout en gagnant à publier le pont qui relie ces contributions à son étiquette finale.

Sources

  1. IETF — Last Call sur la promotion de la RFC 7405
  2. IETF Datatracker — demande de changement de statut
  3. RFC 6410 — les deux niveaux de maturité
  4. RFC 7405 — chaînes sensibles à la casse en ABNF
  5. IETF Datatracker — références à la RFC 7405
  6. RFC 5234 — spécification de l’ABNF
  7. RFC 7950 — langage de modélisation YANG 1.1
  8. RFC 9535 — expressions JSONPath
  9. RFC Editor — errata de la RFC 7405
  10. Heng Lu — primauté du code exécuté