$B!V(BRe: Re: Re:$B!WLdBj(B (Re: $B#N%9$Z$r%@%S%s%0$5$;$F2<$5$$(B)
to...@lbm.go.jp
「Re: Re: Re:」の問題について
＃ Followup-To: fj.net.mime とします。
In article <8mp6r4$5f0$1...@neelix.mmtr.or.jp> ni...@gld.mmtr.or.jp writes:
>>># なんだか河野氏は「Re: 」を増やすのが趣味みたいだなぁ。
>>># 削っておこう。
>>Re: が増えるのは、Re:を含めてMIMEエンコードしているやつの方
>>に責任があるんだよ.... いったい何使ってるんだろう...
>私じゃないよ。増やしてるのは。
>増えてるのは河野氏の記事からだよねぇ… このスレッドでは。
新美さんの環境から見れば
河野さんの記事で増えてるように見えると思いますが、
増える原因は、その直前の新美さんの記事にあるんですよ。
例えば、上に引用したやりとりの直接の契機になった記事の
Subjectは以下のようになっています。
河野さん
Message-ID: <10646.9...@rananim.ie.u-ryukyu.ac.jp>
Date: 6 Aug 2000 01:27:01 GMT
Subject: Re: Ｎスぺをダビングさせて下さい
新美さん
Message-ID: <8mk10c$81q$1...@neelix.mmtr.or.jp>
Date: Mon, 7 Aug 2000 00:10:18 +0900
Subject: =?iso-2022-jp?B?UmU6IBskQiNOJTkkWiRyJUAlUyVzJTAkNSQ7JEYyPCQ1JCQbKEI=?=
河野さん
Message-ID: <11742.9...@rananim.ie.u-ryukyu.ac.jp>
Date: 6 Aug 2000 19:01:03 GMT
Subject: Re: Re: Ｎスぺをダビングさせて下さい
新美さん
Message-ID: <8ml7v3$mkd$2...@neelix.mmtr.or.jp>
Date: Mon, 7 Aug 2000 11:30:01 +0900
Subject: =?iso-2022-jp?B?UmU6IFJlOiAbJEIjTiU5JFokciVAJVMlcyUwJDUkOyRGMjwkNSQkGyhC?=
河野さんは、いわゆる「生JIS」ですね。
「Subject: 」の後にいきなり「Re: 」が来て、
その後に「ESC $ B」で始まるISO-2022-JP文字列がそのまま入っています。
一方の新美さんは、いわゆる「MIME-Bエンコード」なんですが、
「Subject: 」の後にいきなり「=?iso-2022-jp?」で始まる
MIMEエンコードされた文字列が入っています。
つまり、インターネットを記事が流れている状態では
「Subject: 」の直後に「Re:」は存在せず、
MIMEデコードして初めて「Re:」という文字列が見えるのです。
さて、河野さんの環境は、ユーザが記事にフォローする意思を示した時に、
(1)元の記事のSubject（MIMEデコードも何もしない状態の元の文字列）の
冒頭が「Re:」であるかどうかを判断し、違う場合は
元の記事のSubjectの冒頭に「Re: 」を付加したものをSubjectとする
「記事の叩き台」を準備し、編集環境に引き渡す。
(2)編集環境は、SubjectにMIMEエンコードされた文字列があれば
デコードして、ユーザに編集させる。
(3)編集の終了した記事は（ISO-2022-JPでなければISO-2022-JPに変換して）
そのままMIMEエンコードせずに投稿される。
という動作をするようになっているものと推測されます。
しかるに、新美さんの記事のSubjectの冒頭は
“MIMEデコードして「Re:」になる文字列”ではあっても
「Re:」そのものではありませんから、
河野さんの環境では「Re:」で始まっていないSubjectであると判断して
「Re: 」を付加します。その後でMIMEデコードされるので、
Subject: Re: Re: Ｎスぺをダビングさせて下さい
になるわけです。河野さんが編集段階でこれに気付いて
「Re:」１個を手動で除去すれば良いのですが、
論争が進んでいる最中に逐一注意せよという方が無理です。
で、そのまま記事が出て行ってしまうというわけです。
これに対策するには、
(a)MIMEエンコードする際に冒頭の「Re:」をエンコードしない。
つまり、本件の場合は
Subject: Re: =?ISO-2022-JP?B?GyRCI04lOSRaJHIlQCVTJXMlMCQ1JDskRjI8JDUkJBsoQg==?=
という要領でエンコードする。
(b)フォローする側が、「Re:」の存在を判断する前にMIMEデコードする。
の何れか片方が励行されれば良いわけですが、
これまでの議論では(a)の方法で対策するべきであるというのが
大勢だったと思います。それは、特にfj.*においては
MIME環境に対応することを参加者に強制するべきでない
と考えるのが大勢であるからです。その背景には
そもそもMIMEエンコード自体が
合意手続き抜きで「なし崩し」的に導入された
という経緯もあります。それゆえに、
MIMEエンコードに伴って発生する問題には
MIMEエンコードする側が対処するべきである
という基本姿勢になるわけです。
MIMEエンコードされたSubjectは未対応環境では読めませんが、
本文が読めれば議論に参加するに何の支障もありませんから、
それゆえに容認されているというのが実態です。
それに、新美さんの環境が行っているMIMEエンコードは、
それ自体がRFC違反だという説を唱える人も居るようです。
（RFCはSubjectが「Re:」そのもので始まっていることを要請しており、
“MIMEデコードして「Re:」になる文字列”では要請を満たさないと読解する）
というわけで、この問題に関しては、
新美さんの方が分が悪いんですよ。
戸田 孝＠滋賀県立琵琶湖博物館
to...@lbm.go.jp
Koichi Nakatani
戸田さん>
> それに、新美さんの環境が行っているMIMEエンコードは、
> それ自体がRFC違反だという説を唱える人も居るようです。
> （RFCはSubjectが「Re:」そのもので始まっていることを要請しており、
> “MIMEデコードして「Re:」になる文字列”では要請を満たさないと読解する）
すみません。ここでいう「RFC」とは何番のことでしょうか?
というのも、ここでいう「要請」は MIME の考え方とは噛み合わないと
思いますが、もしも STANDARD TRACK 以外の RFC にそのような記述が
あったとしても、必ずしも改訂されるとは限らないからです。
Shinji KONO
In article <39940C29...@pop02.odn.ne.jp> ,
Koichi Nakatani <k...@pop02.odn.ne.jp> writes
>というのも、ここでいう「要請」は MIME の考え方とは噛み合わないと
>思いますが、もしも STANDARD TRACK 以外の RFC にそのような記述が
>あったとしても、必ずしも改訂されるとは限らないからです。
「MIMEの考え方」ってのが、サブジェクトやファイル名の指定に関
することならば、一言で言えば「狂ってる」ってことだと僕は思い
ます。Envelope のフォーマットだと思うと割りと使えるんだけど...
で、どこが狂っているかと言うと、
配送途中ではMIMEデコードしてはいけない部分
MIMEデコードしないと処理できない部分
この二つの部分が重なっているからです。今の場合は、
Re: の処理は、ニュースリーダが行なうべきなのだが、
MIME エンコードするとそれができなくなってしまう
ですよね。新美さんのOutlook に関して言えば、
Subject のMIMEエンコードは最小限にとどめる
ってのがあるから Re: を含めてエンコードしているのもいけないんだよね。
なんだけど、
MIMEエンコードを続けると間の空白の情報が失われる
ってのがあるので、全体をエンコードしたい気持も理解できます。
普通は、Re: をエンコードしないだけで、かなり幸せになれるのだが...
>> （RFCはSubjectが「Re:」そのもので始まっていることを要請しており、
>> “MIMEデコードして「Re:」になる文字列”では要請を満たさないと読解する）
>すみません。ここでいう「RFC」とは何番のことでしょうか?
この議論は前にもあって、その時は、ネットニュースのが引用され
ていたような気がする。
ちなみに僕は、MHから投稿しているので、かなり特殊なほうかもね。
---
Shinji KONO @ Information Engineering, University of the Ryukyus
河野真治 @ 琉球大学工学部情報工学科
Koichi Nakatani
河野さん>
> で、どこが狂っているかと言うと、
>
> 配送途中ではMIMEデコードしてはいけない部分
> MIMEデコードしないと処理できない部分
>
> この二つの部分が重なっているからです。今の場合は、
>
> Re: の処理は、ニュースリーダが行なうべきなのだが、
> MIME エンコードするとそれができなくなってしまう
>
> ですよね。新美さんのOutlook に関して言えば、
>
> Subject のMIMEエンコードは最小限にとどめる
>
> ってのがあるから Re: を含めてエンコードしているのもいけないんだよね。
うむむむむ。
「Re: の処理はニュースリーダが行なうべきである。」
「Subject のMIMEエンコードは最小限にとどめる(べきである)。」
というのは、しっかり決められたことではないように思いますが。
恣意的なルールを持ち出しさえすれば、どちらが悪い、ということは
割と簡単に言えてしまうんだと思います。
> 普通は、Re: をエンコードしないだけで、かなり幸せになれるのだが...
「普通」という言葉は、河野さんが
<13365.9...@rananim.ie.u-ryukyu.ac.jp>
で言及しているところの「法律の解釈」「常識」と同類で、
人それぞれさまざまに異なるモノを指しているんじゃないでしょうか。
Shinji KONO
followup 時に生JISに変換してしまうのは簡単なんだけど... なん
か理由があって、MIMEはそのまま投稿するようにしたんだよな...
本当は、このサブジェクトは、74文字かなんかで改行を入れないと
いけいないはず...
In article <399423DF...@pop02.odn.ne.jp> ,
Koichi Nakatani <k...@pop02.odn.ne.jp> writes
>「Re: の処理はニュースリーダが行なうべきである。」
>「Subject のMIMEエンコードは最小限にとどめる(べきである)。」
>というのは、しっかり決められたことではないように思いますが。
どっちもどこかで見た気がする。でも、このあたりは、スタンダー
ドの扱い方にもよると思う。決められてないから守らないってわけ
でもないのでしょう? Re: を含めてエンコードしたときに増殖する
ような実装は結構多かったみたいだし...
中谷さんとの議論も長いけど、中谷さんの完璧なサンプル実装があ
るなら、trn / MH の中で、それを使いたいです。
>「普通」という言葉は、河野さんが
><13365.9...@rananim.ie.u-ryukyu.ac.jp>
>で言及しているところの「法律の解釈」「常識」と同類で、
>人それぞれさまざまに異なるモノを指しているんじゃないでしょうか。
そういう意味で使ってるんでしょうね。
Koichi Nakatani
河野さん>
> followup 時に生JISに変換してしまうのは簡単なんだけど... なん
> か理由があって、MIMEはそのまま投稿するようにしたんだよな...
> 本当は、このサブジェクトは、74文字かなんかで改行を入れないと
> いけいないはず...
河野さんの記事は、いわゆる「生JIS」になっていると思いますよ。
MIME encoded-word を含むサブジェクトを受け取る。
↓
そのまま Re: を付ける処理をする。
↓
encoded-word から生JIS に変換する。
という手順になっているようです。
ところで私が使っているニュースリーダでは、記事の一覧表示のときに
サブジェクト冒頭の重複する「Re: 」をひとつしかないかのように
扱っているようです。これは、十分な根拠を伴わない責任のなすり合いに
比べればスマートな解決法ではないかと思います。
> 中谷さんとの議論も長いけど、中谷さんの完璧なサンプル実装があ
> るなら、trn / MH の中で、それを使いたいです。
今のところ、 MIME encoded-word についての「完璧な」実装というのは
どこにもないんじゃないかと思います。もしも作るとすれば、いちど
全部 UTF-8 にしてから加工して、最後に encoded-word に戻すなどの
方法が必要になると思います。(IMAP の話に似てきてしまいました。)
Kouichi Niimi
<to...@lbm.go.jp> wrote in message news:8n0qo2$3...@nws-7000.lbm.go.jp...
> というわけで、この問題に関しては、
> 新美さんの方が分が悪いんですよ。
この件了解です。
でも修正できないんだよね、Outlook Expressって。^^;
う～ん……
--
新美 浩一＠知多半島の住人
ni...@gld.mmtr.or.jp
Takahiro Kambe
ko...@ie.u-ryukyu.ac.jp (Shinji KONO) writes:
> 「MIMEの考え方」ってのが、サブジェクトやファイル名の指定に関
> することならば、一言で言えば「狂ってる」ってことだと僕は思い
ろからの制約は大きかったと思います。
> ます。Envelope のフォーマットだと思うと割りと使えるんだけど...
ここで、なんでエンベロープが出てくるんでしょうか。河野さんの言われて
いるエンベロープって何ですか?
> で、どこが狂っているかと言うと、
>
> 配送途中ではMIMEデコードしてはいけない部分
> MIMEデコードしないと処理できない部分
>
> この二つの部分が重なっているからです。今の場合は、
配送途中でデコードしないといけないケースというのってありますか?
> Re: の処理は、ニュースリーダが行なうべきなのだが、
> MIME エンコードするとそれができなくなってしまう
これは単純にニュースリーダの処理の問題に過ぎないでしょう。
> なんだけど、
>
> MIMEエンコードを続けると間の空白の情報が失われる
>
> ってのがあるので、全体をエンコードしたい気持も理解できます。
理解できるけれど、やるべきでないことでしょう。
> >> （RFCはSubjectが「Re:」そのもので始まっていることを要請しており、
> >> “MIMEデコードして「Re:」になる文字列”では要請を満たさないと読解する）
> >すみません。ここでいう「RFC」とは何番のことでしょうか?
>
> この議論は前にもあって、その時は、ネットニュースのが引用され
> ていたような気がする。
これはRFC1036, Standard for interchange of USENET messagesでしょう。
> ちなみに僕は、MHから投稿しているので、かなり特殊なほうかもね。
希少種でしょう。:-)
--
神戸 隆博 / Takahiro Kambe
Koichi Nakatani
戸田さん>
> > >> （RFCはSubjectが「Re:」そのもので始まっていることを要請しており、
> > >> “MIMEデコードして「Re:」になる文字列”では要請を満たさないと読解する）
中谷>
> > >すみません。ここでいう「RFC」とは何番のことでしょうか?
河野さん>
> > この議論は前にもあって、その時は、ネットニュースのが引用され
> > ていたような気がする。
神戸さん>
> これはRFC1036, Standard for interchange of USENET messagesでしょう。
お教えいただき有り難うございます。
戸田さんに御紹介頂いた所の「RFC違反だという説を唱える人」が、
もしも Status: UNKNOWN である RFC 1036 を根拠にしているとすれば、
STANDARD TRACK 以外の RFC を根拠とするのはコケおどしな言説であると
言わざるを得ません。
Takahiro Kambe
Koichi Nakatani <k...@pop02.odn.ne.jp> writes:
> 戸田さんに御紹介頂いた所の「RFC違反だという説を唱える人」が、
> もしも Status: UNKNOWN である RFC 1036 を根拠にしているとすれば、
> STANDARD TRACK 以外の RFC を根拠とするのはコケおどしな言説であると
> 言わざるを得ません。
1. NetNewsの記事の形式を定めたものはRFCでは1036しかなく、それを様々
なNetNewsのソフトウェアが守って来ていること。
かつてInternet-draftはあったと記憶していますが、現在有効なも
のがあるかどうかは把握していません。
2. NetNewsの由来はInternet上ではありません。現在はInternetを介して配
送されることが殆どとなり、その1サービスである様になりましたが。
たまたまInternetが配送の1手段として使用されていたシステムの記事の
形式なので、ある意味standard trackに乗っていなくて当然だったと言
うことも言えます。
3. standard trackに乗っていないRFCだからといって、その規定する内容が
無意味というわけではありません。特定のサービスにおいて重要なこと
を決めていたものが、RFCとなったと言ったケースでは、それがinforma-
tionalなものであろうが何であろうが、その方面では重要な「規約」で
あるケースがあっても不思議ではありません。
--
神戸 隆博, 株式会社ジェプロ(京都) / Takahiro Kambe, JEPRO Co., Ltd.
Koichi Nakatani
神戸さん>
> 3. standard trackに乗っていないRFCだからといって、その規定する内容が
> 無意味というわけではありません。特定のサービスにおいて重要なこと
> を決めていたものが、RFCとなったと言ったケースでは、それがinforma-
> tionalなものであろうが何であろうが、その方面では重要な「規約」で
> あるケースがあっても不思議ではありません。
おっしゃる通りですが、ある方面で重要な規約であれば、その写しが
RFC になっているか否かとは無関係に重要であるはずです。その場合には
ことさら「RFC違反」という言い方をすべきではないと思います。というのは
RFC であること自体が重要だという誤解が蔓延しているようなので。
Shinji KONO
使ってたりしますが... いまだに通さないサイトが残っていると言うのが
感動ですよね。
In article <399AA5F3...@pop02.odn.ne.jp> ,
Koichi Nakatani <k...@pop02.odn.ne.jp> writes
>おっしゃる通りですが、ある方面で重要な規約であれば、その写しが
>RFC になっているか否かとは無関係に重要であるはずです。その場合には
>ことさら「RFC違反」という言い方をすべきではないと思います。というのは
>RFC であること自体が重要だという誤解が蔓延しているようなので。
あれ? それって、
Re: を重複させない処理を行なうこと
その簡単な実装を知りつつ、それを邪魔する MIME の実装を行なうこと
みたいなことを正当化するのには、ちょっと不利な主張じゃないですか?
なかたにさんの主張は、
MIMEエンコードしたRe:を、重複させないのは簡単だから、Outlook
のような実装は正当化できる。 (たとえ、他のすべての実装の手直
しを要求したとしても) 何故かと言うと RFC 違反ではないから。
てなもんだと思ってました。
mh で、MIME エンコードしたRe: の処理をさせるにはどうすれば良いんだろ?
Takahiro Kambe
Koichi Nakatani <k...@pop02.odn.ne.jp> writes:
> おっしゃる通りですが、ある方面で重要な規約であれば、その写しが
> RFC になっているか否かとは無関係に重要であるはずです。その場合には
> ことさら「RFC違反」という言い方をすべきではないと思います。というのは
> RFC であること自体が重要だという誤解が蔓延しているようなので。
た記事の形式に関する規約はRFC1036 *しか* ないのです。Internet-Draft
等であるかもしれませんが、Internet-Draft自身が期限付きであるので、こ
れをもって規約だと言うのは無理があって、将来こうなるという方向性を示
すものとして参照する程度でしょう。
まぁ、せめて単に「RFC違反」じゃなくて、該当するRFCの番号も含めるべき
ですね。