Of course my world view isn't universal. It would be silly to assume so.
However, the point you seem to be consistently missing is that my position
is not based on my own biases as to how things should work.
YES THEY ARE! Oh dear, now I've done it. I've been trying for the longest
time to avoid getting involved in an argument that I don't think will lead
anywhere, but I can't take it anymore. I've been working on email software
for 10+ years and a (mostly lurking) member of the ietf-822 mailing list for
four of them. What really irks me is when certain members of this group take
on this "I know better than you" attitude and swiftly dismiss other peoples'
objections or ideas because they don't match with their own views of the
world. I'm sorry, but I don't believe that you -- or anyone else, myself
included -- have a guaranteed hotline to the Truth and The One Way Things
Really Work. This state is commonly known as hubris, and usually leads to a
rude awakening down the line.
My intent is to state how the *standards* *say* things *are* *required* to
work and that software agents exist that operate on the assumption that the
standards are to be obeyed in this regard.
Who makes the standards? I think your name is on the top of the MIME spec.
Does that make you an impartial observer? I don't think so.
As for what this particular standard specifies, I haven't seen any
statements (your quoted ones included) that has made me believe that
transmitting paragraph-length lines was a bad thing and against the spec. On
the contrary, by their very existence I've always thought of Q-P's "soft"
line breaks as a convenient way to let non-MIME recipients get a message that
would be readable on dumb terminals, while MIME UAs would rejoin the lines
and presumably present them in a reasonable way. I have no illusions of Q-P
implying a particular presentation, but until now, I did believe that any
modern MIME-capable mail UA would have automatic line breaking built in. I
also had no idea that this could be a controversial issue. Regrettably, I
was apparently mistaken on both counts.
All I'm trying to say is that I too -- in good faith, I assure you -- went
along and used Q-P as a way to encode paragraphs in NeXT's Mail 3.3 program.
Is this bad? I wouldn't had thought so, but apparently we disagree on that.
What should be done? Well, it looks like we have three choices:
1. Explicitly disallow (or at least recommend against) sending
paragraph-long lines with text/plain.
2. Explicitly allow long lines with a recommendation that they may have to
be wrapped for a reasonable presentation.
3. Find some other way to represent paragraph oriented text.
Simply saying that all text should be "hardwrapped" I don't see as an option
since it's akin to throwing out the baby with the bathwater. Some of you
may not care much about it, but after having lived for many years with
different email systems that do handle this (eg. Xerox Lafite, Andrew, NeXT
Mail), I have no intention of going back to hardwrapped text.
Using text/enriched instead of text/plain like you suggested earlier is
indeed an option, although it has its own disadvantages that makes it
arguably less attractive for non-MIME recipients (ie. the doubling of hard
newlines and less-than signs). I also fear that it is so little supported
that few recipients will ever see the benefits of the intended presentation.
Yes, if their MIME UAs are properly implemented, the body should at least be
treated as text/plain, but that would be as bad as not having MIME at all.
I frankly don't think much of the future of text/enriched, but I hope that
text/html will soon become popular enough for most of these "Luddite" (or, if
you prefer, "legacy") problems to go away. Still, to get there we first
need an agreement of how to represent the external parts of html, ie. images
and links. I have seen a lot of discussion on the topic, but little attempt
at finding a consensus. Perhaps we will have to wait until some strong party
goes ahead and simply makes a convincing implementation, and then swallow
that wholemeal. I have to admit that I don't really care much about how it's
done, but I do want it.
In the mean time, I'll look into what it would mean for us to switch our
implementation from using long Q-P-encoded text/plain lines to "plain"
text/enriched. We already support both sending and receiving text/enriched,
so it won't be a very long step to take. I only hope that other MIME UAs
will treat it reasonably if we start using it more.
Finally, please forgive me for being a bit moralizing for a moment.
Progress is a painful process, but as long as we can be civil to each other,
there is hope for the future. In this particular case, I saw someone from
Microsoft post a perfectly reasonable question only to have his head chopped
off in response. I don't think it matters who does it, it's just as rude
every time. Worse, I fear that I may be the victim next time. This makes me
less willing to participate in a public forum. This, I believe, is
unfortunate. Do you agree?
Regards,
Lennart Lovstrand
NeXT Software Engineering
(BTW, the Content-Transfer-Encoding: header below in the message I received
is broken. I don't know if it was originally created that way or if it got
damaged on the way, but I'm assuming that someone want to know about it.)
Message-Id: <01I0XK2QDNBI9N3WDF(_at_)INNOSOFT(_dot_)COM>
Date: Wed, 07 Feb 1996 12:28:20 -0800 (PST)
From: Ned Freed <NED(_at_)innosoft(_dot_)com>
To: Valdis(_dot_)Kletnieks(_at_)vt(_dot_)edu
Cc: "Sukvinder Singh Gill (Exchange)"
<sukvg(_at_)wspu(_dot_)MICROSOFT(_dot_)com>,
"ietf-822(_at_)list(_dot_)cren(_dot_)net"
<ietf-822(_at_)list(_dot_)cren(_dot_)net>
Subject: Re: Line Wrapping Question
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; CHARSET=US-ASCII
Content-Transfer-Encoding: 7BIT
<c=US%a=_%p=Microsoft%l=DABONE960207083118QU005600(_at_)yuri(_dot_)microsoft(_dot_)com>
<c=US%a=_%p=Microsoft%l=DABONE960207083118QU005600(_at_)yuri(_dot_)microsoft(_dot_)com>
[...]