2. Analyse lexicale des messages
2.1. Description générale
Au niveau le plus élémentaire, un message est une série de caractères. Un message conforme à cette spécification est composé de caractères dont les valeurs sont comprises entre 1 et 127 et interprétés comme des caractères US-ASCII [ANSI.X3-4.1986]. Par souci de concision, ce document désigne parfois cette plage de caractères simplement par « caractères US-ASCII ».
Remarque : Ce document spécifie que les messages sont constitués de caractères de la plage US-ASCII de 1 à 127. Il existe d'autres documents, notamment la série de documents MIME ([RFC2045], [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]), qui étendent cette spécification pour autoriser des valeurs en dehors de cette plage. La discussion de ces mécanismes ne relève pas du champ d'application de cette spécification.
Les messages sont divisés en lignes de caractères. Une ligne est une série de caractères délimitée par les deux caractères retour chariot et saut de ligne ; c'est-à-dire le caractère retour chariot (CR, valeur ASCII 13) immédiatement suivi du caractère saut de ligne (LF, valeur ASCII 10). (La paire retour chariot/saut de ligne est généralement notée « CRLF » dans ce document.) Un message se compose de champs d'en-tête (collectivement appelés « la section d'en-tête du message ») suivis, éventuellement, d'un corps. La section d'en-tête est une séquence de lignes de caractères dont la syntaxe particulière est définie dans cette spécification. Le corps est simplement une séquence de caractères qui suit la section d'en-tête et en est séparé par une ligne vide (c'est-à-dire une ligne où rien ne précède le CRLF).
Remarque : Le langage courant et les versions antérieures de cette spécification utilisent le terme « en-tête » pour désigner soit l'ensemble de la section d'en-tête, soit un champ d'en-tête individuel. Pour éviter toute ambiguïté, ce document n'utilise pas les termes « en-tête » ou « en-têtes » isolément, mais emploie toujours « champ d'en-tête » pour désigner le champ individuel et « section d'en-tête » pour désigner l'ensemble de la collection.
2.1.1. Limites de longueur de ligne
Cette spécification impose deux limites au nombre de caractères d'une ligne. Chaque ligne de caractères MUST comporter au plus 998 caractères, et SHOULD comporter au plus 78 caractères, à l'exclusion du CRLF.
La limite de 998 caractères est due aux limitations de nombreuses mises en œuvre qui envoient, reçoivent ou stockent des messages IMF et qui ne peuvent tout simplement pas traiter plus de 998 caractères sur une ligne. Les mises en œuvre réceptrices feraient bien de traiter un nombre de caractères arbitrairement grand sur une ligne, par souci de robustesse. Cependant, tant de mises en œuvre n'acceptent pas (conformément aux exigences de transport de [RFC5321]) les messages contenant plus de 1000 caractères par ligne, CR et LF compris, qu'il est important que les mises en œuvre ne créent pas de tels messages.
La recommandation plus conservatrice de 78 caractères vise à s'accommoder des nombreuses mises en œuvre d'interfaces utilisateur qui affichent ces messages et qui peuvent tronquer, ou replier de manière désastreuse, l'affichage de plus de 78 caractères par ligne, bien que de telles mises en œuvre ne soient pas conformes à l'intention de cette spécification (ni à celle de [RFC5321] si elles entraînent effectivement une perte d'informations). Là encore, même si cette limitation porte sur les messages, il incombe aux mises en œuvre qui affichent les messages de traiter un nombre de caractères arbitrairement grand sur une ligne (certainement au moins jusqu'à la limite de 998 caractères) par souci de robustesse.
2.2. Champs d'en-tête
Les champs d'en-tête sont des lignes commençant par un nom de champ, suivi de deux-points (« : »), suivi d'un corps de champ, et terminées par CRLF. Un nom de champ MUST être composé de caractères US-ASCII imprimables (c'est-à-dire des caractères dont les valeurs sont comprises entre 33 et 126 inclus), à l'exception des deux-points. Un corps de champ peut être composé de caractères US-ASCII imprimables ainsi que des caractères espace (SP, valeur ASCII 32) et tabulation horizontale (HTAB, valeur ASCII 9) (collectivement appelés caractères d'espacement, WSP). Un corps de champ MUST NOT inclure CR et LF, sauf lorsqu'ils sont utilisés pour le « pliage » et le « dépliage », comme décrit à la section 2.2.3. Tous les corps de champ MUST être conformes à la syntaxe décrite aux sections 3 et 4 de cette spécification.
2.2.1. Corps des champs d'en-tête non structurés
Certains corps de champ de cette spécification sont définis simplement comme « non structurés » (ce qui est spécifié à la section 3.2.5 comme tout caractère US-ASCII imprimable plus les caractères d'espacement) sans autre restriction. Ils sont appelés corps de champ non structurés. Sémantiquement, les corps de champ non structurés doivent simplement être traités comme une seule ligne de caractères sans traitement supplémentaire (sauf le « pliage » et le « dépliage » décrits à la section 2.2.3).
2.2.2. Corps des champs d'en-tête structurés
Certains corps de champ de cette spécification ont une syntaxe plus restrictive que les corps de champ non structurés décrits ci-dessus. Ils sont appelés corps de champ « structurés ». Les corps de champ structurés sont des séquences de jetons lexicaux spécifiques, comme décrit aux sections 3 et 4 de cette spécification. Beaucoup de ces jetons peuvent (conformément à leur syntaxe) être introduits ou terminés par des commentaires (comme décrit à la section 3.2.2) ainsi que par les caractères d'espacement, et ces caractères d'espacement sont soumis au « pliage » et au « dépliage » décrits à la section 2.2.3. L'analyse sémantique des corps de champ structurés est donnée avec leur syntaxe.
2.2.3. Champs d'en-tête longs
Chaque champ d'en-tête est logiquement une seule ligne de caractères comprenant le nom du champ, les deux-points et le corps du champ. Toutefois, par commodité et pour faire face aux limitations de 998/78 caractères par ligne, la partie corps d'un champ d'en-tête peut être scindée en une représentation sur plusieurs lignes ; c'est ce qu'on appelle le « pliage ». La règle générale est que partout où cette spécification autorise un espacement de pliage (et non simplement des caractères WSP), un CRLF peut être inséré avant tout WSP.
Par exemple, le champ d'en-tête :
Subject: This is a test
peut être représenté par :
Subject: This is a test
Remarque : Bien que les corps de champ structurés soient définis de manière à permettre le pliage entre bon nombre de jetons lexicaux (et même à l'intérieur de certains d'entre eux), le pliage SHOULD être limité au placement du CRLF aux ruptures syntaxiques de niveau supérieur. Par exemple, si un corps de champ est défini comme des valeurs séparées par des virgules, il est recommandé que le pliage ait lieu après la virgule séparant les éléments structurés, de préférence à d'autres endroits où le champ pourrait être plié, même si cela est autorisé ailleurs.
Le processus consistant à passer de cette représentation pliée sur plusieurs lignes d'un champ d'en-tête à sa représentation sur une seule ligne est appelé « dépliage ». Le dépliage s'effectue en supprimant simplement tout CRLF immédiatement suivi d'un WSP. Chaque champ d'en-tête doit être traité sous sa forme dépliée pour toute évaluation syntaxique et sémantique ultérieure. Un champ d'en-tête déplié n'a aucune restriction de longueur et peut donc être d'une longueur indéterminée.
2.3. Corps
Le corps d'un message est simplement constitué de lignes de caractères US-ASCII. Les deux seules limitations imposées au corps sont les suivantes :
o CR et LF MUST apparaître uniquement ensemble sous la forme CRLF ; ils MUST NOT apparaître indépendamment dans le corps. o Les lignes de caractères du corps MUST être limitées à 998 caractères, et SHOULD être limitées à 78 caractères, à l'exclusion du CRLF.
Remarque : Comme indiqué précédemment, il existe d'autres documents, notamment les documents MIME ([RFC2045], [RFC2046], [RFC2049], [RFC4288], [RFC4289]), qui étendent (et limitent) cette spécification afin d'autoriser différents types de corps de message. Là encore, ces mécanismes sortent du champ d'application de ce document.