Résumé

  • Le RFC 1874 réservait text/sgml aux entités dont un humain pouvait saisir le sens général sans interpréteur SGML. Cette promesse concernait le repli, pas l'absence d'effets actifs.
  • charset, SGML-bctf et SGML-boot décrivaient trois opérations différentes : afficher approximativement, reconstruire les combinaisons de bits et retrouver une carte d'amorçage dans une autre partie MIME.
  • Le document avertissait qu'un système SGML pouvait exécuter des commandes. La séparation ultérieure de XML montra qu'une parenté syntaxique ne rendait ni les processeurs ni les rôles d'entités interchangeables.

Une ligne visible n'était que le chemin le moins exigeant

Le choix du mot « texte » avait une fonction très précise. Une machine ne connaissant pas SGML devait pouvoir présenter le corps comme du texte ordinaire et laisser le lecteur en tirer l'idée générale. Pour cela, le RFC 1874 imposait, dans text/sgml, qu'un enregistrement SGML corresponde à une ligne du corps MIME.

Cette règle ne transformait pas le balisage en prose pure. Elle protégeait un résultat minimum lorsque l'interprétation spécialisée manquait. Les références d'entités pouvaient rester opaques, les instructions de présentation ne pas être suivies et la structure logique ne pas apparaître. Le lecteur obtenait quelque chose de sensé sans obtenir nécessairement la représentation voulue.

Le type application/sgml accueillait les entités qui perdaient leur sens sans traitement SGML. Les deux branches partaient donc de la même grammaire mais distribuaient différemment le coût de l'ignorance. L'une autorisait un repli humain ; l'autre demandait une application capable.

Le RFC 2046 formula ensuite ce principe pour MIME : le type de premier niveau guide le comportement lorsqu'un sous-type est inconnu. Montrer les données brutes peut convenir au texte, pas forcément à une image ou à du son. Un sous-type textuel devait rester compréhensible sans logiciel spécialisé.

La catégorie contrôlait donc le repli. Elle ne signait pas un certificat de sécurité pour le chemin complet.

Le décodage avait plusieurs autorités

Le paramètre charset de text/sgml servait au client dépourvu de SGML. Il l'aidait à afficher les caractères selon la convention MIME. Un système SGML compétent devait cependant regarder SGML-bctf, le format de transformation des combinaisons de bits. Celui-ci expliquait comment les nombres de largeur constante du modèle SGML avaient été convertis en octets transportés.

Une valeur identity ne demandait aucune transformation ; d'autres valeurs décrivaient des largeurs fixes ou des encodages variables. Reconnaître text/sgml ne prouvait donc pas que l'implémentation connaissait le BCTF annoncé. Obtenir des caractères à l'écran ne prouvait pas qu'ils correspondaient aux nombres employés par la déclaration SGML.

Le paramètre SGML-boot ajoutait une dépendance. Sa valeur n'était pas la carte d'amorçage, mais le Content-ID d'une autre partie MIME de type application/octet-stream. Cette partie contenait des triplets d'entiers permettant de retrouver les numéros des caractères significatifs de la déclaration. Le mécanisme ne concernait que les entités documentaires.

Une référence bien écrite pouvait néanmoins pointer vers une partie absente, dupliquée ou altérée. Le destinataire devait conserver la structure multipart, résoudre le bon identifiant, lire les triplets puis seulement interpréter la déclaration. Le paramètre attestait une intention d'assemblage, non la possession de sa cible.

Le RFC 1590 organisait l'enregistrement public des types de média. Ce registre permettait de découvrir la définition d'un nom. Il n'observait pas chaque message et ne validait aucun analyseur en fonctionnement.

L'analyse changeait la nature du risque

La section de sécurité du RFC 1874 rompait l'illusion d'un texte inerte. Une entité SGML était destinée à être analysée et traitée. Certains systèmes pouvaient autoriser des commandes explicites au niveau du système ; des instructions de traitement destinées à la composition ou à la présentation soulevaient des problèmes comparables à PostScript.

Il existait alors deux actes séparés. Afficher les lignes en mode de repli exposait un contenu textuel. Envoyer les mêmes octets à un processeur SGML lui donnait potentiellement accès à des fonctions plus puissantes. Le premier succès n'autorisait pas le second.

Une implémentation MIME devait aussi ignorer les paramètres qu'elle ne connaissait pas. Cette discipline rendait l'enveloppe extensible. Mais ignorer SGML-boot pouvait produire un repli acceptable tout en empêchant une reconstruction fidèle. « Message accepté » ne disait pas quelle information avait été perdue.

Le journal utile devait donc séparer réception, interprétation de l'en-tête, transformation BCTF, résolution de la partie boot, analyse de la déclaration, décision de sécurité et résultat applicatif. La simple mention « ouvert » écrasait les preuves les plus importantes.

XML refusa d'hériter d'une compatibilité non démontrée

Lorsque XML apparut, sa relation avec SGML semblait offrir un raccourci : XML était un sous-ensemble de SGML, alors pourquoi ne pas réutiliser les types SGML ? Le RFC 2376 répondit par trois limites concrètes. De nombreux processeurs XML ne savaient pas traiter l'ensemble plus vaste de SGML. Des processeurs SGML ne comprenaient pas toujours les corrections récentes utilisées par XML. Enfin, XML n'employait ni SGML-bctf ni SGML-boot; les recevoir aurait été ambigu.

La taxonomie du langage ne constituait donc pas un inventaire des programmes déployés. Une relation de sous-ensemble ne promettait ni acceptation dans les deux sens ni identité de paramètres.

Le RFC 3023 poursuivit cette séparation et introduisit le suffixe +xml pour les formats applicatifs fondés sur XML. Le suffixe signalait une syntaxe commune sans effacer le sens du type complet.

Le RFC 6838 donna ensuite un registre et une procédure aux suffixes structurés. L'enregistrement devait documenter encodage, interopérabilité, fragments et sécurité. L'acte administratif rendait la convention inspectable ; il ne prouvait pas que tous les logiciels la suivaient.

Le RFC 7303 affina encore le contrat. Une application pouvait repérer +xml, vérifier l'hypothèse avec un processeur XML, puis appliquer les règles du type particulier. Lorsqu'un traitement XML générique était indésirable, les concepteurs pouvaient ne pas employer le suffixe. Le signal donnait la permission de vérifier, pas celle de tout exécuter.

Ce RFC distingua aussi document, sous-ensemble DTD externe, entité analysée externe et entité paramètre externe. La syntaxe partagée ne rendait pas ces objets substituables. Leur rôle faisait partie de la preuve.

Le reçu le plus court était le plus honnête

« Type enregistré » prouvait une publication. « En-tête reçu » prouvait un transport local. « Texte affiché » prouvait un repli. « BCTF appliqué » prouvait une transformation choisie. « Cible boot trouvée » prouvait une relation dans le paquet. « Arbre analysé » prouvait une réussite syntaxique. Aucun de ces reçus ne prouvait à lui seul une exécution autorisée ou un résultat utile.

Cette granularité explique la valeur historique de RFC 1874. Ses noms ont été dépassés par l'évolution de XML, mais la coupure demeure actuelle : la lisibilité humaine et le pouvoir d'un interpréteur ne sont pas la même propriété. Une étiquette peut diriger le logiciel vers une décision. Elle ne peut pas prendre cette décision à sa place.

Sources et limites

Les RFC 1590, 1874 et 2046 établissent le registre, les paramètres SGML et le comportement MIME. Les RFC 2376, 3023, 6838 et 7303 établissent la séparation XML et les suffixes structurés. Ils ne prouvent ni adoption universelle, ni conformité d'un produit nommé, ni analyse réussie, ni commande exécutée, ni attaque réelle, ni dommage.