要約

  • RFC 3969 は、一つの綴りが SIP と SIPS で異なる意味を持つのを防ぐため、すべての URI パラメーター名を両方式に予約した。予約は両方への適用を証明しない。
  • 本文は「Specification Required」と書きながら Standards Track RFC を要求した。RFC 5727 はこれを矛盾と認定し、意図された方針が Standards Action だったと明確化した。

RFC 3969 の表を横から見ると、同じ名前が SIP と SIPS の二つの欄を占めているように見える。普通なら、二つの欄は二つの機能を示すと思うだろう。しかし文書は、あるパラメーターが片方の方式には適用されない場合があると明記した。二つ目の欄は実装証明ではなく、別の意味を入れさせないための空間だった。

この設計が必要になったのは、RFC 3261 が新しい SIP/SIPS URI パラメーターと値を許した一方、IANA レジストリを作らなかったからだ。独立した拡張の設計者が同じ短い名前を選び、構文上は正しいまま異なる意味で処理する危険が残った。RFC 3969 は 2004 年 12 月、その命名面を補修した。

七つの初期名と二つの予約枠

最初の表には comp、lr、maddr、method、transport、ttl、user が載った。comp は RFC 3486 を参照し、残る初期項目は RFC 3261 を参照した。行には名前、値集合が事前定義かどうか、そして定義文書が保存された。

重要なのは、同じ名前を双方に登録する理由である。SIP で使われた名前が SIPS では空いていると扱われれば、後の仕様が別の意味を与えられる。ログや設定、解析器に同じ文字列が現れても、意味を一意に復元できなくなる。両方を予約すれば、適用されない側でも別用途への再割り当てだけは阻止できる。

したがって「SIP/SIPS に登録済み」という表示から、両方で動くと結論してはいけない。観測記録には方式、名前、時刻、参照集合が必要だ。RFC 5630 は後に SIPS URI の扱いとセキュリティ上の期待を明確化し、RFC 3263 はサーバー探索とトランスポート選択を説明した。それらの実行条件は予約行には入っていない。

RFC 3969 は登録された名前と値を予約語とした。未登録のローカル名も使えたが、将来の公開登録と衝突する恐れがある。ベンダー拡張用の木も設けなかった。RFC 3427 が、SIP 拡張は複雑性を増しセキュリティを損ね得ると警告していたため、公開登録には構文、用途、意味を説明する RFC を要求したのである。

Predefined Values: Yes も値一覧そのものではない。RFC 3969 は値を参照によって登録し、実装者にすべての引用文書を読ませた。現在の IANA SIP Parameters では transport が RFC 3261 と RFC 7118 を参照する。古い表の複写は歴史資料として正しくても、現在の解析器仕様としては不足し得る。

方針名と実際の要件が食い違った

命名の境界を整えた文書自身にも、方針の境界にずれがあった。4.2 節は RFC 2434 の用語で「Specification Required」とした直後、登録対象は Standards Track RFC で定義されなければならないと書いた。この二つは審査者も承認経路も違う。

RFC 5727 は 2010 年、この矛盾が登録方針カテゴリーへの誤解から生じ、意図は Standards Action だったと明記した。現在の IANA レジストリも Standards Action を表示する。RFC 8126 の新しい方針体系で見れば、ラベルは単なる説明ではなく、誰が何を根拠に割り当てを承認できるかを定める制御面だと分かる。

現在値だけを保存すれば、2004 年の食い違いと 2010 年の修正理由が消える。逆に原文だけを読めば、現行規則を誤る。RFC Editor の記録、errata 検索、IETF Datatracker は、状態、報告済み訂正、文書履歴という別々の証拠を提供する。RFC 3986 は URI の一般構造を与え、RFC 6648 は後に名前の接頭辞から標準性や安全性を推測しない原則を示した。

実際のパラメーターを調べる順序は明快だ。まず方式と綴りを正確に保存する。観測時点の行を探し、全参照をたどって適用性とセキュリティ条件を読む。その後にソフトウェア版、設定、トランザクション処理、最終結果を確認する。通話成功はパラメーターが作用した証明ではなく、登録は端末が理解した証明ではない。

RFC 3969 は二つの枠を使って一つの意味を守った。広く予約し、狭く推論する。その非対称性こそが、レジストリを能力表に変えないための要点である。

情報源