Hello Eric,
At 06:40 05/02/18, Erik van der Poel wrote:
>Yes, but as a browser developer, I *would* care about whether a user was able to easily type in a domain name and go where s/he wanted to go. In the presence of these homograph problems, a browser developer might even want to retry DNS lookups with different character codes until it succeeded. We can't just foist these solvable problems on the end-user.
As a browser developer, you don't even have to care too much about ease of typing, above and beyond making sure that the user can use the input facilities provided by the OS and Windowing system,... in the usual way.
The rest will be taken care by registrants, they'll figure out sooner or later what names are easy to type and what names are not easy to type. It has worked quite well for the ASCII-only DNS.
>You could use a prefix other than xn-- to migrate from the old to the new. I jotted down a few quick ideas here:
>
>http://lists.w3.org/Archives/Public/www-international/2005JanMar/0101.html
>
>However, if I can't get support from the major organizations such as Microsoft, VeriSign and the Unicode Consortium (either because too many xn-- names have already been registered and the migration would not be practical or for some other reason), then I might just give up on this idea. But I'm willing to explore it some more.
[rethorical question:] Are we also going to deal with those cases in US-ASCII that can be confusing now?
Later, Martin v. Loevis wrote:
The most natural keyboard input in this case is the apparent script of the label. The user should see the script from reading it
Yes. And some labels where the script isn't clear enough might not get registered by honest folks because they want users to understand how to type things, rather than to worry what script to use. An alternative may of course be registering in both scripts. [the number of cases that this applies are probably not large, I'm mainly thinking about short words or company names/acronyms in Russian and similar places]
Regards, Martin.
