Re: [idn] I don't want 8-bit failures in 2011

["Eric A. Hall" <ehall@ehsco.com>]

> > It is clearly within the scope of IDN to consider the
> > interoperability issues here---as illustrated by the Sendmail
> > entry in my list of upgrades necessary for UTF-8.
> 
> of course.  after all, it's this very set of interoperability isssues
> that makes ACE solutions so compelling.

I'm not taking sides in the debate but I would like to point out that by
not making forward compatibility an explicit extension, the use of ACE and
a legacy-friendly message practically guarantees that problems with mixed
encodings will go up. Legacy apps and resolvers that encounter UTF8 names
in documents and links will use the UTF8 domain names even though they
should not do so. As IDNs are promulgated, this problem will get worse,
not better.

Just as a statement of fact, it really would be *easier* (not better, but
easier) to embrace UTF8 directly since there is nothing that prevents UTF8
from being used in queries today except the hostname limitations. Just as
a simple measurement of where implementations are today, UTF8 mostly works
while ACE does not work at all. This means that we are *closer* to UTF8
everywhere than we are to ACE everywhere. This is a simple statement of
fact without examining the technical merits of the solutions, I am not
taking sides in the debate but instead am trying to make simple
observations plain.

In short, ACE actually makes it easier for bad things to happen, since it
does not mandate new behavior. In the end, going with ACE translates
directly into more apps trying to use UTF8, not less. This is not a
compelling (in a good way) feature.

FWIW, these same problems exist if just-send-UTF8 is used. Both ACE and
just-send-UTF8 suffer the same inheritance problems with legacy apps and
resolvers. For example, UTF8-encoded names don't necessarily signify that
the name has been nameprep'd, so it is just as easy for a UTF8 lookup to
send bad data as it is for an ACE system. As such, they both have
tremendous problems.

[Personally, if there were a vote tomorrow I would go for the EDNS
approach, for a variety of reasons, but primarily because it requires
explicit forward compatibility and solves a bunch of other problems along
the way.]

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/