Dear members of ietf-822,
I've got two replies so far. I'd like to state my objection for those
responses here.
You have been misled.
The intent of the text in RFC 822 is clear, and confirmed
by the author, to mean US ASCII, not "anything that will fit
in 7 bits".
Since RFC-822 is a standard, not a someone's memorandum, I think
confirmation by some other one is not needed even by the author. We
cannot implement a system if we need confirmation by the author for
each standard.
RFC-822 is ambiguous about the difference between characters and
codes. It has been led two different interpretations. For those who
have been used only ASCII characters, the difference is not crucial.
But for those people who uses more than one character set for usual
communication, this is very much important.
RFC-822 says as follows,
CHAR = <any ASCII character> ; ( 0-177, 0.-127.)
Since RFC-822 uses only the term ASCII but says nothing about
character sets and its encoding scheme, we have been interpreted the
above definition like,
1. <any ASCII character> means codepoints 0/0-7/15(0.-127.).
2. RFC-822 itself does not define character encoding scheme.
So, in Japan, we adopted ISO 2022 based character encoding scheme
which is now called ISO-2022-JP.
This encoding is carefully considered so that upper compatibility with
existing system is perfect. Also, since this scheme is based on ISO
2022, multilingual extension of the scheme is straightforward. Using
ISO-2022-JP-2, we can mixture English, Japanese, European languages,
Greek, Chinese, Korean as much as we like.
Proposing an extension is a Good Thing, but to claim that
So, please understand that this is *NOT* a proposal of an extension,
but an interpretation caused by the ambiguity of RFC-822.
In Japan, there are a lot of existing systems implemented based on the
interpretation so that we cannot change all of them now.
Dave Crocker did not mean what he wrote is a Bad Thing.
Please help the community calm down this flamewar that
The Internet is an international network. If there is a different
interpretation of a protocol, we should think of existing systems
which are based on the interpretation and carefully consider about
standardization.
What we need is *JUST REMAIN* this ambiguity, or think of a scheme
which is compatible with existing systems.
Best regards,
Yoshio Kuniyoshi
================================================================
Yoshio KUNIYOSHI
Faculty of Science and Technology, Keio University, Yokohama, Japan.
E-mail: yoshio(_at_)nak(_dot_)math(_dot_)keio(_dot_)ac(_dot_)jp
Tel: +81-45-563-1151 ext.3765(dial in)
================================================================