RFC 9682 : ce qu’un accent change à la compatibilité

Résumé

• L’Appendice A normatif de la RFC 9682 remplace l’ABNF collectée de l’Appendice B de la RFC 8610. L’extension \u{hex} conserve la compatibilité des anciens modèles conformes avec la nouvelle grammaire, sans garantir l’acceptation des nouvelles écritures par les anciens processeurs. La direction de cette compatibilité est explicitement précisée dans la RFC 9682.
• Une analyse syntaxique réussie ne prouve ni la fidélité d’un validateur généré, ni son déploiement, ni le traitement correct des messages. Pour engager une migration, il faut relier chaque conclusion à son objet : source exact, outil identifié, résultat conservé et consommateur concerné.

Ce qui change dans le fichier, pas dans le caractère

Prenons trois modèles hypothétiques, chacun contenant une seule définition : libelle = "é", libelle = "\u00E9" ou libelle = "\u{E9}". Il s’agit, dans les trois cas, du même point de code U+00E9, non de caractères simplement ressemblants. Les deux premières notations s’appuient sur les conventions de chaînes JSON auxquelles renvoie la RFC 8610, section 3.1. La troisième exprime cette valeur avec la nouvelle forme d’échappement.

L’équivalence porte sur la valeur représentée. Elle n’efface pas la différence entre les octets des trois sources. Un affichage qui présente seulement le résultat décodé masque précisément l’information nécessaire pour retrouver quelle écriture a été soumise au parseur. Une relecture peut donc conclure, à juste titre, que le caractère n’a pas changé, tout en laissant ouverte la compatibilité du fichier.

Le message réseau appartient encore à un autre niveau. En CBOR, les chaînes textuelles sont encodées en UTF-8 ; les caractères n’y sont pas transmis sous forme d’échappements Unicode, rappelle la RFC 8949, section 3.1. L’écriture CDDL \u{E9} n’impose donc pas ces caractères ASCII dans le message. Une migration de notation peut ne rien modifier à la valeur transportée, tout en modifiant les conditions nécessaires à la lecture du schéma.

Cette dissociation importe pour la recette : comparer seulement des messages ne répond pas à la question de la portabilité des modèles. Comparer seulement des modèles ne répond pas davantage à celle du traitement des messages.

La grammaire fait autorité ; le parc logiciel reste à établir

La réparation couvre les errata 6278, 6526, 6527, 6543 et 6575 : cohérence des chaînes, antislashs perdus, échappements et précision sur les balises et valeurs simples. Leur traitement figure dans les sections 2 et 3 de la RFC 9682. L’Appendice A fournit le texte normatif de remplacement ; il ne remplace pas toute la RFC 8610.

L’ABNF est le langage de description de cette syntaxe. La RFC 5234 définit notamment comment assembler règles, alternatives et répétitions. Publier une nouvelle grammaire établit une référence ; cela n’installe aucun logiciel chez celui qui reçoit le modèle. Il faut donc séparer la question normative — quelle syntaxe est définie ? — de la question expérimentale — quel exécutable accepte quelle entrée ?

La rétrocompatibilité annoncée ne constitue pas non plus une promesse de conserver toutes les tolérances d’un ancien outil. Une entrée autrefois acceptée n’était pas nécessairement conforme. Inversement, un processeur ancien pourrait déjà comprendre une extension : son âge ne permettrait pas, à lui seul, de conclure. Pour une décision opérationnelle, l’étiquette « ancien » ou « récent » doit céder la place à une version précise et à des capacités établies.

Un feu vert peut porter sur le mauvais objet

Imaginons une chaîne entièrement hypothétique. Un outil de préparation actualisé remplace "\u00E9" par "\u{E9}". Le contrôle central accepte le nouveau fichier. Un destinataire utilise cependant une autre version de processeur. Le succès central ne dit encore rien de ce second parcours. La section 4 de la RFC 9682 avertit justement du risque d’interprétations différentes entre outils mis à jour et non mis à jour.

Dans ce scénario, le premier piège serait de demander uniquement si chaque fichier « passe ». Pour les processeurs censés prendre en charge les trois notations, la comparaison devrait aussi porter sur la valeur obtenue. Deux acceptations ne suffiraient pas si les représentations internes divergeaient. Et deux outils d’accord ne constitueraient pas, à eux seuls, un arbitre de la conformité : ils pourraient partager la même erreur.

Une épreuve proposée autour de cet exemple devrait comporter un cas voisin : une chaîne représentant littéralement un antislash suivi de u{E9}, écrite "\\u{E9}" dans le modèle. Elle ne devrait pas être confondue avec le caractère « é ». L’enjeu serait de vérifier la frontière entre notation et contenu, puis sa conservation lors des transformations, plutôt que de collectionner trois résultats positifs presque identiques.

Le troisième piège serait d’attribuer à l’intégration continue un périmètre qu’elle n’a pas. Un contrôle portant sur le parseur ne démontre rien, par sa seule réussite, sur une compilation de schéma non examinée. Une exécution contre un validateur ne renseigne pas sur un autre artefact portant le même nom. La confiance exige ici moins un voyant supplémentaire qu’une description exacte de ce qui a été soumis à quel contrôle.

Du modèle livré au message reçu

Pour suivre notre chaîne hypothétique jusqu’au bout, neuf objets doivent rester reconnaissables.

La publication du standard fournit la référence normative. Les octets du modèle constituent l’entrée effective : une révision de dépôt ou une empreinte aiderait à les identifier, à condition de conserver le fichier correspondant. Ces deux preuves répondraient à des questions différentes : « selon quel texte ? » et « à partir de quel contenu ? ».

La version du parseur identifierait ensuite le lecteur, avec ses options et les capacités pertinentes. Son résultat d’analyse établirait ce qu’il a fait de ce modèle précis. Une déclaration de prise en charge ne serait pas ce résultat ; réciproquement, un résultat positif isolé ne démontrerait pas la prise en charge de toute la grammaire.

La compilation du schéma, si cette architecture en comporte une, constituerait une étape supplémentaire : quelles contraintes ont été comprises et préparées pour l’exécution ? Le validateur généré serait encore un autre objet, à rattacher au source, au compilateur et aux options utilisés. Cette architecture est illustrative, non prescrite par les RFC. La RFC 8610, section 4.2, laisse aux concepteurs et implémenteurs de l’application le choix de l’étendue du contrôle des données.

Le consommateur déployé demanderait sa propre identification. Avoir produit un validateur ne prouverait ni qu’il a été livré partout, ni qu’il est effectivement invoqué sur le chemin concerné. Une preuve de construction et une preuve d’activation ne sont pas substituables.

Viendrait alors le message d’exécution, avec son contenu et le traitement observé. La RFC 8949, section 1.2, distingue données bien formées, données valides et données répondant aux attentes de l’application. L’acceptation du source CDDL ne remplit pas automatiquement ces trois conditions pour un message.

Enfin, l’interopérabilité observée concernerait un échange entre participants identifiés, dans des conditions déterminées. Même concluante, elle ne garantirait pas toutes les combinaisons de versions ni tous les messages futurs. Cette limite ne dévalue pas l’observation : elle empêche seulement de lui faire certifier ce qu’elle n’a pas couvert.

Cette distinction rejoint, par analogie, la séparation entre légitimité symbolique et pouvoir effectivement exécutable proposée par Lu Heng dans son essai sur les couches de réalité. C’est une grille de lecture, pas une exigence IETF : ici, l’autorité de la grammaire reste entière, mais elle ne tient pas lieu de constat de déploiement.

La provenance avant l’automatisation

La RFC 9682 recommande de traiter les modèles employés opérationnellement avec le soin accordé au code source, en établissant leur provenance, leur authenticité, leur intégrité et leur applicabilité, dans ses considérations de sécurité.

La conséquence pratique est précise. Une empreinte pourrait établir que deux équipes possèdent le même fichier ; elle ne dirait pas qui était autorisé à le modifier. Une origine authentifiée ne démontrerait pas que cette révision convient au service visé. Une modification purement notationnelle mériterait donc une revue de compatibilité, même si la valeur Unicode demeure identique.

Dans une automatisation de sécurité hypothétique, une divergence de lecture pourrait entraîner un rejet indésirable ou une vérification différente de celle attendue. Ce sont des scénarios de risque, pas des incidents constatés. La RFC 8610, section 5, déconseille déjà de faire reposer la sécurité sur la seule correction du modèle ou de son implémentation, sans défenses supplémentaires.

Le point décisif n’est ainsi ni l’esthétique des échappements ni le prestige d’une référence. C’est la possibilité de démontrer, sans sauter d’étape, comment un source identifié a conduit au comportement effectivement observé.