Résumé

  • RFC 9512 enregistre application/yaml et le suffixe +yaml afin d’identifier une sérialisation YAML dans l’échange et la négociation de contenu.
  • Cette identification ne tranche ni la version admise, ni la sûreté de l’analyse, ni le sens métier, ni l’autorisation d’une conséquence locale.

Une étiquette d’expédition peut dire de quel entrepôt vient un colis; elle ne dit ni que son contenu a été contrôlé, ni qui a le droit de l’ouvrir, ni où il doit être envoyé. Le champ Content-Type joue un rôle de cette nature. Il aide le destinataire à reconnaître la forme de l’envoi. Lorsqu’une organisation lui prête davantage — une approbation implicite, une validation sémantique, une permission d’agir — elle transforme une convention d’interopérabilité en délégation sans mandat.

RFC 9512 mérite d’être lu pour sa retenue. Le texte enregistre le type application/yaml et le suffixe de syntaxe structurée +yaml. Il fournit une façon commune d’annoncer qu’une représentation est sérialisée en YAML. C’est une contribution réelle : deux systèmes peuvent s’orienter avant de négocier ou de traiter. Mais l’enregistrement ne promet pas qu’un document est acceptable pour tous les récepteurs, ni qu’il conserve le même sens lorsqu’il est transformé, ni qu’un effet opérationnel doit suivre.

La version est le premier rappel. Le type est indépendant des versions; un document peut déclarer une version au moyen d’une directive YAML, mais le type MIME ne la choisit pas. Un service doit donc décider ce qu’il accepte, le consigner et appliquer ce choix. De même, une représentation spécialisée en +yaml peut relever de la famille YAML tout en devant définir ses propres règles d’identification de fragment. L’étiquette de famille évite l’ambiguïté sur le format; elle ne remplace pas le contrat particulier de l’application.

Le cas des flux est plus concret encore. YAML peut contenir zéro, un ou plusieurs documents. RFC 9512 indique qu’une application qui attend un seul document doit signaler une erreur si elle en reçoit plusieurs, plutôt que d’ignorer discrètement le reste. Ce point révèle une question de gouvernance ordinaire : quelle partie du message l’application prétend-elle avoir examinée? Accepter le premier document et oublier les suivants peut sembler commode; c’est pourtant un choix local non déclaré sur la portée de l’entrée.

Les avertissements de sécurité du RFC ne sont pas des slogans sur un langage prétendument dangereux. Ils décrivent les propriétés que le récepteur doit maîtriser. Des tags peuvent déclencher l’exécution de code arbitraire dans certaines implémentations; le RFC recommande de désactiver ce comportement par défaut. Un graphe de représentation peut être cyclique ou croître de façon exponentielle lors de sa construction; validation, limites de récursion et bornes de ressources deviennent alors des décisions de l’implémentation.

L’analyse incrémentale peut livrer un résultat partiel avant qu’une erreur ultérieure n’apparaisse; RFC 9512 demande de tester tous les documents du flux avant d’en traiter le résultat.

Ces détails détruisent l’illusion d’un cachet unique. Un type correct démontre qu’un expéditeur a déclaré un format. Il ne démontre pas que le récepteur a rejeté les mécanismes dont il ne veut pas, qu’il a consommé le flux entier, ou qu’une structure syntaxiquement admise satisfait aux règles qui comptent pour son activité.

La question des signatures pousse cette séparation jusqu’à la preuve. Le RFC avertit qu’un réencodage peut modifier espaces ou ancres d’une manière qui perturbe la validation d’une signature. Il note aussi qu’un passage de YAML à JSON peut perdre commentaires, directives et nœuds d’alias, et que certains traits YAML compliquent l’interopérabilité avec JSON. Un résultat qui « ressemble » au document initial n’est donc pas nécessairement le même objet pour une chaîne de preuve. Il faut conserver la distinction entre octets reçus, représentation interprétée, validation effectuée et action décidée.

La bonne chaîne de contrôle est courte mais non compressible. Le type est admis. Le profil de parseur est choisi. Le flux entier est validé dans les limites locales. Le schéma et la sémantique de la demande sont évalués. Une autorité distincte accepte ou refuse son effet. Enfin, l’état observé confirme ce qui s’est réellement passé. Chacune de ces étapes peut être automatisée; aucune ne se déduit automatiquement du nom YAML.

Cette discipline rejoint l’idée de Heng Lu d’une spécification initiale minimale suivie de décisions localisées. La norme commune doit établir le fait interopérable le plus étroit — ici, l’identité d’une sérialisation — et laisser visibles les choix qui engagent une machine, une équipe ou un client. Du code peut fonctionner parfaitement et pourtant ne pas justifier le récit qu’on en tire. Une analyse réussie est une observation de traitement, non une procuration sur ses effets.

Sources