要約

  • 初期仕様は Expires を「推奨される満了日」と呼び、通常の保存期間をディスク容量などに左右されるサイトごとの既定方針に委ねた。
  • RFC 5536 の定義は、投稿者が記事を無関係とみなし、有用に除去できる時点である。保存枠の予約でも、検証可能な削除命令でもない。
  • NNTP が答えられるのは一台のサーバーにおける現在の可用性だけであり、不在応答から削除理由や全コピーの消滅を導くことはできない。

同じ告知に異なる保存履歴

セミナー告知が二つのニュースサーバーへ届く。Message-ID も、催しの翌日に設定された Expires も同じだ。一方は容量に余裕があり、その期限まで告知を保つ。もう一方は容量が逼迫し、より短いローカル方針を適用する。

日付が偽りになったわけではない。投稿者が知るのは、催しが終われば告知の用途が薄れるということだ。遠隔サーバーの棚を確保する権限までは持たない。運用者は自らの容量、利用者、アーカイブ、法的・運用上の責任を知っている。

「推奨」という語が境界を作った

RFC 850 は Expires を推奨満了日とした。欄がなければローカル既定値を使う。自然に価値を失う記事を早めに片付ける用途と、重要な記事を通常より長く残したい用途の双方が示された。

セミナーの例は、日付を内容の寿命に結び付ける。同時に仕様は、各サイトの満了方針が利用可能なディスクなどに依存すると明記した。自然な期限がなければ利用者は記入を控え、システムソフトウェアも既定の Expires をほぼ決して挿入すべきでないとした。

自動挿入を避けることは出所を守る。テンプレートが作った日付を、投稿者の判断のように見せないためだ。欄がなければ通常のサイト方針が働き、欄があれば投稿者由来の例外的な有用性情報だと分かる。

RFC 1036 もこの分担を維持した。共通の欄を設けても、保存資源の管理は集中させなかった。

遠い日付はディスクの債権ではない

将来の遠い日付は、投稿者が長く有用だと考えていることを示す。全受信サイトが容量を約束した証拠ではない。近い日付も全世界的な消去指示ではない。アーカイブ、調査記録、リレー、私的コピー、引用は日付後も残り得る。

欄は保管者を列挙せず、削除の受領確認も集めない。有用性の地平は一度書いて記事と共に複製できるが、保管判断は実際にバイトを支配する場所ごとに行う必要がある。

現代仕様は判断者を明記した

RFC 5536 は Expires を、投稿者が記事をもはや関連性なしとみなし、有用に除去できると考える日時と定義する。通常より長い、または短い満了を望む場合に役立つとも説明する。

主語は投稿者である。仕様は、その時刻までディスクが予約されたとも、全エージェントが同時に削除しなければならないとも述べない。ローカル方針で早く消えることも、アーカイブ例外で後まで残ることもある。どちらも日付の虚偽を単独では証明しない。有用性と保管状態が別だからだ。

NNTP は照会先のサーバーについてだけ答えた

RFC 3977 の GROUP は、そのサーバーで現在利用できる記事を報告する。グループ内番号がなければ ARTICLE は 423、Message-ID の記事をそのサーバーが持たなければ 430 を返せる。

この応答は、記事が過去に存在しなかったこと、Expires が削除原因だったこと、別サーバーにもコピーがないことを証明しない。ローカル観測を世界的な削除証明に格上げしない点こそ、正確な設計である。

RFC 5537 は保存制限の一般的な限界も述べる。Netnews で運ばれる要求は受信サイトの協力に依存し、プロトコルだけでは強制できない。この箇所は Archive と Distribution を扱い、Expires を再定義してはいない。それでも、運ばれた構文が保管設備を支配しないという境界を確認できる。

登録は名前を安定させ、結果を保証しない

現在の IANA Message Headers Registry は、Netnews の Expires を RFC 5536 参照の標準欄として掲げる。実装が同じ名前を使う根拠にはなるが、現在の事業者の容量、保存期間、例外を監査するものではない。

Usenet が残した価値は節度にある。情報がいつ役目を終えるか知る者は、その判断を記録できる。ディスクを持つ者は、バイトをどこに残すか決める。日付がネットワークを渡れたのは、渡った先の棚を所有するふりをしなかったからだ。