browser behavioral differences for IDNA

[Markus Scherer]

On Wed, Oct 28, 2009 at 6:56 PM, "Martin J. Dürst"
<duerst at it.aoyama.ac.jp>wrote:
>
> a) For each corrigendum, at least some of the implementations seem to have
> adopted it. I very much hope the others will follow. On the IDNAbis WG list,
> some people pointed out that if there were RFC errat for the Unicode
> corrigenda, that would help implementations. I can submit some errata if
> people thing that indeed will help.
>
> b) The entry "FF - 3.2 -- applied twice!" confirms what I have been
> claiming since the very time the Normalization Idempotency bug was found:
> That the IDNA spec (implicilty) assumed that normalization was idempotent,
> and than different implementations might end up with applying normalization
> once or twice, and thus differ in their result on those cases where (before
> the corrigendum) normalization wasn't idempotent. All the more reason to
> apply this corrigendum via an RFC erratum.
>

I plan to change ICU soon. Currently, ICU's IDNA code uses a specific,
internal flag to *make *the normalization code behave like *before *Corrigendum
#5 while the regular ICU normalization API works as specified
*since*Corrigendum #5. This fork in the code path is annoying, and the
bug nasty
although extremely obscure. The different browser behaviors have convinced
me that it does not make sense to maintain the old behavior.

The reason that ICU's IDNA implementation explicitly behaves like before
Corrigenda #4 & #5 is that, at the time, IETF people wanted normalization
behavior to be super-compatible with Unicode 3.2 as originally specified,
and we assumed that other IDNA implementations would not update either.

Personally, I would be happy to see errata for the IDNA RFCs for adopting
the normalization corrigenda.

BTW, what is Opera doing?
>

Opera implements Corrigendum #5, like Internet Explorer. I don't know about
#4.

Best regards,
markus
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/idna-update/attachments/20091028/312c0f0e/attachment.htm