I know I shouldn't jump into this argument, but I can't resist the
opportunity.
I have no argument that QP is not a presentation encoding, it's a transfer
encoding. However, QP is specifically designed to support sending of long
lines. Most implementors of MIME readers have recognized this and made sure
that they wrap long lines when presenting them to the user (usually at the
window width at presentation time, not to some fixed width).
And when they do this often as not they turn legitimate material into garbage.
I receive legitimate material all the time as text/plain containing long lines
that absolutely cannot be wrapped. In fact I would say that this amounts to a
high percentage of the messages I receive.
I agree, text/plain is defined as "unformatted" text. But wrapping
unformatted
text is a very reasonable presentation thing to do (perhaps as a configurable
user option).
I disagree. It may or may not be reasonable, depending on what the original
message had in it. The problem is that if you wrap blindly you stand an
excellent chance of making legitimate content unusable.
From your rather vociferous reply, I take it your mail client or gateway
didn't
wrap text/plain by default. Given that, you've taken the world view that
"just
send QP" is a radical misunderstanding of the difference between transfer
encoding and presentation encoding. But most MIME implementors have found
that
sending QP results in decent interoperability of automatically wrapped text
and
therefore took that approach. They knew that any mail client that supported
MIME, supported QP, but couldn't guarantee that it would support
text/enriched.
So "just send QP" was a more conservative thing to do.
I'm not sure how you arrived at any of this. It is absolutely wrong in almost
every particular.
First of all, the client I happen to use most of the time wraps long lines just
fine if and when I want it to. I have no problem getting this effect when I
need it. However, I keep it turned off most of the time because most of the
messages I receive would be turned into trash by line wrapping. And again, this
message is a case in point, as are most of the messages I send and receive
every day.
Second, Innosoft is in the business of selling MTA/gateway functionality, not
email client software. We include some clients in our packages (including the
one I happen to use) but as I say there are no problems wrappping lines in any
of our clients if that's the effect users want. But this misses the point --
MTA/gateway functional is our focus and in general it is not the business of
either MTAs or gateways to change the presentation of the material passing
through it, so the wrapping problem is (or should be) a non-issue for us.
The problem is that there are vast number of clients, both MIME-capable and
non-MIME-capable, in widespread use that cannot do wrapping. These clients were
written with the expectation that plain text material they are given are
already in a format suitable for presentation. This is how RFC822 message text
is defined to work, and MIME's text/plain is simply a way of tacking a label on
what has been standard practice for over 13 years. To say that such clients are
broken and have to change is simply not acceptable -- we have rules about not
invalidating old practices.
These are the clients I have to support. They are fully standards-compliant,
and even if they weren't I doubt I could get a significant number of them to
change. As such, unless Microsoft and the others indulging in this practice
change their behavior the only solution I can implement is to perform line
wrapping on text/plain object in the context of an MTA. (This is not limited to
gateways.) This is at best a serious layering violation. At worst it ends up
trashing many messages, since there is in general no way I can tell the
difference between, say, a quoted section that cannot be wrapped and a section
that can.
Does all this lead me to say that Microsoft isn't playing by the rules? You bet
it does. But I'm not saying this because I have clients that lack
functionality. I don't, and even if I did it would not excuse Microsoft's
behavior. I say it because I believe that this practice is wrong. Period.
Ned