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

Asmus Freytag (c) asmusf at ix.netcom.com
Wed Dec 26 06:22:55 UTC 2018

On 12/25/2018 1:58 PM, John Levine wrote:
> In article <2eb428e5-ed29-a914-23e3-7889b427b69d at ix.netcom.com> you write:
>> What about "www." being an optional subdomain?
>> How are the techniques used to handle this different from having an IDN
>> alias?
> I think it's pretty safe to assume that foo.com and www.foo.com are in
> the same language, and if one redirects to the other, nobody will be
> confused.  Even so, getting it to work right is not totally trivial.

I agree on both counts. But nevertheless, it is commonly done.

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.

So while "confusion" in the sense of not getting what you expect is an 
issue (I mean it is a bit silly to get a foreign weather forecast 
delivered in Fahrenheit as long as I access it from the US, but 
refreshing the same site after arriving at my destination will switch 
the display to Celsius) it's not one that's dependent on IDNs.

> The two names need their own SSL certificates, or if there's one cert
> it has to be validated for both names.  If the site uses cookies as
> most do to manage site logins or user options, it has to be sure the
> cookies for the two names are kept in sync or all forced to one of the
> names.
> None of this is terribly hard, but it's not automatic either.

The point about it not being automatic is worth making.

>> Yes, I did note the passage on language negotiation, but how is that
>> different from sites that can be accessed via ccTLDs in addition to a
>> domain name in a gTLD. That's a pattern typical for many global
>> organizations.
> 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.

>> How are any of these issues materially different from offering your site
>> with multiple localized names?
> The point, which I apparently wrongly thought was obvious, is that none
> of this multi-name stuff works automatically, and telling people "just
> add a bunch of IDN names and EAI addresses" is not going to end well.

I think that "aliasing" doesn't work automatically is a point worth making.

IDNs add another level of opportunity for aliasing, but I don't think 
they really add anything new that existing forms of aliasing aren't 
exposing you to.

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).

That, however, is a cognitive issue, in the sense that if you present 
the wrong user with an "opaque" name you may or may not create an issue. 
It's similar, but not the same as presenting them with the "wrong" 
language version of your site.

> R's,
> John
> PS:
>> PS: some non-European scripts can have variants that work similar to
>> case-equivalence. If you want to institute loose matching of e-mail
>> usernames based on them, you'd have to roll your own -
> Yes, people who are working about EAI are aware of the way that local
> part matching works.  Since every mail system already has its own
> loose matching rules, it's not a new problem but it's not one that
> anyone has thought much about for EAI mail addresses.  I can
> 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.


My point was intended to be helpful in pointing out where you might find 
to extend loose matching.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ua-discuss/attachments/20181225/c981b6b4/attachment.html>

More information about the UA-discuss mailing list