Dear ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu members:
My name is Shuichi Ichikawa. I have been maintained some
patches to make TIN (newsreader) and MUSH (mailer) fit to
Japanese environment (ISO-2022-JP). I would like to make a
comment on "draft-ietf-822-ext-mime-imb-01.txt" here, from
the standpoint of Japanese newsreader/mailer implementer.
Page 20 of draft-ietf-822ext-mime-imb-01.txt:
Default RFC 822 messages without a MIME Content-Type header
are taken by this protocol to be plain text in the US-ASCII
character set, which can be explicitly specified as:
Content-type: text/plain; charset=us-ascii
This default is assumed if no Content-Type is specified. In
the presence of a MIME-Version header field, a receiving User
Agent can also assume that plain US-ASCII text was the
sender's intent. Plain US-ASCII text must still be assumed in
the absence of a MIME-Version specification, but the sender's
intent might have been otherwise.
We have been using rfc822 style messages with
ISO-2022-JP encoding for years, as a default in Japan. Most
of them do *NOT* have any MIME headers.
too(_at_)mm(_dot_)t(_dot_)u-tokyo(_dot_)ac(_dot_)jp (OKADA Takashi) wrote:
For many years, we are using localized(Japanese) versions of MUA,
and they assume plain text messages are in the ISO-2022-JP encoding.
If we assume plain text messages are in US-ASCII, we lose the inter-
operability with many existing MUA. We have many colleages that know
NOTHING about the MIME standard, and we can't force all of them to
give up their MUAs. They are posting many messages for us WITHOUT
Content-Type: or even WITHOUT MIME-Version:, NOW!
I completely agree with Okada's comment. We *CAN* make
new newsreaders and mailers which add MIME headers (it's
easy!). But we can *NEVER* ignore the existing messages
generated by old softwares.
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.
The draft follows:
RATIONALE: In the absence of any Content-Type header field or
MIME-Version header field, it is impossible to be certain that
a message is actually text in the US-ASCII character set,
since it might well be a message that, using some set of
nonstandard conventions that predate this document, includes
text in another character set or non-textual data in a manner
that cannot be automatically recognized (e.g., a uuencoded
compressed UNIX tar file). Although there is no fully
acceptable alternative to treating such untyped messages as
"text/plain; charset=us-ascii", implementors should remain
aware that if a message lacks both the MIME-Version and the
Content-Type header fields, it may in practice contain almost
anything.
It *MAY* be adequate to treat untyped massages as
US-ASCII plain text in *the United States*. But it is *NOT*
always true in some other countries. The standard which is
intended to be international should not include such local
assumptions.
P.S. I date put my signature in ISO-2022-JP style, as an
example of ISO-2022-JP plain text.
--
市\xA8焉扤扤 周一 (Shuichi ICHIKAWA)
<ichikawa(_at_)nuee(_dot_)nagoya-u(_dot_)ac(_dot_)jp>