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

Dear Dale,

Thank you for your insightful feedback. You have identified a critical
point where this proposal could face a political deadlock: the issue of
authority and delegation.

I would like to clarify that my proposal does not seek to establish a new
governance mechanism or require the IETF to appoint "National Registrars."
Instead, I am proposing a semantic and syntactic framework for a "Class of
NIDs" already reserved by RFC 8141, Section 5.1.

To address your points:

1. Semantics over Governance

The goal is to define that any URN starting with "urn:<iso-3166-alpha2>:"
carries a Territorial Context.

Just as the "tel:" URI scheme (RFC 3966) relies on the E.164 standard
without the IETF having to manage every national phone numbering plan, this
proposal leverages ISO 3166-1 to provide a predictable namespace. The
"authority" is not a person or agency designated by the IETF, but the
intrinsic issuer of the identifier within that territory.

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.

3. Avoiding the "Registrar" Trap

I believe we can bypass the political problem by treating these NIDs as
self-managed territorial namespaces.

Instead of the IETF choosing a registrar (e.g., ANSI vs. Federal
Government), the RFC may simply state that the NSS for this NID class is
opaque to the IETF, and its internal structure is managed according to the
practices of the entities operating within the corresponding ISO 3166
territory.

4. Why an RFC Update is the right path

As you mentioned, this would update RFC 8141. The core of the proposal is
to:
- Formalize the 2-letter NID space as a "Territorial Class".
- Standardize the NSS delimiter pattern (<type>:<id>) to ensure global
parseability.
- Explicitly decouple IETF/IANA from national-level politics, delegating
the responsibility of collision avoidance within the NID to the resource
issuers of that territory.

I am prepared to draft an initial Internet-Draft that specifies this
"Territorial Class" without the need for individual NID registrations if
the community agrees that focusing on the syntactic framework (like "tel:"
URIs) rather than administrative delegation is a viable path.

Thanks again for your comments. They provide a perspective I had
overlooked, yet it is crucial to address in this matter.

Best regards,

Jesús Alonso Abad

On Mon, Feb 16, 2026 at 5:17 PM Dale R. Worley <[email protected]> wrote:

> This is quite interesting.  I think the next step is to flesh out what
> the "formal proposal" is, as your initial e-mail is rather sparse in
> details.
>
> Ultimately, this requires an RFC to update RFC 8141.  Since RFC 8141 is
> Standards Track, the new RFC would have to be also.
>
> You talk about the syntax of the new class of URNs but you don't
> specify it very clearly.  IIUC, the base is to define
> "urn:<country-code>:..." to be a class of URNs whose allocation is
> delegated to "the authorities" of the country/territory/etity with that
> ISO alpha-2 code <country-code>.
>
> I think beyond that, you intend to specify that *all* of these URNs will
> have the format "urn:<country-code>:<id-type>:<id>", where <id-type> is
> a code for a type of identifier issued by the authorities of
> <country-code>, and <id> is one of those identifiers.
>
> At first sight, this seems to be restrictive, in that there can't be any
> country-specific URNs that aren't country-issued IDs.  But on second
> thought, that isn't really a restriction, as any country-specific URN
> namespace is a "type of identifier issued by the authorities".
>
> Of course, with URNs a lot of the definition is defining how the space
> is administered.  (Hence we are talking about this proposal here!)  So
> there needs to be some systematic registration of the delegations for
> <country-code>s to suitable "national registries", with each national
> registrar formally undertaking to administer the allocation of the
> <id-type> "sub-namespaces".
>
> There is the messy political problem of when the
> government/territory/authority for particular <country-code> changes.
> But the registrar of ISO.3166 has to make such decisions, and the IETF
> can simply copy ISO's actions.  But even when the political entity for a
> <country-code> is well-defined (because we copy the ISO), how do we
> choose the registrar entity?  If the recognized government of the
> country designates a registrar, that's reasonably simple, but e.g. I can
> easily imagine the US federal government to not care and it falls by
> default to ANSI ... and a decade later, some other organization disputes
> the designation.
>
> Dale
>


-- 

Jesús Alonso Abad

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