1. Introduction

Depuis sa publication en 1982, la RFC 822 a défini le format standard des messages de courrier textuels sur Internet. Son succès a été tel que le format RFC 822 a été adopté, en totalité ou en partie, bien au-delà des limites d'Internet et du transport SMTP Internet défini par la RFC 821. Au fur et à mesure que ce format a été largement adopté, un certain nombre de limitations se sont révélées de plus en plus restrictives pour la communauté des utilisateurs.

La RFC 822 était destinée à spécifier un format pour les messages textuels. En tant que tel, les messages non textuels, tels que les messages multimédias pouvant inclure de l'audio ou des images, ne sont tout simplement pas mentionnés. Même dans le cas du texte, cependant, la RFC 822 est inadéquate pour les besoins des utilisateurs de courrier dont les langues nécessitent l'utilisation de jeux de caractères plus riches que l'US-ASCII. Étant donné que la RFC 822 ne spécifie pas de mécanismes pour le courrier contenant de l'audio, de la vidéo, du texte en langue asiatique, ou même du texte dans la plupart des langues européennes, des spécifications supplémentaires sont nécessaires.

L'une des limitations notables du système de messagerie de base RFC 821/822 est qu'il limite le contenu des messages de courrier électronique à des lignes relativement courtes (par exemple, 1000 caractères ou moins [RFC-821]) d'US-ASCII 7 bits. Cela oblige les utilisateurs à convertir toutes les données non textuelles qu'ils souhaitent envoyer en octets de sept bits représentables sous forme de caractères US-ASCII imprimables avant d'invoquer un UA de messagerie local (User Agent, un programme avec lequel les utilisateurs humains envoient et reçoivent du courrier). Les exemples de tels encodages actuellement utilisés sur Internet incluent l'hexadécimal pur, uuencode, le schéma base 64 3-en-4 spécifié dans la RFC 1421, l'Andrew Toolkit Representation [ATK], et bien d'autres.

Les limitations du format de courrier RFC 822 deviennent encore plus apparentes lorsque des passerelles sont conçues pour permettre l'échange de messages de courrier entre les hôtes RFC 822 et les hôtes X.400. X.400 [X400] spécifie des mécanismes pour l'inclusion de matériel non textuel dans les messages de courrier électronique. Les normes actuelles pour mapper les messages X.400 aux messages RFC 822 spécifient que le matériel non textuel X.400 doit (must) être converti (et non encodé) au format IA5Text, ou être supprimé, en notifiant l'utilisateur RFC 822 que la suppression s'est produite. Ceci est clairement indésirable, car les informations qu'un utilisateur peut souhaiter recevoir sont perdues. Même si un agent utilisateur n'a pas la capacité de traiter le matériel non textuel, l'utilisateur peut avoir un mécanisme externe à l'UA qui peut extraire des informations utiles du matériel. De plus, cela ne tient pas compte du fait que le message peut éventuellement être réacheminé vers un système de traitement de messages X.400 (c'est-à-dire que le message X.400 est « tunnelisé » à travers le courrier Internet), où l'information non textuelle redeviendrait certainement utile.

Ce document décrit plusieurs mécanismes qui se combinent pour résoudre la plupart de ces problèmes sans introduire d'incompatibilités graves avec le monde existant du courrier RFC 822. En particulier, il décrit :

Un champ d'en-tête MIME-Version, qui utilise un numéro de version pour déclarer qu'un message est conforme à MIME et permet aux agents de traitement de courrier de distinguer ces messages de ceux générés par un logiciel plus ancien ou non conforme, qui est présumé manquer d'un tel champ.
Un champ d'en-tête Content-Type, généralisé à partir de la RFC 1049, qui peut être utilisé pour spécifier le type de média et le sous-type de données dans le corps d'un message, et pour spécifier entièrement la représentation native (forme canonique) de telles données.
Un champ d'en-tête Content-Transfer-Encoding, qui peut être utilisé pour spécifier à la fois la transformation d'encodage qui a été appliquée au corps et le domaine du résultat. Les transformations d'encodage autres que la transformation d'identité sont généralement appliquées aux données afin de leur permettre de passer par des mécanismes de transport de courrier qui peuvent avoir des limitations de données ou de jeu de caractères.
Deux champs d'en-tête supplémentaires, Content-ID et Content-Description, qui peuvent être utilisés pour décrire davantage les données dans un corps.

Tous les champs d'en-tête définis dans ce document sont soumis aux règles syntaxiques générales pour les champs d'en-tête spécifiées dans la RFC 822. En particulier, tous ces champs d'en-tête, à l'exception de Content-Disposition, peuvent inclure des commentaires RFC 822, qui n'ont pas de contenu sémantique et devraient (should) être ignorés pendant le traitement MIME.

Enfin, pour spécifier et promouvoir l'interopérabilité, la RFC 2049 fournit une déclaration d'applicabilité de base pour un sous-ensemble des mécanismes ci-dessus qui définit un niveau « conforme » minimal pour le document actuel.

NOTE HISTORIQUE : Plusieurs des mécanismes décrits dans cet ensemble de documents peuvent sembler quelque peu étranges ou même baroques à la première lecture. Il est important de noter que la compatibilité avec les normes existantes ET la robustesse à travers la pratique existante étaient deux des priorités les plus élevées du groupe de travail qui a développé cet ensemble de documents. En particulier, la compatibilité a toujours été préférée à l'élégance.

Veuillez vous référer à l'édition actuelle des « Internet Official Protocol Standards » pour l'état de normalisation et le statut de ce protocole. La RFC 822 et le STD 3, la RFC 1123 fournissent également un contexte important pour MIME car aucune implémentation MIME conforme ne peut les violer. De plus, plusieurs autres documents RFC informatifs sont également précieux pour les implémenteurs MIME, en particulier la RFC 1344, la RFC 1345 et la RFC 1524.

Terminologie :

User Agent (UA) (Agent Utilisateur) : Un programme avec lequel les utilisateurs humains envoient et reçoivent du courrier
MIME : Multipurpose Internet Mail Extensions (Extensions de Messagerie Internet Polyvalentes)
forme canonique : La représentation native des données
type de média : Le type général de données
sous-type : Un format spécifique dans un type de média
transformation d'encodage : Une conversion appliquée aux données pour la transmission

Concepts Clés :

Limitations de la RFC 822 : Prend en charge uniquement le texte US-ASCII 7 bits
Objectifs de MIME : Prendre en charge le multimédia, plusieurs jeux de caractères, le contenu non textuel
Compatibilité d'abord : La conception MIME maintient la compatibilité ascendante avec la RFC 822