4. Syntaxe obsolète
Les versions antérieures de cette spécification autorisaient une syntaxe différente (généralement plus permissive) que celle autorisée dans la présente version. En outre, des éléments syntaxiques utilisés dans des messages sur Internet n'ont jamais fait l'objet d'une interprétation documentée. Bien que ces formes syntaxiques MUST NOT soient générées conformément à la grammaire de la section 3, elles MUST être acceptées et analysées par un récepteur conforme. La présente section documente bon nombre de ces éléments syntaxiques. En prenant la grammaire de la section 3 et en y ajoutant les définitions présentées dans cette section, on obtient la grammaire à utiliser pour l'interprétation des messages.
Remarque : Cette section identifie les formes syntaxiques que toute implémentation MUST raisonnablement interpréter. Cependant, il existe assurément des messages Internet qui ne sont conformes même pas à la syntaxe supplémentaire donnée dans cette section. Le fait qu'une forme particulière n'apparaisse dans aucune section du présent document n'est pas une justification pour que des programmes informatiques plantent ou pour que des données mal formées soient irrémédiablement perdues par une implémentation quelconque. Il appartient à l'implémentation de traiter les messages de manière robuste.
Une différence importante entre la syntaxe obsolète (d'interprétation) et la syntaxe actuelle (de génération) est que, dans les corps de champs d'en-tête structurés (c'est-à-dire entre les deux-points et le CRLF de tout champ d'en-tête structuré), des caractères blancs, y compris l'espacement de pliage, et des commentaires pouvaient être librement insérés entre n'importe quels jetons syntaxiques. Cela permettait de nombreuses formes complexes qui se sont avérées difficiles à analyser pour certaines implémentations.
Une autre différence clé entre la syntaxe obsolète et la syntaxe actuelle est que la règle de la section 3.2.2 concernant les lignes composées uniquement de blancs dans les commentaires et l'espacement de pliage ne s'applique pas. Voir la discussion sur l'espacement de pliage à la section 4.2 ci-dessous.
Enfin, certains caractères qui étaient autrefois autorisés dans les messages apparaissent dans cette section. Le caractère NUL (valeur ASCII 0) était autrefois autorisé, mais ne l'est plus, pour des raisons de compatibilité. De même, les caractères de contrôle US-ASCII autres que CR, LF, SP et HTAB (valeurs ASCII 1 à 8, 11, 12, 14 à 31 et 127) étaient autorisés à apparaître dans les corps de champs d'en-tête. CR et LF étaient autorisés à apparaître dans les messages autrement que sous forme de CRLF ; cet usage est également montré ici.
Les autres différences de syntaxe et de sémantique sont notées dans les sections suivantes.
4.1. Jetons obsolètes divers
Ces éléments syntaxiques sont utilisés ailleurs dans la syntaxe obsolète ou dans la syntaxe principale. CR isolé, LF isolé et NUL sont ajoutés à obs-qp, obs-body et obs-unstruct. Les caractères de contrôle US-ASCII sont ajoutés à obs-qp, obs-unstruct, obs-ctext et obs-qtext. Le caractère point est ajouté à obs-phrase. La règle obs-phrase-list prévoit une liste de phrases séparées par des virgules (potentiellement vide) pouvant inclure des éléments « nuls ». Autrement dit, une telle liste pourrait comporter deux virgules ou plus sans rien entre elles, ou des virgules au début ou à la fin de la liste.
Remarque : Le caractère « point » (ou « point final ») (« . ») dans obs-phrase n'est pas une forme qui était autorisée dans les versions antérieures de cette spécification ou de toute autre spécification. Le point (ni d'ailleurs aucun autre caractère de specials) n'était pas permis dans phrase car il introduisait une difficulté d'analyse pour distinguer les phrases des parties d'un addr-spec (voir la section 4.4). Il apparaît ici parce que le caractère point est actuellement utilisé dans de nombreux messages dans la partie display-name des adresses, en particulier pour les initiales des noms, et doit donc être interprété correctement.
obs-NO-WS-CTL = %d1-8 / ; US-ASCII control
%d11 / ; characters that do not
%d12 / ; include the carriage
%d14-31 / ; return, line feed, and
%d127 ; white space characters
obs-ctext = obs-NO-WS-CTL
obs-qtext = obs-NO-WS-CTL
obs-utext = %d0 / obs-NO-WS-CTL / VCHAR
obs-qp = "\" (%d0 / obs-NO-WS-CTL / LF / CR)
obs-body = *((*LF *CR *((%d0 / text) *LF *CR)) / CRLF)
obs-unstruct = *((*LF *CR *(obs-utext *LF *CR)) / FWS)
obs-phrase = word *(word / "." / CFWS)
obs-phrase-list = [phrase / CFWS] *("," [phrase / CFWS])
CR isolé et LF isolé apparaissent dans les messages avec deux significations différentes. Dans de nombreux cas, CR isolé ou LF isolé est utilisé à tort à la place de CRLF pour indiquer des séparateurs de ligne. Dans d'autres cas, CR isolé et LF isolé sont simplement utilisés comme caractères de contrôle US-ASCII avec leurs significations ASCII traditionnelles.
4.2. Espacement de pliage obsolète
Dans la syntaxe obsolète, une quantité quelconque d'espacement de pliage MAY être insérée là où la règle obs-FWS est autorisée. Cela crée la possibilité d'avoir deux « pliures » consécutives dans une ligne, et donc la possibilité qu'une ligne constituant un champ d'en-tête plié soit composée entièrement de blancs.
obs-FWS = 1*WSP *(CRLF 1*WSP)
4.3. Date et heure obsolètes
La syntaxe du format de date obsolète autorise une année à deux chiffres dans le champ de date et prévoit une liste de spécificateurs de fuseau horaire alphabétiques utilisés dans les versions antérieures de cette spécification. Elle permet également des commentaires et de l'espacement de pliage entre bon nombre des jetons.
obs-day-of-week = [CFWS] day-name [CFWS]
obs-day = [CFWS] 1*2DIGIT [CFWS]
obs-year = [CFWS] 2*DIGIT [CFWS]
obs-hour = [CFWS] 2DIGIT [CFWS]
obs-minute = [CFWS] 2DIGIT [CFWS]
obs-second = [CFWS] 2DIGIT [CFWS]
obs-zone = "UT" / "GMT" / ; Universal Time
; North American UT
; offsets
"EST" / "EDT" / ; Eastern: - 5/ - 4
"CST" / "CDT" / ; Central: - 6/ - 5
"MST" / "MDT" / ; Mountain: - 7/ - 6
"PST" / "PDT" / ; Pacific: - 8/ - 7
;
%d65-73 / ; Military zones - "A"
%d75-90 / ; through "I" and "K"
%d97-105 / ; through "Z", both
%d107-122 ; upper and lower case
Lorsqu'une année à deux ou trois chiffres apparaît dans une date, l'année est à interpréter comme suit : si l'on rencontre une année à deux chiffres dont la valeur est comprise entre 00 et 49, l'année est interprétée en ajoutant 2000, ce qui donne une valeur comprise entre 2000 et 2049. Si l'on rencontre une année à deux chiffres dont la valeur est comprise entre 50 et 99, ou une année à trois chiffres quelconque, l'année est interprétée en ajoutant 1900.
Dans le fuseau horaire obsolète, « UT » et « GMT » désignent respectivement « Universal Time » (temps universel) et « Greenwich Mean Time » (heure moyenne de Greenwich), et sont sémantiquement tous deux identiques à « +0000 ».
Les autres fuseaux à trois caractères sont les fuseaux horaires des États-Unis. La première lettre, « E », « C », « M » ou « P », représente « Eastern » , « Central », « Mountain » et « Pacific ». La seconde lettre est soit « S » pour l'heure « Standard », soit « D » pour l'heure « Daylight Savings » (heure d'été). Leurs interprétations sont les suivantes :
EDT est sémantiquement équivalent à -0400 EST est sémantiquement équivalent à -0500 CDT est sémantiquement équivalent à -0500 CST est sémantiquement équivalent à -0600 MDT est sémantiquement équivalent à -0600 MST est sémantiquement équivalent à -0700 PDT est sémantiquement équivalent à -0700 PST est sémantiquement équivalent à -0800
Les fuseaux horaires militaires d'un caractère ont été définis de manière non normalisée dans [RFC0822] et leur signification est donc imprévisible. Les définitions originales des fuseaux militaires « A » à « I » sont respectivement équivalentes à « +0100 » à « +0900 » ; « K », « L » et « M » sont respectivement équivalents à « +1000 », « +1100 » et « +1200 » ; « N » à « Y » sont respectivement équivalents à « -0100 » à « -1200 » ; et « Z » est équivalent à « +0000 ». Cependant, en raison de l'erreur dans [RFC0822], ils SHOULD tous être considérés comme équivalents à « -0000 », sauf s'il existe une information hors bande confirmant leur signification.
D'autres fuseaux horaires alphabétiques à plusieurs caractères (généralement entre 3 et 5) ont été utilisés dans des messages Internet. Tout fuseau horaire dont la signification n'est pas connue SHOULD être considéré comme équivalent à « -0000 », sauf s'il existe une information hors bande confirmant sa signification.
4.4. Adressage obsolète
Il y a quatre différences principales dans l'adressage. Premièrement, les adresses de boîte aux lettres étaient autorisées à comporter une partie route avant l'addr-spec lorsqu'elles étaient encadrées par « < » et « > ». La route est simplement une liste de noms de domaine séparés par des virgules, chacun précédé de « @ », la liste étant terminée par deux-points. Deuxièmement, CFWS était autorisé entre les éléments séparés par des points du local-part et du domain (c'est-à-dire que dot-atom n'était pas utilisé). En outre, le local-part était autorisé à contenir un quoted-string en plus d'un simple atom. Troisièmement, mailbox-list et address-list étaient autorisées à avoir des membres « nuls ». Autrement dit, une telle liste pouvait comporter deux virgules ou plus sans rien entre elles, ou des virgules au début ou à la fin de la liste. Enfin, les caractères de contrôle US-ASCII et les quoted-pairs étaient autorisés dans les domain literals et sont ajoutés ici.
obs-angle-addr = [CFWS] "<" obs-route addr-spec ">" [CFWS]
obs-route = obs-domain-list ":"
obs-domain-list = *(CFWS / ",") "@" domain
*("," [CFWS] ["@" domain])
obs-mbox-list = *([CFWS] ",") mailbox *("," [mailbox / CFWS])
obs-addr-list = *([CFWS] ",") address *("," [address / CFWS])
obs-group-list = 1*([CFWS] ",") [CFWS]
obs-local-part = word *("." word)
obs-domain = atom *("." atom)
obs-dtext = obs-NO-WS-CTL / quoted-pair
Lors de l'interprétation des adresses, la partie route SHOULD être ignorée.
4.5. Champs d'en-tête obsolètes
Sur le plan syntaxique, la différence principale de la syntaxe obsolète des champs est qu'elle autorise des occurrences multiples de chacun des champs et qu'elles peuvent apparaître dans n'importe quel ordre. En outre, une quantité quelconque de blancs est autorisée avant les « : » qui terminent le nom du champ.
obs-fields = *(obs-return /
obs-received /
obs-orig-date /
obs-from /
obs-sender /
obs-reply-to /
obs-to /
obs-cc /
obs-bcc /
obs-message-id /
obs-in-reply-to /
obs-references /
obs-subject /
obs-comments /
obs-keywords /
obs-resent-date /
obs-resent-from /
obs-resent-send /
obs-resent-rply /
obs-resent-to /
obs-resent-cc /
obs-resent-bcc /
obs-resent-mid /
obs-optional)
À l'exception des champs d'adresse de destination (décrits à la section 4.5.3), l'interprétation des occurrences multiples de champs n'est pas spécifiée. De même, l'interprétation des champs de trace et des champs resent qui n'apparaissent pas dans des blocs préfixés au message n'est pas spécifiée non plus. Sauf indication contraire dans les sections suivantes, l'interprétation des autres champs est identique à celle de leurs homologues non obsolètes de la section 3.
4.5.1. Champ de date d'origine obsolète
obs-orig-date = "Date" *WSP ":" date-time CRLF
4.5.2. Champs d'origine obsolètes
obs-from = "From" *WSP ":" mailbox-list CRLF
obs-sender = "Sender" *WSP ":" mailbox CRLF
obs-reply-to = "Reply-To" *WSP ":" address-list CRLF
4.5.3. Champs d'adresse de destination obsolètes
obs-to = "To" *WSP ":" address-list CRLF
obs-cc = "Cc" *WSP ":" address-list CRLF
obs-bcc = "Bcc" *WSP ":"
(address-list / (*([CFWS] ",") [CFWS])) CRLF
Lorsque des occurrences multiples de champs d'adresse de destination apparaissent dans un message, elles SHOULD être traitées comme si la liste d'adresses de la première occurrence du champ était combinée aux listes d'adresses des occurrences suivantes par ajout d'une virgule et concaténation.
4.5.4. Champs d'identification obsolètes
Les champs obsolètes « In-Reply-To: » et « References: » diffèrent de la syntaxe actuelle en ceci qu'ils permettent l'apparition de phrase (mots ou chaînes entre guillemets). Les formes obsolètes des parties gauche et droite de msg-id permettent d'entrelacer du CFWS, ce qui les rend syntaxiquement identiques respectivement à local-part et à domain.
obs-message-id = "Message-ID" *WSP ":" msg-id CRLF
obs-in-reply-to = "In-Reply-To" *WSP ":" *(phrase / msg-id) CRLF
obs-references = "References" *WSP ":" *(phrase / msg-id) CRLF
obs-id-left = local-part
obs-id-right = domain
Aux fins de l'interprétation, les phrases des champs « In-Reply-To: » et « References: » sont ignorées.
Sémantiquement, aucun du CFWS facultatif du local-part et du domain ne fait partie de obs-id-left et obs-id-right, respectivement.
4.5.5. Champs d'information obsolètes
obs-subject = "Subject" *WSP ":" unstructured CRLF
obs-comments = "Comments" *WSP ":" unstructured CRLF
obs-keywords = "Keywords" *WSP ":" obs-phrase-list CRLF
4.5.6. Champs resent obsolètes
La syntaxe obsolète ajoute un champ « Resent-Reply-To: », qui se compose du nom du champ, des commentaires et de l'espacement de pliage facultatifs, des deux-points, et d'une liste d'adresses séparées par des virgules.
obs-resent-from = "Resent-From" *WSP ":" mailbox-list CRLF
obs-resent-send = "Resent-Sender" *WSP ":" mailbox CRLF
obs-resent-date = "Resent-Date" *WSP ":" date-time CRLF
obs-resent-to = "Resent-To" *WSP ":" address-list CRLF
obs-resent-cc = "Resent-Cc" *WSP ":" address-list CRLF
obs-resent-bcc = "Resent-Bcc" *WSP ":"
(address-list / (*([CFWS] ",") [CFWS])) CRLF
obs-resent-mid = "Resent-Message-ID" *WSP ":" msg-id CRLF
obs-resent-rply = "Resent-Reply-To" *WSP ":" address-list CRLF
Comme pour les autres champs resent, le champ « Resent-Reply-To: » doit être traité comme une simple information de trace.
4.5.7. Champs de trace obsolètes
obs-return et obs-received sont de nouveau donnés ici comme définitions de gabarit, tout comme return et received à la section 3. Leur syntaxe complète est donnée dans [RFC5321].
obs-return = "Return-Path" *WSP ":" path CRLF
obs-received = "Received" *WSP ":" *received-token CRLF
4.5.8. Champs facultatifs obsolètes
obs-optional = field-name *WSP ":" unstructured CRLF