Zusammenfassung

  • Der IESG genehmigte am 17. August 2026 draft-ietf-regext-ext-registry-epp-10 zur Veröffentlichung als Best Current Practice. Das Verfahren verbessert Spezifikation, Prüfung und Pflege von EPP-Erweiterungen, macht den IANA-Katalog aber nicht zu einer universellen Server-Kompatibilitätsliste.
  • Active belegt Implementierung und Nutzung in mindestens einem Registry–Registrar- oder Server–Client-Paar. Ob ein bestimmter Server die URI ankündigt, ein Client sie aushandeln darf und eine Transaktion gelingt, muss getrennt nachgewiesen werden.

Der richtige Datensatz beantwortete die falsche Frage

Der Einstieg ist ein Gedankenfall, kein gemeldeter Ausfall eines TLD-Betreibers. Er zeigt, wie aus einer korrekten öffentlichen Beobachtung eine unzulässige Betriebsentscheidung werden kann.

Das IANA-Register dient der Koordination. Es nennt Erweiterung, dauerhafte Spezifikation, Registrant, erklärten TLD-Bereich, IPR-Angaben, Status und Hinweise. Dadurch werden bestehende Ansätze auffindbar, Namensraumkollisionen seltener und Zuständigkeiten sichtbarer.

Die Serverbegrüßung beschreibt dagegen das aktuelle Angebot eines Endpunkts: Protokollversionen, Sprachen, Objekt-URIs und optionale Erweiterungs-URIs. Der Login legt für einen identifizierten Client die ausgewählten Dienste fest. Erst die Befehlsantwort wendet Rechte und lokale Regeln auf ein bestimmtes Objekt an; der nachgelagerte Zustand bestätigt die Wirkung.

Ein Registereintrag kann somit richtig sein, obwohl ein Server die Erweiterung nicht anbietet. Eine angekündigte URI kann für ein Konto gesperrt sein. Selbst nach erfolgreicher Aushandlung kann ein gültiger Befehl an lokaler Policy scheitern.

Was das genehmigte Verfahren tatsächlich verbessert

Der Titel des Dokuments lautet “Extension Registry for the Extensible Provisioning Protocol”. Bis zur Veröffentlichung durch den RFC Editor bleibt Version 10 ein Internet-Draft. Sie soll RFC 7451 ablösen und den Status von Informational zu BCP anheben.

Die öffentliche Prüfung wechselt von der alten Liste eppext zu REGEXT. Künftige Anträge dürfen keinen Internet-Draft als dauerhafte Spezifikation verwenden; das Frühzuweisungsverfahren aus RFC 7120 ist nicht anwendbar. Die Referenz muss stabil und leicht zugänglich sein. Auch bei weiteren Sprachfassungen muss das Register auf eine englische Fassung verweisen.

Es gilt weiterhin Specification Required nach RFC 8126. IANA legt Anträge Designated Experts vor. Diese prüfen Architektur sowie Sicherheits- und Datenschutzdokumentation. Bei Interessenkonflikten müssen sie zurücktreten; nicht lösbare Einwände gehen in die öffentliche Beratung zurück.

Hinzu kommt klare URI-Verwaltung. XML-Schemata, Schema-URIs und Namensraum-URIs müssen syntaktisch und semantisch stimmen und nach RFC 3688 registriert sein. Für IETF reservierte Namensräume gehören IETF-Stream-Spezifikationen; proprietäre oder anderweitig veröffentlichte Arbeiten benötigen einen passenden eigenen Raum.

Damit wächst das Vertrauen, dass ein Eintrag identifizierbar und aus einer stabilen Quelle implementierbar ist. Eine Bestandsaufnahme sämtlicher laufender Server ist das Verfahren trotzdem nicht.

Active ist aussagekräftig, aber nicht allgemein

Ein Eintrag enthält Name, Dokumentstatus, Referenz, Registrant, TLD-Feld, IPR, Betriebsstatus und Notizen. Für eine Nicht-RFC-Spezifikation lautet der Dokumentstatus Other; sie erhält nicht fälschlich die Bedeutung einer Informational RFC.

Active bedeutet, dass die Erweiterung derzeit implementiert und in Gebrauch ist. Inactive steht für fehlende Implementierung oder Nutzung und kann auch verwendet werden, wenn die zitierte Spezifikation nicht mehr verfügbar ist.

Entscheidend ist die Reichweite. Bereits ein Einsatz in einem Registry–Registrar- oder Server–Client-Paar soll zu einer großzügigen Beurteilung führen. So kann der Katalog reale, noch nicht weit verbreitete Praxis erfassen. Daraus folgt keine Unterstützung durch alle Registries, Konten oder TLDs.

Auch das TLD-Feld hat begrenzte Bedeutung. Ein benannter TLD dokumentiert den erklärten Bereich. Any heißt, dass die Erweiterung nicht an genau einen TLD gebunden ist; N/A bedeutet, dass sie keine Domain-Verarbeitung betrifft. Any heißt nicht verpflichtend oder überall verfügbar.

Ein Betriebssystem muss daher neben Registrierung und Status auch Quelle, Ort und Zeitpunkt der Beobachtung behalten. Zwei globale Wahrheitswerte machen aus einem präzisen Register eine unpräzise Freigabeentscheidung.

Ähnliche Funktionen dürfen nebeneinander bestehen

EPP verbindet einen kleinen Kern mit Erweiterungspunkten, weil Registries unterschiedlichen technischen und geschäftlichen Regeln folgen. Ähnliche Anforderungen können deshalb zu verschiedenen Erweiterungen führen. RFC 7451 sollte solche Überschneidungen unter anderem sichtbar machen.

Für einen noch nicht eingesetzten Vorschlag können Experten eine Überarbeitung empfehlen, wenn bereits etwas Ähnliches registriert ist. Ähnlichkeit allein soll jedoch bei erfüllten Anforderungen nicht zur Ablehnung führen. Ist die Erweiterung in einem Server–Client-Paar schon produktiv, zählt diese Praxis.

Diese Offenheit macht den Katalog realistisch; sie erklärt keine Erweiterung zum Sieger und schafft keine Austauschbarkeit. Zwei Lösungen für Preise, Berechtigungen oder internationalisierte Namen können andere Datenmodelle, Regeln und Ergebnisse besitzen. Ein Client muss die genaue angekündigte URI mit deren genauer Spezifikation abgleichen.

Die laufende Autoritätskette beginnt mit der Begrüßung

RFC 5730 definiert die EPP-Begrüßung. Das Servicemenü führt unterstützte Versionen und Sprachen, verwaltbare Objekt-Namensräume und optional Erweiterungs-Namensräume auf. Der Server darf Verwaltungsrechte je Client begrenzen.

Beim Login wählt der Client eine passende Version und Sprache sowie Objekt- und Erweiterungs-URIs. Ein erfolgreicher Login eröffnet eine Sitzung, in der Identität und Autorisierung erhalten bleiben.

Künftige Befehle sind dennoch nicht garantiert. EPP-Ergebniscodes unterscheiden lokale Verbote, Objektabhängigkeiten, nach Serverregeln semantisch falsche Werte, nicht implementierte Dienste, Verstöße gegen Datenregeln sowie vorübergehende oder endgültige Serverfehler. Ein einziges Feld „unterstützt“ verwischt diese betrieblich wichtigen Ursachen.

Die belastbare Leiter lautet: registrierte Spezifikation; aktueller Status; frische Begrüßung des Zielservers; erfolgreiche Aushandlung für den konkreten Client; akzeptierte Befehlsform; erfolgreiche Transaktion; geprüfter Objektzustand. Jede Stufe trägt eine engere Aussage.

Das aktuelle Register ist kein Verlaufsarchiv

Das Verfahren regelt Einfügen, Ändern, Deaktivieren und Entfernen. Ein auf IETF-Konsens beruhender Eintrag benötigt zur Löschung IESG Approval. Andere können mit IESG-Zustimmung oder auf Antrag des Registranten nach Beratung mit den Experten entfernt oder deaktiviert werden. Verschwindet der Verantwortliche, darf ein Experte die Kontaktdaten korrigieren.

Ein Eintrag kann zwischen Active und Inactive wechseln. Ist die Spezifikation dauerhaft nicht erreichbar, soll er bis zur Wiederherstellung einer zuverlässigen Quelle inaktiv sein. So bleibt die Gegenwartsansicht belastbar.

Das Dokument benennt aber eine Lücke: Das Register besitzt keinen Verlaufsmechanismus; gelöschte Einträge lassen sich dort nicht weiterverfolgen. Betreiber müssen datierte Beobachtungen, Spezifikationskopie oder Hash, Begrüßungen, Sitzungsentscheidungen und Migrationspläne selbst sichern. Sonst verschwindet die Begründung einer Integration, während ihre Abhängigkeit fortlebt.

Die Zuständigkeit ist damit sauber geteilt. IANA und Experten pflegen den öffentlichen Koordinationsraum. Serverbetreiber bestimmen angekündigte Fähigkeiten und lokale Regeln. Registrare steuern die Nutzung ihrer Clients. Keiner sollte Tatsachen bescheinigen, die nur der andere beobachten kann.

Quellen