畑です。

Shinji KONO wrote:
>>えば、フランス人がフランス語でメールを書いて送ってくるようなケース）を考
>>えて、
>>Content-Type: text/plain; charset=UTF-8
>>Content-Transfer-Encoding: Base64

> 多言語が混在する状況でなければ、utf-8 である必然性はないです
> よね。charset で frech を指定しているんだったら7bit を使うで
> しょう。

多言語が混在する可能性も視野に入っているんです。例えば、そのフランス人が
日本に興味があって、こちらにフランス語と勉強中の日本語混じりでメールを
送ってくるようなケースも想定はしているので、UTF-8（UTF-16 でもいいかもし
れませんが）は外せないと思います。

> せめて、8bit で iso-8559-1 だと思うんだ。Quated-Pritable を
> 使うのも良く見ますけど無駄だと思う。7bit を維持する努力をし
> つつ、Base64を推進するより、7bit 経路をトンネルするlayer を
> 隠す方が良い。MTA が、こそこそ変換するってのも見たことあります。

Base64 に対するまずい理由というのはすごく納得できました。
僕はどちらかというと、Base64 よりも Quoted-Printable の暗号化アルゴリズ
ムを見て、「あくまでも 7bit が【常識】で 7bit から溢れた 128〜255 が【非
常識】だから、溢れた 8bit 目の領域の文字をエスケープする」という発想で、
強引な感じがしていました。Base64 の方は、バイナリデータの文字データ化と
いう感じで捉えていたので、あまり気になりませんでしたが。

ただ一つ気になるのが、Content-Type: 8bit のメッセージ本体しかもたない
メールデータを送信する場合、途中経路や、受信者のシステムが 7bit のシステ
ムの場合、該当する MTA で暗黙裏に Content-Type: Base64 に変換して対処し
てくれる（これが河野さんのおっしゃる「こそこそ変換」だと思いますが）こと
が（RFC 的に）保証されているのでしょうか？

まあでも、「7bit の旧式のメールシステムだから文字化けするんだ」みたいな
風潮にしてエンドユーザの利用実態からプレッシャーをかけて世間の 8bit 化を
促進した方がいいのかもしれませんね。

>>Base64 まずいですかね？

> まずい一つの理由は、
> 
>     Base64 の中に何が入っているかを各段階で(人やコンピュータが)チェックできない

この点について言えば、メッセージ本体だけじゃなくて、メールヘッダの B エ
ンコードなんかも好ましくないという話になるわけでしょうか？

>     ISO 7 layer とまでは言わないが、せめて、Transport層と、
>     Presentation 層を、ちゃんと分ける
（以下略）

確かに、言われてみれば、僕は MIME の意義を Transport 層的な情報内容の一
貫性保証の点でしか理解していませんでしたので、特に疑問を持たなかったわけ
なのですが、メールデータの Presentation 層的な役割について考えてみると、
おざなりもいいところですね。^^; 普段、Thunderbird のような比較的 MIME だ
とかの処理を意識しない形でメール（やニュース）システムを利用できるような
MUA を使っているので、気付きませんでした。

> まぁ、別に HATA さんに文句を言っているわけではないです。

はい、この点についてはご心配なく。:)

-- 
Masanori HATA