2. Definitionen, Konventionen und generische BNF-Grammatik (Definitions, Conventions, and Generic BNF Grammar)

Obwohl MIME-Mechanismen in diesem Dokumentensatz durchgehend in Prosa spezifiziert werden, werden viele auch formal unter Verwendung der erweiterten BNF-Notation (Augmented BNF Notation) von RFC 822 beschrieben. Implementierer müssen mit dieser Notation vertraut sein, um diesen Dokumentensatz zu verstehen, und werden auf RFC 822 für eine vollständige Erklärung der erweiterten BNF-Notation verwiesen.

Ein Teil des erweiterten BNF in diesem Dokumentensatz verweist namentlich auf Syntaxregeln, die in RFC 822 definiert sind. Eine vollständige formale Grammatik (Formal Grammar) wird daher durch Kombination der gesammelten Grammatik-Anhänge aus jedem Dokument in diesem Satz mit der aus RFC 822 plus den Modifikationen zu RFC 822, die in RFC 1123 definiert sind (die speziell die Syntax für return, date und mailbox ändern), erhalten.

Alle numerischen Werte und Oktett-Werte in diesem Dokumentensatz werden in Dezimalnotation angegeben. Alle Medientyp-Werte (Media Type Values), Subtyp-Werte und Parameternamen sind gemäß Definition nicht von Groß-/Kleinschreibung abhängig (Case-insensitive). Parameterwerte sind jedoch von Groß-/Kleinschreibung abhängig (Case-sensitive), sofern nicht anders für den spezifischen Parameter angegeben.

FORMATHINWEIS: Hinweise wie dieser bieten zusätzliche, nicht wesentliche Informationen, die Leser überspringen können, ohne etwas Wesentliches zu verpassen. Der Hauptzweck dieser nicht wesentlichen Hinweise besteht darin, Informationen über die Begründung dieses Dokumentensatzes zu vermitteln oder diese Dokumente in den richtigen historischen oder evolutionären Kontext zu stellen. Insbesondere können solche Informationen von denen übersprungen werden, die sich ausschließlich auf den Aufbau einer konformen Implementierung konzentrieren, können aber für diejenigen nützlich sein, die verstehen möchten, warum bestimmte Designentscheidungen getroffen wurden.

2.1. CRLF

Der Begriff CRLF bezieht sich in diesem Dokumentensatz auf die Sequenz von Oktetten, die den beiden US-ASCII-Zeichen CR (Dezimalwert 13) und LF (Dezimalwert 10) entsprechen, die zusammen in dieser Reihenfolge einen Zeilenumbruch (Line Break) in RFC 822-Mail bezeichnen.

2.2. Zeichensatz (Character Set)

Der Begriff „Zeichensatz (Character Set)" wird in MIME verwendet, um sich auf eine Methode zur Umwandlung einer Sequenz von Oktetten in eine Sequenz von Zeichen zu beziehen. Beachten Sie, dass eine bedingungslose und eindeutige Umwandlung in die andere Richtung nicht erforderlich ist, da nicht alle Zeichen durch einen gegebenen Zeichensatz darstellbar sein müssen und ein Zeichensatz mehr als eine Sequenz von Oktetten bereitstellen kann, um eine bestimmte Sequenz von Zeichen darzustellen.

Diese Definition soll verschiedene Arten von Zeichenkodierungen ermöglichen, von einfachen Einzeltabellen-Mappings wie US-ASCII bis zu komplexen Tabellenumschaltverfahren wie denen, die ISO 2022-Techniken verwenden. Die Definition, die mit einem MIME-Zeichensatznamen verbunden ist, muss (MUST) jedoch das durchzuführende Mapping vollständig spezifizieren. Insbesondere ist die Verwendung externer Profilinformationen (External Profiling Information) zur Bestimmung des genauen Mappings nicht gestattet.

HINWEIS: Der Begriff „Zeichensatz (Character Set)" wurde ursprünglich verwendet, um Dinge wie US-ASCII und ISO-8859-1 zu beschreiben, die aus einer kleinen Menge von Zeichen und einem einfachen Eins-zu-Eins-Mapping von einzelnen Oktetten zu einzelnen Zeichen bestehen. Mehroktett-kodierte Zeichensätze (Multi-octet Coded Character Sets) und Umschalttechniken machen die Situation viel komplizierter. Einige Communities verwenden beispielsweise den Begriff „Zeichenkodierung (Character Encoding)" für das, was MIME einen „Zeichensatz" nennt, während sie die Phrase „kodierter Zeichensatz (Coded Character Set)" verwenden, um ein abstraktes Mapping von ganzen Zahlen (nicht Oktetten) zu Zeichen zu bezeichnen.

2.3. Nachricht (Message)

Der Begriff „Nachricht (Message)", wenn nicht weiter qualifiziert, bedeutet entweder die (vollständige oder „oberste") Nachricht, die über ein Netzwerk übertragen wird, oder eine Nachricht, die in einem Body vom Typ "message/rfc822" oder "message/partial" gekapselt ist.

2.4. Entität (Entity)

Der Begriff „Entität (Entity)" bezieht sich speziell auf die MIME-definierten Header-Felder und Inhalte entweder einer Nachricht oder eines der Teile in einem mehrteiligen Body. Die Spezifikation solcher Entitäten ist das Wesen von MIME. Da der Inhalt einer Entität oft als „Body" bezeichnet wird, ist es sinnvoll, vom Body einer Entität zu sprechen. Jede Art von Feld kann im Header einer Entität vorhanden sein, aber nur die Felder, deren Namen mit "content-" beginnen, haben tatsächlich eine MIME-bezogene Bedeutung. Beachten Sie, dass dies nicht bedeutet, dass sie überhaupt keine Bedeutung haben - eine Entität, die auch eine Nachricht ist, hat Nicht-MIME-Header-Felder, deren Bedeutung durch RFC 822 definiert ist.

2.5. Body-Teil (Body Part)

Der Begriff „Body-Teil (Body Part)" bezieht sich auf eine Entität innerhalb einer mehrteiligen Entität.

2.6. Body

Der Begriff „Body", wenn nicht weiter qualifiziert, bedeutet den Body einer Entität, d.h. den Body entweder einer Nachricht oder eines Body-Teils.

HINWEIS: Die vorherigen vier Definitionen sind eindeutig zirkulär. Dies ist unvermeidlich, da die Gesamtstruktur einer MIME-Nachricht tatsächlich rekursiv ist.

2.7. 7-Bit-Daten (7bit Data)

„7-Bit-Daten (7bit Data)" beziehen sich auf Daten, die alle als relativ kurze Zeilen mit 998 Oktetten oder weniger zwischen CRLF-Zeilentrennungssequenzen dargestellt werden [RFC-821]. Keine Oktette mit Dezimalwerten größer als 127 sind erlaubt, ebenso keine NULs (Oktette mit Dezimalwert 0). CR (Dezimalwert 13) und LF (Dezimalwert 10) Oktette treten nur als Teil von CRLF-Zeilentrennungssequenzen auf.

2.8. 8-Bit-Daten (8bit Data)

„8-Bit-Daten (8bit Data)" beziehen sich auf Daten, die alle als relativ kurze Zeilen mit 998 Oktetten oder weniger zwischen CRLF-Zeilentrennungssequenzen dargestellt werden [RFC-821], aber Oktette mit Dezimalwerten größer als 127 können verwendet werden. Wie bei „7-Bit-Daten" treten CR- und LF-Oktette nur als Teil von CRLF-Zeilentrennungssequenzen auf und keine NULs sind erlaubt.

2.9. Binärdaten (Binary Data)

„Binärdaten (Binary Data)" beziehen sich auf Daten, bei denen jede beliebige Sequenz von Oktetten erlaubt ist.

2.10. Zeilen (Lines)

„Zeilen (Lines)" sind als Sequenzen von Oktetten definiert, die durch CRLF-Sequenzen getrennt sind. Dies ist konsistent sowohl mit RFC 821 als auch mit RFC 822. „Zeilen" bezieht sich nur auf eine Dateneinheit in einer Nachricht, die möglicherweise etwas entspricht oder nicht, das tatsächlich von einem Benutzeragenten (User Agent) angezeigt wird.

---

Terminologie-Zusammenfassung:

Begriff	Beschreibung
Zeichensatz (Character Set)	Methode zur Umwandlung von Oktettsequenzen in Zeichensequenzen
Nachricht (Message)	RFC 822-Nachricht oder gekapselte Nachricht
Entität (Entity)	MIME-Header-Felder und Inhalt
Body-Teil (Body Part)	Entität innerhalb einer mehrteiligen Entität
Body	Inhalt einer Entität
7-Bit-Daten (7bit Data)	Nur US-ASCII, keine High-Bit-Oktette, kurze Zeilen
8-Bit-Daten (8bit Data)	High-Bit-Oktette erlaubt, kurze Zeilen
Binärdaten (Binary Data)	Jede Oktettsequenz erlaubt
Zeilen (Lines)	CRLF-getrennte Oktettsequenzen

Schlüsselkonzepte:

• Die MIME-Struktur ist rekursiv (Entitäten können Entitäten enthalten)
• Parameternamen sind nicht von Groß-/Kleinschreibung abhängig, aber Werte normalerweise schon
• CRLF ist die einzige Form des Zeilenseparators
• Daten werden in 7-Bit-, 8-Bit- und Binärtypen klassifiziert

---