Summary

  • La RFC 2376 a enregistré text/xml et application/xml, mais l’absence de charset produisait deux régimes : US-ASCII pour le premier, même contre un BOM ou une déclaration XML, et détection par le processeur XML pour le second.
  • Ce conflit séparait l’inscription du type, l’en-tête reçu, les octets, la règle du décodeur et le sens applicatif. La RFC 7303 a ensuite aligné les deux types et supprimé l’ancien défaut silencieux.

Un document qui voyage avec deux étiquettes

XML promettait une structure indépendante de la machine et du logiciel. Sa déclaration interne pouvait nommer l’encodage, tandis qu’un indicateur d’ordre des octets permettait de reconnaître certaines sérialisations avant même de lire le contenu.

Sur le réseau, cette autonomie n’était pourtant jamais complète. HTTP, le courrier et WebDAV plaçaient l’entité dans une enveloppe de style MIME. Le champ Content-Type pouvait lui aussi comporter un charset. À l’arrivée, le processeur disposait donc de plusieurs sources susceptibles de répondre à la même question : comment transformer les octets en caractères ?

Publiée en juillet 1998 comme document Informational, la RFC 2376 a créé text/xml et application/xml. Elle refusait de rabattre XML sur les types SGML, car les processeurs et paramètres n’étaient pas interchangeables. L’objectif initial était raisonnable : donner un nom commun aux échanges XML.

Le choix d’affichage a fixé la hiérarchie

Toute entité XML convenait à application/xml. Un agent ignorant XML pouvait la traiter comme un objet opaque. text/xml indiquait au contraire qu’un affichage en texte brut constituait un comportement acceptable.

Cette commodité héritait des règles du type principal text. Lorsque le paramètre charset était présent, la RFC 2376 lui donnait autorité pour les deux types. Une déclaration interne n’était donc pas nécessairement la source décisive.

Lorsque le paramètre manquait, la bifurcation devenait spectaculaire. Sous application/xml, l’enveloppe ne livrait aucune information d’encodage. Un processeur XML pouvait observer le BOM, la forme des premiers octets et la déclaration interne. Un agent MIME qui ne connaissait pas XML ne devait rien supposer.

Sous text/xml, l’absence activait US-ASCII. Cette règle valait également sur HTTP et même si le corps était en UTF-8 ou UTF-16 avec une déclaration explicite. Le vide extérieur n’était pas neutre : il déclenchait une décision héritée.

Un exemple construit pour échouer

La RFC exposait le problème sans détour : un corps portant un BOM UTF-16 et encoding="utf-16", envoyé avec le seul type text/xml, devait néanmoins être traité comme US-ASCII. Croire le document revenait à désobéir au contrat de transport.

Les mêmes indices sous application/xml retrouvaient leur valeur. Sans charset, le BOM pouvait gouverner ; sans BOM, le processeur pouvait utiliser la signature initiale puis la déclaration. Un seul mot du type MIME modifiait la preuve recevable.

Cette différence survivait au-delà du parseur. Un intermédiaire pouvait transcoder le corps et mettre à jour l’en-tête sans toucher la déclaration. Un système d’archivage pouvait supprimer l’enveloppe et conserver des octets dont le sens dépendait d’elle. En séparant l’objet de son contexte, on pouvait perdre l’autorité qui l’avait rendu lisible.

L’auto-description ne tranche pas son propre rang

XML 1.0 savait qu’une déclaration interne ne résout pas seule un conflit avec le transport. La spécification renvoyait la priorité au protocole supérieur. C’était cohérent : un intermédiaire observe des transformations que le document ne peut pas connaître.

Mais cette délégation produisait une question institutionnelle. Quelle couche peut en dominer une autre ? L’absence d’une valeur est-elle une ignorance ou une instruction implicite ? La RFC 2376 a répondu en important une convention MIME historique.

La RFC 3023 l’a remplacée en 2001 sans supprimer le défaut US-ASCII de text/xml. Elle a mieux expliqué l’intérêt d’un charset externe, notamment face aux transcodeurs. La pratique réelle et les règles des types textuels ont toutefois continué d’évoluer.

La réparation a rendu la décision explicite

La RFC 6657 a imposé aux nouveaux types textuels de préciser leur comportement de charset plutôt que d’hériter d’une hypothèse générale. Puis la RFC 7303, en 2014, a aligné text/xml sur application/xml. Le choix entre text et application ne devait plus, à lui seul, changer l’encodage.

Le nouveau texte ordonnait jusqu’à trois indices : le BOM d’abord ; en son absence, le charset MIME explicite ; puis les règles XML si aucun des deux n’existait. Il recommandait encore application/xml afin d’éviter la confusion historique.

La convention +xml complétait ce dispositif. Un type spécialisé peut annoncer sa syntaxe XML aux outils génériques sans réduire son contenu à « du XML ». Reconnaître les chevrons et construire un arbre ne suffit pas à comprendre un vocabulaire métier ni à autoriser une action.

Le registre ne raconte pas l’exécution

Le registre IANA actuel relie application/xml et les types associés à la RFC 7303. Il prouve une coordination de noms. Il ne prouve ni l’en-tête effectivement reçu, ni l’intégrité des octets, ni le choix du décodeur, ni la validité du sens applicatif.

La lecture par couches de Lu Heng interdit ces raccourcis : type enregistré, en-tête capturé, octets, BOM, déclaration, résultat du décodeur, arbre et décision métier sont des reçus différents. La primauté du code en fonctionnement demande d’observer l’objet réel et le logiciel réel. La spécification initiale minimale rappelle enfin que la RFC 2376 a fourni une ouverture utile ; la correction ultérieure a retiré une autorité cachée, non la coordination elle-même.