<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 12/25/2018 1:58 PM, John Levine
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:20181225215820.B065D200BF0EEE@ary.local">
<pre class="moz-quote-pre" wrap="">In article <a class="moz-txt-link-rfc2396E" href="mailto:2eb428e5-ed29-a914-23e3-7889b427b69d@ix.netcom.com"><2eb428e5-ed29-a914-23e3-7889b427b69d@ix.netcom.com></a> you write:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">What about "www." being an optional subdomain?
How are the techniques used to handle this different from having an IDN
alias?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
I think it's pretty safe to assume that foo.com and <a class="moz-txt-link-abbreviated" href="http://www.foo.com">www.foo.com</a> 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.</pre>
</blockquote>
<p>I agree on both counts. But nevertheless, it is commonly done.</p>
<p>I think the "language" issue is a bit of a red herring.</p>
<p>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.</p>
<p>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.<br>
</p>
<blockquote type="cite"
cite="mid:20181225215820.B065D200BF0EEE@ary.local">
<pre class="moz-quote-pre" wrap="">
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.</pre>
</blockquote>
<p><br>
</p>
<p>The point about it not being automatic is worth making.</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:20181225215820.B065D200BF0EEE@ary.local">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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.
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
Same answer, except that if one name isn't a subdomain of the other,
the login and option cookie problems are a lot harder.</pre>
</blockquote>
<p><br>
</p>
<p>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.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:20181225215820.B065D200BF0EEE@ary.local">
<pre class="moz-quote-pre" wrap="">
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">How are any of these issues materially different from offering your site
with multiple localized names?
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.</pre>
</blockquote>
<p><br>
</p>
<p>I think that "aliasing" doesn't work automatically is a point
worth making.</p>
<p>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.</p>
<p>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).</p>
<p>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.<br>
</p>
<blockquote type="cite"
cite="mid:20181225215820.B065D200BF0EEE@ary.local">
<pre class="moz-quote-pre" wrap="">
R's,
John
PS:
</pre>
<blockquote type="cite">
<pre class="moz-quote-pre" wrap="">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 -
</pre>
</blockquote>
<pre class="moz-quote-pre" wrap="">
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.</pre>
</blockquote>
<p><br>
</p>
<p>Totally.</p>
<p>My point was intended to be helpful in pointing out where you
might find data<br>
to extend loose matching.<br>
</p>
<blockquote type="cite"
cite="mid:20181225215820.B065D200BF0EEE@ary.local">
<pre class="moz-quote-pre" wrap="">
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>