Summary

  • The REGEXT working-group draft dated 3 September 2026 maps stateful EPP onto HTTPS. It is an active Internet-Draft, not an RFC, an IESG approval or evidence of deployment.
  • Every request that reaches EPP processing and produces an EPP response returns HTTP 200 (OK), whether the EPP command succeeded or failed. HTTP status and EPP result code are separate records.
  • If processing may have occurred but no valid EPP response arrives, the command outcome is indeterminate. HTTP intermediaries must not retry automatically; only the EoH client may retry after proving the complete command, including extensions, is idempotent and preserving its transaction identifier and order.

The load balancer logged success. The registry rejected the command. There is no contradiction.

The first statement describes an HTTP exchange. The second describes an EPP operation. A system that stores only one of those answers can tell its operators that registration is healthy while failing every transform command—or can report a transport incident after the registry has already changed authoritative state.

That distinction is the strongest contribution of draft-ietf-regext-epp-https-04, a REGEXT working-group draft dated 3 September 2026. The document maps the Extensible Provisioning Protocol onto HTTPS. Its status is important: it is work in progress with an intended standards-track destination, not an RFC and not an IETF approval. The implementation notes do not prove adoption or performance.

Its operating problem is already real enough to describe precisely. EPP is the stateful XML protocol used between provisioning clients and shared repositories. RFC 5730 requires command order, persistent session state, coordinated responses and atomic commands. The new mapping does not redesign that protocol as REST. It tunnels the existing conversation through HTTP POST requests so operators can reuse web infrastructure without pretending that EPP has acquired ordinary web semantics.

A successful envelope can contain a refusal

An EoH connection begins with an empty POST to a server URL supplied out of band. A successful response carries an EPP greeting, the application/epp+xml media type, Cache-Control: no-store, X-Content-Type-Options: nosniff and a session cookie. A later successful EPP login turns that connection into an authenticated EPP session.

After that, one POST carries one EPP command and one HTTP response carries one EPP response. The decisive rule is that HTTP status codes do not report the command result. If a request reaches the EPP processing layer and the server generates an EPP response, HTTP returns 200 even when that embedded response says the command failed.

An HTTP-layer failure is different. A malformed request, unsupported media type, size limit, rate limit, overload condition or gateway failure can produce the appropriate 4xx or 5xx response because no authoritative EPP response was delivered. Monitoring therefore needs two columns. The HTTP column asks whether the request crossed the web-facing boundary. The EPP column asks what the registry application decided.

Even a missing or invalid session cookie demonstrates the split. If that request reaches EPP processing, the draft calls for EPP result 2002—command use error—inside HTTP 200. Counting 200s as successful registry transactions would turn a clearly specified refusal into a green dashboard.

The third state is more dangerous than failure

Failure is manageable when it is authoritative. The client receives an EPP result code, records the rejection and knows the requested state transition did not succeed. The harder case is silence after possible execution.

Suppose a registrar sends an object-transform command. The gateway forwards it. The registry processes it. The response is then lost when a connection, proxy or backend fails. The client has neither an EPP success nor an EPP failure. It has an HTTP event and an absent authoritative result. The draft names the command outcome correctly: indeterminate.

This is why automatic retry is not a resilience feature by default. HTTP defines POST as non-idempotent. EPP commands are designed so they can be made idempotent, but safety belongs to the complete application command, including any extension. A proxy sees a POST and a timeout; it does not necessarily know whether the XML represents a repeat-safe query, a transform already committed, or an extension whose second execution has a different effect.

Revision 04 therefore places retry authority with the EoH client. A retry is permitted only when the failure may be transient, the HTTP status semantics allow it and the client knows the entire command is idempotent. The retry must contain the same command and the same client transaction identifier when one exists. No later command may pass it in the session until a valid response arrives or the session is abandoned. Intermediaries under the operator's control must have automatic EPP POST retry disabled.

That is not caution for its own sake. A new transaction identifier can make one logical attempt look like a second instruction. A later command can overtake the unknown state and make reconciliation harder. A retry performed by a generic gateway can erase the only place where application semantics were understood.

Faster transport does not authorize parallel commands

HTTP/2 and HTTP/3 can multiplex requests, but the mapping explicitly forbids more than one outstanding request in an EPP session. EPP permits a transport mapping to define pipelining, yet this one chooses not to. Command order remains part of correctness.

An intermediary may still create concurrent requests despite the client rule, so the server must define whether it rejects or serializes them. This is a useful test of control. It is not enough to configure a client library correctly when a retry layer, service mesh or load balancer can manufacture a second in-flight command.

The same discipline applies to session state. The HTTP cookie identifies the logical EPP connection even when its messages cross different underlying HTTP connections. A multi-instance service can pin that cookie to one backend or place state in a shared store. Sticky affinity is simpler, but a failed backend loses its active sessions unless state is replicated. A shared store enables failover and maintenance, but becomes part of the confidentiality, integrity and availability boundary.

The draft requires sequential processing and atomic state changes for one EoH connection. Session-store lifetime must remain aligned with the HTTP and EPP sessions. Otherwise the web tier can stay reachable while the protocol conversation it claims to carry has disappeared.

Standard web infrastructure creates new evidence, not one truth

Moving EPP to port 443 can make firewall traversal, DDoS filtering, load balancing and Layer-7 monitoring easier. It also creates more places to mistake a local observation for the final fact. HTTP access logs expose source, latency and status. EPP logs expose command identifiers and result codes. The shared session store exposes connection continuity. The registry database exposes object state. DNS publication and later resolver observation sit further downstream.

Heng Lu's reality-layer discipline is exact here. A transport acknowledgement is not command acceptance. Command acceptance is not necessarily completion of an offline action. Stored registry state is not DNS propagation. A resolver answer is not the user's experience. Each record can be true without substituting for the next.

His running-code primacy turns that distinction into an operator test. Which component knows whether the full command is idempotent? Which one can freeze later commands? Which retains the client transaction identifier? Which can query authoritative state before repeating a transform? That component, not the most convenient retry feature, should control recovery.

The draft also reports a development-stage Verisign SDK implementation for HTTP/1.1 and HTTP/2, plus a slightly different arrangement used by Registro.it since 2009. The document itself warns that implementation-status reports are contributor-supplied and unverified. They show that the design is not purely imaginary. They do not establish conformance, uptake or operational quality.

The practical lesson is narrower. HTTPS can replace a transport layer while preserving EPP software and state semantics. It cannot collapse those semantics into a single green status. The moment a registry command crosses a generic web stack, delivery, decision and uncertainty must each retain their own receipt.

Sources