頼光 wrote:
> 
> 　「あったなら」いいんですが、それはどうやって確認するの
> でしょう。
> 
> 　そのアプローチは、少なくとも私には２つしか思いつきません。
> 
> 1) 既存の全 Message-ID をリストにして、重複が無いことを
> 　チェックする。
> 2) 生成アルゴリズムを工夫して、原理的に重複が無い方法で
> 　生成する。

1) は不可能です。2)に対するアプローチとしてRFC-1036の中で
述べられているよな方法が現実に使用されてるわけです。
しかしそれでも現実には同じメッセージIDを持った記事が
ネットワークに流れてくることがありますが。

> 　どちらかが（もしくは他に方法があるならそれでも）行われ
> ていて、私がそれを知らないだけなら、何の問題もありません。
> が、そうでないなら「あったなら」が成立しないわけです。
> 　論点は、ここです。

そこはこの件に関するかぎり、僕は論点にならんと思いますね。
というのは、どんな方法でニュース・サーバーがメッセージIDを
生成して記事に付加したとしても、サーバーは基本的に自分の
マシン内のスプールをチェックして、今生成したIDがその中に
存在するかどうかをチェックする以上のことは事実上できない
わけで、常に世の中のどこかで同じIDが生成使用される可能性が
あるからです。

RFC-977(NNTP, Network News Transfer Protocol) を実装した
ニュース・サーバーの場合、例えば頼光さんが「投稿ボタン」
を押したときに、Datula が "POST"コマンドを使って頼光さんの
ニュース・サーバーに記事を送信します。このときにサーバー
の側で、その記事にメッセージIDが存在しないことを検出した
場合には(通常はほとんどがこのケースでしょう)、サーバーが
なんらかのアルゴリズムで新しいIDを生成して、ヘッダーに
付加して自分のスプールへしまい込みます。このときに付加する
IDが「世界中で唯一でなければならない」と、RFC-1036は要求
してるわけですが、それを確実に保障するメカニズムに関しては
RFC-1036もRFC-977も関知してません。

で、サーバーに到着してIDを付加された頼光さんの記事ですけど、
次にそのサーバーが、自分と相互(あるいは一方通行)配送してる
相手のサーバーに対して "IHAVE" コマンドでその記事のIDを
示して、相手がそれを欲しがるかどうか聞くわけです。このときに
もしかすると相手側のサーバーにまったく同じIDの記事が存在
する可能性だってあるわけです。そういった事態にどう対処するか
ということは、これまた規格としては特に規定されてはおらず、
そのサーバーのソフトウェアの実装者の考えが反映されるのです。
ただし通常この場合には「それは(もうあるから)いらない」という
反応が番号として返って来ることが多いと思いますが。

つまり、ニュース・サーバーは自分の持つデータに照らし合わせて、
おそらくこれが世界で唯一のIDであろうという、ID番号を生成
して記事に付加しているだけなのです。

そこで今、同じIDが発生する事故の確率はIDの生成方法により
差があるのかということを言うなら、無論RFC-1036で推奨されて
いるような方法を利用するのが、比較にならないほど安全です。
しかしこれは、ある記事のメッセージIDが規格に沿っているか
どうか、ということは別の話です。

玉川厚徳