要約

  • RFC 5367 は、最初の SUBSCRIBE に recipient-list 本文を入れて複数リソースへの購読を一つの対話から作れるようにする一方、既定の RFC 4826 文書から必要とするのは平らなリストであり、階層や entry-ref はサービスの意味にならない。
  • 最初の応答はリストサーバーが要求を扱ったことを示すが、各 URI の購読成功は示さない。構成要素の状態は rlmi+xml を理解するクライアントが NOTIFY から観測する。
  • 経営上必要なのは、原文、採用プロファイル、正規化後の集合、対話 URI、リソースごとの通知、管理能力、期限切れ、破棄を別々の受領証として残すことである。

文書の見た目は権限の境界ではない

RFC 4826 のリソースリストは表現力が高い。要素を入れ子にし、別の項目を entry-ref で参照できる。その文書を人が見ると、階層そのものが業務上の意味を持つように感じる。

RFC 5367 は同じ形式を既定として使うが、要求に含まれるリストについて必要なのは平らな集合だけである。クライアントは階層や参照を避けるべきであり、サーバーは余分な情報を捨ててもよい。

ここで失われるのは単なる装飾とは限らない。部署、優先順位、委任元といった意味を階層に込めたつもりなら、平坦化後の集合は同じファイルから生まれても別の決定対象である。

したがって監査記録には、受信したバイト列のハッシュだけでなく、どのプロファイルを適用し、何を無視し、どの URI を正規化し、最終的に何件の位置を作ったかが必要になる。文書保全と実行解釈を一つのハッシュで代用してはならない。

最初の要求だけが集合を作る

UAC は最初の SUBSCRIBE を公開されたリストリソース URI に送る。本文の少なくとも一つは disposition type recipient-list を持ち、Require には recipient-list-subscribe が入る。

同時に、クライアントは rlmi+xml を受け取れることを示す。これは設計上重要である。作成要求の本文が集合を指定し、その後の通知が集合内の状態を伝える。入力と観測には別の器が使われる。

初回要求が受理された後、対話内の後続 SUBSCRIBE は有効期間を延ばせる。しかし RFC 5367 は、そこに再びリソースリスト本文を載せた場合の意味を定義していない。クライアントは本文を送るべきでなく、受けたサーバーは 415 Unsupported Media Type で拒否する。

同じ XML が初回には作成権限を持ち、更新時には命令として読まれない。これは不統一ではない。更新権限を、集合を差し替える権限へ黙って拡張しないための位相境界である。

公開 URI と継続 URI は別の面を持つ

最初の要求先は公開リスト URI である。対話が成立した後の要求は、サーバーがその対話のために提供した URI へ送られる。

クライアントから見ると、前者は recipient-list 本文を受け入れる作成面であり、後者は既存対話を維持する継続面である。同じサービス名の下にあるからといって、交換可能なアドレスではない。

ログは公開 URI、認証主体、イベントパッケージ、リスト集合のハッシュ、Call-ID とタグ、リモートターゲット、Expires を結び付ける必要がある。これがなければ、どの作成判断から更新能力が生まれたのか説明できない。

誤った URI に送った SUBSCRIBE は構文上は正しく見える。メソッド名だけを集計するダッシュボードでは、作成面への再投入と対話面の更新を区別できない。

2xx は各リソースの成功票ではない

RFC 5367 は、SUBSCRIBE への応答コードが、リストに含まれた URI への購読に成功したかどうかを伝えないと明記する。応答の主語はトップレベル要求であり、構成要素すべてではない。

サーバーは対話を確立してから、下流の各購読について異なる結果を得ることがある。ある URI は成功し、別の URI は opt-in を欠き、さらに別の URI はまだ不明かもしれない。

その差を運ぶのが通知である。RFC 4662 のリソースリストメタ情報は、集約された対話の中でリソースごとの状態を識別する枠組みを提供する。

管理画面は「対話成立」と「構成要素の観測範囲」を分けて表示すべきである。分母は正規化後の集合で固定し、最近観測した件数、失敗、終了、不明を別々に示す。通知に現れなかった位置を分母から消すと、不明が成功に変わる。

通知にも版と鮮度が要る

一つの NOTIFY を受け取った事実だけでは、現在の完全な集合状態を証明できない。通知が完全スナップショットなのか差分なのか、版番号がどう進むのか、欠落したメッセージをどう検出するのかを実装は理解しなければならない。

各位置には、正規 URI、状態、インスタンス、版、観測時刻、終了理由を持たせる。古い通知が後から到着したとき、新しい状態を上書きしないようにする。

「不明」はエラー表示の失敗ではなく、証拠の正直な値である。ネットワーク断、認可判断の遅延、通知欠落を緑色に塗り替えるより、意思決定を止める明示的な不確実性として残す方がよい。

対話の Expires と各リソースの観測鮮度も異なる。対話が有効でも、一部の状態が古いことはある。逆に終了通知を受けても、保存系での削除が完了したとは限らない。

管理リンクは第三の能力である

最初の NOTIFY には、purpose=list-management を持つ Call-Info URI が含まれることがある。これは購読に関連するリストを操作するための入口である。

公開 URI は作成し、対話 URI は維持し、管理 URI は変更する。三つを一つの「購読 URL」として扱うと、認可範囲が見えなくなる。

リンクを表示した事実は、変更が実施された証拠ではない。管理サービスは別途、主体を認証し、対象リストへの権限を評価し、更新内容を検証し、結果を記録する必要がある。

ブラウザーの履歴や運用ノートに残った URI も能力として扱うべきである。長いランダム文字列であることは、明示的な期限、失効、監査の代わりにならない。

リストの寿命は対話に束ねられる

RFC 5367 の操作可能なリストは購読の寿命に束ねられ、購読が期限切れまたは終了したとき破棄されるべきである。これは一時的な観測集合を恒久名簿へ変えないための重要な制約である。

ただし Expires: 0 や終了イベントは、物理削除の完了通知ではない。主データ、キャッシュ、検索索引、レプリカ、監査記録では時間軸が違う。

運用契約は、対話終了、管理能力の失効、主記録の削除、派生コピーの掃除を分けて観測する必要がある。法的保持があるなら、対象、理由、期限、アクセス制限を例外として記録する。

「標準に破棄と書いてある」ことと「この実装で破棄を確認した」ことを混同しない。前者は規範、後者はランタイムの受領証である。

正当なクライアントでも対象の許可は要る

この仕組みは RFC 4662 と RFC 5363 のセキュリティ考慮事項を引き継ぐ。リストサービスはクライアントを認証・認可し、影響を受ける対象について opt-in を守る。

呼び出し主体が正当であることは、各 URI がそのイベントパッケージ、目的、期間の観測に同意したことを意味しない。主体の資格と対象の許可は別の関係である。

認可判断は、主体、サービス、イベント、正規 URI、目的、期間、ポリシー版を結ぶべきである。単一の「管理者」ロールで任意のリストを許すと、集約効率が大量観測の近道になる。

拒否や省略にも理由コードが必要である。そうでなければ、プライバシー保護、存在秘匿、経路障害、未試行を同じ空白として扱ってしまう。

登録名は実行結果を証明しない

IANA の SIP パラメーター登録には recipient-list-subscribe と list-management がある。相互運用のための語彙として重要だが、個別リソースの購読成功やリンクの現在権限を証明するものではない。

RFC 5367 は 2008 年 10 月に Standards Track として公開され、NOTIFY における Call-Info の利用に関連して RFC 3265 を更新した。RFC 3265 は後に RFC 6665 に置き換えられた。現在の実装はこの履歴を読みつつ、RFC 5367 の位相分離を保つ必要がある。

Lu Heng の Minimum Initial Specification は、初期合意を必要最小限に限定し、将来の判断を局所知識を持つ主体に残すという観点を与える。更新本文に未定義の変更意味を足さない RFC 5367 の選択は、その節度を具体化している。

Reality Layers の視点では、文書、URI、応答、通知、タイマーは、それぞれ別の現実を指す記号である。接続の受領証なしに強い事実へ昇格させてはならない。プロトコル上の事実は RFC と IANA を根拠とする。