要約

  • RFC 3966 は、見た目の区切り記号、文字の大小、パラメーターの記載順を越えて tel URI を比較した一方、ローカル／グローバルの別、文脈、全パラメーター名を意味のある差として残した。
  • URI が等価でも、番号の現行割当、到達性、同じ経路、同じ人物や端末、利用者の同意、通話成立までは導けない。

電話番号は機械のキーである前に、人が読む記号でもある。桁を括弧やハイフンで区切り、地域ごとに慣れた形で書く。原文一致だけに頼れば、単なる表示差を別物と誤認する。だからといって数字以外を全部捨てれば、異なる番号空間まで重ねてしまう。2004 年 12 月の RFC 3966 は、何を捨て、何を残すかを比較規則として明文化した。

そこで扱われる tel URI は、電話番号で識別されるリソースの名前である。外線発信番号、国際発信接頭辞、トーンかパルスか、呼出音の解釈、発信後の入力といった手順書ではない。特定の物理端末を指すとも限らず、固定、携帯、移動可能な終端や、音声、データ、ファクスなど複数のサービスに結び付き得る。

先行する RFC 2806 には、通信事業者の選択、ダイヤル文脈の動作、ファクス／モデム形式、休止や発信後文字列まで含まれていた。RFC 3966 はそれらを外し、識別子とローカルな動作を分けた。動作を含む phone string の別系譜は RFC 3601 に見えるが、ここでの等価関係とは役割が違う。

同じと判断するために、あえて消すもの

番号部分の 、.、(、) は視認性のための区切りなので、比較時には除かれる。比較は大文字小文字を区別せず、パラメーターは書かれた順番ではなく名前で対応させる。従って二つの文字列が別でも、二つのグローバル番号 URI、または二つのローカル番号 URI は等価になり得る。

消去は無制限ではない。一方がグローバル形式でもう一方がローカル形式なら、実際に同じ宛先へ届きそうでも、このアルゴリズムでは等しくない。一方だけに存在するパラメーター名があれば不一致である。ローカル番号の phone-context、内線を示す ext、ISDN サブアドレスの isub、追加された必須パラメーターは、外観ではなく意味を担う。

構文は安定した表現順も勧めている。isub または ext を最初に、次に phone-context、残りを辞書順に置く。文字単位で扱う周辺システムには有用だが、意味上の比較は受信時の順序にかかわらず名前で行う。標準的な出力形式と、二つの入力が等価かという判断は別の管理面である。

RFC 3986 は URI 全般の枠組みを示し、RFC 3261 は SIP 内の電話加入者構文を通じて、周辺処理が文字列に敏感になり得る場所を示す。監査可能な実装なら、元のオクテット列、解析結果、正規化の各操作、正規表現を別々に保存する。最後の文字列で最初の証拠を上書きしてはならない。

phone-context は名前空間であって、経路ではない

仕様はグローバル番号形式を優先する。しかし PBX の内線、緊急番号、そのほかのローカルサービス番号は世界番号にできないことがある。そこでローカル番号には、管理されたドメイン名または有効なグローバル番号の先頭桁を phone-context として必須にした。ローカル桁と文脈の組を世界で一意にするためである。

この組合せは連結命令ではない。911 と +1 の文脈を足して +1-911 にするわけではない。ドメイン文脈もホストへ解決する必要はなく、その番号空間を管理する主体の管理下にあればよい。従って文脈の一致から、DNS ゲートウェイ、利用可能な経路、現在の番号割当、発信権限は得られない。

識別だけを行う受信者は文脈を不透明値として扱える。一方、実際に電話をかける受信者は文脈を理解し、その環境で動作できなければならない。グローバル番号でさえ古い場合や、ある場所から到達不能な場合があると仕様は指摘する。名前の一致と行動可能性には、別の受領証が必要だ。

等価でも、理解できなければ使えない

ext は非 ISDN PBX 配下の内線を、isub は ISDN サブアドレスを表し、同時には使えない。RFC 4715 は後に ISDN サブアドレスの符号化を精緻化した。RFC 4694、RFC 4759、RFC 4904 には番号ポータビリティ、ENUM dip、トランクグループに関する後続パラメーターの履歴がある。

RFC 3966 は将来の必須拡張に m- 接頭辞も予約した。実装が未知の m- パラメーターに遭遇した場合、その URI を使用してはならない。任意パラメーターを無視できることとは対照的である。二つの URI が同じ未知必須パラメーターを含み、構造上は対応していても、それを理解しない受信者に実行権限は生まれない。等価性、構文妥当性、能力、権限は一つの真偽値ではない。

後の RFC 5341 は tel URI パラメーターの登録手続きを定め、現在の IANA tel URI Parameters レジストリ は調整済みの語彙を公開する。登録済みという事実は、その値が正しいこと、現在も有効なこと、送信者が主張する権限を持つこと、受信側が実装済みであることを保証しない。

電話リソースを人間の身元へ拡張しない

呼設定の途中で、一つの tel URI が複数の別 URI に変換されることがある。信号処理はサービス種別を交渉し、一つの終端に複数の識別子があり、一つの番号の先に複数の端末や人が存在し得る。RFC 6116 は E.164 番号から ENUM を通じてサービスと URI を得る仕組みを後に記した。それは検索時点と応答レコードという追加証拠であり、RFC 3966 の比較結果を本人確認へ変えるものではない。

安全上の制約も同じ線を引く。ウェブページの tel リンクから自動的に発信してはならず、明示的な利用者同意が要る。料金、回線占有、発信者情報の漏えい、悪意ある呼出しが起こり得るからだ。画面に見える番号と実際のリンク先が違うことさえある。二つの解析済み宛先が等価でも、表示の誠実さや同意は証明されない。

RFC Editor の情報ページ、正誤表検索、IETF Datatracker は仕様の状態と報告済み訂正を確認する資料であって、普及率や障害件数、通話結果の統計ではない。運用証拠には、原文と表示、ローカル／グローバル形式、区切り除去前後の桁、大小変換、パラメーター集合と受信順、標準順序、文脈の種類と管理者、ext／isub、必須パラメーター認識、パーサー版、比較規則と結果を残すべきである。割当の鮮度、ダイヤル変換、信号宛先、選択経路、同意、応答、人の応答、サービスと費用は別記録にする。

RFC 3966 は、比較を役立てるために契約上「装飾」とされた差だけを忘れた。その裏返しが現代にも効く。比較規則が観測していない現実を、「同じ」という便利な語へ混入させてはいけない。

出典