Re: treatment of U+002E that is produced by NFKC

[Erik van der Poel]

On Jan 13, 2008 1:23 AM, Simon Josefsson <address@hidden> wrote:
> I don't understand what the problem is.  I'm not even sure you are
> claiming there is a problem in libidn?

Libidn, ICU and Opera 9 implemented RFC 3490 one way, while MSIE 7 and
Firefox 2 implemented it a different way. It is up to the owner(s) of
libidn to decide what to do here. (In my opinion, libidn should be
changed to handle these cases in the same way as MSIE 7 and Firefox
2.)

> If I invoke:
>
> address@hidden:~$ idn --debug --quiet foo․bar

Yes, libidn handles this case (ASCIIs followed by U+2024, followed by
ASCIIs) the same way as the others. Libidn handles the
<non-ASCII-label>U+2024<ASCII-label> differently. For example, in
HTML:

<a href="http://&#x5341;&#x2024;com";>blah</a>

> The web page for the same input is:
>
> http://josefsson.org/idn.php/?data=foo%E2%80%A4bar&profile=Nameprep&mode=toascii&debug=on&charset=UTF-8&lastcharset=UTF-8
>
> This looks correct to me.  What is wrong?

Try this one instead:

http://josefsson.org/idn.php/?data=%E5%8D%81%E2%80%A4com&profile=Nameprep&mode=toascii&debug=on&charset=UTF-8&lastcharset=UTF-8

MSIE 7 and Firefox 2 both end up with xn--kkr.com while libidn
produces xn--.com-pq0g

> Why not add U+2024 to the list of dot-like code points in RFC 3490
> section 3.1 instead?

Well, yes, something like that is being considered for IDNA200X (and
that is being discussed on the address@hidden list).

Erik