Résumé

  • RFC 9896 autorise les dessins SVG dans les RFC définitifs, à condition que le concept soit aussi porté par le texte et que l’image lui reste cohérente.
  • L’acceptation par le RPC prouve une admissibilité éditoriale bornée, pas un rendu identique partout, une accessibilité universelle ni la compréhension du lecteur.

Une même relation technique entre dans le RFCXML définitif sous deux formes : une proposition écrite et un dessin. Le HTML déploie une version large, le PDF l’ajuste à la page, un petit écran la réduit et un parcours assisté en donne une autre représentation. Les pixels changent ; la proposition, elle, ne devrait pas changer.

RFC 9896, publié en janvier 2026 dans l’Editorial Stream, remplace l’approche à profil fixe de RFC 7996. La politique demeure, mais le RFC Production Center choisit désormais l’outillage et peut l’adapter. Cette souplesse évite de transformer une implémentation momentanée en constitution permanente.

Elle ne remet pas le sens au moteur de rendu. Le dessin peut éclairer un concept, mais ne doit pas en être l’unique représentation. Les auteurs doivent s’efforcer de décrire entièrement protocoles, formats et architectures dans le texte ; au minimum, l’image doit s’accorder avec lui. Un contrôle de publication réussi signifie donc que l’œuvre respecte un périmètre de règles. Il ne dit pas si une branche optionnelle paraît obligatoire, si une condition a disparu ou si la hiérarchie visuelle contredit la phrase.

RFC 9720 rend cette séparation exploitable : RFCXML est le format définitif, tandis que HTML, texte brut et PDF sont des versions de publication dérivées. RFC 7991 fournit le vocabulaire source. Le fichier définitif, autonome, conserve l’information voulue ; l’image vue sur un écran précis n’en est qu’une projection.

RFC 9896 borne la projection. Pas de script exécutable, pas de ressource externe, pas d’animation ni d’interaction. Les adaptations limitées — échelle, mode sombre ou clair, ajustement d’affichage — ne doivent pas modifier le sens. Ces interdictions réduisent les dépendances cachées. Elles ne prouvent ni la justesse du schéma, ni l’équivalence pour un lecteur d’écran, ni l’absence d’une information portée seulement par la couleur.

L’accessibilité reste donc un dossier de preuve distinct. Le RPC peut écarter les fonctions mal prises en charge ou illisibles sur petit écran et doit viser l’accès des personnes malvoyantes. Les standards d’accessibilité du W3C orientent ce jugement ; SVG 2 décrit un langage plus vaste que le sous-ensemble acceptable dans un RFC. Validité W3C, admissibilité RPC et accessibilité observée ne sont pas le même fait.

Plusieurs versions d’une image peuvent être fournies, et chaque format peut choisir la plus adaptée. Il faut alors relier la cartographie des affirmations textuelles, les empreintes de la source et des variantes, la version des règles, l’outil de rendu, les tests de contraste et de zoom, la description accessible et l’archive. Lors d’un changement, la comparaison du sens compte davantage que la comparaison des pixels.

La politique assume l’évolution : la compatibilité antérieure est souhaitable, non garantie. Le RPC documente l’usage admis, communique les changements, sollicite la communauté et explique ses choix. RFC 9280 situe cette délégation dans la gouvernance de la Série ; la fiche RFC Editor fixe l’identité de publication. Aucun des deux ne prouve le comportement actuel d’un outil nommé.

Le principe de spécification initiale minimale de Heng Lu protège l’obligation commune étroite tout en laissant les choix futurs localement responsables. La primauté du code exécuté demande de tester les rendus réels. Les couches de réalité empêchent de confondre symbole admis et compréhension démontrée.

Le diagramme peut rejoindre l’archive définitive. Il ne remplace pas la proposition qui permet encore de juger chaque rendu.

Sources