要約

  • RFC 3968 は、RFC 3261 に欠けていた SIP ヘッダーフィールドのパラメーターと値の IANA レジストリを作り、名称をフィールドと定義文書に結び付けた。
  • 登録行は名前の帰属を示す索引であり、端末の実装、値の理解、取引時の受諾、安全性、通話結果を証明するものではなかった。

一覧表の一行は完全な仕様に見えやすい。名前があり、Yes または No があり、RFC 番号がある。しかし RFC 3968 の設計では、その行は終点ではなく入口だった。

RFC 3261 は新しい SIP ヘッダーフィールドのパラメーターと値を定義できるようにしたが、対応する IANA レジストリを用意しなかった。2004 年の RFC 3968 はこの欠落を埋めた。登録には、対象フィールド、パラメーター名、定義済み値だけを受け入れるかどうか、そして意味を記した RFC が必要だった。

目的は、独立した実装の相互運用と偶発的な名前衝突の防止である。RFC は構文、用途、意味を説明しなければならなかった。これにより、誰がどの意味を公共の名前空間へ持ち込んだかを追跡できるようになった。ただし、その名前を端末が実装したことにはならない。

Yes は値集合そのものではなかった

定義済み値を持つパラメーターごとに別レジストリを作れば、サブレジストリが増え続ける。RFC 3968 は代わりに、値を参照によって登録した。元の RFC と、新しい値を追加した後続 RFC を行に並べ、追加文書を二重角括弧で示した。

したがって Yes は「この行だけで列挙を完了できる」という印ではない。「許容値を参照文書から回収せよ」という分岐である。実装者は全ての適用可能な RFC を読み、構文、条件、意味、安全上の注意を合わせなければならない。

レジストリの古いコピーをコード生成へ使うと、見た目は公式でも後から追加された値を拒否する可能性がある。参照を削った表はさらに危険だ。権威の外観を残したまま、その根拠だけを失うからである。

名前の同一性には場所が含まれた

RFC 3968 は、異なるヘッダーフィールドなら同じパラメーター名を許した。同じフィールドの中では重複を許さなかった。つまり文字列だけでは登録対象を特定できない。ヘッダーフィールドが名前の一部だった。

観測ログが q や algorithm だけを保存すれば、正しい文字列を誤った意味へ接続し得る。フィールド、名前、参照集合、観測時刻を一緒に残して初めて、後から同じ対象を復元できる。

登録済みの語は予約語となり、定義 RFC と一貫した方法で使う必要があった。ローカルな定義が衝突してはならない。一方、未登録パラメーターそのものは禁止されなかった。将来、同じ名前が別用途で登録される保証がないため、利用は危険だとされた。

閉域での成功は、その時点の共有知識を示す。公共の名前を予約した証拠ではない。逆に公共登録は、古い端末が機能を導入した証拠ではない。

能力の証拠は取引から出た

RFC 3261 には Supported、Require、Proxy-Require、Unsupported、420 応答があった。端末は拡張対応を表明し、相手に必須対応を求め、理解できない要求を返答できた。これは具体的な端末と取引から生まれる証拠である。

IANA 登録はその交換を代行しない。ソフトウェア版、機能の有効化、ポリシー、認可、通話結果を記録しない。対応表明があっても、個別要求の受諾や最終結果は別である。

RFC 3261 は、理解できないヘッダーフィールドが要求処理に必須でなければ、無視して処理を続けるよう求めた。メッセージが通過した事実は二通りに読める。機能が正しく処理されたかもしれないし、何も理解されずに無視されたかもしれない。

接頭辞は状態を保存できなかった

RFC 3427 は SIP 拡張が複雑性や安全性を損なう懸念から、予備的、私的、独自の P- ヘッダーを管理する仕組みを設けた。しかし RFC 5727 は、一部の P- ヘッダーが想定範囲外へ普及し、導入後の改名も現実的でなくなったと記録した。接頭辞は配備範囲を拘束できなかった。

RFC 6648 はこの経験を一般化し、X- の有無だけから標準性や安全性を推定してはならないとした。状態は綴りではなく、明示的な登録情報と文書に置く必要がある。

当時の登録例も一様ではない。RFC 3310 の認証、RFC 3265 のイベント、RFC 3455 の私設網向け拡張、RFC 3329 のセキュリティ合意は、同じ列に入っても異なる作用とリスクを持つ。表形式は探索方法を統一しただけである。

登録方針は RFC 2434 の IETF Consensus だった。RFC 8126 は後に、登録を名前空間の値と目的の結合として整理した。この結合は公共の意味を与えるが、端末に処理を命じない。

現在の IANA SIP Parameters は多数のサブレジストリを持つ生きた索引である。RFC Editor の記録、正誤表、IETF Datatracker は文書状態を示すが、実装率や安全効果は測定しない。

RFC 3968 は名前の出所を検証可能にした。その先の理解と行為は、端末自身の証拠を待たなければならない。

出典