Zusammenfassung

  • Nach Revision 04 des EPP-over-HTTPS-Entwurfs begleitet HTTP 200 jede erzeugte EPP-Antwort, unabhängig davon, ob der EPP-Befehl erfolgreich war oder scheiterte.
  • Fehlt eine gültige EPP-Antwort, obwohl der Befehl die Verarbeitung erreicht haben könnte, ist der Ausgang unbestimmt. Wiederholen darf nur der EoH-Client mit gesichertem Wissen über die Idempotenz des vollständigen Befehls samt Erweiterungen.
  • Ein Befehlsdispositionsbeleg muss HTTP-Versuch, Transaktionskennungen, Reihenfolgesperre, Wiederholungsgrund und abschließende Abstimmung zusammenführen.

Ein grüner HTTP-Wert beendet viele Diskussionen. Der Dienst hat geantwortet, die Verfügbarkeitsanzeige steigt, der Vorgang gilt als erledigt. Bei EPP über HTTPS ist diese Lesart gefährlich kurz. Der Status beschreibt den äußeren Transport. Über die Wirkung eines Registerbefehls entscheidet die EPP-Antwort im Inneren.

draft-ietf-regext-epp-https-04 vom 3. September 2026 macht diese Grenze ausdrücklich. Sobald eine Anfrage die EPP-Verarbeitung erreicht und der Server eine EPP-Antwort erzeugt, muss die HTTP-Antwort den Status 200 tragen — auch dann, wenn EPP den Befehl ablehnt. Ein erfolgreich zugestellter Umschlag kann eine fachliche Fehlermeldung enthalten.

Umgekehrt beweist ein Gateway-Fehler nicht immer, dass der Befehl unangetastet blieb. Kann die Anfrage die EPP-Schicht erreicht haben, ohne dass der Client eine gültige EPP-Antwort empfängt, ist der Befehlsausgang unbestimmt. Diese Kategorie ist keine sprachliche Schwäche. Sie verhindert, dass fehlendes Wissen in eine neue, möglicherweise wirksame Mutation umgedeutet wird.

Zustandsbehaftetes Registerprotokoll im Webgewand

RFC 5730 definiert EPP als zustandsbehaftetes XML-Protokoll für Objekte in einem gemeinsamen zentralen Repository. Sitzungsbefehle, Abfragen und Transformationen folgen einer geordneten Anforderung-Antwort-Folge. Befehle sind atomar und so entworfen, dass sie idempotent gemacht werden können. Transportabbildungen müssen Reihenfolge und Zustand bewahren sowie Pipelining ausdrücklich erlauben oder verbieten.

Die HTTPS-Abbildung startet mit einem leeren POST. Eine EoH-Verbindung entsteht nur, wenn HTTP 200 eine EPP-Begrüßung liefert und per Cookie eine HTTP-Sitzung etabliert. Erst ein erfolgreicher EPP-Login eröffnet die authentisierte EPP-Sitzung. Danach trägt jeder POST genau eine EPP-Nachricht; nach fachlicher Verarbeitung enthält jede Antwort genau eine EPP-Antwort.

Port 443 und vertraute Webkomponenten erleichtern Cloud-Betrieb. Sie beseitigen den EPP-Zustand nicht. Der Entwurf nennt die Abbildung bewusst einen Tunnel und schränkt normale HTTP-Funktionen ein. Caching, Multiplexing, Infrastruktur-Authentisierung, Logging und automatische Wiederholungen dürfen nicht ungeprüft ihre übliche Bedeutung behalten.

Besonders deutlich wird das bei einer ungültigen Sitzungskennung. Erreicht der Befehl mit leerem oder falschem Cookie die EPP-Verarbeitung, verlangt der Entwurf EPP-Fehler 2002 innerhalb von HTTP 200. Wer nur außen misst, erklärt einen fachlichen Nutzungsfehler zum Erfolg.

Unbestimmt ist ein belastbarer Befund

Betriebsmodelle bevorzugen Erfolg und Fehler. Eine dritte Kategorie erschwert SLA-Berichte und Ticketabschluss. Doch die binäre Einstufung kann die fehlende Antwort nicht ersetzen. „Unbestimmt“ sagt präzise: Eine autoritative EPP-Antwort liegt nicht vor, und die vorhandenen Spuren schließen eine Verarbeitung nicht aus.

Daraus folgen klare Grenzen. Ein Registrar darf die Änderung nicht bestätigen. Er darf dem Register aber auch keine Ablehnung zuschreiben. Vor allem darf er nicht so tun, als sei eine Wiederholung bloß Wiederherstellung des Transports. Sie kann ein zweiter fachlicher Auftrag sein.

Eine spätere Objektabfrage kann bei der Abstimmung helfen, beweist aber nicht in jedem Fall die Ursache. Der Zustand könnte schon vorher bestanden haben, durch einen anderen Akteur verändert worden sein oder ein ausstehendes Verfahren widerspiegeln. Zustandsbeweis und Dispositionsbeweis sind verschieden. Das offene Dossier muss deshalb über den Timeout hinaus bestehen.

Idempotenz wird am vollständigen Inhalt entschieden

RFC 9110 definiert POST nicht als idempotent. Automatische Wiederholung ist nur vertretbar, wenn der Client weiß, dass die konkrete Semantik idempotent ist, oder feststellen kann, dass die erste Anfrage nie angewendet wurde. Ein Proxy darf nicht-idempotente Anfragen nicht automatisch wiederholen.

Revision 04 setzt dafür drei Bedingungen: Der Fehler könnte vorübergehend sein; die Semantik eines empfangenen HTTP-Status lässt eine Wiederholung zu; und der EoH-Client weiß, dass der vollständige EPP-Befehl einschließlich sämtlicher Erweiterungen idempotente Anwendungssemantik besitzt. Der Versuch muss denselben Befehl und gegebenenfalls denselben clTRID enthalten. Bis zur gültigen Antwort oder Aufgabe der Sitzung darf kein Folgekommando gesendet werden.

Die Erweiterungen sind kein Nebensatz. Sie können Bedingungen oder Wirkungen ergänzen. Eine Klassifikation des Basisbefehls reicht daher nicht. Der Betreiber braucht eine versionierte Begründung für genau das gesendete Nachrichtenprofil. Fehlt sie, ist Nicht-Wiederholen die evidenzbasierte Entscheidung.

Der Zwischenkomponente fehlt dieses Wissen regelmäßig. Ein Load Balancer erkennt Zeitüberschreitung und Backend, aber nicht die registerfachliche Absicht. Ein Service Mesh kennt den Datenpfad, nicht die EPP-Reihenfolge. Darum müssen Betreiber automatische EPP-POST-Wiederholungen in ihren kontrollierten Intermediären deaktivieren.

Transaktionskennungen schaffen Nachvollziehbarkeit

RFC 5730 erlaubt dem Client einen clTRID, dessen Eindeutigkeit er selbst verwaltet. Die Serverantwort verbindet ihn mit einem serverseitig eindeutigen svTRID. Diese Kennungen sichern die Synchronisation von Befehl und Antwort und sollen beidseits protokolliert, aufbewahrt und geschützt werden.

Bei einer zulässigen Wiederholung verlangt der HTTPS-Entwurf denselben clTRID. So lassen sich Versuche einem Vorgang zuordnen. Die Texte versprechen jedoch nicht, dass jede Serverimplementierung einen wiederholten clTRID automatisch als universellen Deduplizierungsschlüssel behandelt. Wer darauf angewiesen ist, braucht eine ausdrückliche, versionsgebundene Zusage im Implementierungs- oder Dienstvertrag.

Korrelation beantwortet: Welche Nachrichten gehören zusammen? Idempotenz beantwortet: Haben mehrere Ausführungen dieselbe beabsichtigte Wirkung? Deduplizierung beantwortet: Unterdrückt der Server eine weitere Ausführung? Diese drei Fragen dürfen nicht durch eine einzige Kennung verschmolzen werden.

Die Wartesperre schützt die Kausalität

HTTP/2 und HTTP/3 können multiplexen. EoH verbietet dennoch mehr als eine ausstehende HTTP-Anfrage pro EPP-Sitzung. Erzeugt ein Intermediär Konkurrenz, muss der Server festlegen, ob er ablehnt oder serialisiert.

Das ist mehr als eine Leistungseinbuße. Eine Aktualisierung kann eine erfolgreiche Anlage voraussetzen; ein Transfer kann die Berechtigung für den nächsten Eingriff verändern. Solange der erste Befehl unbestimmt bleibt, vervielfacht ein zweiter die möglichen Geschichten. Die Reihenfolgesperre hält aus einem offenen Sachverhalt ein begrenztes Problem.

Die Sitzung aufzugeben stoppt neue Befehle, entscheidet den alten aber nicht. Die Abstimmung kann Serverprotokolle, eine wiedergefundene Antwort, eine gezielte Objektabfrage oder ein bilaterales Verfahren benötigen. Eine neue Sitzung stellt Verkehr her; sie tilgt keine ausstehende Verantwortung.

Der Befehlsdispositionsbeleg

HTTP-Protokolle dokumentieren Route, Status, Latenz und Backend. EPP-Protokolle dokumentieren Nachricht, Ergebniscode und Transaktionskennung. Der erforderliche Governance-Beleg verbindet beide Perspektiven:

  1. Befehlsart, betroffenes Objekt und kanonischer Fingerabdruck der vollständigen EPP-Nachricht samt Erweiterungen;
  2. Sitzungsidentität, clTRID und Kennung jedes HTTP-Versuchs;
  3. Absendezeit und letzter Punkt, an dem Nichtzustellung beweisbar war;
  4. HTTP-Befund und tatsächlich antwortende Komponente;
  5. EPP-Ergebnis sowie svTRID, sofern eine gültige Antwort vorliegt;
  6. dreiteilige Disposition: bestätigter Erfolg, bestätigter Fehler oder unbestimmt;
  7. Quelle, Umfang und Version der Idempotenzbegründung;
  8. Nachweis der Sperre für Folgekommandos;
  9. verantwortliche Person oder Regel für Wiederholung, Aufgabe und Abstimmung;
  10. Abschlussbeleg mit Zeitpunkt, Vertrauensniveau und verbleibender Abweichung.

Lu Hengs Gedanke einer minimalen Anfangsspezifikation spricht gegen ein global vorgeschriebenes Ticketsystem. Der gemeinsame Kern sind Unterscheidungen und Beweise; Speicherung und Arbeitsablauf können lokal bleiben. Ein signiertes Ereignis, ein bilateraler Fall oder eine geschützte Log-Verknüpfung kann genügen, sofern „unbekannt“ nicht automatisch zu „fehlgeschlagen“ wird.

The Policy Mirror legt die Machtfrage offen. Wer darf den Befehl wiederholen? Wer trägt die Kosten einer doppelten Wirkung? Wer sieht und bestreitet den Nachweis? Steigert die Infrastruktur ihre scheinbare Verfügbarkeit und verlagert die Abstimmung auf Registrar oder Registrant, verteilt eine technische Voreinstellung bereits Risiko und Entscheidungsgewalt.

Auch die Norm hat einen präzisen Status

Revision 04 ist ein aktives REGEXT-Arbeitsgruppendokument mit angestrebtem Standards Track. Sie ist kein RFC, hat die IESG-Prüfung nicht abgeschlossen und läuft am 7. März 2027 aus. Der Meilenstein für September 2026 ist ein Ziel, keine bestätigte Veröffentlichung.

Der Implementierungsabschnitt nennt ein Verisign-SDK und Arbeiten von IIT-CNR/Registro.it. Der Hinweis nach RFC 7942 stellt klar: Angaben von Beitragenden sind nicht durch die IETF verifiziert, bedeuten keine Empfehlung und bilden keinen Katalog. Sie belegen berichtete Erprobung, nicht einheitliches Produktionsverhalten.

Auch der IANA-Eintrag ist im Entwurf vorgeschlagen. Vorschlag und aktiver Registereintrag sind verschiedene Zustände. Wer vom Betrieb semantische Genauigkeit verlangt, muss sie beim Status des Dokuments vorleben.

Quellen

  1. IETF — EPP Transport over HTTPS, Revision 04
  2. Datatracker — Dokumentstatus
  3. Datatracker — Änderungshistorie
  4. REGEXT Working Group
  5. RFC 5730 — Extensible Provisioning Protocol
  6. RFC 5731 — EPP Domain Name Mapping
  7. RFC 5734 — EPP Transport over TCP
  8. RFC 9110 — HTTP Semantics
  9. RFC 7942 — Improving Awareness of Running Code
  10. IANA — Extensions for EPP
  11. Lu Heng — Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption
  12. Lu Heng — The Policy Mirror