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

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

Rohan,

Partly to follow up and expand on Patrik's comments and having
glanced at the pull request to which you refer, the problem with
non-ASCII characters is not in making a small twitch to the ABNF as
you seem to suggest.  The problem is that, especially for
identifiers, various properties of both writing systems that use such
characters and of Unicode's instantiation of them create a large
collection of potential ambiguities, representation problems, and
other ambiguities.  Perhaps the most obvious examples (at least for
some of us) involve RtoL characters inserted in the middle of LtoR
strings (and vice versa) and, if humans are ever going to look at
these things, look-alike character representations (both so-called
homoglyphs and combinations of precomposed characters and ones built
from combining sequences of code points).

If the above paragraph is not clear to both active participants in
the WG and anyone advocating for allowing non-ASCII characters, Q.E.D.

These issues have been (IMO minimally) addressed in RFC 9839, more
extensively (especially for identifiers) in the PRECIS documents (Cf.
at least RFCs 8264-8266), and, as Patrik points out, for domain names
in the IDNA2008 documents (starting with RFCs 5890-5894 and updates
to them).   Or, if you don't like IETF specs, at least look at
Unicode UAX #31.

It may be that none of those exactly meet your needs but, especially
if they don't, experience suggests that you need more specification
than "just allow the code points in encoded form" and/or fairly
extensive treatment of the issue in the document's Security
Considerations.

Procedurally, if any of these changes are to be made, it is entirely
inappropriate to introduce them into the document and approve them as
part of, or after, this Last Call -- the document needs to go back to
the WG for discussion (and understanding) of the issues and tradeoffs
involved with the motivation for the documents mentioned above as one
starting point.

    john


--On Thursday, February 12, 2026 11:25 +0100 Rohan Mahy
<[e-mail]> wrote:

> I think if we are defining an identifier space in 2026 that is
> ASCII-only I think we need to at least provide a reason. I don't
> think it is a huge bar.
> 
> Patrik, please have a look at my comment on
> https://github.com/ietf-wg-spice/draft-ietf-spice-glue-id/pull/59
> and comment if this would be a reasonable way to allow a larger set
> of characters.
> 
> I am also not going to object if the reason was something as simple
> as "we wanted to make it consistent with a NID".
> thanks,
> -rohan
> 
> 
> On Thu, 12 Feb 2026, 10:01 Patrik Fältström, <[e-mail]>
> wrote:
> 
>> Note that my comment is based on the fact only ASCII is to be
>> used. If on the other hand a broader selection of characters are
>> to be used, then we have a completely different kind of fish to
>> fry -- all depending on whether the identifiers are to be
>> compared, sorted and what not.
>> 
>> I.e. a whole lot of baggage that is most easily solved by
>> referencing various IDN related work in other wg's in the IETF.
>> 
>> To conclude, I did not make any judgement whether it is a good or
>> bad decision to be ASCII only.
>> 
>> Patrik
>> 
>> On 12 Feb 2026, at 9:05, Rohan Mahy wrote:
>> 
>> > My question is what is the argument for excluding them. Is there
>> > a
>> technical argument (because URNs can perfectly well include
>> percent-encoded characters)? Is there a security argument? Or is
>> this just an arbitrary decision, in which case the IETF does not
>> look so good.
>> > 
>> > The closest thing I could guess is effectively duplicating the
>> > syntax of
>> NID. There is some logic in that, but it requires explanation and
>> a reason why that would be a good thing.
>> > 
>> > thanks,
>> > -rohan
>> > 
>> > On Thu, 12 Feb 2026, 01:07 Tim Bray, <[e-mail]>
>> > wrote:
>> > 
>> >> On Feb 11, 2026 at 3:56:28 PM, Brent Zundel <brent.zundel=
>> >> [e-mail]> wrote:
>> >> 
>> >>> Patrik,
>> >>> 
>> >>> Thank you for your review.
>> >>> We have raised a PR in response and invite your comments there:
>> >>> https://github.com/ietf-wg-spice/draft-ietf-spice-glue-id/pull
>> >>> /60
>> >>> 
>> >> 
>> >> Very clear. It feels weird to me that we're specifying
>> >> ASCII-only identifier systems in 2026, but maybe I'm in the
>> >> rough on that one. -Tim
>> >> 
>> >> --
>> >> SPICE mailing list -- [e-mail]
>> >> To unsubscribe send an email to [e-mail]
>> >> 
>> > 
>> > _______________________________________________
>> > art mailing list -- [e-mail]
>> > To unsubscribe send an email to [e-mail]
>>