Network Working Group R. Stastny
Request for Comments: 4759 Oefeg
Category: Standards Track R. Shockey
Neustar Inc.
L. Conroy
Roke Manor Research
November 2006
The ENUM Dip Indicator Parameter for the "tel" URI
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（2006）。
Abstract
抽象
This document defines a new parameter "enumdi" for the "tel" Uniform Resource Identifier (URI) to support the handling of ENUM queries in Voice over Internet Protocol (VoIP) network elements. A VoIP network element may receive a URI containing an E.164 number, where that URI contains an "enumdi" parameter. The presence of the "enumdi" parameter indicates that an ENUM query has already been performed on the E.164 number by a previous VoIP network element. Equally, if a VoIP network element sends such a URI, it asserts that an ENUM query has been carried out on this number.
この文書は、インターネットプロトコル（VoIP）ネットワーク要素を介して音声でENUMクエリーの処理をサポートするために、「TEL」のURI（Uniform Resource Identifier）のための新しいパラメータ「enumdi」を定義します。 VoIPネットワーク要素は、URIが「enumdi」パラメータが含まれているE.164番号を含むURIを受信することができます。 「enumdi」パラメータの存在は、ENUMクエリーは、すでに前のVoIPネットワーク要素によってE.164番号に行われていることを示しています。 VoIPネットワーク要素は、そのようなURIを送信した場合同様に、それはENUMクエリーがこの数に行われていると主張しています。
Table of Contents
目次
1. Introduction ....................................................2
2. Terminology .....................................................2
3. Formal Syntax ...................................................3
4. Normative Rules .................................................3
4.1. Options for ENUM Domain Providers ..........................3
4.2. Client Behaviour for VoIP Network Elements .................3
4.2.1. Handling a URI with the "enumdi" Parameter ..........3
4.2.2. Adding the "enumdi" Parameter to URIs ...............4
4.2.3. Handling a URI Retrieved from ENUM ..................4
5. Examples ........................................................4
6. Security Considerations .........................................5
7. IANA Considerations .............................................5
8. Acknowledgements ................................................6
9. References ......................................................6
9.1. Normative References .......................................6
9.2. Informative References .....................................6
VoIP network elements (including User Agent Servers and User Agent Clients) may be set up in different ways to handle E.164 [3] numbers during call setup, depending on the capabilities provided. One common approach is to query ENUM as defined in RFC 3761 [4], and to use the set of NAPTR resource records that is returned.
（ユーザエージェントサーバとユーザエージェントクライアントを含む）、VoIPネットワーク要素が提供される機能に応じて、コールセットアップ中にE.164 [3]の数字を処理するために、さまざまな方法で設定することができます。一つの一般的なアプローチは、RFC 3761で定義されている[4] ENUMを照会することで、返されたNAPTRリソースレコードのセットを使用します。
If the ENUM query leads to a result, the call is set up accordingly. If the ENUM query does not lead finally to a result, another database may be queried and/or the call may finally be routed to the Public Switched Telephone Network (PSTN). In doing so, the call may be routed to another VoIP network element. To indicate in signalling to this next VoIP element that an ENUM query has already been made for the "tel" URI (specified in RFC 3966 [5]), the "enumdi" parameter is used, to prevent the next VoIP network element from repeating redundant queries.
ENUMクエリーが結果につながる場合、コールはそれに応じて設定されています。 ENUMクエリーが結果を最終的につながらない場合は、別のデータベースを照会することができ、および/または公衆交換電話網（PSTN）への呼び出しは最終的にルーティングすることができます。そうすることで、コールは別のVoIPネットワーク要素にルーティングすることができます。 ENUMクエリーは、既に「TEL」URIのために作られたことを、この次のVoIP要素へのシグナリングに示すために、（RFC 3966で指定された[5]）、「enumdi」パラメータは反復から次のVoIPネットワーク要素を防ぐために、使用されています冗長なクエリ。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[1]。
The following syntax specification uses the Augmented Backus-Naur Form (ABNF) as described in RFC 4234 [2] to extend the syntax of the "par" production defined in the ABNF of RFC 3966 [5].
以下の構文仕様はRFC 4234に記載されているように[2] RFC 3966のABNFで定義された「PAR」生産の構文を拡張するように拡張バッカス・ナウアフォーム（ABNF）を使用する[5]。
par =/ enum-dip-indicator
= /列挙型-DIP-インジケーターオン
enum-dip-indicator = ";enumdi"
列挙型ディップ・インジケータ=「; enumdi」
The enum-dip-indicator is an optional parameter for the "tel" URI. Note also that enum-dip-indicator can appear at most once in any "tel" URI.
列挙ディップインジケータは、「TEL」URIのためのオプションのパラメータです。その列挙-ディップインジケータは任意の「TEL」URIで、最高1回出現することができますも注意してください。
A domain provider can, at its choosing, populate a NAPTR record with a "tel" URI that contains the enum dip indicator. This would, as a consequence of the rules stated below, inform the client that it should not bother performing a query and pass the request on.
ドメインプロバイダは、その選んで、列挙型のディップインジケータが含まれている「TEL」URIを持つNAPTRレコードを取り込むことができます。これは、下記のルールの結果として、それがクエリを実行する気にして上の要求を渡すべきではないことをクライアントに通知します。
This section discusses how a VoIP network element handles a received "tel" URI that contains the "enumdi" parameter or has queried ENUM in e164.arpa. for a given E.164 number.
このセクションでは、VoIPネットワーク要素は、「enumdi」パラメータが含まれているかe164.arpaにENUMを照会した受信した「TEL」URIを処理する方法を説明します。与えられたE.164番号の。
If a VoIP network element receives a "tel" URI containing the "enumdi" parameter, the VoIP network element SHOULD NOT retrieve the related information for this number from ENUM in e164.arpa. even if it would normally do so.
VoIPネットワーク要素は、「TEL」「enumdi」パラメータを含むURIを受信した場合、VoIPネットワーク要素は、e164.arpaにおけるENUMからこの番号の関連情報を取得すべきではありません。それは通常、そうでしょうしても。
Note that the recipient network element may reasonably choose to query ENUM if it does not have a trust relationship with the immediate sender of the URI.
受信者のネットワーク要素は、合理的に、それはURIの直接の送信者との信頼関係を持っていない場合、ENUMを照会することを選択することがあります。
If the "tel" URI (received from a trusted entity) is to be passed to the next network element, the VoIP network element MUST pass on the received URI containing the "enumdi" parameter unchanged.
（信頼できるエンティティから受信した）「TEL」URIは、次のネットワーク要素に渡される場合は、VoIPネットワーク要素は変わらない「enumdi」パラメータを含む受信URIに渡す必要があります。
If, however, the URI has been received from an untrusted entity, then the recipient entity may either strip it before sending the URI onwards or instead carry out its own ENUM query and add the parameter accordingly to the URI (see next).
しかし、URIは信頼できないエンティティから受信された場合には、受信側エンティティは、以降のURIを送信する前にそれを取り除くか、代わりに独自のENUMクエリーを実行し、URI（次を参照）に応じてパラメータを追加することができますどちらか。
When a VoIP network element queries ENUM in e164.arpa. for a given E.164 number and the result of the query is DNS error code 3 (commonly known as "NXDOMAIN"), then if that network element chooses to pass the call to another network element by using a "tel" URI, the "enumdi" parameter MUST be set.
ときVoIPネットワーク要素は、e164.arpaにENUMを照会します。所与のE.164番号、クエリの結果は、DNSエラーコード3であるため（一般に「NXDOMAIN」として知られている）、そのネットワーク要素が「TEL」URIを使用して別のネットワーク要素への呼び出しを通過することを選択した場合、 「enumdi」パラメータを設定しなければなりません。
When a VoIP network element queries ENUM in e164.arpa. for a given E.164 number and either:
ときVoIPネットワーク要素は、e164.arpaにENUMを照会します。与えられたE.164番号のいずれか：
o the result of the query includes a NAPTR resource record containing a "tel" URI that has the same E.164 number, or
Oクエリの結果は、同一のE.164番号を有する「TEL」URIを含むNAPTRリソースレコードを含み、または
o the result of the query includes a NAPTR resource record containing a "tel" URI with the "enumdi" parameter set,
Oクエリの結果は、「enumdi」パラメータセットで「TEL」URIを含むNAPTRリソースレコードを含みます
then if that retrieved "tel" URI is chosen to be passed to another network element, the sending VoIP network element MUST pass on the retrieved URI with the "enumdi" parameter set.
その検索された「TEL」URIは、別のネットワーク要素に渡されるように選択された場合、次に、送信VoIPネットワーク要素「enumdi」パラメータセットを取得URIに通過しなければなりません。
When a VoIP network element queries ENUM in e164.arpa. for a given E.164 number and the result is a "tel" URI with a different E.164 number that lacks the enum dip indicator, the client can either perform another query against that number or pass the request on, as a matter of local policy.
ときVoIPネットワーク要素は、e164.arpaにENUMを照会します。与えられた164番号と結果を列挙ディップインジケータを欠い異なるE.164番号を持つ「TEL」URIは、クライアントがその数に対して別のクエリを実行するか、またはの問題として、上の要求を渡しますローカルポリシー。
a. A VoIP network element called server.example.com receives a "tel" URI tel:+441632960038. The VoIP network element queries the DNS for NAPTR resource records in 8.3.0.0.6.9.2.3.6.1.4.4.e164.arpa., and gets an error response with code = 3 (commonly known as "NXDOMAIN"). The VoIP network element decides to route the call to the PSTN via another VoIP network element called gw.example.com.
A。 server.example.comと呼ばれるVoIPネットワーク要素は、「TEL」URI電話を受ける：441632960038。 VoIPネットワーク要素は8.3.0.0.6.9.2.3.6.1.4.4.e164.arpaにNAPTRリソースレコードのDNSを照会し、そしてコード= 3（一般に「NXDOMAIN」として知られている）と、エラー応答を取得します。 VoIPネットワーク要素はgw.example.comと呼ばれる別のVoIPネットワーク要素を経由してPSTNへのコールをルーティングすることを決定します。
It therefore signals to the next VoIP network element with:
tel:+441632960038;enumdi
or (using the procedures of RFC 3261 [6] section 19.1.6):
sip:+441632960038;enumdi@gw.example.com;user=phone
b. A VoIP network element called server.example.com receives a "tel" URI tel:+441632960038. The VoIP network element queries the DNS for NAPTR resource records in 8.3.0.0.6.9.2.3.6.1.4.4.e164.arpa., and receives the same "tel" URI in reply (i.e., tel:+441632960038).
B。 server.example.comと呼ばれるVoIPネットワーク要素は、「TEL」URI電話を受ける：441632960038。 。VoIPネットワーク要素は8.3.0.0.6.9.2.3.6.1.4.4.e164.arpaにNAPTRリソースレコードのDNSを照会し、応答（すなわち、電話：441632960038）で同じ「TEL」URIを受信します。
The VoIP network element decides to route the call to the PSTN
via another VoIP network element called gw.example.com.
It therefore signals to this next VoIP network element with: tel:+441632960038;enumdi or (using the procedures of RFC 3261 [6] section 19.1.6): sip:+441632960038;enumdi@gw.example.com;user=phone
+441632960038; enumdi@gw.example.com;ユーザー=電話：SIP：enumdiまたは（RFC 3261の手順を用いて、[6]セクション19.1.6）; +441632960038：TEL：したがって、この次のVoIPネットワーク要素に信号
In addition to those security implications discussed in the "tel" URI [5] specification, there are new security implications associated with the defined parameter.
「TEL」URI [5]明細書で論じられるこれらのセキュリティ上の影響に加えて、定義されたパラメータに関連付けられた新しいセキュリティに影響があります。
If the "enumdi" is illegally inserted into the "tel" URI when the signalling message carrying the "tel" URI is en route to the destination entity, the call may be routed to the PSTN network, incurring unexpected charges or causing a downstream VoIP network element to reject the call setup. Many network elements that will process URIs containing this parameter will maintain trust relationships with others. If such a URI is received from an entity outside the trust boundary of the recipient, then that recipient entity may reasonably ignore it and make an ENUM query itself. In so doing, it can avoid this potential attack.
「enumdi」不法「TEL」URIに挿入される場合、「TEL」URIは、宛先エンティティへの途中でを運ぶシグナリングメッセージは、コールが予期しない電荷を発生または下流のVoIPを引き起こし、PSTNネットワークにルーティングすることができる場合コールセットアップを拒否するネットワーク要素。このパラメータを含むURIは他の人との信頼関係を維持します処理する多くのネットワーク要素。そのようなURIは、受信者の信頼境界外のエンティティから受信された場合、その受信者の実体は、合理的にそれを無視して、ENUMクエリー自体を行うことができます。そうすることで、この潜在的な攻撃を回避することができます。
It is less a problem if the "enumdi" is illegally removed. An additional ENUM query may be performed to retrieve the routing number information and have the "enumdi" included again.
「enumdi」が不正に削除された場合にはあまり問題です。追加のENUMクエリーは、ルーティング番号情報を取得するために行うことができ、「enumdiは」再び含まれています。
It is RECOMMENDED that protocols carrying the "tel" URI ensure message integrity during the message transfer between the two communicating network elements so as to detect any unauthorised changes to the content of the "tel" URI and other information.
「TEL」URIと他の情報の内容に不正な変更を検出するように、「TEL」URIを搬送するプロトコルは、2つの通信ネットワーク要素間のメッセージ転送中にメッセージの完全性を保証することが推奨されます。
This document does not itself require any IANA actions.
このドキュメントは、自身が任意のIANAのアクションを必要としません。
It does define a parameter for the "tel" URI. Further information on a registry for such parameters is covered in the IANA "tel" URI Parameter Registry [7].
これは、「TEL」URIのためのパラメータを定義しません。このようなパラメータのレジストリの詳細は、IANA「TEL」に覆われているURIパラメータレジストリ[7]。
Many thanks for the thorough review provided by Alex Mayrhofer.
アレックスMayrhoferが提供する徹底的な見直しのための多くのおかげで。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
[1]ブラドナーのは、S.は、RFC 2119、BCP 14、1997年3月 "のRFCsにおける使用のためのレベルを示すために"。
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[2]クロッカー、D.、およびP. Overell、 "構文仕様のための増大しているBNF：ABNF"、RFC 4234、2005年10月。
[3] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, February 2005.
[3] ITU-T、 "国際公共通信番号プラン"、勧告E.164を、2005年2月。
[4] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[4] Faltstrom、P.及びM. Mealling、 "ユニフォームリソース識別子にE.164（URI）ダイナミックな委譲発見システム（DDDS）アプリケーション（ENUM）"、RFC 3761、2004年4月。
[5] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[5] Schulzrinneと、H.、 "電話番号については、TEL URI"、RFC 3966、2004年12月に。
[6] 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.
[6]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[7] Jennings, C. and V. Gurbani, "The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry", Work in Progress, May 2006.
[7]ジェニングス、C.およびV. Gurbani、 "番号機関（IANA）のtel URI（Uniform Resource Identifier）でパラメータレジストリの割り当てインターネット"、進歩、2006年5月での作業。
Authors' Addresses
著者のアドレス
Richard Stastny Oefeg Postbox 147 1103 Vienna Austria
リチャードStastny Oefeg郵便受け147 1103ウィーンオーストリア
Phone: +43-664-420-4100 EMail: Richard.stastny@oefeg.at
電話：+ 43-664-420-4100電子メール：Richard.stastny@oefeg.at
Richard Shockey Neustar Inc. 46000 Center Oak Plaza Sterling, VA 20166 United States
リチャードショッキーNeustar社46000センターオークプラザスターリング、バージニア州20166米国
Phone: +1-571-434-5651 EMail: richard.shockey@neustar.biz
電話：+ 1-571-434-5651 Eメール：richard.shockey@neustar.biz
Lawrence Conroy Roke Manor Research Roke Manor Romsey United Kingdom
ローレンスコンロイRokeマナー研究Rokeマナーロムジーイギリス
Phone: +44-1794-833666 EMail: lconroy@insensate.co.uk
電話：+ 44-1794-833666電子メール：lconroy@insensate.co.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
著作権（C）IETFトラスト（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST, AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書およびここに含まれる情報は、上に提供される基礎とCONTRIBUTOR、ORGANIZATION彼/彼女が表すOR（もしあれば）後援が「そのまま」、インターネット学会、IETFトラスト、インターネットエンジニアリングタスクフォース放棄情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されないすべての保証、明示または黙示、。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。