I think that the reason for the objections to quoted-printable is that it
tries to do too much.
Specifically, q-p tries to deal with the data munging problem as well as the
8-bit problem.
A correct q-p implementation will indeed deal with the data munging problem,
although you have to do extra things such as apply quoting to any line that
begins with ``From '' to work around the cretinism in Unix mbox format.
However, here are you are starting to see where q-p goes overboard.
Some editors by their nature leave trailing whitespace at the end of lines.
That comes out in q-p as lots of =20 sequences, none of which are of any
interest to either the sender or the recipient.
I am starting to think that what we need to do is define a new transfer
encoding that seeks only to get 8-bit characters through while keeping the
data readable, but does not attempt to deal with octet preservation the way
q-p does.
My proposal is for something like this:
Content-Transfer-Encoding 8IN7
The 8IN7 transfer encoding provides a way of indicating 8-bit
characters in a 7-bit stream in a readable fashion. It does
not attempt to preserve the precise octets of the original
stream; for this see the QUOTED-PRINTABLE and BASE64 encodings.
Two characters in 8IN7 encoding are special. The backslash (\)
character quotes the next character, which may be either another
backslash (\) or a tilde (~); no other character is valid. The
\\ sequence results in a single backslash, and the \~ sequence
results in a single tilde in the destination stream.
The tilde (~) character applies the high order (0x80) bit to the
next character. For example, the sequence ~A (0x7e 0x41)
results in a capital accented A (0xc1).