Résumé

  • Le RFC 9694 exige un Standards Action : frontière d’appartenance claire, sécurité commune aux futurs sous-types et au moins un sous-type réel.
  • Le nom avant la barre oblique peut guider le dispatch type/*, l’icône et l’application par défaut ; ajouter une ligne au registre crée donc du travail pour tout l’écosystème.
  • Définition, état IANA, enregistrement du sous-type, émission, conservation, parsing, fallback, validation, autorisation locale et résultat sont dix preuves différentes.

Une icône correcte ne prouve que la règle d’affichage

Un gestionnaire de fichiers ignore haptics/hjif, mais connaît haptics/*. Il peut afficher une icône tactile ou proposer une application générale. Le sous-type exact n’est pas encore compris, le contenu n’est pas validé et aucun appareil n’a reçu l’autorisation de produire un effet physique. Pourtant, le premier niveau a déjà orienté le dispatch et l’attente de l’utilisateur.

C’est pourquoi le RFC 9694, publié en mars 2025 comme BCP 13, traite tout nouveau nom à gauche de la barre oblique comme une exception. Il met à jour le RFC 6838. La plupart des nouveaux formats doivent rester sous un type existant ; application accueille les données discrètes sans famille plus précise. Créer une famille ne relève donc pas d’un simple rangement : producteurs, intermédiaires, systèmes, bibliothèques et agents utilisateurs devront interpréter une nouvelle frontière.

Le texte impose un RFC Standards Track, une demande explicite à IANA, des critères disant ce qui appartient ou non à la famille, l’analyse des risques communs à tout ou partie importante des sous-types, et au moins un sous-type. Une catégorie vide n’a pas de fonction opérationnelle.

Le registre IANA des types de premier niveau applique Standards Action. Il conserve les familles MIME historiques du RFC 2046, puis model, example, font et haptics. Il prouve qu’un nom et son RFC existent. Il ne prouve ni l’émission par un producteur donné, ni la conservation par un proxy, ni la prise en charge sûre par un client.

La frontière doit être testable

Une catégorie supérieure n’a de valeur que si elle prédit quelque chose de durable entre plusieurs sous-types. Des critères précis permettent aux experts d’évaluer une nouvelle inscription. Une frontière impossible à expliquer indique plutôt que le sujet ne mérite pas un premier niveau.

Le RFC refuse aussi les raccourcis : pas de miroir d’un autre registre, de correspondance inverse d’extensions ou de schémas URI, de copie d’un système de types de programmation ou d’ontologie, ni d’aliases pour des formats déjà installés. Le préfixe X- ne transforme pas une convention locale en catégorie enregistrable. Ces limites empêchent l’espace partagé de devenir le dictionnaire privé d’un produit.

Un usage non enregistré mais répandu peut signaler un besoin ; il ne remplace pas la procédure. À l’inverse, une définition abstraite sans pression de sous-types ne démontre aucune demande. Le RFC recommande donc d’apporter de vrais sous-types initiaux, afin que la frontière soit éprouvée.

Le cas haptics, développé en parallèle, rend la distinction concrète. Le RFC 9695 définit la famille ; le registre IANA des médias contient haptics/ivs, haptics/hjif et haptics/hmpg. Voilà une preuve de normalisation et d’enregistrement, pas un recensement des navigateurs, clients mail, passerelles ou appareils qui savent les utiliser. La référence ultérieure de RFC 9993 à haptics/hmpg ne vaut pas déploiement universel.

Le dispatch générique agrandit aussi l’erreur

La fonction principale des types de média est de diriger des formats vers du code. Le plus souvent, type complet, sous-type et paramètres choisissent le handler. Le premier niveau peut servir de fallback provisoire vers une application couvrant une famille, comme pour l’image, l’audio et la vidéo. Les générateurs HTML et les bureaux peuvent également choisir élément ou icône à partir de ce nom.

Mais lancer une application ne prouve pas le support du sous-type. Une icône ne prouve ni le respect des paramètres, ni la correspondance des octets, ni l’isolement d’un contenu actif, ni le consentement à l’action suivante. Le RFC avertit que la déclaration peut être contrôlée par un attaquant.

Une chaîne sûre conserve le type complet, vérifie l’enregistrement du sous-type, applique les contraintes du protocole et la validation des octets, décide si le fallback est admissible, place rendu ou exécution derrière une politique locale, puis mesure le résultat. Le sniffing peut révéler une incohérence ; remplacer silencieusement une déclaration par une conjecture crée cependant une autre ambiguïté d’autorité.

Le déploiement demande donc dix reçus : RFC Standards Track, entrée IANA supérieure, sous-type, émission, conservation intermédiaire, reconnaissance exacte, fallback, validation, autorisation locale et résultat observé. Une étape peut réussir tandis que la suivante échoue. Les coûts se dispersent de la même façon : migration chez le producteur, normalisation par les intermédiaires, maintenance de handlers côté client, nouvelle surface de classification pour la sécurité, tickets où l’icône semble juste mais le contenu échoue.

Le RFC 8126 décrit le Standards Action. Le Datatracker IETF et la fiche RFC Editor établissent statut et historique, pas l’adoption. Celle-ci exige configurations, traces, essais d’intermédiaires, inventaires de handlers, résultats de validation et comportement constaté.

Le texte de Lu Heng sur la spécification initiale minimale n’est ici qu’une grille éditoriale déclarée : mutualiser le minimum requis pour l’interopérabilité et laisser les décisions ultérieures près des opérateurs. Ce n’est ni une exigence IETF ni une preuve de déploiement.

Sources