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

[Rohan Mahy <[e-mail]>]

Hi Patrik,
I am aware that there is plenty more work to be done if we wish to go down
this path, but without a concrete BNF example, very few people were going
to understand the flexibility and complexity of choosing this path. If we
decide we want to do this, I am happy to help with the rest.
thanks,
-rohan

On Thu, 12 Feb 2026, 16:43 Patrik Fältström, <[e-mail]> wrote:

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