要約

  • IANA の現在行は現在の名前割当と参照先を示すが、古い送受信者がその意味を実装していた証拠ではない。
  • レジストリ時点、仕様、URI 検証、受信能力、方針、シグナリング、身元、結果を分離する必要がある。

生きたレジストリには時計が要る

障害調査で古い tel URI を見つけ、現在の IANA 表を照会するとパラメータ名が存在する。分析者は「標準項目だから当時のゲートウェイも理解した」と結論する。しかし、その行は後年に追加されたかもしれない。

RFC 5341 は初期表を設け、後続の登録を可能にした。現在の表には当初の項目に加え premium-rate や verstat などがある。変化はレジストリの役割であり、過去実装への遡及配備ではない。

監査は取得時刻、表の内容、参照仕様のハッシュ、解析器バージョンを一緒に保存すべきだ。そうしなければ、現在の語彙が過去の能力を捏造する。

登録行は仕様への索引である

新パラメータは名前、定義済み値の有無、恒久的な公開仕様を提出する。既存パラメータの新しい値にも参照が要る。これにより名称衝突を防ぎ、意味の責任者を示す。

行そのものは具体的 URI を検証しない。Constrained の詳細は参照文書にあり、合法な値の形式や比較規則を読まねばならない。登録された名前に不正値を付けても適合にはならない。

No Value も無意味ではない。フラグ、または定義済み集合を持たない形式を示す。enumdi や npdi の存在は処理上の主張であり、送信者の信頼性や事実の鮮度を自動的に証明しない。

番号名とダイヤル動作は別である

RFC 3966 の tel URI は電話番号で識別される資源の名前である。到達手順、ダイヤル方式、単一の物理端末を意味しない。端末やシグナリングがローカル規則を適用する。

音声、FAX、データの種別も URI 単独では決まらない。登録パラメータが揃っていても、メディア交渉や接続完了は別の証跡である。

ローカル番号の phone-context は一意性の範囲を示すが、双方の設定一致、番号所有、経路存在を証明しない。範囲宣言と運用合意を同じものにしてはならない。

未知の必須項目は能力不足を示す

RFC 3966 では、必須パラメータを理解できない受信者は URI を使用してはならない。したがって IANA 登録と実装能力は別である。新しい登録を旧装置が自動的に解釈することはない。

ログには認識、必須性、検証、無視または拒否、使用した仕様版を残す。「IANA にあった」という一件だけでは、正しい拒否と危険な無視を区別できない。

また RFC 5341 はパラメータがなくても基本サービスが通常動作することを求める。ある製品が拡張を必須化するなら、それはローカル契約であり、登録制度の命令ではない。

運用パラメータは自己証明しない

RFC 4694 の携帯番号移植関連パラメータ、RFC 4904 のトランクグループ関連パラメータは、登録された語彙で運用情報を伝える。行があるからといって、ルーティング番号が最新、事業者コードが認可済み、トランクが稼働中とは限らない。

RFC 4759 の enumdi も処理履歴を表すフラグであり、ENUM 問合せ実行を暗号学的に証明しない。isub-encoding の登録も受信側実装を保証しない。発行者、信頼境界、時刻、検証、消費決定が必要である。

情報源と証拠の限界

以下は仕様、文書履歴、IANA 表の時点を裏付ける。現在の通話、番号所有者、発信者、製品、導入、経路、料金、検証結果を示さない。