Résumé

  • La RFC 2361 permettait de citer les codecs déjà inscrits dans les registres WAVE et AVI au moyen de audio/vnd.wave;codec=... et video/vnd.avi;codec=... ; l’IANA republiait les valeurs sans les attribuer.
  • Une valeur reconnue prouvait l’existence d’un identifiant, non la conformité des octets, la présence d’un décodeur, l’actualité du fournisseur ou la réussite de la lecture.

Un serveur annonce video/vnd.avi;codec=CVID. Le code de quatre lettres figure bien dans le registre. Le poste possède un composant présenté comme un décodeur Cinepak. Pourtant, l’image n’apparaît pas. Il n’y a là aucune contradiction : trois faits de nature différente ont été assemblés comme s’ils formaient un reçu unique.

Le paramètre peut être erroné. Le conteneur peut porter une autre piste. Le composant installé peut connaître une variante différente, refuser un en-tête endommagé, épuiser sa mémoire ou décoder des images que l’application ne présente jamais. La précision d’un nom ne garantit pas le résultat de l’opération qu’on lui associe.

La RFC 2361, publiée en juin 1998 avec un statut informatif, répondait à un besoin très concret. Les protocoles Internet commençaient à référencer, transporter et diffuser des volumes importants de contenus créés auparavant pour des environnements de bureau. WAVE et AVI disposaient déjà de bases d’identifiants maintenues par Microsoft. Pour exploiter ces archives, les applications Internet avaient besoin d’un langage commun permettant de nommer le codec déclaré.

La solution fut volontairement étroite. Le texte ne transférait pas les codecs dans un nouveau registre IETF. Il plaçait un pont vers les registres existants dans l’arbre fournisseur de MIME. Le sous-type vnd.wave ou vnd.avi indiquait le registre extérieur ; le paramètre obligatoire codec sélectionnait une entrée de ce registre.

Cette architecture reliait deux autorités sans les confondre. Microsoft avait attribué les numéros WAVE et les FourCC AVI. MIME fournissait la syntaxe utilisable dans un message ou un protocole Internet. La publication en RFC rendait publique la règle de traduction. La page actuelle de l’IANA résume encore la limite : l’IANA n’attribue pas ces valeurs, elle les republie.

Pour l’audio, la convention cachait un piège discret. Les identifiants WAVE étaient des numéros d’enregistrement hexadécimaux. Dans le paramètre, on reprenait leurs chiffres sans préfixe 0x. Le numéro 0x0055 de MP3 devenait donc audio/vnd.wave;codec=55. Il ne devenait pas le nombre décimal 55. Un logiciel qui reconvertirait cette chaîne comme une quantité décimale pourrait consulter une autre entrée tout en affichant une apparente exactitude numérique.

La vidéo utilisait une autre forme d’identité. Un identifiant AVI était un FourCC : quatre caractères ASCII, soit 32 bits, sensibles à la casse. CVID, cvid et une version normalisée n’étaient pas interchangeables parce qu’un écran les trouvait ressemblants. La casse et les octets appartenaient à l’identifiant lui-même.

Le document décrivait aussi une conversion vers des GUID. Le numéro WAVE était étendu dans le premier champ d’un gabarit fixe. Le FourCC occupait les mêmes 32 bits. Ainsi, H260 apparaissait sous la forme hexadécimale 30363248, l’ordre des octets d’un DWORD expliquant l’inversion visuelle. Ce calcul permettait à deux représentations logicielles de pointer vers la même identité.

Il n’ajoutait aucune autorité nouvelle. Un GUID calculé à partir d’un FourCC ne constituait pas une spécification autonome. Il n’attestait ni l’implémentation du flux binaire, ni l’origine du binaire du décodeur, ni le droit de l’exécuter sur un objet reçu du réseau. La RFC 4122 a ensuite normalisé les formats et le vocabulaire des UUID ; elle ne transforme pas une conversion déterministe en preuve fonctionnelle.

L’âge des registres rendait cette distinction essentielle. La RFC 2361 les qualifiait de bases historiques. Elles avaient été utiles pour éviter les collisions et publier les informations d’enregistrement. Mais les coordonnées d’une entreprise ou d’un contact n’étaient généralement mises à jour que si le déclarant signalait lui-même le changement. Les annexes formaient une référence autorisée pour les valeurs connues en janvier 1998, pas un annuaire commercial certifié pour l’avenir.

Un identifiant peut donc survivre à son gardien. C’est même l’un des avantages d’un registre : un fichier ancien reste reconnaissable après une acquisition ou la disparition d’un produit. L’inférence inverse est interdite. La présence durable d’une ligne ne prouve pas qu’un décodeur maintenu, une licence, un responsable sécurité ou un service d’assistance existe encore.

Le registre ne validait pas non plus les octets. Un paramètre de type MIME est une déclaration de l’émetteur. Le récepteur doit toujours examiner le conteneur, découvrir les pistes et comparer les identifiants réellement présents. Le champ peut être absent, faux ou hostile ; le fichier peut être tronqué, ambigu ou construit pour exploiter un parseur. Une consultation réussie prouve seulement que le jeton reçu a une signification dans l’édition consultée du registre.

La RFC 6381, écrite plus tard pour le paramètre pluriel codecs d’autres formats conteneurs, expose nettement une limite comparable : en cas de désaccord, le corps fait foi. Elle reconnaît aussi qu’une liste de codecs ne dit pas toujours si toutes les pistes sont indispensables à un rendu utile. Cette RFC ne remplace pas la syntaxe singulière de la RFC 2361 ; elle montre que la séparation entre déclaration et contenu inspecté demeure une question d’architecture.

La capacité du poste était encore un reçu distinct. Le nom pouvait aider à refuser tôt, choisir un transcodeur ou chercher un composant candidat. Il fallait néanmoins connaître la version réelle du décodeur, ses variantes prises en charge, son environnement d’isolation et ses limites de ressources. « Installé », « sélectionné », « initialisé », « décodé » et « présenté à l’utilisateur » sont cinq états différents.

Le transport ne fusionnait pas ces états. RTSP pouvait piloter une session et HTTP récupérer un objet. Un nom WAVE ou AVI aidait ces protocoles à parler d’un contenu traditionnel. Il ne constituait ni un format de charge RTP, ni un accord de session, ni un accusé de réception complet, ni une preuve de synchronisation audiovisuelle.

La section de sécurité de la RFC tenait en une mise en garde radicale : ce document enregistrait des formats et ne traitait pas leurs risques ; chaque format devait être étudié séparément. Une correspondance dans le registre ne pouvait donc pas autoriser l’installation automatique d’un codec ou l’exécution privilégiée d’un parseur natif.

La chaîne probante correcte conserve le type MIME reçu et ses octets exacts, la version du registre, la règle hexadécimale ou FourCC appliquée, le résultat de l’inspection du corps, le logiciel retenu, sa provenance, la décision d’isolation, la tentative de décodage, les pistes produites et le rendu observé. Chaque étape peut réussir alors que la suivante reste inconnue.

La réussite historique de la RFC 2361 n’était donc pas une compatibilité universelle. C’était une fédération limitée : Internet pouvait nommer un espace extérieur sans prétendre l’avoir créé, audité ou rendu exécutable.