3. Problembeschreibung

Internationalizing Domain Names in Applications (IDNA) [RFC5890] erlaubt internationalisierte Domänennamen, aber die Bereitstellung hat die meisten Benutzer noch nicht erreicht. Einer der Gründe dafür ist, dass wir noch keine vollständig internationalisierten Benennungsschemata haben. Domänennamen sind nur einer der verschiedenen Namen und Identifikatoren, die internationalisiert werden müssen. In vielen Kontexten haben internationalisierte Domänennamen allein wenig Wert, bis mehr dieser Identifikatoren internationalisiert sind.

E-Mail-Adressen sind Paradebeispiele dafür, warum es nicht ausreicht, nur den Domänennamen zu internationalisieren. Wie die meisten Beobachter aus Erfahrung gelernt haben, bevorzugen Benutzer stark E-Mail-Adressen, die Namen oder Initialen ähneln, gegenüber solchen mit scheinbar bedeutungslosen Buchstaben- oder Zahlenfolgen. Sofern nicht die gesamte E-Mail-Adresse vertraute Zeichen und Formate verwenden kann, werden Benutzer E-Mail als kulturell unfreundlich wahrnehmen. Wenn die in E-Mail-Adressen verwendeten Namen und Initialen in den Muttersprachen und Schriftsystemen der Benutzer ausgedrückt werden können, wird das Internet als natürlicher wahrgenommen, insbesondere von denen, deren Muttersprache nicht in einer Teilmenge einer vom Romanischen abgeleiteten Schrift geschrieben wird.

Die Internationalisierung von E-Mail-Adressen ist nicht nur eine Frage der Änderung des SMTP-Umschlags; oder der Modifizierung der Header-Felder "From:", "To:" und "Cc:"; oder der Erlaubnis für aufgerüstete Mail User Agents (MUAs), eine spezielle Kodierung zu dekodieren und durch Anzeige lokaler Zeichen zu reagieren. Um als nutzbar wahrgenommen zu werden, müssen die Adressen internationalisiert und in allen Kontexten, in denen sie vorkommen, konsistent behandelt werden. Diese Anforderung hat weitreichende Implikationen: Sammlungen von Patches und Workarounds sind nicht ausreichend. Selbst wenn sie ausreichend wären, kann ein auf Workarounds basierender Ansatz zu einer Vielfalt von Implementierungen mit unterschiedlichen Sätzen von Patches und Workarounds führen, mit der Folge, dass Benutzer verwirrt sind darüber, was tatsächlich nutzbar und unterstützt wird. Stattdessen müssen wir eine vollständig internationalisierte E-Mail-Umgebung aufbauen, mit dem Fokus darauf, eine effiziente Kommunikation zwischen denen zu ermöglichen, die eine Sprache und ein Schriftsystem teilen. Das wiederum impliziert Änderungen an der E-Mail-Header-Umgebung, um jenen Header-Feldern, die angemessen internationalisiert sind, die Nutzung des vollen Bereichs an Unicode-Zeichen zu ermöglichen, eine SMTP-Erweiterung, um UTF-8- [RFC3629] [RFC5198] E-Mail-Adressierung und die Zustellung jener erweiterten Header-Felder zu erlauben, Unterstützung für die Internationalisierung von Zustell- und Dienstbenachrichtigungen [RFC3461] [RFC3464] und (schließlich) eine Anforderung zur Unterstützung der 8BITMIME-SMTP-Erweiterung [RFC6152], damit all dies durch das E-Mail-System transportiert werden kann, ohne die Einschränkung überwinden zu müssen, dass Header-Felder keine content-transfer-encodings haben.