2. Lexikalische Analyse von Nachrichten
2.1. Allgemeine Beschreibung
Auf der grundlegendsten Ebene ist eine Nachricht eine Folge von Zeichen. Eine Nachricht, die mit dieser Spezifikation konform ist, besteht aus Zeichen mit Werten im Bereich von 1 bis 127, die als US-ASCII-Zeichen [ANSI.X3-4.1986] interpretiert werden. Der Kürze halber bezeichnet dieses Dokument diesen Zeichenbereich manchmal einfach als "US-ASCII-Zeichen".
Hinweis: Dieses Dokument spezifiziert, dass Nachrichten aus Zeichen im US-ASCII-Bereich von 1 bis 127 bestehen. Es gibt andere Dokumente, insbesondere die MIME-Dokumentenreihe ([RFC2045], [RFC2046], [RFC2047], [RFC2049], [RFC4288], [RFC4289]), die diese Spezifikation erweitern, um Werte außerhalb dieses Bereichs zuzulassen. Eine Erörterung dieser Mechanismen liegt nicht im Geltungsbereich dieser Spezifikation.
Nachrichten werden in Zeilen von Zeichen unterteilt. Eine Zeile ist eine Folge von Zeichen, die durch die beiden Zeichen Wagenrücklauf und Zeilenvorschub begrenzt wird; das heißt, das Zeichen Wagenrücklauf (CR) (ASCII-Wert 13) unmittelbar gefolgt vom Zeichen Zeilenvorschub (LF) (ASCII-Wert 10). (Das Paar aus Wagenrücklauf und Zeilenvorschub wird in diesem Dokument üblicherweise als "CRLF" geschrieben.) Eine Nachricht besteht aus Header-Feldern (zusammenfassend "der Header-Abschnitt der Nachricht" genannt), gefolgt, optional, von einem Körper. Der Header-Abschnitt ist eine Folge von Zeilen von Zeichen mit spezieller Syntax, wie in dieser Spezifikation definiert. Der Körper ist einfach eine Folge von Zeichen, die auf den Header-Abschnitt folgt und von diesem durch eine leere Zeile getrennt ist (d. h. eine Zeile, der nichts vor dem CRLF vorausgeht).
Hinweis: Der übliche Sprachgebrauch und frühere Versionen dieser Spezifikation verwenden den Begriff "header", um entweder den gesamten Header-Abschnitt oder ein einzelnes Header-Feld zu bezeichnen. Um Mehrdeutigkeit zu vermeiden, verwendet dieses Dokument die Begriffe "header" oder "headers" nicht isoliert, sondern verwendet stets "Header-Feld" (header field) für das einzelne Feld und "Header-Abschnitt" (header section) für die gesamte Sammlung.
2.1.1. Zeilenlängengrenzen
Es gibt zwei Grenzen, die diese Spezifikation für die Anzahl der Zeichen in einer Zeile festlegt. Jede Zeile von Zeichen darf nicht mehr als (MUST) 998 Zeichen umfassen und sollte nicht mehr als (SHOULD) 78 Zeichen umfassen, wobei das CRLF nicht mitgezählt wird.
Die Grenze von 998 Zeichen ist auf Einschränkungen in vielen Implementierungen zurückzuführen, die IMF-Nachrichten senden, empfangen oder speichern und die schlicht nicht mehr als 998 Zeichen in einer Zeile verarbeiten können. Empfangende Implementierungen täten gut daran, um der Robustheit willen eine beliebig große Anzahl von Zeichen in einer Zeile zu verarbeiten. Es gibt jedoch so viele Implementierungen, die (in Übereinstimmung mit den Transportanforderungen von [RFC5321]) Nachrichten nicht akzeptieren, die mehr als 1000 Zeichen einschließlich des CR und LF pro Zeile enthalten, dass es für Implementierungen wichtig ist, solche Nachrichten nicht zu erstellen.
Die konservativere Empfehlung von 78 Zeichen dient dazu, den vielen Implementierungen von Benutzeroberflächen Rechnung zu tragen, die diese Nachrichten anzeigen und die Darstellung von mehr als 78 Zeichen pro Zeile abschneiden oder in katastrophaler Weise umbrechen könnten, auch wenn solche Implementierungen nicht konform mit der Absicht dieser Spezifikation sind (und mit der von [RFC5321], wenn sie tatsächlich einen Informationsverlust verursachen). Auch hier gilt: Obwohl diese Beschränkung Nachrichten betrifft, ist es für Implementierungen, die Nachrichten anzeigen, unerlässlich, um der Robustheit willen eine beliebig große Anzahl von Zeichen in einer Zeile zu verarbeiten (sicherlich mindestens bis zur Grenze von 998 Zeichen).
2.2. Header-Felder
Header-Felder sind Zeilen, die mit einem Feldnamen beginnen, gefolgt von einem Doppelpunkt (":"), gefolgt von einem Feldkörper, und die mit CRLF abgeschlossen werden. Ein Feldname muss (MUST) aus druckbaren US-ASCII-Zeichen bestehen (d. h. Zeichen mit Werten zwischen 33 und 126, einschließlich), mit Ausnahme des Doppelpunkts. Ein Feldkörper darf aus druckbaren US-ASCII-Zeichen sowie dem Leerzeichen (SP, ASCII-Wert 32) und dem horizontalen Tabulator (HTAB, ASCII-Wert 9) bestehen (zusammen als die Leerzeichen (white space characters, WSP) bekannt). Ein Feldkörper darf nicht (MUST NOT) CR und LF enthalten, außer wenn er in "folding" und "unfolding" verwendet wird, wie in Abschnitt 2.2.3 beschrieben. Alle Feldkörper müssen (MUST) der in den Abschnitten 3 und 4 dieser Spezifikation beschriebenen Syntax entsprechen.
2.2.1. Unstrukturierte Header-Feld-Körper
Einige Feldkörper in dieser Spezifikation sind einfach als "unstrukturiert" (unstructured) definiert (was in Abschnitt 3.2.5 als beliebige druckbare US-ASCII-Zeichen plus Leerzeichen spezifiziert wird), ohne weitere Einschränkungen. Diese werden als unstrukturierte Feldkörper bezeichnet. Semantisch sind unstrukturierte Feldkörper einfach als eine einzelne Zeile von Zeichen ohne weitere Verarbeitung zu behandeln (mit Ausnahme von "folding" und "unfolding", wie in Abschnitt 2.2.3 beschrieben).
2.2.2. Strukturierte Header-Feld-Körper
Einige Feldkörper in dieser Spezifikation haben eine Syntax, die restriktiver ist als die oben beschriebenen unstrukturierten Feldkörper. Diese werden als "strukturierte" (structured) Feldkörper bezeichnet. Strukturierte Feldkörper sind Folgen spezifischer lexikalischer Token, wie in den Abschnitten 3 und 4 dieser Spezifikation beschrieben. Viele dieser Token dürfen (gemäß ihrer Syntax) mit Kommentaren (wie in Abschnitt 3.2.2 beschrieben) sowie mit Leerzeichen eingeleitet oder beendet werden, und diese Leerzeichen unterliegen dem "folding" und "unfolding", wie in Abschnitt 2.2.3 beschrieben. Die semantische Analyse strukturierter Feldkörper wird zusammen mit ihrer Syntax angegeben.
2.2.3. Lange Header-Felder
Jedes Header-Feld ist logisch eine einzelne Zeile von Zeichen, die den Feldnamen, den Doppelpunkt und den Feldkörper umfasst. Der Bequemlichkeit halber und um mit den Beschränkungen von 998/78 Zeichen pro Zeile umzugehen, kann der Feldkörperteil eines Header-Felds in eine mehrzeilige Darstellung aufgeteilt werden; dies wird "folding" genannt. Die allgemeine Regel lautet, dass überall dort, wo diese Spezifikation faltbare Leerzeichen zulässt (nicht einfach WSP-Zeichen), ein CRLF vor jedem WSP eingefügt werden darf.
Zum Beispiel kann das Header-Feld:
Subject: This is a test
folgendermaßen dargestellt werden:
Subject: This is a test
Hinweis: Obwohl strukturierte Feldkörper so definiert sind, dass Folding zwischen vielen der lexikalischen Token (und sogar innerhalb einiger der lexikalischen Token) stattfinden kann, sollte (SHOULD) Folding darauf beschränkt werden, das CRLF an syntaktischen Brüchen höherer Ebene zu platzieren. Wenn ein Feldkörper beispielsweise als kommagetrennte Werte definiert ist, wird empfohlen, dass Folding nach dem Komma erfolgt, das die strukturierten Elemente trennt, und nicht an anderen Stellen, an denen das Feld gefaltet werden könnte, selbst wenn dies anderswo zulässig ist.
Der Vorgang, von dieser gefalteten mehrzeiligen Darstellung eines Header-Felds zu seiner einzeiligen Darstellung zu gelangen, wird "unfolding" genannt. Unfolding wird erreicht, indem einfach jedes CRLF entfernt wird, auf das unmittelbar WSP folgt. Jedes Header-Feld sollte in seiner entfalteten Form für die weitere syntaktische und semantische Auswertung behandelt werden. Ein entfaltetes Header-Feld hat keine Längenbeschränkung und kann daher unbestimmt lang sein.
2.3. Nachrichtenkörper
Der Körper (body) einer Nachricht ist einfach eine Folge von Zeilen aus US-ASCII-Zeichen. Die einzigen beiden Einschränkungen für den Körper sind wie folgt:
o CR und LF dürfen nur gemeinsam als CRLF auftreten (MUST); sie dürfen nicht (MUST NOT) unabhängig voneinander im Körper erscheinen. o Zeilen von Zeichen im Körper müssen (MUST) auf 998 Zeichen beschränkt sein und sollten (SHOULD) auf 78 Zeichen beschränkt sein, wobei das CRLF nicht mitgezählt wird.
Hinweis: Wie bereits erwähnt, gibt es andere Dokumente, insbesondere die MIME-Dokumente ([RFC2045], [RFC2046], [RFC2049], [RFC4288], [RFC4289]), die diese Spezifikation erweitern (und begrenzen), um verschiedene Arten von Nachrichtenkörpern zuzulassen. Auch hier liegen diese Mechanismen außerhalb des Geltungsbereichs dieses Dokuments.