Subject: [idn] phasing out ACE

From: "Adam M. Costello" <[email-masked]>
Date: Fri, 29 Mar 2002 22:35:47 +0000

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.

On one side are people who think it is both possible and desirable
to phase out ACE eventually.  On the other side are people who doubt
whether it is possible or worth the effort to phase out ACE.  I don't
recall anyone saying that ACE should live forever even if it were easy
and painless to phase out.

So the people who favor the phase-out can go ahead and work toward that
goal.  The others need not bother to stand in the way (because if the
goal is unachievable, there's no need to oppose it, and if the goal is
not worth the effort, then opposing the goal is likewise not worth the
effort).

I see only two points of possible contention for this working group:

First, should the IDNA spec state that ACE is transitional, or should
it state that ACE is the long-term solution, or should it take neither
position?  By remaining neutral it would not shut the door on either
possibility, so this ought to be the least objectionable to the most
people.

Second, should DNS extensions for native support of IDNs be developed
by the idn working group, or the dnsext working group?  Phasing out
ACE will require upgrades to every IETF standard that uses domain
names, and hence will involve many working groups.  DNS is just one
of many protocols that will need to be upgraded.  So perhaps the idn
working group should take a coordinating/consulting role, while the new
standards are actually produced by other working groups.  DNS need not
be an exception.

AMC

---

From: Mats Dufberg <[email-masked]>
Date: Sat, 30 Mar 2002 00:55:24 +0100 (CET)

> and painless to phase out.

ACE is like quoted-printable in mail messages. It is a solution that will
cause the least problem for time being, but not the solution that anyone
would invent from scratch.

> possibility, so this ought to be the least objectionable to the most

To state that the ACE solution is transitional, we have to know how and by
what it should be replace. When (and if) there is a better solution, we
should welcome that to replace ACE.

> standards are actually produced by other working groups.  DNS need not

Replacing ACE with, say, UTF-8, if possible, is a task for an entire new
working group. The dnsext working group will possibly close when the
DNSsec work is done. As you note, such work will effect several IETF
standards. Every such standard must be updated first to be neutral between
7bit ASCII and unicode encoded in UTF-8 (or some other encoding), before
DNS can be updated.

Mats

----------------------------------------------------------------------
Mats Dufberg <[email-masked]>
----------------------------------------------------------------------

---

From: "D. J. Bernstein" <[email-masked]>
Date: 30 Mar 2002 01:39:41 -0000

Adam M. Costello writes:
> 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.

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.

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

---

From: "Adam M. Costello" <[email-masked]>
Date: Sat, 30 Mar 2002 02:24:29 +0000

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

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

Yes, if a UTF-8 mail header standard is going to appear ever, it would
be convenient (not essential, but convenient) if it could appear soon,
so that applications would have the option of adding support for IDNA
and UTF-8 headers all at once.

> UTF-8

UTF-8 in what?  In UTF-8 mail headers and SMTP commands that haven't
been standardized yet?  And in upgraded HTML, HTTP, SSL, etc. standards
that haven't been created yet?  And on and on...  IDNA can't set
requirements for all these protocols, because it's way outside the scope
and expertise if this working group.

By letting IDNA out the door before we've added UTF-8 support to every
protocol, we give applications the choice of using IDNs now (and
possibly facing two upgrades), or hanging back and waiting to see if
UTF-8 versions of their protocols are forthcoming (so they can just do
one big upgrade).

AMC

---

From: Mats Dufberg <[email-masked]>
Date: Sat, 30 Mar 2002 12:24:12 +0100 (CET)

> would have been able to deploy UTF-8 years ago.

Stop nagging about the claimed bugs in sendmail. We all know that your
MTA is superior to any other know or futur MTA. OK?

You had the same problem with mail as with DNS. The mailstandard said that
the headers must be seven bit, and you wish for:

  And the lord said "Be 8 bit" and all installed MTA's were by the
  wish of the lord 8 bit clean. And the lord saw that mail was good.

Contrary to your claim, the path that was taken has proved to be a safe
path. The problems we have seen have not been due to bad protocol, but to
bad implementations.

> redeployment of those programs.

The first move (the introduction of IDN with ACE) will only require
replacement of mail clients. And nothing will truely break without
replacement.

The second move will require the replacement of both servers and mail
clients. That step must be taken with care.

> _all_ programs will require at most one upgrade---maybe 0.5 on average.

  And the lord said "Replace 7 bit with 8 bit on the day of rest when
  nobody uses mail" and holy men did what the lord said, and nobody even
  noticed the change. Everything was replaced when people were at rest.
  The holy men saw that the path was good, and praised the lord.

Mats