[art] Re: [SPICE] Re: Re: [Last-Call] Re: Re: Re: draft-ietf-spice-glue-id-04 ietf last call Artart review

[Rohan Mahy <[e-mail]>]

I think there are three questions that follow from this discussion:
- do we want national/regional identifier systems to be registered? For
example, the example of the US tax ID number was brought up as an example
when the draft was introduced to the WG. The draft already mentions a
hypothetical system that has different registrations in Singapore and Korea
as two separate Authority Identifiers, so I'd say the document implies they
should be allowed.
- do we want to allow or encourage internationalized domain names for the
names of any non-ASCII Authority Identifiers? If so, punycode is a logical
way to represent them.
- is it the responsibility of the GLUE spec to define how non-ASCII
characters (if any) are represented in the rest of the URN (after the
Authority Identifier and colon), or should that be left to the individual
registrations?

thanks,
-rohan

On Fri, 13 Feb 2026, 14:50 Orie, <[e-mail]> wrote:

> Hi all,
>
> It's great to see so many comments on this draft : )
>
> I am wondering if anyone is aware of any global business or legal entity
> identifier systems which are not based on US ASCII ?
>
> I don't think the IETF should specify a business identifier system that
> supports more than US ASCII without a compelling example of one in the wild.
>
> I had gemini do a little research and the only one that showed up was our
> old friend IDNs : )
>
> BEGIN RESPONSE FROM GEMINI
>
> There are currently no major *global* business identifier standards where
> the **identifier code itself** uses non-Latin (non-ASCII) characters.
>
> If a business in Tokyo, Cairo, or Beijing gets a global identifier, that
> code will almost certainly consist of **Latin letters (A-Z)** and **Arabic
> numerals (0-9)**.
>
> The reason is **interoperability**. Global financial infrastructure (like
> SWIFT networks, customs databases, and stock exchanges) relies on legacy
> systems that cannot reliably process characters like "Д", "Φ", or "中" in
> the identifier field without risking data corruption or transaction failure.
>
> However, there is a major distinction between the **Identifier Code** (the
> tag) and the **Entity Data** (the content).
>
> ### 1. The Code vs. The Data
>
> While the ID *code* is almost always ASCII, the *records* attached to that
> ID increasingly support local scripts.
>
> | Identifier | The Code (ASCII/Latin) | The Data Record (Unicode) |
> | --- | --- | --- |
> | **LEI** (Legal Entity Identifier) | `5493000IBP32UCZ95H59` | Can store
> the company name as **腾讯** (Tencent) or **БАНК** (Bank). |
> | **SWIFT / BIC** | `KOEXKRSE` | The bank's name and address can be stored
> in local character sets in modern registries. |
> | **USCC** (China) | `91110000710925462X` | Even China's national standard
> uses Latin letters and numbers for the code itself to ensure it works with
> Western software. |
>
> ### 2. The "Language-Neutral" Approach (Numeric IDs)
>
> To avoid the bias of the Latin alphabet, many global standards rely
> strictly on **numbers**. While these are technically "ASCII digits" (0-9)
> in computer systems, they are considered culturally neutral because they
> don't require knowledge of the English alphabet to transcribe.
>
> * **DUNS Number:** A unique 9-digit code (e.g., `12-345-6789`). It
> contains no letters, making it usable by anyone who reads Arabic numerals.
> * **GLN (Global Location Number):** A 13-digit number used in logistics
> (GS1 standard).
>
> ### 3. The One Exception: Internationalized Domain Names (IDNs)
>
> The only widely used "business identifier" that allows non-ASCII
> characters is the **Internet Domain Name**.
>
> If you consider a website address a business identifier (which it
> effectively is in digital commerce), this is the only place where non-Latin
> scripts are standard.
>
> * **Example:** `http://见.香港 <http://xn--6x2a.xn--j6w193g>` (A domain
> ending in .HongKong)
> * **Example:** `http://сбербанк.рф <http://xn--80abap1arsf.xn--p1ai>`
> (Sberbank in Russia)
>
> ### Why doesn't a "Unicode Business ID" exist?
>
> Technically, we *could* create a business ID that uses Chinese or Arabic
> characters today. We don't do it because of **the keyboard problem**.
>
> If a German customs agent needs to input the ID of a Thai supplier, they
> cannot type `บริษัท` on a German keyboard. If the ID is alphanumeric
> (`TH-12345`), they can type it instantly. Until input methods become
> universally seamless, global identifiers will likely remain stuck in the
> Latin alphabet.
>
> ### Summary Table of Global IDs
>
> | Identifier | Full Name | Character Set | Status |
> | --- | --- | --- | --- |
> | **LEI** | Legal Entity Identifier | **ISO 17442** (Latin + Numbers) |
> The "Gold Standard" for global finance. |
> | **USCC** | Unified Social Credit Code | **GB 32100** (Latin + Numbers) |
> China's standard. notably uses Latin letters. |
> | **DUNS** | Data Universal Numbering System | **Numeric** (0-9) | Private
> standard, widely used in US/UK supply chains. |
> | **EORI** | Economic Operators Registration | **Alphanumeric** (Latin +
> Numbers) | Used for customs in the EU. |
>
>
> On Fri, Feb 13, 2026 at 4:14 AM Arnt Gulbrandsen <[e-mail]>
> wrote:
>
>> Thanks, Patrik and John.
>>
>> John C Klensin <[e-mail]> writes:
>> > However, I think that what Patrik and I are saying in different
>> > ways is that, if you start by specifying syntax, rather than
>> > having the WG understand the issues involved, including the
>> > decisions that need to be made, and having at least preliminary
>> > draft text to deal with them, you just specify syntax, you
>> > invite a world of pain and hurt.
>>
>> Please please please don't start with syntax.
>>
>> > That is especially important since there may be interactions
>> > between substantive choices and optimal choices of encoding
>> > systems (and hence syntax).   Even if you say "just do what RFC
>> > 3987 IRIs do", that raises other issues, starting with whether
>> > that is really the best spec to cite for (if I understand the
>> > intent of the SPICE work correctly) in the definition of a URN
>> > namespace.  So I am suggesting that the order of events/
>> > consideration should be:
>> >
>> > (1) Decide whether non-ASCII identifiers are going to be
>> > allowed.  If not, preferentially explain why and incorporate the
>> > explanation in the document.  If so...
>>
>> At a quick glance, all of the current identifier authorities
>> appear to use arabic digits. It's not obvious to me that even the
>> full ASCII range is required. But if ASCII letters are required, I
>> suspect that the same argument will apply to other letters.
>>
>> > And, unfortunately, Patrik and I both have scars from attempts
>> > to do this in other ways, including "syntax first, rules and
>> > semantics later" approaches.  So do many others around the IETF.
>> > Let's not make that mistake again.
>>
>> Yes yes yes yes yes.
>>
>> Arnt
>>
>> --
>> SPICE mailing list -- [e-mail]
>> To unsubscribe send an email to [e-mail]
>>
>