2. Définitions, Conventions et Grammaire BNF Générique (Definitions, Conventions, and Generic BNF Grammar)

Bien que les mécanismes MIME soient spécifiés en prose tout au long de cet ensemble de documents, nombre d'entre eux sont également décrits formellement en utilisant la notation BNF augmentée (Augmented BNF Notation) de la RFC 822. Les implémenteurs doivent être familiers avec cette notation afin de comprendre cet ensemble de documents, et sont invités à consulter la RFC 822 pour une explication complète de la notation BNF augmentée.

Une partie du BNF augmenté dans cet ensemble de documents fait référence par nom aux règles de syntaxe définies dans la RFC 822. Une grammaire formelle complète est donc obtenue en combinant les annexes de grammaire collectées de chaque document dans cet ensemble avec celle de la RFC 822 plus les modifications à la RFC 822 définies dans la RFC 1123 (qui modifie spécifiquement la syntaxe pour return, date, et mailbox).

Toutes les valeurs numériques et d'octets dans cet ensemble de documents sont données en notation décimale. Toutes les valeurs de type de média (Media Type), les valeurs de sous-type et les noms de paramètres tels que définis sont insensibles à la casse (Case-insensitive). Cependant, les valeurs de paramètres sont sensibles à la casse (Case-sensitive) sauf indication contraire pour le paramètre spécifique.

NOTE DE FORMAT : Des notes comme celle-ci fournissent des informations supplémentaires non essentielles que les lecteurs peuvent ignorer sans manquer quoi que ce soit d'essentiel. L'objectif principal de ces notes non essentielles est de transmettre des informations sur la justification de cet ensemble de documents, ou de placer ces documents dans le contexte historique ou évolutif approprié. En particulier, de telles informations peuvent être ignorées par ceux qui se concentrent uniquement sur la construction d'une implémentation conforme, mais peuvent être utiles à ceux qui souhaitent comprendre pourquoi certains choix de conception ont été faits.

2.1. CRLF

Le terme CRLF, dans cet ensemble de documents, se réfère à la séquence d'octets correspondant aux deux caractères US-ASCII CR (valeur décimale 13) et LF (valeur décimale 10) qui, pris ensemble, dans cet ordre, dénotent un saut de ligne (Line Break) dans le courrier RFC 822.

2.2. Jeu de Caractères (Character Set)

Le terme « jeu de caractères (Character Set) » est utilisé dans MIME pour faire référence à une méthode de conversion d'une séquence d'octets en une séquence de caractères. Notez qu'une conversion inconditionnelle et sans ambiguïté dans l'autre sens n'est pas requise, car tous les caractères peuvent ne pas être représentables par un jeu de caractères donné et un jeu de caractères peut fournir plus d'une séquence d'octets pour représenter une séquence de caractères particulière.

Cette définition est destinée à permettre divers types d'encodages de caractères, depuis de simples mappages à table unique tels que US-ASCII jusqu'à des méthodes complexes de commutation de tables telles que celles qui utilisent les techniques d'ISO 2022. Cependant, la définition associée à un nom de jeu de caractères MIME doit (MUST) spécifier complètement le mappage à effectuer. En particulier, l'utilisation d'informations de profilage externes (External Profiling Information) pour déterminer le mappage exact n'est pas autorisée.

NOTE : Le terme « jeu de caractères (Character Set) » était à l'origine utilisé pour décrire des éléments tels que US-ASCII et ISO-8859-1 qui consistent en un petit ensemble de caractères et un simple mappage un-à-un d'octets individuels vers des caractères individuels. Les jeux de caractères codés multi-octets (Multi-octet Coded Character Sets) et les techniques de commutation rendent la situation beaucoup plus compliquée. Par exemple, certaines communautés utilisent le terme « encodage de caractères (Character Encoding) » pour ce que MIME appelle un « jeu de caractères », tout en utilisant l'expression « jeu de caractères codés (Coded Character Set) » pour désigner un mappage abstrait d'entiers (pas d'octets) vers des caractères.

2.3. Message

Le terme « message (Message) », lorsqu'il n'est pas davantage qualifié, signifie soit le message (complet ou « de niveau supérieur ») transféré sur un réseau, soit un message encapsulé dans un corps de type "message/rfc822" ou "message/partial".

2.4. Entité (Entity)

Le terme « entité (Entity) » se réfère spécifiquement aux champs d'en-tête définis par MIME et au contenu soit d'un message, soit d'une des parties dans un corps multipartite. La spécification de telles entités est l'essence de MIME. Étant donné que le contenu d'une entité est souvent appelé le « corps (Body) », il est logique de parler du corps d'une entité. N'importe quel type de champ peut être présent dans l'en-tête d'une entité, mais seuls les champs dont les noms commencent par "content-" ont réellement une signification liée à MIME. Notez que cela ne signifie pas qu'ils n'ont aucune signification du tout - une entité qui est également un message possède des champs d'en-tête non-MIME dont la signification est définie par la RFC 822.

2.5. Partie de Corps (Body Part)

Le terme « partie de corps (Body Part) » se réfère à une entité à l'intérieur d'une entité multipartite.

2.6. Corps (Body)

Le terme « corps (Body) », lorsqu'il n'est pas davantage qualifié, signifie le corps d'une entité, c'est-à-dire le corps soit d'un message, soit d'une partie de corps.

NOTE : Les quatre définitions précédentes sont clairement circulaires. Ceci est inévitable, car la structure globale d'un message MIME est en effet récursive.

2.7. Données 7 bits (7bit Data)

Les « données 7 bits (7bit Data) » se réfèrent à des données entièrement représentées sous forme de lignes relativement courtes avec 998 octets ou moins entre les séquences de séparation de lignes CRLF [RFC-821]. Aucun octet avec des valeurs décimales supérieures à 127 n'est autorisé, ni les NUL (octets avec une valeur décimale de 0). Les octets CR (valeur décimale 13) et LF (valeur décimale 10) ne se produisent que dans le cadre de séquences de séparation de lignes CRLF.

2.8. Données 8 bits (8bit Data)

Les « données 8 bits (8bit Data) » se réfèrent à des données entièrement représentées sous forme de lignes relativement courtes avec 998 octets ou moins entre les séquences de séparation de lignes CRLF [RFC-821], mais les octets avec des valeurs décimales supérieures à 127 peuvent être utilisés. Comme avec les « données 7 bits », les octets CR et LF ne se produisent que dans le cadre de séquences de séparation de lignes CRLF et aucun NUL n'est autorisé.

2.9. Données Binaires (Binary Data)

Les « données binaires (Binary Data) » se réfèrent à des données où n'importe quelle séquence d'octets est autorisée.

2.10. Lignes (Lines)

Les « lignes (Lines) » sont définies comme des séquences d'octets séparées par des séquences CRLF. Ceci est cohérent avec la RFC 821 et la RFC 822. « Lignes » ne se réfère qu'à une unité de données dans un message, qui peut ou non correspondre à quelque chose qui est réellement affiché par un agent utilisateur (User Agent).

---

Résumé de la Terminologie :

Terme	Description
Jeu de Caractères (Character Set)	Méthode de conversion de séquences d'octets en séquences de caractères
Message	Message RFC 822 ou message encapsulé
Entité (Entity)	Champs d'en-tête MIME et contenu
Partie de Corps (Body Part)	Entité dans une entité multipartite
Corps (Body)	Contenu d'une entité
Données 7 bits (7bit Data)	US-ASCII uniquement, pas d'octets de poids fort, lignes courtes
Données 8 bits (8bit Data)	Octets de poids fort autorisés, lignes courtes
Données Binaires (Binary Data)	Toute séquence d'octets autorisée
Lignes (Lines)	Séquences d'octets séparées par CRLF

Concepts Clés :

• La structure MIME est récursive (les entités peuvent contenir des entités)
• Les noms de paramètres sont insensibles à la casse, mais les valeurs sont généralement sensibles à la casse
• CRLF est la seule forme de séparateur de ligne
• Les données sont classées en types 7 bits, 8 bits et binaires

---