Without character set information, such 8-bit information is useless.
Most enclaves assume a single 8-bit character set, this does not scale
to a global communication system.
Agreed. But perhaps 8-bit characters could be legal in News headers
*after* a charset parameter appears? I know that one cannot depend on
header order being preserved in mail, but maybe News is (or could be)
different?
Steve,
Maybe I'm missing something, but I don't see why a forward declaration would
be necessary. Just read (all) the headers, look for the key with the charset
carrying information and then proceed with any required charset conversions
on their values. I am presuming that charset header will itself be only 7
bit ASCII, but that seems to be a given.
On the other hand, I am a bit worried that MIME's Content-Type and
Content-Transfer-Encoding might not be "good enough" to carry this
information since they apply only to the body of the message, not the
headers. For example, I might want to send an image base64-encoded (since it
contains non-textual information), yet use 8 bit text in the headers. It
doesn't seem to make sense to me to have a charset parameter in an image
Content-Type. And what about the Content-Transfer-Encoding? It can't be
base64 and 8bit at the same time.
I wonder if it wouldn't be better to have a "default" charset header that
establishes the default character set for the complete message. A missing
charset header would imply 7 bit US-ASCII while one with, say, ISO-8859-1
would automatically dictate an 8 bit message. Any specific charset parameter
in a MIME Content-Type would still be valid, of course, as would any 7 bit
encoding. The only other MIME-centric solution I can think of would be to
extend the Content- headers to apply to the headers and to expressly forbid
8 bit headers with any other Content-Type than text. It's certainly
feasible, but it seems a bit unnecessarily complicated and restrictive.
Lennart Lovstrand
NeXT Software Engineering