At 10:38 AM 12/2/94, ichikawa(_at_)nuee(_dot_)nagoya-u(_dot_)ac(_dot_)jp
(=?ISO-2022-JP?B?GyRAO1RAbiEhPH4wb wrote:
Assume a new newsreader/mailer, which is compliant to
draft-ietf-822ext-mime-imb-01.txt. It will interprete the
old ISO-2022-JP encoded plain massage without MIME headers
as US-ASCII plain text, and will display us a junk of string
of US-ASCII characters. No one will use such software (at
least in Japan). Therefore, I cannot adopt draft-ietf-
822ext-mime-imb-01.txt on this point anyway.
If this draft is intended to be accepted in many
countries on the earth, it is *NOT* adequate to assume the
old style message as US-ASCII plain text.
There is a misinterpretation of the MIME draft here. It is not MIME which
is making this specification, it is RFC 822. This is not a new restriction
introduced by MIME; it has been there all along. Nothing the new MIME spec
can say can change the fact that RFC 822 specifies ASCII. Since MIME is
constrained to be upwardly compatible with RFC 822, there is really no
choice in this matter.
Now, if you are saying that as a practical matter, in order to be
compatible with the installed base of software and users in Japan, you need
to make MUAs that violate this particular aspect of RFC 822 (and by
extension MIME), then that's the kind of tradeoff people building real
software make every day. You do have to keep the customers happy, after
all. Rather than claim that this software is not in violation of RFC 822,
however, I think a better strategy is to just admit it is, because it has
to be to be practical in Japan, and work towards making the software
compatible with Internet practice in the long run.
One possible strategy:
1. New MUAs should always mark messages with charset ISO-2022-JP (or
whatever your favorite charset is). Old MUAs will ignore this. I agree with
whoever said that if the message is pure ASCII it should be labelled as
such; that's already in the MIME spec. Older MUAs will ignore the charset
label, but if they're assuming ISO-2022 they'll work in either case.
2. If you get a message with no charset label, you have a choice: adhere to
RFC 822 and make your customers angry, always assume it's ISO-2022 and
degrade your interoperability with the Internet, or (I think the best
option) let your customers specify how they want such messages to be
treated. This last option lets you migrate people towards standards
compliance while allowing them to work as they always have.
Note that there is still no reason for an MUA which generates MIME headers
to omit a charset label on text that is not ASCII. You can support older,
non MIME aware MUAs, but new MIME aware MUAs should at least get it right.
People using their own local charset in e-mail without a label is just a
fact of life, but there is no point in denying it is in violation of RFC
822, and such practice cannot be the basis of any e-mail standard that is
supposed to work between countries.
----------------------------
David Goldsmith
david_goldsmith(_at_)taligent(_dot_)com
Senior Scientist
Taligent, Inc.
10201 N. DeAnza Blvd.
Cupertino, CA 95014-2233