I've become strongly in favor of 1 + 2 from my perspective as a group member. But from a VC perspective, I evidently leave this open to the group. The more I study 1 + 2, the more it looks like an implementable rule. We would not need to ship a library or a large table with exceptions, but only define two rules that developers can incorporate where needed. That makes adoption much more feasible at the application level where these ASCII-IDN equivalences would need to be recognized beyond the DNS itself, such as string comparison, validation, normalization, display, and matching. My UA claim only really applies beyond 1 + 2, where we establish truly ad-hoc rules. Best, On 31/03/2026 13:37, Tapani Tarvainen via Gnso-latin-diacritics wrote:
Dear all,
Let's consider three alternatives:
(1) Decomposable diacritics only.
This is technically easy, single, straightforward rule. The downside is that it excludes several diacritical letters.
(2) Include also "SMALL LATIN LETTER [A-Z] WITH ..."
Also technically easy (how long did it take Mark to add this to his tool?), only a bit more complicated in that we'd need two different rules. It provides unambiguous, machine-testable set of letters and relationships between the diacritics and their ASCII counterparts, and it adds 15 letters that are used in at least 35 languages.
(3) Add also letters that aren't real diacritics, like ŋ, æ, ð, þ etc, but that could still be handled the same way. These would need to be evaluated individually and automated processing would have to be based on tables. It would, however, cover even more languages.
I would argue that (2) is closest match to our charter as it covers almost(?) all diacritics.
I would also argue that those extra letters and languages supported by (2) are at least symbolically significant.
I do not see a significant difference in technical difficulty between (1) and (2), but I am open to persuasion here. Staff input would be appreciated.
I don't think (3) would be technically all that difficult either, but it would certainly be at least stretching our mandate and it would require significant amount of extra work.
Looking forward to an interesting discussion tomorrow,
-- Mark W. Datysgeld Director at Governance Primer [governanceprimer.com <https://governanceprimer.com>] Project Lead Developer at ICANNWiki [icannwiki.org <https://icannwiki.org/>]