Network Working Group R. Mahy
Request for Comments: 5028 Plantronics
Category: Standards Track October 2007
Network Working Group R. Mahy
Request for Comments: 5028 Plantronics
Category: Standards Track October 2007
A Telephone Number Mapping (ENUM) Service Registration for Instant Messaging (IM) Services
即时消息（IM）服务的电话号码映射（ENUM）服务注册
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）。本备忘录的分发不受限制。
Abstract
摘要
This document registers a Telephone Number Mapping (ENUM) service for Instant Messaging (IM). Specifically, this document focuses on provisioning 'im:' URIs (Uniform Resource Identifiers) in ENUM.
本文档注册了即时消息（IM）的电话号码映射（ENUM）服务。具体而言，本文档重点介绍在枚举中设置“im:”URI（统一资源标识符）。
ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that uses DNS (Domain Name Service, RFC 1034 [2]) to translate telephone numbers, such as '+12025550100', into URIs (Uniform Resource Identifiers, RFC 3986 [3]), such as 'im:user@example.com'. ENUM exists primarily to facilitate the interconnection of systems that rely on telephone numbers with those that use URIs to identify resources.
ENUM（E.164数字映射，RFC 3761[1]）是一个使用DNS（域名服务，RFC 1034[2]）将电话号码（如“+12025550100”）转换为URI（统一资源标识符，RFC 3986[3]）的系统，如“im:user@example.com'. ENUM的存在主要是为了促进依赖电话号码的系统与使用URI识别资源的系统之间的互连。
Instant Messaging (IM) is a service defined in RFC 2778 [6] that allows users to send and receive typically short, often textual messages in near real-time. The IETF has defined a generic URI used to identify an IM service for a particular resource: the 'im:' URI scheme (defined in RFC 3861 [4]). RFC 3861 [4] also defines rules for discovering service running specific protocols, such as SIP (the Session Initiation Protocol, RFC 3261 [8]) and XMPP (the eXtensible Messaging and Presence Protocol, RFC 3921 [9]) from a specific 'im:' URI.
即时消息（IM）是RFC 2778[6]中定义的一项服务，它允许用户以近乎实时的方式发送和接收通常为短消息，通常为文本消息。IETF定义了一个通用URI，用于标识特定资源的IM服务：“IM:”URI方案（在RFC 3861[4]中定义）。RFC 3861[4]还定义了从特定的“im:”URI发现运行特定协议的服务的规则，如SIP（会话启动协议，RFC 3261[8]）和XMPP（可扩展消息和状态协议，RFC 3921[9]）。
RFC 3953 [10] already defines an enumservice for presence services, which returns 'pres:' URIs (also defined in RFC 3861 [4]). This document registers an enumservice for advertising IM information associated with an E.164 number.
RFC 3953[10]已经为状态服务定义了一个enumservice，它返回“pres:”URI（也在RFC 3861[4]中定义）。本文档注册了一个enumservice，用于发布与E.164号码相关的IM信息。
As defined in RFC 3761 [1], the following is a template covering information needed for the registration of the enumservice specified in this document:
如RFC 3761[1]中所定义，以下模板涵盖了注册本文档中指定的enumservice所需的信息：
Enumservice Name: "im" Enumservice Type: "im" Enumservice Subtypes: N/A URI scheme(s): "im:" Functional Specification: This Enumservice indicates that the resource identified is an 'im:' URI. The 'im:' URI scheme does not identify any particular protocol that will be used to handle instant messaging receipt or delivery, rather the mechanism in RFC 3861 [4] is used to discover whether an IM protocol supported by the party querying ENUM is also supported by the target resource. Security considerations: See section 3. Intended usage: COMMON Author: Rohan Mahy (rohan@ekabal.com)
Enumservice名称：“im”Enumservice类型：“im”Enumservice子类型：不适用URI方案：“im:”功能规范：此Enumservice表示标识的资源是“im:”URI。“im:”URI方案没有标识任何将用于处理即时消息接收或传递的特定协议，而是使用RFC 3861[4]中的机制来发现目标资源是否也支持查询枚举的参与方支持的im协议。安全注意事项：见第3节。预期用途：共同作者：Rohan Mahy(rohan@ekabal.com)
The Domain Name System (DNS) does not make policy decisions about which records it provides to a DNS resolver. All DNS records must be assumed to be available to all inquirers at all times. The information provided within an ENUM record set must therefore be considered open to the public -- which is a cause for some privacy considerations.
域名系统（DNS）不会就向DNS解析程序提供哪些记录做出策略决定。必须假设所有DNS记录在任何时候都可供所有查询者使用。因此，枚举记录集中提供的信息必须被视为对公众开放——这是一些隐私考虑的原因。
Revealing an 'im:' URI by itself is unlikely to introduce many privacy concerns, although, depending on the structure of the URI, it might reveal the full name or employer of the target. The use of anonymous URIs mitigates this risk.
透露“im:”URI本身不太可能引起很多隐私问题，不过，根据URI的结构，它可能会透露目标公司的全名或雇主。匿名URI的使用减轻了这种风险。
As ENUM uses DNS, which in its current form is an insecure protocol, there is no mechanism for ensuring that the answer returned to a query is authentic. An analysis of threats specific to the dependence of ENUM on the DNS is provided in RFC 3761, and a thorough analysis of threats to the DNS itself is covered in RFC 3833 [11]. Many of these problems are prevented when the resolver verifies the
由于ENUM使用DNS（目前的形式是一种不安全的协议），因此没有任何机制来确保返回到查询的答案是真实的。RFC 3761中提供了针对ENUM对DNS依赖性的特定威胁分析，RFC 3833[11]中涵盖了对DNS本身威胁的彻底分析。当解析器验证
authenticity of answers to its ENUM queries via DNSSEC [5] in zones where it is available.
在可用区域内，通过DNSSEC[5]对其枚举查询的答案的真实性。
More serious security concerns are associated with potential attacks against an underlying Instant Messaging system (for example, message forgery and tampering). For this reason, IM protocols have a number of security requirements (detailed in RFC 2779 [7]) that call for authentication, integrity and confidentiality properties, and similar measures to prevent such attacks. Any instant messaging protocol used in conjunction with the 'im:' URI scheme is required to meet these requirements.
更严重的安全问题与针对底层即时消息系统的潜在攻击有关（例如，消息伪造和篡改）。因此，IM协议有许多安全要求（详见RFC 2779[7]），要求认证、完整性和机密性属性，以及防止此类攻击的类似措施。任何与“im:”URI方案结合使用的即时消息协议都需要满足这些要求。
Unlike a traditional telephone number, the resource identified by an 'im:' URI may require that callers provide cryptographic credentials for authentication and authorization before instant messages are exchanged. In concert with instant messaging protocols, ENUM can actually provide far greater protection from unwanted callers than does the existing PSTN, despite the public availability of ENUM records.
与传统电话号码不同，“im:”URI标识的资源可能要求呼叫者在交换即时消息之前提供用于身份验证和授权的加密凭据。与即时消息协议相结合，尽管ENUM记录公开可用，但与现有PSTN相比，ENUM实际上可以提供更大的保护，防止不需要的呼叫者。
This document requests registration of the "im" Enumservice according to the definitions in this document and RFC 3761 [1].
本文件要求根据本文件和RFC 3761[1]中的定义注册“im”Enumservice。
[1] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[1] Faltstrom，P.和M.Mealling，“E.164到统一资源标识符（URI）动态委托发现系统（DDDS）应用程序（ENUM）”，RFC 3761，2004年4月。
[2] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[2] Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，1987年11月。
[3] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[3] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[4] Peterson, J., "Address Resolution for Instant Messaging and Presence", RFC 3861, August 2004.
[4] Peterson，J.，“即时消息和状态的地址解析”，RFC 38612004年8月。
[5] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[5] Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[6] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[6] Day，M.，Rosenberg，J.，和H.Sugano，“状态和即时信息模型”，RFC 27782000年2月。
[7] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[7] Day，M.，Aggarwal，S.，Mohr，G.，和J.Vincent，“即时消息传递/存在协议要求”，RFC 2779，2000年2月。
[8] 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.
[8] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[9] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004.
[9] Saint Andre，P.，Ed.，“可扩展消息和状态协议（XMPP）：即时消息和状态”，RFC 39212004年10月。
[10] Peterson, J., "Telephone Number Mapping (ENUM) Service Registration for Presence Services", RFC 3953, January 2005.
[10] Peterson，J.，“状态服务的电话号码映射（ENUM）服务注册”，RFC 3953，2005年1月。
[11] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[11] Atkins，D.和R.Austein，“域名系统（DNS）的威胁分析”，RFC 38332004年8月。
Author's Address
作者地址
Rohan Mahy Plantronics
Rohan Mahy Plantronics公司
EMail: rohan@ekabal.com
EMail: rohan@ekabal.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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.