At 2:57 PM 9/12/94, Lennart Lovstrand wrote:
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 dislike multiple passes, and I distrust the assumption that all headers
can be buffered. However, if order-dependence were the only stumbling
block, I wouldn't insist on it.
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.
That's a good point. No charset currently allowed on non-text parts!
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 wasn't proposing honoring the CTE in headers; the desire is to avoid
encoding if possible. I had in mind that headers would be 8 bits in the
appropriate character set, wherever 1522 encoding is allowed.
Of course, 16 bit charsets would not live through that. They'd have to be
1522-encoded; but they're going to have to be encoded anyway.
In fact, I guess no charset except strict US-ASCII supersets (like
ISO-8859-1) would work right.
--
Steve Dorner, Qualcomm Incorporated
Whosoever has lived long enough to find out what life is, knows how deep a
debt of gratitude we owe to Adam. He brought death into this world.
Mark Twain