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

Howdy Ted,

Thank you for bringing up the precedent of RFC 4350 and the New Zealand
case. That historical context is very helpful.

It is clear from your explanation that "activating" these reserved NIDs is
not just a syntactic update to RFC 8141, but an institutional challenge
involving national authorities and formal registrations. I certainly do not
intend to "end run" around the established process, nor do I have the
diplomatic reach to coordinate national namespace authorities.

My primary goal was to ensure a compact and collision-resistant format for
territorial identifiers. Given that Section 5.1 already provides the
necessary protection by reserving these two-letter strings, I am satisfied
with that safety net.

I will refrain from pushing this as a formal Standards Track proposal, as
the bureaucratic lift is indeed far from trivial. I will keep the
implementation as a community-driven tool for those who wish to use the
reserved space under these conventions.

Best regards,

Jesús Alonso Abad

On Tue, Feb 17, 2026 at 4:44 PM Ted Hardie <[email protected]> wrote:

> Howdy,
>
> The text in RFC 8141 says:
>
>        such strings are reserved for potential
>        use as NIDs based on ISO alpha-2 country codes [ISO.3166-1 <https://datatracker.ietf.org/doc/html/rfc8141#ref-ISO.3166-1>] for
>        eventual national registrations of URN namespaces (however, the
>        definition and scoping of rules for allocation of responsibility
>        for such country-code-based URN namespaces are beyond the scope
>        of this document).  As a consequence, it MUST NOT start with the
>        string "xn--" or any other string consisting of two letters
>        followed by two hyphens; such strings are reserved for potential
>        representation of DNS A-labels and similar strings in the future
>        [RFC5890 <https://datatracker.ietf.org/doc/html/rfc5890>].
>
> There has been one attempt to register a two-letter NID (
> https://www.rfc-editor.org/rfc/rfc4350.html describes it).  I think it is
> the case that if we created a process to register them that other
> governments might follow New Zealand's lead and create formal namespaces.
> Creating that process is not a trivial task, but I don't think we can end
> run around it because the registrations require someone to stand up as the
> organization that meets the requirements of RFC 8141, Section 5.1.   You
> could, in parallel, suggest that the government led namespace authorities
> consider a common set of internal structures, but you certainly couldn't
> require it; they may have other designations already in use.
>
> best regards,
>
> Ted Hardie
>
> On Mon, Feb 16, 2026 at 7:14 PM Jesús Alonso Abad <
> [email protected]> wrote:
>
>> 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]
>>
>

-- 

Jesús Alonso Abad

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