[Idna-update] Re: Unicode IDNA2008 generated tables and release notifications

[Asmus Freytag <[e-mail]>]

(@markus - please read to end.)

On 8/15/2026 2:53 AM, Patrik Fältström wrote:
> On 15 Aug 2026, at 11:46, Asmus Freytag wrote:
>
>> This would not remove the ability of IETF to make explicit overrides for any other reason, just a mechanical way to guarantee stability of IDNA 2008 without tying other property-derived algorithms into impossible knots. (And the fact that it happened so rarely is a good indicator that maintaining mechanical stability by default should ultimately be a workable solution.)
> I think IETF should think of taking one step even further, to say "hey, Unicode consortium, you are doing a good job, keep on doing this, so we do not have to".

That is an entirely doable option.

If desired, you could even specify that "once assigned" an IDNA2008 
status is stable. As long as there's a mechanism by which Unicode can 
accomplish that without forcing strict stability on the GC property, 
that's something the Consortium would be able to do, because it already 
defines and honors a number of similar stability policies.

The idea of "automatic exceptions for stability" would be such a 
mechanism. If the GC must change after the fact, an exception would be 
added to the derivation at that point so as to preserve the IDNA 2008 
status. (Expected incidence of that would be very low, given the history 
of the last 25 years, but such a mechanism would need to formally exist, 
bc Unicode cannot freeze GC absolutely).

>
> But the ability to distinguish between beta and released versions is (for me) the last thing to hang up on. From 12.0.0, as I wrote, we have a stable train of versions from Unicode.

Absolutely.

At the minimum, there needs to be a fix that the non-final versions of 
the file identify themselves as such (and not merely by their physical 
server location and/or readme in a folder).

> So default could very much be to "just" point at the Unicode document of derived property value, but it must be to the released versions, not the draft versions.
>
> If IETF (or someone else, including Unicode) find in the future IDNA must be changed (for example by adding exceptions or something) that can easily be done with an RFC.
That was my thinking as well.
> But we get out of the loop of requiring an RFC for every version of Unicode which is what I feel where we are stuck now.
This would be a win.
>
> Personally I would love to make this change. To have that said. But I am nervous over the risk of using beta versions of IDNA lists.

Just to be clear, the beta (or alpha) versions were only ever intended 
for review by human experts.

Formally, there is a way to navigate that establishes whether a file is 
part of a release: you access the version's main page in the versions 
folder. It will have explicit language on the status and also any file 
linked from there will be the final one. (I agree with you that this 
alone isn't sufficient in practice, for the reasons you gave. Which 
dovetail with the concerns I have been raising internally. The reason it 
hasn't been fixed is that we didn't have credible output from "outside" 
consumers on why the current scheme is not working, so with some input 
from IETF this is now a matter of public feedback.)

A./

@markus: I plan to turn the issue about file identification into a 
feedback item, but feel free to anticipate me, if I don't get around to 
it soon enough.