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.
Geez. Did I say anything like this? I don't think so... The only "suggestion"
that has been made here as far as I know was to add some prose to the MIME
specification. I did object to the prose, but I certainly did not dismiss it
out of hand. On the contrary, I spent considerable time looking into it and
formulating a detailed response explaining why I thought it was not appropriate
to include the prose in the MIME document.
I try to take all suggestions for changes to MIME seriously and answer
them fully and completely. If I screw up sometimes I certainly apologize
for it.
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.
Of course I'm not an impartial observer. Nor did I ever claim to be one. My
participation in this discussion makes it obvious that I'm nothing of the sort.
If I were an impartial observer by definition I would not be a participant.
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.
I certainly hope not, because it is not a bad thing and it is entirely in
accordance with the specification to do it. My objection to the suggested prose
was exactly this, in fact -- the suggested prose recommended banning (or at
least deprecating) doing things like this. Many systems currently depend on the
ability to send long lines in text and have them arrive intact.
You are absolutely allowed to transmit long lines of text if you want to do so.
The specification specifically allows for it. The problem lies in how receiving
agents are expected to handle such material. Microsoft apparently assumed that
such material would be wrapped automatically, and also assumed that using
quoted-printable would in some way provide a guarantee of this. And such
assumptions are contrary to the MIME specification.
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.
Misreading the specifications is one thing. Having expectations that have
nothing whatsoever to back them up in the specification is a different
situation. There is nothing in the MIME conformance document that says that
line wrapping services must be provided by receiving user agents.
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.
Using QP is perfectly fine, and I applaud you for having used it. Expecting
MIME-capable agents to have line wrapping facilities available is a different
(and separate) matter.
Is this bad? I wouldn't had thought so, but apparently we disagree on that.
I'm not sure about that. If the material was properly formatted underneath the
QP for whatever agent you expected to send to I see no problems with your
approach. If, on the other hand, you expected all agents in the world to have
the ability to line wrap, a capability nowhere required by MIME, I would have
to say that your expectations were a overly hopeful. And if you expected QP
encoding to somehow imply to MIME agents that line wrapping should be done,
then I would say that your usage is contrary to the specifications.
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.
This is a bit simplistic. What if I want to have really long lines in the
material I send? How am I supposed to accomplish this in the face of such a
recommendation?
The point here is not to send material that isn't suitable for display "as-is".
Not to avoid long lines altogether. Not to ban such usage outright.
2. Explicitly allow long lines with a recommendation that they may have to
be wrapped for a reasonable presentation.
What consitutes "reasonable presentation"? I deal with material all the time
that cannot tolerate being line-wrapped, and I suspect lots of other people do
as well.
If you want lines wrapped you can either use text/plain and do it yourself or
use a format that let's you tell the receiver when it's appropriate to do it.
3. Find some other way to represent paragraph oriented text.
Presumably by using one of the other formats we have already defined for
this purpose.
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.
Nor do I. It's probably obvious from the messages I send that the agent I use
does line wrapping for me. I certainly don't bother to do the wrapping
manually!
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.
Speaking as an early proponent of text/richtext back in the days when Nathaniel
and I fought to keep it in the MIME specification (and eventually lost), I must
say I used to be very disappointed as what I saw as an outright rejection by
most developers of text/enriched. But recently the good folks at Qualcomm and
Intercon have opened my eyes: There is an amazing amount of support for
text/enriched out there already. Far from being rejected, it actually has
caught on in a fairly major way. It just took longer than we expected, and it
also happened without a lot of trumpets and sundry fanfare.
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.
I don't think the text/enriched proponents disagree with you, as Pete Resnick
has already illustrated in his recent posting. text/enriched is primarily seen
as a step on the road to text/html in email. Pete's discussion of the
various pros and cons was so good that I see no reason to repeat any of
it here.
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 admit to considerable frustration about this, as I believe I pointed out in
my original response. I have been over this ground with Microsoft both directly
and indirectly through various Exchange beta sites a large number of times now,
and up until now I've gotten nowhere. I'm sure I was a lot nicer the first half
a dozen times it came up in other forums.
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?
Well, it now seems that the folks at Microsoft might actually do something
about this. So maybe "chopping their heads off", to use your phrase, was a good
idea after all ;-)
(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.)
I checked -- it is not what left my system nor was it corrupted in what I
received from the list. I don't know where the problem arose for you, but I
didn't see any sign of it here.
Ned