IAB Statement on Identifiers and Unicode 7.0.0
michel at suignard.com
Wed Jan 28 20:20:13 CET 2015
>> If IAB and IETF wants to pursue a path to eliminate these pseudo
>>equivalences, they have to build on top of NFC a more restrictive
>That is certainly one direction in which we might head but I, and I think several others here, would like to avoid it if possible.
Isn't that what IDNA2008 does already? As mentioned by Asmus, Unicode is already full of 'derived' properties. It is much easier to build on top of an existing transform such as NFC than to create your own from scratch and it is also easier to update when the repertoire is updated.
To clarify, I was not advocating for a brand new Normalization Form build from scratch, but a derived form. I understand that it would have been easier to assume that NFC does the trick for you, but if you perceive needs that are not addressed by NFC, I don't see how you can avoid a solution analog to what is done in IDNA 2008, that is NFC + special rules. Then in the future IDNA20xx (and any other application with similar need) can adopt that transform.
More information about the Idna-update