On Wed, 7 Feb 1996, Sukvinder Singh Gill (Exchange) wrote:
Date: Wed, 7 Feb 1996 08:31:18 -0800
From: Sukvinder Singh Gill (Exchange)
Subject: Line Wrapping Question
I'd like to get some advice on a problem that many people
using our product have commented on.
Currently, when sending Internet Mail with long lines, we
default to using QP encoding so that MIME aware clients
can unwrap the lines, and display as required on their
viewers. (We use 140chars as the threshold)
You don't say much about the environment you are opperating in. Why are
you encountering very long lines? If it is because the message is the
output of a text editing system that assumes soft wrapping and where a
real new line character represents a paragraph, that's one thing. If the
problem is that most of the stuff is short but you have one or two lines
at the begining of the message that are unwrapped 822 headers from a
forwarded message, that's a completely different story.
We have received numerous complaints (most people assumed
that this was a bug) from people that use non-MIME aware
apps about the equal signs on every line.
I thought about this for awhile, and hoped the issue may
be resolved by using a prologue informing people that this
message was a MIME message, and they may see some
irregular things in it. Therefore every message that we
send, is sent using the multipart type, so that we could
use the prologue.
I would like to be able to recommend that you just go with MIME but if
the basic problem is lack of MIME support, then using another MIME
feature (multi-part in addition to QP) probably won't solve your problem
This is catch22, since people complained about the use of
multipart, even when we could have sent just text/plain
messages. (They also complained about the contents of the
prologue, but thats another issue)
? Surely you could make the use of the multipart also conditional on
there being long lines. The prolog is good in that you can give a
message saying you are using MIME that won't be seen or get in the way
for MIME capable MUAs.
I see the choices for our product as follows, and would
like your feedback on what you consider the right choice,
or suggestions on doing something better.
a)We provide an option to hard wrap lines, therefore we
don't use QP encoding to deal with the line wrapping issue
i.e. CTE is 7-bit unless QP is required for some other
Options are good. An option to hard wrap seems useful. (Although if
there are only one or two long lines out of many, QP should not be
b) We just hard wrap without an option even when using QP
(An option is probably a good thing to turn this to use QP
c) We leave things the way they are.
d) We don't send the prologue, and hope that the world
will move to MIME, and this becomes a non-issue.
I think the world is moving to MIME, although gradually, so it will
eventually become a non-issue, but your customers are complaining now.
The user based and organization environments probably vary so much that
one or more options is probably the only way to do.
I really only consider option a, or b as viable for our
user population, but I'll wait to hear back from people
before I commit.
Sukvinder S. Gill
E-Mail - sukvg(_at_)microsoft(_dot_)com
Donald E. Eastlake 3rd +1 508-287-4877(tel) dee(_at_)cybercash(_dot_)com
318 Acton Street +1 508-371-7148(fax)
Carlisle, MA 01741 USA +1 703-620-4200(main office, Reston, VA)