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