3. Änderungen an den Nachrichtenkopffeldern
Um Nicht-ASCII-Unicode-Zeichen in Feldwerten zu ermöglichen, wird die Header-Definition in [RFC5322] erweitert, um das neue Format zu unterstützen. Die folgenden Abschnitte spezifizieren die erforderlichen Änderungen an der ABNF von RFC 5322.
Die unten nicht erwähnten Syntaxregeln bleiben wie in [RFC5322] definiert.
Beachten Sie, dass dieses Protokoll die Regeln in RFC 5322 zur Definition von Header-Feldnamen nicht ändert. Die Bodies von Header-Feldern dürfen Unicode-Zeichen enthalten, die Header-Feldnamen selbst müssen jedoch ausschließlich aus ASCII-Zeichen bestehen.
Beachten Sie außerdem, dass Nachrichten in diesem Format die Verwendung der SMTPUTF8-Erweiterung [RFC6531] erfordern, um über SMTP übertragen zu werden.
3.1. UTF-8-Syntax und Normalisierung
UTF-8-Zeichen können in Bezug auf Oktette mithilfe der folgenden ABNF [RFC5234] definiert werden, die aus [RFC3629] übernommen wurde:
UTF8-non-ascii = UTF8-2 / UTF8-3 / UTF8-4
UTF8-2 = <Defined in Section 4 of RFC3629>
UTF8-3 = <Defined in Section 4 of RFC3629>
UTF8-4 = <Defined in Section 4 of RFC3629>
Siehe [RFC5198] für eine Erörterung der Unicode-Normalisierung; die Normalisierungsform NFC [UNF] sollte (SHOULD) verwendet werden. Wenn man Internationalisierung richtig betreibt, ist eines der am häufigsten genannten Ziele tatsächlich, Menschen zu ermöglichen, ihre Namen korrekt zu schreiben. Da viele lokale Teile von Mailboxen Personennamen widerspiegeln, gilt dieses Prinzip auch für Mailboxen. Die Normalisierungsform NFKC [UNF] sollte nicht (SHOULD NOT) verwendet werden, da sie Informationen verlieren kann, die benötigt werden, um einige Namen unter bestimmten ungewöhnlichen Umständen korrekt zu schreiben.
3.2. Syntaxerweiterungen zu RFC 5322
Die folgenden Regeln erweitern die in [RFC5322] und [RFC5234] definierte ABNF-Syntax, um UTF-8-Inhalte zu ermöglichen.
VCHAR =/ UTF8-non-ascii
ctext =/ UTF8-non-ascii
atext =/ UTF8-non-ascii
qtext =/ UTF8-non-ascii
text =/ UTF8-non-ascii
; note that this upgrades the body to UTF-8
dtext =/ UTF8-non-ascii
Die vorstehenden Änderungen bedeuten, dass die folgenden Konstrukte nun UTF-8 zulassen:
-
Unstrukturierter Text (unstructured text), der in Header-Feldern wie "Subject:" oder "Content-description:" verwendet wird.
-
Jedes Konstrukt, das Atome verwendet, einschließlich, aber nicht beschränkt auf die lokalen Teile von Adressen und Message-IDs. Dies umfasst Adressen in den "for"-Klauseln von "Received:"-Header-Feldern.
-
Zeichenketten in Anführungszeichen (quoted strings).
-
Domains.
Beachten Sie, dass Header-Feldnamen nicht in dieser Liste enthalten sind; diese sind weiterhin auf ASCII beschränkt.
3.3. Verwendung von 8-Bit-UTF-8 in Message-IDs
Implementierer von Message-ID-Generierungsalgorithmen können (MAY) es vorziehen, ihre Ausgabe auf ASCII zu beschränken, da dies einige Vorteile bietet, etwa beim Aufbau der Header-Felder "In-reply-to:" und "References:" in Mailinglisten-Threads, in denen einige Absender internationalisierte Adressen verwenden und andere nicht.
3.4. Auswirkungen auf Zeilenlängenbeschränkungen
Abschnitt 2.1.1 von [RFC5322] begrenzt Zeilen auf 998 Zeichen und empfiehlt, die Zeilen auf nur 78 Zeichen zu beschränken. Diese Spezifikation ändert die erstgenannte Grenze auf 998 Oktette. (Beachten Sie, dass in ASCII Oktette und Zeichen praktisch identisch sind, was in UTF-8 jedoch nicht gilt.) Die Grenze von 78 Zeichen bleibt in Zeichen und nicht in Oktetten definiert, da sie Anzeigebreitenprobleme und nicht Zeilenlängenprobleme adressieren soll.
3.5. Änderungen der MIME-Nachrichtentyp-Kodierungsbeschränkungen
Diese Spezifikation aktualisiert Abschnitt 6.4 von [RFC2045]. [RFC2045] verbietet die Anwendung eines Content-Transfer-Encoding auf beliebige Untertypen von "message/". Diese Spezifikation lockert diese Regel -- sie erlaubt neu definierten MIME-Typen, Content-Transfer-Encoding zuzulassen, und sie erlaubt Content-Transfer-Encoding für message/global (siehe Abschnitt 3.7).
Hintergrund: Normalerweise erfolgt die Übertragung von message/global in 8-bit-clean-Kanälen, und Body-Teile haben "identity"-Kodierungen, das heißt, es ist keine Dekodierung erforderlich.
In dem Fall jedoch, in dem eine Nachricht, die ein message/global enthält, wie in [RFC6152] beschrieben von 8-Bit auf 7-Bit herabgestuft wird, muss möglicherweise eine Kodierung auf die Nachricht angewendet werden. Wenn die Nachricht mehrfach zwischen einer 7-Bit-Umgebung und einer Umgebung, die diese Erweiterungen implementiert, hin- und herreist, können mehrere Kodierungsebenen auftreten. Dies dürfte in der Praxis selten zu beobachten sein, und die potenzielle Komplexität anderer Vorgehensweisen zur Behandlung des Problems wird als größer angesehen als die Komplexität, verschachtelte Kodierungen bei Bedarf zuzulassen.
3.6. Verwendung von MIME Encoded-Words
Die MIME-Encoded-Words-Einrichtung [RFC2047] bietet die Möglichkeit, Nicht-ASCII-Text zu platzieren, jedoch nur in einer Teilmenge der von dieser Erweiterung zugelassenen Stellen. Darüber hinaus sind Encoded-Words wesentlich komplexer, da sie die Verwendung beliebiger Zeichensätze erlauben. Dementsprechend sollten (SHOULD NOT) Encoded-Words nicht verwendet werden, wenn Header-Felder für Nachrichten erzeugt werden, die diese Erweiterung einsetzen. Agenten können (MAY), wenn sie Material aus einer anderen Nachricht übernehmen, die Verwendung von Encoded-Words in die direkte Verwendung von UTF-8 umwandeln.
Beachten Sie, dass beim Dekodieren von Encoded-Words Sorgfalt geboten ist, da die Ergebnisse nach dem Ersetzen eines Encoded-Word durch sein dekodiertes UTF-8-Äquivalent syntaktisch ungültig sein können. Prozessoren, die sich dafür entscheiden, Encoded-Words zu dekodieren, dürfen (MUST NOT) keine syntaktisch ungültigen Felder erzeugen.
3.7. Der Medientyp message/global
Internationalisierte Nachrichten in diesem Format dürfen (MUST) nur so übertragen werden, wie es durch [RFC6531] autorisiert ist, oder innerhalb einer Nicht-SMTP-Umgebung, die diese Nachrichten unterstützt. Eine Nachricht ist eine "message/global message", wenn:
-
sie 8-Bit-UTF-8-Header-Werte enthält, wie in diesem Dokument spezifiziert, oder
-
sie 8-Bit-UTF-8-Werte in den Header-Feldern von Body-Teilen enthält.
Der Inhalt eines message/global-Teils ist ansonsten mit dem eines message/rfc822-Teils identisch.
Wenn ein Objekt dieses Typs an ein reines 7-Bit-System gesendet wird, muss (MUST) ein geeignetes Content-Transfer-Encoding darauf angewendet werden. (Beachten Sie, dass ein MIME-konformes System, das message/global nicht erkennt, es gemäß Abschnitt 5.2.4 von [RFC2046] als "application/octet-stream" behandeln soll.)
Die Registrierung lautet wie folgt:
Type name: message
Subtype name: global
Required parameters: none
Optional parameters: none
Encoding considerations: Jedes Content-Transfer-Encoding ist zulässig. Die 8-Bit- oder Binär-Content-Transfer-Encodings werden empfohlen, wo sie zulässig sind.
Security considerations: Siehe Abschnitt 4.
Interoperability considerations: Dieser Medientyp bietet Funktionalität ähnlich dem Content-Typ message/rfc822 für E-Mail-Nachrichten mit internationalisierten E-Mail-Headern. Wenn solche Inhalte in eine andere Nachricht eingebettet oder darin zurückgegeben werden müssen, besteht im Allgemeinen die Möglichkeit, diesen Medientyp zu verwenden und den Inhalt unverändert zu lassen oder den Inhalt in message/rfc822 herunterzukonvertieren. Jede dieser Wahlmöglichkeiten interoperiert mit dem installierten Bestand, jedoch mit unterschiedlichen Eigenschaften. Systeme, die internationalisierte Header nicht kennen, behandeln einen message/global-Body-Teil typischerweise als unbekannten Anhang, während sie die Struktur eines message/rfc822 verstehen. Systeme, die message/global verstehen, bieten jedoch Funktionalität, die dem Ergebnis einer Herunterkonvertierung in message/rfc822 überlegen ist. Die interoperabelste Wahl hängt von der eingesetzten Software ab.
Published specification: RFC 6532
Applications that use this media type: SMTP-Server und E-Mail-Clients, die die Erzeugung oder Analyse von multipart/report unterstützen. E-Mail-Clients, die Nachrichten mit internationalisierten Headern als Anhänge weiterleiten.
Additional information:
Magic number(s): none
File extension(s): Die Erweiterung ".u8msg" wird vorgeschlagen.
Macintosh file type code(s): Ein Uniform Type Identifier (UTI) "public.utf8-email-message" wird vorgeschlagen. Dieser entspricht "public.message" und "public.composite-content", entspricht aber nicht notwendigerweise "public.utf8-plain-text".
Person & email address to contact for further information: Siehe den Abschnitt "Adressen der Autoren" in diesem Dokument.
Intended usage: COMMON
Restrictions on usage: Dies ist ein strukturierter Medientyp, der andere MIME-Medientypen einbettet. Ein 8-Bit- oder Binär-Content-Transfer-Encoding sollte (SHOULD) verwendet werden, sofern dieser Medientyp nicht über einen reinen 7-Bit-Transport gesendet wird.
Author: Siehe den Abschnitt "Adressen der Autoren" in diesem Dokument.
Change controller: IETF Standards Process