Résumé

  • La révision 10 de draft-ietf-mediaman-6838bis est devenue disponible le 9 septembre 2026 UTC. Elle reste une draft du groupe Media Type Maintenance, et non un RFC ou une opération IANA achevée.
  • Le texte abandonne une priorité dépendant du succès de l’exécution. Il impose désormais la cohérence avec les règles de fragment effectivement définies par un suffixe ; à défaut, le type de média décide.
  • Treize fiches IANA sont nommées. Chacune contient trois cas de traitement tout en déclarant qu’aucune syntaxe de fragment n’est définie pour le suffixe, de sorte que ces cas ne peuvent pas se produire.
  • Je propose un manifeste de correction en éventail, reliant la future autorité publiée aux treize états avant et après modification. Cette idée relève de mon analyse éditoriale ; elle ne figure pas parmi les exigences actuelles.

Le registre conserve deux affirmations incompatibles

Le point de départ n’est pas un incident logiciel. C’est une contradiction documentaire. Dans la version 09, la règle demandait d’essayer d’abord le traitement défini par le suffixe : s’il résolvait le fragment, il prévalait ; sinon, le type de média précis reprenait la main. La question 93 du groupe a relevé que le choix de la règle dépendait alors du résultat obtenu après avoir commencé à l’appliquer.

La révision 10 change la nature du test. Si l’enregistrement du suffixe définit une syntaxe et une sémantique de fragment, le type qui emploie ce suffixe doit rester compatible et ne peut interdire une syntaxe exigée. Si le suffixe ne définit rien, le type de média fixe le traitement. Le diff officiel montre bien le remplacement d’une priorité dynamique par une contrainte déclarative.

Vient ensuite la portée réelle de la réparation. Le texte cite +json, +ber, +cbor, +der, +fastinfoset, +wbxml, +zip, +tlv, +json-seq, +sqlite3, +jwt, +gzip et +cbor-seq. Le modèle en trois cas remonte à RFC 6839 et s’est propagé entre enregistrements. Pourtant, chaque fiche concernée indique aussi que le suffixe ne dispose pas d’une syntaxe de fragment. La branche supposée réussir selon ces règles n’a donc aucune règle sur laquelle réussir.

Une future norme n’efface pas elle-même treize champs

Le registre IANA des suffixes structurés indiquait une dernière mise à jour au 25 juin 2026 lors de la vérification. Il comptait 24 fiches, relevait d’Expert Review et nommait deux experts. Les treize fiches visées contenaient toujours à la fois les trois cas et la déclaration d’absence de syntaxe. C’est l’état antérieur normal : la draft demande à IANA une action future, elle ne l’a pas encore autorisée par sa seule publication comme document de travail.

La répartition des pouvoirs doit rester lisible. Le groupe Media Type Maintenance prépare le successeur de RFC 6838. IANA tient les fiches. Les experts désignés interviennent selon la politique du registre, dans le cadre général de RFC 8126. L’IESG gère les experts des registres créés par l’IETF et peut être sollicitée si nécessaire. Aucun de ces rôles ne peut servir de raccourci probatoire pour les autres.

La prudence vaut aussi pour le statut. L’en-tête de la draft annonce une Best Current Practice, tandis que la fiche Datatracker affiche actuellement aucun statut RFC prévu. Le groupe est indiqué In WG Last Call depuis la révision 06 d’octobre 2025. Ces éléments décrivent un travail en cours ; ils ne valent ni approbation de l’IESG, ni publication, ni mise à jour du registre.

Ce que le suffixe permet réellement d’inférer

Un suffixe structuré donne à un processeur une indication sur un format sous-jacent. Il ne transforme pas tous les types terminés par +json ou +zip en objets aux mêmes sémantiques. La révision 10 insiste sur ce point : on ne peut pas déduire de la seule chaîne de caractères la relation entre un type suffixé et le type obtenu en retirant le suffixe. Les fragments et les propriétés de sécurité peuvent dépendre du type précis.

La suppression demandée enlèverait donc une instruction sans objet. Elle ne créerait aucune syntaxe de fragment, ne modifierait aucun logiciel, ne prouverait aucune interopérabilité et ne documenterait aucune faille. RFC 3986 fournit le modèle général des fragments d’URI, non le comportement de chaque format.

Le même document intégrerait aussi RFC 9694 et remplacerait RFC 6838 et RFC 9694 s’il était approuvé. Ces changements plus larges ne doivent pas être confondus avec l’état actuel des treize fiches.

Un manifeste très court, mais treize preuves

Je séparerais l’autorisation commune de son déploiement. Un manifeste public pourrait conserver l’identité et l’empreinte du texte finalement publié ; la liste fermée des suffixes ; l’identité et l’empreinte antérieure de chaque fiche ; la classe exacte de paragraphes à retirer ; l’empreinte du contenu à préserver ; l’acte IANA et son heure ; l’avis de l’expert et de l’IESG seulement lorsqu’ils sont utilisés ; puis l’empreinte finale et un lien de rectification.

Ce document ne deviendrait pas un nouveau niveau d’approbation. Il n’exposerait pas les échanges confidentiels et ne dirait pas aux applications comment interpréter leurs fragments. Il prouverait seulement qu’une décision publiée a atteint ses treize cibles sans emporter d’autres informations.

Cette économie rejoint la logique de spécification minimale décrite par Heng Lu : normaliser la trace commune utile à la coordination, sans centraliser les choix qui appartiennent aux types de médias.

Limite de la preuve

La fiche Datatracker et son historique établissent la révision et son état. La pull request 108 et le commit de fusion établissent le chemin de rédaction. Ils ne permettent pas d’annoncer la future décision.

Sources