Network Working Group G. Vaudreuil
Request for Comments: 4238 Lucent Technologies
Category: Standards Track October 2005
Network Working Group G. Vaudreuil
Request for Comments: 4238 Lucent Technologies
Category: Standards Track October 2005
Voice Message Routing Service
语音消息路由服务
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 Internet Society (2005).
版权所有（C）互联网协会（2005年）。
Abstract
摘要
Voice messaging is traditionally addressed using telephone number addressing. This document describes two techniques for routing voice messages based on a telephone number. The complete service uses the Voice Profile for Internet Mail (VPIM) Directory service to lookup a VPIM email address with a telephone number and confirm that the address is both valid and associated with the intended recipient. However, this service will take time to become widely deployed in the near term. This document also describes a basic send-and-pray service that routes and delivers messages using only the ENUM telephone number resolution service and the existing DNS mail routing facilities.
语音信息通常使用电话号码寻址。本文档描述了基于电话号码路由语音消息的两种技术。完整服务使用互联网邮件语音配置文件（VPIM）目录服务查找带有电话号码的VPIM电子邮件地址，并确认该地址有效且与预期收件人关联。然而，这项服务在短期内要得到广泛部署还需要时间。本文档还描述了一种基本的发送和祈祷服务，该服务仅使用ENUM电话号码解析服务和现有DNS邮件路由设施来路由和传递消息。
Table of Contents
目录
1. Design Goals ....................................................2
2. The Complete Service ............................................3
2.1. Specification of Service "E2U+VPIM:LDAP" ...................3
2.2. VPIM Directory Discovery ...................................4
2.3. Address Query ..............................................4
3. The Basic Service ...............................................4
3.1. Specification of Service "E2U+VPIM:Mailto:" ................5
3.2. Address Construction .......................................6
3.3. Interdomain Message Routing ................................6
3.4. Intradomain Message Routing ................................6
3.4.1. Directory-Enabled Routing ...........................6
3.4.2. Service-based Mail Routing ..........................7
4. Security Considerations .........................................7
4.1. Unsolicited Bulk Email .....................................7
4.2. DNS-based Attacks ..........................................7
5. IANA Considerations .............................................8
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................8
1. Design Goals ....................................................2
2. The Complete Service ............................................3
2.1. Specification of Service "E2U+VPIM:LDAP" ...................3
2.2. VPIM Directory Discovery ...................................4
2.3. Address Query ..............................................4
3. The Basic Service ...............................................4
3.1. Specification of Service "E2U+VPIM:Mailto:" ................5
3.2. Address Construction .......................................6
3.3. Interdomain Message Routing ................................6
3.4. Intradomain Message Routing ................................6
3.4.1. Directory-Enabled Routing ...........................6
3.4.2. Service-based Mail Routing ..........................7
4. Security Considerations .........................................7
4.1. Unsolicited Bulk Email .....................................7
4.2. DNS-based Attacks ..........................................7
5. IANA Considerations .............................................8
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................8
This profile is intended to provide a range of functional capabilities for message routing based on one of two mechanisms. The most complete service should use the ENUM address resolution service to determine the VPIM directory, and then use LDAP to retrieve the VPIM-specific email address that will be used for message routing.
此配置文件旨在基于两种机制之一为消息路由提供一系列功能。最完整的服务应使用枚举地址解析服务确定VPIM目录，然后使用LDAP检索将用于消息路由的VPIM特定电子邮件地址。
The more basic send-and-pray message service uses only the ENUM service and MX records to route the message to the intended recipient's domain. The intelligence to further route the message to the intended recipient is placed within the message routing system of the recipient's domain.
更基本的发送和祈祷消息服务仅使用枚举服务和MX记录将消息路由到预期收件人的域。将消息进一步路由到预期收件人的智能被放置在收件人域的消息路由系统中。
The basic mechanism may be used even when there is a VPIM directory service available. The basic service is useful when LDAP queries are not available, such as may be the case for disconnected mobile terminals or because of firewall or information security policies.
即使有VPIM目录服务可用，也可以使用基本机制。当LDAP查询不可用时，基本服务很有用，例如断开连接的移动终端，或者由于防火墙或信息安全策略的原因。
The basic mechanism should facilitate the routing of VPIM messages to a suitable internal destination with a minimum of configuration. It is an important goal to avoid any content-processing to determine the nature of the message and its internal destination. At a minimum, it should be possible to establish a simple mail forwarding rule that
基本机制应便于将VPIM消息路由到适当的内部目的地，且配置最少。避免任何内容处理以确定消息的性质及其内部目的地是一个重要目标。至少，应该可以建立一个简单的邮件转发规则
sends all inbound VPIM messages to a designated system, while facilitating the routing of FAX, SMS, or other telephone-addressed messages to other potentially different systems.
将所有入站VPIM消息发送到指定系统，同时方便将传真、SMS或其他电话寻址消息路由到其他可能不同的系统。
It is a goal that the mechanisms outlined in this document be extensible for all store-and-forward, telephone-number addressed messaging services.
本文档中概述的机制可以扩展到所有存储转发、电话号码寻址的消息服务，这是一个目标。
It is a goal that the VPIM directory discovery and VPIM directory query steps occur within the timing constraints for user interfaces in PSTN networks. 95% of the time, that constraint can be a two-second response.
VPIM目录发现和VPIM目录查询步骤的目标是在PSTN网络中用户界面的时间限制内进行。95%的情况下，该约束可能是两秒钟的响应。
For the complete VPIM message routing service, the sending client SHOULD query the VPIM directory for the VPIM-specific email address. The client SHOULD use the ENUM service to retrieve the identity of the VPIM Directory to query. The client should then query that server for the email address and any additional attributes desired.
对于完整的VPIM消息路由服务，发送客户端应在VPIM目录中查询特定于VPIM的电子邮件地址。客户端应使用枚举服务检索要查询的VPIM目录的标识。然后，客户机应向该服务器查询电子邮件地址和所需的任何其他属性。
* Service Name: E.164 to VPIM LDAP URL
* 服务名称：E.164到VPIM LDAP URL
* URI Type: "LDAP:"
* URI类型：“LDAP：”
* Type: VPIM
* 类型：VPIM
* Subtype: LDAP
* 子类型：LDAP
* Functional Specification: See sections 3.2 through 3.3
* 功能规范：见第3.2节至第3.3节
* Intended Usage: COMMON
* 预期用途：普通
* Author: Greg Vaudreuil (gregv@ieee.org)
* 作者：Greg Vaudreuil(gregv@ieee.org)
* Security Considerations:
* 安全考虑：
o Malicious Redirection
o 恶意重定向
One of the fundamental dangers related to any service such as this is that a malicious entry in a resolver's database will cause clients to resolve the E.164 into the wrong LDAP URL. The possible intent may be to cause the client to connect to a rogue LDAP server and retrieve (or fail to retrieve) a resource containing fraudulent or damaging information.
与此类服务相关的基本危险之一是，解析程序数据库中的恶意条目将导致客户端将E.164解析为错误的LDAP URL。可能的目的是使客户机连接到恶意LDAP服务器并检索（或无法检索）包含欺诈或破坏性信息的资源。
o Denial of Service
o 拒绝服务
By removing the URL to which the E.164 maps, a malicious intruder may remove the client's ability to access the LDAP directory server.
通过删除E.164映射到的URL，恶意入侵者可能会删除客户端访问LDAP目录服务器的能力。
The VPIM directory server is found by using the ENUM protocol and querying for the VPIMDIR service associated with the telephone number of the recipient.
VPIM目录服务器是通过使用ENUM协议并查询与收件人电话号码关联的VPIMDIR服务来找到的。
The DNS query name is created as described by [ENUM]. The telephone number used for the directory location MAY contain additional sub-address information as additional digits.
DNS查询名称按[ENUM]所述创建。用于目录位置的电话号码可能包含作为附加数字的附加子地址信息。
Example:
例子：
Query: 2.1.2.1.5.5.5.3.1.6.1.e164.arpa Responses: IN NAPTR 10 10 "U" "E2U+VPIM:LDAP" \ "!^.*$!ldap://vdir1.Zcorp.com/telephoneNumber=\1!" .
查询：2.1.2.1.5.5.3.1.6.1.e164.arpa响应：在NAPTR 10 10“U”中E2U+VPIM:LDAP“\”！^.*$！ldap://vdir1.Zcorp.com/telephoneNumber=\1!" .
IN NAPTR 10 20 "U" " E2U+VPIM:LDAP" \ "!^.*$!ldap://vdir2.Zcorp.com/telephoneNumber=\1!" .
在NAPTR 10 20“U”E2U+VPIM中：LDAP“\”！^.*$！ldap://vdir2.Zcorp.com/telephoneNumber=\1!" .
It is recommended that VPIMDIR servers be deployed in a redundant configuration. NAPTR weight fields provide the ability to give two records indicating the same service and preference a different weight. The same weight can be specified for random distribution between the two servers. See [NAPTR-1, NAPTR-2, NAPTR-3, NAPTR-4]
建议在冗余配置中部署VPIMDIR服务器。NAPTR权重字段能够为指示相同服务和偏好的两条记录提供不同的权重。可以为两台服务器之间的随机分布指定相同的权重。见[NAPTR-1、NAPTR-2、NAPTR-3、NAPTR-4]
Once the VPIM directory is discovered, the client SHOULD issue an LDAP query for the vPIMrFC822Mailbox, that is, the address that SHOULD be used as the value for both the RFC 822 To: field and the SMTP RCPT command. See [VPIMDIR].
发现VPIM目录后，客户端应发出vPIMrFC822Mailbox的LDAP查询，即应用作RFC 822 To:字段和SMTP RCPT命令值的地址。见[VPIMDIR]。
The basic service relies upon NAPTR rewrite rules to mechanically construct a valid VPIM-specific email address. In the recipient's domain, the constructed address may be further routed using intradomain mail routing techniques.
基本服务依赖NAPTR重写规则来机械地构造有效的VPIM特定电子邮件地址。在接收者的域中，可以使用域内邮件路由技术进一步路由构造的地址。
To facilitate a full range of intradomain routing options, the constructed email address indicates that the message is a VPIM message. For ease of processing in the recipient's intradomain mail routing system, the indication that the message is a VPIM message SHOULD be in the domain name portion.
为了方便提供全方位的域内路由选项，构造的电子邮件地址表示该消息是VPIM消息。为了便于在收件人的域内邮件路由系统中进行处理，应在域名部分显示消息是VPIM消息。
Note that there is no assurance the constructed address is valid, nor that the constructed address corresponds to the intended recipient. Because no capabilities information is provided about the recipient, messages sent with this mechanism SHOULD be sent using only the media and content types of the VPIM V2 profile.
请注意，不能保证构造的地址是有效的，也不能保证构造的地址对应于预期的收件人。由于未提供有关收件人的功能信息，因此使用此机制发送的邮件应仅使用VPIM V2配置文件的媒体和内容类型发送。
* Service Name: E.164 to VPIM MailTo: URL
* 服务名称：E.164至VPIM邮箱：URL
* URI Type: "Mailto:"
* URI类型：“Mailto：”
* Type: VPIM
* 类型：VPIM
* Subtype: MAILTO
* 子类型：MAILTO
* Functional Specification: See sections 4.2 through 4.4
* 功能规范：见第4.2节至第4.4节
* Intended Usage: COMMON
* 预期用途：普通
* Author: Greg Vaudreuil (gregv@ieee.org)
* 作者：Greg Vaudreuil(gregv@ieee.org)
* Error Conditions:
* 错误条件：
o E.164 number not in the numbering plan
o E.164编号计划中没有编号
o E.164 number in the numbering plan, but no URLs exist for that number
o E.164编号计划中的编号，但该编号不存在URL
o E2U+VPIM:Mailto Service unavailable
o E2U+VPIM:邮件发送服务不可用
* Security Considerations:
* 安全考虑：
o Malicious Redirection
o 恶意重定向
One of the fundamental dangers related to any service such as this is that a malicious entry in a resolver's database will cause clients to resolve the E.164 into the wrong email URL. The possible intent may be to cause the client to send the information to an incorrect destination.
与此类服务相关的基本危险之一是，解析程序数据库中的恶意条目将导致客户端将E.164解析为错误的电子邮件URL。可能的意图是导致客户端将信息发送到错误的目的地。
o Denial of Service
o 拒绝服务
By removing the URL to which the E.164 maps, a malicious intruder may remove the client's ability to access the resource.
通过删除E.164映射到的URL，恶意入侵者可能会删除客户端访问资源的能力。
o Unsolicited Bulk Email
o 未经请求的批量电子邮件
The exposure of email addresses through the ENUM service provides a bulk mailer access to large numbers of email addresses where only the telephone number was previously known.
通过ENUM服务公开电子邮件地址，使大量邮件收发人员能够访问以前只知道电话号码的大量电子邮件地址。
Construct a VPIM email address using the address rewrite rules of the NAPTR records associated with the VPIM service.
使用与VPIM服务关联的NAPTR记录的地址重写规则构造VPIM电子邮件地址。
The interdomain routing of a constructed VPIM address is mechanically indistinguishable from existing email routing. No changes to the infrastructure are required. The sending system consults the Domain Name System for an MX record corresponding to the domain name and forwards the message to the indicated system.
构造的VPIM地址的域间路由与现有电子邮件路由在机械上无法区分。不需要对基础设施进行任何更改。发送系统向域名系统咨询与域名对应的MX记录，并将消息转发到指定的系统。
Within the recipient's domain, the message may be further routed to the appropriate messaging system. Two general mechanisms may be used to further route the message to the intended system within a network.
在接收者的域内，消息可以进一步路由到适当的消息传递系统。两种通用机制可用于进一步将消息路由到网络内的预期系统。
Note: This section is strictly informational. The mechanisms for intradomain routing are an internal matter for the domain and do not affect the protocol. It is only necessary that the addresses created by the NAPTR rewrite rules have meaning to the domain advertising them. However, a convention for the creation and use of such addresses may be useful.
注：本节仅供参考。域内路由机制是域的内部事务，不影响协议。只需要NAPTR重写规则创建的地址对公布它们的域具有意义。然而，创建和使用此类地址的约定可能有用。
Various proprietary directory mechanisms provide a means for an inbound mail router of the recipient's domain to send a message to the appropriate internal mail host. In many cases, the local part of the address is used to query for an internal mail address. That internal mail address is substituted for the SMTP RCPT address and used to deliver the message to the recipient mailbox. Note that the mailbox does not need to have any knowledge of the mechanically-constructed telephone number-based address.
各种专有目录机制为收件人域的入站邮件路由器提供了将邮件发送到适当的内部邮件主机的方法。在许多情况下，地址的本地部分用于查询内部邮件地址。该内部邮件地址将取代SMTP RCPT地址，并用于将邮件传递到收件人邮箱。请注意，邮箱不需要知道机械构造的基于电话号码的地址。
Example address: +12145551212@sp.net
Example address: +12145551212@sp.net
Alternately, a mail gateway may simply send all voice messages into a separate messaging system. That system may be a single voice messaging server or a service-specific gateway into a larger telephone number-based voice-messaging network.
或者，邮件网关可以简单地将所有语音消息发送到单独的消息传递系统中。该系统可以是单个语音消息服务器，也可以是接入更大的基于电话号码的语音消息网络的特定于服务的网关。
Such a mail gateway may be provisioned with a simple rule or small set of rules to forward all messages of a given service type to a pre-defined server. This rule would check for the service name "VPIM" as a prefix to the constructed domain name to reroute messages.
这样的邮件网关可以设置有一个简单的规则或一组小的规则，以将给定服务类型的所有消息转发到预定义的服务器。此规则将检查服务名称“VPIM”作为构造的域名的前缀，以重新路由消息。
Example address: +12145551212@VPIM.sp.net
Example address: +12145551212@VPIM.sp.net
There is little information disclosed to the sender of the message that is not already disclosed using standard email protocols. The ability to use this protocol to probe for valid addresses is identical to the sending of test messages and waiting for a non-delivery notification in return.
向消息发送者披露的信息很少，而这些信息是使用标准电子邮件协议尚未披露的。使用此协议探测有效地址的能力与发送测试消息并等待未送达通知的能力相同。
However, the use of ENUM records to create routable email addresses from telephone numbers provides bulk-emailers the capabilities to send email to a large set of recipients where only the telephone number is known or where telephone numbers are guessed.
但是，使用ENUM记录从电话号码创建可路由的电子邮件地址为批量电子邮件发送者提供了向大量收件人发送电子邮件的能力，其中只有电话号码是已知的或猜测电话号码。
Both the complete and basic services rely upon the DNS to provide the information necessary to validate a recipient or send a message. The message sender is a casual, unauthenticated use of the indicated servers, and relies upon the DNS for accurate information. If the DNS is compromised, an attacker can redirect messages by providing a malicious email address or indicating a rogue directory with malicious LDAP URL's. Use of DNS Security protocols [DNSSEC] substantially reduces the risk of a domain being hijacked. If the E.164 zone is secured with DNSSEC, then the attack is precluded if the client can trust the key used to sign the zone. DNS security does not protect against the LDAP service being independently compromised. Further discussion on the risk to this LDAP service is provided in [VPIMDIR].
完整服务和基本服务都依赖DNS来提供验证收件人或发送消息所需的信息。消息发送者是对指定服务器的未经验证的临时使用，并依赖DNS获取准确信息。如果DNS受损，攻击者可以通过提供恶意电子邮件地址或使用恶意LDAP URL指示恶意目录来重定向消息。DNS安全协议[DNSSEC]的使用大大降低了域名被劫持的风险。如果E.164区域由DNSSEC保护，则如果客户端可以信任用于签署该区域的密钥，则可以阻止攻击。DNS安全性不保护LDAP服务不受独立损害。[VPIMDIR]中提供了关于此LDAP服务风险的进一步讨论。
This specification registers the E2U+VPIM and E2U+Voice services according to the specifications and guidelines in RFC 3761 [ENUM] and the definitions in this document.
本规范根据RFC 3761[ENUM]中的规范和指南以及本文档中的定义注册E2U+VPIM和E2U+语音服务。
[ENUM] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[ENUM]Faltstrom，P.和M.Mealling，“E.164到统一资源标识符（URI）动态委托发现系统（DDDS）应用程序（ENUM）”，RFC 3761，2004年4月。
[NAPTR-1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[NAPTR-1]Mealling，M.“动态委托发现系统（DDDS）第一部分：综合DDDS”，RFC 3401，2002年10月。
[NAPTR-2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[NAPTR-2]Mealling，M.“动态委托发现系统（DDDS）第二部分：算法”，RFC 3402，2002年10月。
[NAPTR-3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[NAPTR-3]Mealling，M.，“动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库”，RFC 3403，2002年10月。
[NAPTR-4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.
[NAPTR-4]Mealling，M.“动态委托发现系统（DDDS）第四部分：统一资源标识符（URI）”，RFC 34042002年10月。
[VPIMDIR] Vaudreuil, G., "Voice Messaging Directory Service", RFC 4237, October 2005.
[VPIMDIR]Vaudreuil，G.，“语音信息目录服务”，RFC 4237，2005年10月。
[VPIMV2] Vaudreuil, G. and G. Parsons, "Voice Profile for Internet Mail - version 2 (VPIMv2)", RFC 3801, June 2004.
[VPIMV2]Vaudreuil，G.和G.Parsons，“互联网邮件语音配置文件-第2版（VPIMV2）”，RFC 38012004年6月。
[DNSSEC] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[DNSSEC]Arends，R.，Austein，R.，Larson，M.，Massey，D.，和S.Rose，“DNS安全介绍和要求”，RFC 4033，2005年3月。
Author's Address
作者地址
Please send comments on this document to the VPIM working group mailing list <vpim@ietf.org>.
请将对本文件的意见发送至VPIM工作组邮件列表<vpim@ietf.org>.
Gregory M. Vaudreuil Lucent Technologies 9489 Bartgis Ct Frederick, MD 21702
格雷戈里·沃德鲁伊·朗讯科技9489马里兰州弗雷德里克巴特吉斯Ct 21702
EMail: GregV@ieee.org
EMail: GregV@ieee.org
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2005).
版权所有（C）互联网协会（2005年）。
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 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.
向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编辑功能的资金目前由互联网协会提供。