Masatka Ohta writes:
So, the current MIME specification for non-Mime mail that says:
Default RFC 822 messages are typed by this protocol as plain
text in the US-ASCII character set, which can be explicitly
specified as "Content-type: text/plain; charset=us-ascii".
should be removed, because, for you, it is specification on non-MIME
mails and, for me, it is obstacle to the Internationalized Internet.
I think this shows a fundamental misunderstanding.
Fundamental misunderstanding of you.
That paragraph
simply RESTATES, in terms of the MIME content-type, the definition that
was already made in RFC 822.
Read RFC 822 again. We have designed ISO-2022-JP, which is NOT US-ASCII,
10 years ago with full understanding on RFC 822.
RFC 822 makes it very clear that messages
are 7-bit ASCII.
It seems to me that you don't understand what ASCII is.
RFC 822 makes it very clear that messages are 7-bit NET-ASCII. That
is, anything between 0 and 127.
All that this paragraph does is to explain how that
pre-existent reality is expressed in MIME terms.
Yes, ISO-2022-JP is the RFC 822 conformant pre-existent reality.
The fact that various local communities sent things other than ASCII
around in pre-MIME mail is important,
That's the reality.
but not relevant to the
standardization issue:
Not to the MIME standardization issue, agreed. So, remove overwordings
of MIME.
Those uses were clearly out of spec with regard
to RFC 822,
You need some real world experience to use non-ASCII environment
daily.
People have been doing localizaion within the spec of RFC 822.
and were an important reason why MIME was designed in the
first place! -- Nathaniel
And failed.
Let MIME go its own way within, but absolutely not outside of,
the MIME specification.
Internationalization of truly multi-lingual encoding is outside
the scope of MIME.
Masataka Ohta