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

[Michael Jones <[e-mail]>]

I would not allow % encoding or any other kind of encoding because that requires canonicalization to perform comparison. These are identifiers for machines to use - not people. There's no reason to allow anything other than printable ASCII characters in identifiers for programmatic use.

Keep simple things simple.

				-- Mike

-----Original Message-----
From: Rohan Mahy <[e-mail]> 
Sent: Saturday, February 14, 2026 8:10 AM
To: Orie <[e-mail]>
Cc: Arnt Gulbrandsen <[e-mail]>; John C Klensin <[e-mail]>; Patrik Fältström <[e-mail]>; Tim Bray <[e-mail]>; Brent Zundel <brent.zundel=[e-mail]>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [SPICE] Re: [art] Re: [Last-Call] Re: Re: Re: draft-ietf-spice-glue-id-04 ietf last call Artart review

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