要約

  • RFC 5264 では、完全状態から始まった publication に差分を順次適用する。更新されないまま期限切れになると、最後のパッチではなく、その publication の完全状態全体が消去される。
  • 検証可能な記録には、entity-tag の系譜、差分本文、適用前後の完全文書ハッシュ、寿命、refresh、コンポジターの確定と合成結果を結び付ける必要がある。

消えたのは最後の操作ではなかった

端末は最初に完全な presence を公開した。その後は、連絡先の優先度、活動、サービス可用性の変更だけを送った。ネットワーク上では小さな pidf-diff が並んでいた。

refresh が遅れた瞬間、コンポジターからその端末の publication 全体が消えた。最後の差分を取り消して一つ前の状態へ戻ったのではない。

この違いは障害説明を変える。「小さな変更が期限切れになった」のではなく、「小さな変更を含む一つの軟状態が、寿命を更新できずに削除された」のである。

部分という言葉は搬送方法を指す

RFC 3903 の PUBLISH は、期限を持つ event soft state を作る。RFC 5264 は、その状態を更新するたびに巨大な PIDF 全文を送る非効率を減らす。

部分公開を始める最初の本文は pidf-full であり、完全な基礎を置く。後続の変更では pidf-diff を使えるが、必要なら再び完全状態を送ってよい。受信側が管理する対象は、終始一つの publication である。

したがって、partial は永続化の粒度ではない。XML の一部だけを運んでも、寿命が付く単位まで細分化されたわけではない。

順序を決めるのは条件付き PUBLISH である

成功した PUBLISH には SIP-ETag が返る。既存状態の refresh、modify、remove は、そのタグを SIP-If-Match に入れて対象を特定する。成功すれば次のタグが返り、因果の鎖が進む。

部分 PIDF には別の version 属性もある。しかし RFC 5264 は、二つの版管理が食い違う曖昧さを避け、publication の順序には entity-tag を使う。

監査で本文だけを残すのは不十分だ。直前のタグ、条件、応答、新しいタグがなければ、どの状態に対する操作だったのか、受理されたのかを再現できない。

適用後の差分は履歴帳簿ではない

add、replace、remove は順番に完全文書へ適用される。生成された文書は、通常の完全状態と同じように composition logic へ渡される。

仕様は、コンポジターが適用済みパッチの記録を保持して巻き戻すとは定めていない。過去の姿へ戻すには、その姿を表す完全状態を新たに公開する必要がある。

ここで version control の比喩を持ち込むと誤る。差分は確定的な変換を表すが、履歴の保存、分岐、逆操作まで保証しない。

更新がないことが全状態を消す

期限の変更は、パッチ適用後の完全 publication に作用する。PUA が時間内に refresh しなければ、コンポジターはその全状態を消去しなければならない。

本文を伴わない refresh の欠落が、大きな状態変化を起こし得る。逆に、古い差分の効果は publication が更新され続ける限り残る。差分の送信日時と、現在状態の寿命は同じ軸ではない。

運用上の中心指標は「最新パッチは成功したか」だけではない。「publication の期限までに refresh が確定したか」である。

同じ presentity の他の寄与は別物である

RFC 3903 では、複数の端末が同じ資源について別々の publication を持てる。コンポジターはそれらを組み合わせ、さらに期限を持たない hard state を利用することもある。

RFC 5264 が消すのは期限切れした publication の完全状態である。別の publication や hard state まで自動的に消すという意味ではない。最終的な composite state は、残った寄与と合成方針で決まる。

「全状態消去」という表現は publication の境界内でのみ正確だ。資源全体について語るなら、残存入力と合成結果を別に確認しなければならない。

処理失敗には別の原子性がある

初期 publication に pidf-diff を使うことはできない。完全な基礎がないからである。文書処理エラーは 400 で拒否され、RFC 5261 の診断を含められる。それ以外の処理途中の失敗は 500 を返し、元のローカル状態へ戻す。

この rollback は、まだ確定していない試行を破棄する動作である。受理済み publication の後日の expiry とは違う。後者は現在の軟状態そのものを削除する。

失敗、拒否、期限切れを一つのイベント種別にまとめると、復旧判断も責任分界も誤る。

完全 publication の受領証

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

  • Request-URI、event package、発行元、presentity、publication 識別子
  • 直前の entity-tag、SIP-If-Match、返却された新タグ
  • 完全または差分の本文、バイト列、ハッシュ、受信時刻
  • 各 patch operation の順序と結果
  • 処理前後の完全文書ハッシュ
  • 要求、許可、実効の有効期間
  • refresh の期限、送信、応答、確定時刻
  • 明示的 remove または自然 expiry と削除対象
  • 他の publication と hard state の残存状況
  • composite state のハッシュと方針版
  • 下流通知、表示、自動判断、人の反応

entity-tag は条件付き遷移を証明する。コンポジターの commit はローカル状態を証明する。composite のハッシュは合成結果を証明する。それぞれの証拠を、まだ観測していない下流の結果にまで拡張してはならない。

Sources