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

[Patrik Fältström <[e-mail]>]

I have now looked at the change in the BNF, and as John I would say that "that is not good enough". For a change like that to be a solution, arguments are needed why that solves all issues with "equality" between two strings. This regarding comparison, display and sorting.

In short and different words than what John wrote, two unicode strings behave completely different than two ascii strings.

See for example this blog post of mine from July 31, 2008: <https://paftech.se/notes/683/>

My suggestion is because of this to first decide whether these identifiers REALLY need to handle wider charset than ASCII. If that is the case, then look at the various already in the IETF (and elsewhere) created solutions to the very complicated problem that John refer to. Choose one of them, and do not invent something yourself.

And, explain in plain text what "the same" or "equality" means (and not) for two identifiers that might have different content in the form of zeroes and ones, but should be treated as equal for example when being displayed (for phishing situations for example).

Patrik

On 12 Feb 2026, at 16:19, John C Klensin wrote:

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