Re: [idn] phasing out ACE

["James Seng" <jseng@pobox.org.sg>]

I am sure accusing those who disagree with you are blindfolding themselves
is a very conviencing technical argument.

-James Seng

----- Original Message -----
From: "David Leung (Neteka Inc.)" <david@neteka.com>
To: "D. J. Bernstein" <djb@cr.yp.to>; <idn@ops.ietf.org>
Sent: Monday, April 01, 2002 2:39 PM
Subject: Re: [idn] phasing out ACE


> > > There has been much debate about whether ACE should be phased out.
> > > Even though people have different views, I don't think we really need
> > > to debate this question.
> >
> > There are two issues here.
> >
> >
> > 1. Should applications be required to handle UTF-8 properly, in
> > preparation for a UTF-8 world?
> >
> > The lessons of history are helpful at this point. If Keith Moore and his
> > buddies had---with or without Quoted-Printable---required 8-bit-clean
> > mail software in 1991, we wouldn't have sendmail's 8-bit bugs today. If
> > they had thought a little more broadly and fixed other protocols, we
> > would have been able to deploy UTF-8 years ago.
> >
> > Unfortunately, they, like you, didn't consider the long term. I don't
> > know if they were as blatant as you in claiming that shortsightedness
> > was a good thing; but the bottom line is that they, like you, made a
> > decision destined to look really stupid to future users.
>
> ACE = hiding approach, why dont we just hide away from the reality, the
ACE
> supporters are always saying that we are hiding from the reality, actually
> we are just trying to propose to look at the entire problem more carefully
> and more long term, let's not just HIDE away from the reality and try to
> come up with a real solution that can both be able to perform a fallback
to
> ASCII, and step forward to be able to accept UTF8, so that users will have
> the benefit of using UTF8. If everyone in the WG think UTF8 is something
> that is so bad to use in internet protocols, or even will break or
> "crash-and-burn" something, so i guess they are just saying that the UTF8
> itself is something that is a bad design already, if not why having UTF8
and
> not being able to use it almost anywhere, bad design in UTF8 itself or bad
> design on previous drafts or RFC and people not willing to upgrade the
RFCs
> and think long-term enough?!
>
> > 2. Should short-term plans be considered in the context of the desired
> > transition to UTF-8?
> >
> > Common sense is helpful at this point. The cost of the long-term move to
> > UTF-8 obviously depends on the choice of short-term plan. Consquently,
> > ignoring the UTF-8 transition will not produce the same cost-benefit
> > analysis as taking it into account.
> >
> > Here is one example of the variation in costs. Suppose we do a massive
> > redeployment of mail-displaying programs etc. to present IDNA names as
> > non-ASCII glyphs. Moving to UTF-8 then requires _another_ massive
> > redeployment of those programs.
> >
> > In contrast, if IDNA were modified to also require proper display of
> > UTF-8, programs dedicated to displays would require only one upgrade.
> > Notice how a small change in the short-term plan provides huge long-term
> > benefits---benefits that you are refusing to take into account.
> >
> > Even better, if we scrap this 7-bit garbage and move directly to UTF-8,
> > _all_ programs will require at most one upgrade---maybe 0.5 on average.
> > But you don't need to think about this possibility to understand why
> > ignoring the long-term plan is stupid.
>
> Totally agree... IDNA will require deployment costs and same as the pure
> UTF8 systems, so why dont we think about system that can fallback to ACE
and
> step towards using UTF8, like a hybrid approach... ignoring the long-term
is
> not only stupid, but is also trying avoid to face the real problem,
however
> the real problem is always there but a group of people just wont see it
> because they came up with a solution that haven't solve anything but just
to
> blind folded themselves...
>
>
>