----------
From: Donald E. Eastlake 3rd[SMTP:dee(_at_)cybercash(_dot_)com]
Sent: Wednesday, February 07, 1996 10:52 AM
To: Sukvinder Singh Gill (Exchange)
Cc: ietf-822(_at_)list(_dot_)cren(_dot_)net
Subject: Re: Line Wrapping Question
Hi,
On Wed, 7 Feb 1996, Sukvinder Singh Gill (Exchange)
wrote:
Date: Wed, 7 Feb 1996 08:31:18 -0800
From: Sukvinder Singh Gill (Exchange)
<sukvg(_at_)wspu(_dot_)MICROSOFT(_dot_)com>
To: "ietf-822(_at_)list(_dot_)cren(_dot_)net"
<ietf-822(_at_)list(_dot_)cren(_dot_)net>
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
of perception.
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
at all.
i.e. CTE is 7-bit unless QP is required for some other
reason
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
objectionable...)
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
wrapping)
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.
Thanks,
-Suki
Sukvinder S. Gill
Microsoft Corporation
E-Mail - sukvg(_at_)microsoft(_dot_)com
Tel: 206-936-9761
Donald
==========================================================
===========
Donald E. Eastlake 3rd +1 508-287-4877(tel)
dee(_at_)cybercash(_dot_)com
318 Acton Street +1 508-371-7148(fax)
dee(_at_)world(_dot_)std(_dot_)com
Carlisle, MA 01741 USA +1 703-620-4200(main office,
Reston, VA)
http://www.cybercash.com
http://www.eff.org/blueribbon.html