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

[Orie <[e-mail]>]

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