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

["James Seng/Personal" <James@Seng.cc>]

Hi Eric,

This pros and cons discussion have been done before and been considered
by the Protocol Design Team. Check out their reports on
http://www.i-d-n.net/ietf49/idn-sandiego-protocol-design-term-report.ppt

While you are there http://www.i-d-n.net/, you may also want to read a
few I-Ds, including

draft-idn-idne-01.txt, on how to use EDNS for IDN

but more importantly, draft-klensin-dns-role-00.txt which discuss why
above may not be right solution either.

And for a really long term solution (which may be totally out of the
scope of this WG) due to the radical approach proposed,
draft-klensin-dnsclass0e-00.txt. :-)

-James Seng

----- Original Message -----
From: "Eric A. Hall" <ehall@ehsco.com>
Cc: <idn@ops.ietf.org>
Sent: Monday, February 05, 2001 10:55 AM
Subject: Re: [idn] I don't want 8-bit failures in 2011


>
> 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/
>