1. Einführung (Introduction)

Seit seiner Veröffentlichung im Jahr 1982 hat RFC 822 das Standardformat für textuelle Mail-Nachrichten im Internet definiert. Sein Erfolg war so groß, dass das RFC 822-Format ganz oder teilweise weit über die Grenzen des Internets und des durch RFC 821 definierten Internet-SMTP-Transports hinaus übernommen wurde. Da dieses Format weit verbreitet wurde, haben sich eine Reihe von Einschränkungen für die Benutzer-Community als zunehmend restriktiv erwiesen.

RFC 822 war dazu bestimmt, ein Format für Textnachrichten zu spezifizieren. Als solches werden nicht-textuelle Nachrichten, wie z.B. Multimedia-Nachrichten, die Audio oder Bilder enthalten könnten, einfach nicht erwähnt. Aber selbst im Fall von Text ist RFC 822 für die Bedürfnisse von Mail-Benutzern unzureichend, deren Sprachen die Verwendung von reichhaltigeren Zeichensätzen als US-ASCII erfordern. Da RFC 822 keine Mechanismen für Mail mit Audio, Video, asiatischem Sprachtext oder sogar Text in den meisten europäischen Sprachen spezifiziert, sind zusätzliche Spezifikationen erforderlich.

Eine der bemerkenswerten Einschränkungen des grundlegenden RFC 821/822-Mail-Systems besteht darin, dass sie den Inhalt von E-Mail-Nachrichten auf relativ kurze Zeilen (z.B. 1000 Zeichen oder weniger [RFC-821]) von 7-Bit-US-ASCII begrenzen. Dies zwingt Benutzer, alle nicht-textuellen Daten, die sie senden möchten, in sieben-Bit-Bytes umzuwandeln, die als druckbare US-ASCII-Zeichen darstellbar sind, bevor sie einen lokalen Mail-UA (User Agent, ein Programm, mit dem menschliche Benutzer Mail senden und empfangen) aufrufen. Beispiele für solche Kodierungen, die derzeit im Internet verwendet werden, umfassen reines Hexadezimal, uuencode, das in RFC 1421 spezifizierte 3-in-4-Base-64-Schema, die Andrew Toolkit Representation [ATK] und viele andere.

Die Einschränkungen des RFC 822-Mail-Formats werden noch deutlicher, wenn Gateways entworfen werden, um den Austausch von Mail-Nachrichten zwischen RFC 822-Hosts und X.400-Hosts zu ermöglichen. X.400 [X400] spezifiziert Mechanismen für die Einbeziehung von nicht-textuellem Material in E-Mail-Nachrichten. Die aktuellen Standards für die Zuordnung von X.400-Nachrichten zu RFC 822-Nachrichten geben an, dass nicht-textuelles X.400-Material in das IA5Text-Format konvertiert (nicht kodiert) werden muss (must) oder verworfen werden muss, wobei der RFC 822-Benutzer über das Verwerfen benachrichtigt wird. Dies ist eindeutig unerwünscht, da Informationen, die ein Benutzer möglicherweise erhalten möchte, verloren gehen. Selbst wenn ein Benutzeragent nicht die Fähigkeit hat, das nicht-textuelle Material zu verarbeiten, könnte der Benutzer einen Mechanismus außerhalb des UA haben, der nützliche Informationen aus dem Material extrahieren kann. Darüber hinaus berücksichtigt es nicht die Tatsache, dass die Nachricht möglicherweise schließlich wieder in ein X.400-Message-Handling-System zurückgeleitet wird (d.h. die X.400-Nachricht wird durch Internet-Mail „getunnelt"), wo die nicht-textuellen Informationen definitiv wieder nützlich werden würden.

Dieses Dokument beschreibt mehrere Mechanismen, die sich kombinieren, um die meisten dieser Probleme zu lösen, ohne ernsthafte Inkompatibilitäten mit der bestehenden RFC 822-Mail-Welt einzuführen. Insbesondere beschreibt es:

Ein MIME-Version-Header-Feld, das eine Versionsnummer verwendet, um zu erklären, dass eine Nachricht mit MIME konform ist, und Mail-Verarbeitungsagenten ermöglicht, zwischen solchen Nachrichten und denen zu unterscheiden, die von älterer oder nicht konformer Software generiert wurden, die vermutlich ein solches Feld nicht enthält.
Ein Content-Type-Header-Feld, verallgemeinert aus RFC 1049, das verwendet werden kann, um den Medientyp und Untertyp von Daten im Körper einer Nachricht zu spezifizieren und die native Darstellung (kanonische Form) solcher Daten vollständig zu spezifizieren.
Ein Content-Transfer-Encoding-Header-Feld, das verwendet werden kann, um sowohl die Kodierungstransformation, die auf den Körper angewendet wurde, als auch die Domäne des Ergebnisses zu spezifizieren. Kodierungstransformationen, die nicht die Identitätstransformation sind, werden normalerweise auf Daten angewendet, um ihnen zu ermöglichen, Mail-Transport-Mechanismen zu passieren, die Daten- oder Zeichensatzbeschränkungen haben können.
Zwei zusätzliche Header-Felder, Content-ID und Content-Description, die verwendet werden können, um die Daten in einem Körper weiter zu beschreiben.

Alle in diesem Dokument definierten Header-Felder unterliegen den allgemeinen syntaktischen Regeln für Header-Felder, die in RFC 822 spezifiziert sind. Insbesondere können alle diese Header-Felder mit Ausnahme von Content-Disposition RFC 822-Kommentare enthalten, die keinen semantischen Inhalt haben und während der MIME-Verarbeitung ignoriert werden sollten (should).

Schließlich bietet RFC 2049, um Interoperabilität zu spezifizieren und zu fördern, eine grundlegende Anwendbarkeitserklärung für eine Teilmenge der oben genannten Mechanismen, die ein minimales „konformes" Niveau für das aktuelle Dokument definiert.

HISTORISCHE ANMERKUNG: Einige der in diesem Dokumentensatz beschriebenen Mechanismen mögen beim ersten Lesen etwas seltsam oder sogar barock erscheinen. Es ist wichtig zu beachten, dass Kompatibilität mit bestehenden Standards UND Robustheit über die bestehende Praxis hinweg zwei der höchsten Prioritäten der Arbeitsgruppe waren, die diesen Dokumentensatz entwickelt hat. Insbesondere wurde Kompatibilität immer gegenüber Eleganz bevorzugt.

Bitte beziehen Sie sich auf die aktuelle Ausgabe der „Internet Official Protocol Standards" für den Standardisierungszustand und -status dieses Protokolls. RFC 822 und STD 3, RFC 1123 liefern auch wichtigen Hintergrund für MIME, da keine konforme MIME-Implementierung diese verletzen kann. Darüber hinaus sind mehrere andere informative RFC-Dokumente auch für MIME-Implementierer wertvoll, insbesondere RFC 1344, RFC 1345 und RFC 1524.

Terminologie:

User Agent (UA) (Benutzeragent): Ein Programm, mit dem menschliche Benutzer Mail senden und empfangen
MIME: Multipurpose Internet Mail Extensions (Mehrzweck-Internet-Mail-Erweiterungen)
kanonische Form: Die native Darstellung von Daten
Medientyp: Der allgemeine Datentyp
Untertyp: Ein spezifisches Format innerhalb eines Medientyps
Kodierungstransformation: Eine Umwandlung, die auf Daten für die Übertragung angewendet wird

Schlüsselkonzepte:

RFC 822-Einschränkungen: Unterstützt nur 7-Bit-US-ASCII-Text
MIME-Ziele: Unterstützung für Multimedia, mehrere Zeichensätze, nicht-textuellen Inhalt
Kompatibilität zuerst: MIME-Design bewahrt Abwärtskompatibilität mit RFC 822