A couple points:
1. Yes, QP is simply an encoding mechanism.
2. Yes, it shouldn't be used as a presentation mechanism (e.g assuming long
lines wrap).
But, THIS WAS NOT CLEAR. It really wasn't. Trust me.
The whole discussion of QP in the MIME spec discusses "hard" and "soft"
carriage returns, and the examples show lines that are wrapped by QP, being
rewrapped when decoded (partially an unfortunate consequence of the ASCII only
presentation medium). The discussion doesn't center on long lined data that
needs to get through wrapping transports/gateways. It talks about hard and
soft CR's, a word-processing notion.
Ned, step back for a moment and recognize that your world view is not everyone
elses. For example, you talk about "wrapping blindly". But if I'm presenting
the text in a windowed screen, I can "wrap blindly" and allow the user to
resize the window if they don't like the way it wrapped at that size. You're
writing gateways, so you're forced to make a hard and fast decision that isn't
revokable. In your case, wrapping would be wrapping blindly. In my case it's
not.
But this is history. The bottom line is, there are still MIME capable
mailers/gateways that do things in incompatible ways because of confusion in
reading/interpreting/using the MIME spec. The programmers that are reading
that spec are not stupid. It just wasn't clear.
Here's a clear statement:
1. For maximum interoperability of text composed by the user in an
automatically wrapping text editor, send text/plain with short, hard-wrapped
lines. Wrap at something less that 80 characters (72 or 76 are good choices)
to allow for quoting on reply. If possible, send as 7-bit. If your data
contains 8-bit characters, you'll probably have to provide a user option about
whether they want to encode as QP in this case or "just send 8-bit".
2. If you want to send automatically wrapped text, use text/enriched, encoded
using QP.
If you're a vendor of MIME-capable software, support for text/enriched is a
must.
Terry