That should not matter at all. Transfer encoding is completely orthogonal
to character sets.
I don't think so. Each charset has its own proper MIME encoding.
Well, all I can is that you're wrong. Both base64 and quoted-printable are
designed to be 100% invertible and loss-free. If you have a problem with
quoted-printable it is because of bugs in your MIME implementation.
Now, it is indeed true that one encoding can work better than another. For one
thing, quoted-printable can be a lot more efficient than base64 sometimes. And
in other cases it is far less efficient. There are also still cases, albeit
very rare ones now, where the transport infrastructure is weak and you'd be
well advised not to stress it with the character repetiore quoted-printable
employs. And there are instances of incomplete MIME support where one
decoder is available but not the other.
Before any 2022 interpretation is done all the QP
encoding will be removed. All it will see is "From ".
The difference between Base64 and QP is whether or not *partial*
encoding is possible. QP is possible and Base64 is not. If ISO 2022
text is encoded with QP partially(e.g. only spaces in ASCII part),
it is likely that encoded ISO 2022 cannot be decoded. This is real.
Experience says that QP is not suitable for ISO 2022 family.
I'm sorry, but I also have a fair amount of experience with using ISO-2022-JP
and ISO-2022-KR and have encountered no problems with using quoted-printable on
them that did not arise from broken MIME software. (In fact I cannot recall a
case where an ISO-2022-* charset was damaged by bad MIME software, but I have
seen instances of bad MIME software would damage most anything, ISO-2022-*
included. But if this is considered to be an issue, how about the one fairly
popular gateway that rejects 7bit as an "invalid encoding"?)
To my understanding, RFC 2045 says that values of MIME parameters are
case sensitive in general. And I cannot find any sentence to define
that the protocol parameter is case-insensitive in RFC 1847. If there
is one, please tell me what page in which RFC.
This, at least, is correct -- parameter values are to be considered to be case
sensitive unless noted otherwise. RFC1847 should have noted that the value of
the protocol parameter is case-insensitive. I've had this noted as something to
fix in the next revision of RFC1847 for quite some time now.
Ned