[Mew-dist 08120] Re: B-encoded header routine

[Shun-ichi GOTO]

後藤＠太陽計測です

＃MewのMIME encoder/decoderにかかわる問題と言うことで続けてみます

問題の発生する具体例を挙げてください＞出沢さん
それらに対するMewやFLIMでのencode結果、decode結果ならすぐに
作成できますから。


>>>>> at Wed, 17 Mar 1999 01:22:11 +0900
>>>>> 出沢 <dezawa at example.com> said,
出沢> 余計なこだわりかも知れないのですが、
出沢>     encode されたものを decode したら全く同じに戻る

出沢> 様にしたいのです。

これはみな同じ考えのはずです。

出沢>                   もしそうでなくて構わないのなら、古い rfc のままで
出沢> 追加された \s+ が decode後もそのまま残ってしまって構わないのですから。

これは意味がわかりません。
古いRFCとはRFC822のことですか？
MIME(RFC-2045〜49)でいくつかの点で拡張されたとはいえ、RFC822は今も有効です。
folding/unfoldingに関しても。

foldingにふさわしくない場所でfoldingしてしまい、原文を復元できないような
エンコードは私も本意ではありません。


gotoh> unfold時のルールは以下のように記述されています

出沢> これは 822 ですから、MIME化前の話、というか、人が入力する時の 見たいな
出沢> 話ですよね。  この形で入力されているのなら、その改行は保存するだけの
出沢> 話なので、問題はないです。
出沢> 問題は、同じ行でこれに前後する部分が encodeの必要があり、その場合に 76Byte
出沢> overしてしまうとき。その時にどこに(decode時に削除されるべき)改行を追加出来
出沢> るのか、という問題です。

RFC822+RFC2047 に従うと、機械が改行を自動挿入して良いのは
原文にあるLWSP-charの部分およびエンコードが必要な文字列の途中、という
ことが導けると思います。

gotoh> X: 53_bytes_ASCII_string_with/without_white_space
gotoh>  =?iso-2022-jp?B?GyRCJCIbKEI=?=
gotoh> X: =?iso-2022-jp?B?GyRCJCIbKEI=?=
gotoh>  53_bytes_ASCII_string_with/without_white_space
gotoh> X: 23_bytes_ASCII_string =?iso-2022-jp?B?GyRCJCIbKEI=?=
gotoh>  30_bytes_ASCII_string_wi
gotoh> X: 20_bytes_ASCII =?iso-2022-jp?B?GyRCJCIbKEI=?= 10_bytes_ASCII
gotoh>  =?iso-2022-jp?B?GyRCJCIbKEI=?= 23_bytes_ASCII

出沢> これらの場合に追加された 改行は、「encode に挟まれた ^\s+$」ではないから
出沢> decode時に削除されずに残ってしまいます。

もともとの例で空白が入っていたのだからこれでよいはずですが、
それとももとの例が具体的な例ではなかったと言うことですか？

具体的な例をお願いします。

[原文]
Subject: RE:ごあいさつ
Subject: Re:aaa bbb cccccccccc漢字のencodeは 難しいなぁ。
Subject: Re: aaa-bbb-cccccccccc-dddddddddd-eeeeeeeeeeee漢字のencodeは 難しいなぁ。

[エンコード後]
Subject: =?iso-2022-jp?B?UkU6GyRCJDQkIiQkJDUkRBsoQg==?=
Subject: Re:aaa bbb
 =?iso-2022-jp?B?Y2NjY2NjY2NjYxskQjRBO3okThsoQmVuY28=?=
 =?iso-2022-jp?B?ZGUbJEIkTxsoQiAbJEJGcSQ3JCQkSiQhISMbKEI=?=
Subject: Re: =?us-ascii?Q?aaa-bbb-cccccccccc-dddddddddd-eeeeeeeee?=
 =?iso-2022-jp?B?ZWVlGyRCNEE7eiROGyhCZW5jb2RlGyRCJE8bKEI=?=
 =?iso-2022-jp?B?IBskQkZxJDckJCRKJCEhIxsoQg==?=

[デコード後]
Subject: RE:ごあいさつ
Subject: Re:aaa bbb cccccccccc漢字のencodeは 難しいなぁ。
Subject: Re: aaa-bbb-cccccccccc-dddddddddd-eeeeeeeeeeee漢字のencodeは 難しいなぁ。

みたいに

出沢> 76byte がMUSTなのかどうかですね。
出沢> Received: header なんて、平気で80Byteをoverしたりしてるのだから。
出沢> 全体を encode してしまうのが 76Byte ルールを含めた楽な解決策で
出沢> ある事が理解出来てきた。

Received:に関してはRFC822を参照してください。
また、Received:と同列に考えるのはやめましょうよ。


出沢>                         でも ML での れれれ 対策を考えると、、、、

MLでの問題は "Re: [ml:002] Re: [ml:001] RE:" などですかね。
1. (Re:の後ろに空白があり)エンコードしなくても良いはずの部分まで
   エンコードしてしまうMUA
2. MIMEヘッダ考慮の能力に欠けているくせにヘッダを加工してしまうMLプログラム

という問題ではないでしょうか。
加えて

3. 確実なエンコードアルゴリズムを提供していないRFC-2045〜49

というのもありますが。


"Re: RE:"の問題とかもあって "RE:" を "Re:"と同じに扱わないため削除しない
問題。これはMUAの問題ですよね？

どちらもMIMEのエンコード方法自体の問題ではないはずです。
実装者の妥協点が生んだ結果のように思います。

また、通常Re:の後ろには空白がつくので、"Re: "までエンコードしてしまう
ことはないはずです。というか、一緒にエンコードしなければならなくなるよ
うな制限はRFC2047にはないはずです。


gotoh> というわけで、出沢さんのルールでは linear-white-spaceの扱い方が間違っ
gotoh> ているように思うのですが。私が出沢さんのルールを理解し損ねているでしょ
gotoh> うか。。。問題点をちょっと理解し損ねているかも＞私

出沢> 次の節への私の答え/例 でもあるのですが、
出沢> 	encode して decode したら 同じになる。

出沢> ということへのこだわり、が問題意識の違いだと思います。

私も同じになるべきと考えておりますよ。


出沢> 元通りに復元出来ないなんて、encodeルールじゃあないよ、っていうのが
出沢> 私の問題意識です。

その具体例を示してください。


出沢> これへのもうひとつの例/答え は、
出沢>   同じルールに従ったencodeなのに、答えが一致しない。

出沢> だと思っています。  実装方針で変わってしまう。

原文とdeocdeした結果が一致すればなればよいのではないですか？


出沢> ＃ とりあえず、「境界条件では 76Byteルールは破る。出来るだけ短くはするが。」
出沢> ＃ で実装してみました。最大、Prefix SI １文字 SO postfix の 30Byte over
出沢> ＃  空encode をなくし、出来るだけ短く のためにえらく見通しが悪くなってしまった。
出沢> ＃ 76もこだわるなら、ASCII部分もencodeすることになるか、、、

ASCII部分もencodeすることにためらいをもつ理由がわかりません。

foldingのための元文字列のencode/non-encode判定による分割までの前処理、
長さをあわせるためのencode部の分割処理などを行なっている、
MewやFLIMでの実装を見てみるのはいかがでしょうか。

なんにせよ、具体的な例を挙げて欲しいです。

・どうしたらよいか迷う例
・encode & decodeで文字列が変化してしまう例
・理解できない例

など


--- Regards,
 Shun-ichi Goto  <gotoh at example.com>
   R&D Group, TAIYO Corp., Tokyo, JAPAN