Network Working Group R. Brandner
Request for Comments: 4355 Siemens AG
Category: Standards Track L. Conroy
Siemens Roke Manor Research
R. Stastny
Oefeg
January 2006
Network Working Group R. Brandner
Request for Comments: 4355 Siemens AG
Category: Standards Track L. Conroy
Siemens Roke Manor Research
R. Stastny
Oefeg
January 2006
IANA Registration for Enumservices email, fax, mms, ems, and sms
IANA注册Enumservices电子邮件、传真、彩信、ems和sms
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 Enumservices "email", "fax", "sms", "ems", and "mms" using the URI schemes 'tel:' and 'mailto:' as per the IANA registration process defined in the ENUM specification RFC 3761.
本文档根据ENUM规范RFC 3761中定义的IANA注册过程，使用URI方案“tel:”和“mailto:”注册ENUM服务“电子邮件”、“传真”、“sms”、“ems”和“mms”。
Table of Contents
目录
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Email Service Registration ......................................4
4. Fax Service Registration ........................................4
5. MMS, EMS, SMS Service ...........................................5
5.1. Introduction ...............................................5
5.2. SMS Service Registrations ..................................6
5.2.1. SMS Service Registration with tel: URI ..............6
5.2.2. SMS Service Registration with mailto: URI ...........6
5.3. EMS Service Registrations ..................................7
5.3.1. EMS Service Registration with tel: URI ..............7
5.3.2. EMS Service Registration with mailto: URI ...........8
5.4. MMS Service Registrations ..................................9
5.4.1. MMS Service Registration with tel: URI ..............9
5.4.2. MMS Service Registration with mailto: URI ..........10
6. Security Considerations ........................................11
7. Acknowledgements ...............................................13
8. References .....................................................13
8.1. Normative References ......................................13
8.2. Informative References ....................................14
1. Introduction ....................................................2
2. Terminology .....................................................3
3. Email Service Registration ......................................4
4. Fax Service Registration ........................................4
5. MMS, EMS, SMS Service ...........................................5
5.1. Introduction ...............................................5
5.2. SMS Service Registrations ..................................6
5.2.1. SMS Service Registration with tel: URI ..............6
5.2.2. SMS Service Registration with mailto: URI ...........6
5.3. EMS Service Registrations ..................................7
5.3.1. EMS Service Registration with tel: URI ..............7
5.3.2. EMS Service Registration with mailto: URI ...........8
5.4. MMS Service Registrations ..................................9
5.4.1. MMS Service Registration with tel: URI ..............9
5.4.2. MMS Service Registration with mailto: URI ..........10
6. Security Considerations ........................................11
7. Acknowledgements ...............................................13
8. References .....................................................13
8.1. Normative References ......................................13
8.2. Informative References ....................................14
ENUM (E.164 Number Mapping, RFC 3761 [2]) is a system that transforms E.164 numbers [3] into domain names and then uses DNS (Domain Name Service, RFC 1034 [4]) services like delegation through NS records and NAPTR records to look up what services are available for a specific domain name.
ENUM（E.164数字映射，RFC 3761[2]）是一个系统，它将E.164数字[3]转换为域名，然后使用DNS（域名服务，RFC 1034[4]）服务，如通过NS记录和NAPTR记录进行委派，以查找特定域名的可用服务。
This document registers Enumservices according to the guidelines given in RFC 3761 to be used for provisioning in the services field of a NAPTR [5] resource record to indicate what class of functionality a given endpoint offers. The registration is defined within the DDDS (Dynamic Delegation Discovery System [6][7][5][8][9]) hierarchy, for use with the "E2U" DDDS Application defined in RFC 3761.
本文档根据RFC 3761中给出的指南注册Enumservices，用于在NAPTR[5]资源记录的服务字段中进行配置，以指示给定端点提供的功能类别。注册在DDDS（动态委派发现系统[6][7][5][8][9]）层次结构中定义，用于RFC 3761中定义的“E2U”DDDS应用程序。
The following Enumservices are registered with this document: "email", "fax", "sms", "ems", and "mms". These share a common feature in that they each indicate that the functionality of the given endpoints and the associated resources are capable of receiving discrete messages, albeit of different types.
本文档注册了以下服务：“电子邮件”、“传真”、“sms”、“ems”和“彩信”。它们共享一个共同的特性，即它们各自表示给定端点和相关资源的功能能够接收离散消息，尽管消息类型不同。
According to RFC 3761, the Enumservice registered must be able to function as a selection mechanism when choosing one NAPTR resource record from another. That means that the registration MUST specify
根据RFC 3761，当从一个NAPTR资源记录中选择另一个时，注册的Enumservice必须能够起到选择机制的作用。这意味着注册必须指定
what is expected when using that very NAPTR record, and the Uniform Resource Identifier (URI) scheme that is the outcome of the use of it.
当使用NAPTR记录以及作为使用结果的统一资源标识符（URI）方案时，期望得到什么。
Therefore, an Enumservice acts as a hint, indicating the kind of service with which the URI constructed using the regexp field is associated. There can be more than one Enumservice included within a single NAPTR; this indicates that there is more than one service that can be achieved using the associated URI scheme.
因此，Enumservice充当提示，指示使用regexp字段构造的URI所关联的服务类型。一个NAPTR中可以包含多个Enumservice；这表明可以使用关联的URI方案实现多个服务。
The common thread with this set of definitions is that they reflect the kind of service that the end-user will hope to achieve with the communication using the associated URI.
这组定义的共同点是，它们反映了最终用户希望通过使用相关URI的通信实现的服务类型。
The services specified here are intended not to specify the protocol or even method of connection that must be used to achieve each service. Instead they define the kind of interactive behaviour that an end-user will expect, leaving the end system to decide (based on policies outside the remit of this specification) how to execute the service.
此处指定的服务不用于指定实现每个服务必须使用的协议或连接方法。相反，它们定义了最终用户期望的交互行为类型，让最终系统决定（基于本规范范围之外的策略）如何执行服务。
Since the same URI scheme may be used for different services (e.g., 'tel:'), and the same kind of service may use different URI schemes (e.g., for VoIP 'h323:' and 'tel:' may be used), it is necessary in some cases to specify the service and the URI scheme used.
由于相同的URI方案可用于不同的服务（例如，“tel:”），并且相同类型的服务可使用不同的URI方案（例如，对于VoIP，可使用“h323:”和“tel:”），因此在某些情况下有必要指定所使用的服务和URI方案。
The service parameters defined in RFC 3761 allow, therefore, a "type" and a "subtype" to be specified. Within this set of specifications, the convention is assumed that the "type" (being the more generic term) defines the service and the "subtype" defines the URI scheme.
因此，RFC 3761中定义的服务参数允许指定“类型”和“子类型”。在这组规范中，约定假定“类型”（更通用的术语）定义服务，“子类型”定义URI方案。
Even where currently only one URI scheme is associated with a given service, it should be considered that an additional URI scheme to be used with this service may be added later. Thus, the subtype is needed to identify the specific Enumservice intended.
即使当前只有一个URI方案与给定服务相关联，也应该考虑稍后添加将与该服务一起使用的附加URI方案。因此，需要使用子类型来标识所需的特定枚举服务。
In this document, there are two URI schemes that are used within the various services. These are 'tel:', as specified in RFC 3966 [10] and 'mailto:', as specified in RFC 2368 [11].
在本文档中，有两个URI方案在各种服务中使用。这些是RFC 3966[10]中规定的“电话：”，以及RFC 2368[11]中规定的“邮寄地址：”。
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]中的描述进行解释。
Enumservice Name: "email"
枚举服务名称：“电子邮件”
Enumservice Type: "email"
枚举服务类型：“电子邮件”
Enumservice Subtypes: "mailto"
Enumservice子类型：“mailto”
URI Scheme: 'mailto:'
URI方案：“mailto:”
Functional Specification:
功能规格：
This Enumservice indicates that the remote resource can be addressed by the associated URI scheme in order to send an email.
此Enumservice表示可以通过关联的URI方案对远程资源进行寻址，以便发送电子邮件。
Security Considerations:
安全考虑：
See Section 6.
见第6节。
Intended Usage: COMMON
预期用途：普通
Authors:
作者：
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail, see Authors' Addresses section)
鲁道夫·布兰德纳、劳伦斯·康罗伊、理查德·斯塔斯尼（关于作者联系方式，请参见作者地址部分）
Any other information the author deems interesting:
作者认为有趣的任何其他信息：
None
没有一个
Enumservice Name: "fax"
服务名称：“传真”
Enumservice Type: "fax"
枚举服务类型：“传真”
Enumservice Subtype: "tel"
枚举服务子类型：“电话”
URI Scheme: 'tel:'
URI方案：“电话：”
Functional Specification:
功能规格：
This Enumservice indicates that the resource identified by the associated URI scheme is capable of being contacted to provide a communication session during which facsimile documents can be sent.
该服务指示由相关联的URI方案标识的资源能够被联系以提供通信会话，在该通信会话期间可以发送传真文档。
Clients selecting this NAPTR will have support for generating and sending facsimile documents to the recipient using the Public Switched Telephone Network (PSTN) session and transfer protocols specified in [12] and [13]. In short, they will have a fax program with a local or shared PSTN access over which they can send faxes.
选择此NAPTR的客户将支持使用[12]和[13]中规定的公共交换电话网络（PSTN）会话和传输协议生成传真文件并将其发送给收件人。简言之，他们将有一个传真程序，通过本地或共享PSTN接入，他们可以发送传真。
Security Considerations:
安全考虑：
See Section 6.
见第6节。
Intended Usage: COMMON
预期用途：普通
Authors:
作者：
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail see Authors' Addresses section)
Rudolf Brandner，Lawrence Conroy，Richard Stastny（作者联系方式详见作者地址部分）
Any other information the author deems interesting:
作者认为有趣的任何其他信息：
None
没有一个
An ENUM NAPTR indicates ability on the part of the Subscriber to receive specified communication service (or services) provided via the contact address (shown in the generated URI).
ENUM NAPTR表示订户能够接收通过联系人地址（在生成的URI中显示）提供的指定通信服务。
In the case of MMS, EMS, and SMS services, the capability of these services is a nested superset; thus, a service supporting MMS can support also delivery of EMS or SMS message content to a recipient that is receiving a Multimedia Message, whilst a service supporting EMS can also deliver SMS message content to a recipient that can accept receipt of EMS Messages.
在MMS、EMS和SMS服务的情况下，这些服务的能力是嵌套的超集；因此，支持MMS的服务还可以支持将EMS或SMS消息内容传送给正在接收多媒体消息的接收者，而支持EMS的服务还可以将SMS消息内容传送给能够接收EMS消息的接收者。
Thus, even if a client wants only to generate and send content that could be carried in an SMS message, the client MAY choose to consider also NAPTRs holding EMS and/or MMS Enumservices, as these indicate that the destination can accept EMS and/or MMS messages. These services will be able to deliver SMS content to the recipient address.
因此，即使客户端只希望生成和发送可以在SMS消息中携带的内容，客户端也可以选择考虑保持EMS和/或MMS枚举服务的NAPTRS，因为这些指示目的地可以接受EMS和/或MMS消息。这些服务将能够将SMS内容发送到收件人地址。
Conversely, a client capable of sending MMS messages may choose to consider also NAPTRs indicating support for EMS or SMS messages (assuming that the network to which it is connected provides these services as well, or is capable of providing a gateway to systems
相反，能够发送MMS消息的客户端可以选择考虑支持EMS或SMS消息的NAPTRS（假设其所连接的网络也提供这些服务，或者能够向系统提供网关）。
that do provide these services). In taking this choice, it would have to "downgrade" its User Interface to allow only generation of content that conforms to SMS or EMS standards.
提供这些服务）。在做出这一选择时，它必须“降级”其用户界面，只允许生成符合SMS或EMS标准的内容。
These behaviours on the part of the client are purely optional and are NOT the subject of any protocol standardisation.
客户的这些行为纯粹是可选的，不属于任何协议标准化的主题。
Enumservice Name: "sms"
枚举服务名称：“sms”
Enumservice Type: "sms"
枚举服务类型：“sms”
Enumservice Subtypes: "tel"
枚举服务子类型：“电话”
URI Scheme: 'tel:'
URI方案：“电话：”
Functional Specification:
功能规格：
This Enumservice indicates that the resource identified by the associated URI scheme is capable of receiving a message using the Short Message Service (SMS) [14].
此Enumservice表示由相关URI方案标识的资源能够使用短消息服务（SMS）接收消息[14]。
Security Considerations:
安全考虑：
There are no specific security issues with this Enumservice. However, the general considerations of Section 6 apply.
此Enumservice没有特定的安全问题。但是，第6节的一般考虑因素适用。
Intended Usage: COMMON
预期用途：普通
Authors:
作者：
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail, see Authors' Addresses section)
鲁道夫·布兰德纳、劳伦斯·康罗伊、理查德·斯塔斯尼（关于作者联系方式，请参见作者地址部分）
Any other information the author deems interesting:
作者认为有趣的任何其他信息：
None
没有一个
Enumservice Name: "sms"
枚举服务名称：“sms”
Enumservice Type: "sms"
枚举服务类型：“sms”
Enumservice Subtypes: "mailto"
Enumservice子类型：“mailto”
URI Scheme: 'mailto:'
URI方案：“mailto:”
Functional Specification:
功能规格：
This Enumservice indicates that the resource identified by the associated URI scheme is capable of receiving a message using an email protocol.
此Enumservice表示由关联URI方案标识的资源能够使用电子邮件协议接收消息。
SMS content is sent over SMTP using the format specified by TS 23.140 [15] Section 8.4.4 and TS 26.140 [16] Section 4, as an MMS message. Within such a message, SMS content is carried as either a text or application/octet-stream MIME sub-part (see TS 26.140 [16] Section 4.1).
SMS内容通过SMTP发送，使用TS 23.140[15]第8.4.4节和TS 26.140[16]第4节规定的格式作为彩信。在这样的消息中，SMS内容以文本或应用程序/八位字节流MIME子部分的形式承载（参见TS 26.140[16]第4.1节）。
Security Considerations:
安全考虑：
There are no specific security issues with this Enumservice. However, the general considerations of Section 6 apply.
此Enumservice没有特定的安全问题。但是，第6节的一般考虑因素适用。
Intended Usage: COMMON
预期用途：普通
Authors:
作者：
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail, see Authors' Addresses section)
鲁道夫·布兰德纳、劳伦斯·康罗伊、理查德·斯塔斯尼（关于作者联系方式，请参见作者地址部分）
Any other information the author deems interesting:
作者认为有趣的任何其他信息：
None
没有一个
Enumservice Name: "ems"
枚举服务名称：“ems”
Enumservice Type: "ems"
枚举服务类型：“ems”
Enumservice Subtype: "tel"
枚举服务子类型：“电话”
URI Scheme: 'tel:'
URI方案：“电话：”
Functional Specification:
功能规格：
This Enumservice indicates that the resource identified by the associated URI scheme is capable of receiving a message using the Enhanced Message Service (EMS) [14].
此Enumservice表示由关联URI方案标识的资源能够使用增强消息服务（EMS）接收消息[14]。
Security Considerations:
安全考虑：
There are no specific security issues with this Enumservice. However, the general considerations of Section 6 apply.
此Enumservice没有特定的安全问题。但是，第6节的一般考虑因素适用。
Intended Usage: COMMON
预期用途：普通
Authors:
作者：
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail, see Authors' Addresses section)
鲁道夫·布兰德纳、劳伦斯·康罗伊、理查德·斯塔斯尼（关于作者联系方式，请参见作者地址部分）
Any other information the author deems interesting:
作者认为有趣的任何其他信息：
Note that an indication of EMS can be taken as implying that the recipient is capable of receiving SMS messages at this address as well.
注意，EMS的指示可被视为暗示接收者也能够在该地址接收SMS消息。
Enumservice Name: "ems"
枚举服务名称：“ems”
Enumservice Type: "ems"
枚举服务类型：“ems”
Enumservice Subtypes: "mailto"
Enumservice子类型：“mailto”
URI Scheme: 'mailto:'
URI方案：“mailto:”
Functional Specification:
功能规格：
This Enumservice indicates that the resource identified by the associated URI scheme is capable of receiving a message using an email protocol.
此Enumservice表示由关联URI方案标识的资源能够使用电子邮件协议接收消息。
EMS content is sent over SMTP using the format specified by TS 23.140 [15] Section 8.4.4 and TS 26.140 [16] Section 4, as an MMS message. Within such a message, EMS content is carried as either a text or application/octet-stream MIME sub-part (see TS 26.140 [16] section 4.1).
EMS内容使用TS 23.140[15]第8.4.4节和TS 26.140[16]第4节规定的格式通过SMTP以彩信的形式发送。在这样的消息中，EMS内容以文本或应用程序/八位字节流MIME子部分的形式传送（见TS 26.140[16]第4.1节）。
Security Considerations:
安全考虑：
There are no specific security issues with this Enumservice. However, the general considerations of Section 6 apply.
此Enumservice没有特定的安全问题。但是，第6节的一般考虑因素适用。
Intended Usage: COMMON
预期用途：普通
Authors:
作者：
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail, see Authors' Addresses section)
鲁道夫·布兰德纳、劳伦斯·康罗伊、理查德·斯塔斯尼（关于作者联系方式，请参见作者地址部分）
Any other information the author deems interesting:
作者认为有趣的任何其他信息：
None
没有一个
Enumservice Name: "mms"
枚举服务名称：“彩信”
Enumservice Type: "mms"
枚举服务类型：“彩信”
Enumservice Subtype: "tel"
枚举服务子类型：“电话”
URI Scheme: 'tel:'
URI方案：“电话：”
Functional Specification:
功能规格：
This Enumservice indicates that the resource identified by the associated URI scheme is capable of receiving a message using the Multimedia Messaging Service (MMS) [15].
该服务指示由相关URI方案标识的资源能够使用彩信服务（MMS）接收消息[15]。
Security Considerations:
安全考虑：
There are no specific security issues with this Enumservice. However, the general considerations of Section 6 apply.
此Enumservice没有特定的安全问题。但是，第6节的一般考虑因素适用。
Intended Usage: COMMON
预期用途：普通
Authors:
作者：
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail, see Authors' Addresses section)
鲁道夫·布兰德纳、劳伦斯·康罗伊、理查德·斯塔斯尼（关于作者联系方式，请参见作者地址部分）
Any other information the author deems interesting:
作者认为有趣的任何其他信息：
Note that MMS can be used as an alternative to deliver an SMS RP-DATA RPDU if, for example, the SMS bearer is not supported. If an entry includes this Enumservice, then in effect this can be taken as implying that the recipient is capable of receiving EMS or SMS messages at this address. Such choices on the end system design do have two small caveats; whilst in practice all terminals
注意，例如，如果不支持SMS承载，则可以使用MMS作为交付SMS RP-DATA RPDU的替代方案。如果条目包含此Enumservice，则实际上可以认为这意味着收件人能够在此地址接收EMS或SMS消息。在终端系统设计上的这种选择确实有两个小警告；在实践中，所有终端
supporting MMS today support SMS as well, it might not necessarily be the case in the future, and there may be tariff differences in using the MMS rather than using the SMS or EMS.
现在支持彩信也支持短信，将来可能不一定如此，使用彩信而不是使用短信或EMS可能会有价格差异。
Enumservice Name: "mms"
枚举服务名称：“彩信”
Enumservice Type: "mms"
枚举服务类型：“彩信”
Enumservice Subtypes: "mailto"
Enumservice子类型：“mailto”
URI Scheme: 'mailto:'
URI方案：“mailto:”
Functional Specification:
功能规格：
This Enumservice indicates that the resource identified by the associated URI scheme is capable of receiving a message using an email protocol.
此Enumservice表示由关联URI方案标识的资源能够使用电子邮件协议接收消息。
MMS messages are sent over SMTP using the format specified by TS 23.140 [15] Section 8.4.4 and TS 26.140 [16] Section 4.
彩信使用TS 23.140[15]第8.4.4节和TS 26.140[16]第4节规定的格式通过SMTP发送。
Within and between MMS Environments (MMSE, network infrastructures that support the MultiMedia Service), other pieces of state data (for example, charging-significant information) are exchanged between MMS Relay Servers. Thus, although these servers use SMTP as the "bearer" for their application exchanges, they map their internal state to specialised headers carried in the SMTP message exchanges. The headers used in such MMSE are described in detail in [17].
在MMS环境（MMSE，支持多媒体服务的网络基础设施）内部和之间，其他状态数据（例如，重要信息的收费）在MMS中继服务器之间交换。因此，尽管这些服务器使用SMTP作为其应用程序交换的“承载者”，但它们将其内部状态映射到SMTP消息交换中携带的专用头。[17]中详细描述了此类MMSE中使用的报头。
Security Considerations:
安全考虑：
There are no specific security issues with this Enumservice. However, the general considerations of Section 6 apply.
此Enumservice没有特定的安全问题。但是，第6节的一般考虑因素适用。
Intended Usage: COMMON
预期用途：普通
Authors:
作者：
Rudolf Brandner, Lawrence Conroy, Richard Stastny (for author contact detail see Authors' Addresses section)
Rudolf Brandner，Lawrence Conroy，Richard Stastny（作者联系方式详见作者地址部分）
Any other information the author deems interesting:
作者认为有趣的任何其他信息：
The MMS Architecture describes an interface between the MMSE and "legacy messaging systems" (labelled as MM3) that accepts
MMS体系结构描述了MMSE和“传统消息传递系统”（标记为MM3）之间的接口，该系统接受
"standard" SMTP messages. Thus, although the MMS Relay Server that supports this interface appears as a standard SMTP server from the perspective of an Internet-based mail server, it acts as a gateway and translator, adding the internal state data that is used within and between the MMS Environments. This mechanism is described in [17], which also includes references to the specifications agreed by those bodies responsible for the design of the MMS.
“标准”SMTP邮件。因此，尽管从基于Internet的邮件服务器的角度来看，支持此接口的MMS中继服务器显示为标准SMTP服务器，但它充当网关和转换器，添加MMS环境内部和之间使用的内部状态数据。[17]中描述了该机制，其中还包括对负责MMS设计的机构商定的规范的参考。
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 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 they are sent increases when they post to the mailing list. Publication of a telephone number in ENUM is no different, and may be used to send "junk faxes" or "junk SMS", for example.
第三方收集的此类数据通常用于生成未请求信息的目标列表；简而言之，它们被用来处理“垃圾邮件”。任何使用Web存档邮件列表的人都知道，当他们发布到邮件列表时，他们发送的“垃圾邮件”数量会增加。在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, 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 data subjects can at any time request that the data is removed from publication and that their consent for its publication is explicitly confirmed at regular intervals.
然而，许多地区的法规将要求数据主体可以在任何时候要求将数据从发布中删除，并定期明确确认其对发布的同意。
When placing a fax call via the PSTN or a sending a message via the Public Land Mobile Network, the sender may be charged for this action. In both kinds of network, calling or messaging to some numbers is more expensive than sending to others; both networks have "premium rate" services that can charge considerably more than a "normal" call or message destination. As such, it is important that end-users be asked to confirm sending the message and that the destination number be presented to them. It is the originating user's choice on whether or not to send a message to this destination number, but end-users SHOULD be shown the destination number so that they can make this decision.
当通过PSTN进行传真呼叫或通过公共陆地移动网络发送消息时，发送方可能会为此操作收取费用。在这两种网络中，打电话或发短信给某些号码比发送给其他号码要贵；这两个网络都有“特优费率”服务，收费可能远远高于“正常”呼叫或消息目的地。因此，重要的是要求最终用户确认发送消息，并向他们提供目的地号码。是否将消息发送到此目的地号码是原始用户的选择，但应向最终用户显示目的地号码，以便他们做出此决定。
Although a fax number, like other E.164 numbers, doesn't appear to reveal as much identity information about a user as a name in the format user@host (e.g., an email or SIP address), the information is still publicly available; thus, there is still the risk of unwanted communication.
尽管传真号码和其他E.164号码一样，在显示用户身份信息时，似乎不如在格式中显示姓名那样多user@host（例如，电子邮件或SIP地址），该信息仍然是公开的；因此，仍然存在不必要通信的风险。
An analysis of threats specific to the dependence of ENUM on the DNS, and the applicability of DNSSEC [18] to these, is provided in RFC 3761 [2]. A thorough analysis of threats to the DNS itself is covered in RFC 3833 [19].
RFC 3761[2]中提供了对ENUM依赖DNS的特定威胁的分析，以及DNSSEC[18]对这些威胁的适用性。RFC 3833[19]对DNS本身的威胁进行了全面分析。
An email address is a canonical address by which a user is known. Placing this address in ENUM is comparable to placing a SIP or H.323 address in the DNS.
电子邮件地址是已知用户的标准地址。在ENUM中放置此地址与在DNS中放置SIP或H.323地址相当。
DNS does not make any policy decisions about the records that it shares with an inquirer. All DNS records must be assumed to be available to all inquirers at all times. The information provided within an ENUM NAPTR resource record must, therefore, be considered to be open to the public, which is a cause for some privacy considerations.
DNS不对其与查询者共享的记录做出任何策略决定。必须假设所有DNS记录在任何时候都可供所有查询者使用。因此，必须将ENUM NAPTR资源记录中提供的信息视为对公众开放，这是出于某些隐私考虑的原因。
Therefore, ENUM Subscribers should be made aware of this risk. Since it is within the responsibility of the ENUM Subscriber which data is entered in ENUM, it is within the ENUM Subscriber's control if he enters email addresses:
因此，应让ENUM订户意识到这一风险。由于在ENUM中输入数据属于ENUM订户的责任，因此，如果ENUM订户输入电子邮件地址，则属于ENUM订户的控制范围：
1. allowing inference of private data, e.g., his first and last name 2. at all
1. 允许推断私人数据，例如他的名字和姓氏2。完全
It should also be considered that it is the purpose of public communication identifiers to be publicly known. To reduce spam and other unwanted communication, other means should be made available, such as incoming message filtering.
还应考虑到，公共通信标识符的目的是公开。为了减少垃圾邮件和其他不必要的通信，应提供其他手段，如传入消息过滤。
Some Value Added Service Providers use receipt of a short message to a given special service telephone number as a trigger to start delivery of data messages to the calling number. By sending an SMS (or, in principle, an EMS or MMS) to one of these special service numbers, one is entering into a contract to pay for receipt of a set of messages containing information (e.g., news, sports results, "ring tones").
一些增值服务提供商使用接收到特定特殊服务电话号码的短消息作为触发，开始向主叫号码发送数据消息。通过向这些特殊服务号码中的一个发送SMS（或者，原则上是EMS或MMS），即签订了一份合同，为接收包含信息（例如，新闻、体育成绩、“铃声”）的一组消息支付费用。
Thus, it is very important that the end terminal presents the destination number to which any message is to be sent using the "sms: tel", "ems:tel", or "mms:tel" Enumservices, to allow the end-user to cancel any message before it is sent to one of these numbers.
因此，非常重要的是，终端使用“sms:tel”、“ems:tel”或“mms:tel”服务呈现任何消息将被发送到的目的地号码，以允许终端用户在将任何消息发送到这些号码之一之前取消该消息。
At present, these systems use the circuit switched network trusted calling line identifier to identify the destination for the subsequent charged information messages, and so it is believed that sending using the "sms:mailto", "ems:mailto", or "mms:mailto" Enumservices does not have this risk currently.
目前，这些系统使用电路交换网络可信呼叫线路标识符来识别后续收费信息消息的目的地，因此，相信使用“sms:mailto”、“ems:mailto”或“mms:mailto”服务发送当前不存在这种风险。
Many thanks to Ville Warsta for his close reading of the document and extracting the right references. Thanks also to those who are involved in the parallel effort to specify the requirements for "real world" ENUM trials resulting in TS 102 172 [20], in which this and other Enumservices are referenced.
非常感谢Ville Warsta仔细阅读了该文件并提取了正确的参考资料。还感谢那些参与并行工作的人员，他们指定了导致TS 102 172[20]的“真实世界”ENUM试验的要求，其中引用了此服务和其他ENUM服务。
[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] Faltstrom, P. and M. Mealling, "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[2] Faltstrom，P.和M.Mealling，“E.164到统一资源标识符（URI）动态委托发现系统（DDDS）应用程序（ENUM）”，RFC 3761，2004年4月。
[3] ITU-T, "The International Public Telecommunication Number Plan", Recommendation E.164, May 1997.
[3] ITU-T，“国际公共电信号码计划”，建议E.164，1997年5月。
[4] Mockapetris, P., "DOMAIN NAMES - CONCEPTS AND FACILITIES", RFC 1034, November 1987.
[4] Mockapetris，P.，“域名-概念和设施”，RFC1034，1987年11月。
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[5] Mealling，M.“动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库”，RFC3403，2002年10月。
[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[6] Mealling，M，“动态委托发现系统（DDDS）第一部分：综合DDDS”，RFC 3401，2002年10月。
[7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[7] Mealling，M.，“动态委托发现系统（DDDS）第二部分：算法”，RFC3402，2002年10月。
[8] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.
[8] Mealling，M.“动态委托发现系统（DDDS）第四部分：统一资源标识符（URI）”，RFC34042002年10月。
[9] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.
[9] Mealling，M.“动态委托发现系统（DDDS）第五部分：URI.ARPA分配程序”，RFC 3405，2002年10月。
[10] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[10] Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，2004年12月。
[11] Hoffman, P., Masinter, L., and J. Zawinski, "The mailto URL scheme", RFC 2368, July 1998.
[11] Hoffman，P.，Masinter，L.，和J.Zawinski，“邮件URL方案”，RFC 2368，1998年7月。
[12] ITU-T, "Standardization of Group 3 facsimile terminals for document transmission", Recommendation T.4, April 1999.
[12] ITU-T，“用于文件传输的第3组传真终端的标准化”，建议T.4，1999年4月。
[13] ITU-T, "Procedures for document facsimile transmission in the general switched telephone network", Recommendation T.30, April 1999.
[13] ITU-T，“通用交换电话网中文件传真传输程序”，建议T.30，1999年4月。
[14] 3GPP, "Technical realization of the Short Message Service (SMS); (Release5)", 3GPP TS 23.040.
[14] 3GPP，“短消息服务（SMS）的技术实现；（Release5）”，3GPP TS 23.040。
[15] 3GPP, "Multimedia Messaging Service (MMS); Functional description; Stage 2 (Release 5)", 3GPP TS 23.140.
[15] 3GPP，“彩信服务（MMS）；功能描述；第2阶段（第5版）”，3GPP TS 23.140。
[16] 3GPP, "Multimedia Messaging Service (MMS); Media formats and codecs; (Release 5)", 3GPP TS 26.140.
[16] 3GPP，“彩信服务（MMS）；媒体格式和编解码器；（第5版）”，3GPP TS 26.140。
[17] Gellens, R., "Mapping Between the Multimedia Messaging Service (MMS) and Internet Mail", RFC 4356, January 2006.
[17] Gellens，R.，“多媒体信息服务（MMS）和互联网邮件之间的映射”，RFC 4356，2006年1月。
[18] Arends, R. and et al. , "Protocol Modifications for the DNS Security Extensions", RFC 4035, March 2005.
[18] Arends，R.和等人，“DNS安全扩展的协议修改”，RFC 4035，2005年3月。
[19] Atkins, D. and R. Austein, "Threat Analysis of the Domain Name System (DNS)", RFC 3833, August 2004.
[19] Atkins，D.和R.Austein，“域名系统（DNS）的威胁分析”，RFC 38332004年8月。
[20] ETSI, "Minimum Requirements for Interoperability of ENUM Implementations", ETSI TS 102 172, January 2005.
[20] ETSI，“ENUM实施互操作性的最低要求”，ETSI TS 102 172，2005年1月。
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）提供。