Network Working Group R. Stastny
Request for Comments: 4759 Oefeg
Category: Standards Track R. Shockey
Neustar Inc.
L. Conroy
Roke Manor Research
November 2006
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的枚举倾斜指示器参数
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.
本文档为“tel”统一资源标识符（URI）定义了一个新参数“enumdi”，以支持在VoIP网络元素中处理ENUM查询。VoIP网元可以接收包含E.164号码的URI，其中该URI包含“enumdi”参数。“enumdi”参数的存在表示先前的VoIP网元已经对E.164号码执行了ENUM查询。同样，如果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
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]中定义的枚举，并使用返回的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查询没有最终导致结果，则可以查询另一个数据库和/或最终将呼叫路由到公共交换电话网（PSTN）。这样，呼叫可以路由到另一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].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照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]中所述的增广巴科斯诺尔形式（ABNF）来扩展RFC 3966[5]中ABNF中定义的“par”产品的语法。
par =/ enum-dip-indicator
PAR＝/Enm倾角指示器
enum-dip-indicator = ";enumdi"
枚举倾斜指示器=“；枚举DI”
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中最多只能出现一次。
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.
域提供程序可以根据自己的选择，使用包含枚举dip指示符的“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网元接收到包含“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.
请注意，如果接收方网元与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之前将其剥离，或者执行自己的枚举查询，并相应地将参数添加到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（通常称为“NXDOMIN”），则如果该网元选择使用“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 查询结果包括一个NAPTR资源记录，其中包含一个具有相同E.164编号的“tel”URI，或
o the result of the query includes a NAPTR resource record containing a "tel" URI with the "enumdi" parameter set,
o 查询结果包括一个NAPTR资源记录，其中包含一个设置了“enumdi”参数的“tel”URI，
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时。对于给定的E.164号码，并且结果是一个“tel”URI，该URI具有不同的E.164号码，该号码缺少enum dip指示符，客户端可以对该号码执行另一个查询，或者根据本地策略传递请求。
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:+44163296038。VoIP网元在DNS中查询8.3.0.0.6.9.2.3.6.1.4.4.e164.arpa中的NAPTR资源记录，并获得代码为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
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:+44163296038。VoIP网元在8.3.0.0.6.9.2.3.6.1.4.4.e164.arpa.中查询DNS中的NAPTR资源记录，并接收相同的“tel”URI作为回复（即电话：+44163296038）。
The VoIP network element decides to route the call to the PSTN via another VoIP network element called gw.example.com.
VoIP网元决定通过另一个名为gw.example.com的VoIP网元将呼叫路由到PSTN。
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
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.
除了“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.
如果当承载“tel”URI的信令消息正在路由到目的地实体时，“enumdi”被非法插入到“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.
如果“enumdi”被非法删除，问题就不会那么严重了。可以执行额外的枚举查询以检索路由号码信息并再次包括“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的内容和其他信息的任何未经授权的更改。
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.
非常感谢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 42342005年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.，“电话号码的电话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：会话启动协议”，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] Jennings，C.和V.Gurbani，“互联网分配号码管理局（IANA）电话统一资源标识符（URI）参数注册表”，正在进行的工作，2006年5月。
Authors' Addresses
作者地址
Richard Stastny Oefeg Postbox 147 1103 Vienna Austria
Richard Stastny Oefeg邮箱147 1103奥地利维也纳
Phone: +43-664-420-4100
EMail: Richard.stastny@oefeg.at
Phone: +43-664-420-4100
EMail: Richard.stastny@oefeg.at
Richard Shockey Neustar Inc. 46000 Center Oak Plaza Sterling, VA 20166 United States
Richard Shockey Neustar Inc.美国弗吉尼亚州斯特林中心橡木广场46000号，邮编20166
Phone: +1-571-434-5651
EMail: richard.shockey@neustar.biz
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
Phone: +44-1794-833666
EMail: 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。