T. Hansen (AT&T Laboratories)A. Melnikov (Isode)January20132013-01-30
Tout le monde connait les « types de contenu » (media
types, aussi appelés types MIME pour
des raisons historiques), comme application/pdf
ou text/plain. On sait qu'ils ont un
type (comme application ou
text, dans les exemples ci-dessus) et un
sous-type (pdf ou
plain ci-dessus) qui précise le format, à
l'intérieur de la catégorie définie par le type. On sait moins que le
sous-type peut avoir une structure : on peut voir un format générique
et un format plus spécifique, séparés par un +,
comme dans application/xhtml+xml ou
image/svg+xml. Cette structuration, introduite à
l'origine par le , pour XML,
est ici généralisée à d'autres formats et normalisée en détail. (Pour +xml, une
mise à jour a été faite ensuite dans le .)
Cette technique vient du fait que certains formats ont deux
couches : un format décrivant la syntaxe de base et plusieurs formats
(plutôt appelés vocabulaires, ou même langages, dans le monde XML) qui
définissent des règles sémantiques différentes, mais tous utilisant la
même syntaxe de base. L'exemple typique est
XML. Ainsi, les fichiers
TEI () sont en
XML et un processeur XML généraliste saura en faire quelque chose (par
exemple vérifier leur validité syntaxique). Mais TEI n'est pas que
XML : c'est aussi la définition d'un certain nombre d'éléments XML
légaux et de leurs relations (le schéma). Un
fichier TEI peut donc être étiqueté
application/xml mais son type de contenu
officiel, application/tei+xml, donne davantage
d'informations (cf. section 2, sur l'intérêt de ces suffixes). Si on
prend un autre vocabulaire XML, le Atom du , c'est aussi du XML mais les éléments
acceptés sont complètement différents. Son type de contenu aura donc
aussi le suffixe +xml mais le type sera distinct,
ce sera application/atom+xml.
La section 3 liste les sous-types à
suffixe possibles (mais cette liste va grandir par la suite,
cf. , section 6). Pour chaque suffixe, sont notamment indiquées les
règles relatives à son encodage (pour savoir si
la ressource doit être transportéee comme du texte ou comme du binaire), et les règles
de sécurité. Parmi les suffixes possibles, il y a, entre autres :
+json pour le format
JSON du . comme
vnd.oftn.l10n+json (format de la bibliothèque
Javascript l10n) ou comme les réponses de l'API de GitHub. Comme XML, JSON peut être encodé en
UTF-8 (il est alors considéré comme texte,
cf. ) ou
UTF-32 (il est alors vu comme du binaire).+ber pour le format
BER et +der pour le format
DER, tous les deux d'encodage
d'ASN.1 (norme UIT
ITU.X690.2008). Un exemple est dssc+der, du
format du (qui peut aussi se représenter en XML). À noter que BER
présente des risques particuliers en terme de sécurité. Encodage
TLV, il permet de construire des fichiers avec
des longueurs invalides, permettant de dépasser les limites des
données et de déclencher un débordement de
tampon chez des décodeurs naïfs. On peut aussi faire des
dépassements de pile puisque BER permet
d'emboîter des données récursivement.+fastinfoset est la norme Fast Infoset, un encodage binaire de XML, qui ne semble pas
avoir été un grand succès (bien que résolvant un reproche parfois fait
à XML, celui que son encodage par défaut est trop bavard).+zip est le fameux format de compression et
d'archivage ZIP. (Aucun n'a apparemment encore
été enregistré.)
La section 4 reprend le suffixe +xml, déjà
décrit dans le et l'adapte aux exigences du .
Le registre IANA de ces suffixes est désormais
en ligne.