要約

  • NNTPは、世界的に一意なMessage-IDと、「ニュースグループ名＋記事番号」というサーバーローカルなキーを分けた。クロスポストされた一つの記事は、複数の番号を持っても複数の記事にはならない。
  • Xrefは、そのサーバー上の複数の格納位置を一つの記録にまとめ、閲覧ソフトが同じクロスポストを何度も処理するのを防いだ。
  • 配信サーバーは通常、受け取ったXrefを削除して自分の格納情報を書き直す。書き換わるのはローカルな整理券であり、記事本文や世界的な同一性ではない。

二度目に現れた記事

あるニュースグループで記事を読み終えた後、別の購読グループを開くと同じ記事が再び現れる。表題も本文も同じなのに、記事番号だけが違う。複製なのか、再投稿なのか、それとも別の記事なのか。

Netnewsでは、どれとも限らない。投稿者が一つの記事を二つのグループへクロスポストした可能性がある。サーバーは通常、一つの実体だけを保存し、各グループの索引から別々の位置で参照する。最初の番号しか覚えない閲覧ソフトは、二つ目の座標を二つ目の実体と誤認しかねない。

Xrefはこのための格納票だった。最後に記事を処理したニュースサーバーの名前と、そのサーバー内で記事が置かれたグループおよび位置を並べる。記事に別名を与えるのではなく、複数のローカル座標を一つの記事へ結び直す。

同一性は「どの記事か」を答え、位置は「このサーバーのどこから読めるか」を答える。分散システムには両方が必要だが、両者を同じ権限として扱ってはならない。

三つのキーが示す範囲

RFC 3977 は、NNTPが記事の保存と取得に使う三種類のキーを説明する。第一は記事を世界的に一意にするMessage-ID、第二はニュースグループ名とその中の記事番号、第三はサーバーが持つ到着時刻である。

グループと番号の組には強いローカル規則がある。一台のサーバーの一つのグループでは、ある番号は一つの記事だけを指し、一つの記事が同じグループで二つの番号を持つこともない。しかしクロスポスト記事は複数のグループに属せるため、グループごとに別のキーを持ち、番号も違ってよい。

一方、このキーは世界的に一意である必要がない。同じグループ名と番号の組が、別のサーバーでは別の記事を指し得る。番号は各サーバーへの到着順で割り当てられるから、サーバーを替えることは座標系を替えることでもある。

NNTPのGROUP応答が示すのは下限・上限の水位と推定件数であり、間の全番号が存在するという保証ではない。記事は削除されることがあり、規則の範囲内で以前の番号に復元されることもある。欠番はネットワーク全体からの消滅証明ではなく、大きな番号も世界的な新しさの証明ではない。

一つの記事、複数の棚

RFC 5536 は、一つの記事を複数のニュースグループへ投稿するクロスポストと、同じ文章を別々の記事として投稿する行為を区別する。一般的なサーバーは記事を一部だけ保存し、その周囲に複数のグループ索引を作る。

Xrefはこの広がりを短く表現する。先頭に生成したニュースサーバーの識別子があり、その後に一つ以上の位置が続く。各位置はグループ名と記事ロケーターの組である。伝統的なNNTPではロケーターは十進の記事番号だが、RFCは実装固有の形式も許す。

サーバー名には座標の範囲を示す役割がある。それを外せば、同じように見えるグループと番号が他のサーバーで別の記事を指す。範囲を保てば、閲覧ソフトは一台のサーバー上の複数位置が一つの記事へ戻ることを理解できる。

RFC 5536は、利用者エージェントがクロスポスト記事を何度も処理しないためにXrefをよく使うと説明する。一つのグループで記事を表示した後、同じ格納票に結ばれた他の位置も処理済みにできる。これは単なる見栄えの改善ではない。一つの発言が複数の読者層へ届いても、複数の独立した発言として数えないための意味保全である。

投稿先の宣言とサーバーの格納判断

Newsgroupsは記事がどのグループへ投稿されたかを宣言し、Xrefは最後のサーバーが実際にどこへ格納したかを示す。RFC 5536は、Xrefに列挙されるグループがNewsgroupsと異なってもよいと明記する。

これは矛盾ではなく、ローカルな判断を隠さない設計である。サーバーが全グループを扱うとは限らず、サイト方針やモデレーションによって一部の格納を拒否する場合もある。保存期限によって閲覧可能な集合も変わる。投稿者の宣言をそのまま格納票に写せば、サーバー自身の判断が見えなくなる。

したがってNewsgroupsは宣言された配布先、Xrefはローカルな保存像を担う。一方を他方の権限に見せかけてはならない。

書き換えられることが仕様だった

RFC 1036 が1987年に記述したXrefは、ローカルホスト名とスプールディレクトリ由来のグループ／メッセージ番号の組だった。情報はローカルシステムだけに価値があり、転送すべきでないと説明している。その例でも、一つのメッセージは二つのグループで異なる番号を持った。

後のアーキテクチャは、フィールドを恒久的な同一性へ昇格させず、構成要素間での扱いを整理した。RFC 5537 は中継エージェントが既存のXrefを削除し、自分の用途のために新しく追加することを許す。配信エージェントは、送信側ロケーターを保存する特別設定を除き、受信したXrefを通常削除し、保存前に自分のXrefを加えてよい。実際には加えるのが一般的だとされる。

この置換は例外処理の穴ではない。同じRFCは、中継・配信エージェントが記事を変更できる範囲をPathとXrefに限り、本文を変更してはならないとする。位置メタデータが変わっても、記事は同じ記事のままである。

格納票が保管境界で書き換え可能なのは、それが投稿者の恒久的な記事ではなく、各サーバーの格納判断を記録するからだ。

サーバー名は印鑑ではない

サーバー名を発信元の証明と読みたくなるが、仕様はその権限を与えていない。名前は後続の座標をどのサーバーの体系で読むかを示すもので、暗号署名でも、投稿者確認でも、最初に記事を受け入れた機械の証明でもない。

中継・配信側がフィールドを削除して再生成できる事実は、不変の来歴として扱えない理由でもある。認証ではないという境界は、書換規則と認証契約がないことから導く慎重な推論である。Xrefは配信サーバーの視点を示す有用な証拠だが、そのサーバーに対する信頼と観測の範囲でしか読めない。

現在のIANAメッセージヘッダーフィールド登録簿 はXrefを標準Netnewsフィールドとして登録し、RFC 5536を参照している。Message-IDとNewsgroupsも別項目である。登録は共通語彙を保つが、同一性、配布宣言、ローカル位置を一つの権限にはしない。

その番号が意味したのは「ここ」

Xrefの成果は、強力な識別子をもう一つ発明したことではない。一つの記事が複数の座標を持ち、次のサーバーで座標が変わっても記事は変わらないと、分散閲覧システムに認めさせたことである。

位置を同一性とみなせば、クロスポストやサーバー移行のたびに重複した記事が生まれる。反対に、同一性を位置とみなせば、世界的に名前のある記事には世界共通の住所があるはずだと錯覚する。NNTPはそのような約束をしていない。

公的資料から、現在どの程度のクライアントがXrefを使うか、個別事業者が既読状態をどう実装するかは分からない。ある番号が消えた理由も、このフィールドだけでは説明できない。ただし仕組みの範囲は明確である。Message-IDは「どの記事か」、Xrefは「このサーバーがどこへ格納したか」を答える。その節度こそが設計上の強みだった。