<html><head></head><body>Hello Friends.<br>
<br>
Looks like we have wonderful discussion with bit of digression from UASG stuff.<br>
<br>
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.<br>
<br>
Boundary 1.<br>
All the domain names must be treated equally which includes all ASCII .tld and IDN .tld's and ccTLDs.<br>
<br>
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.<br>
<br>
Having said that both the above companies are not UA ready and that's what we should be really concerned with. <br>
<br>
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.<br>
<br>
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).<br>
<br>
Boundary 2:<br>
We are supposed to create awareness about UA issues and help to solve them.<br>
<br>
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. <br>
<br>
We are providing users multiple help to become UA ready. Great volunteering and paid professional wok has happened to produce superb documents. <br>
<br>
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. <br>
<br>
So off course adopting IDN or EAI is not directly an UA issue but surely helps to push UA agenda within company. This<br>
falls in line of the activities where we create awareness and pushcompany to be UA ready. That's the ultimate goal. <br>
<br>
So I would support Andre argument for ICANN to adopt IDNs , walk the talk and become UA ready. <br>
<br>
Side Note:<br>
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. <br>
<br>
Thanks.<br>
<br>
AD<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br>
<br><br><div class="gmail_quote">On 27 December 2018 07:00:04 GMT+05:30, John Levine <john.levine@standcore.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> I think the "language" issue is a bit of a red herring.<br /><br /> When traveling, things like google searches, weather forecasts and many other <br /> services are re-routed to the local service who then impose their local <br /> language (and metric) preferences on me by default. All without IDNs.<br /></blockquote><br />Indeed, but I would think that multiple IDN names for a web site would <br />imply multiple languages. If they all just redirect to the English <br />language site, that's technically easy, but it also seems like a cruel <br />joke.<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> Same answer, except that if one name isn't a subdomain of the other,<br /> the login and option cookie problems are a lot harder.<br /></blockquote><br /> Airline sites that direct to local access (with domain in local ccTLD) would <br /> have that issue and appear to be able to handle it. Other services do as well <br /> - not always without some bumps.<br /></blockquote><br />Having done this a few times, my experience is that they generally all <br />redirect to the same site, and there's a button at the top to pick a <br />language, which is usually remembered in a cookie, maybe initialized with <br />a guess from the original name but usually not. Again, one could do that <br />with multiple IDN names, but why bother?<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> The main difference is that crossing script boundaries makes it impossible <br /> for users not native (or competent) in both scripts to relate your aliased <br /> names. (Within a script my suspicion is that you wouldn't normally translate <br /> domain names without leaving at least a recognizable part, like a <br /> language-neutral brand name or abbreviation).<br /></blockquote><br />Seems reasonable.<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;"> definitely tell you that without loose address matching that matches<br /> user expectations, whatever they are, your customers will hate you and<br /> decide that your system is unusable.<br /></blockquote><br /> Totally.<br /><br /> My point was intended to be helpful in pointing out where you might find data<br /> to extend loose matching.<br /></blockquote><br />I've been wondering if it's worth spinning up an IRTF group to try and <br />collect advice on loose matching and (sort of its inverse) son-of-PRECIS<br />assigning user names that allow characters that users expect, but that <br />won't collide with variants or if non-speakers misenter them as homographs <br />or near homographs.<br /><br />Regards,<br />John Levine, john.levine@standcore.com<br />Standcore LLC<br /><br /></pre></blockquote></div><br>
-- <br>
Sent from my Android device with XGenPlus.</body></html>