mew-dist 355 (古い…) から一部抜粋。
|仕様では通常、シンタックスとセマンティクスを定義します。
|
|RFC822 では、ヘッダのセマンティクスもボディのセマンティクスも ASCII と
|定めています。ASCII とは、0-127 の範囲を ASCII 表にある文字として解釈
|するというセマンティクスです。ただ、RFC822 の執筆当時 Dave が気が付い
|ていた犯しやすいシンタックス上の問題点(単一の CR など)は明確に排除しま
|した。
|
|日本で本文に ISO-2022-JP を入れたのは、シンタックス上は問題ありません
|が、セマンティクスを破っています。ASCII 文字列中に ESC シーケンスが現
|れても、それは単なる ESC シーケンスですから、日本語として取り扱われま
|せん。また、ヨーロッパでは、本文に 0-255 までを許し、これを Latin-1 と
|解釈することにしました。これはシンタックスもセマンティックスも破ってい
|ます。しかし、所詮、日本で ISO-2022-JP を利用しようとした背景は、ヨー
|ロッパが 8bit 領域を使っていたからにほかなりません。日本でも EUC Japan
|を標準に選ぶ可能性はあったということです。

シンタックスは「構文」、セマンティクスは「データの意味」のことらしい。へぇ〜。
Gartner Column：第11回 そもそも「セマンティクス」とは何だろう？ が参考になるかも。

追記(2009-04-05):
関連する話題があったので、貼り付けておきますね。

(URL: 日本語のe-mail、ISO-2022-JP以外のcharsetを使うのは是か非か - スラッシュドット・ジャパン )

個人的には ISO-2022-JP で表現できない内容なら、Unicode で送るのはまっ
たく問題ないと思います。ただ上の記事にあるように、本文に 8bit 目を
使うのはシンタックスを破ることになるので、base64 符号化は必須です。

Shift-JIS や EUC-JP を base64 符号化せずに送るのは 8bit 目を使って
いるので論外ですが、じゃあ Shift-JIS+base64 や EUC-JP+base64 なら良
いの？と言われるとこれも NO です。ISO-2022-JP で送れば素直なプレー
ンテキストになるのに、無駄な符号化をしているので。