Skip to Content.
Sympa Menu

public-l - Re: [DENICpublic-l] IDNA-Kollisionen

public-l AT list.denic.de

Subject: Public DENIC mailinglist

List archive

Re: [DENICpublic-l] IDNA-Kollisionen


Chronological Thread 
  • From: Florian Weimer <fw AT deneb.enyo.de>
  • To: DENIC Presse <presse AT denic.de>
  • Cc: public-l AT denic.de
  • Subject: Re: [DENICpublic-l] IDNA-Kollisionen
  • Date: Thu, 10 Nov 2016 10:24:45 +0100

Sehr geehrte Frau Knauf-Hochvárt,

vielen Dank für Ihre Antwort.

> Durch IDNA2008 (RFC 5890-5893) wurde IDNA2003 obsolet. Aus
> technischer Sicht ist der Standard IDNA2003 veraltet und
> problematisch und sollte nicht eingesetzt werden.
>
> Als 2010 der neue Standard IDNA2008 verabschiedet und damit „ß“ als
> selbständiges Zeichen eingeführt wurde,

Das ist eine vereinfachte Darstellung. IDNA2008 läßt offen, wie die
Mapping-Phase nach Unicode umgesetzt wird.

Unicode definiert einen Standard dafür:

<http://www.unicode.org/reports/tr46/>

Dieser spricht von einer “transitional period” die (Stand Juni 2016)
offenbar immer noch nicht abgeschlossen ist. Während dieser
“transitional period” wird in der Mapping-Phase »ß« zu »ss« umgesetzt.
Laut o.g. Unicode-Standard (UTS #46) betrifft dieses Problem aber
längst nicht nur »ß« und »ς«, sondern auch “extremely common
characters, such as all uppercase characters, all halfwidth or
fullwidth characters (commonly used in Japan, China, and Korea)”.

Auf Software-Seite haben wir nun das Problem, daß Unterstützung für
IDNA2008 derzeit minimal ist (insbesondere im Vergleich zu
IDNA2003). Nachgefragt wird zudem auch nicht Unterstützung für
IDNA2008 an sich, sondern IDNA2008 in Verbindung mit UTS #46, wo das
Schicksal des »ß« zumindest unklar ist (vermutlich ist die Erwartung
der Autoren, daß es noch immer als »ss« umgesetzt wird, weil wir noch
in der “transitional period” sind).

Etwas mehr Hintergrundinformation gibt es hier:

<https://bugzilla.mozilla.org/show_bug.cgi?id=1218179>

Was fehlt, sind Kommentare von den ebenfalls betroffenen Registries in
Fernost (die mit den “extremely common characters”).

Die Frage ist, warum UTS #46 nicht angepaßt wurde. Auf Software-Seite
wäre es einfacher, wenn IDNA2003 auf IETF-Seite als HISTORIC
gekennzeichnet würde, und wenn die “transitional period” aus UTS #46
entfernt würde.

Mit freundlichem Gruß
Florian Weimer

____________________________________
Mailinglist-Managenment:
http://mailinglists.denic.de/mailman/listinfo/public-l


Archive powered by MHonArc 2.6.19.

Top of Page