The appearance of MIME

To satisfy users' desire such as transportation of picture and audio and to bridge localized RFC822, MIME was defined in 1992. With MIME, the character parameter can be specified. Since JUNET code is called ISO-2022-JP, Japanese message looks as follows:

Content-Type: Text/Plain; charset=iso-2022-jp
Content-Transfer-Encoding: 7bit

Japanese text.

Is this charset useful? Absolutely! The charset parameter can tell user interface an exact character set. Suppose that a Norway guy send a message with ISO-8859-1 to Japanese. If his interface supports ISO-8859-1 then it is no problem to display the body. Otherwise the interface can safely ignore the body. Mew makes use of the charset parameter to convert messages to Mule's internal representation.

Some people say like this; "If we use ISO-2022-JP-2 which is upper compatible to ISO-2022-JP and can handle numerous character set, the charset parameter is not necessary since ISO-2022-JP-2 itself contains information about character set." Maybe, just maybe, such people don't understand MIME.

Ideally speaking, this assessment is correct. But MIME takes a practical stance. MIME does not suppose that all people in the world will start using ISO-2022-JP-2 tomorrow. Moreover, MIME is designed to be robust against unstable transfer programs. All transfer program in the world are not well implemented. And all site cannot use rich resources. If you ask to use UNICODE as of today, how do you feel?

MIME provides the charset parameter to bridge between numerous localized regions. The additional procedure under MIME is to label the charset parameter and we can use ISO-2022-JP as we used to. If you wish to make ISO-2022-JP-2 an Internet standard, you should make an effort to spread region where ISO-2022-JP-2 is used by default. Likewise, ISO-2022-JP-2 and MIME is not inconsistent. Rather, ISO-2022-JP-2 can make most use of MIME to make itself widely spread. Of course, the name of "charset" is not proper for character switching mechanisms such as ISO-2022-xx.

With MIME, you can encode non-ASCII character set and insert it into header. This scheme prevents errors of Email transfer programs and makes it possible to convey non-ASCII strings in header. We don't have to say "Do not use Japanese on Subject:" anymore!

MIME is not a spec to prohibit localized RFC822. So, MIME interfaces are supposed to act as follows:

Viewing

1. Allow user to choose a default charset.
2. If MIME-Version: doesn't exist, the body is treated as the default charset.
3. If MIME-Version: exists and Content-Type: is not provided, the body is treated as US-ASCII.
4. If both MIME-Version: and Content-Type: exist, specified charset is used.

Composing

1. Specify MIME-Version:, Content-Type:, and its charset.
2. Choose minimum character set for charset. For instance, US-ASCII for English. If the rule is violated, it is likely that a message to be read cannot be read. For instance, consider a message labeled ISO-2022-JP whose body is US-ASCII in fact. Mailers which support US-ASCII only could not handle such a message.

If you store messages in a spool or folders after conversion from ISO-2022-JP to EUC-Japan, please don't be blind. You should check charset out, and convert only ISO-2022-JP messages to EUC-Japan.

Insertion of non-ASCII in header is one of MIME features but in fact MIME-Version: is not necessary.