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

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

Keith, let me redefine the point:

One of the great things about the EDNS proposal is that it provides long
labels and names. Since this would be a favorite feature of a lot of the
non-English locales, it would be widely-adopted. In turn, its very usage
would break legacy apps and resolvers that tried to resolve the long
labels/names. That keeps UTF8 names out of the legacy lookup path, while
also encouraging upgrades to applications, resolvers and servers that
support the necessary EDNS extensions. None of the other proposals have
the ability to preserve legacy lookups while simultaneously promoting the
adoption of the new service.

There are numerous other benefits -- any application that does the EDNS
formatted lookup is (very) likely to have done nameprep on the name in the
application beforehand, it uses the same technology as A6 RRs so it can
ride the same adoption wave, and many others -- but the key point is that
the EDNS approach lets the domain names (and just the names) break the
apps and resolvers. Very little additional effort is required except for
the labels/names that do not exceed 63/255 bytes. That scenario is very
likely yes but it will only happen in a percentage of the cases instead of
all of them.

> So for example in email, even though ACE might be required in SMTP
> and in message headers, we'll see UTF-8 in both places, and we'll
> be better off if MTAs and UAs that do try to handle these things
> do so in a uniform way.

In a common scenario, the relay would write out the HELO name, the IP
address, and the PTR data. Setting aside HELO names for a moment, if the
PTR data included EDNS data which the relay or its resolver did not
understand, then the relay should leave the PTR string empty. If the app
is able to extract the EDNS name then there are ugly but feasible encoding
methods to keep it from destroying downstream mailers. As for HELO names,
there are also some potential problems there, but they don't look like
show stoppers (I don't know of any restrictions on length so encoding
appears to be the only issue). What this all means is that mail servers
aren't broken during a transition period, so no problem with EDNS-encoded
names (regardless of the length issues). (Yes I know that some anal sites
will break if they can't match HELO with PTR but that is an operational
concern which is not covered by protocol).

As for outbound mail, there might be problems if MX RRs mix legacy and
modern names. Probably not if the netadmins design their forwarding
through multi-homed and multi-named relays, and maybe no problems at all
if the mailer can't read the complete list anyway. I mean, if the mailer
only sees MX 100 on an ASCII name and never sees MX 50 with an IDN, then
SMTP will still work if the mailer only sends to 100. It will break in
situations where intermediary relays aren't capable of handling delivery
to downstreams which have IDNs but that again is an operational issue
which can be overcome. Worth exploration and testing but I don't see any
problems that are insurmountable.

> > a simple measurement of where implementations are today, UTF8 mostly
> > works while ACE does not work at all.
> 
> for DNS servers, perhaps.  for applications that transmit DNS names as
> protocol elements, the opposite is closer to the truth.

I'm not arguing for or against ACE or just-use-UTF8. The point of the
response was to point out that ACE and just-use-UTF8 both introduce major
issues with backwards compatibility. If we really want to avoid the
problems of bad names in legacy lookups then they should both be avoided.

Yes I also realize it's too late for this argument and that ACE is the
interim solution of choice. My bad for showing up late. Still the opinion
is valid.

> on the contrary, ACE does mandate new behavior in any application that
> needs to do more with an IDN than query its DNS records, pass it to
> another application, or compare one IDN with another.

None of the simple stuff above is reliable with ACE or just-use-UTF8 using
legacy apps or resolvers.

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