Network Working Group H. Schulzrinne Request for Comments: 3966 Columbia University Obsoletes: 2806 December 2004 Category: Standards Track 電話番号のためのtel URI The tel URI for Telephone Numbers 本文書の位置付け この文書は、インターネットコミュニティのためのインターネット標準トラッ クプロトコルを規定するものであり、改善のための議論や提案を依頼するもの である。標準化の段階や、プロトコルの位置付けについては、最新版の "Internet Official Protocol Standards" (STD 1)を参照されたい。この文書 の配信は無制限である。 著作権表記 Copyright (C) The Internet Society (2004). 概要 本文書は、URI (Uniform Resource Identifier)スキームの「tel」を規定す る。「tel」URIは、電話番号で識別されるリソースを記述する。本文書によっ て、RFC 2806が廃止される。 目次 1. はじめに 2. 用語 3. URI構文 4. URIの比較 5. 電話番号とそのコンテキスト 5.1. 電話番号 5.1.1. 電話番号のセパレータ 5.1.2. 英字と数字の対応 5.1.3. 識別子としての英字、*文字、および#文字 5.1.4. グローバル番号 5.1.5. ローカル番号 5.2. ISDNサブアドレス 5.3. 電話の内線番号 5.4. 他のパラメータ 6. 例 7. 原理 7.1. 電話番号をそのままSIP URIに指定しない理由 7.2. 呼の種類を区別しない理由 7.3. telの理由 7.4. 番号とダイヤル方法を混同しないこと Schulzrinne Standards Track [Page 1] RFC 3966 The tel URI December 2004 8. HTMLにおける電話URLの用法 9. 「tel」URIとSIPの併用(参考情報) 10. 謝辞 11. セキュリティの考慮事項 12. RFC 2806からの変更点 13. 参考文献 13.1. 規範となる参考文献 13.2. 有益な参考文献 著者の連絡先 完全な著作権表示 1. はじめに 本文書は、URIスキーム「tel」を定義する。これによって、電話番号で識別さ れるリソースを記述する。電話番号は、ネットワークの終端ポイントを一意に 識別する10進数で構成される文字列である。この数字には、この終端ポイント の呼び出しをルートするために必要な情報が含まれる(この定義は[E.164]に由 来しているが、パブリック番号とプライベート番号の両方を網羅する)。 「tel」URI電話番号の終端ポイントには、制約がない。公衆電話網、専用電話 網、またはインターネットのいずれも可能である。固定または無線の場合もあ り、固定電話端末、モバイル端末、または移動(nomadic)端末にも対応する。 このような端末では、音声、データ、FAXなど、任意の電子通信サービス (electronic communication service/ECS)をサポートすることができる。URI は、電話の発呼元または発呼先を始め、電話番号で識別されるリソースを指す ことができる。 「tel」URIは、グローバルに一意な識別子(「name」)でしかない。特定の番号 に到達するときに必要な手順も表していないし、ダイヤルのセマンティクス も規定していない。さらに、単に電話番号を示すのみで、特定の物理デバイス も示していない。 一般的に知られているように、電話番号は、関連してはいるが別個の概念2つ から構成されている。1つは標準のAddresses-of-Recordとダイヤル文字列であ る。本文書では、以下の概念を定義する。 Addresses-of-Recordまたは識別子: 本文書での電話番号は、特定のネット ワーク内における終端ポイントの標準Addresses-of-Recordまたは識別子と 理解される。公衆網の場合、この番号は、E.164[E.164]の規則に従う。一 方で、プライベート番号は、そのプライベートな付番計画の所有者が作成 した規則に従う。サブスクライバは、発信元の位置にかかわらず到達でき るように、この識別子を発行する。(当然ながら、さまざまな技術的理由 およびローカルポリシーの理由から、すべての番号が任意の場所から到達 Schulzrinne Standards Track [Page 2] RFC 3966 The tel URI December 2004 可能である訳ではない。また、1つの終端ポイントが複数のネットワーク から到達可能なこともあり、複数の識別子を持つこともある)。 ダイヤル文字列: 「Dial strings」は、ユーザーが電話をかけるときに入力す る実数、記号、およびポーズである。ダイヤル文字列は、1つ以上のネット ワークエンティティによって使用され、そのエンティティの構成の文脈で 理解される。呼をルートできるように、Addresses-of-Recordまたは識別子 (前述の意味)を生成するときに使用される。エンドシステムが接続するPBX (Private Branch Exchange)を抜けるために、ダイヤル文字列の先頭に数 字を付ける必要な場合がある。また、ダイヤル文字列には、IVR (Interactive Voice Response)システムを制御したり内線に到達するため に、ダイヤル後にDTMF (dual-tone multi-frequency)シグナリングを含め る場合もある。ダイヤル文字列は、本文書の範囲外である。 どちらの手法も、URIで表現することができる。ダイヤル文字列の場合、この URIは、ダイヤル文字列で規定された動作を再生することができるエンティ ティに渡される。たとえば、アナログ電話システムの場合、ダイヤル側は、ダ イヤル文字列を一連の動作に変換する。たとえば、発信音を待ち、DTMF数字を 送信し、一時停止し、受信側が電話を取ってからダイヤル後のDTMF数字を生成 するなどの動作である。ISDN (Integrated Services Digital Network)または ISUP (ISDN User Part)の環境では、ダイヤル文字列が含まれたプロトコル メッセージを受信するシグナリング要素は、適切なプロトコル動作を実行す る。注記したように、この方法は、本仕様の範囲外である。 本文書で説明される手法には、電話番号を識別子として規定するURIがある。 このURIはグローバルに一意にすることもできるが、ローカルの文脈内でのみ 有効にすることもできる。ダイヤルアプリケーションは、ローカルの文脈を意 識する。たとえば、外線にかけるときに特殊な番号をダイヤルする必要がある かどうか、ダイヤルにネットワーク、パルス、またはトーンが必要かどうか、 発呼中であることを示すトーンは何かなどを理解する。ダイヤルアプリケー ションは、電話番号をダイヤルシーケンスに変換し、必要なシグナリング動作 を実行する。発呼側アプリケーションは、従来のデスクトップオペレーティン グシステムで使用されるような、ユーザーアプリケーションにする必要はな い。IP-to-PSTNゲートウェイの一部にすることもできる。 ある電話番号にPBX上にある電話から到達するには、たとえば、その電話の ユーザーは、電話番号の識別子を、相手側の電話に適したダイヤル文字列に変 換する方法を知る必要がある。電話番号自体では、特定の端末で必要な動作が わからない。発呼前に「9」をダイヤルしたり、海外の電話番号にかけるとき は先頭に「00」を付けるなどの指示が含まれることもある。また、電話番号か ら地域コードや国コードを削除することが必要な場合もある。 Schulzrinne Standards Track [Page 3] RFC 3966 The tel URI December 2004 本文書で説明する識別子の手法には、電子バンキングや音声メールなど特定の サービスを「tel」URIで規定できない、という欠点がある。 本文書の電話番号の表記は、RFC 3191 [RFC3191]およびRFC 3192 [RFC3192]の 表記と似ている。ただし、本文書ではURIを記述するが、RFC 3191とRFC 3192 では電子メールアドレスを記述する、という点で構文が異なる。RFC 3191と RFC 3192では、パラメータ(修飾子)を示すために「/」を使用する。URIではパ スの階層構造を記述するためにこのフォワードスラッシュを使用するため、本 文書のURIスキームでは、セッション開始プロトコル(Session Initiation Protocol/SIP)のURI規約[RFC3261]に合わせて、セミコロンを使用する。 「tel」URIは、SIPリクエストのリクエストURIに使用できる。SIP仕様では、 この構文の「サブスクライバ」部分をSIP URIの「ユーザー要素」の部分とし て継承する。他のプロトコルでも、このURIスキームを使用する可能性があ る。 「tel」URIでは、音声、FAX、データコールなど、呼の種類を規定しない。ま た、データコールの接続パラメータを提供しない。このような種類とパラメー タは、電話機によって帯域内でネゴシエートするか、SIPなどのシグナリング プロトコルを使用してネゴシエートすると考えられる。 本文書によって、RFC 2806が廃止される。 2. 用語 本文書では、キーワード「MUST」、「MUST NOT」、「REQUIRED」、 「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、 「RECOMMENDED」、「MAY」、「OPTIONAL」はRFC 2119のBCP 14 [RFC2119]に記 載されるとおりに解釈されるべきであり、CPL準拠の実装のための実装レベル を示すものである。 3. URI構文 URIは、RFC 2234 [RFC2234]に記載されているABNF (augmented Backus-Naur form)を使用して定義され、そのコア定義の要素が使用される(RFC 2234の付録 A)。 構文の定義はRFC 2396 [RFC2396]に従う。この文書で、URIに含まれる実際の 文字が指定されている。予約文字「+」、「;」、「=」、および「?」は、 「tel」URIのコンポーネント間を区切るデリミタとして使用される。これらの 文字はパーセントでエンコードしてはならない[MUST NOT]。これらの文字を tel URIパラメータ値に指定する場合、パーセントでエンコードしなくてはな らない[MUST]。 Schulzrinne Standards Track [Page 4] RFC 3966 The tel URI December 2004 「予約済み(reserved)」および「安全ではない(unsafe)」文字セット(RFC 2396 [RFC2396])に含まれない文字は、「% HEX HEX」のパーセントでエンコー ディングされたものと同等である。 「tel」URIの構文を次に示す。 telephone-uri = "tel:" telephone-subscriber telephone-subscriber = global-number / local-number global-number = global-number-digits *par local-number = local-number-digits *par context *par par = parameter / extension / isdn-subaddress isdn-subaddress = ";isub=" 1*uric extension = ";ext=" 1*phonedigit context = ";phone-context=" descriptor descriptor = domainname / global-number-digits global-number-digits = "+" *phonedigit DIGIT *phonedigit local-number-digits = *phonedigit-hex (HEXDIG / "*" / "#")*phonedigit-hex domainname = *( domainlabel "." ) toplabel [ "." ] domainlabel = alphanum / alphanum *( alphanum / "-" ) alphanum toplabel = ALPHA / ALPHA *( alphanum / "-" ) alphanum parameter = ";" pname ["=" pvalue ] pname = 1*( alphanum / "-" ) pvalue = 1*paramchar paramchar = param-unreserved / unreserved / pct-encoded unreserved = alphanum / mark mark = "-" / "_" / "." / "!" / "~" / "*" / "'" / "(" / ")" pct-encoded = "%" HEXDIG HEXDIG param-unreserved = "[" / "]" / "/" / ":" / "&" / "+" / "$" phonedigit = DIGIT / [ visual-separator ] phonedigit-hex = HEXDIG / "*" / "#" / [ visual-separator ] visual-separator = "-" / "." / "(" / ")" alphanum = ALPHA / DIGIT reserved = ";" / "/" / "?" / ":" / "@" / "&" / "=" / "+" / "$" / "," uric = reserved / unreserved / pct-encoded パラメータ名("pname")、ISDNサブアドレス、「内線番号(extension)」、およ び「コンテキスト(context)」は、それぞれ複数回出現してはならない[MUST NOT]。最初に「isdn-subaddress」パラメータまたは「extension」パラメータ (存在する場合)、次に「context」パラメータ(存在する場合)、次にその他の パラメータを辞書式順序(lexicographical order)で指定しなければならない [MUST]。 これによって、SIP URI [RFC3261]などで「tel」URIが1文字ずつ比較する ときに、比較処理が単純になる。 Schulzrinne Standards Track [Page 5] RFC 3966 The tel URI December 2004 4. URIの比較 次の規則に従って、2つの「tel」URIが同一とされる。 o どちらも、「local-number」または「global-number」(つまり「+」で始ま る番号)である。 o 視覚的なセパレータを取り除いた「global-number-digits」と「local- number-digits」は同一である。 o 必須の追加パラメータ(セクション5.4)と本文書で定義されている「phone- context」と「extension」に関して、「phone-context」パラメータ値が 「global-number-digits」で「domainname」または数字による表記の場 合、「phone-context」はホスト名と比較される。後者は、「視覚的セパ レータ」文字をすべて取り除いた後に比較される。 o パラメータは、URIでの表記順序にかかわらず、「pname」に従って比較さ れる。一方のURIに、もう一方のURIにないパラメータ名がある場合、2つの URIは同一ではない。 o URIの比較では大文字と小文字を区別しない。 すべてのパラメータの名前とパスワードでは、小文字を使用すべきである [SHOULD]。これは、比較時に大文字と小文字を区別する文脈で、tel URIが使 用される可能性があるためである。 SIP仕様[RFC3261]のセクション19.1.4で、このような状況について議論されて いる。 5. 電話番号とそのコンテキスト 5.1. 電話番号 URIの「telephone-subscriber」部は番号を示す。電話番号は、グローバル(E. 164)表記またはローカル表記で表すことができる。すべての電話番号は、グ ローバル形式で表すことができない場合を除き、グローバル形式を使用しなけ ればならない[MUST]。緊急番号(「911」、「112」)や何らかの電話番号案内の 番号(例: 「411」)といったプライベートな付番計画による番号、およびその 他のサービスコード(米国におけるN11形式の番号)は、グローバル形式で表す ことができない[訳注]。そのため、コンテキスト付きのローカル番号として 表す必要がある。ローカル番号は、「phone-context」(セクション5.1.5)でタ グを付けなければならない[MUST]。 [訳注: 「911」は米国など、「112」はEU各国などで使用されている緊急 通報先で、日本では「110」または「119」に相当します。 「411」は米国などの電話番号案内で、日本では「104」に相当しま す。 「N11」は、211や711など911以外の番号を公的情報サービスの番号 に割り当てる計画です。] 実装では、電話番号の長さに最大値があること、最小値があること、または固 定値があることを仮定したり、常に特定の数字で始まったり、特定の数字を含 むと仮定してはならない[MUST NOT]。 Schulzrinne Standards Track [Page 6] RFC 3966 The tel URI December 2004 5.1.1. 電話番号のセパレータ 電話番号には視覚的セパレータを含めてもよい[MAY]。視覚的セパレータ (「visual-separator」)は単に読みやすくするだけのもので、URIの比較や発 呼には使用されない。 比較は複雑になるが、RFC 2396 [RFC2396]の精神に従って、本仕様では視覚的 セパレータを保持する。RFC 2396では、「URIは、人に記憶してもらう必要が ある場合が多い。URIを意味のあるコンポーネントで構成すると、人が記憶し やすくなる。」と注記している。また、RFC 3187 [RFC3187]で文書化されてい るISBN URNでは、本仕様と似た方法で視覚的セパレータを使用している。 一方、ITU-TのE.123 [E.123]では、電話番号を印刷する場合、視覚的セパレー タとしてスペース文字を使用することを推奨しているが、「tel」URIでは、エ スケープが過度になることを防ぐために、視覚的セパレータにスペースを使用 してはならない[MUST NOT]。 5.1.2. 英字と数字の対応 一部の国では、電話のプッシュボタンにある特定の数値に英字を対応させて、 電話番号を記述する方法が一般的である。URI形式ではこの表記方法をサポー トしない。これは、英字から数字へのマッピングが国際的に完全に統一されて いないためである。ただし、この問題に対処する規格は存在する[E.161] [T1.703]。 5.1.3. 識別子としての英字、*文字、および#文字 着呼および発呼する端末番号(terminal number/TN)は、ISUPのBCDでエンコー ドされるため、1つの数字ごとに6つの追加の値をエンコードできる(A〜Fの16 進文字で表されることもある)。同様に、DTMFでは、記号(*、#、A〜D)のエン コーディングを許容している。ただし、E.164に従うと、このような文字はグ ローバル番号に含めることができない。ローカル番号における意味合いは本文 書で定義しないが、禁止もしない。 5.1.4. グローバル番号 グローバルに一意な番号は、先頭に付く「+」文字で識別される。グローバル 番号は、E.123 [E.123]およびE.164 [E.164]で規定されている国コード(CC/ Country Code)および国内番号(NSN/National Number)で構成しなければならな い[MUST]。グローバルに一意な番号は世界のどこでも一義的なので、使用すべ きである[SHOULD]。 Schulzrinne Standards Track [Page 7] RFC 3966 The tel URI December 2004 5.1.5. ローカル番号 ローカル番号とは、特定の地域内、または電話網の特定部分(PBX (Private Branch Exchange)、州や地方、特定地域の交換キャリア、または特定の国な ど)でのみ一意な番号である。ローカル電話番号が含まれるURIは、その番号を ダイヤルソフトウェアに渡すと、すべてのローカルエンティティが通話を確立 できる環境でのみ、使用すべきである。たとえば、外線にアクセスするときに 必要な数字は、ローカル番号に含まれない。ローカル番号は、グローバル番号 として表す方法がない場合を除き、使用すべきではない[SHOULD NOT]。 ローカル番号は、いくつかの理由から使用すべきではない[SHOULD NOT]。ロー カル番号は、正しいコンテキスト記述を挿入および認識することができるよう に、発信元または受信者を適切に設定する必要がある。同じ記述子を単独で選 択するアルゴリズムはないため、コンテキストで番号にラベルを付ける場合、 誤設定の可能性が高くなる。結果的に、有効な識別子が誤って拒否される。記 述子を選択するアルゴリズムは、偶然による衝突がほとんど発生しないように 選択されたが、完全になくすことはできていない。 ローカル番号は、「phone-context」パラメータを含めなければならない [MUST]。これによって、ローカル番号の有効範囲が特定される。このパラメー タは、番号が一意になるローカルのコンテキストを明確に識別できるように選 択しなければならない[MUST]。したがって、「phone-context」パラメータの 記述子とローカル番号を組み合わせると、グローバルに一意になる。このパラ メータ値は、ローカル番号の割り当て者(assignee)によって定義される。これ は、ローカル番号をグローバル番号(E.164)に変換する接頭辞を示すものでは ない[NOT]。 コンテキストにラベルを付ける方法は2つある。先頭の数桁のグローバル番号 または任意の番号による場合(「+33」など)と、ドメイン名による場合 (「houston.example.com」)であるどちらを選択するかは、ローカル番号の 「所有者(owner)」に委ねられる。また、グローバル番号が存在するか、また は特定のローカル番号に有効な識別子であるドメイン名が存在するかによって 決まる。 ドメイン名は、実際のホストに解決される必要はないが、ローカルの電話コン テキストを管理するエンティティの制御下で管理しなければならない[MUST]。 グローバル番号のコンテキストは、有効なグローバル番号の先頭番号(initial digits)で構成される。このような先頭番号を持つグローバル番号はすべて、 必ず同じ組織に相当する。また、このような一致番号は、他の組織では使用で きない。たとえば、ダルムシュタット技術大学(Technical University of Darmstadt)では、必ず+49-6151-16で始まる番号を使用しているため、 +49-6151-16はこの大学のコンテキストに適している。このような先頭の数字 文字列が存在しない場合、組織は、割り当たっているグローバル番号の範囲の Schulzrinne Standards Track [Page 8] RFC 3966 The tel URI December 2004 うち、最小桁の数値を使用すべきである[SHOULD]。(2つの組織が同じ10進数の ブロックを共有している場合、このような状況が発生する。たとえば、ある組 織が+1-212- 555-0100〜+1-212-555-0149の範囲の番号を所有しているとす る。+1-212-555-1は有効なグローバル番号ではないが、+1-212-555-0100なら 機能する。)コンテキスト内のローカル番号が、選択した先頭の複数桁で実際 に始まる必要はない。 グローバル番号の先頭番号を構成するコンテキストは、先頭番号をローカル番 号に追加することで有効なE.164番号が生成されることは意味しない。偶然そ うなることはあるが、確実ではない。(たとえば、「911」にコンテキスト 「+1」でラベルを付けられるが、「+1-911」は有効なE.164番号ではない。) 国内の無料電話番号は、特定の国コード以外または特定の付番計画以外から到 達できない場合でも、コンテキストを必要としない。「tel」URIは識別子であ るということを改めて思い出すこと。識別子なので、グローバル番号は一意だ が、任意の場所から到達可能である必要はない。 無料以外の番号でも、失効したり、特定の場所から到達できない場合があ る。たとえば、北アメリカの付番計画で、「900」番などの割り増し料金の サービスは、特定の国コード以外からはダイヤルできない場合が多い。 この2つのラベルの種類は、わかりやすくIANA管轄で割り当てられる番号を 必要としない新しい識別子を、ほとんどすべての場合にローカル管理者が 選択できるように選択された。適切な識別子を割り当て、一貫して使用す る方法は、ローカル管理者に委ねられる。多くの場合、1つの組織は複数の 識別子から選択できる。 「tel」URIの受信者が識別のためにのみ使用する場合、受信者は、コンテキス トの記述子に関して何も理解する必要はない。単にグローバルに一意な識別子 の一部として扱い、その他はローカル番号として扱うだけである。URIの受信 者は、ローカル番号に発呼する場合、コンテキストを理解してそのコンテキス ト内で発呼できなければならない[MUST]。 5.2. ISDNサブアドレス 電話番号には、ISDNのサブアドレスを示す「isdn-subaddress」パラメータを 含めてもよい[MAY]。 Schulzrinne Standards Track [Page 9] RFC 3966 The tel URI December 2004 ISDNのサブアドレスには、一般的にInternational Alphabet 5 (IA5 [T.50]) 文字が含まれるが、任意のオクテット値を含めることもできる。 5.3. 電話の内線番号 電話の内線番号によって、ISDN PBXの内側にあるステーションが識別される。 また、機能的に言うとISDNのサブアドレスと大体同じである。内線番号は、 「extension」パラメータで識別される。最大でも、1つの「tel」URIに指定で きるのは、「isdn-subaddress」パラメータと「extension」パラメータのいず れかである。つまり、両方を同時に指定することはできない。 5.4. 他のパラメータ このURIスキームに対する将来的なプロトコル拡張で、別のパラメータ(ABNFの 「パラメータ」)が追加される場合がある。このようなパラメータは、必須ま たはオプションのどちらになる可能性もある。必須のパラメータは「m-」で始 まる。実装ではオプションのパラメータを無視してもよい[MAY]。また、未知 の必須パラメータが含まれる場合、そのURIを使用してはならない[MUST NOT]。「m-」の接頭辞は、登録済みのパラメータには追加できない(ただし、 論理的に区別できる新しいパラメータを作成する場合は除く)。本文書の 「phone-context」パラメータは必須であり、「isub」と「ext」はオプション である。 新規の必須パラメータは、標準化過程(standards-track)のRFCに記載する必要 がある。ただし、オプションのパラメータの場合、通知(informational )の RFCでもよい。 たとえば、「parameter」パラメータは、電話番号、用途、または番号に適用 された変換に関するアプリケーション固有の追加データを格納するときに使用 できる。 オプションのパラメータが指定された「tel」URIを含むプロトコルのリクエス トを転送する場合、エンティティは未知のパラメータを削除または修正しては ならない[MUST NOT]。 6. 例 tel:+1-201-555-0123: このURIは、米国の電話番号を示す。ハイフンは、番号 を読みやすくなるように含まれている。ハイフンによって国、地域コー ド、加入者番号が区別される。 tel:7042;phone-context=example.com: このURIは、「example.com」のコンテ キスト内で有効なローカル電話番号を示す。 tel:863-1234;phone-context=+1-914-555: このURIは、特定の電話番号の接頭 辞内で有効な、ローカル電話番号を示す。 Schulzrinne Standards Track [Page 10] RFC 3966 The tel URI December 2004 7. 原理 7.1. 電話番号をそのままSIP URIに指定しない理由 「tel」URIは、電話番号に到達するサービスを記述するものであり、実現手段 とは独立している。たとえば、SIP-to-PSTNゲートウェイ経由、E.164番号 (「ENUM」)変換[RFC3761]経由によるSIPの直接発呼、H.323などの他のシグナ リングプロトコル、または、Telephony Application Programming Interface (TAPI)などを経由してクライアント側で開始される従来の回路交換(circuit- switched)方式の発呼など、手段は問わない。したがって、本質的に「tel」 URIはURNスキームと似ている。URNも、解決は外部の仕組みに委ねている。同 じ「tel」URIが、呼を確立する処理の中で、さまざまな別URIに変換される可 能性がある。 7.2. 呼の種類を区別しない理由 SIPなどのシグナリングプロトコルを使用すると、呼の種類とパラメータをネ ゴシエートすることができる。これによって、URIスキーム内の非常に基本的 な表記が論点になる。また、呼の種類は頻繁に変化する可能性があるため、 URIの表記は期限切れになる可能性が高い。SIPなどのシグナリングプロトコル なしで直接発呼するデバイスで、このような指定が必要な場合、HTMLの「A」 要素の「type」属性などの仕組みの方が、より適切である。 7.3. telの理由 「tel」を選択した理由は、広く認識されており、その他の提案が適切と思わ れなかったためである。「Callto」が外されたのは、URIスキームはリソース の位置を特定するもので、実行されるアクションを指定しないためである。 「telephone」と「phone」は長すぎ、国際的にも容易に認識できないと考えら れた。 7.4. 番号とダイヤル方法を混同しないこと 一例を挙げる。多くの国ではE.164番号「+1-212-555-3141」は「00-1-212-555 -3141」とダイヤルされる。先頭の「00」は、国際電話の接頭辞である。(一般 的に、E.164の「+」記号は、国際電話の接頭辞が必要であることを示す。) 8. HTMLにおける電話URLの用法 「tel」URIを使用したリンクの場合、ユーザーがリンクをたどったときに実行 されるアクションを予想しやすいように、リンクで電話番号を囲むべきである [SHOULD]。 お問い合わせについては、+1-212-555-0101 までお電話ください。 Schulzrinne Standards Track [Page 11] RFC 3966 The tel URI December 2004 上記の表記方法を、下記の表記方法の代わりに使用する。 お問い合わせについては、この番号まで お電話ください。 パブリックのHTMLページの場合、リンクのテキストでローカル形式を使用して いる場合でも、URIの電話番号は常にグローバル形式にすべきである [SHOULD]。 電話(米国から電話するとき): (201) 555-0111 または RFCの音読については、1-555-IETF-RFC にお電話ください。 9. 「tel」URIとSIPの併用(参考情報) SIPでは、URIを使用できるところであればどこにでも「tel」URIを使用でき る。たとえば、Request-URIで「sip」URIや「sips」URIと共に使用することが できる。簡略化しているが、本書でSIP URIと言う場合、「sips」URIを指す。 「tel」とSIP URLのどちらにも、電話番号を含めることができる。SIP URIで は、@記号前のユーザー部として表記される([RFC3261のセクション19.1.6])。 SIP UAが直接PSTNゲートウェイに接続する場合を除き、SIPプロキシサーバー のいずれかが「tel」URIをSIP URIに変換する必要がある。このとき、URIのホ スト部はゲートウェイを指す。一般的に、発呼リクエストが最初のプロキシ サーバーに到達したとき、アウトバウンドプロキシサーバーがこの変換を実 行する。プロキシサーバーは、すべての「tel」URIを同じSIPホスト名に変換 するか、TRIP [RFC3219]によって取得した情報などに基づいて、「tel」の接 頭辞ごとに異なるゲートウェイを選択することもできる。ただし、プロキシ サーバーは、この変換タスクを別のプロキシサーバーに委任することもでき る。これは、プロキシサーバーはルーティングロジックを自由に適用できるた めである。ローカル番号の場合、プロキシは未知のコンテキストを持つ 「tel」URIを変換してはならない[MUST NOT]。 前述したように、すべての電話番号は、グローバル形式で表すことができない 場合を除き、グローバル形式を使用しなければならない[MUST]。ローカル番号 形式を使用する場合、「phone-context」で修飾しなければならない[MUST]。 ローカル番号と電話のコンテキストを組み合わせることで、実質的に「tel」 URIはグローバルに一意になる。 Webページ、vCardの名刺、アドレス帳、ディレクトリにグローバル「tel」URI を簡単に含めることができる場合でも、ボタン数が12の(IP)電話のユーザー は、そのようなURIを直接ダイヤルすることはできない。また、一般的に、URI はダイヤル方式に合わせて短い文字列(PBXの内線やローカル番号など)に短縮 される。このようないわゆるダイヤル文字列(セクション1)は、前述のように Schulzrinne Standards Track [Page 12] RFC 3966 The tel URI December 2004 「tel」URIでは直接表すことはない。ダイヤル文字列から、SIP URIおよび 「tel」URI(グローバルまたはローカルかはダイヤル計画による)への変換を規 定する規則について言及する。現在、ダイヤル文字列から「tel」URIへの変換 は、エンドシステムで実行する必要がある。将来的な研究で、たとえばSIP URIでダイヤル文字列を伝達する方法が実現する可能性はある。ただし、その ような仕組みは執筆時点で存在しない。 SIP UAは、ダイヤル計画を使用して、ダイヤル文字列をSIP URIまたは「tel」 URIに変換することができる。ダイヤル計画は、手動で設定できるか、できれ ばデバイス設定の仕組みの一部でダウンロードできるようにする。(現時点 で、適切な標準の仕組みはない。) モバイルユーザーは、少なくとも2つのダイヤル計画を使用できる。つまり、 現在訪問しているネットワークのダイヤル計画と、自分のホームネットワーク のダイヤル計画である。一般的に、グローバル番号を表す意図でダイヤルされ た番号は、ダイヤル計画にかかわらず、ユーザーが現在のダイヤル計画を意識 している限り、変換後は同じように見える。たとえば、訪問したネットワーク で「外線」番号にダイヤルする場合に「0」を使用し、ユーザーのホームネッ トワークでは「9」を使用している場合でもそうである。ただし、直接のグ ローバル番号がないローカルの内線番号は、動作が異なることがある。あいま いさをなくすために、ダイヤル計画で変換を実行するときに、適切な「phone- context」文字列を挿入しなければならない[MUST]。「phone-context」がドメ イン名の場合、3つのケースがある。 1. アウトバウンドプロキシが、「tel」URIまたはSIP URIのドメイン名を ローカルのコンテキストと認識する。そのため、ローカル番号を理解する ゲートウェイにリクエストをルートすることができる。 2. アウトバウンドプロキシは同じ電話のコンテキストを使用していないが、 この電話のコンテキストを処理するプロキシにルーティングできる。この ルーティングは、検索テーブル経由で実行することができる。または、適 切なプロキシのSIPドメイン名を反映して、電話のコンテキストのドメイ ン名がセットアップされることがある。たとえば、プロキシは以下のよう に、常に呼を「tel」URIにルーティングすることができる。 tel:1234;phone-context=munich.example.com これは、munich.example.comにあるSIPプロキシに対してルーティングさ れる。(プロキシは、未知のコンテキストを持つ「tel」URIを受信した場 合、404 (Not Found)のステータス応答を返す義務がある。これは、アウ トバウンドプロキシがこのようなヒューリスティックを試行するように判 断する可能性があるためである。) 3. アウトバウンドプロキシは、電話のコンテキストを認識せず、その電話の コンテキストに適切なプロキシを検出できない。この場合、変換は失敗 し、アウトバウンドプロキシは404 (Not Found)のエラー応答を返す。 Schulzrinne Standards Track [Page 13] RFC 3966 The tel URI December 2004 10. 謝辞 本文書は、Antti Vaehae-Sipilae著のRFC 2806 [RFC2806]から派生している。 Mark Allman、Flemming Andreasen、Francois Audet、Lawrence Conroy、 Cullen Jennings、Michael Hammer、Paul Kyzivat、Andrew Main、Xavier Marjou、Jon Peterson、Mike Pierce、Jonathan Rosenberg、James Yuの各氏 から豊富なコメントをいただいた。 11. セキュリティの考慮事項 セキュリティの考慮事項は、malto URL [RFC2368]のものと同様である。 Webクライアントとその類似ツールは、クライアントのユーザーが明示的に承 諾しない限り、発呼の目的で「tel」URIを使用してはならない[MUST NOT]。 ユーザーによる適切な承諾がないのに自動的に発呼すると、以下に示すような 数多くの危険性がある。 o 通話に費用がかかる可能性がある。 o 悪意があったり迷惑な相手に発呼するときにURIが使用される可能性が ある。 o 発呼によってユーザーの電話回線がオフフック状態になり、使用できなく なる。 o 発呼側の表示データに含まれる、ユーザーが公開していない電話番号が、 発呼によってリモートホストに公表される可能性がある。また、攻撃者が ユーザーの電話番号を別の情報(電子メールやIPアドレス)と関連付けるこ とができる可能性がある。 HTMLリンクに「tel」URIを埋め込む場合、これは特に重要である。悪意のある パーティが、次のように、リンクテキストではURIが持つ真の性質を隠すこと ができるためである。 無料情報はこちら tel:+1-800-555-0191 電話番号をテキストとして含める場合と同様に、「tel」URIによってプライ ベート情報が明かされる可能性がある。一方、tel:スキーマ識別子があること で、攻撃者は検索エンジンを使用してこのような番号を簡単に検出できる可能 性がある。 12. RFC 2806からの変更点 本仕様は、RFC 2806[RFC2806]で定義されている「tel」URIと構文的には下位 互換性があるが、全体的に書き直されている。本文書では、ネットワークの終 端ポイントの識別子としての電話番号と、ダイヤル文字列とをより明確に区別 し、「tel」URIの範囲からダイヤル文字列を除外した。 Schulzrinne Standards Track [Page 14] RFC 3966 The tel URI December 2004 RFC 2806と比較すると、キャリアの選択、ダイヤルコンテキスト、FAXとモデ ムのURI、ダイヤル後文字列、およびポーズ文字に関する言及は削除された。 URI構文はRFC 2396 [RFC2396]に準拠するようになった。 SIPにおける「tel」URIの使用に関するセクションが追加された。 13. 参考文献 13.1. 規範となる参考文献 [E.123] International Telecommunications Union, "Notation for national and international telephone numbers, e-mail addresses and web addresses", Recommendation E.123, February 2001. [E.161] International Telecommunications Union, "Arrangement of digits, letters and symbols on telephones and other devices that can be used for gaining access to a telephone network", Recommendation E.161, May 1995. [E.164] International Telecommunications Union, "The international public telecommunication numbering plan", Recommendation E.164, May 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997. [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. [T1.703] ANSI, "Allocation of Letters to the Keys of Numeric Keypads for Telecommunications", Standard T1.703-1995 (R1999), 1999. Schulzrinne Standards Track [Page 15] RFC 3966 The tel URI December 2004 13.2. 有益な参考文献 [RFC2368] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998. [RFC2396] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998. [RFC2806] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000. [RFC3761] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004. [RFC3187] Hakala, J. and H. Walravens, "Using International Standard Book Numbers as Uniform Resource Names", RFC 3187, October 2001. [RFC3191] Allocchio, C., "Minimal GSTN address format in Internet Mail", RFC 3191, October 2001. [RFC3192] Allocchio, C., "Minimal FAX address format in Internet Mail", RFC 3192, October 2001. [RFC3219] Rosenberg, J., Salama, H., and M. Squire, "Telephony Routing over IP (TRIP)", RFC 3219, January 2002. [T.50] International Telecommunications Union, "International Reference Alphabet (IRA) (Formerly International Alphabet No. 5 or IA5) - Information technology - 7-bit coded character set for information interchange", Recommendation T.50, 1992. 著者の連絡先 Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US Phone: +1 212 939 7042 EMail: hgs@cs.columbia.edu URI: http://www.cs.columbia.edu Schulzrinne Standards Track [Page 16] RFC 3966 The tel URI December 2004 完全な著作権表示 Copyright (C) The Internet Society (2004). 本文書は、BCP 78に含まれる権利、ライセンス、制限の対象となり、BCP 78に 記載されている例外に従い、著者はすべての権利を持つ。 本文書とここに含まれた情報は「無保証(AS IS)」で提供され、寄稿者、寄稿 者が代表となる組織、または寄稿者を後援する組織(存在する場合)、インター ネット協会およびIETFは、この情報がいかなる権利も侵害していないという保 証、商用利用および特定目的への適合性への保証を含め、また、これらだけに 限らずすべての保証について、明示的もしくは暗黙的の保証は行われない。 知的財産権 IETFは、本文書で記述される技術の実装または使用に関して要求される、知的 所有権または他の諸権利の有効性または範囲に関して、またはこのような権利 下の任意のライセンスがどの範囲まで使用可能か不可能かに関して、何ら見解 を持たない。このような権利を確認する独自の取り組みを行ったことも示さな い。RFC文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記 載されている。 IPRの開示のコピーがIETF事務局に対して作成され、利用可能になるライセン スの保証すべて、またはこのような所有権の使用に関して、本仕様の実装者ま たはユーザーが一般的なライセンスまたは許可の取得を試みた結果について は、IETFのオンラインIPR保存所 http://www.ietf.org/ipr で取得可能であ る。 IETFは、この規格を実装するために必要とされる技術の範囲にある可能性があ る、すべての著作権、特許または特許アプリケーション、あるいは他の所有権 について、すべての関連団体に対して配慮するよう依頼している。情報につい ては、IETFの ietf-ipr@ietf.org まで連絡されたい。 謝辞 RFC編集職務のための資金は、現在、インターネット協会によって提供されて いる。 ----------------------------------------------------------------------- 本文書は、RFCの原文を元に、株式会社ソフトフロントが日本語に翻訳したもの です。本翻訳物の著作権は、株式会社ソフトフロントが保持しています。ただ し、この権利の設定は原文から新たな翻訳を作成し公開することを妨げるもの ではありません。本翻訳物は、本著作権表示を含めて改変しないことを条件に 再配布を許可します。翻訳の正確さについては一切保証しません。原文とあわ せてご利用ください。 2005年 ----------------------------------------------------------------------- Schulzrinne Standards Track [Page 17]