RE: Line Wrapping Question

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

Ned: 

Please  copy me on any issues you see with Microsoft's
support of MIME or any aspect of Internet Mail, and I will
make sure that these issues get handled correctly. I
apologize if you have been frustrated by many people
asking the same question on this topic.

I read your response to Terry's mail, about Microsoft not
playing by the rules, and was concerned that you feel that
there is something that Microsoft is doing knowingly to
not conform to the MIME specifications. This is absolutely
not the case.

Anyway rather than dwell on what's already been said and
done, I wanted to talk more about the issue I desperately
want to solve.

I see the distinction between CTE being for transport
rather than presentation purposes and I agree. 

Ned, I believe that your take on QP line wrapping is never
use the line wrapping for text/plain message bodies on
outbound messages, but do so for attachments right?

Therefore when a UA generates long lines with extended
characters in a message. Lets say the length of the line
is 87 characters, and you do not support text/enriched.
You should use option b) below.

a) Use QP and therefore wrap lines using the QP method

b) Use QP and hard wrap lines at <= 76 characters

The problem  with option a is that it could force the
unwrapping at the receiving end, and subsequently could
require re-wrapping for UAs not capable of presenting
lines longer than say 80 chars for sake of a better
example
The problem we originally saw with option b is that jagged
lines get presented to the recipient

For option b we also considered the following issue when
we did the QP style line wrapping - 

A UA generates a message, with extended characters, and
all lines were <= to 76 characters long, therefore the QP
encoding for long lines was not an issue. When the
recipient replies to the message, they prefixed a "> "
combination on the lines, therefore taking some of the
line lengths over 76 characters. Now the reply is sent
with a jagged line.

We are considering hard wrapping at <= 76 characters even
if QP is used for the moment, but really would like your
feedback on the right thing to do. i.e. is jagged lines
something you believe is acceptable in Internet Mail for
these cases? 

We are looking at using a lower limit for the wrapping
than 76, and using an upper threshold to decide when to
wrap. Have you used heard of people doing this, and what
upper threshold did they use. We would use the lower limit
to deal with cases where replies to mail originated in our
systems, could be replied to and we could respond back
without forcing jagged lines for those messages atleast,
but this reasoning is still being thought through.


RE: Text/Enriched (I am investigating what supporting that
means right now by the way, but I am concerned with the
interoperability cases since not every MIME aware
application may have implemented downgrading to text/plain
if they don't support text/enriched.)

Please take me up on my offer to be the liaison for
Internet Mail issues where you see Microsoft making
mistakes on, and I will ensure that these get the proper
attention. Lets communicate on these issues, that's the
only way that we can guarantee a greater level of
interoperability and hence customer satisfaction in
messaging products. (That's the right goal to have)

Thanks,
-Suki

Sukvinder S. Gill
Microsoft Corporation
E-mail - [e-mail]
Tel: [phone]




>----------
>From: 	Ned Freed[SMTP:[e-mail]]
>Sent: 	Wednesday, February 07, 1996 12:11 PM
>To: 	Sukvinder Singh Gill (Exchange)
>Cc: 	[e-mail]
>Subject: 	Re: Line Wrapping Question
>
>> I'd like to get some advice on a problem that many people
>> using our product have commented on.
>
>FYI, this is about the tenth time I've gone other this
>set of issues with
>either a Microsoft customer or someone from Microsoft. I
>hope this pass will be
>more effective than the previous ones have been.
>
>> 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)
>
>The problem in a nutshell is simple: You don't understand
>the intent
>and operation of MIME.
>
>More specifically, quoted-printable is *NOT* a
>presentation mechanism. It is a
>transport mechanism. As such, you must not assume that
>the line wrapping
>imposed by quoted-printable encoding takes care of your
>presentation problems
>in any way, shape, or form on the systems that receive
>your messages.
>
>There is confusion in this area because quoted-printable
>is actually designed
>to be a kind of half-assed presentation mechanism for
>non-MIME-capable readers.
>But this *ONLY* applies to non-MIME readers. MIME-capable
>readers remove the
>presentation aspects of quoted-prinable before displaying
>the result.
>
>This means that the material inside of the
>quoted-printable encoding has to be
>in a form that is suitable for presentation. Nothing more
>and nothing less.
>
>Text/plain material is material formatted for direct
>presentation to the user.
>It isn't supposed to be line-wrapped by the user agent.
>Indeed, if it is
>wrapped willy-nilly many common usage elements of
>text/plain will be lost. This
>message is a case in point: I have used, as is my custom,
>a "> " quoting
>convention to mark passages from your original message.
>Line wrap this message
>and this effect will be trashed.
>
>> 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.
>
>The only assumption people are making is that your intent
>is that your messages
>will be presented in a reasonable way by MIME-compliant
>agents And since they
>aren't, it's therefore a bug in your implementation.
>
>You are operating under the belief that text/plain
>material under the
>quoted-printable encoding will be line-wrapped on
>presentation. And this is not
>the case. It is not supposed to be line-wrapped by
>receiving agents. If you
>want your text to be line-wrapped, either use
>text/enriched or define a new
>subtype of text for this purpose.
>
>> 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.
>
>You're now trying to solve the problem in the one case
>where it doesn't exist.
>A non-MIME reader is the only one that will see this
>prologue. But it is also
>the only one that necessarily will see a the line-wrapped
>quoted-printable!
>
>In other words, you have provided the information in a
>way that guarantees that
>the people who need it won't see it, and the people who
>will see it won't need
>it.
>
>> 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)
>
>Of course they did -- they didn't need the prologue since
>it doesn't help then
>in any way. And the ones who might be helped by the
>prologue never see it.
>
>> 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
>
>Like it or not, this is an option you are going to have
>to provide.
>
>> 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)
>
>This is just a variant of the first approach, i.e. make
>it non-optional.
>I don't really count it as a separate approach to the
>problem.
>
>> c) We leave things the way they are.
>
>This will lead to other implementors having to provide
>facilities to
>line-wrap text/plain material. We'll have to work around
>your
>bug, in other words. 
>
>In fact I already see this as a foregone conclusion --
>we've already set up
>workarounds for this Microsoft problem at a number of
>sites.
>
>> d) We don't send the prologue, and hope that the world
>> will move to MIME, and this becomes a non-issue.
>
>The fact that you say this demonstrates that you do not
>have a clear
>understanding of the problem.
>
>The world moving to MIME makes this much worse, not
>better. People without MIME
>readers are inconvenienced by the tacky appearance of the
>quoted-printable
>encoding, but aside from that they have nothing to
>complain about. It's people
>who *HAVE* *STANDARDS-COMPLIANT* *MIME* *IMPLEMENTATIONS*
>that bear the brunt
>of your current practices. They are the ones who often as
>not have to manually
>wrap lines in replies to messages you send.
>
>There are also some options you have not considered:
>
>(e) Use text/enriched. The characteristics of this type
>are such that you
>        could build material that looks decent on MIME
>readers and non-MIME
>    readers at the same time.
>
>(f) Define a new subtype of text that specifically allows
>for
>
>> 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.
>
>I would recommend a combination of (a) and (e). Provide
>an option to present
>text material in an unencoded form that looks reasonable
>when it is displayed.
>And also provide an option to present text material in a
>more sophisticated
>form. Neither of these necessarily should be encoded by
>default. The latter
>form must be carefullly implemented so that it looks
>decent on non-MIME readers
>but provides whatever presentation elements that lie in
>the intersection of
>text/enriched and your internal format.
>
>				Ned
>