Summary

  • A current REGEXT draft would let an extension’s recorded contact, or the IESG for any entry, request a dated deprecation in the IANA RDAP Extensions registry. That changes the registry record; it does not remotely remove code from servers or clients.
  • A companion versioning draft gives servers start, end, default, predecessor and successor signals in /help, identifies the version used in each response and lets clients request a version. These signals coordinate a transition but do not enumerate an unknown client population.
  • Operators need a retirement receipt that separates the authorized registry act, each server’s advertised and observed state, sampled client demand and the uncertainty that remains. This is Daniel Kade’s governance proposal, not an IETF requirement.

The cleanest software retirement appears to fit in one cell. Add a date beside an old name, announce a replacement and, after a decent interval, delete the compatibility path. Registries are good at the first act. They preserve a public vocabulary and identify the authority entitled to change its recorded state. Distributed protocols are much worse at the last act. A client need not register before it asks a public RDAP server a question, and the server may never learn who maintains it or how urgently it depends on a particular response shape.

That gap is unusually visible in two active documents from the IETF Registration Protocols Extensions Working Group. Revision 15 of RDAP Extensions, dated 13 August 2026, proposes a Deprecation Date field for the IANA RDAP Extensions registry. Revision 07 of Versioning in the Registration Data Access Protocol, dated 31 July, proposes protocol machinery for announcing supported versions, defaults, replacements and end times. Together they describe a plausible migration. They also show why a registry date, a server deadline and client readiness are not the same fact.

Both documents remain Internet-Drafts. Datatracker records them as REGEXT Working Group documents intended for the Standards Track, not RFCs or deployment mandates. Revision 15 is in a “Revised I-D Needed — Issue raised by WG” state and has no responsible Area Director. Their detail is valuable precisely because it exposes an unresolved governance problem without granting anyone more authority than the process currently provides.

The registry controls a name’s public status

RDAP extends its base query and response formats through identifiers carried in rdapConformance and in names, paths, parameters or other protocol elements. Those identifiers prevent collisions and lead implementers to specifications. They are opaque. A suffix that looks like a version number does not, on its own, prove that one identifier replaces another. An operator must consult the defining documents.

Revision 15 would give each registry row a full-date deprecation field. The contact named in the registry could ask IANA to deprecate its own extension. The IESG could ask IANA to deprecate any RDAP extension. The proposal therefore names two possible sources of authority and one custodian of the resulting record. It does not say that any user of the old extension has transferred deployment control to those actors.

The draft also asks IANA to attach 21 August 2025 to two ICANN identifiers already shown as obsolete: icann_rdap_response_profile_0 and icann_rdap_technical_implementation_guide_0. At this research cutoff, the live registry—last updated on 1 September 2026—shows both identifiers as OBSOLETED, alongside their version-one successors, but does not yet display a separate date column. That is not evidence of an IANA failure. The new field is proposed by a working document that has not become an RFC.

The distinction matters beyond procedural courtesy. “Obsolete” answers a registry question: how should readers understand this identifier now? It does not answer a deployment question: which servers still emit it? Nor does it answer a dependency question: which clients still parse it, request behavior associated with it or fail if it disappears? A public registry can make the first answer authoritative while remaining entirely honest about not knowing the other two.

The registration rules reinforce the registry’s narrower role. The current policy is Specification Required with Expert Review. Revision 15 would ask for at least three reviewers, ideally four or five, and require a second expert to double-check an assigned registration. A specification must be stable, readily available and detailed enough for independent implementations to interoperate. Those are strong admission controls over shared vocabulary. They are not an inventory of deployed software.

The server controls what it is willing to serve

The versioning draft operates at a different layer. Its proposed versioning_help member lets a server describe extensions and versions it supports, identify a default, point to documentation, relate a predecessor to a successor and publish start and end times. Its versioning_data member records which extension versions shaped a particular response. A client can use a versioning_list media-type parameter to express the versions it wants.

This creates three records where an undifferentiated sunset notice offered one. /help describes a server’s support policy. versioning_data describes a returned representation. The client’s request describes a preference for that exchange. None should be silently substituted for another. A server may support an old version without using it by default. A response may use the new version because the client asked for it while the old one remains available. A client may omit a preference and receive the default without proving it understands every alternative.

The proposed end member is particularly easy to overread. It is the date and time at which an extension-version object will cease to be supported. Once that time passes, the object must be removed from the advertised set. If end is absent, no support expiry is planned. This is a precise statement about the server’s declared behavior. It is not a certificate that every downstream client completed a migration.

Revision 07 recommends an intermediate stage for incompatible changes. The server exposes both deprecated and replacement elements, advertises the transition in /help, permits old clients to continue during the period and later removes the deprecated form. A second pattern overlaps versions, moves the default and allows clients to select the old version until its end. These are sensible mechanisms for reducing abrupt breakage.

But the server chooses how many versions to support and how long to overlap them. “Sufficient time” cannot be derived from the calendar alone when clients are not enrolled. A ninety-day overlap can be generous for a centrally managed fleet and reckless for archived scripts used only during annual reporting. The protocol can expose a door and its closing time. It cannot prove that every person who may use the door read the notice.

Unknown clients are a fact, not a permanent veto

Revision 15 states the hard limit directly: there is no relationship between an RDAP client and an RDAP server that would allow anyone to determine absolutely that a breaking change has no effect on all clients. Public query interfaces are valuable partly because they do not require a bilateral contract. The same openness weakens the operator’s ability to conduct a complete migration roll call.

This does not mean an old interface can never be removed. Turning uncertainty into a permanent veto would create a different governance failure. Compatibility code accumulates, contradictory semantics survive and security or privacy improvements can be delayed by hypothetical users who never identify themselves. The correct response is not certainty but bounded evidence.

Request telemetry can show that a particular server received old-version demand during an interval. It can identify concentrations by client software signature, network or authenticated account where those signals lawfully exist. It may show that demand fell after the default changed. Yet public RDAP requests can contain registration targets and network identifiers. A migration programme that collects indefinite, linkable client histories to prove readiness would solve an interface problem by creating a privacy problem.

Absence must therefore be worded carefully. “No old-version request was observed on these servers during this measured period under this sampling policy” is defensible. “No client depends on the old version” is not. Likewise, one successful new-version response proves that one path worked at one time. It does not prove that referrals, redirects, caches, libraries and periodic workflows have converged.

A retirement receipt for three authorities

A useful retirement receipt would begin with the exact extension identifier and, where defined, exact version. It would record whether the registry action was requested by the listed contact or the IESG, the date accepted by IANA and the visible registry state. That is the authority receipt. It should not claim to be a server rollout record.

The second section would describe the compatibility contract. What is the predecessor? What is the successor? Is the change syntactic, semantic, policy-driven or a combination? Which fields, paths or parameters disappear? Can old and new representations coexist without ambiguity? Where is the stable specification? A bare numerical suffix is not enough.

The third section would be per server or operational cohort. It would preserve dated /help observations, default changes, announced start and end times, representative versioning_data, error behavior for unsupported requests and the rollback rule. Planned and observed removal would be separate fields. A server that misses its own end date should reveal drift rather than rewrite the plan after the fact.

The fourth section would summarize demand without pretending to identify the world. It would state the measurement window, servers covered, exclusions, privacy aggregation, old-version request count or rate, known managed clients contacted, unresolved high-impact clients and the decision rule used. If no client signaling exists, the receipt should say so. If telemetry is unavailable, “unknown” is better than a fabricated zero.

Finally, the receipt would record the removal decision, decision-maker, evidence cutoff, exceptions and post-removal observation. It would link incidents or rollbacks without treating their absence as proof of universal success. The record would remain intelligible if the IANA entry changes first, if one operator keeps compatibility longer or if a replacement document itself is revised.

This structure reflects a simple allocation of power. The registry authority controls the public status of a name. The server operator controls the interface it serves. The client operator controls the software it upgrades. Coordination can link their acts; it cannot merge their mandates.

Sources