> Not at all. Canonicalization is something which needs to be done
> always when you compare strings, and those algorithms should not
> change -- especially not regarding DNS -- because then two domains
> which previously were different (and because of that registered by
> two different parties) will no longer be different so one of the
> domain name holders have to give up his name.
Depends on what you mean by "change". For character strings
where all the characters are in a 3.0 or post-3.0 version
of Unicode, the normal forms D, C, KD, and KC of the string
will not change. (Ducking the issue on case folding, since
how that should interact with normal forms is unclear and
non-trivial.)
However, there will be characters added to 10646/Unicode
from time to time. There is a strong issue not to add any
more characters that would have a canonical decomposition,
and even if added, that case is guarded against by UAX 15.
But certainly there some characters that will have
compatibility decompositions that will be added (some are
about to be added via 10646-2). And certainly there may
also be characters that have uppercase/lowercase pairs that
can be added.
So the idea that normalisation+case folding will never
change (for IDN) is not supportable. However, there
must be no change in normalisation+case folding (for IDN)
for character strings where all characters are in a given
post-3.0 version for later versions, once the normalisation+
case folding for each bunch of added characters have been
established.
Even though the kind of "changes" are limited (to new
characters), managing such updates will be easier in a
(relatively) few servers than trying to do it for each
conceivable "client". On the other hand cliens need
other updates to well support new characters (like
keyboard handling and updated fonts).
I would suggest leaving the *requirements* document
open on this issue. But sure, the any IDN *protocol
standard's* text must be precise on this point.
Kind regards
/kent k