Internet Engineering Task Force (IETF) S. Hollenbeck
Request for Comments: 8521 Verisign Labs
BCP: 221 A. Newton
Updates: 7484 ARIN
Category: Best Current Practice November 2018
ISSN: 2070-1721
Internet Engineering Task Force (IETF) S. Hollenbeck
Request for Comments: 8521 Verisign Labs
BCP: 221 A. Newton
Updates: 7484 ARIN
Category: Best Current Practice November 2018
ISSN: 2070-1721
Registration Data Access Protocol (RDAP) Object Tagging
注册数据访问协议（RDAP）对象标记
Abstract
摘要
The Registration Data Access Protocol (RDAP) includes a method that can be used to identify the authoritative server for processing domain name, IP address, and autonomous system number queries. The method does not describe how to identify the authoritative server for processing other RDAP query types, such as entity queries. This limitation exists because the identifiers associated with these query types are typically unstructured. This document updates RFC 7484 by describing an operational practice that can be used to add structure to RDAP identifiers and that makes it possible to identify the authoritative server for additional RDAP queries.
注册数据访问协议（RDAP）包括一种方法，可用于识别用于处理域名、IP地址和自主系统号查询的权威服务器。该方法不描述如何识别用于处理其他RDAP查询类型（如实体查询）的权威服务器。存在此限制是因为与这些查询类型关联的标识符通常是非结构化的。本文档通过描述一种操作实践来更新RFC 7484，该操作实践可用于向RDAP标识符添加结构，并可用于为其他RDAP查询标识权威服务器。
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/rfc8521.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问https://www.rfc-editor.org/info/rfc8521.
Copyright Notice
版权公告
Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2018 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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Object Naming Practice . . . . . . . . . . . . . . . . . . . 3
3. Bootstrap Service Registry for Provider Object Tags . . . . . 9
3.1. Registration Procedure . . . . . . . . . . . . . . . . . 10
4. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.1. Bootstrap Service Registry Structure . . . . . . . . . . 11
5.2. RDAP Extensions Registry . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Object Naming Practice . . . . . . . . . . . . . . . . . . . 3
3. Bootstrap Service Registry for Provider Object Tags . . . . . 9
3.1. Registration Procedure . . . . . . . . . . . . . . . . . 10
4. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
5.1. Bootstrap Service Registry Structure . . . . . . . . . . 11
5.2. RDAP Extensions Registry . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.1. Normative References . . . . . . . . . . . . . . . . . . 12
7.2. Informative References . . . . . . . . . . . . . . . . . 12
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
The Registration Data Access Protocol (RDAP) includes a method [RFC7484] that can be used to identify the authoritative server for processing domain name, IP address, and Autonomous System Number (ASN) queries. This method works because each of these data elements is structured in a way that facilitates automated parsing of the element and association of the data element with a particular RDAP service provider. For example, domain names include labels (such as "com", "net", and "org") that are associated with specific service providers.
注册数据访问协议（RDAP）包括一种方法[RFC7484]，该方法可用于识别用于处理域名、IP地址和自主系统号（ASN）查询的权威服务器。这种方法之所以有效，是因为这些数据元素的结构都有助于自动解析元素以及数据元素与特定RDAP服务提供商的关联。例如，域名包括与特定服务提供商关联的标签（如“com”、“net”和“org”）。
As noted in Section 9 of RFC 7484 [RFC7484], the method does not describe how to identify the authoritative server for processing entity queries, name server queries, help queries, or queries using certain search patterns. This limitation exists because the identifiers bound to these queries are typically not structured in a way that makes it easy to associate an identifier with a specific service provider. This document describes an operational practice that can be used to add structure to RDAP identifiers and makes it possible to identify the authoritative server for additional RDAP queries.
如RFC 7484[RFC7484]第9节所述，该方法不描述如何识别用于处理实体查询、名称服务器查询、帮助查询或使用特定搜索模式的查询的权威服务器。存在此限制是因为绑定到这些查询的标识符的结构通常不便于将标识符与特定服务提供商关联。本文档描述了一种操作实践，可用于向RDAP标识符添加结构，并使其能够识别用于其他RDAP查询的权威服务器。
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]所述进行解释。
Tagging object identifiers with a service provider tag makes it possible to identify the authoritative server for processing an RDAP query using the method described in RFC 7484 [RFC7484]. A service provider tag is constructed by prepending the Unicode HYPHEN-MINUS character "-" (U+002D, described as an "unreserved" character in RFC 3986 [RFC3986]) to an IANA-registered value that represents the service provider. For example, a tag for a service provider identified by the string value "ARIN" is represented as "-ARIN".
使用服务提供者标记标记对象标识符可以使用RFC 7484[RFC7484]中描述的方法识别用于处理RDAP查询的权威服务器。通过将Unicode连字符-减号“-”（U+002D，在RFC 3986[RFC3986]中被描述为“无保留”字符）前置到表示服务提供者的IANA注册值来构造服务提供者标记。例如，由字符串值“ARIN”标识的服务提供商的标记表示为“-ARIN”。
In combination with the rdapConformance attribute described in Section 4, service provider tags are concatenated to the end of RDAP query object identifiers to unambiguously identify the authoritative server for processing an RDAP query. Building on the example from Section 3.1.5 of RFC 7482 [RFC7482], an RDAP entity handle can be constructed to allow an RDAP client to bootstrap an entity query.
结合第4节中描述的rdapConformance属性，服务提供者标记连接到RDAP查询对象标识符的末尾，以明确标识用于处理RDAP查询的权威服务器。以RFC 7482[RFC7482]第3.1.5节中的示例为基础，可以构造RDAP实体句柄，以允许RDAP客户端引导实体查询。
The following identifier is used to find information for the entity associated with handle "XXXX" at service provider "ARIN":
以下标识符用于查找与服务提供商“ARN”上的句柄“XXXX”关联的实体的信息：
XXXX-ARIN
XXXX-ARIN
Clients that wish to bootstrap an entity query can parse this identifier into distinct handle and service provider identifier elements. Handles can themselves contain HYPHEN-MINUS characters; the service provider identifier is found following the last HYPHEN-MINUS character in the tagged identifier. The service provider identifier is used to retrieve a base RDAP URL from an IANA registry. The base URL and entity handle are then used to form a complete RDAP query path segment. For example, if the base RDAP URL "https://example.com/rdap/" is associated with service provider "YYYY" in an IANA registry, an RDAP client will parse a tagged entity identifier "XXXX-YYYY" into distinct handle ("XXXX") and service provider ("YYYY") identifiers. The service provider identifier "YYYY" is used to query an IANA registry to retrieve the base RDAP URL "https://example.com/rdap/". The RDAP query URL is formed using the base RDAP URL and entity path segment described in Section 3.1.5 of RFC 7482 [RFC7482] and using "XXXX-YYY" as the value of the handle identifier. The complete RDAP query URL becomes "https://example.com/rdap/entity/XXXX-YYYY".
希望引导实体查询的客户端可以将该标识符解析为不同的句柄和服务提供者标识符元素。句柄本身可以包含连字符和减号字符；服务提供商标识符位于标记标识符中最后一个连字符的后面。服务提供者标识符用于从IANA注册表检索基本RDAP URL。然后使用基本URL和实体句柄形成完整的RDAP查询路径段。例如，如果基本RDAP URL“https://example.com/rdap/与IANA注册表中的服务提供商“YYYY”关联，RDAP客户端将标记的实体标识符“XXXX-YYYY”解析为不同的句柄（“XXXX”）和服务提供商（“YYYY”）标识符。服务提供商标识符“yyy”用于查询IANA注册表以检索基本RDAP URL“https://example.com/rdap/". RDAP查询URL使用RFC 7482[RFC7482]第3.1.5节中描述的基本RDAP URL和实体路径段，并使用“XXXX-YYY”作为句柄标识符的值形成。完整的RDAP查询URL变为“https://example.com/rdap/entity/XXXX-YYYY".
Implementation of this practice requires tagging of unstructured potential query identifiers in RDAP responses. Consider these elided examples ("..." is used to note elided response objects) from Section 5.3 of RFC 7483 [RFC7483] in which the handle identifiers have been tagged with service provider tags "RIR", "DNR", and "ABC", respectively:
此实践的实现需要在RDAP响应中标记非结构化的潜在查询标识符。从这些RFC 7483（RFC783]的第5.3节中，考虑到这些已删除的实例（“…”用于记录ELID响应对象），其中句柄标识符分别用服务提供者标签“RIR”、“DNR”和“ABC”标记：
{
"objectClassName" : "domain",
"handle" : "XXXX-RIR",
"ldhName" : "0.2.192.in-addr.arpa",
"nameservers" :
[
...
],
"secureDNS":
{
...
},
"remarks" :
[
...
],
"links" :
{
"objectClassName" : "domain",
"handle" : "XXXX-RIR",
"ldhName" : "0.2.192.in-addr.arpa",
"nameservers" :
[
...
],
"secureDNS":
{
...
},
"remarks" :
[
...
],
"links" :
[
...
],
"events" :
[
...
],
"entities" :
[
{
"objectClassName" : "entity",
"handle" : "XXXX-RIR",
"vcardArray":
[
...
],
"roles" : [ "registrant" ],
"remarks" :
[
...
],
"links" :
[
...
],
"events" :
[
...
]
}
],
"network" :
{
"objectClassName" : "ip network",
"handle" : "XXXX-RIR",
"startAddress" : "192.0.2.0",
"endAddress" : "192.0.2.255",
"ipVersion" : "v4",
"name": "NET-RTR-1",
"type" : "DIRECT ALLOCATION",
"country" : "AU",
"parentHandle" : "YYYY-RIR",
"status" : [ "active" ]
}
}
[
...
],
"events" :
[
...
],
"entities" :
[
{
"objectClassName" : "entity",
"handle" : "XXXX-RIR",
"vcardArray":
[
...
],
"roles" : [ "registrant" ],
"remarks" :
[
...
],
"links" :
[
...
],
"events" :
[
...
]
}
],
"network" :
{
"objectClassName" : "ip network",
"handle" : "XXXX-RIR",
"startAddress" : "192.0.2.0",
"endAddress" : "192.0.2.255",
"ipVersion" : "v4",
"name": "NET-RTR-1",
"type" : "DIRECT ALLOCATION",
"country" : "AU",
"parentHandle" : "YYYY-RIR",
"status" : [ "active" ]
}
}
Figure 1
图1
{
"objectClassName" : "domain",
"handle" : "XXXX-YYY-DNR",
"ldhName" : "xn--fo-5ja.example",
"unicodeName" : "foo.example",
"variants" :
[
...
],
"status" : [ "locked", "transfer prohibited" ],
"publicIds":
[
...
],
"nameservers" :
[
{
"objectClassName" : "nameserver",
"handle" : "XXXX-DNR",
"ldhName" : "ns1.example.com",
"status" : [ "active" ],
"ipAddresses" :
{
...
},
"remarks" :
[
...
],
"links" :
[
...
],
"events" :
[
...
]
},
{
"objectClassName" : "nameserver",
"handle" : "XXXX-DNR",
"ldhName" : "ns2.example.com",
"status" : [ "active" ],
"ipAddresses" :
{
...
},
"remarks" :
{
"objectClassName" : "domain",
"handle" : "XXXX-YYY-DNR",
"ldhName" : "xn--fo-5ja.example",
"unicodeName" : "foo.example",
"variants" :
[
...
],
"status" : [ "locked", "transfer prohibited" ],
"publicIds":
[
...
],
"nameservers" :
[
{
"objectClassName" : "nameserver",
"handle" : "XXXX-DNR",
"ldhName" : "ns1.example.com",
"status" : [ "active" ],
"ipAddresses" :
{
...
},
"remarks" :
[
...
],
"links" :
[
...
],
"events" :
[
...
]
},
{
"objectClassName" : "nameserver",
"handle" : "XXXX-DNR",
"ldhName" : "ns2.example.com",
"status" : [ "active" ],
"ipAddresses" :
{
...
},
"remarks" :
[
...
],
"links" :
[
...
],
"events" :
[
...
]
}
],
"secureDNS":
{
...
},
"remarks" :
[
...
],
"links" :
[
...
],
"port43" : "whois.example.net",
"events" :
[
...
],
"entities" :
[
{
"objectClassName" : "entity",
"handle" : "XXXX-ABC",
"vcardArray":
[
...
],
"status" : [ "validated", "locked" ],
"roles" : [ "registrant" ],
"remarks" :
[
...
],
"links" :
[
...
[
...
],
"links" :
[
...
],
"events" :
[
...
]
}
],
"secureDNS":
{
...
},
"remarks" :
[
...
],
"links" :
[
...
],
"port43" : "whois.example.net",
"events" :
[
...
],
"entities" :
[
{
"objectClassName" : "entity",
"handle" : "XXXX-ABC",
"vcardArray":
[
...
],
"status" : [ "validated", "locked" ],
"roles" : [ "registrant" ],
"remarks" :
[
...
],
"links" :
[
...
],
"events" :
[
...
]
}
]
}
],
"events" :
[
...
]
}
]
}
Figure 2
图2
As described in Section 5 of RFC 7483 [RFC7483], RDAP responses can contain "self" links. Service provider tags and self references SHOULD be consistent. If they are inconsistent, the service provider tag is processed with higher priority when using these values to identify a service provider.
如RFC 7483[RFC7483]第5节所述，RDAP响应可以包含“自”链接。服务提供商标记和自引用应保持一致。如果它们不一致，则在使用这些值标识服务提供商时，服务提供商标记将以更高的优先级进行处理。
There is a risk of unpredictable processing behavior if the HYPHEN-MINUS character is used for naturally occurring, non-separator purposes in an entity handle. This could lead to a client mistakenly assuming that a HYPHEN-MINUS character represents a separator and that the text that follows HYPHEN-MINUS is a service provider identifier. A client that queries the IANA registry for what they assume is a valid service provider will likely receive an unexpected, invalid result. As a consequence, use of the HYPHEN-MINUS character as a service provider tag separator MUST be noted by adding an rdapConformance value to query responses as described in Section 4.
如果连字符用于实体句柄中自然出现的非分隔符目的，则存在不可预测的处理行为的风险。这可能会导致客户端错误地认为连字符-减号字符表示分隔符，并且连字符-减号后面的文本是服务提供商标识符。查询IANA注册表以确定其假定为有效服务提供商的客户端可能会收到意外的无效结果。因此，必须注意使用连字符作为服务提供者标记分隔符，方法是向查询响应添加rdapConformance值，如第4节所述。
The HYPHEN-MINUS character was chosen as a separator for two reasons: 1) it is a familiar separator character in operational use, and 2) it avoids collision with URI-reserved characters. The list of unreserved characters specified in Section 2.3 of RFC 3986 [RFC3986] provided multiple options for consideration:
选择连字符作为分隔符有两个原因：1）它是操作使用中常见的分隔符，2）它避免了与URI保留字符的冲突。RFC 3986[RFC3986]第2.3节中规定的无保留字符列表提供了多个选项供考虑：
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
ALPHA and DIGIT characters were excluded because they are commonly used in entity handles for non-separator purposes. HYPHEN-MINUS is commonly used as a separator, and recognition of this practice will reduce implementation requirements and operational risk. The remaining characters were excluded because they are not broadly used as separators in entity handles.
字母和数字字符被排除在外，因为它们通常在实体句柄中用于非分隔符目的。连字符-减号通常用作分隔符，认识到这种做法将降低实施要求和运营风险。其余字符被排除在外，因为它们没有广泛用作实体句柄中的分隔符。
The bootstrap service registry for the RDAP service provider space is represented using the structure specified in Section 3 of RFC 7484 [RFC7484]. The JSON output of this registry contains contact information for the registered service provider identifiers, alphanumeric identifiers that identify RDAP service providers, and base RDAP service URLs as shown in this example.
RDAP服务提供程序空间的引导服务注册表使用RFC 7484[RFC7484]第3节中指定的结构表示。此注册表的JSON输出包含注册的服务提供者标识符、标识RDAP服务提供者的字母数字标识符和基本RDAP服务URL的联系信息，如本例所示。
{
"version": "1.0",
"publication": "YYYY-MM-DDTHH:MM:SSZ",
"description": "RDAP bootstrap file for service provider object tags",
"services": [
[
["contact@example.com"],
["YYYY"],
[
"https://example.com/rdap/"
]
],
[
["contact@example.org"],
["ZZ54"],
[
"http://rdap.example.org/"
]
],
[
["contact@example.net"],
["1754"],
[
"https://example.net/rdap/",
"http://example.net/rdap/"
]
]
]
}
{
"version": "1.0",
"publication": "YYYY-MM-DDTHH:MM:SSZ",
"description": "RDAP bootstrap file for service provider object tags",
"services": [
[
["contact@example.com"],
["YYYY"],
[
"https://example.com/rdap/"
]
],
[
["contact@example.org"],
["ZZ54"],
[
"http://rdap.example.org/"
]
],
[
["contact@example.net"],
["1754"],
[
"https://example.net/rdap/",
"http://example.net/rdap/"
]
]
]
}
Figure 3
图3
Alphanumeric service provider identifiers conform to the suffix portion ("\w{1,8}") of the "roidType" syntax specified in Section 4.2 of RFC 5730 [RFC5730].
字母数字服务提供商标识符符合RFC 5730[RFC5730]第4.2节中规定的“roidType”语法的后缀部分（“\w{1,8}”）。
The service provider registry is populated using the "First Come First Served" policy defined in RFC 8126 [RFC8126]. Provider identifier values can be derived and assigned by IANA on request. Registration requests include an email address to be associated with the registered service provider identifier, the requested service provider identifier (or an indication that IANA should assign an identifier), and one or more base RDAP URLs to be associated with the service provider identifier.
使用RFC 8126[RFC8126]中定义的“先到先得”策略填充服务提供商注册表。IANA可以根据请求派生和分配提供者标识符值。注册请求包括与注册服务提供商标识符关联的电子邮件地址、请求的服务提供商标识符（或IANA应分配标识符的指示）以及与服务提供商标识符关联的一个或多个基本RDAP URL。
RDAP responses that contain values described in this document MUST indicate conformance with this specification by including an rdapConformance [RFC7483] value of "rdap_objectTag_level_0". The information needed to register this value in the "RDAP Extensions" registry is described in Section 5.2.
包含本文档中描述的值的RDAP响应必须通过包含“RDAP_objectTag_level_0”的rdapConformance[RFC7483]值来表示符合本规范。第5.2节描述了在“RDAP扩展”注册表中注册该值所需的信息。
The following is an example rdapConformance structure with the extension specified.
以下是具有指定扩展名的rdapConformance结构示例。
"rdapConformance" : [ "rdap_level_0", "rdap_objectTag_level_0" ]
“rdapConformance”：[“rdap\u级别\u 0”、“rdap\u对象标记\u级别\u 0”]
Figure 4
图4
IANA has created the RDAP "Bootstrap Service Registry for Provider Object Tags" listed below and made it available as a JSON object. The contents of this registry are described in Section 3; the formal syntax is specified in Section 10 of RFC 7484 [RFC7484].
IANA已经创建了下面列出的RDAP“提供者对象标记的引导服务注册表”，并将其作为JSON对象提供。本登记册的内容见第3节；RFC 7484[RFC7484]第10节规定了形式语法。
Entries in this registry contain the following information:
此注册表中的条目包含以下信息：
o an email address that identifies a contact associated with the registered RDAP service provider value. o an alphanumeric value that identifies the RDAP service provider being registered. o one or more URLs that provide the RDAP service regarding this registration. The URLs are expected to supply the same data, but they can differ in scheme or other components as required by the service operator.
o 标识与已注册RDAP服务提供商值关联的联系人的电子邮件地址。o标识正在注册的RDAP服务提供商的字母数字值。o提供有关此注册的RDAP服务的一个或多个URL。URL应提供相同的数据，但根据服务运营商的要求，它们可以在方案或其他组件上有所不同。
IANA has registered the following value in the "RDAP Extensions" registry:
IANA已在“RDAP扩展”注册表中注册了以下值：
Extension identifier: rdap_objectTag
Registry operator: Any
Published specification: This document
Contact: IESG <iesg@ietf.org>
Extension identifier: rdap_objectTag
Registry operator: Any
Published specification: This document
Contact: IESG <iesg@ietf.org>
Intended usage: This extension describes a best practice for structuring entity identifiers to enable query bootstrapping.
预期用途：此扩展描述了构造实体标识符以启用查询引导的最佳实践。
This practice uses IANA as a well-known, centrally trusted authority to allow users to get RDAP data from an authoritative source, which reduces the risk of sending queries to non-authoritative sources and divulging query information to unintended parties. Using TLS 1.2 [RFC5246] or TLS 1.3 [RFC8446], which obsoletes TLS 1.2, to protect the connection to IANA allows the server to authenticate itself as being operated by IANA and provides integrity protection for the resulting referral information, as well as provides privacy protection via data confidentiality. The subsequent RDAP connection is performed as usual and retains the same security properties of the RDAP protocols themselves as described in RFC 7481 [RFC7481].
这种做法使用IANA作为知名的中央受信任机构，允许用户从权威来源获取RDAP数据，从而降低了向非权威来源发送查询以及向意外方泄露查询信息的风险。使用淘汰TLS 1.2的TLS 1.2[RFC5246]或TLS 1.3[RFC8446]来保护与IANA的连接，允许服务器验证自己是否由IANA操作，并为产生的转介信息提供完整性保护，以及通过数据保密性提供隐私保护。随后的RDAP连接照常执行，并保留RFC 7481[RFC7481]中所述的RDAP协议本身的相同安全属性。
[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>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, <https://www.rfc-editor.org/info/rfc5730>.
[RFC5730]Hollenbeck，S.，“可扩展资源调配协议（EPP）”，STD 69，RFC 5730，DOI 10.17487/RFC5730，2009年8月<https://www.rfc-editor.org/info/rfc5730>.
[RFC7484] Blanchet, M., "Finding the Authoritative Registration Data (RDAP) Service", RFC 7484, DOI 10.17487/RFC7484, March 2015, <https://www.rfc-editor.org/info/rfc7484>.
[RFC7484]Blanchet，M.“查找权威注册数据（RDAP）服务”，RFC 7484，DOI 10.17487/RFC7484，2015年3月<https://www.rfc-editor.org/info/rfc7484>.
[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>.
[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>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，DOI 10.17487/RFC3986，2005年1月<https://www.rfc-editor.org/info/rfc3986>.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, DOI 10.17487/RFC5246, August 2008, <https://www.rfc-editor.org/info/rfc5246>.
[RFC5246]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，DOI 10.17487/RFC5246，2008年8月<https://www.rfc-editor.org/info/rfc5246>.
[RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the Registration Data Access Protocol (RDAP)", RFC 7481, DOI 10.17487/RFC7481, March 2015, <https://www.rfc-editor.org/info/rfc7481>.
[RFC7481]Hollenbeck，S.和N.Kong，“注册数据访问协议（RDAP）的安全服务”，RFC 7481，DOI 10.17487/RFC7481，2015年3月<https://www.rfc-editor.org/info/rfc7481>.
[RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access Protocol (RDAP) Query Format", RFC 7482, DOI 10.17487/RFC7482, March 2015, <https://www.rfc-editor.org/info/rfc7482>.
[RFC7482]Newton，A.和S.Hollenbeck，“注册数据访问协议（RDAP）查询格式”，RFC 7482，DOI 10.17487/RFC7482，2015年3月<https://www.rfc-editor.org/info/rfc7482>.
[RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the Registration Data Access Protocol (RDAP)", RFC 7483, DOI 10.17487/RFC7483, March 2015, <https://www.rfc-editor.org/info/rfc7483>.
[RFC7483]Newton，A.和S.Hollenbeck，“注册数据访问协议（RDAP）的JSON响应”，RFC 7483，DOI 10.17487/RFC7483，2015年3月<https://www.rfc-editor.org/info/rfc7483>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.
[RFC8446]Rescorla，E.“传输层安全（TLS）协议版本1.3”，RFC 8446，DOI 10.17487/RFC8446，2018年8月<https://www.rfc-editor.org/info/rfc8446>.
Acknowledgements
致谢
The authors would like to acknowledge the following individuals for their contributions to the development of this document: Tom Harrison, Patrick Mevzek, and Marcos Sanz. In addition, the authors would like to recognize the Regional Internet Registry (RIR) operators (AFRINIC, APNIC, ARIN, LACNIC, and RIPE) that have been implementing and using the practice of tagging handle identifiers for several years. Their experience provided significant inspiration for the development of this document.
作者要感谢以下个人对本文件的开发所做的贡献：Tom Harrison、Patrick Mevzek和Marcos Sanz。此外，作者还想表彰几年来一直实施和使用标记句柄标识符实践的区域互联网注册（RIR）运营商（AFRINIC、APNIC、ARIN、LACNIC和RIME）。他们的经验为本文件的编写提供了重要启示。
Authors' Addresses
作者地址
Scott Hollenbeck Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States of America
Scott Hollenbeck Verisign实验室12061美国弗吉尼亚州布鲁蒙特路莱斯顿20190
Email: shollenbeck@verisign.com
URI: http://www.verisignlabs.com/
Email: shollenbeck@verisign.com
URI: http://www.verisignlabs.com/
Andrew Lee Newton American Registry for Internet Numbers PO Box 232290 Centreville, VA 20120 United States of America
Andrew Lee Newton美国互联网号码注册处美国弗吉尼亚州Centreville 232290邮政信箱20120
Email: andy@arin.net
URI: http://www.arin.net
Email: andy@arin.net
URI: http://www.arin.net