Zusammenfassung

  • ICANN nutzt zwei getrennte Kontrollen: ASCII-Strings aus einem oder zwei Buchstaben sind bereits bei der Einreichung unzulässig. Ein beantragter Zwei-Zeichen-String oder eine seiner Varianten kann später zusätzlich scheitern, wenn das Panel ihn als visuell ähnlich zu einem Zwei-Zeichen-ASCII-String oder dessen Variante einstuft.
  • Das SSE-Werkzeug übernimmt die Vorauswahl, nicht die abschließende Entscheidung. Ein prüfbarer Bescheid sollte das ausschlaggebende Labelpaar, Schrift und Groß-/Kleinschreibung, ausgelassene Vergleiche, die Begründung des Panels und die 21-tägige Anfechtungsfrist offenlegen.

Der komplizierte Fall beginnt nicht bei jemandem, der schlicht zwei ASCII-Buchstaben eingibt. Dafür gibt es eine unmittelbare Sperre im Einreichungssystem. Schwieriger ist der Antrag eines IDN-Labels aus zwei Zeichen, das die technischen Regeln erfüllt und keinen Zwei-Buchstaben-Ländercode wörtlich übernimmt.

Der Applicant Guidebook für die Runde 2026 zieht eine zweite Grenze. In der String Similarity Evaluation werden der primäre String und seine Varianten mit einem Vergleichsuniversum abgeglichen, das sämtliche Zwei-Zeichen-ASCII-Strings und deren Varianten umfasst. Wird ein beantragter Zwei-Zeichen-String oder eine seiner Varianten als ähnlich eingestuft, kann der Antrag nicht fortgesetzt werden.

Beide Grenzen dürfen nicht unter dem Sammelbegriff „gesperrter Name“ verschwinden. Die erste prüft Identität und Zulässigkeit. Die zweite verlangt ein Urteil über die visuelle Ähnlichkeit unterschiedlicher Labels. Dementsprechend unterscheiden sich Beweise, Fehlerquellen und Anfechtungsgründe.

Die erste Schranke ist ein direkter Abgleich

Abschnitt 7.2.1 des Guidebooks führt alle übrigen ASCII-Strings aus einem oder zwei Buchstaben unter den nicht beantragbaren Strings. Die aktuelle ICANN-FAQ nennt dieselbe Kategorie. Nach Abschnitt 7.2.1.1 prüft das Einreichungssystem den gewählten String automatisch. Fällt er in die einschlägige Sperrkategorie, muss der Antragsteller einen anderen String wählen.

Der Nachweis ist überschaubar: Eingabewert, normalisierte Form, getroffene Kategorie, Version der Liste und Zeitpunkt der Prüfung. Eine Wahrnehmungs- oder Schriftbeurteilung ist für einen exakten Treffer nicht nötig.

Bei der zweiten Schranke lautet die Frage anders. Ein Nicht-ASCII-Label kann sich formal von jedem Zwei-Zeichen-ASCII-String unterscheiden und dennoch im String Similarity Evaluation als visuell ähnlich zu einem solchen String oder dessen Variante gelten. Auch eine Variante kann die maßgebliche Beziehung erzeugen.

Der Bescheid sollte zuerst angeben, welche Schranke gegriffen hat. Andernfalls weiß der Antragsteller nicht, ob er Normalisierung, Listenzuordnung, Variantenbeziehung, Darstellung oder Panelurteil prüfen muss.

Die entscheidende Kante kann von einer Variante stammen

Die SSE beschränkt sich nicht auf das primäre Label. Abschnitt 7.10.1 bezieht den primären String, zuteilbare Varianten und unter den vorgesehenen Bedingungen gesperrte Varianten ein. Für die hier untersuchte Beziehung belegt das eingefrorene Faktenpaket den Vergleich mit allen Zwei-Zeichen-ASCII-Strings samt Varianten.

Damit kann die ausschlaggebende Beziehung zwischen zwei Primärlabels, zwischen Primärlabel und Variante oder zwischen zwei Varianten liegen. Abschnitt 7.10.3 bestimmt zudem, dass alle Mitglieder eines variant-string-set dasselbe SSE-Ergebnis teilen. Eine einzelne Ähnlichkeitskante kann folglich die Konsequenz auf den gesamten Antrag übertragen.

Die Formulierung „ähnlich zu einem Zwei-Zeichen-ASCII-String“ ist deshalb zu dünn. Veröffentlicht werden sollten mindestens:

  1. das konkrete primäre oder Variantenpaar;
  2. A-label, U-label und Unicode-Codepunkte beider Seiten;
  3. Schrift, Groß-/Kleinschreibung und Variantenbeziehung;
  4. Ähnlichkeitskategorie und angewandte Leitlinie; sowie
  5. die Mitglieder des Variantensatzes, die das Ergebnis erben.

Diese Liste ist eine redaktionelle Governance-Empfehlung für eine rekonstruierbare Spur, keine Beschreibung der Felder, die ICANN veröffentlichen wird. Das Paket belegt kein Veröffentlichungsformat für ein individuelles Ergebnis der Runde 2026.

Die SSE-Daten vom Juli 2026 zeigen die Grenzen einfacher Zeichenvergleiche

Am 23. Juli 2026 veröffentlichte ICANN Version 1.0 der SSE Data und SSE Guidelines. Schriftexperten verglichen Elemente innerhalb einer Schrift, mit verwandten Schriften und mit ASCII-Zeichen in Groß- und Kleinschreibung. Variantenbeziehungen aus der RZ-LGR wurden integriert, damit das Werkzeug potenzielle Ähnlichkeitsmengen bilden kann.

Im ASCII-Abschnitt dokumentiert ICANN unter anderem Beziehungen zwischen i und l, m und rn, n und ri sowie vv und w. Ihre Stärke ist nicht einheitlich. Einige beruhen auf unmittelbarer Expertenklassifikation, andere gelangen über Variantenintegration oder Transitivität in eine Menge. Auch eine Großschreibung kann Ähnlichkeit erzeugen, die in Kleinbuchstaben weniger ausgeprägt ist.

Diese Paare sind methodische Beispiele, keine realen Anträge der Runde 2026. Das Faktenpaket dieses Artikels enthält weder ein antragsbezogenes SSE-Ergebnis noch Fehlalarm-, Anfechtungs- oder Aufhebungsquoten. Ein Beispiel aus einer technischen Dokumentation darf nicht als bereits erfolgte Ablehnung dargestellt werden.

Die Beispiele belegen jedoch, warum die tatsächlich bewertete Darstellung erhalten bleiben muss. Das Wort „ähnlich“ oder ein einzelner Score zeigt nicht, ob die Beziehung aus direkter Formähnlichkeit, Großschreibung, einer formalen Variante oder einer transitiv erzeugten Vorauswahl stammt.

Das Werkzeug sortiert vor, das Panel entscheidet

Die SSE Guidelines vom Juli 2026 weisen dem Werkzeug eine begrenzte Rolle zu. Es erstellt potenzielle Mengen und einen Bericht. Das Panel kann Mengen hinzufügen, verändern oder entfernen, muss dies jedoch begründen. Ein String, der im Werkzeugbericht fehlt, gilt nicht automatisch als freigegeben; er und seine Varianten müssen manuell überprüft werden.

Die belegte Arbeitsteilung ist enger: Das Werkzeug liefert Vorauswahldaten, das Panel kann Mengen mit Begründung ändern und muss Strings außerhalb des Berichts manuell prüfen. Das Paket trifft keine zusätzliche Aussage über die fachliche Zusammensetzung des Panels und schreibt keinen Darstellungskontext-Test für Einzelergebnisse vor.

Der veröffentlichte Datensatz sollte beide Stufen verbinden: Hat das Werkzeug das Paar gefunden? Welche Kategorie schlug es vor? Wie entschied das Panel? Warum wich es gegebenenfalls ab? Ein Score ohne zugrunde liegendes Paar ist keine Begründung. Ein menschliches Ergebnis ohne angewandte Leitlinie ist ebenfalls nicht nachprüfbar.

Die Guidelines erlauben, bestimmte Vergleiche gesperrter Varianten auszulassen, wenn die Verwechslungsgefahr zwischen Schriften offenkundig gering ist. Das vermeidet nutzlose Arbeit, ist aber selbst eine Entscheidung. Der Bescheid sollte den ausgelassenen Vergleich, das Kriterium und die verantwortliche Freigabe nennen.

Zwei Beziehungen haben in derselben Kategorie zwei Folgen

Tabelle 7-5 unterscheidet die Folgen. Ist der beantragte String identisch mit einem Zwei-Zeichen-ASCII-String oder dessen Variante, wird der Antrag nicht angenommen. Ist er visuell ähnlich, aber keine Variante, darf er nicht fortfahren.

Der Unterschied sollte getrennt erfasst werden, weil Identität oder formale Variantenstellung nicht derselbe Befund wie visuelle Ähnlichkeit ist, obwohl beide den Antrag in dieser Kategorie stoppen. ICANNs Glossar beschreibt die Kategorie als potenziellen Raum künftiger ccTLDs; das eingefrorene Paket leitet daraus kein weiteres Verfahren ab.

Diese Programmbeschreibung begründet kein Eigentum. Die Quellen beweisen nicht, dass ICANN, die ISO-3166 Maintenance Agency oder ein Staat einen Zwei-Buchstaben-Code als Vermögenswert besitzt. Der Guidebook regelt das gTLD-Verfahren; weitergehende Souveränitäts- oder Eigentumsthesen entscheidet er nicht.

Eine Frist von 21 Tagen braucht vom ersten Tag an verwertbare Gründe

Ein Antragsteller kann das SSE-Ergebnis innerhalb von 21 Tagen nach Erhalt wegen eines tatsächlichen, verfahrensbezogenen oder systemischen Fehlers anfechten. Wird ein Fehler bestätigt, erfolgt eine Neubewertung unter Berücksichtigung der Anfechtungsfeststellungen. Andernfalls bleibt das ursprüngliche Ergebnis bestehen.

Eine kurze Frist funktioniert nur, wenn die Begründung mit dem Bescheid eintrifft. Der Antragsteller sollte nicht erst während der 21 Tage herausfinden müssen, welche Variante verglichen wurde, welche Schreibweise dargestellt war oder ob das Panel ein vom Werkzeug nicht erkanntes Paar ergänzte.

Der Mindestdatensatz sollte enthalten:

  1. die ausgelöste Kontrolle – Direktsperre oder Ähnlichkeitsbewertung;
  2. das konkrete Primär- oder Variantenpaar;
  3. normalisierte Formen, A-labels, U-labels, Codepunkte, Schriften und Groß-/Kleinschreibung;
  4. Ähnlichkeitskategorie und angewandte Leitlinie;
  5. Vorauswahlergebnis und jede Änderung des Panels;
  6. ausgelassene Vergleiche mit Begründung geringer Verwechslungsgefahr;
  7. die Wirkung auf das gesamte variant-string-set; und
  8. Übermittlungszeit, Anfechtungsfrist und stabile Ergebnis-ID.

Diese Liste ist eine redaktionelle Governance-Empfehlung, keine ICANN-Feststellung. Sie wendet die Heng-Lu-Doktrin als normative Perspektive an: Eine Kontrolle, die einen Antrag beenden kann, sollte eine rekonstruierbare Spur von Regel, Beweisen, Vergleichskante, Gründen, Entscheider und Rechtsbehelf hinterlassen. Die Doktrin beweist weder einen ICANN-Fehler noch einen Fehlalarm oder eine spätere Ergebnisänderung.

Die Zwei-Zeichen-ASCII-Schranke kann eine verständliche Grenze im DNS-Root schützen, ohne zur Blackbox zu werden. Dazu muss der Datensatz zwei Vorgänge auseinanderhalten: Ein kurzer ASCII-String kann bei der Einreichung gesperrt werden; ein anderes Zwei-Zeichen-Label oder seine Variante kann später aufgrund eines begründeten visuellen Urteils ausscheiden. Wenn ICANN die ausgelöste Schranke und das entscheidende Paar veröffentlicht, lässt sich die Regel prüfen, ohne das Werkzeug zum Richter zu machen.

Quellen