Ned,
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).
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'm sure if text/enriched had seemed like more of an integral part of the MIME
spec, and if there hadn't been confusion introduced by QP's handling of long
lines and text/enriched's handling of long lines, more implementors would have
decided that when deciding to send formatted text, to send QP-encoded
text/enriched rather than "just send QP". But that's not how it happened.
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.
Yes, you really need a presentation semantics to cleanly handle quoting of
wrapped text. But that's a distinct issue.
Terry