Résumé

  • RFC 3023 a proposé le suffixe +xml afin que des types de médias distincts puissent signaler une même structure XML et profiter d’outils génériques.
  • Ce suffixe ne livrait ni la sémantique du vocabulaire ni une autorisation d’agir : type exact, validation, politique de sécurité et effet observé demeuraient des preuves séparées.

Au début de 2001, XML n’était déjà plus un seul « type de document ». Des protocoles commerciaux, des formats graphiques et des langages de configuration pouvaient partager la même grammaire tout en exigeant des logiciels incompatibles. Les appeler tous application/xml aurait masqué leur contrat applicatif. Leur donner des noms totalement opaques aurait caché une information utile : un éditeur, un moteur de recherche ou un parseur XML pouvait encore effectuer un traitement commun.

RFC 3023 a choisi une articulation minuscule. Le nom précis restait intact et se terminait par +xml. La partie gauche identifiait le format ; la terminaison rendait visible son substrat.

Un nom, deux profondeurs de connaissance

Pour une application connaissant application/foo+xml, le type complet commandait le traitement spécialisé. Pour un outil ignorant foo mais connaissant XML, les quatre derniers caractères autorisaient une question plus modeste : ce contenu peut-il passer par un traitement XML générique ?

Cette possibilité évitait une liste sans fin de vocabulaires. Le RFC expliquait aussi pourquoi un paramètre MIME convenait mal : les paramètres modifiaient un sous-type sans définir sa nature profonde, et les répartiteurs existants les utilisaient rarement pour choisir une application. Un nouveau type de premier niveau aurait déplacé beaucoup plus d’architecture que nécessaire. Le suffixe ne transportait que le fait commun.

Il ne fusionnait pourtant rien. Pour un processeur ignorant XML, +xml restait opaque. L’annexe de RFC 3023 insistait donc sur l’absence de sémantique supplémentaire attachée à sa seule présence. application/foo et application/foo+xml constituaient deux types indépendants. La variante XML pouvait changer à la fois syntaxe et sens ; prendre en charge l’une ne prouvait pas la prise en charge de l’autre.

Un arbre syntaxique n’était pas une décision

La réception d’un suffixe fournit d’abord une déclaration du producteur. Un parseur peut ensuite vérifier que les octets forment réellement un document XML selon les règles d’encodage applicables. Cette réussite ne dit toujours pas si l’espace de noms est attendu, si le profil est valide, si une signature est fiable ou si l’auteur est habilité.

Un élément nommé delete ne supprime rien par la force de sa balise. Le vocabulaire doit lui donner un sens ; une politique doit accepter ce vocabulaire ; une autorisation doit couvrir l’opération ; enfin le système doit enregistrer l’effet. De même, le traitement générique n’ordonne pas de résoudre des entités externes, de télécharger des ressources, d’exécuter une transformation ou d’allouer sans limite. Ces capacités appartiennent au contrôle local.

Le suffixe rend donc possible une réutilisation disciplinée. Il ne délègue pas la confiance.

La convention est devenue une pièce de registre

RFC 6838 a ensuite intégré les suffixes de syntaxe structurée à l’architecture d’enregistrement des types de médias : ce qui suit le dernier signe plus identifie une syntaxe commune enregistrée. RFC 6839 a formalisé +xml et décrit le partage des tâches. Le type exact fournit le traitement sémantique précis ; le suffixe permet un traitement générique lorsque cette sémantique particulière n’est pas nécessaire et qu’aucune connaissance supplémentaire n’est requise pour lire la représentation.

RFC 7303 a remplacé RFC 3023 sans abandonner ce partage. Il recommande toujours +xml pour les nouveaux formats XML, sauf si un traitement XML générique serait inadapté. Le récepteur peut reconnaître le suffixe, appeler un parseur pour vérifier l’hypothèse, puis choisir une suite. Les règles propres au format — affichage, édition, sécurité, exécution ou fragments — restent attachées au type complet.

Le registre IANA actuel montre les deux niveaux. Une entrée décrit le suffixe structuré +xml; de nombreux types distincts le portent. Leur fin commune est une preuve de famille syntaxique, jamais une preuve d’interchangeabilité.

Sources

Lu Heng n’a ni rédigé ni approuvé RFC 3023. Ses essais servent ici de grilles d’analyse déclarées.