Résumé

  • La révision 28 de Concise Diagnostic Notation enrichit la représentation lisible de CBOR, sans transformer le texte source en contrat d’exécution autonome.
  • Pour une décision sensible, il faut une quittance d’interprétation : révision, instantané du registre, code de l’extension, version, autorisations, avertissements, valeur obtenue et, si nécessaire, empreinte des octets.

Le principal avantage d’une notation de diagnostic est aussi l’origine possible d’un malentendu. Parce qu’un humain peut lire une valeur, il peut croire que tout ce qui détermine cette valeur se trouve sur la page.

La révision 28 du projet Concise Diagnostic Notation, travail actif du groupe CBOR de l’IETF, consolide la manière d’écrire le modèle de données CBOR sous forme textuelle. Un littéral préfixé n’est pas seulement une chaîne décorée. Son préfixe appelle une extension applicative. h ou b64 peut produire des octets ; dt porte une représentation temporelle ; ip traite une adresse ou un préfixe. Une séquence préfixée peut transmettre des paramètres et produire un seul élément du modèle de données.

Cette commodité distribue aussi l’autorité. Le fichier contient le nom demandé, mais pas nécessairement l’instantané du registre utilisé pour le résoudre. Il ne prouve ni l’implémentation chargée, ni sa version, ni les options actives, ni la liste d’autorisation de l’opérateur. Il ne dit pas non plus si un indicateur visible a été appliqué ou simplement accepté puis ignoré.

Le projet ne cache pas ces limites. Il précise que CDN vise les humains et n’est pas une représentation déterministe. Un aller-retour entre une valeur, sa notation et un encodage ne promet ni la même graphie ni les mêmes octets. Lorsqu’un indicateur d’encodage accompagne l’argument d’une extension qui ne lui attribue pas de traitement spécial, le consommateur doit l’accepter : il peut le traiter ou l’ignorer. Un avertissement est recommandé dans ce dernier cas. Le succès du parseur ne démontre donc pas que tous les signes vus par le relecteur ont influencé le résultat.

La section de sécurité est encore plus nette. Un outil doit empêcher qu’un attaquant puisse invoquer des extensions que l’opérateur n’avait pas prévu d’exposer. L’activation explicite et la liste d’autorisation sont des défenses légitimes ; l’activation peut rester une décision hors bande. Deux interprètes peuvent donc reconnaître la même grammaire tout en prenant des décisions différentes parce que leurs propriétaires n’ont pas délégué la même capacité.

Le registre coordonne un nom, pas tout le système

Le projet propose un registre d’identifiants et rend obligatoires à implémenter h, b64, t1, b1, dt et ip. Le registre évite les collisions et crée un vocabulaire commun. Il ne fusionne pas quatre réalités distinctes : l’entrée du registre, la spécification de l’extension, le code qui l’exécute et la politique du déploiement.

La politique prévue est l’Expert Review. Le texte envisage même qu’une spécification complète ne soit pas encore disponible et qu’un identifiant déjà déployé soit enregistré pour éviter une collision. « Enregistré » signifie alors que le nom est coordonné. Cela ne signifie pas automatiquement « sémantique complète et stable », « même code partout », « activation sûre » ou « autorisation accordée ici ».

Imaginons deux chaînes de livraison recevant exactement le même fichier. La première charge toutes les extensions installées ; la seconde n’autorise qu’un ensemble minimal. La première construit une valeur, la seconde refuse. L’empreinte du fichier est identique et le préfixe existe. La différence se trouve dans la décision locale. Sans preuve de la version, de l’extension et de la liste d’autorisation, qualifier l’un des résultats d’erreur serait aller au-delà des faits.

Autre cas : les deux chaînes acceptent le texte. L’une traite un indicateur, l’autre l’ignore et émet un avertissement que l’interface ne conserve pas. Les deux affichent « succès ». Pourtant, le dossier de preuve n’est pas le même. L’avertissement et la valeur produite doivent accompagner le statut du parseur.

Une révision qui demande elle-même de la prudence

Datatracker présente la révision 28 comme un Internet-Draft actif du groupe CBOR, en dernier appel du groupe, avec l’état IESG « I-D Exists ». Ce n’est ni un RFC ni une norme approuvée.

Les sources figées divergent même sur le statut visé : l’en-tête du texte annonce « Standards Track », tandis que l’API Datatracker enregistre « Informational ». Il serait fautif de résoudre cette divergence à la place du processus. Aucun de ces champs n’est une décision finale de publication.

La note de la révision 28 est exceptionnellement explicite. Elle dit refléter des suppressions de fonctionnalités discutées sur la liste, sous forme de delta par rapport à la révision 27. Elle qualifie le texte de partiellement incohérent, prévient que certaines explications peuvent devenir trompeuses et indique l’absence d’avis du groupe sur les noms CDN et b1/t1. La comparaison des deux révisions confirme notamment la disparition de l’extension CRI, d’un registre d’indicateurs et des représentations binaires balisées de l’entrée CDN.

Cette honnêteté est précieuse. Elle interdit toutefois de traiter « compatible révision 28 » comme une preuve complète. Il faut savoir quelles fonctions supprimées restent éventuellement derrière une option, quelle version du code applique le nouveau périmètre et quel registre a été consulté.

Déplier le mot « valide »

Un voyant vert condense au moins sept questions : les octets source sont-ils ceux qui ont été relus ? quelle révision de grammaire les a acceptés ? quel instantané de registre a résolu le préfixe ? quelle extension et quelle version ont traité les paramètres ? quelle politique locale a permis l’appel ? quels indicateurs ont été ignorés et quels avertissements ont été conservés ? quelle valeur CBOR, puis quels octets, ont réellement été produits ?

Ces réponses peuvent diverger indépendamment. L’empreinte source peut rester stable tandis que la bibliothèque change. Le registre peut être figé tandis que la liste d’autorisation évolue. La valeur peut rester identique mais son encodage varier. Les octets peuvent être exacts sans que l’application soit autorisée à agir.

La solution est une quittance d’interprétation. Cette proposition est une recommandation opérationnelle de Daniel Kade, pas une exigence de la révision 28. La quittance consigne l’empreinte source, la révision, le registre, la spécification et l’implémentation de l’extension, sa version, les paramètres, les options hors bande, les autorisations, la règle appliquée aux indicateurs, les avertissements, la valeur résultante et l’empreinte des octets lorsque leur identité compte.

Elle doit s’arrêter à la frontière de l’interprète. La validation par schéma, la signature, l’autorisation de l’action, la mutation du réseau et le résultat métier exigent leurs propres preuves. Un unique drapeau « valide » efface précisément l’endroit où une divergence peut être réparée.

Les sources ne démontrent aucun taux d’adoption, test d’interopérabilité, comportement d’un produit nommé, incident, vulnérabilité ou panne. Elles suffisent en revanche à montrer le partage de contrôle : modèle d’extension, politique de registre, activation hors bande, avertissements et non-déterminisme sont tous écrits dans le projet.

RFC 8949, RFC 8610, RFC 4648 et RFC 3339 éclairent respectivement CBOR, CDDL, les encodages de base et le temps. Ils ne prouvent pas que deux interprètes déployés possèdent le même code et la même configuration. Même un encodage déterministe, sujet de RFC 9741, intervient après le choix de la valeur ; il ne choisit pas la sémantique de l’extension.

La conclusion est volontairement limitée : le préfixe enregistré est une bonne unité de coordination. Le parseur qui réussit apporte un élément de preuve. Aucun des deux ne remplace la quittance de l’exécution.