要約

  • RFC 5263 は同じ Request-URI の部分 NOTIFY を、前の最終応答またはタイムアウトまで待たせる。これは送信を直列化する規則であり、Watcher の状態が永続的に変わったという受領証ではない。
  • 説明可能な引き渡しには、購読と版番号、NOTIFY 本文、SIP 応答、解析・パッチ結果、適用前後のハッシュ、保存確認、下流での観測を一つの記録に結ぶ必要がある。

人を待たずに返すことが正しい応答

Watcher の自動処理は NOTIFY を受理し、200 を返した。その時点で画面を見ている人は誰もいなかった。実際、SIP イベントの規則は、人の応答を待って最終応答を遅らせてはならないとしている。

これは欠陥ではない。NOTIFY トランザクションを人の判断時間に縛らないための設計である。だからこそ、200 を「利用者が状態を見た」「利用者は連絡可能だ」「業務判断が成立した」という証拠に昇格させることもできない。

機械応答が速いほど、制度側はその範囲を明示する必要がある。速さは観測範囲を広げない。

最終応答は次の送信を解放する

Presence Agent は、同じ Request-URI に対する前の部分 NOTIFY の最終応答を受けるか、そのトランザクションがタイムアウトするまで、新しい部分 NOTIFY を送ってはならない。依存する差分を無制限に並行送信しないための境界である。

通知が購読者に受け入れ可能と判断されれば、通常は 200 を返す。トランザクションは自動処理に必要な時間を超えて延長すべきではない。この規則が証明するのは、送信側が現在の取引を終えて次へ進める条件である。

ローカル XML が保存されたか、別プロセスが新しい状態を読んだかは、別の観測面に属する。

版番号の座標系は購読である

部分通知を許す Watcher は、SUBSCRIBE の Accept に application/pidf-diff+xml と application/pidf+xml を入れる。優先度を示すことはできるが、Presence Agent はローカルポリシーも考慮して形式を選ぶ。

部分形式で最初にプレゼンス情報を送る NOTIFY は完全状態を含み、版番号を一から始める。購読の更新では番号をリセットせず、購読終了時に初めてリセットする。

従って「版 12 に 200 が返った」という記録だけでは座標が足りない。購読、ダイアログ、Call-ID、タグ、CSeq、本文ハッシュを結び付けて初めて、どの遷移について話しているかが分かる。

送信成功は送信側の履歴である

Presence Agent は、その Watcher と購読に以前正常送信した部分プレゼンス文書に対して版番号を一つ進める。さらに、前の最終応答またはタイムアウトを待って送信窓を進める。

この履歴は重要だが、送信側から見える事実である。受信側のパーサー、基準文書、パッチ適用、ディスク書き込み、再起動後の存続、下流表示のどれも直接観測していない。

健全時にはすべてが連続して見える。障害時には、それぞれの所有者と証拠が違う。近接して起きることを同一イベントとして保存してはならない。

Watcher は上流に見えない回復を選べる

受信版がローカル版以下なら、Watcher は Presence Agent の失敗とみなし、処理せず破棄すべきである。一つだけ高ければ差分を適用し、二つ以上飛べば通知の欠落を仮定して、完全状態を得るため更新するか購読を終了する。

本文処理そのものが失敗した場合も、Watcher は購読を更新し、次の SUBSCRIBE から部分形式を外して通常の完全状態へ戻ることができる。RFC 5263 は、その処理エラーを通知側へ知らせることはほとんど合理的でないと記す。

つまり通知側のログは成功で並んでいても、Watcher は内部で差分経路を断念して再同期しているかもしれない。エラーが届かなかったことは、エラーがなかったことの証明ではない。

形式変更では内容を捨て、番号を残す

同じ購読内で通知の Content-Type が変わると、Watcher は以前受け取ったプレゼンス情報を破棄する。ただしローカル版カウンターは残す。再び部分形式へ戻ったときに番号が続くためである。

この動作では、連続する番号の下で保存内容が入れ替わる。番号だけを監査すれば途切れはない。しかしどの完全状態が破棄され、どれが新しい基準になり、どの時点で下流へ見えたかは失われる。

更新時の完全文書は現在を再び固定する。過去の適用成功を後から証明するものではない。

正真正銘のメッセージでも適用は失敗する

RFC 5263 は、SIP プレゼンスの機密性、完全性、真正性、リプレイ防止、サービス妨害への配慮を引き継ぐ。当時の文脈ではホップごとの TLS を推奨し、SUBSCRIBE と NOTIFY に S/MIME を使える。RFC 8996 は TLS 1.0 と 1.1 を非推奨にする形で依存関係を更新した。

偽の部分 NOTIFY は欠番を装い、完全状態の要求を誘発できる。これを防ぐことは重要である。しかし真正な本文でも解析、パッチ、保存、公開のいずれかで失敗できる。

真正性は入力の出所を支える。ローカルコミットはその入力を何に変えたかを支える。二つを一つのチェックにしない。

Watcher 状態の受領証

重要な利用では、次を保存する。

  • presentity、Watcher、Request-URI、購読、ダイアログ、イベントパッケージ；
  • Accept の形式、優先度、Presence Agent のローカル選択；
  • NOTIFY の Call-ID、タグ、CSeq、本文、Content-Type、ハッシュ、受信時刻；
  • 購読内版番号と期待した直前版；
  • 最終 SIP 応答コード、応答時刻、タイムアウト、再試行；
  • 解析結果と具体的な処理エラー；
  • 適用前の完全文書ハッシュとパッチ結果；
  • 再構成後のハッシュ、ローカルカウンター、保存確認；
  • 更新、フォールバック、形式変更、代替完全状態；
  • 下流公開先、ハッシュ、観測時刻；
  • 画面表示、連絡試行、配送、人またはサービスの結果。

この受領証は 200 の意味を否定しない。その意味を、観測していない段階まで膨らませないためにある。

Sources