From: =?utf-8?b?UGF0cmlrIEbDpGx0c3Ryw7Zt?= <paf@paftech.se>
To: John C Klensin <john-ietf@jck.com>
Date: Thu, 12 Feb 2026 16:43:12 +0100
Message-ID: <794B84A2-9042-4B7A-815B-42AE37DF336F@paftech.se>
In-Reply-To: <62A41349908B128EDD6AA331@PSB>
References: <176999555082.2258144.15300311588293625134@dt-datatracker-
 77f8b84995-z4hzn>
 <CAP5QTG5-hGWm1_u7CZTJW5H56LxXecoKbk3viBfBPdoDOxozhA@mail.gmail.com>
 <CAHBU6itnZa3VDE=_zWsMeDJ8CuieWvdyzvQS51BhcPqG8Fz07Q@mail.gmail.com>
 <CAKoiRubs9ZUO=kbvOgvgruaqiBusyvv_BqO0_kkah2SokjRcmw@mail.gmail.com>
 <4C4C41E0-9D36-4A10-AEE4-D94C8B319485@paftech.se>
 <CAKoiRub+QYyMFE=jMTvNc+FDn-YFiBdM7jC5da64HyvmXyx3Dg@mail.gmail.com>
 <62A41349908B128EDD6AA331@PSB>
MIME-Version: 1.0
Content-Type: multipart/signed;
 boundary="=_MailMate_7B7C44BA-FD15-4837-8B8B-E1558D5F80FE_=";
 micalg=pgp-sha512; protocol="application/pgp-signature"
Message-ID-Hash: HQ2ZY6EBOZUVFIOYJYTWEVGB54MPBXFU
CC: Rohan Mahy <rohan.mahy@gmail.com>, Tim Bray <tbray@textuality.com>,
 Brent Zundel <brent.zundel=40yubico.com@dmarc.ietf.org>, art@ietf.org,
 draft-ietf-spice-glue-id.all@ietf.org, last-call@ietf.org, spice@ietf.org
Precedence: list
Subject: =?utf-8?q?=5Bart=5D_Re=3A_=5BLast-Call=5D_=5BSPICE=5D_Re=3A_Re=3A_draft-ietf?=
 =?utf-8?q?-spice-glue-id-04_ietf_last_call_Artart_review?=
Archived-At: 
 <https://mailarchive.ietf.org/arch/msg/art/yiG1c_hz5pSnqXsR3NtfQ4pRSvo>

This is an OpenPGP/MIME signed message (RFC 3156 and 4880).

--=_MailMate_7B7C44BA-FD15-4837-8B8B-E1558D5F80FE_=
Content-Type: text/plain
Content-Transfer-Encoding: quoted-printable

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, argum=
ents are needed why that solves all issues with "equality" between two st=
rings. This regarding comparison, display and sorting.

In short and different words than what John wrote, two unicode strings be=
have completely different than two ascii strings.

See for example this blog post of mine from July 31, 2008: <https://pafte=
ch.se/notes/683/>

My suggestion is because of this to first decide whether these identifier=
s REALLY need to handle wider charset than ASCII. If that is the case, th=
en look at the various already in the IETF (and elsewhere) created soluti=
ons to the very complicated problem that John refer to. Choose one of the=
m, 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 zero=
es and ones, but should be treated as equal for example when being displa=
yed (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 exte=
nsively (especially for identifiers) in the PRECIS documents (Cf.
> at least RFCs 8264-8266), and, as Patrik points out, for domain names i=
n the IDNA2008 documents (starting with RFCs 5890-5894 and updates to the=
m).   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 "j=
ust allow the code points in encoded form" and/or fairly extensive treatm=
ent of the issue in the document's Security
> Considerations.
>
> Procedurally, if any of these changes are to be made, it is entirely in=
appropriate 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 f=
or discussion (and understanding) of the issues and tradeoffs involved wi=
th the motivation for the documents mentioned above as one starting point=
=2E

--=_MailMate_7B7C44BA-FD15-4837-8B8B-E1558D5F80FE_=
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename=signature.asc
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iG0EAREKAC0WIQRUH/cJI8i4DDUU3qWsxpsaC4jXzQUCaY31EQ8ccGFmQHBhZnRl
Y2guc2UACgkQrMabGguI182+qACZAR7AOFAYLfTqdzEuZbZ0yvMFgDYAnjlhw+yO
qzzej7ydIqILIOIpMmcc
=Po8d
-----END PGP SIGNATURE-----

--=_MailMate_7B7C44BA-FD15-4837-8B8B-E1558D5F80FE_=--