Standardizing on IDNA 2003 in the URL Standard

Gervase Markham gerv at
Wed Aug 21 11:07:18 CEST 2013

[I'm also not on many of these lists...]

On 20/08/13 15:46, Jungshik SHIN (신정식) wrote:
> 2013. 8. 20. 오전 5:33에 "Anne van Kesteren" <annevk at
> <mailto:annevk at>>님이 작성:
>> Last I checked with implementers there was not much interest in that.

In the case of Mozilla, if it was something I said which gave you that
impression, I apologise. That's not correct.

> Chrome is interested. It is very long overdue.

We are also interested. Sticking with a single version of Unicode is
untenable; given that, implementing anything other than IDNA2008 would
just be some mish-mash which would behave differently to everyone else.
Our implementation was held up for quite some time by licensing problems
with idnkit2 (now resolved), and it's now held up (I believe) due to
lack of time on the part of the main engineer in this area. (Patches
welcome.) But, insofar as I have any say, we do want to move to
IDNA2008, perhaps with some compatibility mitigations from TR46. (We've
not yet developed a precise plan.)

With regard to any incompatibilities, particularly around sharp-S and
final sigma, my understanding and expectation is that the registries
most concerned with those characters (e.g. the Greek registry for final
sigma) were in agreement that IDNA2008 was the correct way forward, and
that any breakage caused by the switch was better than the breakage
caused by not moving. If I became aware that this was not the case, my
view might perhaps change. But I believe that it is. If there is a
phishing problem in any particular TLD due to this change, then I place
the blame for that squarely on the registry concerned.

This is .


More information about the Idna-update mailing list