Summary

  • The IESG approved draft-ietf-regext-ext-registry-epp-10 on 17 August 2026 for publication as Best Current Practice. It strengthens how EPP extensions are specified, reviewed, recorded and maintained; it does not turn IANA’s catalogue into a universal server capability directory.
  • A registered extension can be Active because it is implemented and used by at least one registry/registrar or server/client pair, while a particular server omits its namespace from the current greeting or rejects a command under local policy. Registration, advertised support, negotiated use and transaction success are separate evidence states.

The catalogue answered a different question

The opening is hypothetical, not a reported registry failure. It begins with a true fact: the extension has a durable specification and an entry in the public IANA registry. The mistake occurs when software converts that fact into a claim about an unrelated live endpoint.

The registry answers questions of coordination. What is the extension called? Where is its stable specification? Who maintains the record? Which TLD scope was declared? Is intellectual-property information disclosed? Is the entry recorded as active or inactive? Those fields make extensions discoverable and reduce accidental namespace collision.

A server greeting answers a different question: which protocol versions, object namespaces and optional extension namespaces does this server currently say it supports? A successful login adds another layer by establishing the client identity, authorization context and services selected for that session. The command response then answers whether this operation, against this object, under present local policy, succeeded.

One layer cannot safely stand in for the next. A catalogue can be correct while a server offers a smaller set. A greeting can advertise an extension while one client lacks privileges. A negotiated session can include the namespace while a syntactically valid command still violates registry policy.

The approved practice raises the quality of registration

On 17 August, the IESG approved version 10 of “Extension Registry for the Extensible Provisioning Protocol” as Best Current Practice. Until the RFC Editor publishes it, the document remains an Internet-Draft. It is intended to obsolete RFC 7451.

The update is more than an editorial refresh. The intended status moves from Informational to BCP. Public review moves from the old eppext list to REGEXT. Future registrations cannot cite an Internet-Draft as their specification, and RFC 7120 early allocation does not apply. A permanent, readily available specification is required, with an English version linked from the registry even when other languages are also provided.

The registry continues to use the RFC 8126 Specification Required policy. IANA sends requests to Designated Experts, who assess architectural soundness, security and privacy documentation. A perceived conflict of interest requires an expert to defer. Discussion takes place on the public working-group list.

URI stewardship is now explicit. XML schemas, schema URIs and namespace URIs must be syntactically and semantically sound and registered through the IETF XML Registry. IETF namespaces are reserved for IETF-stream specifications; a proprietary or Independent Submission specification must use an appropriate non-IETF namespace. An implementer should therefore gain stronger confidence that an entry is identifiable and implementable from a stable source.

That is valuable institutional work. It still does not inspect every deployed server.

Active has evidence, but its scope is not universal

Each entry records the name, document status, reference, registrant, TLD field, IPR disclosure, status and notes. For a non-RFC specification, document status becomes Other rather than borrowing the more specific meaning of an Informational RFC.

The status field is not decorative. Active is used when an extension is currently implemented and in use. Inactive covers extensions that are not implemented or not used, and may also be applied when the referenced specification remains unavailable.

The important word is scope. The experts are encouraged to be permissive when an extension has been implemented and deployed by at least one registry/registrar or server/client pair. That evidence supports registration and active maintenance. It cannot prove that every registry server, every client account or every TLD offers the feature.

The TLD field has the same bounded character. A named TLD records the scope for which the extension was specified. Any means it is not tied to one specific TLD. N/A means it is unrelated to domain-name processing. Any does not mean “mandatory everywhere,” just as a public specification does not create a commercial entitlement.

Automation should therefore store both the registry state and its evidentiary scope. A discovery interface that exposes only “registered: yes” and “status: active” invites a false global conclusion.

Duplicate functions are permitted because the registry is a map

EPP was designed around a small common core and extension points because domain registries operate different technical and business models. The resulting flexibility also permits different extensions to address similar needs. RFC 7451 created the registry partly to make that duplication visible.

The new practice does not pretend it can eliminate overlap. Experts should ask an undeployed proposal to reconsider when a similar extension is already registered. Yet similarity alone should not cause rejection when the other requirements are met. If an extension is already deployed by a registry/server pair and its client counterpart, the review should be permissive.

This is a pragmatic coordination choice. A registry entry is not a declaration that one extension has won, that two similar namespaces interoperate, or that clients may substitute one for another. The catalogue lowers discovery cost; it does not erase local semantics or installed practice.

For client developers, functional labels are therefore weaker than namespace and version evidence. Two extensions that both appear to handle eligibility, pricing or internationalized names may have different data models, policies and outcomes. An integration should match the exact URI advertised by the server and the exact specification attached to that URI.

The live authority chain begins with the greeting

RFC 5730 defines the EPP server greeting. Its service menu lists supported protocol versions and languages, the object namespace URIs the server can manage, and optionally the extension namespace URIs it supports. The same RFC permits a server to limit object-management privileges per client.

The client then sends a login whose version and language must match the greeting and whose service selection names the object and optional extension URIs intended for the session. A successful login creates an ongoing session that preserves identity and authorization information.

Even then, no future command is guaranteed. EPP result codes distinguish local-policy prohibitions, object dependencies, semantically invalid values under server policy, unimplemented services, data-management-policy violations and transient or terminal server failures. This is why a synthetic “extension supported” flag is too coarse for production control.

A useful evidence ladder is: registered specification; current registry status; current target-server greeting; successful session negotiation for the exact client; accepted command shape; successful transaction; verified downstream object state. Each step answers a narrower and more operational question.

Maintenance changes need their own memory

The approved procedure defines insert, modify, deactivate and remove operations. IETF-consensus registrations require IESG Approval for removal. Other entries can be removed or deactivated with IESG approval or at the original registrant’s request in consultation with the experts. Normally the registrant updates its entry; an expert may repair registrant information if the responsible party disappears.

An entry can move between Active and Inactive. If the public specification becomes consistently unavailable, an expert should mark it inactive until reliable availability returns. These controls protect the present registry view.

The operational section also states a harder limitation: the registry has no history mechanism, and a deleted entry cannot be tracked there after removal. A change can affect other parties already deploying the extension. Operators who depend on the catalogue therefore need their own signed or hashed observations, specification copies, greeting captures and migration decisions. Otherwise the evidence used to approve an integration may vanish from the current public view.

The institutional boundary is clear. IANA and the experts maintain a public coordination record under defined rules. Server operators control live advertised capabilities and policy. Registrars control which negotiated features their clients use. Neither side should be asked to certify a conclusion belonging to the other.

Sources