[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
We are using ISO-2022-JP *NOW*!
Dear ietf-822 members,
Mr. Ohta <firstname.lastname@example.org> told us of this
ietf-draft, and I'm very surprised!
>> 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.
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!
We found nothing useful with charset. For example, we often
handle messages of plain text without help of MUA. Of course our
tools like less, grep, or Mule know nothing about MIME specification.
How do you tell them the MIME standard?
Or, if the charset is required, how do we choose value for
charset? If we found US-ASCII characters in the message, we will also
find ISO-8859-1, JIS X0208, or many other characters from many other
standard character sets.
Or, with or without the other information like MIME charset, our
internationalized (or localized) MUAs or the other tools have to scan
all of the received text when we want to find characters that can not
be handled correctly with the local system.
I'm designing a new MUA with internationalized features. If
the draft will become Internet standard, I have to ignore the
standard to keep interoperability with existing tools...