Re: Line Wrapping Question

[Lennart Lovstrand <[e-mail]>]

> 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: <[e-mail]>
Date: Wed, 07 Feb 1996 12:28:20 -0800 (PST)
From: Ned Freed <[e-mail]>
To: [e-mail]
Cc: "Sukvinder Singh Gill (Exchange)" <[e-mail]>om>,
        "[e-mail]" <[e-mail]>
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=[e-mail]>
 <c=US%a=_%p=Microsoft%l=[e-mail]>

[...]