In article <2eb428e5-ed29-a914-23e3-7889b427b69d@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.
Totally.
My point was intended to be helpful in pointing out where you
might find data
to extend loose matching.