要約

  • RFC 3407 の能力集合は、端末が現在利用可能で相手との利用を望む形式を宣言したが、どれを使うかは決めなかった。
  • 宣言、offer/answer による選択、実媒体の成功は別々の証拠であり、一つ前の段階から次を推定してはならなかった。

初期 SDP の媒体行は二つの役割を抱えた。実際のセッション構成を記述する一方、装置が扱える代替 codec の一覧にもなった。複数形式を並べると、すべてを同時に提供する約束に見える。しかし DSP の記憶容量や演算能力は、各形式を別々に扱えても、全組合せを同時には支えられないことがあった。

RFC 3407 は全面的な交渉方式を作らず、小さな宣言層を追加した。未知の属性を無視する既存 SDP 実装との互換性を保ちながら、実構成の外側に可能性を置いた。能力記述は使用候補を示すだけで、選択しない。実際に使うには RFC 3264 など別の手続きが必要だった。

文書は最も危険な推論を明示的に禁じた。ある形式が集合に含まれていても、その形式だけを使う後続交渉が成功するとは限らない。相手の選択、資源変化、形式の組合せ、付随パラメータが未確定だからである。能力は試行の根拠であり、成功証明ではない。

集合には鮮度の境界もあった。一つのシーケンス番号が完全な集合を覆い、新しい集合を受け取ると古い集合は失効した。番号はゼロから始まり 256 で循環する。受信側は途中の集合を見逃し得るため、番号の飛びだけで拒否してはならない。これは宣言の世代を示す印であって、欠損のない配送履歴ではなかった。

配置は適用範囲を決めた。セッションレベルの能力は、指定媒体型の各ストリームに適用された。媒体レベルの能力は、宣言する型が違っても、関連付けられた一つの媒体行だけに属した。該当型のストリームがないセッションレベル宣言は、ストリームが一つだけの場合を除いて対象が未定義だった。

形式名だけでも足りない。cpar は形式パラメータや帯域条件を添え、最小値と最大値は一つの数値範囲を示した。この条件を無視した交渉が失敗しても、元の宣言が虚偽だったとは限らない。条件を落とした側が証拠を薄くしていた。

能力番号は現在の集合内で使う局所的なハンドルだった。番号の欠落も拒否理由ではない。外部手続きが特定候補を指すために利用できたが、RFC 3407 自身はその指示を合意に変換しなかった。

安全に関わる能力の再交渉では、認証なしの変更がダウングレードやサービス拒否につながり得た。弱い選択肢が本当に利用可能であることと、その選択を攻撃者に許してよいことは別問題だった。

RFC 5939 は後に、能力、候補構成、実構成、offer/answer 手続きをまとめた広い枠組みを提供した。新実装にはそちらを推奨し、旧実装との互換性が必要なら双方の宣言を同梱できた。ただし RFC 3407 を正式には廃止せず、新しい交渉手続きも旧記述を利用しなかった。並存は意味の統合ではない。

この境界は現在の機能発見にも残る。製品が対応を表明したこと、二者がその機能を選んだこと、実行時に成功したことは、同じ事実ではない。可能性を決定に昇格させない記録設計が必要である。

出典