要約

  • NetnewsのSupersedesが指定する先行記事は、単一のMessage-IDで特定される。訂正版は別の識別子を持つ通常の記事である。
  • 先行記事の取り下げはcancelと同じ認証・認可を受け、各サービングサイトが自分のコピーに対して判断する。訂正版を受け入れても旧版を残すサイトはあり得る。
  • Cancel-LockとCancel-Keyは要求者の証明を強化したが、独立した保存先すべてに消去を強制する仕組みにはならなかった。

訂正版は二つのサイトに届いた

左右に二つのニュースサーバーがあるとする。誤記を直した記事は両方に届き、どちらの読者も開ける。一方のサーバーは取り下げ要求を認証し、旧記事を通常の提供対象から外した。もう一方は証明を確認できず、あるいは方針上応じず、新旧をともに残した。

訂正の配布状況は同じでも、見える過去は違う。ここで「置き換えに成功したか」という問いを一つの真偽値にすると、プロトコルが意図的に分けた二つの結果を失ってしまう。

Supersedesの巧みさは、旧版を回収できないサイトにも訂正版を届けられる点にあった。分散した過去を一括更新する代わりに、新しい事実を追加し、古い事実の扱いは保管者ごとの判断にしたのである。

原型はcancelのローカル処理だった

RFC 1036では、cancel制御記事が対象のMessage-IDを示す。受信したシステムが取り消し可能なら、そのサイトにあるコピーを処理する。ネットワーク全体の原本を書き換える命令ではない。

誰に取り下げを認めるかは早くから難題だった。旧仕様は対象記事と要求側のSenderまたはFromを比較し、サイト管理者にも権限を与えた。だが、開放的な配送環境で似た差出人欄を示すことは、原稿を支配していることの強い証明にならない。

この弱さは、削除の範囲だけでなく、削除権限の危うさも示した。コピーが各地に分かれれば、処理主体も認可判断も各地に分かれる。

Supersedesは上書きではなく二つの処理を束ねた

RFC 5536のNetnews用Supersedesは、先行記事一件のMessage-IDを値に取る。規定上の効果は、対象へのcancel要求を先に処理し、その直後にSupersedes欄を取り除いた新記事を通常どおり扱うことに相当する。

つまり、訂正版が旧記事の本文領域を更新するのではない。新しいMessage-ID、ヘッダー、配送経路、保存記録を持つ別の記事である。二つの識別子の間に「後継」という関係を置きつつ、旧記事への操作を別に求める。

さらに、先行記事の取り下げが新記事受理の前提ではない。この非対称性によって、掃除が完全でなくても訂正は流通できる。

どのコピーを引き下げるかはサイトが決めた

RFC 5537は、Supersedes自体を制御メッセージとはしない一方、指定記事の取り下げについてはcancelと同じ認証・認可を適用する。認めるなら、有効なcancelと同じローカル処理を行う。

ところが、新記事は要求が認められたかどうかにかかわらず通常どおり扱われる。訂正版を受け取った事実から旧版消去を推定することも、旧版が残った事実から訂正失敗を推定することもできない。

同RFCは、認証の難しさと不正cancelの危険から、多くのサイトがcancelやsupersedeを無視してきた事情にも触れる。投稿ソフトは他人の記事を置き換えようとする操作を拒むべきだが、その後の各サイトも独自に証拠を評価する。

暗号的な鍵は証明を改善した

RFC 8315のCancel-LockとCancel-Keyは、差出人欄の類似より強い手掛かりを与える。元記事にロック値を載せ、後のcancelまたはsuperseding articleが鍵を提示する。サイトは鍵から導いた値をロックと比較し、元の投稿に結び付く知識を確認できる。

これは権限詐称への防御であって、全保存先への命令ではない。鍵が一致しても、実装していないサイト、独立アーカイブ、ゲートウェイ先、引用済みの文章まで消えるわけではない。認証結果と消去範囲は別の問いである。

強い証明を得たからこそ、表現も精密でなければならない。「要求者を確認できた」を「世界中から消えた」と言い換えてはならない。

Mailの同名欄は別物だった

RFC 2156はInternet MailとX.400の変換において、複数のメッセージ識別子を取り得るSupersedes欄を定める。RFC 5536は、単一対象のNetnews欄とこのメール版には関係がないと明記した。

IANA Message Headers Registryでも、mailとnetnewsの項目は別々に登録されている。同じ英単語が表示されても、メールボックスの「取り消し」とニュースサーバーのローカルwithdrawalを同一視する根拠にはならない。

登録が保証するのは名称と参照仕様であり、現在の採用率、運用方針、削除完了ではない。

消せない過去にも訂正は追加できる

分散システムの履歴は、訂正版を出しただけでは一列に整わない。ある読者は新版だけを見て、別の読者は二版を比較し、アーカイブはサイトが隠した旧版を保持するかもしれない。その不揃いを欠陥として隠すより、「関係付け」「表示抑制」「特定ストアからの取り下げ」「証拠集合からの不存在」を区別する方が正確である。

Supersedesは過去を上書きする権利を発明しなかった。訂正を独立した記事として前へ進め、過去への要求には範囲と証明を求めた。呼び戻せない先行記事があっても、改訂の公開は止めない。それが分散ネットワークに適した訂正の形だった。