Re: [idn] Alternative Solutions

["Adam M. Costello" <amc@cs.berkeley.edu>]

This discussion seems to be getting more complicated than necessary.

First, let's make sure we all mean the same thing when we say "ACE".
When I say "ACE", I mean a reversible algorithmic mapping from Unicode
strings to LDH strings.

What started this thread was the possibility that patents might prevent
us from using an ACE.  If we're going to use an ACE at all, we might
as well stick with IDNA, so the alternative ideas, whatever they are,
should not require the use of an ACE.

The main problem that IDN needs to solve is the problem of higher-layer
protocols and software assuming that domain names contain only LDH
characters and dots.  So for every Unicode domain name, there needs
to be an LDH domain name that these older protocols and software can
use.  If we're not allowed to do the transformation algorithmically, the
obvious other option is a giant lookup table.  And that's what DNS is.

So take the IDNA architecture, replace the ace_encode operation by a
dns_lookup_ldh_of(unicode_name) operation, and replace the ace_decode
operation by a dns_lookup_unicode_of(ldh_name) operation.  Everything
else can stay the same.

That bears repeating:  Everything else can stay the same as IDNA.
Things that work or don't work in IDNA will still work or not work in
the new scheme.  The only exceptions are:

  * Applications now need to be online to do these operations, whereas
    in IDNA they could be offline.

  * IDNs can exist only in domains served by upgraded DNS servers that
    know the new resource record types, whereas IDNA requires no changes
    to DNS.

  * The LDH name need not look like gibberish (as in IDNA), but
    can be chosen at the whims of the registrants and/or name
    server administrators.  (Some may choose to manually select
    meaningful LDH names, while others may choose to use an algorithmic
    transformation for ease of administration, but there is no need for
    standardization, or even publication, of the algorithm.)

As someone already pointed out, this is just adding another layer.  Just
as domain names are a layer of abstraction on top of IP addresses,
mapped back and forth by A and PTR records, IDNs would be a layer of
abstraction on top of LDH domain names, mapped back and forth by two new
record types.

I don't like this scheme very much.  I'd prefer IDNA.  But if IDNA were
not an option, this would be an obvious thing to look at instead.

Keith Moore <moore@cs.utk.edu> wrote:

> *AND* we insist that "international" names are never leaked *by any
> protocol* (including, say, SMTP) to an application that doesn't
> understand them.  In practice this means not just a mode bit for DNS
> but also a mode bit for every protocol that carries DNS names.

Existing protocols carry only LDH names, so there is no mode bit.  New
protocols (or new versions of old ones) could choose to use a mode
bit, or could choose to continue to carry only LDH names, and let the
receiver look up the Unicode name if it wants to.

AMC