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.)" <[EMAIL PROTECTED]> To: "D. J. Bernstein" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> 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... > > >
