treatment of U+002E that is produced by NFKC

[Erik van der Poel]

GNU libidn handles the case below in the same way as Opera 9 and ICU,
but MSIE 7 and Firefox 2 handle it differently.

I tried the demo page at http://josefsson.org/idn.php/

By the way, the main libidn Web page tries to link to the Bug Report
section, but fails to jump to the right anchor:

http://www.gnu.org/software/libidn/#bugs (see the link "how to report
bugs" at this location)

Speaking of U+2024 and where in the protocol stack to handle things, I
just discovered that MSIE 7 and Firefox 2 both perform NFKC on this
character, to yield U+002E (.). After that, they divide the host name
into labels *again*, so the new U+002E becomes a new label separator.

If we ever get around to writing a document about IDNA in HTML, we may
want to make a note of this. I.e. the steps are:

(1) Divide the domain name into labels by looking for IDNA2003 dots.
(2) Perform Nameprep2003 on each non-ASCII label.
(3) Divide each label into multiple labels, by looking for regular dots.
(4) Perform Punycode2003 on each non-ASCII label.

Interestingly, Opera 9 appears to perform a slightly different set of
steps (see step 2):

(1) Divide the domain name into labels by looking for IDNA2003 dots.
(2) Perform Nameprep2003 on each non-ASCII label, and, if result is
non-ASCII, perform Punycode2003.
(3) Divide each label into multiple labels, by looking for regular dots.

Opera 9 is somewhat more conformant to RFC 3490, but it re-divides the
labels instead of inserting 0x2E (.) into the DNS packet. (One might
argue that RFC 3490 did not really take this into account.)

I haven't tried it in Safari 3 or MSIE 6 with Verisign plug-in. The
HTML I used for testing was:

<a href="http://google&#x2024;com";>one</a><br>
<a href="http://&#x5341;&#x2024;com";>two</a>