要約

  • LIST ACTIVEはその読者が今このサーバーで選べるグループを示し、任意のLIST ACTIVE.TIMESは保持されたローカル作成履歴を示した。
  • 履歴には現役グループが欠けることも、提供を終えたグループが残ることもあり、行の有無だけでは現在や過去を断定できなかった。
  • 時刻はこのサーバーでの作成時刻であり、作成者欄は説明文にすぎない。世界的な誕生時刻、認証済み主体、所有権ではない。

一致しないことが仕様だった

同じサーバーに二つの質問を送る。LIST ACTIVEには、記事番号の範囲と状態を伴う現役グループが見える。しかしLIST ACTIVE.TIMESにはその名前がない。一方、履歴側には作成時刻と作成者の説明が残る名前があり、現行一覧には存在しない。

RFC 3977は役割を分ける。読者機能を提供するサーバーのLIST ACTIVEは、そのクライアントがGROUPで選択できる全グループを含む。LIST ACTIVE.TIMESは任意で、グループ名、このニュースサーバー上で作成された時刻、作成主体を説明するための平文を返す。

さらに、履歴は情報のないグループを省略でき、古い時期を丸ごと失い、現在利用できないグループを含められる。クライアントは完全性もLIST ACTIVEとの一致も仮定してはならない。

現行一覧は行動のためにあった

RFC 977のLISTは、サーバーの有効なニュースグループ一覧だった。各行には名前、既知の記事番号境界、通常の投稿状態がある。空の一覧も「現在、有効なグループがない」という正規の答えだった。

読者が必要としたのは、次に選択できる場所である。以前存在したという理由だけで、退役グループを現在のサービスに残す必要はない。逆に、移行後に設定を復元したグループは、古い作成記録がなくても動作できる。

この現在状態は最初からローカルだった。記事番号、閲覧範囲、権限はサーバーやクライアントによって異なる。

運用ファイルが相互運用の表面になった

RFC 2980はACTIVE.TIMESを一般的な拡張として記録した。一部のニュース転送システムは、名前、このサーバーで作成された時刻、作成した主体の説明からなるactive.timesファイルを持っていた。UNIX参照実装に由来し、情報がなければ機能を実行できないこともあった。

つまり、世界的な登録機関を先に設計したのではない。ローカルな運用記録を共通コマンドで見られるようにした。その後の標準は、記録の意味を広げるより、境界を明確にした。

RFC 3977が定める作成者欄は、しばしばメールボックスの形を取る説明文である。署名でも、本人確認でも、名前空間の支配権でもない。

残った行は現在を保証しない

グループの配信を止め、保存記事を消し、構成から外し、ある読者だけに見せなくしても、古い作成行は残せる。仕様はその状態を明示的に認める。

したがって正の記録が証明するのは限定的だ。このサーバーが、名前とローカル時刻と説明を関連付けて保持している。それだけでGROUPの成功、記事の残存、他サイトの承認は証明しない。

現在を判断するには、新しいLIST ACTIVE観測との結合が要る。履歴行を永続的なサービス権と読むと、記憶を約束に変えてしまう。

欠落も過去を否定しない

空欄は強い証拠に見えやすい。しかし履歴は、情報を失ったグループを省略できる。最古の保持行より前をすべて欠くこともある。新サーバーが現在の一覧だけを受け継ぎ、前任の履歴を持たないこともある。

行がないという事実は、この応答に行がないことしか示さない。グループが存在しなかった、名前が無効だ、別のサーバーにも記録がない、とは言えない。

不在から強い否定を導けるのは、完全な網羅が約束される場合だけだ。ACTIVE.TIMESはその約束をしない。未知を未知のまま残す設計だった。

NEWGROUPSは保持窓を照らした

NEWGROUPSは指定時刻以後にサーバー上で作成されたグループを問い合わせる。RFC 3977は、場合によってはこちらがよいアクセス方法で、通常はACTIVE.TIMESと整合すべきだとする。ただし問い合わせが最古の保持行より前に及ぶと、追加のグループを返し得る。

差は保持期間の調査に使える。それでも世界共通時計にはならない。応答したサーバー、観測時刻、読者の権限、検索範囲、隣接する現行一覧を一緒に保存する必要がある。

同じ名前に異なる時刻が付く場合、各サーバーがローカルに採用した時刻の差かもしれない。分散した採用の履歴を、即座に虚偽判定へ変えてはならない。

作成者の説明は作成権限ではない

人間らしい欄は、主体の権利を連想させる。だがRFC 3977は単に「説明するための平文」とする。RFC 5537では、newgroupは要求であり、各サービスエージェントがローカル方針で認証し、拒否できる。

後の履歴行はローカル判断に付随したラベルを残せるが、その時の認証証拠を再現せず、他サイトを拘束しない。結果の記録は、結果を生んだ権限そのものではない。

来歴は調査を支える。保存されたという理由だけで主権にはならない。

IANAは言葉を揃えた

IANAのNNTP Parametersは、LISTをコマンド変種の能力ラベルとして登録し、RFC 3977を参照する。これで実装は同じ機能群を認識できる。

登録は各サーバーのACTIVE.TIMES対応、履歴の長さ、作成者説明の正しさを保証しない。IANAが調整するのはプロトコル語彙であり、ローカル事実ではない。

中央の出生台帳がなくてもよい。各サーバーが、今提供するものと覚えている過去を別々に、過大評価せず示せばよかった。

接合部を隠さない証拠

現行一覧と監査履歴を一表にまとめれば見た目は整う。しかし移行で履歴だけが失われたとき、一表は過去の連続性を偽る。退役後も記録を残したいとき、一表は現在をきれいに見せるため本当の過去を消す。

NNTPは接合部を残した。LIST ACTIVEは現在の行動可能性、ACTIVE.TIMESは限定された記憶、作成者欄は調査の手掛かりである。

二つの一覧が一致しないのは、答える問いが違うからだった。その不一致こそ、部分的な履歴が全体の権威になることを防いだ。

出典