RE: Line Wrapping Question

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 - sukvg(_at_)microsoft(_dot_)com
Tel: 206-936-9761

----------
From:  Ned Freed[SMTP:NED(_at_)innosoft(_dot_)com]
Sent:  Wednesday, February 07, 1996 12:11 PM
To:    Sukvinder Singh Gill (Exchange)
Cc:    ietf-822(_at_)list(_dot_)cren(_dot_)net
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