From: Dan Kohn (dan@dankohn.com)
Date: Tue Apr 02 2002 - 13:54:13 CST
It's not clear how format=flowed could have been improved, given that
many popular MUAs (in violation of RFC 2046) present text/paragraph as
an attachment rather than text/plain. The argument for 2646 is that
even nicely formatted 74 character lines, when quoted 5 times, will
start exhibiting embarrassing line wrap. Many MTAs (e.g., Exchange)
wrap at unpredictable and user-uncontrollable lengths, even the first
reply can get line lengths mangled. Given that 2646 has the potential
to solve the problem completely, it seems a shame not to mention it.
- dan
-- Dan Kohn <mailto:dan@dankohn.com> <http://www.dankohn.com/> <tel:+1-650-327-2600> Essays announced on <mailto:dankohn-subscribe@yahoogroups.com>-----Original Message----- From: Charles Lindsey [mailto:chl@clw.cs.man.ac.uk] Sent: Tuesday, April 02, 2002 08:59 To: Dan Kohn; usenet-format@landfield.com Subject: Re: FW: [idn] Re: 7 bits forever!
On Mon, 1 Apr 2002 21:21:12 -0800 "Dan Kohn" <dan@dankohn.com> said...
> > I thought you might be interested in email below, given your USEFOR > work. Feel free to send to USEFOR, if appropriate.
Forwarded as suggested.
> I would be > interested in your views on making gateways support downconversion of > parameter names to 2231 format.
I regard RFC 2231 as a mess that never ought to have happened (an extension of the applicability of RFC 2047 would have made much more sense). It's implementation seems to be very patchy. However, there it is, so we cannot ignore it :-( .
Present plan, when I rewrite the gatewaying bit, is to leave it to gateways whether they take a chance on leaving the 8bit stuff alone, or whether to downconvert using RFC 2047 and/or RFC 2231. A particular gateway will know who its intended clients are, and hence what it can get away with, and whether it matters or not. > > Also, here's a comment on your -06 USEFOR draft: > > + I would seriously consider referencing RFC 2646 as a SHOULD in section > 4.3.2, as it significantly improves the chance for automatic > interpretation of multiple quoting blocks.
Ah! The Gelens format=flowed thing. Another bit of protocol that could have been done much better with a bit more thought. I am not anxious to mention it. The general opinion within Usenet at the moment is that your ought to fit into 79 columns if you expect to be widely read.
> > - dan > -- > Dan Kohn <mailto:dan@dankohn.com> > <http://www.dankohn.com/> <tel:+1-650-327-2600> > Essays announced on <mailto:dankohn-subscribe@yahoogroups.com> > > -----Original Message----- > From: Dan Kohn > Sent: Monday, April 01, 2002 17:31 > To: 'ietf-smtp@imc.org' > Cc: 'Einar Stefferud'; ietf@ietf.org; idn@ops.ietf.org > Subject: RE: [idn] Re: 7 bits forever! > > > I believe that Einar could be most easily satisfied with something along > the lines of a UTF8HEADERS ESMTP extension, which would specify both > that 8 bit character are permitted in the header and that those > characters MUST be interpreted as UTF-8. It would be expected that this > extension would normally be used in conjunction with 8BITMIME [1] or > BINARYMIME [2]. The challenge is that any mail relay implementing this > extension MUST be able to downconvert headers to 7-bit RFC 2047 [3] > compliant encoded words if the next hop does not support UTF8HEADERS. > > This would seem to be a middle ground between Dan's desire for > just-send-8 and other's demand that existing RFC 2821 [4] compliant > relays not be broken by adding support for UTF-8 headers.
Yes, there I am with you entirely. If only one quarter of the energy that has been spent on cramming everything into 7 bits had instead been spent on making email transports 8bit clean in the first place, we should never have got into this mess. But people are still trying to do it :-( . It is like the conversion from pounds/feet/pints into kilograms/metres/litres. In the UK we decided to do it in principle 40 years ago, and we are still not there. In Canada, they "just did it", and it was all over in about 5 years.
We have tried to do our bit in Usefor by making it 8bit clean by edict (well, it was so already). But OTOH we did not need to be quite so squeamish about the odd site that did not conform, since the flooding algorithm will find a way around it and we can live with something less than 100% perfect. Sadly, however, Netnews has always been under pressure to conform to the Email standards. It is time there was a little traffic in the other direction :-) . > > This should be an easy RFC to write up. If there is interest from > implementers, I would be happy to do so. In any event, I would suggest > taking follow-up to ietf-smtp [5]. > > [1] http://www.ietf.org/rfc/rfc1652.txt > [2] http://www.ietf.org/rfc/rfc3030.txt > [3] http://www.ietf.org/rfc/rfc2047.txt > [4] http://www.ietf.org/rfc/rfc2821.txt > [5] http://www.imc.org/ietf-smtp/ > > - dan > -- > Dan Kohn <mailto:dan@dankohn.com> > <http://www.dankohn.com/> <tel:+1-650-327-2600> > Essays announced on <mailto:dankohn-subscribe@yahoogroups.com> > > > -----Original Message----- > From: Einar Stefferud [mailto:stef@nma.com] > Sent: Monday, April 01, 2002 11:47 > To: ietf@ietf.org; idn@ops.ietf.org > Subject: Re: [idn] Re: 7 bits forever! > > > Hi John -- My thesis is that the problem lies now in the SMTP > standards, where the current "Send 8-bits" problem has always > resided. The MIME working group could not solve that problem, and so > did not, but it made mail work since its deployment, which was the > objective in the MIME WG. inside the RFC822 Body there is only one > way to handle 8-bit data, and that is to tag it, and bag it. Even if > you can transmit 8-bit data without encoding it in the body of an > SMTP message, it needs to be tagged and delimited in the body. > > MIME Quoted-Printable was designed to be a work-around-damage > solution at the time, and was not design to remove the need for > handling 8-bit data in SMTP. > > So, my only point is that it appears that some work needs to be done > in the SMTP standards, and beating up on the MIME WG does not compute > given this observation. > > That is all... Just trying to shift the focus of this thread to > where someone might think of a way to solve the current problem. > > In the meantime, Thankfully, Mail still works, which was the MIME > objective for Quoted-Printable. > > Cheers;-)....\Stef > > > At 12:41 PM -0500 4/1/02, John C Klensin wrote: > >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 > > > > > > > > > > > > > > > > > > > > - > This message was passed through ietf_censored@carmen.ipv6.cselt.it, > which > is a sublist of ietf@ietf.org. Not all messages are passed. > Decisions on what to pass are made solely by Raffaele D'Albenzio. >
Charles H. Lindsey ---------At Home, doing my own thing------------------------ Tel: +44 161 436 6131 Fax: +44 161 436 6133 Web: http://www.cs.man.ac.uk/~chl Email: chl@clw.cs.man.ac.uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K. PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5