Summary

  • RFC 9517 registers ddi as a formal URN namespace whose names combine an approved agency identifier, an agency-assigned resource identifier and an explicit version identifier.
  • Resolution is a chain: transform the agency name into ddi.urn.arpa, follow DNS/DDDS and NAPTR delegation, select a service, then request the original URN. Each step has a different operator and failure surface.
  • A valid, persistent name is not proof of assignment, live resolution, repository authority, object integrity, preservation or research fitness. Those conclusions require separate receipts.

The audit began with the strongest-looking object in the room: a permanent identifier. It had an agency, a resource and a version. It passed the parser. A registry listed the namespace. Yet the resolver returned two services, one timed out, and the other supplied metadata for an object whose stored bytes no longer matched the preservation manifest.

Nothing in the identifier was false. The mistake was asking the name to testify about the systems behind it.

RFC 9517, published in January 2024 as an Informational Independent Stream document, registers the formal ddi namespace for resources that conform to Data Documentation Initiative standards. It is not an IETF Standards Track specification and does not represent IETF community consensus. Its design is nevertheless operationally valuable because it exposes the custody chain behind a durable research-data name.

Three fields create identity only when three authorities do their work

A DDI URN has the shape urn:ddi:<agency-identifier>:<resource-identifier>:<version-identifier>. The agency identifier follows reversed-domain conventions. The DDI Alliance approves that identifier; the agency then allocates resource and version identifiers inside its own scope.

That division prevents one central registry from assigning every item in every archive. It also means uniqueness is compositional. The DDI Alliance must keep agency names unique. Each agency must prevent collisions in its own resource and version space. A syntactically correct string proves neither duty was performed.

RFC 8141 supplies the wider rule: a string beginning with urn: is not made into a valid assigned URN merely by matching the grammar. The namespace identifier must be registered, and the rest of the name must be generated under that namespace's managed assignment process. This distinction matters to ingestion systems. A parser can say “well formed”; only registry and agency evidence can say “assigned here.”

Comparison rules add another trap. urn, ddi and the agency portion are case insensitive. Resource and version identifiers are case sensitive. A normalizer that lowercases the whole string can silently merge two resources the agency meant to keep distinct. Conversely, treating agency case as significant can create duplicate records for the same authority. The comparison receipt must record the original bytes, parsed components and the normalization actually applied.

Persistence belongs to an institution, not to punctuation

The colons make the identifier look durable. They do not preserve anything.

RFC 9517 says persistence depends on suitable resolution delegation and continued agency assignment. Preservation of the referenced resource remains the agency's responsibility. That is a governance statement embedded in an identifier specification: the name can remain stable while a name server, registry, repository, access policy or object disappears.

Versioning sharpens rather than removes the problem. A version identifier lets an agency distinguish revisions. It does not prove that a repository returned the requested revision, that two repositories hold identical bytes, or that the agency still considers the object authoritative. A consumer needs the returned identifier, content hash, provenance, preservation record and policy context. The version segment is a key for that inquiry, not the conclusion.

Sub-agencies make delegation more flexible. They can also make an incident harder to read. A parent agency may remain approved while a sub-agency's resolver points elsewhere, expires or changes custody. Evidence should therefore retain the full authority path rather than compressing everything into “DDI resolved.”

Resolution is a sequence of decisions

RFC 9517 maps the agency portion into DNS. A client extracts the text between the second and third colon, normalizes its case, reverses its dot-separated labels and appends .ddi.urn.arpa. For an illustrative agency us.ddia1, the lookup begins at ddia1.us.ddi.urn.arpa.

The request can pass from the urn.arpa authority to the DDI Alliance and then to the relevant agency. NAPTR records describe available services. A terminal u rule can produce a URI; an s rule can direct the client to an SRV lookup. The client selects a suitable service and submits the original DDI URN.

This is not one lookup. It is a chain of administrative delegation, cached DNS state, record interpretation, service selection and application response. The expected DDDS output is connection information for one or more agency services. It is not the resource and does not prove that the service is reachable, still authorized or serving the requested version.

A useful operational record includes the resolver, query time, TTL and cache age; validation and encrypted-transport state; every NAPTR order, preference, flag, service, expression and replacement; any SRV result; the selected endpoint and why it was selected; its TLS identity; and the final response. Without those details, “the URN resolved” conceals which authority actually spoke.

A resource, a description and a locator are different answers

The document sketches several potential service classes. I2R returns an instance of the identified resource. I2C returns characteristics or a description. I2L returns one locator; I2Ls returns several. Their service tags and fuller definitions are left for later work.

That unfinished edge is important. A registry response can accurately describe an object that is currently unavailable. A locator can point to a location that no longer serves it. Several locators can disagree. A resource response can carry bytes without proving those bytes are the preserved or authoritative version.

Automation must retain the service type. Converting all successful responses to found=true erases whether the system found an object, metadata, one possible location or a set of alternatives. It also invites a harmful fallback: accepting descriptive metadata as if it were the evidence object simply because the repository timed out.

Transport privacy does not authenticate the research object

RFC 9517 describes the public-information namespace as having a low security profile, while acknowledging that DNS resolution is only as secure as DNS generally. It points to the DNS threat analysis in RFC 3833 and notes that DNS over HTTPS can protect traffic between a client and its chosen resolver from eavesdropping and manipulation on that link.

DoH does not validate the resource. It does not prove the resolver chose an authentic delegation, that the agency still authorizes the endpoint, that TLS terminates at the intended custodian, or that the returned metadata is correct. DNSSEC status, encrypted resolver transport, service TLS, agency authorization and object-level signatures or hashes are separate facts.

The evidence ladder should remain explicit. First validate the namespace registration and syntax. Then establish agency approval and resource assignment. Observe the delegation chain. Interpret the service record. Authenticate the endpoint. Bind its answer to the exact case-sensitive resource and version. Validate the object and provenance. Only then ask whether the material is fit for the research or governance decision.

The durable identifier is doing valuable work throughout. It keeps the question stable while infrastructure and custody change. Its discipline is lost only when the name is promoted into a guarantee the namespace never made.

Sources