RE: [idn] host name vs. domain name

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

Ira,

--On Monday, 20 March, 2000 19:31 -0800 "McDonald, Ira"
<imcdonald@sharplabs.com> wrote:

> Hi John,
> 
> With the widespread deployment of NAT boxes in corporate
> intranets and corresponding explosion of 'ephemeral' IPv4
> addresses in traffic over the public Internet, the assumption
> that IPv4 addresses have any durable meaning is already
> broken beyond repair (see 'Internet Transparency', RFC 2775,
> February 2000).

Well, at several levels, I agree completely.  My comment was
only to stress that things will be even worse (better?) with
IPv6, since relatively ephemeral addresses were part of the
design intent there, not merely something that has happened to
us..

> Certainly the IETF Zero Configuration WG and DHCP WG are
> attuned to this state of affairs.  It seems like a little
> attention to this aspect (the non-durable relationship
> between DNS 'name' and IPv4/IPv6 'address') should be
> paid by the IDN WG.

Certainly any proposed solution that emerges from the IDN
process which assumes long-lived addresses will not be usefully
deployable in many (and an increasing number of) contexts.   And
assuming that some applications don't need to use the DNS would
just be a special case of that, and equally untenable.

The point I think Bill and I were circling around is that it is
possible to believe that some applications need
_internationalized_ DNS and others don't, or don't as much.  If
one believes that, then one might be able to design an
i18n-specific RR which is as specific to that/those
application(s) as MX RRs are to email.  To pursue that line of
reasoning a bit further -- **please note that I am _not_
proposing this** -- suppose that the conclusion was that there
were really two types of uses of the DNS (oversimplifying
somewhat):

       * the traditional "lookup" function, in which DNS names
       are treated as protocol elements and there isn't a strong
       assumption that one can be guessed at from knowing, e.g.,
       the product names of the company that owns the host.
     
     * the DNS-as-directory-substitute function, in which people
     do expect to be able to type DNS names and to deduce them
     from company or product names.

If that categorization worked, and the second group (mostly the
web today, although other entries are possible), didn't need
reverse mappings to original names then one could significantly
change the problem and the set of possible answers.   Note that,
in general, reverse mappings don't work for labels that identify
only MX RRs: only the MX targets are, again in general,
reverse-mappable.  So we've got years of experience dealing with
this situation. If the WG concluded that approach was workable,
then labels on the existings RRs could (continue to) be treated
as protocol elements and hence stay in the
applications-restricted character set now used.   And we could
invent a new RR, perhaps "INT", or "WWW", whose label would be
in an appropriate 10646 encoding and whose target would be one
of the existing RR types (other than PTR or maybe CNAME
--another detail that would need to be worked through).

This approach has the rather significant advantage that nothing
now running breaks: it essentially adds an extra layer to the
applications that require it, and incremental deployment works
nicely (although there are still some potential leakage problems
during transition).   Unlike approaches that try to do much the
same thing by hiding information in other RR types, it is pretty
clean and unlikely to have unanticipated side effects.   And,
while deployment and user-end updating is still an issue, the
number of distinct web browser code bases in the world is a lot
smaller than, e.g., the number of MUAs, MTAs, etc.

However --again please remember that this is a strawman, rather
than a proposal I'm making and will support-- there are a few
difficulties.  For example...

(i) A significant fraction of the community --especially those
who believe that we should adopt one or another "force
everything into international characters as quickly and abruptly
as possible, even if it breaks things" position-- are going to
find it unaesthetic, if not immoral.

(ii) There has been speculation for years about the neat and
useful things that could be done, especially wrt location and
access to replicated content, if one had a web-specific RR.  I
would assume that any proposal to add a web-specific (or nearly
web-specific) RR would reopen those discussions.  I doubt that
they would be quick.

(iii) If one were going to essentially invent layering within
the DNS, with an RR type that carries an i18n label but that
just points to traditional types and with no reverse mappings,
there might be few disadvantages, and many advantages, to
introducing a real directory layer instead.   Several people
have pointed out on this list that the real source of many of
the internationalization issues is misuse of the DNS as a
directory service; for most of the things that directory
services do well, they do them a lot better than the DNS does
and there would be a number of technical advantages of going
this route.  Of course, it would probably be opposed by those
whose businesses depend on the selling of names and the presumed
scarcity of those names, since a heavily-used directory layer
would essentially eliminate that business, but that is just
another difficult tradeoff.

Ultimately, these sorts of alternatives are the reason why
getting the requirements both specific and correct is so
important.

    john