要約

  • RFC 5239 は会議状態と呼制御を中央に置くが、focus、会議制御、floor 仲裁、ミキサー、通知サービスを同じ権限とは扱わない。
  • 監査には、要求、認証、認可、オブジェクト版、実行、観測者別の開示を結ぶ記録が要る。一つのログが証明できるのは自分の制御面だけだ。

ミュートは一回の出来事ではない

Alice が Bob のミュートを要求する。会議制御サーバーは対象オブジェクトの方針に照らし、Alice の役割が操作を許されるか確認する。許可されれば Bob の状態が更新され、メディアを混合しない意図が記録される。通知サービスは方針次第で Bob や Carol に知らせ、ミキサーが実際の音声処理を変える。

画面はこの連鎖を緑の一語に縮められる。証拠は縮められない。要求の受理は認可の証明ではなく、認可は書き込みの証明ではない。書き込みはミキサーの実行を保証せず、通知は特定の受信者に許された表示にすぎない。

focus は中心だが全権者ではない

focus は各参加者と個別の呼シグナリング関係を保ち、グラフを星形にする。これはセッション調整の場所を示す。方針作成、オブジェクト変更、floor の判断、媒体処理、情報開示の全てを focus が担った証拠にはならない。

RFC 5239 は共有オブジェクトの周囲に会議制御サーバー、floor 制御サーバー、一つ以上の focus、通知サービスを置く。これらは論理的な役割なので同じプロセスにも置ける。しかし同居は責務を消さない。一つのプログラムであっても、どの役割として何を決めたかを残す必要がある。

媒体グラフは中央型、分散型、または媒体ごとの混成になり得る。星形のシグナリングだけで、全ての音声や映像が一台のミキサーを通ったとは言えない。

共有状態と権限を混同しない

会議オブジェクトは blueprint、予約、稼働、終了といった段階を表す。方針は操作の権利、許可、制限を定める。オブジェクトが状態を記述し、方針が遷移を認可し、プロトコルが要求を運び、実行部品が結果を生む。

識別子も別物だ。focus を指す会議 URI、オブジェクトを操作する XCON-URI、システム内で利用者と役割を示す会議ユーザー ID は交換できない。表示を簡単にするため一つの ID に畳むと、事故調査では行為者と対象を結べなくなる。

継承も保存すべき証拠である。予約は blueprint から複製され、sidebar は親会議に依存し、親の強制値が子の変更を禁じる。現在値だけでは、初期値、親制約、局所上書き、後の特権操作を見分けられない。

floor を得ても音が届くとは限らない

floor は資源を一時的に使う権利である。現行 BFCP は、floor を持つことが、権利のない他者による同じ資源の使用を技術的に排除するとは限らないと明記する。権利と執行は別の面だ。

「floor granted」は仲裁の結果を示すが、ミキサーが音声を採用したこと、別の入力を除外したこと、全参加者へ正しい混合を届けたことまでは示さない。逆に floor 記録なしの音声は、迂回、実装差、または floor 制御を使わない会議のいずれかである。

通知は世界ではなく許可された眺め

参加者は public、anonymous、hidden として扱われ得る。司会者だけが見られる本人情報もある。通知は役割、方針、プライバシーによって絞られる。

Carol の一覧に Bob がいないからといって、Bob が会議にいないとは限らない。内容の異なる二つの通知がともに正しいこともある。観測者、役割、方針版、開示規則がなければ、遅延、秘匿、検閲、障害の区別はできない。

動いたものから権限を確かめる

重要操作には六つの記録を結び付ける。誰がどの識別子へ要求したか、何で認証したか、どの役割と規則が認可したか、オブジェクトの前後版、どの部品が実行したか、各観測者に何が開示されたかである。

RFC 5239 は製品事故や普及率を報告しない。構造を読むための文法を与える。Lu Heng の running-code の視点を重ねれば、権限は「ホスト」「focus」「中央サーバー」という肩書ではなく、帰属可能な行為と実際の結果から判断すべきだと分かる。

出典