Summary

  • The proposed successor to RFC 7451 tells designated experts to be permissive when an EPP extension has been implemented and deployed by at least one registry/registrar or server/client pair. It also says that multiple extensions with the same or similar functionality may be registered and that similarity alone is not a reason to reject an otherwise valid request.
  • Registration therefore establishes a durable specification, an identifier and an accountable review path. It does not select a preferred design, confer Standards Track status, demonstrate broad adoption or prove that two implementations interoperate.
  • The live IANA registry already makes coexistence visible: notes say that CORE and TANGO IDN extensions, and their privacy extensions, are syntactically and functionally identical while using different XML namespaces. Operators need a coexistence map that records this overlap without converting it into an unsupported claim of equivalence everywhere.

A registry table invites a familiar but dangerous reading. Each row looks like a candidate in a ranking: one name, one reference, one status. When two rows address the same function, the instinct is to ask which one won.

That question mistakes a coordination record for a product verdict. The EPP Extension Registry exists because the Extensible Provisioning Protocol was designed to grow beyond its base commands and object mappings. Registries, registrars and software suppliers can introduce new protocol elements for operational needs that the core specification does not settle. A public catalogue makes those additions findable and gives their identifiers a stable home. It does not erase the institutional history that produced more than one answer.

The distinction is now explicit in draft-ietf-regext-ext-registry-epp-10, the proposed replacement for RFC 7451. The draft tells reviewers that multiple extensions with the same or similar functionality may be registered. An otherwise valid request should not fail merely because another entry already occupies the same functional neighbourhood. It also asks experts to be permissive when at least one registry/registrar or server/client pair has implemented and deployed the extension.

This is a low but meaningful threshold. It screens out an entirely abstract namespace claim. It does not perform a market election.

The admission decision is deliberately narrow

The EPP registry operates under the “Specification Required” policy described by RFC 8126. A request needs a permanent and publicly accessible specification, and the review is performed by designated experts. Under the current draft, acceptable references include RFCs and proprietary specifications that remain readily available; an English-language version must exist. An ordinary Internet-Draft is not a durable reference for a future registration, and the early-allocation route in RFC 7120 does not substitute for the process.

Those conditions protect a public namespace from becoming a collection of undocumented strings. They allow a future implementer to discover what an identifier was intended to mean. They also create a person or organisation that can answer for the submission. The live registry captures a name, document status, reference, registrant, applicable TLDs, IPR information, active or inactive state, and notes.

The expert's review has substance. The draft asks for architectural soundness, adequate privacy documentation, sensible URI construction and correct use of IETF or non-IETF XML namespaces. A primary expert normally handles the request. If unavailable, a backup pool decides as a group by simple-majority consensus. An expert who perceives a conflict must defer, and difficult questions can be exposed to the REGEXT mailing list.

None of that turns the review into comparative procurement. The expert is not instructed to decide whether an incumbent extension is more elegant, commercially successful or politically legitimate than a new one. The task is to decide whether the proposed entry is documented, technically coherent enough for the registry and grounded in real implementation. Registration prevents namespace ambiguity; it does not grant exclusivity over a function.

That boundary is especially important because the draft itself has not yet become an RFC. Revision 10 was issued on 17 August 2026. The Datatracker lists it as an active Internet-Draft intended to become a Best Current Practice, submitted to the IESG and waiting for editor assignment in the RFC Editor queue. If approved and published, it will obsolete RFC 7451. Until publication, its status and text can still change.

One deployment pair proves existence, not reach

The registry's permissive instruction rests on a practical unit: at least one registry/registrar pair, or more generally one server/client pair, has implemented and deployed the extension. That unit matters because EPP is a bilateral operating protocol. An extension that only a server emits or only a client understands cannot complete the intended exchange. A working pair provides more evidence than a design document alone.

But it is easy to stretch the claim beyond its evidentiary reach. One pair does not show that every registrar serving the registry supports the extension. It does not show that a registrar implements the same version across all of its registry connections. It does not show support for every TLD listed in the entry, or that optional fields behave identically in different software stacks. It says the mechanism crossed the boundary from specification into at least one real dialogue.

“Active” must be read with the same discipline. The registry defines an active extension as implemented and in use. An inactive one is not implemented or used, or its specification is no longer available. These are lifecycle signals, not adoption percentages. A row does not report transaction volume, failure rate, geographic reach, software coverage or operational dependency. Absence of those measurements should not be filled with an assumption of ubiquity.

The TLD field can help narrow scope, but even it is not a compatibility matrix. A list of zones associated with an extension does not say which client versions support it, whether use is mandatory or optional, whether a gateway translates it, or whether the same semantics apply in every zone. Registration supplies coordinates. Deployment evidence supplies reach.

The registry already contains parallel answers

The live IANA EPP Extension Registry, updated on 4 September 2026, provides unusually clear evidence that coexistence is not theoretical. It contains Standards Track and “Other” documents, and both active and inactive entries. More importantly, its notes identify pairs of extensions that overlap directly.

For internationalised domain names, the entry associated with CORE says it is syntactically and functionally identical to the corresponding TANGO extension but uses a different XML namespace. The registry gives the same kind of notice for CORE and TANGO privacy extensions. The functions align. The namespaces do not.

An operator cannot safely reduce that observation to “these are one protocol.” XML namespaces are part of the wire identity. A client prepared to send elements in one namespace does not automatically speak the other, even if the schemas and intended operations resemble each other. Servers may support one, both or neither. Policies, deployment dates, test suites and change-control arrangements can diverge after the point at which the note was written.

Nor should the operator read the two rows as evidence that competition failed. Parallel namespaces may reflect historical sequencing, separate communities, licensing or governance choices, different deployment relationships, or the cost of coordinating before implementation. The registry's job is to let those facts remain discoverable. Deleting one row to manufacture conceptual neatness could make old traffic and installed code harder to interpret.

The right question is not “which row deserves to exist?” It is “what exact claim can each row support?” A reference can establish the specification attached to a namespace. A registrant field can establish who requested the record. A status can show the registry's present lifecycle classification. A note can flag known overlap. None of those fields alone demonstrates substitutability in a particular provisioning system.

A coexistence map keeps the layers apart

Operators need a view built for decisions rather than a flat export of registry rows. I would call it a coexistence map. It is not a proposed IANA field set and it is not language from the IETF draft. It is an analytical layer assembled from registry data, specifications and operational evidence.

The first column should be functional class: IDN management, privacy, launch operations, fee information, contact handling or another durable capability. This allows overlapping entries to be seen together without declaring them equivalent.

The second should preserve wire identity: the XML namespace, schema location where relevant, command or response surfaces, and specification version. Namespace differences must never disappear behind a shared functional label.

The third should capture registration provenance: permanent reference, document status, registrant, date of expert action and review path. If a disputed request required mailing-list discussion or a backup-panel decision, that institutional context belongs with the entry.

The fourth should describe deployment evidence with explicit scope. Which registry/server and registrar/client pair has demonstrated use? On which date, version and TLDs? Was evidence supplied by both parties, inferred from documentation or observed in conformance testing? “At least one pair” should be recorded as exactly that, not upgraded to “industry deployed.”

The fifth should identify overlap claims. Is similarity asserted by the registrants, stated in an IANA note, demonstrated through schema comparison or observed in transactions? Does “functionally identical” cover every operation, error path and optional field, or only the documented core? A claim can be strong without being universal.

The sixth should show current client/server support and translation behaviour. If a gateway maps one namespace to another, the map should state who owns the mapping and what information can be lost. If no translation exists, that negative fact is operationally valuable.

The seventh should preserve lifecycle history. The draft distinguishes modification, deactivation and removal, but it also admits that the registry has no history mechanism and a removed entry cannot be tracked there afterwards. A coexistence map therefore needs dated snapshots or another durable record. Otherwise retirement can destroy the evidence needed to understand old logs, contracts or failed transactions.

Together, these columns stop four claims from collapsing into one: an extension is registered; an extension has been deployed somewhere; an extension is supported here; an extension is interchangeable with another. Each can be true while the next is false.

Modification and removal alter the evidence surface

The new draft does more than clarify admission. It describes procedures for inserting, modifying, deactivating and removing entries. Status changes require a rationale. Removal of an IETF-consensus entry requires IESG approval. A non-IETF entry can be removed or deactivated by the IESG or by its original registrant working with the designated experts.

These controls recognise that the table is an operational dependency. Yet the absence of native history creates an asymmetric risk. Adding a competing extension increases the visible record. Removing one can make earlier dependencies less intelligible, especially if its specification also becomes unavailable. The immediate table may become tidier while the ability to reconstruct the past becomes worse.

That is why inactive status and removal are not interchangeable. Inactivation keeps a coordinate for an implementation that should no longer be selected for new use. Removal takes the coordinate out of the present registry. Where old transactions, software or contracts may still cite the namespace, preservation should be the default evidentiary instinct even if active use has ended.

The same principle applies to modification. Updating a reference, TLD list or note may improve the current row, but an operator investigating an older exchange needs to know what the registry said at that time. A current-state catalogue can coordinate present implementations. It cannot, without snapshots, settle historical disputes.

Standards status is a separate axis

The IANA table places different kinds of documents in one operational catalogue because the namespace must cover what implementers encounter. This coexistence is useful, but it invites another false hierarchy: a row in an IANA registry can look official enough that its underlying document status disappears.

RFC 2026 distinguishes stages and streams in the Internet standards process. RFC 7451 created a registration framework; RFC 8126 defines registration policies; RFC 5730 defines EPP's base protocol; RFC 3735 explains how EPP is extended. A proprietary specification admitted under Specification Required has not become a Standards Track RFC merely because IANA records it next to one. Conversely, a non-Standards-Track extension can still be an important operational dependency.

The coexistence map should therefore show standards status without using it as a proxy for deployment. “Standards Track” and “widely used” answer different questions. So do “Other” and “unreliable.” Governance becomes clearer when institutional legitimacy, technical specification and installed reach are visible as separate axes.

Sources