Hello Friends.

Looks like we have wonderful discussion with bit of digression from UASG stuff.

I do not to need to mention UASG scope, as its alreadythere on UASG.TECH website, however I think we have simple to understand UASG boundaries for atleast domain name.

Boundary 1.
All the domain names must be treated equally which includes all ASCII .tld and IDN .tld's and ccTLDs.

Now the question is simple. When global companies like Amazon or Americanexpress do have 100+ domain names active for respective countries (not necessary local languages served) what stops them to use IDNs too. The argument of having single domain seems to be not valid and obviously NOT a UA issue.

Having said that both the above companies are not UA ready and that's what we should be really concerned with.

Now to address this UA issue with them there are many ways but one of the ways could be to push them for adoption of IDN and show them new customer base they are missing which can not reach to there website, as those who do not know English can not type English domain names.

One can argue whether it's a UA issue or not but it is certainly going to activate internal UA initiative , as IDNs are adopted in the company. The similar example we have seen in patrika.bharat ( a media house) and rajasthan.bharat (govt).

Boundary 2:
We are supposed to create awareness about UA issues and help to solve them.

We are spending millions of $s to create document and libraries. Here we are getting into "providing solution" and creating knowledge base. One can argue for these to be the best of the class library/solution or not however is available live on uasg.tech website.

We are providing users multiple help to become UA ready. Great volunteering and paid professional wok has happened to produce superb documents.

If there is No IDN adoption and no EAI visible to Amazon and Americanexpress than they are less likely to even touch there apps for UA and the fact is that globally we have very Little adoption of IDN and EAI. So the low hanging fruit could be that we push large companies to adopt IDN themselves and which pushes them internally to become UA ready themselves.

So off course adopting IDN or EAI is not directly an UA issue but surely helps to push UA agenda within company. This
falls in line of the activities where we create awareness and pushcompany to be UA ready. That's the ultimate goal.

So I would support Andre argument for ICANN to adopt IDNs , walk the talk and become UA ready.

Side Note:
Voice search is increasing globally and people specific to there language are likely to search in there local language where IDN will play major role and ASCII domain name will be of little use.

Thanks.

AD















On 27 December 2018 07:00:04 GMT+05:30, John Levine <john.levine@standcore.com> wrote:
 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@standcore.com
Standcore LLC


--
Sent from my Android device with XGenPlus.