[idn] Re: stability

[Simon Josefsson <[e-mail]>]

Erik van der Poel <[e-mail]> 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