要約
newgroupはグループの作成、または既存グループのモデレーション状態や説明の変更を求める。世界共通レジストリへの強制書き込みではない。- 各エージェントはローカルな承認方針で要求を認証し、実行を拒める。同じ制御記事から異なるサーバー台帳が生まれ得る。
- 通常記事が未知の名前を指定してもグループは作られず、NNTPの
NEWGROUPSも照会先サーバーの履歴しか返さない。
一つの要求が二つの台帳を残す
同じ承認済み制御記事が二台のサーバーに届いたとする。記事はモデレート対象の新グループと説明を提示する。左のサーバーは階層管理者の権限を確認し、ローカル台帳に項目を作る。右のサーバーは自らの信頼経路で権限を確認できず、審査待ちにするか拒否する。
その後、通常記事が新しい名前を宛先に選ぶ。左では作成済みグループに格納できる。右では未知名を見ただけで設定を生やしてはならず、記事はその宛先に入らない。
宣言の配送は同じでも、採用結果は違う。これは同期の失敗ではなく、分散した保管者ごとに執行権限を置く設計だった。
初期仕様にも手動判断の余地があった
RFC 1036では、Controlヘッダーの最初の語が命令、残りが引数だった。実装者と管理者は制御メッセージを自動実行しても、手動処理のために待ち行列へ入れてもよいとされた。
newgroupはグループ名と任意のmoderatedを取る。本文は用途の短い説明を含み、フラグがあればモデレート、なければ非モデレートとして作成を求める。Approvedがなければ無視する。
「作成する」という初期の表現は、要求を受け入れた個々のシステムの処理を指す。自動か手動かを選べた時点で、一つの中央操作が全ホストを拘束するモデルではなかった。
Controlは通常配送を超える行為を求めた
RFC 5536は、Controlを、通常の保存や中継に加えて別の行為を求める記事の印と定義する。動詞が行為を示し、引数や本文が詳細を与える。
したがって、制御記事を受信・中継したことと、その要求を実行したことは別である。サーバーが要求を記録として保持していても、グループが作成済み、あるいは現在利用可能だとは限らない。
同じ記事にControlとSupersedesを併記できない規則も重要だ。グループ台帳の管理と、既存記事の撤回は異なる権限面である。
Approvedだけでは管理権を証明できない
RFC 5537は、制御メッセージが通常処理を超える行為を引き起こすため、悪用されやすいと説明する。当時、送信者を認証し、内容がその送信者から来たと標準方式で検証する手段はなかった。非標準方式は存在した。
実行側は認証すべきだが、別プロトコル、人手の審査、外部情報など、方法はローカル方針に委ねられた。そして、どのNetnewsエージェントも制御要求に従う義務を負わない。標準が定義するのは要求の意味であり、遠隔サーバーへの支配権ではない。
グループ制御にはApprovedが必須で、欠けた要求は実行すべきでない。しかし、承認者の記載は、その人物や組織が当該サーバーで階層を管理できることの認証済み証拠とは別である。
作成は既存メタデータの変更も含んだ
RFC 5537はnewgroup、rmgroup、checkgroupsを、サーバーが知るグループ一覧の更新要求としてまとめる。実行前には、対象名がNetnewsの命名制約に合うか確認しなければならない。
newgroupは新設だけでなく、既存項目のモデレーション状態や説明の変更も求められる。実行するならmoderatedフラグに状態を合わせる。未知の拡張フラグを推測して処理せず、要求を無視する。
本文にはapplication/news-groupinfoで説明を入れられる。そこにもモデレーション状態があれば、命令のフラグと一致しなければならない。説明を保存するサーバーは、要求を受け入れたとき自らのメタデータを更新する。
管理対象は名前だけでなく、運用状態と説明を含む。それでも、効力は採用したサーバーの中に限られる。
通常記事に暗黙の作成権はなかった
RFC 5537は、Newsgroupsに未知名が現れただけでサーバーが新グループを作ることを禁止する。通常の作成経路は制御メッセージである。
この分離がなければ、投稿者の入力ミス、仮のラベル、敵対的な命名が永続設定に変わる。内容を書く権利は、保存先を管理する権利ではない。
未知グループ宛ての記事が拒否されても、newgroupが一度も送られなかった証明にはならない。そのサーバーが処理時点で利用可能な項目を採用していなかったことだけを示す。
NEWGROUPSは照会先の記憶を返した
RFC 3977の読者コマンドNEWGROUPSは、指定時刻以後に照会先サーバーで作成されたグループを返す。似た名前でも、制御動詞を実行するのではなく、ローカル履歴を読む機能である。
応答には現在利用できないグループが含まれることがあり、作成日時が不明なグループは欠落し得る。空の一覧も正しい応答だ。全世界の存在や、ローカルな現在可用性を完全には証明しない。
宣言の受信、要求の採用、現在の可用性、日時付き履歴への掲載は、別々に観測すべき事実である。
IANAが固定したのは道具の名前だった
IANA Message Headers RegistryはControlをNetnewsの恒久フィールドとして登録し、標準を参照する。これにより実装間で制御面を識別できる。
しかし、全グループの一覧、階層管理者、認証済み発行者、各サーバーの実行結果は登録しない。レジストリは道具を標準化し、その使用結果を中央集約しない。
架空の全会一致を要求しない命名
newgroupは、中央データベースなしで管理意図を伝えた。共通構文が要求を説明し、命名規則が対象を制約し、Approvedが承認帰属を示す。認証とローカル方針が実際の効果を決める。
あるサーバーは作成し、別のサーバーは審査し、さらに別のサーバーは階層全体を受け入れない。それらは整合性のない「一つの世界」ではなく、独立した台帳の正直な状態だった。
歴史的教訓は、宣言と採用を同じ証拠にしないことだ。携帯可能な宣言は自治システムを調整できるが、運用上の事実になるのは保管者が採用した場所だけである。
出典
会員向け解説
プロフィールの詳細
適切な会員レベルでログインすると、解説全文と出典メモをご覧いただけます。
Strategic Circle 限定
Strategic Circle
すべての読者に公開されています。参加してログインすると プロフィール解説 を閲覧できます。
Strategic Circle に参加Leadership Alliance 会員限定
Leadership Alliance
対象となる IP 資産の所有者・管理者向けです。ログインすると Leadership Alliance の解説を閲覧できます。
Leadership Alliance に参加
