RE: Line Wrapping Question

["Sukvinder Singh Gill (Exchange)" <[e-mail]>]

Our UAs support soft line breaks, so its to handle the
paragraph case.

-Suki


>----------
>From: 	Donald E. Eastlake 3rd[SMTP:[e-mail]]
>Sent: 	Wednesday, February 07, 1996 10:52 AM
>To: 	Sukvinder Singh Gill (Exchange)
>Cc: 	[e-mail]
>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) <[e-mail]>
>> To: "[e-mail]" <[e-mail]>
>> 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 - [e-mail]
>> Tel: [phone]
>
>Donald
>==========================================================
>===========
>Donald E. Eastlake 3rd     [phone](tel)    
>[e-mail]
>   318 Acton Street        [phone](fax)    
>[e-mail]
>Carlisle, MA 01741 USA     [phone](main office,
>Reston, VA)
>http://www.cybercash.com          
>http://www.eff.org/blueribbon.html
>
>