Types, sous-types et paramètres

Chaque type peut comporter un certain nombre de sous-types (dont l'un au moins doit être spécifié). Par exemple, le type image est doté des deux sous-types gif (pour les images au format GIF) et jpeg (pour les images au format JPEG).

Chaque type et sous-type peut avoir des paramètres. Par exemple, un texte (type text) sans directive de formattage particulière (sous-type plain), doit être accompagné d'un paramètre indiquant le jeu de caractère employé. L'ensemble de ces informations est placé dans le nouveau champ Content-Type.

Les types, sous-types et paramètres définis dans la RFC 2046 ne sont pas limitatifs, d'autres peuvent être ajoutés par la suite^1.6.

Les types définis dans la RFC 2046 sont :

• text
  Le type text comprend plusieurs sous-types, suivant le degré de formattage du texte :
  • text/plain pour les textes non formattés. Il faut noter qu'un courrier à l'ancienne mode (RFC 2822) est implicitement compris comme text/plain ;

  • text/enriched pour les textes comportant des directives de formattage avec une syntaxe particulièrement simple, similaire à HTML. Par exemple, un courrier contenant  :

    mot en <bold>gras</bold> parmi d'autres

    sera affiché comme :

    mot en gras parmi d'autres

    La définition de ce sous-type est donnée dans la RFC 1563.

  Le seul paramètre de ce type est charset= pour spécifier le jeu de caractères utilisé. Parmi les jeux de caractères autorisés, il faut noter que le jeu us-ascii ne permet pas l'échange de caractères accentués (l'alphabet ASCII ne comprend que les 128 premiers caractères), et que seul le jeu iso-8859-1 permet l'échange de messages composés avec les caractères accentués utilisés en Français^1.7. Notons enfin que les jeux de caractères non normalisés comme le jeu PC 8 ne sont pas admis.

  D'autres sous-types ont été définis depuis, comme par exemple le sous-type text/HTML (voir RFC 2110).

• image
  Le type image comprend, comme indiqué plus haut, les deux sous-types image/gif et image/jpeg correspondant aux formats les plus courants de représentation des images.
  Il n'y a pas de paramètre.

• audio
  Le type audio ne comprend qu'un seul sous-type, audio/basic, qui correspond au format de représenation des sons 8 bits, 8$\thinspace$000 Hz, simple canal.
  Il n'y a pas de paramètre.

• video
  Le type video ne comprend qu'un seul sous-type, video/mpeg, correspondant au format de représentation de la vidéo.
  Il n'y a pas de paramètre.

• message
  Le type message sert à encapsuler d'autres courriers. Les trois sous-types définis sont :
  • rfc822 pour spécifier l'encapsulation d'un courrier à la syntaxe RFC 2822. C'est typiquement utilisé lorsqu'un routeur de courrier renvoie un message d'erreur : le routeur doit inclure le message original ;

  • partial lorsqu'un message MIME est découpé par un UA, un routeur de messages ou un agent de transport lorsque le message est trop gros. Le concept est analogue à la fragmentation des datagrammes IP sur le réseau. Le paramètre number= spécifie alors le numéro du fragment de courrier, le paramètre total= spécifie le nombre total de fragments et le le paramètre id= est un identificateur unique commun à tous les fragments du courrier ;

  • external-body pour spécifier une donnée qui se trouve ailleurs, c'est-à-dire hors du message. Dans ce cas, il faut indiquer comment faire pour obtenir la donnée : le paramètre access-type= indique la méthode (ftp, anon-ftp, tftp, afs, local-file, mail-server et URL). D'autres paramètres permettent de préciser cette méthode.

• application
  Le type application est utilisé pour transmettre des données compréhensibles par des applications annexes. Par exemple, on peut imaginer de transmettre des feuilles de calcul Excel, des documents Word, etc. À présent, deux sous-types sont définis :
  • octet-stream est le plus général : le message contient une suite d'octets qui est censée être une donnée pour une application externe ;

  • postscript correspond à un source exécutable par un interprète PostScript.

  Le problème de la sécurité se pose : les courriers sont en effet traités par des programmes. Si on n'y prend pas garde, un utilisateur malicieux peut envoyer un jeu de données malveillant. Il faut donc des contextes d'exécution sûrs, ce qui conduit naturellement au concept d'active mail.

• multipart
  Le dernier type est spécial : il spécifie qu'un message contient en réalité plusieurs sous-messages. Par exemple, un courrier peut contenir un texte, une image et un son. Le message a le type et le sous-type multipart/mixed. Un paramètre boundary= spécifie une chaîne de caractères dont le but est de séparer chaque sous-partie du message. Chaque sous-partie est composée d'une en-tête miniature spécifiant à nouveau un type et un sous-type MIME.

  Les différents sous-types sont :

  • multipart/mixed : les différents constituants sont indépendants et sont présentés par l'UA du destinataire dans l'ordre dans lequel ils sont placés dans le message ;

  • multipart/alternative : tous les constituants contiennent la même information, seule la présentation diffère. En fonction de ses capacités, l'UA du destinataire affiche le constituant le plus « joli ». L'exemple typique est un texte envoyé en text/plain classique, en text/enriched avec des indications de formattage, et en application/postscript. L'utilisateur choisit la version la plus lisible pour lui (texte normal s'il lit son courrier sur un Minitel, postscript s'il a un écran X11 avec un previewer PostScript, par exemple).

  • multipart/digest : comparable à multipart/mixed, à ceci-près que chaque constituant est lui-même un courrier électronique.

  • multipart/parallel : les différents constituants sont présentés simultanément à l'utilisateur. C'est typiquement le cas d'une image affichée en même temps que sa légende (un texte) et accompagnée d'un son.

  • multipart/related : les différents composants constituent un seul et même document, comme par exemple un texte HTML et des icones associées. Ce sous-type est apparu plus récemment (voir RFC 2112).

Une partie d'un message multipart peut également être du type multipart. On obtient ainsi des messages qui peuvent être relativement complexes. Par exemple, le schéma de la figure 1.1 spécifie que le message est constitué de trois parties, un texte, une alternative et un objet externe. L'alternative est soit une image et un son simultanés, soit une vidéo.

Figure 1.1: Exemple de structure de document MIME complexe

D'autres types peuvent être définis ultérieurement. Par exemple, la RFC 1892 définit deux nouveaux sous-types pour supporter les accusés de remise (voir 1.7.3, page ). Ce sont :

• multipart/report : format d'un accusé de remise. Le premier constituant est un message, destiné à l'utilisateur, détaillant la raison de l'émission de l'accusé. Le deuxième constituant reprend les mêmes informations, mais les présente de manière analysable par un programme (par exemple l'UA de l'utilisateur). Le troisième constituant, optionnel, contient le message original (en partie ou en totalité).

• text/rfc822-headers : format de la troisième partie de l'accusé de réception.