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

Jesús,

I think this is fine and you are on the right track thanks to Dale's
and Ted's comments.  Let me add one thing to clarify the difference
between what you proposed and an example you gave.  "tel:" is
actually highly structured, with the top-level "country codes"
coordinated by the ITU and a collection of treaties that put limits
on how nationally-assigned (or delegated) numbers are structured,
starting with a requirement that they be numeric.  Assignment of
numbers after the country code is a national matter, but countries
are required to have a system and use it, at least if they want to
support calling out of or into the country.  So the analogy doesn't
work, absent the sort of treaties that make a single system and runs
for what can and cannot be done within a country.  As you say,
institutional challenge involving national authorities, etc.

best,
    john

--On Tuesday, February 17, 2026 19:28 +0100 Jesús Alonso Abad
<[email protected]> wrote:

> 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]
>>> 


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