要約

  • RFC 5005 は paged feed を lossy と明記する。見えているリンクをすべて取得しても、移動中の集合の一貫したスナップショットとは限らない。
  • archived feed は過去を再構成できる構造を与えるが、実際の走査、照合、保存、警告、読者表示までを証明しない。

夜間処理が正常終了し、現在文書と一つ前のアーカイブが 200 を返した。ローカルの件数も増えている。翌朝の引継ぎで担当者は「履歴同期済み」と報告する。

この報告には、終了条件がない。

RFC 5005 は三つの契約を定義する。complete feed は一つの文書が論理フィードの全エントリーを表す。paged feed は不安定な複数文書へ内容を分ける。archived feed は新しい変更を載せる subscription document と、古い項目を保持する archive document を組み合わせる。これらを混在させた場合の意味は同 RFC では未定義だ。

paged feed では、取得中にページの内容が変わり得る。クライアントが気付かないまま項目が追加・変更されるため、特定時点の論理フィードを再構成できる保証はない。first、last、previous、next は移動先を示すが、整合性の境界ではない。したがってクライアントは、結果を一貫または完全として見せるべきではない。

archived feed は一段強い。prev-archive が直前の古いアーカイブを指し、next-archive が新しい側を、current が現在文書を指せる。公開済みアーカイブの内容と IRI は時間がたっても変わらないことが望ましい。すでに処理したアーカイブを毎回取り直さなくてもよい、という運用上の前提を作るためだ。

しかし SHOULD NOT change は、ハッシュで固定された不変性ではない。発行者が古いアーカイブだけを書き換えると、取得済みのクライアントは変更を知らない可能性がある。全員に届けたい訂正は subscription document にも再掲すべきだと RFC は説明する。

再構成はクライアント側の手続きである。未処理の prev-archive を取得し、エントリーを加え、既処理のリンク、先行リンクのない終端、またはエラーまで繰り返す。発行者は全アーカイブを提供する義務を負わず、403、404、410 が起こり得る。クライアントも常に全部を保存・再構成する義務はない。不完全なら利用者へ知らせる必要がある。

運用上は、次の終了を分けなければならない。

  • 最古のアーカイブへ到達した。
  • 検証済みの既知アンカーへ到達した。
  • 応答エラーで止まった。
  • 要求回数、時間、保存量、手動確認の上限で止めた。

すべてを job success にすると、停止した事実だけが残り、何を完了したのかが消える。

重複も自動的には解けない。より新しい atom:updated を持つ項目を採用するのが原則だが、時刻が同じ、または存在しない場合はクライアント判断になる。RFC 4287 の正しい Atom 構造は、この選択を一意にしない。RFC 6721 が削除通知を追加したのは、基礎 Atom だけでは、以前受け取った項目が除去されたと分からなかったからである。

fh:complete は発行者側の宣言だ。一つの文書が論理フィード全体を表し、そこにない項目をそのフィードの一部とみなさない、という意味を持つ。下流キャッシュが最新表現を取得したこと、古い表示を捨てたこと、認証文脈が連続していること、利用者が結果を読んだことまでは証明しない。

再構成レシートには少なくとも、開始文書と validator、観測した link graph、各 IRI の応答・authority・content hash、走査順序、再試行、資源上限、停止理由、重複・削除方針、保持状態の revision、cutoff、完全性状態、実際に表示した警告、読者画面の readback が必要だ。

これは RFC 5005 の追加要件ではなく、Heng Lu の reality layer を運用へ移した提案である。規格は特定製品の挙動、アーカイブの実在性、削除という外部事象、利用者の反応を証明しない。二件の verified errata は例示 UUID と URI/IRI の用語を直すが、この境界は変えない。

引継ぎで問うべきなのは「ジョブは成功したか」ではない。「どの履歴を、どの終端まで、どの制約下で再構成し、何を未確定として渡すのか」である。

情報源