要約

  • RFC 5363 は、一つの SIP 要求に URI リストを含めるか外部リストを参照させ、サービスが複数の宛先へ類似要求を生成する枠組みを定めた。入力が一件でも、識別、権限、実行、結果は宛先ごとに存在する。
  • クライアントは URI を重複させるべきではなく、受信側は文字列一致ではなく URI スキーム固有の比較規則で重複を一件として扱う必要がある。ただし RFC 5364 のコピー制御のような操作属性が異なる場合、宛先の重複排除だけでは意味の衝突を解決できない。
  • 経営上必要なのは、原文、外部版、正規化規則、同一性判定、属性衝突、受信者許可、出力予算、下流操作、個別結果を結ぶ証拠鎖である。件数だけを合わせても、正しい相手に正しい行為を一度だけ行った証明にはならない。

同じ相手を二度数えた瞬間

URI リストサービスの魅力は、呼び出し側が一回のトランザクションで複数宛先への処理を依頼できることにある。RFC 5363 は、リストを要求本文に含める方法と、保存された外部リストを参照する方法の双方を想定する。サービスはリストを展開し、各宛先へ要求を生成する。

この設計では、リストが単なる表示用データではない。リストは実行計画の入力である。何件あるか、誰が含まれるか、何回要求を作るか、どの許可を確認するかが、その解釈によって変わる。

RFC 5363 はクライアントに重複を避けるよう求め、受信側には重複 URI を一件として扱うよう求める。重要なのは「重複」が生の文字列一致ではない点だ。URI スキームの比較規則を使うため、表記が異なっても同一と判断される場合がある。

ここで最初の証拠境界が現れる。原文の行数は宛先数ではない。正規化後の宛先数も操作数とは限らない。サービスは、識別子を一つにまとめた理由と、その識別子に対してどの操作を残したかを別々に記録しなければならない。

文字列比較は簡単だが誤った安心を生む

単純な実装は、文字列を小文字化し、空白を除き、完全一致で重複を消すかもしれない。しかし URI の等価性はスキームによって異なる。意味のある構成要素を無視すれば別の宛先を潰し、表記上の差だけを残せば同じ宛先へ二回送る。

重複送信の影響は、単なるメトリクス誤差ではない。受信者は二つの通知を受け、アプリケーションは二つの副作用を起こし、再試行ロジックは二つの取引を追うことになる。逆に過剰な統合は、本来必要な操作を欠落させる。

正規化ロジックはバージョン管理された実行規則であるべきだ。どの URI スキームにどの比較関数を使い、どの要素を保持し、衝突時にどう処理したかを記録する。ライブラリの更新で挙動が変われば、同じ入力が違う出力集合を生み得るため、運用変更として扱う必要がある。

テストも例示的な二、三件では足りない。大小文字、エスケープ、既定値、パラメータ、表示名など、スキームが意味を定める境界を含む対照ケースが要る。正規化が「動く」だけでなく、同一性の定義と一致することを確かめる。

コピー制御は同一性の上に別の意味を置いた

RFC 5364 は、URI リストを使う要求にコピー制御の意味を加える。これにより、同じ受信者を指すエントリーが異なる属性を持つ可能性が生まれる。

受信者が同一だからといって、属性の一方を任意に捨てることはできない。二回送ることもできない。RFC 5363 は重複要求を避ける方向を示しているからだ。サービスは、衝突する意図をどう解決するかを仕様として持つ必要がある。

選択肢は、要求全体を拒否する、明示的な優先規則を適用する、または意味を保つ形で一つの操作に統合することだろう。どの選択でも、結果を監査できなければならない。黙った上書きは最も危険である。呼び出し側には受理に見え、受信者には予想外の扱いとなる。

ここから一般則が得られる。識別子の同一性は「誰か」を決める。操作属性は「何をするか」を決める。両者を一つの重複フラグへ圧縮すると、権限判断も結果判断も曖昧になる。

複数の本文部分は一つの集合へ合流した

RFC 5363 は recipient-list という Content-Disposition 値を定義し、IANA の SIP パラメータ登録簿にも記録されている。一つの要求に複数のリスト本文があれば、受信側はそれらを一つのリストに結合する。

各部分が個別に妥当でも、結合結果が妥当とは限らない。異なる部分に同じ URI が入り得る。異なる署名者や生成時刻を持つ場合もある。外部リストの参照と内包リストが混在すれば、出所も時間も一様ではない。

監査記録は各部分のハッシュ、保護範囲、由来、結合順序、正規化前の統合列、最終集合を残すべきだ。最終件数だけでは、一つの受信者がどの入力から入ったのか、どの許可根拠を使ったのかを追えない。

リストの完全性は、ファイルが壊れていないという意味だけではない。実行した集合が、権限を与えられた入力から決定論的に導出されたという意味でなければならない。

外部リストは同じ参照で別の人々を返し得た

RFC 4825 と RFC 4826 は XCAP とリソースリストの用途を記述する。保存リストは再利用と一元管理に適している。一方、参照と内容を分離するため、時間が同一性に加わる。

呼び出し側が確認した時点では五人だったリストが、サービスの取得時には六人かもしれない。同じ URL を再試行しても、以前とは別の集合になるかもしれない。参照文字列が同じでも、実行対象の同一性は証明されない。

必要なのは版の収穫証だ。エンティティタグ、改訂番号、内容ハッシュ、または不変スナップショットを、上流要求と結び付ける。最新版を使う設計なら、その意味を明示し、取得後の集合に対して許可と予算を再評価する。

外部リストと要求内リストには同等の安全性が必要だ。保存場所を変えたことが、由来、完全性、機密性を弱める理由にはならない。

認証済みの呼び出し側は受信者の代理人ではなかった

RFC 5363 は、下流要求を送る前に呼び出し側を認証し、権限を確認するよう求める。しかし正規の利用者でも攻撃や誤操作は可能である。そこで受信者の許可が別に必要になる。

しかも規則は全件一括だ。一件でも必要な許可がなければ、リストの誰にも送ってはならない。許可済みの項目だけを先に流す実装は、依頼された集合を勝手に変更し、後から拒否が見つかっても取り消せない。

許可は相手だけでなく、サービス、方法、代理する呼び出し側、期間などの範囲を持つ。メッセージ受信への同意を会議招待へ流用してはならない。RFC 5360 は関連する同意の仕組みを示すが、ここでの焦点は、リストサービスが正確な集合に対する出力権限を送信前に証明できるかどうかである。

正規化と許可の順序も重要だ。同じ受信者を二回数えた状態で二つの許可記録を要求するのは意味がない。一方、属性衝突を解決する前に許可を見ると、実際に行う操作と異なる範囲を照合しかねない。

一回の入力は出力コストを一回にしなかった

一つの要求が多数の SIP または非 SIP 操作を生成できるため、RFC 5363 は増幅型のサービス拒否を警戒する。サービスは URI 数の上限を設けられる。

ただし正規集合の件数はコストの一部にすぎない。方法、本文量、経路、同時実行数、タイムアウト、再試行、アプリケーション副作用、結果通知の量が実負荷を決める。認証済み利用者にも無制限の増幅権はない。

予算は正規化と属性解決の後、送信前に計算する。そうでなければ重複で過大計上したり、外部リストの拡大を見逃したりする。権限と予算は独立であり、安い無許可操作も、高価な許可済み操作も止める理由がある。

出力予算の記録には、対象数だけでなく、予測取引数、最大再試行、同時実行、方法別単価と実消費を含めるべきだ。事故時に入力バイト数だけを見ても、なぜ負荷が増えたか説明できない。

リストの意味はサービスが与えた

RFC 5363 は URI リストの意味をアプリケーションとサービスに委ねる。単純な送信だけでなく、会議ミキシングのようなアプリケーションサーバー動作も想定する。RFC 5364 から RFC 5368 が個別用途を展開し、RFC 4575 と RFC 4662 も会議状態やリソースリスト通知の異なる集約モデルを示す。

したがって、同じ正規集合でも別のサービスでは別の権限が必要で、成功の意味も異なる。メッセージの受理、招待の受理、会議への参加、購読状態の成立を一つの「成功」で表すことはできない。

基礎枠組みが結果報告の方法をサービス仕様に残したのは、この差を保つためである。実装者は曖昧な共通フラグを作るのではなく、方法ごとの終局性、未知、再試行可能性を定義しなければならない。

結果表は正規集合と同じ数の席を持つ

RFC 5363 は呼び出し側が結果を知れることを求める。結果機構が個別仕様に委ねられていても、証拠の基数は失われない。

正規集合に九人いれば、結果表には九つの位置が要る。送信前に全体拒否されたなら、九位置すべてが同じ門前状態を共有してもよい。送信後に分岐したなら、成功、拒否、失敗、保留、未知を個別に保つ。

集約はそれらから計算する。「一部完了」という表示だけでは再試行対象を決められない。全体を再実行すれば完了済みの操作を重複させる。特定項目だけを再実行するには、意図した操作と各試行の識別子を分けて持つ必要がある。

プロトコル応答が受理だけを示す場合、利用者が実際に経験した効果は別の観測になる。内部の緑表示が外部結果を代弁してはならない。

十二の収穫証が一度だけ正しく行う条件を作る

必要な鎖は、呼び出し側の認証、サービスと負荷の認可、正確なリスト版、正規集合、全受信者の許可、送信前の一括門、増幅予算、方法固有の意味、各宛先の下流操作、各操作の終局または限定された未知、欠落を隠さない集約、必要な外部結果観測である。

前段の緑は後段を代替しない。署名済みリストは許可済みリストではない。許可済みリストは送信済みリストではない。送信済みリストは成功済みリストではない。

同一性と操作意味を分けることで、障害の場所も明確になる。予期せぬ宛先なら出所と正規化を見る。二重作用なら重複処理と試行識別を見る。欠落なら属性衝突と結果基数を見る。認証ログ一行ですべてを説明しようとしない。

登録簿は語彙を統一しただけだった

IANA の SIP パラメータ登録簿にある recipient-list は、実装間で使うトークンを共通化する。現在の普及、実装準拠、許可、配信、効果を証明するものではない。

RFC 5363 は 2008 年 10 月に公開された Standards Track 文書である。この地位と運用実態は別の証拠層にある。

Lu Heng の「最小初期仕様」の論考は、共通層を小さくし、将来の判断を局所的な情報の持ち主に残すという後年の分析視角を与える。リストの表現と基礎要件は共有できるが、サービスの意味、許可範囲、結果の終局性は局所判断である。

「現実の層」に関する論考は、識別子と状態表示を実際の行為や結果と混同しない視角を与える。SIP の技術的事実は RFC と IANA が担い、論考は明示された分析枠として用いる。