[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [idn] 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