Re: [idn] phasing out ACE

["David Leung \(Neteka Inc.\)" <david@neteka.com>]

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