Re: [idn] iDNS transition: end-system vs. infrastructure?

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

--On Saturday, 12 May, 2001 19:41 +0000 "Adam M. Costello"
<amc@cs.berkeley.edu> wrote:

> John C Klensin <klensin@jck.com> wrote:
> 
>>  (iii) A family of solutions that are "no risk", because
>>  their designs prevent non-IDN-aware applications from ever
>>  seeing an IDN in a DNS context.
>> 
>> But let's avoid assuming...that applications will need to
>> handle ACE names no matter what.
> 
> Could you elaborate on this, with examples?  What sorts of
> things would occupy the domain name position in a message
> header field, or an SMTP command, or a URI?

Depends on which member of family (iii) one picks.  

The notion of using a different DNS class (see
draft-klensin-i18n-newclass-... for some discussion; I gather a
more detailled document is coming) is in this family.  If that
were chosen, the answer in all the cases you list would be "DNS
name", but DNS name in a class that would not be used by
non-IDN-aware applications.   If those names were passed to a
non-IDN-aware app, they would presumably be rejected as improper
format if they were in UTF-8 format and passed through with a
"Class=IN" query in ACE-ish formats (or if UTF-8 slipped
through), after which they would get NODOMAIN responses.

At least some of the "directory" / "search system" / "keyword"
approaches also fall into family (iii).  See
draft-klensin-dns-role-... for some discussion of them and watch
for a new and more extensive document/ discussion RSN.  Those
assume that we would gradually migrate all applications that
reference objects using "words" or "names" or "service marks"
--rather than protocol identifiers for network objects-- to
utilize an intermediate layer (or two) whose behavior more
closely matches the expectations of normal users.  I.e.,
searching, imprecise matches, and, generally, a "when in doubt,
ask the user" strategy would be possible and normal.   That, of
course, requires changing not only the code of all of those
applications, but their user interface design.  Large deployment
problem, but possibly the right solution in the long term...
indeed, possibly that only one that will be seen as "working" in
the long term.

  Does family (iii)
> entail revising every protocol/format that embeds domain names?

And worse in some cases.  See above.

> What about the case where I send an email message to two
> people, and one of them has an IDN address and the other is
> using a mail program that predates IDN.  Can the latter reply
> to all of us?

Most likely not, at least without going to some effort.  On the
other hand, this is not necessarily bad news either.  It
encourages those who need to communicate to upgrade, just as the
relative invisibility of new hosts being added to the Internet
was one of the things that finally got people moving on DNS
deployment.  Specifically, if I sent mail to two people, one of
whom had a DNS-only address (possibly with MX records) and the
other one of whom was still using host tables, the latter could
not reply to me and the other correspondent without going
through a more or less complicated drill to translate the DNS
name into an address.  So we have been there before, with what I
would contend was a very similar situation, and we survived it.

> I might not be understanding what you have in mind, but (iii)
> looks difficult to deploy without a lot of effort/pain.

I have carefully not claimed otherwise.  The difficulties with
(i) and (ii) is that they

* Risk considerable damage and subtle interoperability problems
that users can't work around (note that the Hosttable-DNS
transition example above is a case where we have worked examples
of a transition situation the user can work around)

* Arguably don't solve the problem.  As long as there is a
single case in which the result produced by nameprep may be
debatably wrong from the standpoint of a user (characters that
match across scripts and different treatments of case matching
are likely candidate problem areas here, but there are others),
or in which mapping rules are required that may be complex, not
one-one, or that may have heuristic properties, we are sooner or
later going to need something with "search" or "fuzzy match",
not just "lookup" properties.   

The DNS can't do that, and that makes the question one of "if we
have to deploy an 'other layer' solution eventually --including
all those application changes-- do we really help ourselves by
putting complex and risky solutions into the DNS?".  I have
opinions about the answer to that question, but wouldn't claim
to have any certainty about the correct answer.

    john