What I think I'm looking for is a case for omitting the CHARSET
parameter for text/plain unless you encode it as Base 64. With B64,
the "channel" is binary so coding a CHARSET= parm (and here I mean
like US-ASCII or ISO-8859-1 rather than Latin-1 or some such) is safe.
Without any particular encoding, the "channel" is "plain text" and
I can only hope that the gateway got it right. Q-P further aggravates
any error introduced by a gateway.
I think there exists, but am having trouble developing or
proving, a case for trusting and using "plain text" apart from
specific character set (encoding) tagging. And it's not just for
EBCDIC hosts, but for those yet-to-be-created machines with a
smallest addressability of a 32-bit word. (ie: the 32-bit byte)
If you want to tag something as text/plain and ISO-8859-1,
fine. But ensure that the channel is truly binary. Then again,
don't do B64 unless you have to for the sake of those who aren't yet
running a MIME compliant MUA.
And this is assuming that "network plaintext" (what passes
over an SMTP connection) is already ISO-8859-1. (except that it isn't,
it's really 7-bit; but you get the idea)
Rick Troth <troth(_at_)rice(_dot_)edu>, Rice University, Information Systems