Erik van der Poel <[EMAIL PROTECTED]> writes: >> 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?
No, but I also don't think that should be the metric. I believe the RFCs are clear that Unicode 3.2, without the NFKC fix, is what is to be used today... > 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 ...so you can't just "fix" the implementations. If you do, they are not complying with the RFC's. If VeriSign implement PR-29, I believe it doesn't conform to the RFC's. I think the "needs change" statements on the PR29 page are misleading, and based on UTC's subjective position on the matter. See the second mail in the following section for my response: http://www.gnu.org/software/libidn/manual/libidn.html#PR29-discussion The issue should be handled in an update of the StringPrep. If the PR-29 fix is incorporated, there must a good transition discussion in the document. The problem cannot only be discussed in the realm of IDNA, since StringPrep is used for other purposes as well. For me, the most important use is SASLprep, because it is used to prepare username and passwords. Hence, it is used in security critical application, where the requirements are different than from IDNA. The discussion must be wider than for only IDNA. Thanks, Simon
