Erik> In email, there are two basic requirements:
Erik> (1) transmissibility
Erik> (2) readability
Actually, the burden of (2) resides with the composer: this is what
the multipart/alternative content-type is for. Any multibyte text that
basically resembles ascii should probably have an alternative,
readable-by-7-bit-users representation included, at least until MIME
decoders proliferate.
That's an interesting suggestion, though I don't like to waste
bandwidth and people's money. Even your suggestion is qualified by
"at least until MIME decoders proliferate", so we're back to square
one.
Of course, I'm not saying that MIME decoders won't proliferate; I
certainly hope they do. I'm just a little worried about the interim
period, when not all people have the new stuff, and how painful that
period might be. Maybe I shouldn't worry...
This has the advantage of giving us readability and transmissibility
without revising the spec :)
Don't get me wrong -- I'm not suggesting that we revise the spec.
Basically, what I'm saying is that you can avoid the Q-P and Base64
problems by careful design of the "charset".
Example: raison d'_e^tre. The "_" character introduces a two-byte
representation that happens to resemble the intended character.
The Unicode "smiley" can be encoded as _:) which is similar to the
representation that you used above.
These ideas are not new. I'll shut up for now.
Cheers,
Erik