[UA-discuss] More from Ram Mohan on ICANN's further commitment to Universal Acceptance

[John Levine]

> I think the "language" issue is a bit of a red herring.
>
> When traveling, things like google searches, weather forecasts and many other 
> services are re-routed to the local service who then impose their local 
> language (and metric) preferences on me by default. All without IDNs.

Indeed, but I would think that multiple IDN names for a web site would 
imply multiple languages.  If they all just redirect to the English 
language site, that's technically easy, but it also seems like a cruel 
joke.

>>  Same answer, except that if one name isn't a subdomain of the other,
>>  the login and option cookie problems are a lot harder.
>
> Airline sites that direct to local access (with domain in local ccTLD) would 
> have that issue and appear to be able to handle it. Other services do as well 
> - not always without some bumps.

Having done this a few times, my experience is that they generally all 
redirect to the same site, and there's a button at the top to pick a 
language, which is usually remembered in a cookie, maybe initialized with 
a guess from the original name but usually not.  Again, one could do that 
with multiple IDN names, but why bother?

> The main difference is that crossing script boundaries makes it impossible 
> for users not native (or competent) in both scripts to relate your aliased 
> names. (Within a script my suspicion is that you wouldn't normally translate 
> domain names without leaving at least a recognizable part, like a 
> language-neutral brand name or abbreviation).

Seems reasonable.

>>  definitely tell you that without loose address matching that matches
>>  user expectations, whatever they are, your customers will hate you and
>>  decide that your system is unusable.
>
> Totally.
>
> My point was intended to be helpful in pointing out where you might find data
> to extend loose matching.

I've been wondering if it's worth spinning up an IRTF group to try and 
collect advice on loose matching and (sort of its inverse) son-of-PRECIS
assigning user names that allow characters that users expect, but that 
won't collide with variants or if non-speakers misenter them as homographs 
or near homographs.

Regards,
John Levine, john.levine at standcore.com
Standcore LLC