Internet Engineering Task Force (IETF) A. Newton
Request for Comments: 7482 ARIN
Category: Standards Track S. Hollenbeck
ISSN: 2070-1721 Verisign Labs
March 2015
Internet Engineering Task Force (IETF) A. Newton
Request for Comments: 7482 ARIN
Category: Standards Track S. Hollenbeck
ISSN: 2070-1721 Verisign Labs
March 2015
Registration Data Access Protocol (RDAP) Query Format
注册数据访问协议（RDAP）查询格式
Abstract
摘要
This document describes uniform patterns to construct HTTP URLs that may be used to retrieve registration information from registries (including both Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)) using "RESTful" web access patterns. These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP).
本文档描述了使用“RESTful”web访问模式构建HTTP URL的统一模式，这些URL可用于从注册中心（包括区域Internet注册中心（RIR）和域名注册中心（DNR））检索注册信息。这些统一模式定义了注册数据访问协议（RDAP）的查询语法。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
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 Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7482.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7482.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://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文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
2.1. Acronyms and Abbreviations . . . . . . . . . . . . . . . 4
3. Path Segment Specification . . . . . . . . . . . . . . . . . 4
3.1. Lookup Path Segment Specification . . . . . . . . . . . . 5
3.1.1. IP Network Path Segment Specification . . . . . . . . 6
3.1.2. Autonomous System Path Segment Specification . . . . 7
3.1.3. Domain Path Segment Specification . . . . . . . . . . 7
3.1.4. Nameserver Path Segment Specification . . . . . . . . 8
3.1.5. Entity Path Segment Specification . . . . . . . . . . 9
3.1.6. Help Path Segment Specification . . . . . . . . . . . 9
3.2. Search Path Segment Specification . . . . . . . . . . . . 9
3.2.1. Domain Search . . . . . . . . . . . . . . . . . . . . 10
3.2.2. Nameserver Search . . . . . . . . . . . . . . . . . . 11
3.2.3. Entity Search . . . . . . . . . . . . . . . . . . . . 12
4. Query Processing . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Partial String Searching . . . . . . . . . . . . . . . . 13
4.2. Associated Records . . . . . . . . . . . . . . . . . . . 14
5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Internationalization Considerations . . . . . . . . . . . . . 15
6.1. Character Encoding Considerations . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions Used in This Document . . . . . . . . . . . . . . 4
2.1. Acronyms and Abbreviations . . . . . . . . . . . . . . . 4
3. Path Segment Specification . . . . . . . . . . . . . . . . . 4
3.1. Lookup Path Segment Specification . . . . . . . . . . . . 5
3.1.1. IP Network Path Segment Specification . . . . . . . . 6
3.1.2. Autonomous System Path Segment Specification . . . . 7
3.1.3. Domain Path Segment Specification . . . . . . . . . . 7
3.1.4. Nameserver Path Segment Specification . . . . . . . . 8
3.1.5. Entity Path Segment Specification . . . . . . . . . . 9
3.1.6. Help Path Segment Specification . . . . . . . . . . . 9
3.2. Search Path Segment Specification . . . . . . . . . . . . 9
3.2.1. Domain Search . . . . . . . . . . . . . . . . . . . . 10
3.2.2. Nameserver Search . . . . . . . . . . . . . . . . . . 11
3.2.3. Entity Search . . . . . . . . . . . . . . . . . . . . 12
4. Query Processing . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Partial String Searching . . . . . . . . . . . . . . . . 13
4.2. Associated Records . . . . . . . . . . . . . . . . . . . 14
5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 14
6. Internationalization Considerations . . . . . . . . . . . . . 15
6.1. Character Encoding Considerations . . . . . . . . . . . . 15
7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative References . . . . . . . . . . . . . . . . . . 17
8.2. Informative References . . . . . . . . . . . . . . . . . 19
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
This document describes a specification for querying registration data using a RESTful web service and uniform query patterns. The service is implemented using the Hypertext Transfer Protocol (HTTP) [RFC7230] and the conventions described in [RFC7480]. These uniform patterns define the query syntax for the Registration Data Access Protocol (RDAP).
本文档描述了使用RESTfulWeb服务和统一查询模式查询注册数据的规范。该服务使用超文本传输协议（HTTP）[RFC7230]和[RFC7480]中描述的约定实现。这些统一模式定义了注册数据访问协议（RDAP）的查询语法。
The protocol described in this specification is intended to address deficiencies with the WHOIS protocol [RFC3912] that have been identified over time, including:
本规范中描述的协议旨在解决WHOIS协议[RFC3912]的缺陷，这些缺陷随着时间的推移而被识别，包括：
o lack of standardized command structures;
o 缺乏标准化的指挥结构；
o lack of standardized output and error structures;
o 缺乏标准化的输出和错误结构；
o lack of support for internationalization and localization; and
o 缺乏对国际化和本地化的支持；和
o lack of support for user identification, authentication, and access control.
o 缺乏对用户标识、身份验证和访问控制的支持。
The patterns described in this document purposefully do not encompass all of the methods employed in the WHOIS and other RESTful web services used by the RIRs and DNRs. The intent of the patterns described here are to enable queries of:
本文档中描述的模式有意地不包括WHOIS中使用的所有方法以及RIRs和DNRs使用的其他RESTfulWeb服务。这里描述的模式旨在支持以下查询：
o networks by IP address;
o 按IP地址划分的网络；
o Autonomous System (AS) numbers by number;
o 自治系统（AS）按编号编号；
o reverse DNS metadata by domain;
o 按域反向DNS元数据；
o nameservers by name;
o 按名称命名的服务器；
o registrars by name; and
o 登记员姓名；和
o entities (such as contacts) by identifier.
o 按标识符列出的实体（如联系人）。
Server implementations are free to support only a subset of these features depending on local requirements. Servers MUST return an HTTP 501 (Not Implemented) [RFC7231] response to inform clients of unsupported query types. It is also envisioned that each registry will continue to maintain WHOIS and/or other RESTful web services specific to their needs and those of their constituencies, and the information retrieved through the patterns described here may reference such services.
根据本地需求，服务器实现只支持这些功能的一个子集。服务器必须返回HTTP 501（未实现）[RFC7231]响应，以通知客户端不支持的查询类型。还可以设想，每个注册中心将继续维护WHOIS和/或其他RESTful web服务，以满足其需求及其用户群的需求，通过本文描述的模式检索的信息可能会引用这些服务。
Likewise, future IETF standards may add additional patterns for additional query types. A simple pattern namespacing scheme is described in Section 5 to accommodate custom extensions that will not interfere with the patterns defined in this document or patterns defined in future IETF standards.
同样，未来的IETF标准可能会为额外的查询类型添加额外的模式。第5节描述了一个简单的模式名称空间方案，以适应不会干扰本文档中定义的模式或未来IETF标准中定义的模式的自定义扩展。
WHOIS services, in general, are read-only services. Therefore, URL [RFC3986] patterns specified in this document are only applicable to the HTTP [RFC7231] GET and HEAD methods.
WHOIS服务通常是只读服务。因此，本文档中指定的URL[RFC3986]模式仅适用于HTTP[RFC7231]GET和HEAD方法。
This document does not describe the results or entities returned from issuing the described URLs with an HTTP GET. The specification of these entities is described in [RFC7483].
本文档不描述通过HTTP GET发布所述URL返回的结果或实体。[RFC7483]中描述了这些实体的规范。
Additionally, resource management, provisioning, and update functions are out of scope for this document. Registries have various and divergent methods covering these functions, and it is unlikely a uniform approach is needed for interoperability.
此外，资源管理、资源调配和更新功能超出了本文档的范围。注册中心有各种不同的方法来覆盖这些功能，互操作性不太可能需要统一的方法。
HTTP contains mechanisms for servers to authenticate clients and for clients to authenticate servers (from which authorization schemes may be built), so such mechanisms are not described in this document. Policy, provisioning, and processing of authentication and authorization are out of scope for this document as deployments will have to make choices based on local criteria. Supported authentication mechanisms are described in [RFC7481].
HTTP包含用于服务器对客户端进行身份验证和用于客户端对服务器进行身份验证的机制（可以从中构建授权方案），因此本文档中不描述此类机制。策略、资源调配以及身份验证和授权的处理超出了本文档的范围，因为部署必须根据本地标准进行选择。[RFC7481]中描述了支持的身份验证机制。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
IDN: Internationalized Domain Name
IDN：国际化域名
IDNA: Internationalized Domain Names in Applications, a protocol for the handling of IDNs.
IDNA：应用程序中的国际化域名，处理IDN的协议。
DNR: Domain Name Registry
域名注册
NFC: Unicode Normalization Form C [Unicode-UAX15]
NFC:Unicode规范化表单C[Unicode-UAX15]
NFKC: Unicode Normalization Form KC [Unicode-UAX15]
NFKC:Unicode规范化表单KC[Unicode-UAX15]
RDAP: Registration Data Access Protocol
注册数据访问协议
REST: Representational State Transfer. The term was first described in a doctoral dissertation [REST].
REST：代表性状态转移。这个术语最初是在一篇博士论文[REST]中描述的。
RESTful: An adjective that describes a service using HTTP and the principles of REST.
RESTful：描述使用HTTP和REST原则的服务的形容词。
RIR: Regional Internet Registry
RIR：区域互联网注册处
The base URLs used to construct RDAP queries are maintained in an IANA registry described in [RFC7484]. Queries are formed by retrieving an appropriate base URL from the registry and appending a path segment specified in either Sections 3.1 or 3.2. Generally, a registry or other service provider will provide a base URL that identifies the protocol, host, and port, and this will be used as a base URL that the complete URL is resolved against, as per Section 5
用于构造RDAP查询的基本URL保存在[RFC7484]中描述的IANA注册表中。查询是通过从注册表中检索适当的基本URL并附加第3.1节或第3.2节中指定的路径段形成的。通常，注册中心或其他服务提供商将提供一个标识协议、主机和端口的基本URL，并根据第5节将其用作完整URL解析所依据的基本URL
of RFC 3986 [RFC3986]. For example, if the base URL is "https://example.com/rdap/", all RDAP query URLs will begin with "https://example.com/rdap/".
RFC 3986[RFC3986]的标准。例如，如果基本URL为“https://example.com/rdap/，所有RDAP查询URL将以开头https://example.com/rdap/".
The bootstrap registry does not contain information for query objects that are not part of a global namespace, including entities and help. A base URL for an associated object is required to construct a complete query.
引导注册表不包含不属于全局命名空间的查询对象的信息，包括实体和帮助。构造完整查询需要关联对象的基本URL。
For entities, a base URL is retrieved for the service (domain, address, etc.) associated with a given entity. The query URL is constructed by concatenating the base URL to the entity path segment specified in either Sections 3.1.5 or 3.2.3.
对于实体，检索与给定实体关联的服务（域、地址等）的基本URL。通过将基本URL连接到第3.1.5节或第3.2.3节中指定的实体路径段来构造查询URL。
For help, a base URL is retrieved for any service (domain, address, etc.) for which additional information is required. The query URL is constructed by concatenating the base URL to the help path segment specified in Section 3.1.6.
为了获得帮助，将检索任何需要附加信息的服务（域、地址等）的基本URL。通过将基本URL连接到第3.1.6节中指定的帮助路径段来构造查询URL。
A simple lookup to determine if an object exists (or not) without returning RDAP-encoded results can be performed using the HTTP HEAD method as described in Section 4.1 of [RFC7480].
可以使用[RFC7480]第4.1节所述的HTTP HEAD方法执行简单的查找，以确定对象是否存在（或不存在），而不返回RDAP编码的结果。
The resource type path segments for exact match lookup are:
用于精确匹配查找的资源类型路径段包括：
o 'ip': Used to identify IP networks and associated data referenced using either an IPv4 or IPv6 address.
o “ip”：用于标识ip网络和使用IPv4或IPv6地址引用的关联数据。
o 'autnum': Used to identify Autonomous System number registrations and associated data referenced using an asplain Autonomous System number.
o “autnum”：用于标识自治系统号注册和使用asplain自治系统号引用的相关数据。
o 'domain': Used to identify reverse DNS (RIR) or domain name (DNR) information and associated data referenced using a fully qualified domain name.
o “域”：用于标识反向DNS（RIR）或域名（DNR）信息以及使用完全限定域名引用的相关数据。
o 'nameserver': Used to identify a nameserver information query using a host name.
o “名称服务器”：用于标识使用主机名的名称服务器信息查询。
o 'entity': Used to identify an entity information query using a string identifier.
o “实体”：用于使用字符串标识符标识实体信息查询。
Syntax: ip/<IP address> or ip/<CIDR prefix>/<CIDR length>
Syntax: ip/<IP address> or ip/<CIDR prefix>/<CIDR length>
Queries for information about IP networks are of the form /ip/XXX/... or /ip/XXX/YY/... where the path segment following 'ip' is either an IPv4 dotted decimal or IPv6 [RFC5952] address (i.e., XXX) or an IPv4 or IPv6 Classless Inter-domain Routing (CIDR) [RFC4632] notation address block (i.e., XXX/YY). Semantically, the simpler form using the address can be thought of as a CIDR block with a bitmask length of 32 for IPv4 and a bitmask length of 128 for IPv6. A given specific address or CIDR may fall within multiple IP networks in a hierarchy of networks; therefore, this query targets the "most-specific" or smallest IP network that completely encompasses it in a hierarchy of IP networks.
有关IP网络信息的查询格式为/IP/XXX/。。。或/ip/XXX/YY/。。。其中，“ip”后面的路径段是IPv4点十进制或IPv6[RFC5952]地址（即XXX）或IPv4或IPv6无类域间路由（CIDR）[RFC4632]表示法地址块（即XXX/YY）。从语义上讲，使用地址的更简单形式可以被认为是一个CIDR块，对于IPv4，位掩码长度为32，对于IPv6，位掩码长度为128。给定的特定地址或CIDR可能位于网络层次结构中的多个IP网络中；因此，此查询以“最特定”或最小的IP网络为目标，该网络在IP网络的层次结构中完全包含它。
The IPv4 and IPv6 address formats supported in this query are described in Section 3.2.2 of RFC 3986 [RFC3986] as IPv4address and IPv6address ABNF definitions. Any valid IPv6 text address format [RFC4291] can be used. This includes IPv6 addresses written using with or without compressed zeros and IPv6 addresses containing embedded IPv4 addresses. The rules to write a text representation of an IPv6 address [RFC5952] are RECOMMENDED. However, the zone_id [RFC4007] is not appropriate in this context; therefore, the corresponding syntax extension in RFC 6874 [RFC6874] MUST NOT be used, and servers are to ignore it if possible.
RFC 3986[RFC3986]第3.2.2节将此查询中支持的IPv4和IPv6地址格式描述为IPv4address和IPv6address ABNF定义。可以使用任何有效的IPv6文本地址格式[RFC4291]。这包括使用或不使用压缩零写入的IPv6地址，以及包含嵌入式IPv4地址的IPv6地址。建议使用规则写入IPv6地址的文本表示形式[RFC5952]。然而，区域标识[RFC4007]在这种情况下并不合适；因此，RFC 6874[RFC6874]中相应的语法扩展不能使用，如果可能，服务器将忽略它。
For example, the following URL would be used to find information for the most specific network containing 192.0.2.0:
例如，以下URL将用于查找包含192.0.2.0的最特定网络的信息：
https://example.com/rdap/ip/192.0.2.0
https://example.com/rdap/ip/192.0.2.0
The following URL would be used to find information for the most specific network containing 192.0.2.0/24:
以下URL将用于查找包含192.0.2.0/24的最特定网络的信息：
https://example.com/rdap/ip/192.0.2.0/24
https://example.com/rdap/ip/192.0.2.0/24
The following URL would be used to find information for the most specific network containing 2001:db8::0:
以下URL将用于查找包含2001:db8:：0的最特定网络的信息：
https://example.com/rdap/ip/2001:db8::0
https://example.com/rdap/ip/2001:db8::0
Syntax: autnum/<autonomous system number>
Syntax: autnum/<autonomous system number>
Queries for information regarding Autonomous System number registrations are of the form /autnum/XXX/... where XXX is an asplain Autonomous System number [RFC5396]. In some registries, registration of Autonomous System numbers is done on an individual number basis, while other registries may register blocks of Autonomous System numbers. The semantics of this query are such that if a number falls within a range of registered blocks, the target of the query is the block registration and that individual number registrations are considered a block of numbers with a size of 1.
有关自主系统编号注册信息的查询采用/autnum/XXX/…形式。。。其中XXX是阿斯普兰自治系统编号[RFC5396]。在一些注册中心，自主系统编号的注册是在单个编号的基础上进行的，而其他注册中心可以注册自主系统编号块。此查询的语义是这样的：如果一个数字位于已注册块的范围内，则查询的目标是块注册，并且单个数字注册被视为大小为1的数字块。
For example, the following URL would be used to find information describing Autonomous System number 12 (a number within a range of registered blocks):
例如，以下URL将用于查找描述自治系统编号12（注册块范围内的编号）的信息：
https://example.com/rdap/autnum/12
https://example.com/rdap/autnum/12
The following URL would be used to find information describing 4-byte Autonomous System number 65538:
以下URL将用于查找描述4字节自治系统编号65538的信息：
https://example.com/rdap/autnum/65538
https://example.com/rdap/autnum/65538
Syntax: domain/<domain name>
Syntax: domain/<domain name>
Queries for domain information are of the form /domain/XXXX/..., where XXXX is a fully qualified (relative to the root) domain name (as specified in [RFC0952] and [RFC1123]) in either the in-addr.arpa or ip6.arpa zones (for RIRs) or a fully qualified domain name in a zone administered by the server operator (for DNRs). Internationalized Domain Names (IDNs) represented in either A-label or U-label format [RFC5890] are also valid domain names. See Section 6.1 for information on character encoding for the U-label format.
域信息查询的形式为/domain/XXXX/…，其中XXXX是in-addr.arpa或ip6.arpa区域（对于RIR）中的完全限定（相对于根）域名（如[RFC0952]和[RFC1123]中所述），或者是由服务器运营商管理的区域（对于DNR）中的完全限定域名。以A标签或U标签格式[RFC5890]表示的国际化域名（IDN）也是有效的域名。有关U型标签格式的字符编码信息，请参见第6.1节。
IDNs SHOULD NOT be represented as a mixture of A-labels and U-labels; that is, internationalized labels in an IDN SHOULD be either all A-labels or all U-labels. It is possible for an RDAP client to assemble a query string from multiple independent data sources. Such a client might not be able to perform conversions between A-labels and U-labels. An RDAP server that receives a query string with a mixture of A-labels and U-labels MAY convert all the U-labels to A-labels, perform IDNA processing, and proceed with exact-match
IDN不应表示为a标签和U标签的混合物；也就是说，IDN中的国际化标签应该是全部A标签或全部U标签。RDAP客户端可以从多个独立的数据源组合查询字符串。这样的客户端可能无法在a标签和U标签之间执行转换。接收混合了a标签和U标签的查询字符串的RDAP服务器可以将所有U标签转换为a标签，执行IDNA处理，并继续进行精确匹配
lookup. In such cases, the response to be returned to the query source may not match the input from the query source. Alternatively, the server MAY refuse to process the query.
查找。在这种情况下，返回到查询源的响应可能与来自查询源的输入不匹配。或者，服务器可以拒绝处理查询。
The server MAY perform the match using either the A-label or U-label form. Using one consistent form for matching every label is likely to be more reliable.
服务器可以使用A标签或U标签表单执行匹配。使用一个一致的表单匹配每个标签可能更可靠。
The following URL would be used to find information describing the zone serving the network 192.0.2/24:
以下URL将用于查找描述为网络192.0.2/24提供服务的区域的信息：
https://example.com/rdap/domain/2.0.192.in-addr.arpa
https://example.com/rdap/domain/2.0.192.in-addr.arpa
The following URL would be used to find information describing the zone serving the network 2001:db8:1::/48:
以下URL将用于查找描述为网络2001提供服务的区域的信息：db8:1:：/48：
https://example.com/rdap/domain/1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
https://example.com/rdap/domain/1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa
The following URL would be used to find information for the blah.example.com domain name:
以下URL将用于查找blah.example.com域名的信息：
https://example.com/rdap/domain/blah.example.com
https://example.com/rdap/domain/blah.example.com
The following URL would be used to find information for the xn--fo-5ja.example IDN:
以下URL将用于查找xn--fo-5ja的信息。示例IDN：
https://example.com/rdap/domain/xn--fo-5ja.example
https://example.com/rdap/domain/xn--fo-5ja.example
Syntax: nameserver/<nameserver name>
Syntax: nameserver/<nameserver name>
The <nameserver name> parameter represents a fully qualified host name as specified in [RFC0952] and [RFC1123]. Internationalized names represented in either A-label or U-label format [RFC5890] are also valid nameserver names. IDN processing for nameserver names uses the domain name processing instructions specified in Section 3.1.3. See Section 6.1 for information on character encoding for the U-label format.
<nameservername>参数表示[RFC0952]和[RFC1123]中指定的完全限定主机名。以A-label或U-label格式[RFC5890]表示的国际化名称也是有效的名称服务器名称。名称服务器名称的IDN处理使用第3.1.3节中指定的域名处理说明。有关U型标签格式的字符编码信息，请参见第6.1节。
The following URL would be used to find information for the ns1.example.com nameserver:
以下URL将用于查找ns1.example.com名称服务器的信息：
https://example.com/rdap/nameserver/ns1.example.com
https://example.com/rdap/nameserver/ns1.example.com
The following URL would be used to find information for the ns1.xn--fo-5ja.example nameserver:
以下URL将用于查找ns1.xn--fo-5ja.example名称服务器的信息：
https://example.com/rdap/nameserver/ns1.xn--fo-5ja.example
https://example.com/rdap/nameserver/ns1.xn--fo-5ja.example
Syntax: entity/<handle>
Syntax: entity/<handle>
The <handle> parameter represents an entity (such as a contact, registrant, or registrar) identifier whose syntax is specific to the registration provider. For example, for some DNRs, contact identifiers are specified in [RFC5730] and [RFC5733].
<handle>参数表示一个实体（如联系人、注册人或注册人）标识符，其语法特定于注册提供者。例如，对于某些DNR，[RFC5730]和[RFC5733]中指定了联系人标识符。
The following URL would be used to find information for the entity associated with handle XXXX:
以下URL将用于查找与句柄XXXX关联的实体的信息：
https://example.com/rdap/entity/XXXX
https://example.com/rdap/entity/XXXX
Syntax: help
语法：帮助
The help path segment can be used to request helpful information (command syntax, terms of service, privacy policy, rate-limiting policy, supported authentication methods, supported extensions, technical support contact, etc.) from an RDAP server. The response to "help" should provide basic information that a client needs to successfully use the service. The following URL would be used to return "help" information:
帮助路径段可用于从RDAP服务器请求有用信息（命令语法、服务条款、隐私策略、速率限制策略、支持的身份验证方法、支持的扩展、技术支持联系人等）。对“帮助”的响应应提供客户端成功使用服务所需的基本信息。以下URL将用于返回“帮助”信息：
https://example.com/rdap/help
https://example.com/rdap/help
Pattern matching semantics are described in Section 4.1. The resource type path segments for search are:
模式匹配语义在第4.1节中描述。用于搜索的资源类型路径段包括：
o 'domains': Used to identify a domain name information search using a pattern to match a fully qualified domain name.
o “域”：用于标识域名信息搜索，使用模式匹配完全限定的域名。
o 'nameservers': Used to identify a nameserver information search using a pattern to match a host name.
o “名称服务器”：用于标识名称服务器信息搜索，使用模式匹配主机名。
o 'entities': Used to identify an entity information search using a pattern to match a string identifier.
o “实体”：用于标识实体信息搜索，使用模式匹配字符串标识符。
RDAP search path segments are formed using a concatenation of the plural form of the object being searched for and an HTTP query string. The HTTP query string is formed using a concatenation of the question mark character ('?', US-ASCII value 0x003F), the JSON object value associated with the object being searched for, the equal sign character ('=', US-ASCII value 0x003D), and the search pattern. Search pattern query processing is described more fully in Section 4. For the domain, nameserver, and entity objects described in this document, the plural object forms are "domains", "nameservers", and "entities".
RDAP搜索路径段是使用被搜索对象的复数形式和HTTP查询字符串的串联形成的。HTTP查询字符串是使用问号字符（“？”，US-ASCII值0x003F）、与正在搜索的对象相关联的JSON对象值、等号字符（“=”，US-ASCII值0x003D）和搜索模式串联而成的。第4节对搜索模式查询处理进行了更全面的描述。对于本文档中描述的域、名称服务器和实体对象，复数对象形式为“域”、“名称服务器”和“实体”。
Detailed results can be retrieved using the HTTP GET method and the path segments specified here.
可以使用HTTP GET方法和此处指定的路径段检索详细结果。
Syntax: domains?name=<domain search pattern>
Syntax: domains?name=<domain search pattern>
Syntax: domains?nsLdhName=<domain search pattern>
Syntax: domains?nsLdhName=<domain search pattern>
Syntax: domains?nsIp=<domain search pattern>
Syntax: domains?nsIp=<domain search pattern>
Searches for domain information by name are specified using this form:
使用以下表单指定按名称搜索域信息：
domains?name=XXXX
域名？名称=XXXX
XXXX is a search pattern representing a domain name in "letters, digits, hyphen" (LDH) format [RFC5890] in a zone administered by the server operator of a DNR. The following URL would be used to find DNR information for domain names matching the "example*.com" pattern:
XXXX是一种搜索模式，在DNR的服务器操作员管理的区域内，以“字母、数字、连字符”（LDH）格式[RFC5890]表示域名。以下URL将用于查找与“example*.com”模式匹配的域名的DNR信息：
https://example.com/rdap/domains?name=example*.com
https://example.com/rdap/domains?name=example*.com
IDNs in U-label format [RFC5890] can also be used as search patterns (see Section 4). Searches for these names are of the form /domains?name=XXXX, where XXXX is a search pattern representing a domain name in U-label format [RFC5890]. See Section 6.1 for information on character encoding for the U-label format.
U标签格式[RFC5890]的IDN也可用作搜索模式（见第4节）。搜索这些名称的形式为/domains？name=XXXX，其中XXXX是一种搜索模式，表示U标签格式[RFC5890]的域名。有关U型标签格式的字符编码信息，请参见第6.1节。
Searches for domain information by nameserver name are specified using this form:
使用以下表单指定按名称服务器名称搜索域信息：
domains?nsLdhName=YYYY
域？nsLdhName=YYYY
YYYY is a search pattern representing a host name in "letters, digits, hyphen" format [RFC5890] in a zone administered by the server operator of a DNR. The following URL would be used to search for domains delegated to nameservers matching the "ns1.example*.com" pattern:
YYYY是一种搜索模式，在DNR的服务器操作员管理的区域中以“字母、数字、连字符”格式[RFC5890]表示主机名。以下URL将用于搜索委派给与“ns1.example*.com”模式匹配的名称服务器的域：
https://example.com/rdap/domains?nsLdhName=ns1.example*.com
https://example.com/rdap/domains?nsLdhName=ns1.example*.com
Searches for domain information by nameserver IP address are specified using this form:
使用以下表单指定按名称服务器IP地址搜索域信息：
domains?nsIp=ZZZZ
域？nsIp=ZZZZ
ZZZZ is a search pattern representing an IPv4 [RFC1166] or IPv6 [RFC5952] address. The following URL would be used to search for domains that have been delegated to nameservers that resolve to the "192.0.2.0" address:
ZZZZ是表示IPv4[RFC1166]或IPv6[RFC5952]地址的搜索模式。以下URL将用于搜索已委托给解析为“192.0.2.0”地址的名称服务器的域：
https://example.com/rdap/domains?nsIp=192.0.2.0
https://example.com/rdap/domains?nsIp=192.0.2.0
Syntax: nameservers?name=<nameserver search pattern>
Syntax: nameservers?name=<nameserver search pattern>
Syntax: nameservers?ip=<nameserver search pattern>
Syntax: nameservers?ip=<nameserver search pattern>
Searches for nameserver information by nameserver name are specified using this form:
使用以下表单指定按名称服务器名称搜索名称服务器信息：
nameservers?name=XXXX
名称服务器？名称=XXXX
XXXX is a search pattern representing a host name in "letters, digits, hyphen" format [RFC5890] in a zone administered by the server operator of a DNR. The following URL would be used to find DNR information for nameserver names matching the "ns1.example*.com" pattern:
XXXX是一种搜索模式，在DNR服务器操作员管理的区域内，以“字母、数字、连字符”格式[RFC5890]表示主机名。以下URL将用于查找与“ns1.example*.com”模式匹配的名称服务器名称的DNR信息：
https://example.com/rdap/nameservers?name=ns1.example*.com
https://example.com/rdap/nameservers?name=ns1.example*.com
Internationalized nameserver names in U-label format [RFC5890] can also be used as search patterns (see Section 4). Searches for these names are of the form /nameservers?name=XXXX, where XXXX is a search pattern representing a nameserver name in U-label format [RFC5890]. See Section 6.1 for information on character encoding for the U-label format.
U-label格式[RFC5890]的国际化名称服务器名称也可以用作搜索模式（参见第4节）。搜索这些名称的形式为/nameservers？name=XXXX，其中XXXX是一种搜索模式，表示U标签格式[RFC5890]的名称服务器名称。有关U型标签格式的字符编码信息，请参见第6.1节。
Searches for nameserver information by nameserver IP address are specified using this form:
使用以下表单指定按名称服务器IP地址搜索名称服务器信息：
nameservers?ip=YYYY
名称服务器？ip=YYYY
YYYY is a search pattern representing an IPv4 [RFC1166] or IPv6 [RFC5952] address. The following URL would be used to search for nameserver names that resolve to the "192.0.2.0" address:
YYYY是表示IPv4[RFC1166]或IPv6[RFC5952]地址的搜索模式。以下URL将用于搜索解析为“192.0.2.0”地址的名称服务器名称：
https://example.com/rdap/nameservers?ip=192.0.2.0
https://example.com/rdap/nameservers?ip=192.0.2.0
Syntax: entities?fn=<entity name search pattern>
Syntax: entities?fn=<entity name search pattern>
Syntax: entities?handle=<entity handle search pattern>
Syntax: entities?handle=<entity handle search pattern>
Searches for entity information by name are specified using this form:
使用以下表单指定按名称搜索实体信息：
entities?fn=XXXX
实体？fn=XXXX
XXXX is a search pattern representing the "FN" property of an entity (such as a contact, registrant, or registrar) name as specified in Section 5.1 of [RFC7483]. The following URL would be used to find information for entity names matching the "Bobby Joe*" pattern:
XXXX是一种搜索模式，表示[RFC7483]第5.1节规定的实体（如联系人、注册人或注册人）名称的“FN”属性。以下URL将用于查找与“Bobby Joe*”模式匹配的实体名称的信息：
https://example.com/rdap/entities?fn=Bobby%20Joe*
https://example.com/rdap/entities?fn=Bobby%20Joe*
Searches for entity information by handle are specified using this form:
使用以下表单指定按句柄搜索实体信息：
entities?handle=XXXX
实体？句柄=XXXX
XXXX is a search pattern representing an entity (such as a contact, registrant, or registrar) identifier whose syntax is specific to the registration provider. The following URL would be used to find information for entity handles matching the "CID-40*" pattern:
XXXX是一种搜索模式，表示实体（如联系人、注册人或注册人）标识符，其语法特定于注册提供商。以下URL将用于查找与“CID-40*”模式匹配的实体句柄的信息：
https://example.com/rdap/entities?handle=CID-40*
https://example.com/rdap/entities?handle=CID-40*
URLs MUST be properly encoded according to the rules of [RFC3986]. In the example above, "Bobby Joe*" is encoded to "Bobby%20Joe*".
URL必须根据[RFC3986]的规则正确编码。在上面的示例中，“Bobby Joe*”被编码为“Bobby%20Joe*”。
Servers indicate the success or failure of query processing by returning an appropriate HTTP response code to the client. Response codes not specifically identified in this document are described in [RFC7480].
服务器通过向客户端返回适当的HTTP响应代码来指示查询处理的成功或失败。[RFC7480]中描述了本文件中未明确标识的响应代码。
Partial string searching uses the asterisk ('*', US-ASCII value 0x002A) character to match zero or more trailing characters. A character string representing multiple domain name labels MAY be concatenated to the end of the search pattern to limit the scope of the search. For example, the search pattern "exam*" will match "example.com" and "example.net". The search pattern "exam*.com" will match "example.com". If an asterisk appears in a search string, any label that contains the non-asterisk characters in sequence plus zero or more characters in sequence in place of the asterisk would match. Additional pattern matching processing is beyond the scope of this specification.
部分字符串搜索使用星号（“*”，US-ASCII值0x002A）字符匹配零个或多个尾随字符。表示多个域名标签的字符串可以连接到搜索模式的末尾，以限制搜索范围。例如，搜索模式“exam*”将匹配“example.com”和“example.net”。搜索模式“exam*.com”将匹配“example.com”。如果搜索字符串中出现星号，则任何包含非星号字符（按顺序）加上零个或多个字符（按顺序）以代替星号的标签都将匹配。额外的模式匹配处理超出了本规范的范围。
If a server receives a search request but cannot process the request because it does not support a particular style of partial match searching, it SHOULD return an HTTP 422 (Unprocessable Entity) [RFC4918] response. When returning a 422 error, the server MAY also return an error response body as specified in Section 6 of [RFC7483] if the requested media type is one that is specified in [RFC7480].
如果服务器收到搜索请求，但由于不支持特定类型的部分匹配搜索而无法处理该请求，则应返回HTTP 422（不可处理实体）[RFC4918]响应。当返回422错误时，如果请求的介质类型是[RFC7480]中指定的介质类型，则服务器还可以返回[RFC7483]第6节中指定的错误响应正文。
Partial matching is not feasible across combinations of Unicode characters because Unicode characters can be combined with each other. Servers SHOULD NOT partially match combinations of Unicode characters where a legal combination is possible. It should be noted, though, that it may not always be possible to detect cases where a character could have been combined with another character, but was not, because characters can be combined in many different ways.
部分匹配在Unicode字符组合中不可行，因为Unicode字符可以相互组合。在可能存在合法组合的情况下，服务器不应部分匹配Unicode字符的组合。但是，应该注意的是，可能并不总是能够检测到一个字符可以与另一个字符组合的情况，但事实并非如此，因为字符可以以多种不同的方式组合。
Clients should avoid submitting a partial match search of Unicode characters where a Unicode character may be legally combined with another Unicode character or characters. Partial match searches with incomplete combinations of characters where a character must be combined with another character or characters are invalid. Partial match searches with characters that may be combined with another character or characters are to be considered non-combined characters (that is, if character x may be combined with character y but character y is not submitted in the search string, then character x is a complete character and no combinations of character x are to be searched).
如果Unicode字符可能与另一个或多个Unicode字符合法组合，客户端应避免提交Unicode字符的部分匹配搜索。使用不完整的字符组合进行部分匹配搜索，其中一个字符必须与另一个或多个字符组合是无效的。使用可能与另一个或多个字符组合的字符进行的部分匹配搜索将被视为非组合字符（即，如果字符x可能与字符y组合，但未在搜索字符串中提交字符y，则字符x为完整字符，不搜索字符x的组合）.
Conceptually, any query-matching record in a server's database might be a member of a set of related records, related in some fashion as defined by the server -- for example, variants of an IDN. The entire set ought to be considered as candidates for inclusion when constructing the response. However, the construction of the final response needs to be mindful of privacy and other data-releasing policies when assembling the RDAP response set.
从概念上讲，服务器数据库中与记录匹配的任何查询都可能是一组相关记录的成员，这些记录以服务器定义的某种方式相关，例如，IDN的变体。在构建响应时，应将整个集合视为候选项。然而，在组装RDAP响应集时，构建最终响应需要考虑隐私和其他数据发布策略。
Note too that due to the nature of searching, there may be a list of query-matching records. Each one of those is subject to being a member of a set as described in the previous paragraph. What is ultimately returned in a response will be the union of all the sets that has been filtered by whatever policies are in place.
还要注意，由于搜索的性质，可能会有一个查询匹配记录列表。其中每一个都必须是上一段所述集合的成员。最终在响应中返回的将是所有已被任何策略过滤的集合的联合。
Note that this model includes arrangements for associated names, including those that are linked by policy mechanisms and names bound together for some other purposes. Note also that returning information that was not explicitly selected by an exact-match lookup, including additional names that match a relatively fuzzy search as well as lists of names that are linked together, may cause privacy issues.
请注意，此模型包括关联名称的安排，包括由策略机制链接的名称和为某些其他目的绑定在一起的名称。还请注意，返回未通过精确匹配查找明确选择的信息，包括与相对模糊的搜索匹配的其他名称以及链接在一起的名称列表，可能会导致隐私问题。
Note that there might not be a single, static information return policy that applies to all clients equally. Client identity and associated authorizations can be a relevant factor in determining how broad the response set will be for any particular query.
请注意，可能没有一个单一的静态信息返回策略可以平等地应用于所有客户端。客户身份和相关授权可以是确定响应集对于任何特定查询的宽度的相关因素。
This document describes path segment specifications for a limited number of objects commonly registered in both RIRs and DNRs. It does not attempt to describe path segments for all of the objects registered in all registries. Custom path segments can be created for objects not specified here using the process described in Section 6 of "HTTP Usage in the Registration Data Access Protocol (RDAP)" [RFC7480].
本文档描述了通常在RIRs和DNRs中注册的有限数量对象的路径段规范。它不会试图描述在所有注册表中注册的所有对象的路径段。可以使用“注册数据访问协议（RDAP）中的HTTP使用”第6节[RFC7480]中描述的过程为此处未指定的对象创建自定义路径段。
Custom path segments can be created by prefixing the segment with a unique identifier followed by an underscore character (0x5F). For example, a custom entity path segment could be created by prefixing "entity" with "custom_", producing "custom_entity". Servers MUST return an appropriate failure status code for a request with an unrecognized path segment.
自定义路径段可以通过在段前面加上唯一标识符，后跟下划线字符（0x5F）来创建。例如，自定义实体路径段可以通过在“实体”前面加上“自定义实体”来创建，生成“自定义实体”。对于路径段无法识别的请求，服务器必须返回相应的故障状态代码。
There is value in supporting the ability to submit either a U-label (Unicode form of an IDN label) or an A-label (US-ASCII form of an IDN label) as a query argument to an RDAP service. Clients capable of processing non-US-ASCII characters may prefer a U-label since this is more visually recognizable and familiar than A-label strings, but clients using programmatic interfaces might find it easier to submit and display A-labels if they are unable to input U-labels with their keyboard configuration. Both query forms are acceptable.
支持将U-label（IDN标签的Unicode形式）或a-label（IDN标签的US-ASCII形式）作为查询参数提交给RDAP服务的功能是有价值的。能够处理非美国ASCII字符的客户端可能更喜欢U型标签，因为U型标签比a型标签字符串在视觉上更容易识别和熟悉，但如果使用编程接口的客户端无法使用键盘配置输入U型标签，则提交和显示a型标签可能会更容易。两种查询形式都可以接受。
Internationalized domain and nameserver names can contain character variants and variant labels as described in [RFC4290]. Clients that support queries for internationalized domain and nameserver names MUST accept service provider responses that describe variants as specified in "JSON Responses for the Registration Data Access Protocol (RDAP)" [RFC7483].
国际化域和名称服务器名称可以包含字符变体和变体标签，如[RFC4290]中所述。支持查询国际化域和名称服务器名称的客户端必须接受服务提供商响应，这些响应描述了“注册数据访问协议（RDAP）的JSON响应”中指定的变量[RFC7483]。
Servers can expect to receive search patterns from clients that contain character strings encoded in different forms supported by HTTP. It is entirely possible to apply filters and normalization rules to search patterns prior to making character comparisons, but this type of processing is more typically needed to determine the validity of registered strings than to match patterns.
服务器可以从客户端接收搜索模式，这些模式包含以HTTP支持的不同形式编码的字符串。在进行字符比较之前，完全可以将过滤器和规范化规则应用于搜索模式，但这种类型的处理通常需要确定注册字符串的有效性，而不是匹配模式。
An RDAP client submitting a query string containing non-US-ASCII characters converts such strings into Unicode in UTF-8 encoding. It then performs any local case mapping deemed necessary. Strings are normalized using Normalization Form C (NFC) [Unicode-UAX15]; note that clients might not be able to do this reliably. UTF-8 encoded strings are then appropriately percent-encoded [RFC3986] in the query URL.
RDAP客户端提交包含非US ASCII字符的查询字符串时，会将此类字符串转换为UTF-8编码的Unicode。然后，它执行认为必要的任何局部案例映射。使用规范化形式C（NFC）[Unicode-UAX15]对字符串进行规范化；请注意，客户端可能无法可靠地执行此操作。然后，UTF-8编码字符串在查询URL中进行适当的百分比编码[RFC3986]。
After parsing any percent-encoding, an RDAP server treats each query string as Unicode in UTF-8 encoding. If a string is not valid UTF-8, the server can immediately stop processing the query and return an HTTP 400 (Bad Request) response.
解析任何百分比编码后，RDAP服务器将每个查询字符串作为UTF-8编码中的Unicode处理。如果字符串不是有效的UTF-8，服务器可以立即停止处理查询并返回HTTP 400（错误请求）响应。
When processing queries, there is a difference in handling DNS names, including those with putative U-labels, and everything else. DNS names are treated according to the DNS matching rules as described in Section 3.1 of RFC 1035 [RFC1035] for Non-Reserved LDH (NR-LDH) labels and the matching rules described in Section 5.4 of RFC 5891 [RFC5891] for U-labels. Matching of DNS names proceeds one label at a time because it is possible for a combination of U-labels and NR-LDH labels to be found in a single domain or host name. The
在处理查询时，在处理DNS名称（包括带有假定U型标签的名称）和其他所有名称时会有所不同。DNS名称根据RFC 1035[RFC1035]第3.1节中描述的DNS匹配规则（非保留LDH（NR-LDH）标签）和RFC 5891[RFC5891]第5.4节中描述的U标签匹配规则进行处理。DNS名称的匹配一次只进行一个标签的匹配，因为可以在单个域名或主机名中找到U标签和NR-LDH标签的组合。这个
determination of whether a label is a U-label or an NR-LDH label is based on whether the label contains any characters outside of the US-ASCII letters, digits, or hyphen (the so-called LDH rule).
根据标签是否包含US-ASCII字母、数字或连字符以外的任何字符（所谓的LDH规则），确定标签是U型标签还是NR-LDH标签。
For everything else, servers map fullwidth and halfwidth characters to their decomposition equivalents. Servers convert strings to the same coded character set of the target data that is to be looked up or searched, and each string is normalized using the same normalization that was used on the target data. In general, storage of strings as Unicode is RECOMMENDED. For the purposes of comparison, Normalization Form KC (NFKC) [Unicode-UAX15] with case folding is used to maximize predictability and the number of matches. Note the use of case-folded NFKC as opposed to NFC in this case.
对于其他内容，服务器将全宽和半宽字符映射到它们的分解等价物。服务器将字符串转换为要查找或搜索的目标数据的相同编码字符集，每个字符串使用与目标数据相同的规范化进行规范化。通常，建议将字符串存储为Unicode。为了进行比较，使用带有大小写折叠的规范化表单KC（NFKC）[Unicode-UAX15]来最大化可预测性和匹配数。请注意，在这种情况下，使用折叠的NFKC而不是NFC。
Security services for the operations specified in this document are described in "Security Services for the Registration Data Access Protocol (RDAP)" [RFC7481].
“注册数据访问协议（RDAP）的安全服务”[RFC7481]中描述了本文档中指定操作的安全服务。
Search functionality typically requires more server resources (such as memory, CPU cycles, and network bandwidth) when compared to basic lookup functionality. This increases the risk of server resource exhaustion and subsequent denial of service due to abuse. This risk can be mitigated by developing and implementing controls to restrict search functionality to identified and authorized clients. If those clients behave badly, their search privileges can be suspended or revoked. Rate limiting as described in Section 5.5 of "HTTP Usage in the Registration Data Access Protocol (RDAP)" [RFC7480] can also be used to control the rate of received search requests. Server operators can also reduce their risk by restricting the amount of information returned in response to a search request.
与基本查找功能相比，搜索功能通常需要更多的服务器资源（如内存、CPU周期和网络带宽）。这增加了服务器资源耗尽的风险，以及随后由于滥用而导致拒绝服务的风险。通过开发和实施控制措施，将搜索功能限制到已识别和授权的客户，可以缓解此风险。如果这些客户表现不好，他们的搜索权限可能会被暂停或撤销。“注册数据访问协议（RDAP）中的HTTP使用”第5.5节[RFC7480]中所述的速率限制也可用于控制接收到的搜索请求的速率。服务器操作员还可以通过限制响应搜索请求返回的信息量来降低风险。
Search functionality also increases the privacy risk of disclosing object relationships that might not otherwise be obvious. For example, a search that returns IDN variants [RFC6927] that do not explicitly match a client-provided search pattern can disclose information about registered domain names that might not be otherwise available. Implementers need to consider the policy and privacy implications of returning information that was not explicitly requested.
搜索功能还增加了泄露对象关系的隐私风险，否则这些关系可能并不明显。例如，如果搜索返回的IDN变体[RFC6927]与客户端提供的搜索模式不显式匹配，则可能会披露有关注册域名的信息，而这些信息可能不可用。实现者需要考虑返回未明确请求的信息的策略和隐私影响。
Note that there might not be a single, static information return policy that applies to all clients equally. Client identity and associated authorizations can be a relevant factor in determining how broad the response set will be for any particular query.
请注意，可能没有一个单一的静态信息返回策略可以平等地应用于所有客户端。客户身份和相关授权可以是确定响应集对于任何特定查询的宽度的相关因素。
[RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985, <http://www.rfc-editor.org/info/rfc952>.
[RFC0952]Harrenstien，K.，Stahl，M.和E.Feinler，“国防部互联网主机表规范”，RFC 952，1985年10月<http://www.rfc-editor.org/info/rfc952>.
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987, <http://www.rfc-editor.org/info/rfc1035>.
[RFC1035]Mockapetris，P.，“域名-实现和规范”，STD 13，RFC 10351987年11月<http://www.rfc-editor.org/info/rfc1035>.
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989, <http://www.rfc-editor.org/info/rfc1123>.
[RFC1123]Braden，R.，Ed.“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月<http://www.rfc-editor.org/info/rfc1123>.
[RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", RFC 1166, July 1990, <http://www.rfc-editor.org/info/rfc1166>.
[RFC1166]Kirkpatrick，S.，Stahl，M.和M.Recker，“互联网号码”，RFC1166，1990年7月<http://www.rfc-editor.org/info/rfc1166>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, <http://www.rfc-editor.org/info/rfc3986>.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月<http://www.rfc-editor.org/info/rfc3986>.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月<http://www.rfc-editor.org/info/rfc4291>.
[RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006, <http://www.rfc-editor.org/info/rfc4632>.
[RFC4632]Fuller，V.和T.Li，“无类域间路由（CIDR）：互联网地址分配和聚合计划”，BCP 122，RFC 4632，2006年8月<http://www.rfc-editor.org/info/rfc4632>.
[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007, <http://www.rfc-editor.org/info/rfc4918>.
[RFC4918]Dusseault，L.，Ed.“Web分布式创作和版本控制（WebDAV）的HTTP扩展”，RFC4918，2007年6月<http://www.rfc-editor.org/info/rfc4918>.
[RFC5396] Huston, G. and G. Michaelson, "Textual Representation of Autonomous System (AS) Numbers", RFC 5396, December 2008, <http://www.rfc-editor.org/info/rfc5396>.
[RFC5396]Huston，G.和G.Michaelson，“自治系统（AS）编号的文本表示”，RFC 53962008年12月<http://www.rfc-editor.org/info/rfc5396>.
[RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, August 2009, <http://www.rfc-editor.org/info/rfc5730>.
[RFC5730]Hollenbeck，S.，“可扩展资源调配协议（EPP）”，STD 69，RFC 5730，2009年8月<http://www.rfc-editor.org/info/rfc5730>.
[RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", STD 69, RFC 5733, August 2009, <http://www.rfc-editor.org/info/rfc5733>.
[RFC5733]Hollenbeck，S.，“可扩展资源调配协议（EPP）联系人映射”，STD 69，RFC 57332009年8月<http://www.rfc-editor.org/info/rfc5733>.
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>.
[RFC5890]Klensin，J.“应用程序的国际化域名（IDNA）：定义和文档框架”，RFC 58902010年8月<http://www.rfc-editor.org/info/rfc5890>.
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010, <http://www.rfc-editor.org/info/rfc5891>.
[RFC5891]Klensin，J.，“应用程序中的国际化域名（IDNA）：协议”，RFC 58912010年8月<http://www.rfc-editor.org/info/rfc5891>.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010, <http://www.rfc-editor.org/info/rfc5952>.
[RFC5952]Kawamura，S.和M.Kawashima，“IPv6地址文本表示的建议”，RFC 59522010年8月<http://www.rfc-editor.org/info/rfc5952>.
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7230]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：消息语法和路由”，RFC 7230，2014年6月<http://www.rfc-editor.org/info/rfc7230>.
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014, <http://www.rfc-editor.org/info/rfc7231>.
[RFC7231]Fielding，R.，Ed.和J.Reschke，Ed.，“超文本传输协议（HTTP/1.1）：语义和内容”，RFC 72312014年6月<http://www.rfc-editor.org/info/rfc7231>.
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the Registration Data Access Protocol (RDAP)", RFC 7480, March 2015, <http://www.rfc-editor.org/info/rfC7480>.
[RFC7480]Newton，A.，Ellacott，B.，和N.Kong，“注册数据访问协议（RDAP）中的HTTP使用”，RFC 7480，2015年3月<http://www.rfc-editor.org/info/rfC7480>.
[RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the Registration Data Access Protocol (RDAP)", RFC 7481, March 2015, <http://www.rfc-editor.org/info/rfc7481>.
[RFC7481]Hollenbeck，S.和N.Kong，“注册数据访问协议（RDAP）的安全服务”，RFC 74812015年3月<http://www.rfc-editor.org/info/rfc7481>.
[RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the Registration Data Access Protocol (RDAP)", RFC 7483, March 2015, <http://www.rfc-editor.org/info/rfc7483>.
[RFC7483]Newton，A.和S.Hollenbeck，“注册数据访问协议（RDAP）的JSON响应”，RFC 7483，2015年3月<http://www.rfc-editor.org/info/rfc7483>.
[RFC7484] Blanchet, M., "Finding the Authoritative Registration Data (RDAP) Service", RFC 7484, March 2015, <http://www.rfc-editor.org/info/rfc7484>.
[RFC7484]Blanchet，M.“查找权威注册数据（RDAP）服务”，RFC 7484，2015年3月<http://www.rfc-editor.org/info/rfc7484>.
[Unicode-UAX15] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", September 2013, <http://www.unicode.org/reports/tr15/>.
[Unicode-UAX15]Unicode联盟，“Unicode标准附录#15：Unicode规范化表单”，2013年9月<http://www.unicode.org/reports/tr15/>.
[REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", Ph.D. Dissertation, University of California, Irvine, 2000, <http://www.ics.uci.edu/~fielding/pubs/dissertation/ fielding_dissertation.pdf>.
[REST]Fielding，R.，“架构风格和基于网络的软件架构的设计”，博士。学位论文，加利福尼亚大学，尔湾，2000，<http://www.ics.uci.edu/~fielding/pubs/demission/fielding\u demission.pdf>。
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, September 2004, <http://www.rfc-editor.org/info/rfc3912>.
[RFC3912]Daigle，L.，“WHOIS协议规范”，RFC 3912，2004年9月<http://www.rfc-editor.org/info/rfc3912>.
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005, <http://www.rfc-editor.org/info/rfc4007>.
[RFC4007]Deering，S.，Haberman，B.，Jinmei，T.，Nordmark，E.，和B.Zill，“IPv6作用域地址体系结构”，RFC 4007，2005年3月<http://www.rfc-editor.org/info/rfc4007>.
[RFC4290] Klensin, J., "Suggested Practices for Registration of Internationalized Domain Names (IDN)", RFC 4290, December 2005, <http://www.rfc-editor.org/info/rfc4290>.
[RFC4290]Klensin，J.，“国际域名（IDN）注册的建议做法”，RFC 42902005年12月<http://www.rfc-editor.org/info/rfc4290>.
[RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers", RFC 6874, February 2013, <http://www.rfc-editor.org/info/rfc6874>.
[RFC6874]Carpenter，B.，Cheshire，S.和R.Hinden，“以地址文本和统一资源标识符表示IPv6区域标识符”，RFC 68742013年2月<http://www.rfc-editor.org/info/rfc6874>.
[RFC6927] Levine, J. and P. Hoffman, "Variants in Second-Level Names Registered in Top-Level Domains", RFC 6927, May 2013, <http://www.rfc-editor.org/info/rfc6927>.
[RFC6927]Levine，J.和P.Hoffman，“顶级域中注册的二级名称变体”，RFC 6927，2013年5月<http://www.rfc-editor.org/info/rfc6927>.
Acknowledgements
致谢
This document is derived from original work on RIR query formats developed by Byron J. Ellacott of APNIC, Arturo L. Servin of LACNIC, Kaveh Ranjbar of the RIPE NCC, and Andrew L. Newton of ARIN. Additionally, this document incorporates DNR query formats originally described by Francisco Arias and Steve Sheng of ICANN and Scott Hollenbeck of Verisign Labs.
本文档来源于APNIC的Byron J.Ellacott、LACNIC的Arturo L.Servin、成熟NCC的Kaveh Ranjbar和ARIN的Andrew L.Newton开发的RIR查询格式的原始工作。此外，本文档还包含最初由ICANN的Francisco Arias和Steve Sheng以及Verisign实验室的Scott Hollenbeck描述的DNR查询格式。
The authors would like to acknowledge the following individuals for their contributions to this document: Francisco Arias, Marc Blanchet, Ernie Dainow, Jean-Philippe Dionne, Byron J. Ellacott, Behnam Esfahbod, John Klensin, John Levine, Edward Lewis, Mark Nottingham, Kaveh Ranjbar, Arturo L. Servin, Steve Sheng, and Andrew Sullivan.
作者要感谢以下个人对本文件的贡献：弗朗西斯科·阿里亚斯、马克·布兰切特、厄尼·达诺、让·菲利普·迪翁、拜伦·J·埃拉科特、贝南·伊斯法博德、约翰·克莱辛、约翰·莱文、爱德华·刘易斯、马克·诺丁汉、卡维·兰杰巴尔、阿图罗·L·塞文、史蒂夫·盛和安德鲁·沙利文。
Authors' Addresses
作者地址
Andrew Lee Newton American Registry for Internet Numbers 3635 Concorde Parkway Chantilly, VA 20151 United States
Andrew Lee Newton美国互联网注册处，美国弗吉尼亚州尚蒂利协和公园路3635号，邮编：20151
EMail: andy@arin.net
URI: http://www.arin.net
EMail: andy@arin.net
URI: http://www.arin.net
Scott Hollenbeck Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States
Scott Hollenbeck Verisign实验室12061美国弗吉尼亚州布鲁蒙特路莱斯顿20190
EMail: shollenbeck@verisign.com
URI: http://www.verisignlabs.com/
EMail: shollenbeck@verisign.com
URI: http://www.verisignlabs.com/