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

[John C Klensin <[e-mail]>]

--On Saturday, February 14, 2026 11:47 +0100 Arnt Gulbrandsen
<[e-mail]> wrote:

> Rohan Mahy <[e-mail]> writes:
> 
>> I think there are three questions that follow from this 
>> discussion: - do we want national/regional identifier systems to 
>> be registered?
> 
> Indeed.
>  > - 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.
> 
> I would _guess_ that a string derived from a registered company
> name is more likely. Less fleeting, less easily reregistered.
> 
> BTW, I don't think John meant to suggest domain names. Rather, he
> told the story due to the possible parallels. Some countries
> introduced non-ASCII domain names without asking the IETF for
> permission, which led to IETF defining a common way to do non-ASCII
> domain names.

Yes.  And, unless one adopts the constraints of IDNs (including,
e.g., prohibiting upper case but also some mapping rules and
restrictions) punycode would probably be a bad choice.  That is
another example of why deciding what one wants to do and why needs to
do that come first, with encoding decisions following later.

Note that, whether the identifiers in a national or regional
registration system for country names are, to use the Latin script
example, case sensitive may depend on the region.  Moving away from
Latin script, the same question occurs with the presence or absence
of markings that provide pronunciation hints, spaces between "words"
for writing systems that use them, and particular character mapping
or substitutions for others.  Many of these come back to the
comparison problem Patrik mentioned, but whether a comparison
produces a "match" or "does not match" answer may, for names that may
have legal significance or be registered for other reasons, differ by
jurisdiction (coming back to Latin script (but not ASCII) as an
example, the example of that comparison problem that has historically
given the IETF the most aggravation is the relationship between "ß"
(U+00DF, Eszett or "Small Letter Sharp S" in Unicode-speak) and "ss"
and whether "ß" (U+1E9E) is even meaningful). 

>> - 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?
> 
> And that's where the IDN story has a parallel.

> I'd add a fourth: is ASCII really necessary, or is it better to
> restrict it to, say A-Z0-9 or just 0-9. AFAICT the initial
> registrations don't need more than 0-9, or what have I missed?
> 
> So the arguments to accept code points like 0x20, 0x22, 0x25, 0x3b
> seem weak to my untutored eyes. Of course this:that:";drop table
> users is great fun.

And, of course, if domain names were to be chosen as a relevant
analogy (again, a choice, as more or less described above), that
question has at least one set of answers in the preferred name syntax
of RFC 1035.

Observation: This discussion seems to me to be increasingly turning
into a discussion of possible sets of rules, drawing on analogies
that may or may not be useful, and forcing some of us into a sort of
backwards tutorial on some fairly fundamental i18n issues.  Can we
get it off the Last Call and ART lists, return the problem and
questions to the WG, and get the thrashing off of those two lists
until the WG has had some serious discussions, reached its
conclusions, and generated and agreed to a new I-D?

I, at least, am going to try to stop commenting on the issues until
that WG work is done.  If the WG wants advice from me, I'm confident
both Chairs know where to find me.

   john