Re: [idn] Re: 7 bits forever!

[John C Klensin <klensin@jck.com>]

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@nma.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@cr.yp.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
> 
> 
> 
> 
> 
>