[要約] RFC 4759は、"tel" URIのENUM Dip Indicatorパラメータに関する仕様です。このRFCの目的は、電話番号のENUMディップインジケータを定義し、電話番号のENUM解決プロセスを改善することです。
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
"tel" uriのEnum Dipインジケーターパラメーター
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).
Copyright（c）The IETF Trust（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.
このドキュメントでは、「Tel」ユニフォームリソース識別子（URI）の新しいパラメーター「Enumdi」を定義して、Voice over Internet Protocol（VoIP）ネットワーク要素の列挙クエリの処理をサポートします。VoIPネットワーク要素は、E.164番号を含むURIを受信する場合があります。この場合、そのURIには「Enumdi」パラメーターが含まれています。「Enumdi」パラメーターの存在は、以前のVoIPネットワーク要素によってE.164番号で列挙クエリが既に実行されていることを示しています。同様に、VoIPネットワーク要素がそのようなURIを送信する場合、この番号で列挙クエリが実行されていると主張します。
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]数値を処理するために、さまざまな方法でセットアップできます。一般的なアプローチの1つは、RFC 3761 [4]で定義されている列挙列を照会し、返される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.
列挙クエリが結果につながる場合、それに応じてコールが設定されます。列挙クエリが最終的に結果につながらない場合、別のデータベースがクエリになっている可能性があります。そうすることで、呼び出しは別のVoIPネットワーク要素にルーティングされる場合があります。この次のVoIP要素へのシグナリングで、「Tel」URI（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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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]で説明されているように、拡張されたBackus-Naurフォーム（ABNF）を使用して、RFC 3966 [5]のABNFで定義された「PAR」生産の構文を拡張します。
par =/ enum-dip-indicator
par =/ enum-dip-indicator
enum-dip-indicator = ";enumdi"
enum-dip-indicator = "; 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.
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.
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」パラメーターを含む受信した「Tel」URIを処理する方法、またはE164.ARPAでクエリ列を獲得する方法について説明します。特定の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ネットワーク要素が「Enumdi」パラメーターを含む「Tel」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.
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を以前に送信する前にそれを剥がすか、代わりに独自の列挙クエリを実行し、それに応じて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で列挙されている場合。特定の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で列挙されている場合。与えられた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」を取得した「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で列挙されている場合。特定のe.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 Tel：441632960038を受信します。VoIPネットワーク要素は、8.3.0.0.6.9.9.2.2.3.6.1.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.441632960038を受け取ります。code = 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 Tel：441632960038を受信します。VoIPネットワーク要素は、8.3.0.0.6.9.9.2.2.3.6.1.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.4.441632960038を受け取ります。同じ「Tel」URIを返信して受け取ります（つまり、Tel：441632960038）。
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
In addition to those security implications discussed in the "tel" URI [5] specification, there are new security implications associated with the defined parameter.
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が宛先エンティティに向かう途中の信号メッセージがPSTNネットワークにルーティングされ、予期しない請求が発生したり、下流のVoIPが発生したりする場合があります。コールのセットアップを拒否するネットワーク要素。このパラメーターを含むURIを処理する多くのネットワーク要素は、他の人との信頼関係を維持します。そのようなURIが受信者の信託境界外のエンティティから受け取られた場合、その受信者エンティティはそれを合理的に無視し、列挙クエリ自体を作成する可能性があります。そうすることで、この潜在的な攻撃を回避できます。
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.
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.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、RFC 2119、BCP 14、1997年3月。
[2] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[2] Crocker、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。and 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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、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]
Authors' Addresses
著者のアドレス
Richard Stastny Oefeg Postbox 147 1103 Vienna Austria
リチャード・スタストニー・オフェグ・ポストボックス147 1103ウィーン・オーストリア
Phone: +43-664-420-4100
EMail: Richard.stastny@oefeg.at
Richard Shockey Neustar Inc. 46000 Center Oak Plaza Sterling, VA 20166 United States
リチャード・ショッキー・ノイスター・インク46000センター・オーク・プラザ・スターリング、バージニア州20166アメリカ合衆国
Phone: +1-571-434-5651
EMail: richard.shockey@neustar.biz
Lawrence Conroy Roke Manor Research Roke Manor Romsey United Kingdom
ローレンスコンロイロークマナーリサーチロークマナーロムジーイギリス
Phone: +44-1794-833666
EMail: lconroy@insensate.co.uk
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2006).
Copyright（c）The IETF Trust（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.
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.
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.