Zusammenfassung

  • draft-ietf-regext-epp-https-04 vom 3. September 2026 ist ein aktiver Internet-Draft der REGEXT-Arbeitsgruppe. Er ist weder RFC noch IETF-Freigabe oder Beleg einer Einführung.
  • Erreicht eine Anfrage die EPP-Verarbeitung und entsteht eine EPP-Antwort, liefert die HTTP-Schicht 200 (OK) bei Erfolg wie bei Fehler des Befehls. Beide Codes führen getrennte Ergebnisprotokolle.
  • Könnte der Befehl verarbeitet worden sein, ohne dass eine gültige EPP-Antwort ankommt, ist sein Ausgang unbestimmt. Intermediäre dürfen nicht automatisch wiederholen; nur der semantikkundige EoH-Client darf nach Prüfung des vollständigen Befehls Identifikator und Reihenfolge bewahren.

Der Load Balancer sieht eine erfolgreiche HTTP-Antwort. Der Registrar sieht eine abgelehnte Registry-Operation. Wer daraus einen Widerspruch macht, hat zwei Beobachtungsebenen zu früh zusammengelegt.

draft-ietf-regext-epp-https-04 bildet das zustandsbehaftete XML-Protokoll EPP auf HTTPS ab. RFC 5730 verlangt Befehlsreihenfolge, dauerhafte Sitzungen und koordinierte Antworten. Der Entwurf macht daraus keine REST-Schnittstelle. Er tunnelt die bestehende Unterhaltung durch POST-Anfragen, damit Betreiber Web-Firewalls, Lastverteilung und Layer-7-Monitoring nutzen können.

Eine EoH-Verbindung beginnt mit einem leeren POST an eine außerhalb des Protokolls mitgeteilte URL. Die gültige Eröffnung enthält EPP-Greeting, application/epp+xml, no-store, nosniff und ein Sitzungscookie. Erst ein erfolgreiches EPP-<login> erzeugt die authentisierte Sitzung.

200 bestätigt die Hülle, nicht den Befehl

Danach trägt jeder POST genau einen EPP-Befehl, jede HTTP-Antwort genau eine EPP-Antwort. Sobald die Anfrage in der EPP-Schicht verarbeitet und beantwortet wurde, lautet der äußere Status 200—auch wenn der innere Ergebniscode den Befehl ablehnt.

4xx und 5xx bedeuten etwas anderes: fehlerhafte HTTP-Struktur, nicht unterstützter Medientyp, Größen- oder Ratenlimit, Überlastung oder Gateway-Ausfall. Der Client erhielt dann kein maßgebliches EPP-Ergebnis. Aus dem äußeren Fehler allein folgt jedoch nicht in jedem Fall, dass im Register nichts geschah.

Ein ungültiges Sitzungscookie zeigt die Trennung besonders deutlich. Gelangt eine solche Anfrage bis zur EPP-Verarbeitung, kommt EPP-Fehler 2002 innerhalb von HTTP 200 zurück. Wer jeden 200er als erfolgreiche Registry-Transaktion zählt, färbt eine ausdrückliche Ablehnung grün.

Ein brauchbarer Nachweis verbindet daher HTTP-Status, EPP-Ergebnis und Client-Transaktionskennung. Der erste lokalisiert die Anfrage im Web-Pfad, das zweite enthält die Registerentscheidung, die dritte bindet jede Wiederherstellung an den ursprünglichen Versuch.

Keine Antwort ist keine Rücknahme

Der schwierigste Zustand entsteht, wenn eine Transformationsoperation ausgeführt wurde, aber ihre Antwort auf dem Rückweg verschwindet. Der Client besitzt weder Erfolg noch Fehler. Der Entwurf nennt den Ausgang zutreffend unbestimmt.

Automatisches Wiederholen kann die Unsicherheit verdoppeln. HTTP definiert POST nicht als idempotent. EPP-Befehle sind so entworfen, dass sie idempotent gemacht werden können; ob eine konkrete Operation sicher wiederholbar ist, hängt aber vom ganzen Befehl einschließlich Erweiterungen ab. Ein allgemeiner Proxy kennt diese Bedeutung nicht.

Revision 04 lässt die Entscheidung deshalb beim EoH-Client. Eine Wiederholung ist nur zulässig, wenn der Fehler vorübergehend sein könnte, die HTTP-Semantik dazu passt und der Client die vollständige Operation als idempotent kennt. Befehl und Transaktionskennung bleiben gleich. Bis zur gültigen Antwort oder zum Abbruch der Sitzung darf kein Folgebefehl passieren. Intermediäre im Einflussbereich des Betreibers müssen automatische Wiederholungen von EPP-POSTs abschalten.

Damit bleibt die Kausalität erhalten. Eine neue Kennung lässt dieselbe Absicht wie einen zweiten Auftrag erscheinen. Ein vorgezogener Folgebefehl arbeitet auf unbekanntem Zustand. Eine Wiederholung am Gateway verlagert Entscheidungsgewalt vom EPP-kundigen Client auf eine Komponente, die nur ein Timeout sah.

HTTP-Parallelität ist keine EPP-Parallelität

HTTP/2 und HTTP/3 unterstützen Multiplexing. Die Zuordnung verbietet dennoch mehr als eine offene Anfrage pro EPP-Sitzung. Erzeugt ein Intermediär trotzdem Parallelität, muss der Server sie definiert ablehnen oder serialisieren.

Das Cookie steht für die logische EPP-Verbindung, selbst wenn Nachrichten unterschiedliche HTTP-Verbindungen nutzen. In einem Cluster kann Sitzungsaffinität auf eine Instanz oder ein gemeinsamer Zustandsspeicher eingesetzt werden. Affinität ist einfach, verliert ohne Replikation aber aktive Sitzungen mit der Instanz. Ein geteilter Speicher erleichtert Wartung und Failover, wird jedoch Teil der Sicherheits- und Verfügbarkeitsgrenze.

Anfragen derselben Verbindung müssen nacheinander verarbeitet, Zustandsänderungen atomar angewendet und die Lebenszeiten von HTTP-, EPP- und Speicherzustand abgestimmt werden. Sonst bleibt der HTTPS-Endpunkt gesund, während die von ihm dargestellte Registry-Unterhaltung verschwunden ist.

Der Entwurf nennt ein Verisign SDK im Entwicklungsstand für HTTP/1.1 und HTTP/2 sowie eine seit 2009 bei Registro.it eingesetzte, leicht abweichende Lösung. Er warnt ausdrücklich, dass diese Angaben von Mitwirkenden stammen und nicht durch die IETF geprüft wurden. Sie belegen Experimente, nicht Verbreitung, Konformität oder Qualität.

Heng Lus Disziplin der getrennten Realitätsebenen passt exakt: HTTP-Zustellung, EPP-Entscheidung, gespeicherter Registerzustand, DNS-Veröffentlichung und Nutzerbeobachtung sind eigene Belege. Running-Code Primacy weist die Wiederholungsentscheidung der Komponente zu, die den Befehl versteht, die Reihenfolge sperren, die Kennung erhalten und den maßgeblichen Zustand abfragen kann.

HTTPS modernisiert den Transport. Es verwandelt zwei Ergebnisbücher nicht in eine einzige Wahrheit.

Quellen