[urn] Re: Proposal: Activation of RFC 8141 Section 5.1 R eserved NIDs via a Territorial URN Framework

Dear Dale,

Thank you for your question. It perfectly highlights the "missing link" in
my proposal.

In a purely technical implementation like mine, the mapping of "dni" to
"Spanish National ID" is currently implementation-defined (within the
library's logic). To make it a formal standard, as you suggest, we would
need a deterministic registry for these sub-types.

However, after considering the broader feedback regarding the institutional
requirements for national registrars, it is clear that defining these
semantics globally would require a level of administrative coordination
that is beyond my knowledge and energy.

I will step back from the formal proposal, but I appreciate your help in
clarifying why the transition from a "reserved" space to an "active" one is
so complex.

Best regards,

Jesús Alonso Abad

On Tue, Feb 17, 2026 at 4:22 PM Dale R. Worley <[email protected]> wrote:

> Jesús Alonso Abad <[email protected]> writes:
> > 2. The NSS Structure: <id-type>:<id>
> >
> > Your interpretation is correct. The intended syntax is:
> > "urn:<country-code>:<id-type>:<id>".
> >
> > This is deliberately minimalist. By defining this structure, we provide a
> > community standard where <id-type> (e.g., "dni", "ssn", "vat") acts as a
> > sub-namespace. My implementation (international-urns on PyPI) shows that
> we
> > do not need a central registrar to make this useful. If a developer uses
> > "urn:es:dni:...", they are invoking the semantics of a Spanish National
> ID.
> > The URN provides a collision-resistant, semantically clear string
> > regardless of who the official registrar is.
>
> How is it determined that "urn:es:dni:..." refers to the Spanish
> national ID, as opposed to some other Spanish identifier?
>
> Dale
>


-- 

Jesús Alonso Abad

_______________________________________________
urn mailing list -- [email protected]
To unsubscribe send an email to [email protected]