Network Working Group                                        R. Brandner
Request for Comments: 4415                                    Siemens AG
Category: Standards Track                                      L. Conroy
                                             Siemens Roke Manor Research
                                                              R. Stastny
                                                                   Oefeg
                                                           February 2006
        
Network Working Group                                        R. Brandner
Request for Comments: 4415                                    Siemens AG
Category: Standards Track                                      L. Conroy
                                             Siemens Roke Manor Research
                                                              R. Stastny
                                                                   Oefeg
                                                           February 2006
        

IANA Registration for Enumservice Voice

EnumiAna语音注册服务

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 (2006).

版权所有(C)互联网协会(2006年)。

Abstract

摘要

This document registers the Enumservice "voice" (which has a defined subtype "tel"), as per the IANA registration process defined in the ENUM specification RFC 3761. This service indicates that the contact held in the generated Uniform Resource Identifier (URI) can be used to initiate an interactive voice (audio) call.

本文档按照ENUM规范RFC 3761中定义的IANA注册过程注册Enumservice“voice”(具有定义的子类型“tel”)。此服务表示生成的统一资源标识符(URI)中的联系人可用于发起交互式语音(音频)呼叫。

Table of Contents

目录

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Voice Service Registration  . . . . . . . . . . . . . . . . . . 3
   4.  Example of voice:tel Enumservice  . . . . . . . . . . . . . . . 4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
       7.1.  Normative References  . . . . . . . . . . . . . . . . . . 6
       7.2.  Informative References  . . . . . . . . . . . . . . . . . 6
        
   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Voice Service Registration  . . . . . . . . . . . . . . . . . . 3
   4.  Example of voice:tel Enumservice  . . . . . . . . . . . . . . . 4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
       7.1.  Normative References  . . . . . . . . . . . . . . . . . . 6
       7.2.  Informative References  . . . . . . . . . . . . . . . . . 6
        
1. Introduction
1. 介绍

ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that transforms E.164 numbers [2] into domain names and then uses DNS (RFC 1034 [3]) features such as delegation through NS records, and the use of Naming Authority Pointer (NAPTR) records, to look up the communication services available for a specific domain name.

ENUM(E.164数字映射,RFC 3761[1])是一个系统,它将E.164数字[2]转换为域名,然后使用DNS(RFC 1034[3])功能,例如通过NS记录进行授权,以及使用命名机构指针(NAPTR)记录,以查找特定域名的可用通信服务。

This document registers an Enumservice according to the guidelines given in RFC 3761 to be used for provisioning in the services field of a NAPTR [4] resource record to indicate what class of functionality a given endpoint offers. The registration is defined within the Dynamic Delegation Discovery System (DDDS, [5] [6] [4] [7] [8]) hierarchy, for use with the "E2U" DDDS application defined in RFC 3761.

本文档根据RFC 3761中给出的指南注册Enumservice,用于在NAPTR[4]资源记录的服务字段中进行配置,以指示给定端点提供的功能类别。注册在动态委派发现系统(DDDS[5][6][4][7][8])层次结构中定义,用于RFC 3761中定义的“E2U”DDDS应用程序。

Enumservices have a type and subtype. This latter is optional, as it may be implicit in the service type. The type defines the kind of communication session that can be initiated using the contact indicated by the URI generated by the enclosing NAPTR. In telecommunications engineering terms, it reflects the "teleservice".

Enumservices具有类型和子类型。后者是可选的,因为它可能隐含在服务类型中。该类型定义了可以使用由封装的NAPTR生成的URI指示的联系人启动的通信会话的类型。在电信工程术语中,它反映了“远程服务”。

The subtype defines the subsystem that is to be used to initiate the communication session. Note that the subtype definition is usually associated with the URI scheme that is to be used.

子类型定义用于启动通信会话的子系统。请注意,子类型定义通常与要使用的URI方案相关联。

Both the type and subtype (where present) must be supported for the NAPTR to be used by a potential correspondent.

必须同时支持类型和子类型(如果存在),才能让潜在的通讯员使用NAPTR。

There are a number of DDDS applications in addition to ENUM (for example, see [7] and [8]). However, an Enumservice indication operates only within the context of the "E2U" (ENUM) DDDS Application.

除了ENUM之外,还有许多DDDS应用程序(例如,请参见[7]和[8])。但是,Enumservice指示仅在“E2U”(ENUM)DDDS应用程序的上下文中运行。

Whilst the protocol elements that make up ENUM are defined in the above documents and in this one, further examples of the use to which these may be put are given in other documents, for example, in ETSI TS 102 172 [11].

虽然构成ENUM的协议元素在上述文件和本文件中有定义,但其他文件(例如ETSI TS 102 172[11])中给出了这些元素的进一步使用示例。

This document registers the Enumservice "voice" (which has a defined subtype "tel"), as per the IANA registration process defined in the ENUM specification RFC 3761. This service indicates that the contact held in the generated URI can be used to initiate an interactive voice (audio) call.

本文档按照ENUM规范RFC 3761中定义的IANA注册过程注册Enumservice“voice”(具有定义的子类型“tel”)。此服务表示生成的URI中的联系人可用于发起交互式语音(音频)呼叫。

2. Terminology
2. 术语

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 [9].

本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[9]中的描述进行解释。

3. Voice Service Registration
3. 语音服务注册

Enumservice Name: "voice"

枚举服务名称:“语音”

Enumservice Type: "voice"

枚举服务类型:“语音”

Enumservice Subtype: "tel"

枚举服务子类型:“电话”

URI Scheme: 'tel:'

URI方案:“电话:”

Functional Specification:

功能规格:

The kind of communication indicated by this Enumservice is "Interactive Voice". From a protocol perspective, this communication is expected to involve bidirectional media streams carrying audio data.

该服务所表示的通信类型是“交互式语音”。从协议的角度来看,该通信预期涉及承载音频数据的双向媒体流。

A client may imply that the person controlling population of a NAPTR holding this Enumservice indicates his capability to engage in an interactive voice session when contacted using the URI generated by this NAPTR.

客户机可能暗示,控制持有该服务的NAPTR人口的人表示,当使用该NAPTR生成的URI进行联系时,他有能力参与交互式语音会话。

Security Considerations:

安全考虑:

See Section 5.

见第5节。

Intended Usage: COMMON

预期用途:普通

Authors:

作者:

Rudolf Brandner, Lawrence Conroy, and Richard Stastny (for author contact detail, see Authors' Addresses section)

鲁道夫·布兰德纳、劳伦斯·康罗伊和理查德·斯塔斯尼(有关作者联系方式的详细信息,请参见作者地址部分)

Any other information the author deems interesting:

作者认为有趣的任何其他信息:

This Enumservice indicates that the person responsible for the NAPTR is accessible via the Public Switched Telephone Network (PSTN) or Public Land Mobile Network (PLMN) using the value of the generated URI.

此服务表示负责NAPTR的人员可以使用生成的URI值通过公共交换电话网络(PSTN)或公共陆地移动网络(PLMN)访问。

The kind of subsystem required to initiate a Voice Enumservice with this subtype is a "Dialer". This is a subsystem that either

使用此子类型启动语音服务所需的子系统类型是“拨号器”。这是一个子系统

provides a local connection to the PSTN or PLMN or provides an indirect connection to those networks. The subsystem will use the telephone number held in the generated URI to place a voice call. The voice call is placed to a network that uses E.164 numbers to route calls to an appropriate destination.

提供到PSTN或PLMN的本地连接,或提供到这些网络的间接连接。子系统将使用生成的URI中保留的电话号码进行语音呼叫。语音呼叫被置于使用E.164号码将呼叫路由到适当目的地的网络上。

Note that the PSTN/PLMN connection may be indirect. The end user receiving this NAPTR may have a relationship with a Communications Service Provider that accepts call initiation requests from that subsystem using an IP-based protocol such as SIP or H.323, and places the call to the PSTN using a remote gateway service. In this case, the provider either may accept requests using "tel:" URIs or has a defined mechanism to convert "tel:" URI values into a "protocol-native" form.

请注意,PSTN/PLMN连接可能是间接的。接收该NAPTR的最终用户可以与通信服务提供商有关系,该通信服务提供商使用基于IP的协议(例如SIP或H.323)接受来自该子系统的呼叫发起请求,并使用远程网关服务将呼叫放置到PSTN。在这种情况下,提供者可以使用“tel:”URI接受请求,或者具有将“tel:”URI值转换为“协议本机”形式的定义机制。

The "tel:" URI value SHOULD be fully qualified (using the "global phone number" form of RFC 3966 [10]). A "local phone number" as defined in that document SHOULD NOT be used unless the controller of the zone in which the NAPTR appears is sure that it can be distinguished unambiguously by all clients that can access the resource record and that a call from their network access points can be routed to that destination.

“tel:”URI值应该是完全限定的(使用RFC 3966[10]的“全局电话号码”形式)。不应使用该文件中定义的“本地电话号码”,除非NAPTR所在区域的控制器确保所有可以访问资源记录的客户端都可以明确区分该号码,并且可以将来自其网络接入点的呼叫路由到该目的地。

4. Example of voice:tel Enumservice
4. 语音示例:电话服务

The following is an example of the use of the Enumservice registered by this document in a NAPTR resource record.

下面是在NAPTR资源记录中使用此文档注册的Enumservice的示例。

$ORIGIN 0.6.9.2.3.6.1.4.4.e164.arpa. 3.8.0 NAPTR 10 100 "u" "E2U+voice:tel" "!^.*$!tel:+441414960000!" .

$ORIGIN 0.6.9.2.3.6.1.4.4.e164.arpa。3.8.0 NAPTR 10 100“u”E2U+语音:电话:“!^.*$!电话:+441414960000!”。

5. Security Considerations
5. 安全考虑

DNS, as used by ENUM, is a global, distributed database. Thus, any information stored there is visible to anyone anonymously. Whilst this is not qualitatively different from publication in a telephone directory, it does open the data subjects to having "their" information collected automatically without any indication that this has been done or by whom.

ENUM使用的DNS是一个全局分布式数据库。因此,存储在那里的任何信息对任何人都是匿名可见的。虽然这与在电话簿中发布没有本质上的区别,但它确实会让数据主体自动收集“他们的”信息,而没有任何迹象表明这是由谁做的。

Such data harvesting by third parties is often used to generate lists of targets for unrequested information; in short, they are used to address "spam". Anyone who uses a Web-archived mailing list is aware that the volume of "spam" email sent increases when he or she posts to the mailing list; publication of a telephone number in ENUM is no different, and may be used for attempts to send "junk faxes" or "junk SMS", for example.

第三方收集的此类数据通常用于生成未请求信息的目标列表;简而言之,它们被用来处理“垃圾邮件”。任何使用网络存档邮件列表的人都知道,当他或她向邮件列表投递邮件时,发送的“垃圾邮件”数量会增加;在ENUM中公布电话号码也没什么不同,例如,可能用于尝试发送“垃圾传真”或“垃圾短信”。

Many mailing list users have more than one email address and use "sacrificial" email accounts when posting to such lists to help filter out unrequested emails sent to them. This is not so easy with published telephone numbers; the PSTN E.164 number assignment process is much more involved and usually a single E.164 number (or a fixed range of numbers) is associated with each PSTN access. Thus, providing a "sacrificial" phone number in any publication is not possible.

许多邮件列表用户有不止一个电子邮件地址,并在向此类列表投递邮件时使用“牺牲性”电子邮件帐户,以帮助过滤发送给他们的未请求电子邮件。对于公开的电话号码来说,这并不容易;PSTN E.164号码分配过程更为复杂,通常单个E.164号码(或固定范围的号码)与每个PSTN接入相关联。因此,在任何出版物中提供“牺牲性”电话号码是不可能的。

Due to the implications of publishing data on a globally accessible database, as a principle the data subjects MUST give their explicit informed consent to data being published in ENUM.

由于在全球可访问数据库上发布数据的影响,作为一项原则,数据主体必须对在ENUM中发布的数据给予明确的知情同意。

In addition, they should be made aware that, due to storage of such data during harvesting by third parties, removal of the data from publication will not remove any copies that have been taken; in effect, any publication may be permanent.

此外,应让他们意识到,由于第三方在采集过程中存储了此类数据,因此从发布中删除数据不会删除已获取的任何副本;实际上,任何出版物都可能是永久性的。

However, regulations in many regions will require that the data subjects can at any time request that the data be removed from publication and that their consent for its publication be explicitly confirmed at regular intervals.

然而,许多地区的法规将要求数据主体可以在任何时候要求将数据从发布中删除,并定期明确确认其对发布的同意。

When placing a voice call via the PSTN (or from the Public Land Mobile Network), the sender may be charged for this action. In both kinds of networks, calling some numbers is more expensive than sending to others; both kinds of networks have "premium rate" services that can be charged at a rate considerably more than a "normal" call. As such, it is important that end users be asked to confirm placing the call and that the destination number be presented to them. It is the originating user's choice whether or not to place a call to this destination number, but the originating user SHOULD be shown the destination number so that he or she can make this decision.

通过PSTN(或从公共陆地移动网络)拨打语音电话时,可能会向发送方收取此项费用。在这两种网络中,拨打一些号码比发送给其他人要贵;这两种网络都有“特优费率”服务,其费率远远高于“正常”呼叫。因此,重要的是要求最终用户确认拨打电话,并向他们提供目的地号码。发起用户可以选择是否拨打该目的地号码,但应向发起用户显示目的地号码,以便他或她做出此决定。

In addition to the specific security considerations given above, all security considerations given in RFC 3761 apply, as well as the DNS-specific threats covered in RFC 3833 [12].

除上述特定安全注意事项外,RFC 3761中给出的所有安全注意事项以及RFC 3833[12]中涵盖的DNS特定威胁也适用。

6. IANA Considerations
6. IANA考虑

The IANA has registered the Enumservice "voice" with a single subtype "tel" according to the framework defined in RFC 3761. The current document defines this Enumservice and the expected behaviour of clients.

IANA已根据RFC 3761中定义的框架将Enumservice“voice”注册为单个子类型“tel”。当前文档定义了此Enumservice和客户端的预期行为。

7. References
7. 工具书类
7.1. Normative References
7.1. 规范性引用文件

[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] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997.

[2] ITU-T,“国际公共电信号码计划”,建议E.164,1997年5月。

[3] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 1034, November 1987.

[3] Mockapetris,P.,“域名-概念和设施”,RFC1034,1987年11月。

[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.

[4] Mealling,M.“动态委托发现系统(DDDS)第三部分:域名系统(DNS)数据库”,RFC3403,2002年10月。

[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.

[5] Mealling,M,“动态委托发现系统(DDDS)第一部分:综合DDDS”,RFC 3401,2002年10月。

[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.

[6] Mealling,M.,“动态委托发现系统(DDDS)第二部分:算法”,RFC3402,2002年10月。

[7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.

[7] Mealling,M.“动态委托发现系统(DDDS)第四部分:统一资源标识符(URI)”,RFC34042002年10月。

[8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.

[8] Mealling,M.“动态委托发现系统(DDDS)第五部分:URI.ARPA分配程序”,RFC 3405,2002年10月。

[9] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, BCP 14, March 1997.

[9] Bradner,S.,“RFC中用于表示需求水平的关键词”,RFC 2119,BCP 14,1997年3月。

[10] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.

[10] Schulzrinne,H.,“电话号码的电话URI”,RFC 3966,2004年12月。

7.2. Informative References
7.2. 资料性引用

[11] ETSI, "Minimum Requirements for Interoperability of ENUM Implementations", ETSI TS 102 172, January 2005.

[11] ETSI,“ENUM实施互操作性的最低要求”,ETSI TS 102 172,2005年1月。

[12] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.

[12] Atkins,D.和R.Austein,“域名系统(DNS)的威胁分析”,RFC 38332004年8月。

Authors' Addresses

作者地址

Rudolf Brandner Siemens AG Hofmannstr. 51 81359 Munich Germany

鲁道夫·布兰德纳西门子公司Hofmannstr。5181359德国慕尼黑

   Phone: +49-89-722-51003
   EMail: rudolf.brandner@siemens.com
        
   Phone: +49-89-722-51003
   EMail: rudolf.brandner@siemens.com
        

Lawrence Conroy Siemens Roke Manor Research Roke Manor Romsey United Kingdom

劳伦斯·康罗伊·西门子Roke Manor Research Roke Manor Romsey英国

   Phone: +44-1794-833666
   EMail: lwc@roke.co.uk
        
   Phone: +44-1794-833666
   EMail: lwc@roke.co.uk
        

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
        

Full Copyright Statement

完整版权声明

Copyright (C) The Internet Society (2006).

版权所有(C)互联网协会(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 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 provided by the IETF Administrative Support Activity (IASA).

RFC编辑器功能的资金由IETF行政支持活动(IASA)提供。