Re: stability

> I think it may be too late to do a simple flag day and fix things.

Why? Do you believe that there may already be domain labels involving 
the relevant types of strange character sequences?

If we don't fix the specs and the implementations, then we may end up 
with interoperability problems in the future if some strange sequences 
start to appear or new characters are added to Unicode. PRI #29 already 
indicates that VeriSign's implementation does not need a change, while 
idnkit does. I believe Mozilla uses idnkit.

http://www.unicode.org/review/pr-29.html

> I believe it would be useful to start thinking of the problem in terms
> of a transition plan from what we have today and what we would like to
> have tomorrow.  It is not clear to me exactly what we would like to
> have tomorrow, so settling that would have to be part of the plan as
> well.

There may be other things to change in the IDNA RFCs, but as far as this 
normalization problem is concerned, it is pretty clear to me that we 
need to get the RFCs to point to a newer version of UAX #15, i.e. 
tracking number 24 or higher.

http://www.unicode.org/reports/tr15/tr15-24.html

Note that this spec does not require an implementation to update the 
normalization table itself to a newer version. If we believe there are 
good reasons for IDNA to keep the old table entries that changed in 
newer versions of Unicode, then we may be able to do so. Is that right, 
Mark? I.e. could IDNA upgrade to Unicode 4.1.0 while keeping the 
individual mappings indicated below at the older Unicode version?

http://www.unicode.org/Public/UNIDATA/NormalizationCorrections.txt

(Whether we would want to do this is a separate question.)

Erik