Zum Hauptinhalt springen

1. Einleitung

Um internationalisierte E-Mail-Adressen verwenden zu können, ist es erforderlich, sowohl den Domänenteil als auch den lokalen Teil von E-Mail-Adressen zu internationalisieren. Der Domänenteil von E-Mail-Adressen ist bereits internationalisiert [RFC5890], der lokale Teil hingegen nicht. Ohne die in diesem Dokument spezifizierten Erweiterungen ist der Postfachname auf eine Teilmenge von 7-Bit-ASCII [RFC5321] beschränkt. Obwohl MIME [RFC2045] den Transport von non-ASCII-Daten ermöglicht, bietet es keinen Mechanismus für internationalisierte E-Mail-Adressen. In RFC 2047 [RFC2047] definiert MIME einen Kodierungsmechanismus für einige spezifische Nachrichten-Header-Felder, um non-ASCII-Daten aufzunehmen. Er erlaubt jedoch nicht die Verwendung von E-Mail-Adressen, die non-ASCII-Zeichen enthalten. Ohne die hier definierten Erweiterungen oder einen gleichwertigen Satz besteht die einzige Möglichkeit, non-ASCII-Zeichen in irgendeinen Teil von E-Mail-Adressen aufzunehmen, darin, die RFC-2047-Kodierung zu verwenden, um sie in das einzubetten, was RFC 5322 [RFC5322] den "display name" (andernorts als "name phrase" oder mit anderen Begriffen bezeichnet) der betreffenden Header-Felder nennt. Informationen, die in den display name kodiert sind, sind im Nachrichtenumschlag unsichtbar und für viele Zwecke überhaupt nicht Teil der Adresse.

Dieses Dokument ist ein Ersatz für RFC 4952 [RFC4952]; es spiegelt zusätzliche Probleme, gemeinsame Terminologie und einige architektonische Änderungen wider, die seit der Veröffentlichung jenes Dokuments identifiziert wurden. Es macht jenes Dokument obsolet. Die experimentellen Beschreibungen des Downgradings während der Übertragung [RFC5504] [RFC5825] sind nun irrelevant und aufgrund der in Abschnitt 12 diskutierten Änderungen nicht mehr erforderlich. Der RFC Editor wird gebeten, alle drei dieser Dokumente in den Status Historic zu versetzen.

Die Pronomen "he" und "she" werden austauschbar verwendet, um einen Menschen unbestimmten Geschlechts zu bezeichnen.

Die Schlüsselwörter "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" und "OPTIONAL" in diesem Dokument sind so zu interpretieren, wie in BCP 14, RFC 2119 [RFC2119] beschrieben.