On 25 Dec 2018, at 21:58, John Levine <john.levine@standcore.com> wrote:

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

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.

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.

There is one part that can happen automatically. If the web authors have used relative addressing throughout their website then the url will automatically inherit the Domain Name being used on entry. So if icann.org is used on entry then icann.org will show and stick in the browser address bar. If icann.संगठन is used on entry then icann.संगठन will show and stick in the browser address bar.

Whether or not one then adapts website content according to which Domain Name is used is a different issue

André Schappo

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.