Q2: What mapping function should be used in a revised IDNA2008specification?

[Erik van der Poel]

The Eszett issue is not just a matter of registries putting in a few
months worth of work. We would also need to convince client
implementers to stop mapping Eszett to ss. Although one could argue
that the number of labels containing Eszett in stored files and
exchanged text is low (compared to the number of words in plain text
that contain Eszett), we now have quite a lot of installed clients
that perform IDNA2003 mappings out there. I myself am only involved in
a client (Google crawler) that holds little sway in this matter. There
are a number of other clients that hold much more sway, and I am
frustrated about the lack of consensus among those implementers and
other members of this WG.

Another example of a client developer that is inhibiting progress is
Firefox, with its refusal to display Unicode labels under certain
large TLDs such as .com. We really need to resolve this issue too,
otherwise IDNA is not really going to spread.

Both of these issues have been discussed to death, and yet the client
implementers are not convinced. Sorry if I come across as pessimistic.

Erik

>> That's a good example. They noticed that for them it was
>> wrong not to have the second level domains available like in
>> many other countries and made up their mind how to get out of
>> it without unsettling the registrants or users. That's how
>> change can be managed! I am sure what the Mexican registry
>> can do, is no problem for the German and Austrian registry neither.
>
> I'm not saying it's not possible. We have done transitions a few
> times, and assisted other registries in doing so as well. It's just
> always a few months worth of work...