[plamo:17557] Re: (17525) Re: MLの直前の参照番号を残して戴けませんか？

[Shun-ichi TAHARA (田原 俊一)]

From: "Ujiki.oO" <u_jiki@yahoo.co.jp>
Message-Id: <20030123144756.47043.qmail@web303.mail.yahoo.co.jp>

> > References:
> > ヘッダは、スレッド的な先祖メッセージ群のMessage-Id:で、
> > In-reply-to:
> > ヘッダは、直接の親(引用元とか)メッセージ群のMessage-Id:で
> > す。
> 
> なるほど、良くわかります。すると、MLシステムに限らずスレッド
> を無視してしまうメールクライアントって言うのは、このヘッダー
> の重要な標準仕様を無視し、書き換えてしまうから問題を起こすわ
> けですね。違うのかな。例の巨大ソフトメーカーの多数のユーザー
> が利用するメールクライアントのことなんですが。なぜ、標準仕様
> を無視できるのでしょう。

実は、References: と In-reply-to: の使い方が固まったのはつい最近の
RFC2822 からで、それまでは、これらの使い方が一定していませんでした。

元々、Netnews 方面で、References: からスレッドを作って見せる、ってのが
一般化してきて、その流儀がメールの方にも流れてきて、最終的に RFC2822
で固まった、って流れなのかな。

OutLook系に限らず、References: をうまく処理するのは難しいですので、こ
のへんを適当にやっているメーラはたくさんあります。

Microsoft がなんで標準を無視するかってのはみんなが思っている永遠の謎な
んですけどね :-)。でも彼らも一応 RFC は読んでますし、それどころか RFC
を出してることもあります。まぁ会社がでかいので、このへんは部署によりけ
り、ってのもあるんじゃないかしら。

たとえば、WinXP の IPv6 まわりの実装は、かなり凄いという話ですし。あれ
を書いたチームに Outlook を渡せば、きっとすばらしいできになってくれる
と思うのですが… :-)

> > で、References:
> > ヘッダを使ってスレッドを構築しよう、ってのがRFCで推奨
> > されているのにも関わらず、わざわざ非標準の冗長な情報を
> > 付加するのは、無駄なことではないかと思うのですが…
> 
>   小生も含めて、「ヘッダーって何です〜？」って人々もML会員と
> して参加資格はあると思うんです。ヘッダーを見ない人に優しい情
> 報はと考えるわけです。標準仕様があっても、それを無視し、乱す
> 情報も入って来る・・・・ つまり、スレッド管理を壊す、リセット
> させるヘッダー付きのメールも入って来る。

複数の問題をまぜこぜにして議論すると混乱するので分離しましょう。

1) 素人はヘッダを見てもわかんないのでもっとわかりやすい指標を
2) スレッドを切るメーラでもMLシステム側で補完できないか

の2点が要点ですね。

1) については確かにその通りです。ヘッダを全部見る人なんて(私を含めて)
普通の人じゃありません。人が見るべきヘッダはごく一部(それすらも、最近
ではメーラが処理して見易く可視化するのが普通)で、それ以外は配送システ
ムやメーラが使うためにあります。

で、「わかりやすい指標」については、木下さんも仰ってますが、わざわざML
システム側で元メールのシーケンスまで追加してあげる必要はないんです。

  ・(メーラの機能で)References: を手繰って親メッセージに飛ぶ
  ・そこにはちゃんと Subject: にシーケンスがくっついてる

ワンキーで飛べるのがミソです。スレッド対応のメーラなら可能ですよね。

Subject: に書いてある元メールの番号から、その番号を探してやるより簡単
です。

メールが MLサーバにある場合でも、先に述べたように結局スレッド全部引っ
張ってくるにはまとめて取ってくる必要がありますので、やはりローカルにあ
ると考えればいいですし、ML の過去ログアーカイブのサイトを見ればすでに
解決済であることがわかります。

2) については、どうあがいても限界がありますので、こればかりはあきらめ
るしかありません。Subject: の書式に依存したようなシステムは全く意味が
ありませんし、むしろ有害でもあります。

かりにそういう機構が実装されていることが悪い人に知られたら、意図的にス
レッドをおかしくすることだってできますよね。
# まぁ、References: を偽装すれば現状でも可能なんですが、Subject: の場
# 合、悪意じゃなくても事故が起きる可能性があります

スレッドを切ってしまうメーラってのは、どこのMLでも悩みの種のはずなので、
これの実装を改善してもらうとか、こういうメーラをできるだけ捨ててもらう
とか、そういう方向で動く方が正しいのでは?

>   いつも思いますが、結局はユーザー側で補間しないと便利になら
> ない事って多いと思ってます。

ちなみに、「同じSubject: なら繋げようとする」とか「同じSubject: ならス
レッドを隣に並べる」とかの、比較的効果が高くて危険性も低い実装だって存
在します。

インターネットの世界では、ちょっと逸脱したものを救うことは重要ですが、
人間の特定の操作とか、クライアントの特定の実装をあてにした(そうしない
とうまく機能しない)機構ってのは、経験上あまりよくないと言われています。

また、いくら重要なものでも、無理して救いすぎるよりも、そういう大きく逸
脱したもののことは考えない、というのが、システムを複雑化させて変な不具
合を出さない秘訣です。

スレッドが繋がっていることは重要ですが、これがないと絶対に困るわけじゃ
ないですので(だいたい周辺の同じSubject:を探せば見つかる)、そこまでこだ
わらなくても、あきらめてポイしておけばいいのではないかと。

典型的には、そのSubject: で検索をかけてあげれば全部拾えるはずですし。

> PS: MLのコマンドで、References:やら、Message-Id:の検索で、mget
> な手法で取り込めるのでしょうか？ 少し実験してみる必要有ですね
> 。

無理ですねー。これができれば、RFC2369なヘッダ(List-Archive:)とかと組み
合わせて、キー一発でMLサーバから親メッセージを引っ張ってくるコマンド、
みたいなのも作れるんですが。

# Mewでよければ、10分で拡張できそう
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
田原 俊一   jado@flowernet.gr.jp, shunichi_tahara@zenrin.co.jp
                                  http://flowernet.gr.jp/jado/
FingerPrint:  16 9E 70 3B 05 86 5D 08  B8 4C 47 3A E7 E9 8E D9
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣