Summary

  • Revision 05 of the proposed RDAP extension for DNS DELEG removed references to priority and target, renamed its structure DelegInfos, and rebuilt its examples around DELEG-11.
  • The EPP provisioning draft named as a normative dependency still defines priority and target attributes in what it calls a complete XML schema.
  • The RDAP draft requires the dnsDeleg conformance identifier but still marks the complete specification of its JSON key/value pairs as TBD.
  • No source proves a deployed failure. The present evidence supports a narrower conclusion: the three evolving documents do not yet define one testable EPP-to-DNS-to-RDAP round trip.

The read side moved first

The I-D announcement records publication of draft-albanna-regext-rdap-deleg-05 on 4 September 2026. Its job sounds modest: let a Registration Data Access Protocol response for a domain include the new DELEG information being designed for DNS delegation.

The change log makes the important edit unusually easy to see. Revision 05 says it removed references to the list members priority and target, renamed delegInfo to DelegInfos, and changed its examples to follow draft-ietf-deleg-11. The current DELEG-11 text explains why. Unlike the SVCB format that inspired it, DELEG has neither SvcPriority nor TargetName. Its payload is a list of DelegInfo key/value pairs.

DELEG-11 currently defines four name-server-information keys—server-ipv4, server-ipv6, server-name and include-delegparam—plus the mandatory metadata key. It also proposes a dedicated IANA registry so future keys can acquire a numeric code, presentation name, meaning, stable reference and change controller. That is a serious attempt to make extensibility bounded rather than improvised.

The RDAP companion now reflects the field deletion in prose and examples. That is the read side: what a registry-data client would see in a JSON response.

The cited write side still speaks the older shape

The same RDAP draft says its definition is based on both DELEG and the EPP mapping for DELEG records. The latter matters because EPP is the protocol family through which sponsoring clients manage domain objects at registries. RFC 5731 supplies the existing domain-name mapping; the new EPP draft proposes the additional DELEG elements for create, update and info commands.

In EPP DELEG revision 02, the formal-syntax section calls itself a complete schema suitable for automated validation. Its delegType still has an unsigned-short priority attribute and a target attribute. Its parameter container accepts arbitrary attributes with processContents="skip". That revision is dated 21 July, two days before DELEG-11, and has not incorporated the model now followed by RDAP revision 05.

This does not prove that any registrar sends those fields, that any registry stores them, or that an RDAP server drops them. The two companion drafts are individual submissions, and the evidence reviewed here contains no production trace. The observable fact is narrower: a writer that validates against the displayed EPP schema can produce a shape that the current DELEG base says does not exist and the current RDAP draft has deliberately removed.

The documents do not yet say what a bridge must do with that difference. Reject the two attributes? Ignore them? Preserve them as private parameters? Translate them into another construct? A standards reader can infer possibilities, but cannot reproduce a normative answer.

dnsDeleg names an extension, not its transformation history

Revision 05 says a response containing its data MUST include dnsDeleg in rdapConformance. RFC 9083 describes those strings as identifiers for specifications used to construct an RDAP response. They help clients recognize custom JSON. They do not attest to the provenance of each value or prove that a write representation survived a round trip.

That limitation matters here because the response specification itself still says TBD where the complete set of key/value pairs should be defined. It may later cite DELEG, the EPP mapping, or both. The examples show a destination, but the normative conversion table is not present.

The live IANA RDAP Extensions registry did not list dnsDeleg when this research was frozen. The draft requests that registration with operator “Any” and itself as the specification. That absence is not an IANA refusal; it is the current state of a proposed identifier.

There is already separate work on the broader transition problem. The REGEXT RDAP versioning draft proposes machine-readable extension versions, predecessor and successor relationships, deprecation notices and migration policy. RDAP DELEG revision 05 does not currently use that machinery or declare which schema identity produced a payload.

Three documents have three different levels of standing

Datatracker labels the RDAP text an active individual Internet-Draft with no RFC stream and no responsible Area Director. The EPP mapping is also an individual draft without an RFC stream. Anyone may submit such a document; publication does not equal IETF endorsement.

DELEG-11 has stronger process standing: it is a DELEG Working Group document in Working Group Last Call. It is still a draft. Its requested DNS RR assignments and new Delegation Information registry include values that remain requested or provisional. The three statuses should not be compressed into a claim that a finished stack exists.

Nor should the current difference be inflated into an incident. The likely explanation is ordinary dependency lag between drafts moving at different times. Precisely because it is repairable, the seam should be made explicit before implementations turn editorial history into incompatible state.

The missing artefact is an executable custody map

A complete contract would answer four questions. Which revision defines each field? How does an EPP input become authoritative DNS data? How does that DNS state become RDAP JSON? Which information is deliberately lost at either edge?

Until those answers are normative and testable, dnsDeleg can say that an extension is present but not which path produced it. The public query may be accurate to its own database while still leaving the reader unable to distinguish registry intent, authoritative DNS observation and local projection policy. That is a governance boundary because the party controlling the conversion controls which statement becomes visible.