Résumé

  • RFC 9996 enregistre application/protobuf et application/protobuf+json, avec des règles distinctes pour le binaire, JSON et UTF-8.
  • Le paramètre optionnel version vise une éventuelle version du codage sur le fil. Il ne désigne ni Proto2, ni Proto3, ni une édition, ni une révision de schéma approuvée par une organisation.
  • Daniel Kade propose un reçu de contexte de schéma qui relie, sans les confondre, le type de média, le type de message, le schéma immuable, l’autorité de publication, la politique du décodeur et la décision opérationnelle.

Un décodage réussi peut produire le mauvais objet

Le scénario le plus trompeur n’est pas celui où le parseur s’arrête. C’est celui où tout semble fonctionner. Un service reçoit un corps binaire correctement annoncé comme application/protobuf. La bibliothèque reconnaît le format, lit les couples numéro-type et construit un objet. Aucun octet n’est hors grammaire, aucune exception n’est levée.

Pourtant, le producteur et le consommateur peuvent avoir chargé deux définitions différentes. Le champ 4 est une durée pour l’un, un niveau de priorité pour l’autre. Une valeur d’énumération inconnue est conservée dans un environnement et rejetée ou ignorée dans un autre. Le paquet est authentiquement du Protobuf ; l’interprétation reste fausse.

RFC 9996, publié en juillet 2026 comme RFC informationnel issu du consensus de l’IETF, résout un problème plus étroit. Il enregistre deux types de média : application/protobuf pour la représentation binaire et application/protobuf+json pour ProtoJSON. Il met fin au besoin de s’appuyer sur plusieurs noms historiques en x- et fournit un vocabulaire commun pour le transport.

Le texte trace lui-même la frontière. Ces types servent aux objets sérialisés. Le langage de définition d’interface et les définitions d’objets, s’ils sont transportés, utiliseraient un type textuel approprié. Autrement dit, l’enveloppe indique la famille de représentation ; le contrat sémantique se trouve ailleurs.

Deux paramètres, aucune identité de schéma

Le paramètre encoding distingue le binaire de JSON. Pour application/protobuf, la valeur par défaut est binary. Pour application/protobuf+json, elle est json, et charset=utf-8 est obligatoire. Une combinaison contradictoire doit être traitée comme une erreur. Cette discipline empêche qu’un même libellé recouvre deux grammaires incompatibles.

Le paramètre version est plus facile à surinterpréter. Sa valeur par défaut est 1, mais RFC 9996 précise qu’il concerne une version future du codage sur le fil. Les codages Protobuf actuels ne sont pas versionnés de cette façon. Le paramètre ne renvoie pas au langage de schéma.

Proto2, Proto3, l’édition 2023 et l’édition 2024 sont des étapes de l’IDL. Leurs objets peuvent partager un format binaire compatible, tout en présentant des différences sémantiques. Le RFC cite le traitement des valeurs d’énumération inconnues : des bits compatibles ne garantissent pas une lecture identique.

Écrire version=1 ne fournit donc aucune preuve de « schéma version 1 ». Le nombre ne dit pas quel fichier .proto a été employé, quel paquet ou message est attendu, qui a validé la révision, ni si le destinataire a chargé les mêmes octets de définition. Un paramètre réservé à l’avenir du fil ne peut pas être réquisitionné comme cachet de gouvernance du schéma.

La compatibilité n’est pas une autorisation

Le guide Proto3 rappelle qu’un format de fil compact ne peut pas détecter qu’un numéro de champ a été encodé avec une définition puis décodé avec une autre. La réutilisation d’un numéro peut provoquer une erreur, une corruption ou même l’exposition de données sensibles. Le danger ne prend pas toujours la forme d’un échec visible.

Protobuf possède de vrais mécanismes d’évolution. Les champs inconnus peuvent être conservés dans les parcours binaires qui manipulent le message comme un tout. Les numéros supprimés doivent être réservés. Certaines transformations de type sont compatibles sous conditions. Ces règles permettent un déploiement progressif entre producteurs et consommateurs.

Mais elles ne répondent pas à la question institutionnelle : quelle équipe était habilitée à modifier le contrat, quel test de compatibilité a été exécuté, quelle exception a été approuvée et pour quels consommateurs ? Une compatibilité technique possible ne vaut pas décision d’usage.

La représentation JSON rend la séparation encore plus nette. La documentation ProtoJSON indique qu’elle offre de moins bonnes garanties d’évolution que le binaire. Les noms de champs et d’énumérations deviennent visibles sur le fil ; les champs inconnus ne sont pas pris en charge. Un passage du binaire vers JSON peut les perdre. Une réponse bien étiquetée application/protobuf+json peut donc être valide tout en ayant abandonné une partie que le producteur binaire avait conservée.

Le registre coordonne les noms, pas les actes

Le registre IANA des types de média crée un point de coordination public. Il consigne les sous-types, les paramètres, la spécification publiée, l’usage et le responsable des changements. RFC 9996 déprécie les alias application/x-protobuf, application/x-protobuffer et application/x-protobuf+json.

Ce travail a une valeur concrète. Les passerelles peuvent négocier le bon format. Les navigateurs peuvent reconnaître le suffixe +json. Les politiques de sécurité peuvent distinguer un corps binaire d’un document JSON. Les documentations d’API peuvent cesser d’inventer des variantes locales.

La portée du registre s’arrête là. L’enregistrement binaire n’impose ni nombre magique, ni extension de fichier. Aucun des deux types n’exige un identifiant de schéma, une empreinte, un nom de message, l’identité du producteur, une signature ou un état d’autorisation. L’IETF contrôle l’enregistrement ; il n’endosse pas chaque corps HTTP qui utilise le token.

Un token IANA répond à la question « quel nom commun peut désigner cette représentation ? ». Il ne répond pas à « qui a créé ces octets ? », « selon quel schéma ? » ou « le service peut-il agir sur le résultat ? ». Prêter ces réponses au registre reviendrait à transformer une coordination de noms en attestation universelle qu’elle n’a jamais promise.

Sécurité du transport et autorité sémantique restent séparées

RFC 9996 dit également que Protobuf ne fournit, en soi, aucun service de sécurité, de confidentialité, d’intégrité ou de compression. TLS peut protéger le canal. Des limites de ressources peuvent réduire l’impact d’un message mal formé. Les applications doivent vérifier le contenu incorporé dans les champs string ou bytes. Sur le Web, il faut empêcher la détection opportuniste de contenu et annoncer correctement le JSON.

Ces contrôles sont complémentaires, non interchangeables. TLS peut établir l’identité d’un pair selon une politique donnée ; il ne précise pas quel schéma ce pair devait employer. Une signature peut protéger les octets ; elle ne prouve pas que le décodeur leur a appliqué la bonne définition. Un type +json guide le navigateur ; il ne garantit pas la préservation des champs inconnus.

Même le type Any ne résout pas universellement la question. Son URL de type a été conçue pour identifier et théoriquement retrouver une définition, mais RFC 9996 note que la déréférence n’est pas prise en charge par des implémentations largement utilisées. Une URL peut être un sélecteur utile dans un contrat local. Elle n’est pas, par sa seule présence, une racine de confiance.

Le véritable mandat se trouve en dehors du parseur

Dans une organisation, l’autorité du schéma peut être matérialisée par un dépôt, un registre de paquets, une règle de compilation, un catalogue d’API ou un service privé. Une équipe possède le contrat ; une autre examine la compatibilité ; une chaîne de publication produit un artefact ; un opérateur autorise le déploiement.

Le RFC n’a pas à imposer une architecture unique à tous ces systèmes. Il laisse justement le choix à l’application. Le risque apparaît quand l’organisation ne conserve aucune trace de ce choix. La bibliothèque présente dans l’image du conteneur devient alors l’autorité de fait. Le contrat n’est plus décidé ; il est découvert après coup dans les dépendances.

C’est une délégation invisible. Le propriétaire du processus métier supporte la perte créée par une mauvaise interprétation, tandis qu’une équipe de plateforme ou une mise à jour de bibliothèque peut changer la définition effectivement utilisée. La proximité technique remplace le mandat explicite.

La discipline défendue par Heng Lu invite à décrire ce que les preuves établissent réellement. Ici, le type de média établit une classification de transport. Le parseur établit qu’une séquence peut être lue selon une politique. Une signature ou un canal établit une intégrité ou une identité bornée. L’approbation du schéma est encore une autre décision.

Construire un reçu de contexte de schéma

Il serait disproportionné d’exposer les schémas privés dans chaque en-tête ou d’inventer un régulateur mondial des fichiers .proto. Le contrôle nécessaire peut rester interne, compact et respectueux de la confidentialité. Daniel Kade propose un reçu de contexte de schéma au point où le système décide de s’appuyer sur l’objet décodé.

Le reçu conserve d’abord le type de média reçu et tous les paramètres effectivement évalués. Il indique ensuite le sélecteur du type de message : méthode RPC, point d’API, topic de file, URL Any ou convention locale. Ce sélecteur ne doit pas être attribué au Content-Type lorsqu’il vient d’ailleurs.

Il lie ensuite le paquet de schéma, la génération ou édition du langage, la révision et une empreinte immuable. Le nom humain facilite l’exploitation ; l’empreinte identifie les octets examinés. Pour un schéma confidentiel, une référence contrôlée et l’empreinte suffisent au reçu public ou d’audit.

Viennent l’autorité de source et l’événement de publication : dépôt ou namespace, propriétaire responsable, signature ou preuve d’intégrité, état de révocation et remplacement éventuel. Une adresse connue n’est pas à elle seule une autorisation durable.

Le contrôle de compatibilité doit avoir son propre champ : anciens et nouveaux digests, règles et outil appliqués, changements cassants, exceptions, approbateur et population affectée. Un résultat « parse OK » ne remplace pas cette décision.

Le reçu fixe aussi l’implémentation du décodeur et sa politique : version, traitement des champs inconnus et des énumérations, validation UTF-8, plafonds de ressources et options susceptibles d’altérer la lecture. Il décrit chaque transformation binaire-JSON, copie champ par champ, normalisation ou nouvelle sérialisation, ainsi que les pertes connues.

Enfin, il sépare l’intégrité de l’autorité de schéma, puis consigne l’issue : accepté, mis en quarantaine, refusé, remplacé ou retiré ; responsable ; périmètre ; motif ; lien de correction. Aucune charge utile n’a besoin d’être copiée dans ce reçu.

Cette proposition est une analyse éditoriale de Daniel Kade, pas une exigence de RFC 9996, de l’IANA ou du projet Protobuf. Elle ne retire rien à l’enregistrement. Elle empêche seulement qu’une étiquette de transport hérite d’un pouvoir que l’application doit exercer et justifier elle-même.

Limites des preuves

Les sources vérifiées décrivent les enregistrements, les comportements spécifiés et les limites documentées. Elles ne mesurent pas le déploiement des nouveaux types, ne prouvent aucun incident réel, ne désignent aucun service fautif et n’imposent aucun modèle universel de registre de schémas.

Le RFC est informationnel, et non Standards Track. Le rappeler ne diminue pas son utilité. L’Article ne prétend pas que Protobuf serait dépourvu de compatibilité, que JSON serait toujours dangereux ou qu’une URL de type serait inutile. Il affirme une chose plus précise : la validité du type de média, la compatibilité du fil et l’autorité du schéma sont trois faits distincts.

Sources