Re: [idn] The Business Card problem (was: Re: An experiment with UTF-8domain names)

[John C Klensin <klensin@jck.com>]

--On Tuesday, 16 January, 2001 16:01 +0900 GIM Gyeongseog-KIM
Kyongsok <gimgs@asadal.cs.pusan.ac.kr> wrote:

> On Sat, 6 Jan 2001, John C Klensin wrote:
> 
>> But most Han, Kanji,
>> and Hangul are hopeless for me: there are lots of them, I
>> can't (in general) tell them apart, and I just don't have the
>> pattern recognition skills...
> 
>> Anything I can't recognize well enough to match with a table
>> is something I can't copy from a business card.  ...
> 
>   as i understand it, IDNs in Hangeul, for example, are for
> people who understand Hangeul, not for non-Hangeul-aware
> people.   if some company's main customers are people using
>   Hangeul,  then they can use IDN in Hangeul.  if that company
> also wants to attract people using English, then they should
> use English domain name too (of course, the contents 
> of web pages must be in English as well).
> 
>   am i missing something here?

No, except that the DNS supports synchronized changes to
coordinated entries very poorly.  For both, e.g., web and email
addresses, one would normally like

   http://<hangeul-domain-name>/...   and
   http://<english-name-for-same-enterprise>/...
to point to the same site.  Likewise
   <user-name-in-hangeul>@<hangul-domain-name> and
   <user-name-in-english>@<english-name-...>
to point to the same mailbox.

But, if, e.g., one implements this as (using IPv4 as an example)
as

  <hangeul-domain-name>. IN A 10.1.2.3
  <english-name-for-same-enterprise>.  IN A 10.1.2.3

And then tries to make a change, such as to re-home the host,
the two names may, due to differences in usage, take
significantly different times to propagagate.  And, since there
is some history of taking the first matching entry only and
ignoring the others, it may make some significant difference
whether one lists

   3.2.1.10.in-addr.arpa. IN PTR <hangeul-domain-name>.
   3.2.1.10.in-addr.arpa. IN PTR <english-name-...>.

or

   3.2.1.10.in-addr.arpa. IN PTR <english-name-...>.
   3.2.1.10.in-addr.arpa. IN PTR <hangeul-domain-name>.

trying to do the matching with CNAMEs, e.g.,
  <hangeul-domain-name>. IN A 10.1.2.3
  <english-name-...>.  IN CNAME <hangeul-domain-name>.

has most of the same synchronization problems, plus all of the
usual problems with CNAMEs, including, normally, no appearance
of the English name in reverse-mapping records at all.  And the
other variations (Hangeul-> English -> address and both Hangeul
and English names labeling CNAMEs that point to some contrived
intermediary which then labels a single A RR) help with some
problems and introduce others.  And note that several of these
(as well as use of two PTR records for the target address in the
first, "both use A RRs" model) are, for me, the main argument
for ACE-like solutions (or something more radical than embedding
this information in Class=IN), which I otherwise dislike
intensely. They will certainly "leak" strings representative of
the Hangeul into legacy applications.  If those strings are in
anything but the protocol-element restricted ASCII those
applications traditionally expect, we will have trouble, whether
the problem is a leading hyphen or an octet with the high-order
bit turned on, or an octet whose bit value is zero.

Note that this gets worse if there is some coordinated
collection of servers with related domain names (fairly common
for some arrangements today), if the servers are multihomed (and
hence have multiple A RRs for a single FQDN), or if you are
supporting not only English and Hangul names, but names that use
several other languages (and hence scripts) as well.

In looking at "multilingual" names, solutions that work 80% of
the time, or cover 80% of the cases, are actually fairly easy.
Any of the example scenarios above would "pretty much" work, and
synchronized changes may not be very important.   I suppose that
is why we've had so many organizations spring up with claims of
easy and unique solutions to the requirements as they see them.
But the DNS is fairly basic infrastructure for users of the
Internet, and 80% solutions, or even 99% solutions, or solutions
that assume concurrent upgrading everywhere, are almost
certainly not good enough.

    john