Internet Engineering Task Force (IETF) D. Crocker
Request for Comments: 8552 Brandenburg InternetWorking
BCP: 222 March 2019
Category: Best Current Practice
ISSN: 2070-1721
Internet Engineering Task Force (IETF) D. Crocker
Request for Comments: 8552 Brandenburg InternetWorking
BCP: 222 March 2019
Category: Best Current Practice
ISSN: 2070-1721
Scoped Interpretation of DNS Resource Records through "Underscored" Naming of Attribute Leaves
通过属性叶子的“下划线”命名对DNS资源记录进行范围解释
Abstract
摘要
Formally, any DNS Resource Record (RR) may occur under any domain name. However, some services use an operational convention for defining specific interpretations of an RRset by locating the records in a DNS branch under the parent domain to which the RRset actually applies. The top of this subordinate branch is defined by a naming convention that uses a reserved node name, which begins with the underscore character (e.g., "_name"). The underscored naming construct defines a semantic scope for DNS record types that are associated with the parent domain above the underscored branch. This specification explores the nature of this DNS usage and defines the "Underscored and Globally Scoped DNS Node Names" registry with IANA. The purpose of this registry is to avoid collisions resulting from the use of the same underscored name for different services.
在形式上，任何DNS资源记录（RR）都可能出现在任何域名下。但是，一些服务使用操作约定来定义RRset的特定解释，方法是将记录定位在RRset实际应用的父域下的DNS分支中。此从属分支的顶部由使用保留节点名称的命名约定定义，该名称以下划线字符（例如“_name”）开头。下划线命名构造为与下划线分支上方的父域关联的DNS记录类型定义语义范围。本规范探讨了此DNS使用的性质，并使用IANA定义了“带下划线和全局作用域的DNS节点名称”注册表。此注册表的目的是避免因对不同的服务使用相同的带下划线的名称而导致冲突。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 7841第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8552.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8552.
Copyright Notice
版权公告
Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.
版权（c）2019 IETF信托基金和被确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(https://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Underscore-Based Scoping . . . . . . . . . . . . . . . . 3
1.2. Scaling Benefits . . . . . . . . . . . . . . . . . . . . 4
1.3. Global Underscored Node Names . . . . . . . . . . . . . . 4
1.4. Interaction with DNS Wildcards . . . . . . . . . . . . . 5
1.5. History . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. "Underscored and Globally Scoped DNS Node Names" Registry . . 6
3. Guidance for Registering RRset Use . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
4.1. "Underscored and Globally Scoped DNS Node Names" Registry 8
4.2. Enumservices Registrations Registry . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Underscore-Based Scoping . . . . . . . . . . . . . . . . 3
1.2. Scaling Benefits . . . . . . . . . . . . . . . . . . . . 4
1.3. Global Underscored Node Names . . . . . . . . . . . . . . 4
1.4. Interaction with DNS Wildcards . . . . . . . . . . . . . 5
1.5. History . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. "Underscored and Globally Scoped DNS Node Names" Registry . . 6
3. Guidance for Registering RRset Use . . . . . . . . . . . . . 7
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
4.1. "Underscored and Globally Scoped DNS Node Names" Registry 8
4.2. Enumservices Registrations Registry . . . . . . . . . . . 11
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . 15
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15
The core Domain Name System (DNS) technical specifications ([RFC1035] and [RFC2181]) assign no semantics to domain names or their parts, and no constraints upon which resource record (RR) types are permitted to be stored under particular names [RFC1035] [RFC2181]. Over time, some leaf node names, such as "www" and "ftp", have come to imply support for particular services, but this is a matter of operational convention rather than defined protocol semantics. This freedom in the basic technology has permitted a wide range of administrative and semantic policies to be used -- in parallel. DNS data semantics have been limited to the specification of particular resource record types on the expectation that new resource record
核心域名系统（DNS）技术规范（[RFC1035]和[RFC2181]）没有为域名或其部分分配语义，也没有限制资源记录（RR）类型可以存储在特定名称下[RFC1035][RFC2181]。随着时间的推移，一些叶节点名称，如“www”和“ftp”，已经开始暗示对特定服务的支持，但这是一个操作约定的问题，而不是定义的协议语义。基本技术的这种自由允许广泛的管理和语义策略并行使用。DNS数据语义仅限于特定资源记录类型的规范，因为新的资源记录
types would be added as needed. Unfortunately, the addition of new resource record types has proven extremely challenging, with significant adoption and use barriers occurring over the life of the DNS.
将根据需要添加类型。不幸的是，添加新的资源记录类型已被证明是极具挑战性的，在DNS的生命周期中会出现重大的采用和使用障碍。
As an alternative to defining a new RR TYPE, some DNS service enhancements call for using an existing resource record type but specifying a restricted scope for its occurrence. Scope is meant as a static property, not one dependent on the nature of the query. It is an artifact of the DNS name. That scope is a leaf node containing the specific resource record sets that are formally defined and constrained. Specifically:
作为定义新RR类型的替代方法，一些DNS服务增强要求使用现有的资源记录类型，但指定其出现的受限范围。作用域是指静态属性，而不是依赖于查询性质的属性。它是DNS名称的工件。该范围是一个叶节点，包含正式定义和约束的特定资源记录集。明确地：
The leaf occurs in a branch having a distinguished naming convention: there is a parent domain name to which the scoped data applies. The branch is under this name. The sub-branch is indicated by a sequence of one or more reserved DNS node names; at least the first (highest) of these names begins with an underscore (e.g., "_name").
叶出现在具有可分辨命名约定的分支中：存在应用范围数据的父域名。分支机构就是以这个名字命名的。分支由一个或多个保留DNS节点名称的序列指示；这些名称中，至少第一个（最高的）以下划线开头（例如“_name”）。
Because the DNS rules for a "host" (host name) do not allow use of the underscore character, the underscored name is distinguishable from all legal host names [RFC0952]. Effectively, this convention for naming leaf nodes creates a space for the listing of "attributes" -- in the form of resource record types -- that are associated with the parent domain above the underscored sub-branch.
由于“主机”（主机名）的DNS规则不允许使用下划线字符，因此下划线名称可与所有合法主机名区分开来[RFC0952]。实际上，这种命名叶节点的约定为“属性”列表创建了一个空间——以资源记录类型的形式——这些属性与子分支上方的父域相关联。
The scoping feature is particularly useful when generalized resource record types are used -- notably "TXT", "SRV", and "URI" [RFC1035] [RFC2782] [RFC6335] [RFC7553]. It provides efficient separation of one use of them from others. Absent this separation, an undifferentiated mass of these RRsets is returned to the DNS client, which then must parse through the internals of the records in the hope of finding ones that are relevant. Worse, in some cases, the results are ambiguous because a record type might not adequately self-identify its specific purpose. With underscore-based scoping, only the relevant RRsets are returned.
当使用一般化的资源记录类型时，作用域特性特别有用——特别是“TXT”、“SRV”和“URI”[RFC1035][RFC2782][RFC6335][RFC7553]。它有效地将它们的一种用途与其他用途分开。在没有这种分离的情况下，这些RRSET的未区分质量将返回给DNS客户端，然后DNS客户端必须解析记录的内部，以期找到相关的记录。更糟糕的是，在某些情况下，结果是不明确的，因为记录类型可能无法充分自我识别其特定用途。使用基于下划线的作用域，只返回相关的RRSET。
A simple example is DomainKeys Identified Mail (DKIM) [RFC6376], which uses "_domainkey" to define a place to hold a TXT record containing signing information for the parent domain.
一个简单的例子是DomainKeys Identified Mail（DKIM）[RFC6376]，它使用“\u domainkey”定义一个位置来保存包含父域签名信息的TXT记录。
This specification formally defines how underscored names are used as "attribute" enhancements for their parent domain names. For example, the domain name "_domainkey.example." acts as an attribute of the parent domain name "example.". To avoid collisions resulting from
该规范正式定义了如何将带下划线的名称用作其父域名的“属性”增强。例如，域名“\u domainkey.example.”作为父域名“example.”的属性。以避免因碰撞而导致的碰撞
the use of the same underscored names for different applications using the same resource record type, this document establishes the "Underscored and Globally Scoped DNS Node Names" registry with IANA. Use of such node names, which begin with an underscore character, is reserved when they are the underscored name closest to the DNS root; as in that case, they are considered "global". Underscored names that are farther down the hierarchy are handled within the scope of the global underscored node name.
对于使用相同资源记录类型的不同应用程序，使用相同的带下划线的名称，本文档使用IANA建立“带下划线和全局作用域的DNS节点名称”注册表。当这些节点名称是最接近DNS根的带下划线的名称时，保留使用以下划线字符开头的节点名称；在这种情况下，它们被认为是“全球性的”。在层次结构较低的带下划线的名称在全局带下划线节点名称的范围内处理。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”在所有大写字母出现时（如图所示）应按照BCP 14[RFC2119][RFC8174]所述进行解释。
Some resource record types are used in a fashion that can create scaling problems if an entire RRset associated with a domain name is aggregated in the leaf node for that name. An increasingly popular approach, with excellent scaling properties, places the RRset under a specially named branch, which is in turn under the node name that would otherwise contain the RRset. The rules for naming that branch define the context for interpreting the RRset. That is, rather than:
如果与域名关联的整个RRset在该名称的叶节点中聚合，则某些资源记录类型的使用方式可能会产生缩放问题。一种越来越流行的方法，具有良好的伸缩特性，将RRset放在一个特殊命名的分支下，该分支又放在包含RRset的节点名下。命名该分支的规则定义了解释RRset的上下文。也就是说，而不是：
domain-name.example / RRset
domain-name.example/RRset
the arrangement is:
有关安排如下：
_branch.domain-name.example / RRset
_branch.domain-name.example/RRset
A direct lookup to the subordinate leaf node produces only the desired record types, at no greater cost than a typical DNS lookup.
对从属叶节点的直接查找只生成所需的记录类型，其成本不高于典型的DNS查找。
As defined in [RFC1034], the DNS uses names organized in a tree-structured or hierarchical fashion. A domain name might have multiple node names that begin with the underscore character (e.g., "_name"). A global underscored node name is the one that is closest to the root of the DNS hierarchy, also called the highest level or topmost. In the presentation convention described in Section 3.1 of [RFC1034], this is the rightmost name beginning with an underscore.
如[RFC1034]中所定义，DNS使用以树状结构或分层方式组织的名称。域名可能有多个以下划线字符开头的节点名（例如“_name”）。全局带下划线的节点名称是最接近DNS层次结构根的名称，也称为最高级别或最顶层。在[RFC1034]第3.1节所述的表示约定中，这是以下划线开头的最右边的名称。
In other presentation environments, it might be positioned differently. To avoid concern for the presentation variations, the qualifier "global" is used here.
在其他演示环境中，它的位置可能会有所不同。为了避免担心表示的变化，这里使用了限定符“global”。
DNS wildcards interact poorly with underscored names in two ways:
DNS通配符与带下划线的名称的交互有两种方式：
Since wildcards are only interpreted as leaf names, one cannot create the equivalent of a wildcard name for prefixed names. A name such as label.*.example.com is not a wildcard.
由于通配符仅解释为叶名称，因此不能为前缀名称创建与通配符名称等效的名称。label.*.example.com等名称不是通配符。
Conversely, a wildcard such as *.example.com can match any name including an underscored name. So, a wildcard might match an underscored name, returning a record that is the type controlled by the underscored name but is not intended to be used in the underscored context and does not conform to its rules.
相反，诸如*.example.com之类的通配符可以匹配任何名称，包括带下划线的名称。因此，通配符可能与带下划线的名称匹配，返回的记录类型由带下划线的名称控制，但不打算在带下划线的上下文中使用，也不符合其规则。
Originally, different uses of underscored node names developed largely without coordination. For TXT records, there is no consistent, internal syntax that permits distinguishing among the different uses. In the case of the SRV RR and URI RR, distinguishing among different types of use was part of the design (see [RFC2782] and [RFC7553]). The SRV and URI specifications serve as templates, defining RRs that might only be used for specific applications when there is an additional specification. The template definition included reference to two levels of tables of names from which underscored names should be drawn. The lower-level (local scope) set of "_service" names is defined in terms of other IANA tables, namely any table with symbolic names. The upper-level (global scope) SRV naming field is "_proto", although its pool of names is not explicitly defined.
最初，下划线节点名称的不同用法在很大程度上是在没有协调的情况下发展起来的。对于TXT记录，没有一致的内部语法来区分不同的用途。在SRV RR和URI RR的情况下，区分不同的使用类型是设计的一部分（参见[RFC2782]和[RFC7553]）。SRV和URI规范用作模板，定义了RRs，这些RRs可能仅在存在其他规范时用于特定应用程序。模板定义包括对两级名称表的引用，其中应绘制带下划线的名称。较低级别（本地范围）的“_服务”名称集是根据其他IANA表定义的，即具有符号名称的任何表。上层（全局范围）SRV命名字段是“_proto”，尽管其名称池没有明确定义。
The aggregate effect of these independent efforts was a long list of underscored names that were reserved without coordination, which invites an eventual name-assignment collision. The remedy is this base document and a companion document ([RFC8553]), which define a registry for these names and attempt to register all those already in use as well as to direct changes to the pre-registry specifications that used global underscored node names.
这些独立努力的总体效果是保留了一长串带下划线的姓名，但没有进行协调，这最终会导致姓名分配冲突。补救措施是这个基本文档和一个附带文档（[RFC8553]），它们为这些名称定义了一个注册表，并尝试注册所有已经在使用的名称，以及直接更改使用全局下划线节点名称的预注册表规范。
A registry for global DNS node names that begin with an underscore is defined here. The purpose of the "Underscored and Globally Scoped DNS Node Names" registry is to avoid collisions resulting from the use of the same underscored name for different applications.
此处定义了以下划线开头的全局DNS节点名称的注册表。“带下划线和全局作用域的DNS节点名称”注册表的目的是避免在不同的应用程序中使用相同的带下划线名称而导致的冲突。
If a public specification calls for use of an underscored node name, the global underscored node name -- the underscored name that is closest to the DNS root -- MUST be entered into this registry.
如果公共规范要求使用带下划线的节点名称，则必须在此注册表中输入全局带下划线的节点名称（最接近DNS根的带下划线的名称）。
An underscored name defines the scope of use for specific resource record types, which are associated with the domain name that is the "parent" to the branch defined by the underscored name. A given name defines a specific, constrained context for one or more RR TYPEs, where use of such record types conforms to the defined constraints.
带下划线的名称定义了特定资源记录类型的使用范围，这些类型与由带下划线的名称定义的分支的“父级”域名相关联。给定的名称为一个或多个RR类型定义了一个特定的、受约束的上下文，其中此类记录类型的使用符合定义的约束。
o Within a leaf that is underscore scoped, other RRsets that are not specified as part of the scope MAY be used.
o 在下划线作用域的叶中，可以使用未指定为作用域一部分的其他RRSET。
Structurally, the registry is defined as a single, flat table of RR TYPEs, under node names beginning with underscore. In some cases, such as for use of an SRV record, the full scoping name might be multi-part, as a sequence of underscored names. Semantically, that sequence represents a hierarchical model, and it is theoretically reasonable to allow reuse of a subordinate underscored name in a different, global underscored context; that is, a subordinate name is meaningful only within the scope of the global underscored node name. Therefore, they are ignored by this "Underscored and Globally Scoped DNS Node Names" registry. This registry is for the definition of highest-level -- that is, global -- underscored node name used.
从结构上讲，注册表被定义为RR类型的单一平面表，节点名以下划线开头。在某些情况下，例如为了使用SRV记录，完整的作用域名称可能是多部分的，如带下划线的名称序列。语义上，该序列表示一个层次模型，理论上允许在不同的全局下划线上下文中重用从属下划线名称是合理的；也就是说，从属名称仅在全局下划线节点名称的范围内有意义。因此，此“带下划线和全局作用域的DNS节点名称”注册表将忽略它们。此注册表用于定义使用的最高级别（即全局）带下划线的节点名。
+----------------------------+
| NAME |
+----------------------------+
| _service1 |
| _protoB._service2 |
| _protoB._service3 |
| _protoC._service3 |
| _useX._protoD._service4 |
| _protoE._region._authority |
+----------------------------+
+----------------------------+
| NAME |
+----------------------------+
| _service1 |
| _protoB._service2 |
| _protoB._service3 |
| _protoC._service3 |
| _useX._protoD._service4 |
| _protoE._region._authority |
+----------------------------+
Table 1: Examples of Underscored Names
表1：带下划线的名称示例
Only global underscored node names are registered in the "Underscored and Globally Scoped DNS Node Names" registry. From the example above, that would mean _service1, _service2, _service3, _service 4, and _authority would be listed in the IANA registry.
在“带下划线和全局作用域的DNS节点名称”注册表中仅注册全局带下划线的节点名称。从上面的例子来看，这意味着_service1、_service2、_service3、_service4和_authority将列在IANA注册表中。
o The use of underscored node names is specific to each RR TYPE that is being scoped. Each name defines a place but does not define the rules for what appears underneath that place, either as additional underscored naming or as a leaf node with resource records. Details for those rules are provided by specifications for individual RR TYPEs. The sections below describe the way that existing underscored names are used with the RR TYPEs that they name.
o 带下划线的节点名称的使用特定于要确定作用域的每个RR类型。每个名称都定义了一个位置，但没有定义该位置下面显示的内容的规则，可以是附加下划线命名，也可以是带有资源记录的叶节点。这些规则的详细信息由各个RR类型的规范提供。以下各节描述了现有下划线名称与它们命名的RR类型一起使用的方式。
o Definition and registration of subordinate underscored node names are the responsibility of the specification that creates the global underscored node name registry entry.
o 次级带下划线节点名称的定义和注册由创建全局带下划线节点名称注册表项的规范负责。
That is, if a scheme using a global underscored node name has one or more subordinate levels of underscored node naming, the namespaces from which names for those lower levels are chosen are controlled by the parent underscored node name. Each registered global underscored node name owns a distinct, subordinate namespace.
也就是说，如果使用全局下划线节点名称的方案具有一个或多个下划线节点命名的下级级别，则从中选择这些较低级别名称的名称空间由父下划线节点名称控制。每个已注册的全局节点名都拥有一个不同的从属名称空间。
This section provides guidance for specification writers, with a basic template they can use, to register new entries in the "Underscored and Globally Scoped DNS Node Names" registry. The text can be added to specifications using RR TYPE / _NODE NAME combinations that have not already been registered:
本节为规范编写者提供指导，并提供他们可以使用的基本模板，以便在“带下划线和全局作用域的DNS节点名称”注册表中注册新条目。可以使用尚未注册的RR TYPE/_节点名称组合将文本添加到规范中：
Per RFC 8552, please add the following entry to the "Underscored and Globally Scoped DNS Node Names" registry:
根据RFC 8552，请将以下条目添加到“带下划线和全局作用域的DNS节点名称”注册表中：
+---------+-------------------+-------------------------------------+
| RR Type | _NODE NAME | Reference |
+---------+-------------------+-------------------------------------+
| {RR | _{DNS global node | {citation for the document making |
| TYPE} | name} | the addition.} |
+---------+-------------------+-------------------------------------+
+---------+-------------------+-------------------------------------+
| RR Type | _NODE NAME | Reference |
+---------+-------------------+-------------------------------------+
| {RR | _{DNS global node | {citation for the document making |
| TYPE} | name} | the addition.} |
+---------+-------------------+-------------------------------------+
Table 2: Template for Entries in the "Underscored and Globally Scoped DNS Node Names" Registry
表2：“带下划线和全局作用域的DNS节点名称”注册表项的模板
IANA has established the "Underscored and Globally Scoped DNS Node Names" registry. This section describes the registry, the definitions, the initial entries, the use of_ta and _example, and the use of [RFC8126] as guidance for expert review. IANA has also updated the "Enumservices Registrations" registry with a pointer to this document.
IANA已经建立了“带下划线和全局范围的DNS节点名称”注册表。本节介绍了注册表、定义、初始条目、使用_ta和_示例以及使用[RFC8126]作为专家评审指南。IANA还使用指向此文档的指针更新了“Enumservices注册”注册表。
The "Underscored and Globally Scoped DNS Node Names" registry includes any DNS node name that begins with the underscore character ("_", ASCII 0x5F) and is the underscored node name closest to the root; that is, it defines the highest level of a DNS branch under a "parent" domain name.
“带下划线和全局作用域的DNS节点名称”注册表包括以下划线字符（“\”，ASCII 0x5F）开头且最接近根的带下划线节点名称的任何DNS节点名称；也就是说，它定义了“父”域名下DNS分支的最高级别。
o This registry operates under the IANA rules for "Expert Review" registration; see Section 4.1.5.
o 该登记处根据IANA“专家评审”登记规则运作；见第4.1.5节。
o The contents of each entry in the registry are defined in Section 4.1.1.
o 注册表中每个条目的内容在第4.1.1节中定义。
o Each entry in the registry MUST contain values for all of the fields specified in Section 4.1.1.
o 注册表中的每个条目必须包含第4.1.1节中指定的所有字段的值。
o Within the registry, the combination of RR Type and _NODE NAME MUST be unique.
o 在注册表中，RR类型和_节点名称的组合必须是唯一的。
o The table is to be maintained with entries sorted by the first column (RR Type) and, within that, the second column (_NODE NAME).
o 该表将使用按第一列（RR类型）和第二列（_节点名称）排序的条目进行维护。
o The required Reference for an entry MUST have a stable resolution to the organization controlling that registry entry.
o 条目所需的引用必须对控制该注册表条目的组织具有稳定的解析。
4.1.1. Contents of an Entry in the "Underscored and Globally Scoped DNS Node Names" Registry
4.1.1. “带下划线和全局作用域的DNS节点名称”注册表项的内容
A registry entry contains:
注册表项包含：
RR Type: Lists an RR TYPE that is defined for use within this scope.
RR类型：列出为在此范围内使用而定义的RR类型。
_NODE NAME: Specifies a single, underscored name that defines a reserved name; this name is the global entry name for the scoped resource record types that are associated with that name. For characters in the name that have an uppercase form and a lowercase form, the character MUST be recorded as lowercase to simplify name comparisons.
_节点名称：指定一个带下划线的名称，用于定义保留名称；此名称是与该名称关联的作用域资源记录类型的全局条目名称。对于名称中具有大写形式和小写形式的字符，必须将该字符记录为小写，以简化名称比较。
Reference: Lists the specification that defines a record type and its use under this _Node Name. The organization producing the specification retains control over the registry entry for the _Node Name.
参考：列出定义记录类型及其在此_节点名称下的使用的规范。生成规范的组织保留对_节点名称的注册表项的控制权。
Each RR TYPE that is to be used with a _Node Name MUST have a separate registry entry.
要与_节点名称一起使用的每个RR类型必须具有单独的注册表项。
The initial entries in the registry are as follows:
注册表中的初始条目如下：
+------------+-----------------------+---------------+
| RR Type | _NODE NAME | Reference |
+------------+-----------------------+---------------+
| * | _example | Section 4.1.4 |
| NULL | _ta-* {Section 4.1.3} | [RFC8145] |
| OPENPGPKEY | _openpgpkey | [RFC7929] |
| SMIMEA | _smimecert | [RFC8162] |
| SRV | _dccp | [RFC2782] |
| SRV | _http | [RFC4386] |
| SRV | _ipv6 | [RFC5026] |
| SRV | _ldap | [RFC4386] |
| SRV | _ocsp | [RFC4386] |
| SRV | _sctp | [RFC2782] |
| SRV | _sip | [RFC5509] |
| SRV | _tcp | [RFC2782] |
| SRV | _udp | [RFC2782] |
| SRV | _xmpp | [RFC3921] |
| TLSA | _dane | [RFC7671] |
| TLSA | _sctp | [RFC6698] |
| TLSA | _tcp | [RFC6698] |
+------------+-----------------------+---------------+
| RR Type | _NODE NAME | Reference |
+------------+-----------------------+---------------+
| * | _example | Section 4.1.4 |
| NULL | _ta-* {Section 4.1.3} | [RFC8145] |
| OPENPGPKEY | _openpgpkey | [RFC7929] |
| SMIMEA | _smimecert | [RFC8162] |
| SRV | _dccp | [RFC2782] |
| SRV | _http | [RFC4386] |
| SRV | _ipv6 | [RFC5026] |
| SRV | _ldap | [RFC4386] |
| SRV | _ocsp | [RFC4386] |
| SRV | _sctp | [RFC2782] |
| SRV | _sip | [RFC5509] |
| SRV | _tcp | [RFC2782] |
| SRV | _udp | [RFC2782] |
| SRV | _xmpp | [RFC3921] |
| TLSA | _dane | [RFC7671] |
| TLSA | _sctp | [RFC6698] |
| TLSA | _tcp | [RFC6698] |
| TLSA | _udp | [RFC6698] |
| TXT | _acme-challenge | [RFC8555] |
| TXT | _dmarc | [RFC7489] |
| TXT | _domainkey | [RFC6376] |
| TXT | _mta-sts | [RFC8461] |
| TXT | _spf | [RFC7208] |
| TXT | _sztp | [ZEROTOUCH] |
| TXT | _tcp | [RFC6763] |
| TXT | _udp | [RFC6763] |
| TXT | _vouch | [RFC5518] |
| URI | _acct | [RFC6118] |
| URI | _dccp | [RFC7566] |
| URI | _email | [RFC6118] |
| URI | _ems | [RFC6118] |
| URI | _fax | [RFC6118] |
| URI | _ft | [RFC6118] |
| URI | _h323 | [RFC6118] |
| URI | _iax | [RFC6118] |
| URI | _ical-access | [RFC6118] |
| URI | _ical-sched | [RFC6118] |
| URI | _ifax | [RFC6118] |
| URI | _im | [RFC6118] |
| URI | _mms | [RFC6118] |
| URI | _pres | [RFC6118] |
| URI | _pstn | [RFC6118] |
| URI | _sctp | [RFC6118] |
| URI | _sip | [RFC6118] |
| URI | _sms | [RFC6118] |
| URI | _tcp | [RFC6118] |
| URI | _udp | [RFC6118] |
| URI | _unifmsg | [RFC6118] |
| URI | _vcard | [RFC6118] |
| URI | _videomsg | [RFC6118] |
| URI | _voice | [RFC6118] |
| URI | _voicemsg | [RFC6118] |
| URI | _vpim | [RFC6118] |
| URI | _web | [RFC6118] |
| URI | _xmpp | [RFC6118] |
+------------+-----------------------+---------------+
| TLSA | _udp | [RFC6698] |
| TXT | _acme-challenge | [RFC8555] |
| TXT | _dmarc | [RFC7489] |
| TXT | _domainkey | [RFC6376] |
| TXT | _mta-sts | [RFC8461] |
| TXT | _spf | [RFC7208] |
| TXT | _sztp | [ZEROTOUCH] |
| TXT | _tcp | [RFC6763] |
| TXT | _udp | [RFC6763] |
| TXT | _vouch | [RFC5518] |
| URI | _acct | [RFC6118] |
| URI | _dccp | [RFC7566] |
| URI | _email | [RFC6118] |
| URI | _ems | [RFC6118] |
| URI | _fax | [RFC6118] |
| URI | _ft | [RFC6118] |
| URI | _h323 | [RFC6118] |
| URI | _iax | [RFC6118] |
| URI | _ical-access | [RFC6118] |
| URI | _ical-sched | [RFC6118] |
| URI | _ifax | [RFC6118] |
| URI | _im | [RFC6118] |
| URI | _mms | [RFC6118] |
| URI | _pres | [RFC6118] |
| URI | _pstn | [RFC6118] |
| URI | _sctp | [RFC6118] |
| URI | _sip | [RFC6118] |
| URI | _sms | [RFC6118] |
| URI | _tcp | [RFC6118] |
| URI | _udp | [RFC6118] |
| URI | _unifmsg | [RFC6118] |
| URI | _vcard | [RFC6118] |
| URI | _videomsg | [RFC6118] |
| URI | _voice | [RFC6118] |
| URI | _voicemsg | [RFC6118] |
| URI | _vpim | [RFC6118] |
| URI | _web | [RFC6118] |
| URI | _xmpp | [RFC6118] |
+------------+-----------------------+---------------+
Table 3: Initial Contents of the "Underscored and Globally Scoped DNS Node Names" Registry
表3：“带下划线和全局作用域的DNS节点名称”注册表的初始内容
Under the NULL RR Type, the entry "_ta-*" denotes all node names beginning with the string "_ta-*". It does NOT refer to a DNS wildcard specification.
在NULL RR类型下，条目“\u ta-*”表示以字符串“\u ta-*”开头的所有节点名称。它不引用DNS通配符规范。
The node name "_example" is reserved across all RRsets.
节点名“\u example”在所有RRSET中都是保留的。
This section provides guidance for expert review of registration requests in the "Underscored and Globally Scoped DNS Node Names" registry.
本节为专家审查“带下划线和全局范围的DNS节点名称”注册表中的注册请求提供指导。
This review is solely to determine adequacy of a requested entry in this registry, and it does not include review of other aspects of the document specifying that entry. For example, such a document might also contain a definition of the resource record type that is referenced by the requested entry. Any required review of that definition is separate from the expert review required here.
本审查仅用于确定本登记册中所请求条目的充分性，不包括对指定该条目的文件其他方面的审查。例如，这样的文档还可能包含由请求的条目引用的资源记录类型的定义。对该定义所需的任何审查均与此处所需的专家审查分开。
The review is for the purposes of ensuring that:
审查的目的是确保：
o The details for creating the registry entry are sufficiently clear, precise, and complete
o 创建注册表项的详细信息足够清晰、准确和完整
o The combination of the underscored name, under which the listed resource record type is used, and the resource record type is unique in the table
o 带下划线的名称的组合，在该名称下使用列出的资源记录类型，并且资源记录类型在表中是唯一的
For the purposes of this expert review, other matters of the specification's technical quality, adequacy, or the like are outside of scope.
就本专家评审而言，规范的技术质量、充分性等其他事项不在范围之内。
The following note has been added to the "Enumservice Registrations" registry:
以下注释已添加到“Enumservice Registrations”注册表中：
When adding an entry to this registry, strong consideration should be given to also adding an entry to the "Underscored and Globally Scoped DNS Node Names" registry.
在向该注册表添加条目时，应充分考虑向“带下划线和全局作用域的DNS节点名称”注册表添加条目。
This memo raises no security issues.
这份备忘录没有提出任何安全问题。
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, DOI 10.17487/RFC0952, October 1985, <https://www.rfc-editor.org/info/rfc952>.
[RFC0952]Harrenstien，K.，Stahl，M.和E.Feinler，“国防部互联网主机表规范”，RFC 952，DOI 10.17487/RFC0952，1985年10月<https://www.rfc-editor.org/info/rfc952>.
[RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, <https://www.rfc-editor.org/info/rfc1034>.
[RFC1034]Mockapetris，P.，“域名-概念和设施”，STD 13，RFC 1034，DOI 10.17487/RFC1034，1987年11月<https://www.rfc-editor.org/info/rfc1034>.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 1035，DOI 10.17487/RFC1035，1987年11月<https://www.rfc-editor.org/info/rfc1035>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<https://www.rfc-editor.org/info/rfc2119>.
[RFC2181] Elz, R. and R. Bush, "Clarifications to the DNS Specification", RFC 2181, DOI 10.17487/RFC2181, July 1997, <https://www.rfc-editor.org/info/rfc2181>.
[RFC2181]Elz，R.和R.Bush，“DNS规范的澄清”，RFC 2181，DOI 10.17487/RFC2181，1997年7月<https://www.rfc-editor.org/info/rfc2181>.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, DOI 10.17487/RFC2782, February 2000, <https://www.rfc-editor.org/info/rfc2782>.
[RFC2782]Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，DOI 10.17487/RFC2782，2000年2月<https://www.rfc-editor.org/info/rfc2782>.
[RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, DOI 10.17487/RFC3921, October 2004, <https://www.rfc-editor.org/info/rfc3921>.
[RFC3921]Saint Andre，P.，Ed.，“可扩展消息和状态协议（XMPP）：即时消息和状态”，RFC 3921，DOI 10.17487/RFC3921，2004年10月<https://www.rfc-editor.org/info/rfc3921>.
[RFC4386] Boeyen, S. and P. Hallam-Baker, "Internet X.509 Public Key Infrastructure Repository Locator Service", RFC 4386, DOI 10.17487/RFC4386, February 2006, <https://www.rfc-editor.org/info/rfc4386>.
[RFC4386]Boeyen，S.和P.Hallam Baker，“互联网X.509公钥基础设施存储库定位服务”，RFC 4386，DOI 10.17487/RFC4386，2006年2月<https://www.rfc-editor.org/info/rfc4386>.
[RFC5026] Giaretta, G., Ed., Kempf, J., and V. Devarapalli, Ed., "Mobile IPv6 Bootstrapping in Split Scenario", RFC 5026, DOI 10.17487/RFC5026, October 2007, <https://www.rfc-editor.org/info/rfc5026>.
[RFC5026]Giaretta，G.，Ed.，Kempf，J.，和V.Devarapalli，Ed.，“拆分场景中的移动IPv6引导”，RFC 5026，DOI 10.17487/RFC5026，2007年10月<https://www.rfc-editor.org/info/rfc5026>.
[RFC5509] Loreto, S., "Internet Assigned Numbers Authority (IANA) Registration of Instant Messaging and Presence DNS SRV RRs for the Session Initiation Protocol (SIP)", RFC 5509, DOI 10.17487/RFC5509, April 2009, <https://www.rfc-editor.org/info/rfc5509>.
[RFC5509]Loreto，S.，“互联网分配号码管理局（IANA）为会话启动协议（SIP）注册即时消息和状态DNS SRV RRs”，RFC 5509，DOI 10.17487/RFC5509，2009年4月<https://www.rfc-editor.org/info/rfc5509>.
[RFC5518] Hoffman, P., Levine, J., and A. Hathcock, "Vouch By Reference", RFC 5518, DOI 10.17487/RFC5518, April 2009, <https://www.rfc-editor.org/info/rfc5518>.
[RFC5518]Hoffman，P.，Levine，J.和A.Hathcock，“参考凭证”，RFC 5518，DOI 10.17487/RFC5518，2009年4月<https://www.rfc-editor.org/info/rfc5518>.
[RFC6118] Hoeneisen, B. and A. Mayrhofer, "Update of Legacy IANA Registrations of Enumservices", RFC 6118, DOI 10.17487/RFC6118, March 2011, <https://www.rfc-editor.org/info/rfc6118>.
[RFC6118]Hoenesen，B.和A.Mayrhofer，“Enumservices传统IANA注册的更新”，RFC 6118，DOI 10.17487/RFC6118，2011年3月<https://www.rfc-editor.org/info/rfc6118>.
[RFC6335] Cotton, M., Eggert, L., Touch, J., Westerlund, M., and S. Cheshire, "Internet Assigned Numbers Authority (IANA) Procedures for the Management of the Service Name and Transport Protocol Port Number Registry", BCP 165, RFC 6335, DOI 10.17487/RFC6335, August 2011, <https://www.rfc-editor.org/info/rfc6335>.
[RFC6335]Cotton，M.，Eggert，L.，Touch，J.，Westerlund，M.，和S.Cheshire，“互联网分配号码管理局（IANA）服务名称和传输协议端口号注册管理程序”，BCP 165，RFC 6335，DOI 10.17487/RFC6335，2011年8月<https://www.rfc-editor.org/info/rfc6335>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed., "DomainKeys Identified Mail (DKIM) Signatures", STD 76, RFC 6376, DOI 10.17487/RFC6376, September 2011, <https://www.rfc-editor.org/info/rfc6376>.
[RFC6376]Crocker，D.，Ed.，Hansen，T.，Ed.，和M.Kucherawy，Ed.，“域密钥识别邮件（DKIM）签名”，STD 76，RFC 6376，DOI 10.17487/RFC6376，2011年9月<https://www.rfc-editor.org/info/rfc6376>.
[RFC6698] Hoffman, P. and J. Schlyter, "The DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS) Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August 2012, <https://www.rfc-editor.org/info/rfc6698>.
[RFC6698]Hoffman，P.和J.Schlyter，“基于DNS的命名实体认证（DANE）传输层安全（TLS）协议：TLSA”，RFC 6698，DOI 10.17487/RFC6698，2012年8月<https://www.rfc-editor.org/info/rfc6698>.
[RFC6763] Cheshire, S. and M. Krochmal, "DNS-Based Service Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013, <https://www.rfc-editor.org/info/rfc6763>.
[RFC6763]Cheshire，S.和M.Krocmal，“基于DNS的服务发现”，RFC 6763，DOI 10.17487/RFC6763，2013年2月<https://www.rfc-editor.org/info/rfc6763>.
[RFC7208] Kitterman, S., "Sender Policy Framework (SPF) for Authorizing Use of Domains in Email, Version 1", RFC 7208, DOI 10.17487/RFC7208, April 2014, <https://www.rfc-editor.org/info/rfc7208>.
[RFC7208]Kitterman，S.，“授权在电子邮件中使用域的发件人策略框架（SPF），第1版”，RFC 7208，DOI 10.17487/RFC7208，2014年4月<https://www.rfc-editor.org/info/rfc7208>.
[RFC7489] Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based Message Authentication, Reporting, and Conformance (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015, <https://www.rfc-editor.org/info/rfc7489>.
[RFC7489]Kucherawy，M.，Ed.和E.Zwicky，Ed.，“基于域的消息验证、报告和一致性（DMARC）”，RFC 7489，DOI 10.17487/RFC7489，2015年3月<https://www.rfc-editor.org/info/rfc7489>.
[RFC7553] Faltstrom, P. and O. Kolkman, "The Uniform Resource Identifier (URI) DNS Resource Record", RFC 7553, DOI 10.17487/RFC7553, June 2015, <https://www.rfc-editor.org/info/rfc7553>.
[RFC7553]Faltstrom，P.和O.Kolkman，“统一资源标识符（URI）DNS资源记录”，RFC 7553，DOI 10.17487/RFC7553，2015年6月<https://www.rfc-editor.org/info/rfc7553>.
[RFC7566] Goix, L. and K. Li, "Enumservice Registration for 'acct' URI", RFC 7566, DOI 10.17487/RFC7566, June 2015, <https://www.rfc-editor.org/info/rfc7566>.
[RFC7566]Goix，L.和K.Li，“账户URI的Enumservice注册”，RFC 7566，DOI 10.17487/RFC7566，2015年6月<https://www.rfc-editor.org/info/rfc7566>.
[RFC7671] Dukhovni, V. and W. Hardaker, "The DNS-Based Authentication of Named Entities (DANE) Protocol: Updates and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671, October 2015, <https://www.rfc-editor.org/info/rfc7671>.
[RFC7671]Dukhovni，V.和W.Hardaker，“基于DNS的命名实体认证（DANE）协议：更新和操作指南”，RFC 7671，DOI 10.17487/RFC7671，2015年10月<https://www.rfc-editor.org/info/rfc7671>.
[RFC7929] Wouters, P., "DNS-Based Authentication of Named Entities (DANE) Bindings for OpenPGP", RFC 7929, DOI 10.17487/RFC7929, August 2016, <https://www.rfc-editor.org/info/rfc7929>.
[RFC7929]Wouters，P.，“OpenPGP命名实体（DANE）绑定的基于DNS的认证”，RFC 7929，DOI 10.17487/RFC79292016年8月<https://www.rfc-editor.org/info/rfc7929>.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]Cotton，M.，Leiba，B.，和T.Narten，“在RFC中编写IANA考虑事项部分的指南”，BCP 26，RFC 8126，DOI 10.17487/RFC8126，2017年6月<https://www.rfc-editor.org/info/rfc8126>.
[RFC8145] Wessels, D., Kumari, W., and P. Hoffman, "Signaling Trust Anchor Knowledge in DNS Security Extensions (DNSSEC)", RFC 8145, DOI 10.17487/RFC8145, April 2017, <https://www.rfc-editor.org/info/rfc8145>.
[RFC8145]Wessels，D.，Kumari，W.和P.Hoffman，“DNS安全扩展（DNSSEC）中的信令信任锚知识”，RFC8145DOI 10.17487/RFC81452017年4月<https://www.rfc-editor.org/info/rfc8145>.
[RFC8162] Hoffman, P. and J. Schlyter, "Using Secure DNS to Associate Certificates with Domain Names for S/MIME", RFC 8162, DOI 10.17487/RFC8162, May 2017, <https://www.rfc-editor.org/info/rfc8162>.
[RFC8162]Hoffman，P.和J.Schlyter，“使用安全DNS将证书与S/MIME域名关联”，RFC 8162，DOI 10.17487/RFC8162，2017年5月<https://www.rfc-editor.org/info/rfc8162>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174]Leiba，B.，“RFC 2119关键词中大写与小写的歧义”，BCP 14，RFC 8174，DOI 10.17487/RFC8174，2017年5月<https://www.rfc-editor.org/info/rfc8174>.
[RFC8461] Margolis, D., Risher, M., Ramakrishnan, B., Brotman, A., and J. Jones, "SMTP MTA Strict Transport Security (MTA-STS)", RFC 8461, DOI 10.17487/RFC8461, September 2018, <https://www.rfc-editor.org/info/rfc8461>.
[RFC8461]Margolis，D.，Risher，M.，Ramakrishnan，B.，Brotman，A.，和J.Jones，“SMTP MTA严格传输安全（MTA-STS）”，RFC 8461，DOI 10.17487/RFC8461，2018年9月<https://www.rfc-editor.org/info/rfc8461>.
[RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, <https://www.rfc-editor.org/info/rfc8555>.
[RFC8555]Barnes，R.，Hoffman Andrews，J.，McCarney，D.，和J.Kasten，“自动证书管理环境（ACME）”，RFC 8555，DOI 10.17487/RFC8555，2019年3月<https://www.rfc-editor.org/info/rfc8555>.
[RFC8553] Crocker, D., "DNS Attrleaf Changes: Fixing Specifications That Use Underscored Node Names", RFC 8553, DOI 10.17487/RFC8553, March 2019, <https://www.rfc-editor.org/info/rfc8553>.
[RFC8553]Crocker，D.，“DNS属性页更改：修复使用下划线节点名称的规范”，RFC 8553，DOI 10.17487/RFC8553，2019年3月<https://www.rfc-editor.org/info/rfc8553>.
[ZEROTOUCH] Watsen, K., Abrahamsson, M., and I. Farrer, "Secure Zero Touch Provisioning (SZTP)", Work in Progress, draft-ietf-netconf-zerotouch-29, January 2019.
[ZEROTOUCH]Watsen，K.，Abrahamsson，M.，和I.Farrer，“安全零接触供应（SZTP）”，正在进行的工作，草案-ietf-netconf-ZEROTOUCH-292019年1月。
Acknowledgements
致谢
Thanks go to Bill Fenner, Dick Franks, Tony Hansen, Martin Hoffmann, Paul Hoffman, Peter Koch, Olaf Kolkman, Murray Kucherawy, John Levine, Benno Overeinder, and Andrew Sullivan for diligent review of the (much) earlier draft versions. For the later enhancements, thanks to Stephane Bortzmeyer, Alissa Cooper, Bob Harold, Joel Jaeggli, Benjamin Kaduk, Mirja Kuehlewind, Warren Kumari, John Levine, Benno Overeinder, Eric Rescorla, Adam Roach, Petr Spacek, Ondrej Sury, Paul Vixie, Tim Wicinski, and Paul Wouters.
感谢Bill Fenner、Dick Franks、Tony Hansen、Martin Hoffmann、Paul Hoffman、Peter Koch、Olaf Kolkman、Murray Kucherawy、John Levine、Benno Overfinder和Andrew Sullivan对（更）早期版本草案的认真审查。对于后来的增强，感谢斯蒂芬·博茨迈耶、艾莉莎·库珀、鲍勃·哈罗德、乔尔·贾格利、本杰明·卡杜克、米尔贾·库勒温德、沃伦·库马里、约翰·莱文、本诺·奥文德、埃里克·雷科拉、亚当·罗奇、彼得·斯派克、昂德瑞·苏里、保罗·维克西、蒂姆·维辛斯基和保罗·沃特斯。
Special thanks to Ray Bellis for his persistent encouragement to continue this effort, as well as the suggestion for an essential simplification to the registration model.
特别感谢Ray Bellis坚持不懈地鼓励继续这一努力，以及对注册模式进行必要简化的建议。
Author's Address
作者地址
Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA 94086 United States of America
Dave Crocker Brandenburg互联675 Spruce Dr.Sunnyvale，加利福尼亚州，美国94086
Phone: +1.408.246.8253
Email: dcrocker@bbiw.net
URI: http://bbiw.net/
Phone: +1.408.246.8253
Email: dcrocker@bbiw.net
URI: http://bbiw.net/