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