4. Champ d'En-tête MIME-Version (MIME-Version Header Field)
Depuis la publication de la RFC 822 en 1982, il n'y a vraiment eu qu'une seule norme de format pour les messages Internet, et il y a eu peu de besoin perçu de déclarer la norme de format en cours d'utilisation. Ce document est une spécification indépendante qui complète la RFC 822. Bien que les extensions dans ce document aient été définies d'une manière compatible avec la RFC 822, il existe encore des circonstances dans lesquelles il pourrait être souhaitable pour un agent de traitement de courrier de savoir si un message a été composé avec la nouvelle norme à l'esprit.
Par conséquent, ce document définit un nouveau champ d'en-tête, « MIME-Version », qui doit être utilisé pour déclarer la version de la norme de format du corps de message Internet en cours d'utilisation.
Les messages composés conformément à ce document doivent (MUST) inclure un tel champ d'en-tête, avec le texte verbatim suivant :
MIME-Version: 1.0
La présence de ce champ d'en-tête est une assertion que le message a été composé en conformité avec ce document.
Étant donné qu'il est possible qu'un futur document puisse étendre à nouveau la norme de format de message, un BNF formel est donné pour le contenu du champ MIME-Version :
version := "MIME-Version" ":" 1*DIGIT "." 1*DIGIT
Ainsi, les futurs spécificateurs de format, qui pourraient remplacer ou étendre « 1.0 », sont contraints à être deux champs entiers, séparés par un point. Si un message est reçu avec une valeur MIME-Version autre que « 1.0 », on ne peut pas supposer qu'il est conforme à ce document.
Notez que le champ d'en-tête MIME-Version est requis (required) au niveau supérieur d'un message. Il n'est pas requis pour chaque partie de corps d'une entité multipartite. Il est requis pour les en-têtes intégrés d'un corps de type "message/rfc822" ou "message/partial" si et seulement si le message intégré est lui-même revendiqué comme conforme à MIME.
Il n'est pas possible de spécifier complètement comment un lecteur de courrier conforme à MIME tel que défini dans ce document devrait traiter un message qui pourrait arriver à l'avenir avec une valeur de MIME-Version autre que « 1.0 ».
Il convient également de noter que le contrôle de version pour des types de médias spécifiques n'est pas accompli en utilisant le mécanisme MIME-Version. En particulier, certains formats (tels que application/postscript) ont des conventions de numérotation de version qui sont internes au format de média. Lorsque de telles conventions existent, MIME ne les remplace pas. Lorsqu'elles n'existent pas, un type de média MIME peut utiliser un paramètre « version » dans le champ Content-Type si nécessaire.
Note de l'Implémenteur (Implementor's Note)
Lors de la vérification des valeurs MIME-Version, toutes les chaînes de commentaires RFC 822 présentes doivent (MUST) être ignorées. En particulier, les quatre champs MIME-Version suivants sont équivalents :
MIME-Version: 1.0
MIME-Version: 1.0 (produced by MetaSend Vx.x)
MIME-Version: (produced by MetaSend Vx.x) 1.0
MIME-Version: 1.(produced by MetaSend Vx.x)0
En l'absence d'un champ MIME-Version, un agent utilisateur de courrier récepteur (qu'il soit conforme aux exigences MIME ou non) peut éventuellement choisir d'interpréter le corps du message selon des conventions locales. De nombreuses conventions de ce type sont actuellement utilisées et il convient de noter qu'en pratique, les messages non-MIME peuvent contenir à peu près n'importe quoi.
Il est impossible d'être certain qu'un message de courrier non-MIME est réellement du texte brut dans le jeu de caractères US-ASCII, car il pourrait bien s'agir d'un message qui, utilisant un ensemble de conventions locales non standard antérieures à MIME, inclut du texte dans un autre jeu de caractères ou des données non textuelles présentées d'une manière qui ne peut pas être reconnue automatiquement (par exemple, un fichier tar UNIX compressé et uuencodé).
Points Clés :
- Tous les messages MIME doivent (MUST) inclure un en-tête
MIME-Version: 1.0 - Le format de version est
majeur.mineur(par exemple, 1.0) - Seulement requis au niveau supérieur du message, pas dans les parties de corps
- Les commentaires RFC 822 doivent être ignorés
- Les messages non-MIME peuvent utiliser des conventions locales