On Mon, 14 Oct 1991 12:54:45 MET, Johnny Eriksson wrote:
No, we can't. Mark Crispin has decided, in his infinite wisdom, that
a content-type "message" can't have a transport encoding, and therefore
it can only contain characters that can be represented in seven bits.
There is a reason why I -- and several others -- pushed so hard to make sure
that transport encodings not apply to content types `message' or `multipart'.
It has nothing to do with discriminating against Europeans (or should I say
Scandanavians? A lobby representing at most 20 million people are dictating
that their solutions be adopted to apply to hundreds of millions of people).
Applying a transport encoding or a character set to envelope information
creates a technically infeasible protocol.
You cannot assume that all character sets will have the same values for Roman
characters. EBCDIC, GB, and JIS are examples which immediately come to mind.
It's an amazing can of worms that cannot be lightly dismissed.
You have already made the leap in realization that defining an 8-bit transport
is neither sufficient nor necessary to transport ISO-8859-2.
Now take the next leap, which is the realization that you do not want to use
anything other than ASCII for envelope (header) information since this
information must be interchanged globally. Therefore, you must encode any
non-ASCII textual information that may appear in the header in an ASCII-safe
manner.
Then, you need one more leap of realization. You have a 7-bit ASCII safe
path. The last hurdle is to be RFC-822 safe. You can't use characters that
may be interpreted by a reasonable RFC-822 parser as something else. You have
to assume that RFC-822 quoting isn't good enough; too many UA's take shortcuts
in their parses, including the commonly-used Unix tool /usr/ucb/Mail.
Various proposals have been floated about to have subjects, personal name
phrases, and comments be in a base64, quoted-printable, quoted-readable, or
mnemonic form. None of these proposals require any changes to the current
RFC-XXXX draft. All of these proposals require further maturity to get
something that we can be happy with.
The only quick & dirty thing that can get into RFC-XXXX right now is something
really horrible. Such as:
Personal names, comments, and subjects are redefined
to use `international equivalents' for texts and phrases.
An international equivalent is either US-ASCII if it begins
with anything other than a + character. If it begins with a
+ character followed by a character set name, a space, and a
base64 string.
This would solve your problem. It is also hideous. I can not believe you
could accept such a proposal. But it is much less hideous than the prospect
of having to decode encapsulated messages before they can be parsed. It is
quick and dirty. It could go into RFC-XXXX *now* as you demand.
I hope you'll have enough sense to realize that is not what you want.