Zusammenfassung

  • Der geplante Nachfolger von RFC 7451 fordert eine großzügige Prüfung, sobald mindestens ein Registry/Registrar- oder Server/Client-Paar eine EPP-Erweiterung implementiert und eingesetzt hat. Mehrere Erweiterungen mit gleicher oder ähnlicher Funktion dürfen registriert werden; Ähnlichkeit allein begründet keine Ablehnung.
  • Ein Registereintrag belegt eine dauerhafte Spezifikation, eine technische Kennung und einen nachvollziehbaren Prüfweg. Er kürt keinen bevorzugten Entwurf, verleiht keinen Standards-Track-Status, misst keine breite Verbreitung und beweist keine Austauschbarkeit in einer konkreten Umgebung.
  • Im laufenden IANA-Register ist Koexistenz bereits sichtbar: COREs IDN- und Datenschutz-Erweiterungen werden als syntaktisch und funktional identisch mit den jeweiligen TANGO-Erweiterungen beschrieben, verwenden aber andere XML-Namensräume. Für Entscheidungen braucht es daher eine Koexistenzkarte statt einer Rangliste.

Technische Register erzeugen Autorität durch ihre Form. Eine geordnete Zeile mit Namen, Referenz und Status sieht nach abgeschlossener Auswahl aus. Wer zwei Zeilen mit ähnlicher Funktion findet, vermutet einen Übergang: Die eine müsse der veraltete Kandidat, die andere der Gewinner sein.

Beim EPP Extension Registry ist diese Lesart falsch. EPP wurde so angelegt, dass Registries, Registrare und ihre Dienstleister den Grundbestand an Befehlen und Objektabbildungen erweitern können. Solche Mechanismen entstehen in unterschiedlichen Geschäftsbeziehungen und zu unterschiedlichen Zeiten. Das öffentliche Register macht die Kennungen auffindbar und verhindert, dass dokumentationslose Dialekte den gemeinsamen Raum besetzen. Es entscheidet nicht nachträglich, welche Entwicklungslinie hätte gewinnen sollen.

draft-ietf-regext-ext-registry-epp-10 zieht diese Grenze ausdrücklich. Die am 17. August 2026 veröffentlichte Fassung erlaubt mehrere Erweiterungen mit derselben oder einer ähnlichen Funktion. Ein im Übrigen gültiger Antrag soll nicht allein wegen dieser Ähnlichkeit scheitern. Ist eine Erweiterung von mindestens einem Registry/Registrar- oder Server/Client-Paar implementiert und eingesetzt, sollen die benannten Fachleute großzügig urteilen.

Damit ist Wirklichkeit nachgewiesen, nicht Vorrang.

Ein Paar ist ein Existenzbeleg

EPP ist ein Protokoll zwischen Gegenstellen. Eine Serverfunktion ohne verstehenden Client führt keinen Vorgang aus; ein vorbereiteter Client ohne akzeptierenden Server ebenso wenig. Ein funktionierendes Paar ist deshalb ein sinnvoller Mindestbeleg. Die Spezifikation hat nicht nur eine Kennung beansprucht, sondern eine reale Protokollgrenze überwunden.

Mehr lässt sich daraus nicht ohne weitere Daten ableiten. Das Paar sagt nichts über den Anteil unterstützender Registrare, Transaktionsvolumen, Fehlerquoten, Softwarevielfalt oder die Nutzung in sämtlichen genannten TLDs. Auch ein Client kann bei verschiedenen Registry-Verbindungen unterschiedliche Versionen oder optionale Felder handhaben.

Der Status „Active“ ist ebenfalls kein Marktindikator. Im Entwurf bedeutet er, dass die Erweiterung implementiert und in Gebrauch ist. „Inactive“ steht für fehlende Implementierung oder Nutzung beziehungsweise für eine nicht mehr verfügbare Spezifikation. Das Register zählt weder Installationen noch Reichweite. Wer Active als „branchenweit unterstützt“ wiedergibt, ergänzt eine Behauptung, für die das Register keine Messung besitzt.

Die TLD-Spalte grenzt einen erklärten Geltungsbereich ein, ersetzt aber keine Kompatibilitätsmatrix. Sie nennt keine Server- und Client-Versionen, keine Pflicht- oder Wahlfunktion und keine Übersetzungsbrücke zwischen Namensräumen. Registrierung liefert die Adresse; Einsatzdaten zeigen, ob der Weg in der eigenen Umgebung befahrbar ist.

„Specification Required“ schafft nachvollziehbare Namen

Die in RFC 8126 beschriebene Richtlinie „Specification Required“ verlangt eine dauerhafte, öffentlich zugängliche Spezifikation und eine Prüfung durch benannte Fachleute. Der neue Entwurf lässt RFCs sowie langfristig leicht verfügbare proprietäre Spezifikationen zu; eine englische Fassung ist erforderlich. Ein gewöhnlicher Internet-Draft gilt für künftige Registrierungen nicht als dauerhafte Referenz, und das Early-Allocation-Verfahren aus RFC 7120 findet keine Anwendung.

Diese Anforderungen halten den Namensraum erklärbar. Findet ein Entwickler Jahre später einen XML-Namensraum in einem Protokollmitschnitt, soll er dessen beabsichtigte Bedeutung noch ermitteln können. Deshalb führt die Tabelle Name, Dokumentstatus, Referenz, Anmelder, TLDs, IPR-Angaben, Aktivitätsstatus und Hinweise.

Die fachliche Prüfung betrachtet architektonische Tragfähigkeit, Datenschutzdokumentation, Syntax und Semantik von URIs sowie die korrekte Wahl von IETF- oder Nicht-IETF-Namensräumen. Normalerweise entscheidet ein hauptverantwortlicher Experte. Ist er nicht verfügbar, handelt ein Ersatzgremium und bildet einen Konsens mit einfacher Mehrheit. Wer einen Interessenkonflikt wahrnimmt, muss zurücktreten; die REGEXT-Mailingliste kann schwierige Fragen öffentlich behandeln.

Das ist mehr als Formularprüfung, aber weniger als ein Wettbewerb. Die Experten dürfen unzureichende Dokumentation oder technische Mängel beanstanden. Sie sollen weder Marktanteile bewerten noch den elegantesten Anbieter auswählen. Der Eintrag beantwortet „Worauf verweist diese Kennung?“, nicht „Welche Lösung soll jeder verwenden?“.

Auch das neue Regelwerk ist noch nicht endgültig. Revision 10 ist ein aktiver Internet-Draft mit dem vorgesehenen Status Best Current Practice, beim IESG eingereicht und in der RFC-Editor-Warteschlange vor der Zuweisung eines Editors. Nach Genehmigung und Veröffentlichung würde es RFC 7451 ablösen. Bis dahin wäre die Bezeichnung als geltender RFC eine unzulässige Vorwegnahme.

CORE und TANGO sind absichtlich getrennt sichtbar

Das am 4. September 2026 aktualisierte IANA-Register enthält Standards-Track- und „Other“-Dokumente sowie aktive und inaktive Einträge. Seine Hinweise zu CORE und TANGO machen die abstrakte Regel greifbar.

COREs IDN-Erweiterung wird als syntaktisch und funktional identisch mit dem TANGO-Gegenstück beschrieben, verwendet jedoch einen anderen XML-Namensraum. Dasselbe Verhältnis vermerkt die Tabelle bei den Datenschutz-Erweiterungen beider Familien.

Der andere Namensraum ist keine Dekoration. Er gehört zur Identität der Nachricht. Ein Client, der Elemente im TANGO-Namensraum erzeugt, kann nicht allein wegen ähnlicher Schemata davon ausgehen, dass ein CORE-Server sie versteht. Server können eine, beide oder keine Variante anbieten. Testverfahren, Versionsrhythmen und Zuständigkeiten können auseinanderlaufen.

Der Hinweis „funktional identisch“ ist eine starke, aber begrenzte Aussage. Er verspricht nicht automatisch Gleichheit jeder optionalen Eigenschaft, jeder Fehlersituation und jeder späteren Fassung. Er erklärt auch nicht die Entstehung der beiden Linien. Historische Reihenfolge, getrennte Gemeinschaften, Verträge, bereits installierte Systeme oder Änderungshoheit können die Koexistenz tragen.

Das Löschen einer Zeile würde diese Gründe nicht beseitigen. Alte Software und Protokollaufzeichnungen behielten den entfernten Namensraum, hätten aber weniger Erklärung. Zwei sichtbare Einträge können daher eine Voraussetzung geordneter Migration sein, nicht deren Hindernis.

Eine Koexistenzkarte für betriebliche Aussagen

Das IANA-Register bleibt maßgeblich für die Registrierung. Für Auswahl und Migration braucht ein Betreiber jedoch eine ergänzende Sicht. Ich nenne sie Koexistenzkarte. Sie ist ein analytischer Vorschlag dieses Artikels, keine Forderung des IETF-Entwurfs oder der IANA.

Die Karte gruppiert Erweiterungen zunächst nach dauerhafter Funktion — etwa IDN, Datenschutz, Startphase oder Gebühren —, ohne die Kennungen zu verschmelzen. Daneben stehen XML-Namensraum, Spezifikationsfassung und betroffene Befehle. Ein eigener Herkunftsblock hält dauerhafte Referenz, Dokumentstatus, Anmelder, Datum und Prüfweg fest.

Einsatznachweise nennen das konkrete Server/Client-Paar, Software, Version, TLD und Zeitpunkt. Ein einzelnes Paar bleibt sprachlich ein einzelnes Paar. Überlappungen erhalten eine Quellenangabe: stammt die Gleichheitsaussage von den Anmeldern, aus einem IANA-Hinweis, einem Schemavergleich, einem Konformitätstest oder aus Produktionserfahrung? Und auf welche Operationen erstreckt sie sich?

Eine weitere Ebene zeigt gegenwärtige Server- und Client-Unterstützung sowie Übersetzungen zwischen Namensräumen. Für jede Brücke müssen Verantwortung und Informationsverluste erkennbar sein. Schließlich braucht die Karte eine Zeitleiste der Status-, Referenz- und Hinweisänderungen.

So bleiben vier Sätze getrennt: registriert; irgendwo eingesetzt; hier unterstützt; in diesem Fall gegen eine andere Erweiterung austauschbar. Die erste Aussage folgt direkt aus dem Register. Die übrigen benötigen jeweils eigene Belege.

Entfernung kann den Rückweg abschneiden

Der Entwurf unterscheidet Eintragung, Änderung, Deaktivierung und Entfernung. Ein Statuswechsel braucht eine Begründung. Für die Entfernung eines durch IETF-Konsens entstandenen Eintrags ist die Zustimmung des IESG nötig. Nicht-IETF-Einträge können vom IESG oder vom ursprünglichen Anmelder zusammen mit den Experten entfernt oder deaktiviert werden.

Zugleich räumt der Text ein, dass das Register keinen Verlaufsmechanismus besitzt. Nach einer Entfernung lässt sich der gelöschte Eintrag dort nicht mehr verfolgen. Damit wird eine vermeintliche Aufräumhandlung zur Entscheidung über Beweiserhalt.

Inactive warnt vor neuer Abhängigkeit und behält dennoch eine Koordinate für alte Systeme. Entfernung nimmt diese Koordinate aus der aktuellen Tabelle. Verschwindet zusätzlich die Spezifikation, kann ein späteres Team nicht mehr erkennen, ob ein XML-Element zu einer legitimen Alt-Erweiterung, einer falschen Version oder einem lokalen Sonderweg gehörte.

Das aktuelle Register koordiniert die Gegenwart. Datierte Abbilder erhalten die Vergangenheit. Fehlt Letzteres, erkauft die übersichtlichere Tabelle von heute die schlechtere Fehleranalyse von morgen.

Quellen