要約

  • checkgroups の本文は対象範囲のグループを説明とモデレーション状態を含めて完全に表す。そのため範囲内の欠落は、単なる記載漏れではなく削除要求として解釈できた。
  • chkscope は含める階層と除外する枝を区切り、chksernr は一覧の変更ごとに増加して古い版への巻き戻しを防いだ。
  • 完全性や新しさは権限の証明ではない。メディア型は認可情報を持たず、各エージェントは認証、例外、実行の可否をローカルに決めた。

同じ差分、異なる処置

二台のサーバーが、ある階層に同じ四グループを持っているとする。新しい制御記事の本文には三グループだけが並び、それが対象範囲の全件だと定義されている。別管理の小階層は除外され、通し番号は両サーバーが最後に採用した値を上回る。

一台目は発行者を認証し、余分なグループを審査後に停止する。二台目も発行者を認めるが、地域利用者のため例外として残す。除外された枝にはどちらも触れない。あとから小さい番号のコピーが到着しても、すでに新しい版を採用した両者は戻らない。

結果の違いは、一覧が不明確だったからではない。要求が明確であることと、その要求が相手の台帳を支配することは別だった。

初期仕様が想定したのは照合だった

RFC 1036 では、checkgroups 本文に正式なニュースグループ一覧と説明を置く。受信ホストは自分が現在扱うグループと比較し、新規または廃止対象をローカルの Usenet 管理者に知らせ、説明を更新する。

ここには、ネットワーク全体の表を一度に書き換える操作はない。運ばれてくる基準、個別ホストの現状、管理者の処置が分かれている。比較して差が出ることは異常ではなく、この仕組みを使う理由そのものだった。

したがって、記事を受信した事実、サーバーの一覧に現れた事実、管理者が変更を承認した事実は、それぞれ別に記録しなければならない。

完全な集合だから欠落を読める

RFC 5537 は意味をより厳密にした。要求を受け入れるエージェントは、列挙されたグループを存在させ、表現対象の階層内で列挙されていないグループを除き、説明とモデレーション状態を合わせる。

この処理を成立させるため、本文は対象階層の完全な一覧でなければならず、部分一覧であってはならない。差分通知で名前が出ないことは「変更なし」かもしれない。完全スナップショットで名前が出ないことは「現集合に含まれない」という主張になる。

完全性は見栄えではなく、欠落を負の証拠として扱うための前提である。ここを取り違えると、便利な照合が正当なローカル状態を消す装置に変わる。

範囲は沈黙の有効域を決める

階層の一部が別の管理主体に委ねられることもある。chkscope は通常の接頭辞で対象を含め、感嘆符付きの接頭辞で枝を除外する。記述順にかかわらず、含有を計算してから除外を適用する。

これにより「この階層は完全に照合するが、この小階層は対象外」と表現できる。有効範囲内では欠落が削除要求になる。範囲外では、欠落から何も推論できない。古いソフトウェアが chkscope を理解しない可能性があるため、本文自体も意図した範囲外の名前を避けるべきだとされる。

監査時に本文だけを保存し、範囲指定を落とせば、どの欠落が意味を持つのか判定できなくなる。一覧と境界は一つの証拠である。

通し番号は時計ではなく順序だった

chksernr は正の値で、一覧が変わるたびに増え、減少しない。同じ範囲の後続一覧は更新後の値を持つ。サーバーは最後に受け入れた番号を覚え、それより小さい番号、さらに番号のない後続版を拒むことが推奨される。

これは全 Netnews の時刻ではない。特定範囲の完全一覧に対する前後関係である。分散配送では古い記事が遅れて着いたり再送されたりするため、すでに新しい状態へ照合した台帳を古い本文で戻さないことが重要になる。

番号にはヘッダー長以外の上限がなく、機械の整数型に収まると仮定してはいけない。この細部は、長く続く管理系列を実装都合で壊さないための設計だった。

完成した形式でも権限は生まれない

IANA の application/news-checkgroups 登録は、グループ名、説明、モデレーション印の表現を定める。一方で、このメディア型は認可情報を提供せず、認可は別の仕組みから得なければならないと明記する。

つまり、構文が正しく、全件が揃い、番号が最新でも、発行者に権限があるとは限らない。逆に権限ある発行者の一覧でも、受信サーバーがローカル例外を設ける余地は残る。

グループ制御記事には Approved が必要だが、その文字列だけで階層支配権が証明されるわけではない。RFC 5537 は各エージェントに認証と認可方針を求め、いかなるエージェントにも制御メッセージへの実行義務を課していない。

観測値は問い合わせ先のもの

RFC 3977 の LIST ACTIVE は、問い合わせたサーバーが知るグループと状態を返す。これはそのサーバーの在庫表であって、checkgroups の発行一覧でも全体合意でもない。

両者を比べれば、欠けた名前、余分な名前、状態差を見つけられる。しかし理由までは一意に分からない。制御記事を拒否したのか、例外を残したのか、範囲外だったのか、人手審査中なのかを別の記録で確かめる必要がある。

「階層から削除された」では広すぎる。「ある範囲の一覧から欠け、特定サーバーがその要求を採用した」と書いて初めて証拠に合う。

登録簿は道具を登録した

RFC 5536 は、制御記事を通常の保存・中継を超える動作の要求として位置づける。IANA Message Headers Registry は Control を恒久フィールドとして保ち、メディア型登録は専用本文を識別可能にする。

これらは相互運用の道具を安定させるが、全階層のメンバー一覧、管理者の任命、承認者の認証、各サーバーの実行結果は記録しない。表現の標準化は、対象台帳の所有宣言ではない。

中央所有者を仮定しない精密さ

checkgroups は、完全性、範囲、順序、権限という四つの問題を別々に解いた。完全性は欠落を読めるようにし、範囲は読んでよい場所を限り、番号は古い版を退ける。権限と実行だけは受信側に残る。

その結果、二台のサーバーが違う一覧を保っていても、理由を説明できる。精密な調整とは、必ず同一状態を作ることではない。どの完全一覧を、どの境界で、誰の判断により適用したかを追跡できることでもある。

参考資料