Re: [idn] Re: 7 bits forever!

Stef,

Either I misunderstand your message, or we have a bit of a
disconnect.

The SMTP extension "8BITMIME" was specified fairly early in the
game.  My impression is that it is fairly widely deployed and
used, possibly to the extent that most non-ASCII traffic is
moving that way; someone on this list (or the SMTP extensions
one) may have some numbers.  Where it is deployed, MIME is still
required to label ("tag") the data -- one can still not tell one
sort of 8bit character from another, and there is, I think,
still much more traffic on the network in ISO 8859-N variants,
or IS 2022-based systems, or local character sets than there is
UTF-8 encoding of Unicode -- but quoted-printable (or base64)
are not, unless the mail store or mail retrieval implementation
cannot deal with 8bit materials.

      john


--On Monday, 01 April, 2002 08:59 -0800 Einar Stefferud
<stef(_at_)nma(_dot_)com> wrote:

Not to pick on Dan's particular message.
It was just the last one to provide me with a handy response
point.

Looking back, the original 1990-1991 argument was between
"Just send 8 bits" with no tagging of the content, vs "tagging
and bagging" to deal with the fact that 8-bit at that time
would break too many systems, and the problem of needing to
tag the types of text characters that were contained in RFC822
message bodies.

But, as there were two problems to solve (8 bit SMTP ) and
(tagging RFC822 content), the decision was made (after a very
long and very heated argument) to split that problem according
to the boundaries of SMTP and RFC822.

In fact, the two problems were and still are totally distinct.

The RFC822 solution group produced MIME with Quoted-Printable
as its charter specified, to assure interworkability as soon
as possible.

The 8-bit folks did not do anything then or since to require
8-bit carriage.

So, it is time for a working group to solve this problem.

It is not going to help anyone to argue about the past, as in
fact, it was very rational at the time, and one side of the
problem was ignored as soon as quoted printable relieved the
immediate pressure for an SMTP solution.

So, now is a good time for some constructive discussion of
ways to solve the charset problems, hopefully with some useful
charset tagging tools for the non-RFC-822 parts of the SMTP
envelope.  (But I do not mean to specify either the work or
the results at this point.)

It is indeed unfortunate the the DRUMS WG did not find a way
to solve the 8-bit SMTP problem, but now is the time to get to
it.  There should not be too much 7-bit SMTP code to fix by
now.

Cheers...\Stef




At 8:35 AM +0000 4/1/02, D. J. Bernstein wrote:

Claus Faerber writes:
 > D. J. Bernstein <djb(_at_)cr(_dot_)yp(_dot_)to> schrieb/wrote:
 > > I'm not saying that Quoted-Printable had no short-term
 > > benefits for

its

 > > short-term costs. I'm saying that, viewed from our
 > > long-term

perspective

 > > eleven years later, the failure to require 8-bit
 > > transparency was an amazingly stupid decision.
 > From our present perspective, that's true. Back then, it
 > might have been the best solution.

No. The failure to require 8-bit transparency was
inexcusable. Every approach that failed to require 8-bit
transparency could have been dramatically improved. Consider,
for example, these three approaches:

   (1) Quoted-Printable;
   (2) Quoted-Printable plus ``you must handle unencoded
   8-bit data too''; (3) pure 8-bit without this 7-bit
   garbage.

Whether or not you understand that #3 would have been better
than #2, surely you understand that #2 would have been vastly
better than #1.

 > Further, remember that the first MIME standards date back
 > to 1992. Back then, Unicode was brand-new and UTF-8 only
 > came with the 2.0 version in 1996. Without UTF-8, you just
 > could not even think about using Unicode in message
 > headers; and without Unicode, you could not solve the
 > charset-labelling problem.

Get your facts straight. First, UTF-8 was introduced years
before 1996, although under another name. Second, even
without knowing about UTF-8, people _were_ thinking about
Unicode in headers, and proposed several workable approaches.
Third, even without Unicode, there were several solutions to
the character-set labelling problem.

Anyway, none of this is relevant to IETF's acceptance of
7-bit garbage in 1991, and none of it is relevant to IETF's
acceptance of 7-bit garbage today.

 > The movement towards UTF-8 everywhere is quite new.

Again, get your facts straight. The ``movement'' started with
X-Open, Rob Pike, and Ken Thompson a decade ago. RFC 2277,
requiring UTF-8 support for all text on the Internet, is four
years old.

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