要約

  • RFC 5196は、連絡前の選択を助けるため、PIDFにサービスとデバイスの能力を表す拡張を加える。ただし、その情報はヒントであり、SDPなどのメディア交渉を置き換えない。
  • 対応、非対応、非開示、期限切れ、複数ソースの衝突を別々に残し、watcher向けの表示と実際の招待・offer/answer・媒体結果を別の証跡として扱う必要がある。

矛盾を消すと説明可能性も消える

RFC 5196の構造には、明示的な肯定を置く supported と、明示的な否定を置く notsupported がある。不要な否定を網羅的に並べることは推奨されない。同じ値が両方に現れた場合、watcherは対応しているとみなしてよい、という解決も示されている。

ここで重要なのは、仕様が衝突の存在を隠していないことだ。解決規則は読み手を前に進めるが、二つの入力を一つの無履歴な真実へ変える許可ではない。どの発行元が肯定し、どの発行元が否定したか、サービスとデバイスのどちらを指したか、いつ発行され、いつ失効するかは、調査時に必要になる。

片方だけを保存するクライアントは、RFCの値を読んでいてもRFCの意味を運んでいない。障害後に「文書には非対応とあった」と説明しても、対応側を捨てた事実は説明できない。逆に肯定だけを採用すれば、実際には使えない機能を約束することになる。

書かれていないことは否定ではない

三つ目の状態が非開示である。presentityは実際の能力を公開しない選択ができる。RFCは、音声に対応していても利用者がその事実を公表したくない例を挙げる。認可規則やプレゼンスサーバも、watcherごとに情報を制限・変更できる。

したがって、欠落を notsupported に正規化する処理は、技術判断だけでなくアクセス制御の書き換えでもある。別のwatcher向けに作られたビューを再利用すれば、非開示の文脈まで失われる。保存すべき主語は「このデバイスの能力」ではなく、「この購読と認可の下で、このwatcherに見えた能力」である。

不完全または誤った存在情報によって、本来可能な通信を不可能と判断したり、逆に失敗する能力を試したりし得ることをRFCは述べる。watcherは、表示と実能力が完全に一致すると期待してはならない。

URIの先にいるサービスを知るための拡張

基本のPIDFでは、contact URIだけからtupleが音声、映像、メッセージング、その他のどれを表すか分からない場合がある。RFC 5196はRFC 3840の能力表現を利用し、RFC 4479の人・サービス・デバイスモデルに沿ってサービス能力とデバイス能力を表現する。連絡前の選択は確かに良くなる。

しかし、良い予測は成立済みの交渉ではない。RFCの適用範囲は、好み、意思、能力についての事前ヒントを与えるとし、SDPのようなSIPメディア交渉を置き換えないと明記する。存在情報は試行先を推薦できる。実際のSIP応答とSDP offer/answerだけが、そのセッションで何が合意されたかを示す。

時間差もある。発行後に端末が切り替わり、ソフトウェアが再起動し、利用者の意思が変わる。キャッシュに残った正しい過去の値は、現在の接続に対しては誤った未来予測になり得る。そこに形式上の破損はない。

サービスの能力を全端末へ配らない

人・サービス・デバイスの区別は、集約時に崩れやすい。あるサービスが映像を扱えるからといって、presentityに紐づく全デバイスが映像を扱えるわけではない。一台の端末が特定言語のコンテンツを処理できても、その言語を話す人が現在応答可能だとは限らない。

複数の発行元を単純に和集合にすれば、現実には存在しない万能端末が生まれる。積集合なら、応答予定の端末が持つ有効な機能を隠す。「最新優先」も、比較する主体と時計が同じでなければ意味を持たない。RFCが指摘する複数ソース結合の情報損失と不一致は、実装上の端点ではなく、設計すべき制御面である。

値ごとに発行エージェント、対象、版、発行・失効時刻、認可範囲を残す。合成時は入力集合、競合規則、出力の由来を保存する。watcherが受け取った文書自体にもハッシュと受領時刻が要る。

交渉までを一つの線にしない

次に別の証跡を開始する。どの可視値が招待判断に影響したか、どのURIを選んだか、どの端末が応答したか、SIP要求と応答、SDPのofferとanswer、交渉された媒体、利用者の意思、実際の結果を記録する。プレゼンス側の鎖とセッション側の鎖は参照で結ぶが、同じ状態欄に上書きしない。

これはRFC 5196へ新しいワイヤ要件を追加する提案ではない。運用の説明責任を保つ最小受領書である。Heng Luの現実層の原則に従えば、表示は稼働系の現実に従属する。事前ヒントに交渉結果の権威を与えなければ、プレゼンスは軽量な選択支援として長く役に立つ。

Sources

  1. RFC 5196 HTML
  2. RFC 5196 テキスト
  3. RFC 5196 情報ページ
  4. IETF Datatracker：RFC 5196
  5. RFC 5196 履歴
  6. RFC 5196 参照関係
  7. RFC 5196 正誤表
  8. RFC 3840
  9. RFC 3863
  10. RFC 4479
  11. RFC 3859
  12. RFC 4566
  13. RFC 3261
  14. RFC 2778
  15. RFC 3856
  16. RFC 3903
  17. RFC 5025
  18. Heng Lu：現実の層と象徴的権力
  19. Heng Lu：最小初期仕様
  20. Heng Lu：稼働コードの優先