At 11:31 AM 9/15/94, Keith Moore wrote:
- For a C-T: TEXT/PLAIN message in C-T-E: 8BIT form the defined
charset can be applied also for the headers UNLESS they use
RFC 1522 encoding to define othervice.
I don't think this is a good idea, because for those systems that do
strip bits, doing so might convert an 8bit alphabetic character into
a 7bit "special" character...thus fouling the parser. This would
certainly happen with news gatewayed to email.
The problem is, none of these things are really "good" ideas. I view this
topic as choosing the lesser of the bad ideas.
Encoding is good in that the encoded bytes are guaranteed to arrive at
their destination. It's bad in that the destination is, with a very high
probability not going to have a clue as to how to decode them. For those
of us conversing in the One True Language, that's usually no big deal;
however, them furriners really don't like it.
Sending 8 bits (labelled, of course) is good in that the unencoded bytes
have a good chance of being displayed properly. Sending 8 bits is bad, as
you say, because they may get munched in transit because of 8-bit hostile
TA's.
For mail, so darn much of the infrastructure is 8-bit hostile that it's
really not much of a contest. But *if* most NNTP xfers are 8-bit-ok, and
we only have to worry about news->mail gateways, it may be better to accept
that we break a few gateways, in order NOT to break the vast majority of
UA's.
Or, to put it another way, suppose we were worried about old CDC machines,
which had 6-bit characters. Would we automatically dismiss "just-send-7",
and encode everything everywhere in quoted-quoted-printable, or would we
put the honus on the CDC gateways to look out for themselves?
--
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