Summary

  • Revision 04 of the IETF’s EPP-over-HTTPS draft draws a bright line between an HTTP outcome and an authoritative EPP result. HTTP 200 can carry either EPP success or EPP failure; without a valid EPP response, a command that may have reached processing is indeterminate.
  • Retrying is not an infrastructure default. It is an application judgment available only when the EoH client knows that the complete EPP command, including extensions, has idempotent semantics and preserves command order.
  • Registries and registrars therefore need a command-disposition receipt that records what is known, what is not, who decided to retry or abandon, and how the final object state was reconciled.

On a conventional web dashboard, a green 200 OK is reassurance. The request reached something willing to answer, and the answer belongs to the success class. That visual grammar is so familiar that it often travels into monitoring systems, incident tickets and executive reports without qualification. Green becomes “done”.

For a registry provisioning command carried over HTTPS, that shortcut is wrong. draft-ietf-regext-epp-https-04, published on 3 September 2026, makes the distinction unusually explicit. When a request reaches the Extensible Provisioning Protocol processing layer and the server generates an EPP response, the outer HTTP response must be 200 whether the inner EPP result says the command succeeded or failed. If there is no valid EPP response, and the request might nevertheless have reached processing, the command outcome is not failure. It is indeterminate.

This is a small transport rule with a large governance consequence. A registrar may have asked a registry to create, renew, transfer, update or delete an object. The HTTP exchange can tell the operator something about delivery and the web-facing service. Only the EPP response can give the authoritative application result contemplated by the mapping. When that response is missing, the organisation does not possess a negative answer. It possesses an unresolved state that can become more dangerous if automation is allowed to turn uncertainty into another mutation.

Two status systems occupy one envelope

EPP was designed as a stateful, ordered command-response protocol for provisioning objects held in a shared central repository. RFC 5730 divides its work into session management, read-only queries and object transforms. It says commands are atomic and designed so that they can be made idempotent. It also requires any transport mapping to preserve ordering and state and to say whether pipelining is permitted.

The HTTPS draft maps that protocol onto POST requests. An initial empty POST opens the EPP-over-HTTPS connection only if HTTP 200 returns an EPP greeting and establishes the cookie-backed HTTP session. A successful EPP login then creates the authenticated EPP session. After that, each POST contains one EPP command and each processed command yields one EPP response.

The mapping is intentionally a tunnel. The authors want operators to reuse web infrastructure and much of their existing EPP software, but they do not pretend that the HTTP layer acquires knowledge of registry semantics. Indeed, the draft limits several capabilities that reverse proxies and cloud platforms normally advertise: caching, multiplexing, infrastructure authentication, logging and automatic retries cannot simply be inherited as if this were an ordinary stateless web API.

The crucial rule follows. HTTP status codes must not convey the result of an EPP command. A 200 says that the EPP-processing path produced an EPP response; the XML inside may report success or failure. Conversely, a gateway timeout, overload response or unsupported-media-type response is an HTTP-layer outcome, not an EPP response. If a request could have crossed the application boundary before the reply was lost, the outer failure does not prove that the inner command was rejected.

Even an invalid session illustrates the separation. If the request reaches EPP processing with an empty or invalid session identifier, the draft requires an EPP 2002 command-use error inside HTTP 200. The shared number 200 is a coincidence of two different code spaces. Treating the envelope as the decision discards the only result that matters.

Indeterminate is a real operational state

Operators tend to compress uncertain outcomes into the nearest binary category. A timed-out write is labelled failed; a retry that returns an “already exists” response is labelled successful; a later object query is treated as proof of which request caused the state. Each compression may be convenient. None preserves the evidence chain.

Indeterminate should instead be represented as a first-class disposition. It means three things at once: there is no valid authoritative EPP response in hand; the evidence does not exclude application processing; and a new command could compound the uncertainty. That state is not an accusation against a server. Networks lose responses, intermediaries fail, sessions expire and implementations differ. Nor is it a prediction that a duplicate mutation will occur. It is simply the most precise statement the available evidence supports.

That precision matters because registry commands are not interchangeable messages. A query and a renewal create different exposure. The base protocol says commands are designed so they can be made idempotent, but the HTTPS draft does not grant every command in every implementation an unconditional retry licence. The complete command includes extensions, and an extension can change the application semantics. An operator who checks only the base verb has not checked the request that was actually sent.

The client, not the middlebox, owns the retry judgment

HTTP semantics supply a conservative starting point. RFC 9110 does not define POST as idempotent. It advises a client not to retry a non-idempotent method automatically unless the client knows the request semantics are actually idempotent or can establish that the first request was never applied. A proxy must not automatically retry non-idempotent requests.

Revision 04 carries that discipline into EPP. An EoH client may retry only if the failure might be transient, the HTTP status semantics permit it, and the client knows the enclosed EPP command—including all extensions—has idempotent application semantics. The retry must contain the same command and the same client transaction identifier, if one was present. No later EPP command may be sent until a valid response arrives or the session is abandoned. Operators must configure intermediaries under their control not to retry EPP POSTs automatically.

This allocates authority for a reason. A load balancer can observe connections, status codes and timeouts. It generally cannot decide whether a registry extension turns a nominally repeatable operation into a request with a different effect. Nor does it own the EPP command sequence. Letting the intermediary retry makes an infrastructure component the hidden author of application policy.

The same caution applies to transaction identifiers. RFC 5730 allows a client-supplied clTRID and requires a server-assigned unique svTRID in the response. Together they provide command-response synchronisation integrity; the RFC recommends that both sides log, retain and protect them. The HTTPS draft requires the same clTRID on a permitted retry. But correlation is not automatically deduplication. Neither document says that repeating a clTRID alone compels every server to suppress a second execution. If an operator relies on that property, it needs an explicit implementation or service contract and evidence that the property was active.

Ordering is part of the evidence

HTTP/2 and HTTP/3 make concurrent streams appear natural. EPP does not inherit that freedom. The draft forbids more than one outstanding HTTP request per EPP session and does not enable command pipelining. If an intermediary nevertheless produces concurrent requests, the server must define whether it fails or serialises them.

This is not only a performance constraint. Order changes meaning. A later update may depend on a create; a transfer operation may change which client is entitled to modify an object; a retry may be safe only while nothing else has advanced the state. The instruction not to send a subsequent command while the previous outcome is unresolved therefore acts as an evidentiary barrier. It prevents the record from becoming a puzzle in which several plausible sequences explain the same final state.

Abandoning the session is not the same as resolving the command. It is a safety action that stops the sequence. Reconciliation still has to determine what the registry believes, using an authoritative response, a server-side transaction trace, a suitably scoped object query, an operator confirmation or another agreed mechanism. A fresh session may be needed, but a fresh transport does not erase the unresolved history.

A command-disposition receipt

Ordinary request logs are organised around infrastructure. They record a URL, latency, HTTP status, backend and perhaps a retry count. EPP audit records are often organised around the XML transaction. In a tunnelled system, neither view alone is sufficient. The join between them is the governance object.

A command-disposition receipt should be created whenever an EPP command leaves the client. It should record:

  1. the command family, affected registry object and hash or canonical fingerprint of the entire EPP command, including extensions;
  2. the EPP session identity, the client transaction identifier and the HTTP attempt identity;
  3. the time the client committed the request to transport and the last point at which non-delivery is provable;
  4. the HTTP observation, including any intermediary that generated the response;
  5. the EPP result code and server transaction identifier, if a valid response arrived;
  6. a three-way disposition—resolved success, resolved failure or indeterminate—without deriving it from colour or status class alone;
  7. the documented basis for treating the complete command as idempotent, including the version and semantics of extensions;
  8. the ordering barrier, showing that no later command was admitted while disposition remained open;
  9. the named operator or client policy that authorised retry, reconciliation or session abandonment; and
  10. the evidence that closed the case, its timestamp, confidence and any remaining disagreement between client and registry records.

This is not a demand for one global database schema. Lu Heng’s minimum-initial-specification approach points toward a smaller common obligation: preserve the distinctions and the identifiers, while letting registries and registrars choose local storage and reconciliation procedures. The receipt can be a signed event, an incident object, a linked pair of logs or a case in a bilateral support system. What matters is that it cannot silently downgrade “unknown” to “failed” or elevate HTTP success to registry success.

The Policy Mirror supplies the institutional test. Who receives the power when a convenience feature retries a command? Who absorbs the loss if it repeats a mutation? Who can see and contest the evidence? A default that benefits platform throughput while exporting reconciliation costs to registrars, registrants or support teams is not merely a transport setting. It is a policy choice hidden in infrastructure.

What revision 04 proves—and what it does not

The draft is an active REGEXT Working Group document intended for the Standards Track. It is not an RFC, has not completed IESG review, and can change before it expires on 7 March 2027. The working group’s September 2026 submission milestone is a plan, not evidence that submission or approval has happened.

The implementation section names a Verisign SDK and an IIT-CNR/Registro.it implementation. Under the draft’s own RFC 7942 notice, those descriptions were supplied by contributors, were not verified by the IETF, imply no endorsement and are not a catalogue. They are useful evidence that implementers have exercised the design. They do not prove that every deployed intermediary has automatic retry disabled, every extension is classified correctly or every operator can reconcile an indeterminate command.

Likewise, the proposed IANA registration is a proposal in the draft. It should not be reported as though the draft text had already created the registry entry. Governance begins by keeping status claims as exact as protocol claims.

Sources

  1. IETF Internet-Draft — Extensible Provisioning Protocol (EPP) Transport over HTTPS, revision 04
  2. IETF Datatracker — draft-ietf-regext-epp-https
  3. IETF Datatracker — document history
  4. IETF 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