要約

  • 10月28日の個人草案は、活動、対話、タスク、資源、関係という五つの単位で分散した仕事を結ぶ。実際の作業全体と、参加者が保持する関連と、特定のプロトコルが管理する関連を区別する。
  • 新しい対話を管理範囲に入れるかは参加者が選べる。いったん管理対象の結び付きを受け入れたなら、関係する変更を保つか、失敗を明示する責任が生じる。範囲外の秘密の委託先に、元のプロトコルの義務は自動では及ばない。

扉は閉めても、伝言を落としてはいけない

草案の図でDは対話を表す。D1は依頼者と最初の相手、D2はその相手とエージェントA、D3はAとエージェントBの対話だ。D1で要件が変わり、D2とD3のタスクがそれに依存していれば、変更はこの三つの対話の接続を通って届く。一方、Bから別のエージェントCへ延びるD5は、その変更と無関係なら一斉送信の対象ではない。「誰もが全体を知る」ことと「引き受けた接続を守る」ことは違う。

実務上の急所は識別子の対応表だ。D1のタスク番号だけではD2のどの仕事か分からない。両側を知る仲介者が対応を保持するか、境界で番号を訳す。これを失えば、画面には同じ活動が続いているように見えても、変更すべき下流タスクには新しい指示が届かない。

BがCに非公開で仕事を委ね、Cとの対話を上流の管理プロトコルへ登録しないことも草案は認める。Bは橋渡しの記録を手元に置き、Cを公開せずに済む。そのプロトコルは参加していないCに義務を課せない。一方、Bが既に管理すると約束したD1からD3のつながりは残る。秘密の扉は、約束を消す出口ではない。

伝える情報も必要な分だけでよい。活動への参照は渡し、顧客名や対話履歴は伏せられる。受け取った関連情報を次の相手に丸ごと渡す義務もない。ただし必要な対応を作れないほど情報を削れば、作業が際限なく止まる前に失敗を知らせる、というのが草案の線引きだ。識別子を持つだけで指示する権限も生じない。

IETFの登録では、まだ個人草案である。通信形式も運用実績も示していない。「Failure Visibility and Bounded Accountability」の節は TBD のままだ。誰がどの関連を引き受け、変更がどこまで伝わり、途切れたとき何が見えるか。それを示す実装記録が次の材料になる。

出典：草案原文、IETFの状態。