NNTP概要の空欄が不在の証拠になる条件

要約

二つのタブが隣り合えば、列の位置は保たれたまま値だけが空になる。クライアントが知りたいのは、その空白が記事の特徴なのか、サーバーの知識不足なのかである。

ある日から新しいヘッダーを索引化した場合、新着記事には値が入り、古い記事は空になる。古い記事が本当にヘッダーを欠いていた場合も表示は同じだ。ここで空欄を不在と断定すれば、索引の導入日を記事内容の歴史に書き換えてしまう。

RFC 3977は、フィールドについてすべての記事の値または欠如を記録するデータベースを一貫していると定義する。実際にはヘッダーを持つ記事があるのに、その一部しか記録されていなければ一貫していない。

RFC 977のHEADは、Message-IDまたはサーバー内の記事番号で一件を選び、そのヘッダーを返す。精密な個別確認には向くが、ニュースグループ全体の件名一覧を作るには何度も往復する。

RFC 2980が記録したXOVERは、記事番号の範囲を概要データベースからまとめて返した。各行は記事番号、件名、著者、日付、Message-ID、参照、バイト数、行数の順で並び、任意の項目が後ろに続けられた。

事前抽出と一括転送が速度を生む。しかし、短い行では項目名が省かれ、位置が意味を担う。値に含まれるタブや改行は空白に変換される。内容が区切りとして解釈され、後続列をずらさないためである。

RFC 3977のOVERは最初の八項目を固定する。記事番号またはゼロ、Subject、From、Date、Message-ID、References、:bytes、:linesである。途中の空欄は隣接タブで位置を残し、末尾の連続した空欄だけは省略できる。

LIST OVERVIEW.FMTは実際の順番で項目を説明する。最初の七行はOVERの第二項目から第八項目に対応する。追加ヘッダーの:fullは、値にヘッダー名も含まれることを示す。共通部分は固定しながら、追加部分を推測なしに読める仕組みだった。

形式は同じセッション内でも変化し得る。クライアントが取得するのは現在の索引契約であり、永久の構造ではない。

新しい項目の導入には時間差がある。今後の記事は到着時に記録できるが、既存の概要行には値がない。すべてを再読して再構築するか、旧方式の記事が保持期間を終えるまで、全体としての列は完成しない。

RFC 3977は、LIST OVERVIEW.FMTが一貫していない項目や保存していない項目を含むことを禁じる。新しい列は一貫性が戻ってから公開する。一方、保存をやめる列は、停止する前に形式から削除しなければならない。

つまり形式変更は、データ作業の後追い表示ではない。列がどの歴史範囲を代表できるかについての権限移譲である。部分的に値を持つことと、列として不在まで断言できることは別だった。

一貫したフィールドが形式に載っていれば、その記事のセルが空であることは、対応するヘッダーまたはメタデータがないという意味を持つ。存在したなら同じ取り込み規則が記録したはずだ、という反事実が支えている。

形式に載っていない項目については、記事側の不在を推論できない。索引が約束していないだけかもしれない。サーバーの保存選択を、記事著者の選択として読み替えてはならない。

コロンで始まる:bytesと:linesは、記事に書かれた同名ヘッダーを信用せず、サーバーが計算するメタデータである。出所の層は明確になる。

それでも:bytesは歴史的な実装差を抱え、RFC 3977はクライアントに正確さを依存しないよう求める。誰が測ったかと、測定がどこまで正しいかは別の証拠である。

範囲結果は存在する記事だけを数値順に返す。削除済み記事は出力しないことが推奨され、番号の穴は残る。概要は現在の索引であって、本文の永続保管証明ではない。

IANAのNNTPパラメーター登録簿はOVERを概要サポート能力として登録する。標準の合図を示すだけで、現行利用率や性能を保証しない。

概要データベースは、各読者が繰り返していた抽出をサーバー側で共有した。だが、空欄の原因を一つにできなければ、高速な一覧は高速な誤解にもなる。

NNTPは不完全な移行中に列を引っ込めた。履歴全体を同じ規則で扱えるようになってから、形式に戻した。空欄が証拠になれたのは、空であるからではない。列が先に一貫性を証明したからである。