Subject: Re: [idn] phasing out ACE

From: "David Leung \(Neteka Inc.\)" <[email-masked]>
Date: Mon, 1 Apr 2002 01:39:41 -0500

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

---

From: "James Seng" <[email-masked]>
Date: Mon, 1 Apr 2002 15:15:56 +0800

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

-James Seng

---

From: "D. J. Bernstein" <[email-masked]>
Date: 1 Apr 2002 09:20:04 -0000

Adam M. Costello writes:
> IDNA can't set requirements for all these protocols, because it's way
> outside the scope and expertise if this working group.

Next I suppose you'll claim that RFC 2277, which requires UTF-8 support
for text in all protocols, can't possibly exist.

It is clearly within the scope of IDN to do the same for domain names.
Doing the same for mailbox names is arguably also within the scope of
IDN, since domain names are copied to mailbox names in many cases. More
importantly, to the extent that shortsighted WG limitations screw up the
engineering, those limitations obviously have to be removed.

Furthermore, IDN _does_ have the expertise to fix SMTP, HTTP, etc. The
fixes are so easy that I bet even you can understand them.

See, these protocols work with 8-bit bytes. (The Internet, in case you
haven't noticed, transmits 8-bit bytes.) But sometimes the protocols
specifically prohibit bytes 128-255.

We simply eliminate those prohibitions. Implementations are required to
treat bytes 128-255 in domain names, mailbox names, etc. as nicely as
ASCII letters; the default character set is simply declared to be UTF-8.
Failure to support UTF-8 is considered a software bug. Data creators are
cautioned against venturing outside ASCII before the bugs are fixed.

Can you find even a single standard Internet protocol with domain names
that aren't covered by this rule? Can you show us even a single piece of
networking code for which you can't figure out how to follow this rule?

---D. J. Bernstein, Associate Professor, Department of Mathematics,
Statistics, and Computer Science, University of Illinois at Chicago

---

From: Sampo Syreeni <[email-masked]>
Date: Mon, 1 Apr 2002 13:44:58 +0300 (EEST)

Quoting from RFC2277:

>This document does not mandate a policy on name internationalization, but
>requires that all protocols describe whether names are internationalized
>or US-ASCII.
>
>[...]
>
>A "name" is an identifier such as a person's name, a hostname, a
>domainname, a filename or an E-mail address; it is often treated as an
>identifier rather than as a piece of text, and is often used in
>protocols as an identifier for entities, without surrounding text.

RFC2277 does not apply to domain names or DNS's encoding of them.
Evidently the people who wrote the above part foresaw the problems
associated with requiring full language and charset tagging functionality
for names which, most of the time, are treated like opaque strings of
bytes anyway. They understood that a whole lot of names exist in current
protocols, and that they cannot possibly all be expected to migrate to
UTF-8.

Besides, even if RFC2277 *did* apply, it is acknowledged that deviation
from its requirements are possible within the BCP0009 section 9.1 variance
procedure. Here, for well known reasons of compression efficiency and
ASCII compatibility, variant procedure would be easily justified.

Sampo Syreeni, aka decoy - mailto:[email-masked], tel:+358-50-5756111
student/math+cs/helsinki university, http://www.iki.fi/~decoy/front
openpgp: 050985C2/025E D175 ABE5 027C 9494 EEB0 E090 8BA9 0509 85C2

---

From: "Adam M. Costello" <[email-masked]>
Date: Tue, 2 Apr 2002 20:44:48 +0000

"D. J. Bernstein" <[email-masked]> wrote:

> > IDNA can't set requirements for all these protocols, because it's
> > way outside the scope and expertise if this working group.
>
> Next I suppose you'll claim that RFC 2277, which requires UTF-8
> support for text in all protocols, can't possibly exist.

I was speaking about protocol requirements themselves, not
meta-requirements imposed on protocol specifications.  The RFC-2277
requirement that new protocols support UTF-8 for text is a
meta-requirement.  It doesn't say exactly how each protocol will satisfy
that meta-requirement.

The IDN working group could perhaps issue a similar meta-requirement
saying that protocols that use domain names must be upgraded to
support UTF-8, but people would still need to decide exactly what
changes to make to each protocol to bring it into compliance with the
meta-requirement, and that work would be done in other working groups,
because it's out of scope of this one.

[For the record, even if such a meta-requirement would be in-scope, I
wouldn't recommend it.  For some protocols it might not be worth the
trouble to upgrade.]

> (The Internet, in case you haven't noticed, transmits 8-bit bytes.)
> But sometimes the protocols specifically prohibit bytes 128-255.
>
> We simply eliminate those prohibitions.  Implementations are required
> to treat bytes 128-255 in domain names, mailbox names, etc. as nicely
> as ASCII letters; the default character set is simply declared to be
> UTF-8.

That's certainly one technique that almost any protocol *could* use to
add support for UTF-8.  But some protocols might prefer a more graceful
transition than simply sending 8-bit data to old implementations that
expect 7-bit data and letting them choke on it.  For example, people
have discussed negotiation and new header fields.  There should be an
opportunity for each protocol to use an upgrade path best suited to its
needs.

[And I think not upgrading should also be an option, since IDNA can
still be used on top of protocols that don't upgrade.]

AMC

---

From: Dave Crocker <[email-masked]>
Date: Tue, 02 Apr 2002 13:08:10 -0800

>IDN, since domain names are copied to mailbox names in many cases. More

Well that means we also need to start specifying changes for graphics 
printers, since domain names are copied to printers.

d/

----------
Dave Crocker <mailto:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850