Re: Line Wrapping Question

"Donald E. Eastlake 3rd" <dee@cybercash.com> Wed, 07 February 1996 19:50 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa18657; 7 Feb 96 14:50 EST
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa18653; 7 Feb 96 14:50 EST
Received: from list.cren.net by CNRI.Reston.VA.US id aa11830; 7 Feb 96 14:50 EST
Received: from localhost (localhost [127.0.0.1]) by list.cren.net (8.6.12/8.6.12) with SMTP id NAA15068; Wed, 7 Feb 1996 13:56:31 -0500
Received: from callandor.cybercash.com (callandor.cybercash.com [204.178.186.70]) by list.cren.net (8.6.12/8.6.12) with ESMTP id NAA15050 for <ietf-822@list.cren.net>; Wed, 7 Feb 1996 13:56:15 -0500
Received: by callandor.cybercash.com; id OAA08791; Wed, 7 Feb 1996 14:01:08 -0500
Received: from cybercash.com(204.254.34.52) by callandor.cybercash.com via smap (g3.0.3) id xma008785; Wed, 7 Feb 96 14:00:51 -0500
Received: by cybercash.com.cybercash.com (4.1/SMI-4.1) id AA23878; Wed, 7 Feb 96 13:52:50 EST
Message-Id: <Pine.SUN.3.91.960207134108.22582D-100000@cybercash.com>
Date: Wed, 7 Feb 1996 13:52:49 -0500 (EST)
X-Orig-Sender: owner-ietf-822@list.cren.net
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: "Donald E. Eastlake 3rd" <dee@cybercash.com>
To: "Sukvinder Singh Gill (Exchange)" <sukvg@wspu.microsoft.com>
Cc: "ietf-822@list.cren.net" <ietf-822@list.cren.net>
Subject: Re: Line Wrapping Question
In-Reply-To: <c=US%a=_%p=Microsoft%l=DABONE960207083118QU005600@yuri.microsoft.com>
Mime-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-Listprocessor-Version: 8.0(beta) -- ListProcessor by CREN

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@wspu.MICROSOFT.com>
> To: "ietf-822@list.cren.net" <ietf-822@list.cren.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@microsoft.com
> Tel: 206-936-9761

Donald
=====================================================================
Donald E. Eastlake 3rd     +1 508-287-4877(tel)     dee@cybercash.com
   318 Acton Street        +1 508-371-7148(fax)     dee@world.std.com
Carlisle, MA 01741 USA     +1 703-620-4200(main office, Reston, VA)
http://www.cybercash.com           http://www.eff.org/blueribbon.html