Zusammenfassung

  • ICANN führt ccPDP4 derzeit als Policy Recommendation Pending Board Action. Das ist weder eine angenommene Regel noch ein Umsetzungsprojekt oder eine Ankündigung der Ausmusterung einer bestimmten Zeichenfolge.
  • Der Endbericht behandelt eine eng umschriebene Änderung von ISO 3166-1 als Verfahrensauslöser, lässt die territoriale Vorfrage jedoch ausdrücklich außerhalb von IANA/ICANN.
  • Daniel Kade empfiehlt einen externen Auslöserbeleg, der Quelle, Vorschrift, Zeichenfolge und Varianten, zuständiges Organ, Überprüfung und Betriebsakt getrennt ausweist. Dies ist keine ICANN-Vorgabe.

Ein Bezugspunkt überträgt keine Hoheitsgewalt

Listen sind für technische Koordinierung nützlich, weil sie Arbeit teilen. ISO pflegt einen Referenzbestand; eine ccNSO-Politik kann bestimmen, welche begrenzte Folge ein darin verzeichnetes Ereignis in ihrem eigenen Verfahren hat. Weder wird ISO dadurch zur Wurzelzonenbetreiberin noch ICANN zur Instanz für territoriale Anerkennung.

Der Endbericht zeigt außerdem, warum „Auslöser“ nicht „Ergebnis“ bedeutet. Für einen Zusammenschluss nennt er Bedingungen, unter denen eine gewählte IDN-Zeichenfolge nicht ausgemustert werden sollte: Sie bleibt eine sinnvolle Darstellung in einer vorgesehenen Sprache und erhält Unterstützung Significantly Interested Parties. Die Regel einer Zeichenfolge je vorgesehener Sprache bleibt ebenfalls relevant. Diese Aussagen beschreiben einen Pfad; sie beweisen keinen aktuellen ISO-Wechsel, keine reale Ausmusterung und keinen Streit.

Die Vermischung der Ebenen würde ein Mandat erfinden. Eine technische Prüfung entscheidet nicht die externe Vorfrage. Unterstützung kann innerhalb eines genau bezeichneten Kriteriums Evidenz sein, aber keine Souveränitätsabstimmung. Eine IANA-Handlung kann eine autorisierte Folge sein, aber nicht den Tatsachenakt erzeugen, auf den sie reagiert. Teilnahme und Sachkenntnis sind nicht dasselbe wie Zuständigkeit.

Der gegenwärtige Status ist noch keine Entscheidung

Das ICANN-Inventar trennt ccPDP4 als ausstehende Board-Aktion von Umsetzungsprojekten. Öffentliche Unterlagen aus 2026 zeigen vier Klarstellungs- oder Auslegungsfragen eines Board Caucus an den ccNSO Council im Rahmen einer Umsetzbarkeitsprüfung. Der Council nahm im Juli eine Antwort an. Die Vorschau auf den Board-Workshop vom 2. September kündigte eine Diskussion der Empfehlungen an.

Jede dieser Tatsachen hat Gewicht und doch einen begrenzten Sinn. Eine Frage ist keine Annahme. Eine Council-Antwort ersetzt keinen Board-Beschluss. Eine Workshop-Agenda ist keine Resolution. Wer diese Stufen zusammenzieht, kann eine noch ausstehende Handlung als geltende Politik ausgeben.

Ein externer Auslöserbeleg

Daniel Kade schlägt einen externen Auslöserbeleg vor. Er soll die externe Stelle, Ausgabe, Wirksamkeitsdatum, Änderungskennung und Primärquelle nennen und klar markieren, dass dies keine ICANN-Feststellung ist. Er soll die konkrete ccPDP4-Klausel, Fassung und den Dokumentstatus nennen; Endbericht, angenommene Regel, Klarstellung und Umsetzungsverfahren dürfen nicht gleich heißen.

Der Beleg sollte die betroffene IDN-Zeichenfolge und Varianten begrenzen sowie mögliche Ausmusterung, Ausnahme, Überprüfung oder Umsetzung unterscheiden. Er sollte zeigen, welches Organ den nächsten Schritt verantwortet und was außerhalb seines Mandats bleibt. Board-Entscheidung, IANA-Anweisung und ausgeführter Vorgang müssen getrennte Datensätze mit Datum, Umfang und Korrekturweg sein.

Damit wird kein Territorialkonflikt in einem Formular entschieden und keine vertrauliche Kommunikation offen gelegt. Der Beleg verhindert nur, dass eine Koordinierungsinstitution sich Autorität von einer Liste, einer Konsultation oder einer späteren Ausführung leiht.

Warum dies bei IDN-Namen besonders zählt

Ein IDN-ccTLD ist nicht bloß ein austauschbarer Datenbankschlüssel. Er kann den Zugang in einer bestimmten Sprache und Schrift vermitteln. Eine knappe Statuszeile kann deshalb als Anerkennung oder Ausschluss gelesen werden, obwohl sie nur einen technischen Schritt meint. Kontinuität verlangt Handlung, wenn sie autorisiert ist; sie verlangt ebenso eine sichtbare Trennung von externer Prämisse, interner Regel, Entscheidung und Umsetzung.

Evidenzgrenzen

Dieser Artikel meldet keinen aktuellen ISO-3166-1-Wechsel, keine konkrete Ausmusterung, keinen Territorialstreit, keinen Board-Beschluss und keine IANA-Umsetzung. Er behauptet nicht, ccPDP4 sei angenommen. Der Beleg ist Daniel Kades redaktionelle Empfehlung, keine Weisung an ISO, ICANN, ccNSO oder IANA.

Quellen

  1. Final Report ccNSO PDP4 (de-)selection of IDNccTLDs
  2. ICANN policy implementation inventory
  3. PDP (de-)selection of IDN ccTLD Strings Working Group
  4. Questions Board Caucus IDNccPDP4
  5. Draft agenda ccNSO Council meeting 231
  6. Chair's Blog: September Board Workshop Preview
  7. ICANN Bylaws
  8. RFC 1591
  9. RFC 5890
  10. Heng Lu — The Multi-Stakeholder Mirage