Internet Engineering Task Force (IETF) A. Newton
Request for Comments: 7480 ARIN
Category: Standards Track B. Ellacott
ISSN: 2070-1721 APNIC
N. Kong
CNNIC
March 2015
Internet Engineering Task Force (IETF) A. Newton
Request for Comments: 7480 ARIN
Category: Standards Track B. Ellacott
ISSN: 2070-1721 APNIC
N. Kong
CNNIC
March 2015
HTTP Usage in the Registration Data Access Protocol (RDAP)
注册数据访问协议（RDAP）中的HTTP使用
Abstract
摘要
This document is one of a collection that together describes the Registration Data Access Protocol (RDAP). It describes how RDAP is transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor protocol to the very old WHOIS protocol. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application.
本文档是描述注册数据访问协议（RDAP）的集合之一。它描述了如何使用超文本传输协议（HTTP）传输RDAP。RDAP是非常古老的WHOIS协议的继承协议。本文档的目的是澄清此应用程序使用标准HTTP机制的情况。
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/rfc7480.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7480.
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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Design Intents . . . . . . . . . . . . . . . . . . . . . . . 5
4. Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. HTTP Methods . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Accept Header . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Query Parameters . . . . . . . . . . . . . . . . . . . . 6
5. Types of HTTP Response . . . . . . . . . . . . . . . . . . . 6
5.1. Positive Answers . . . . . . . . . . . . . . . . . . . . 6
5.2. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Negative Answers . . . . . . . . . . . . . . . . . . . . 7
5.4. Malformed Queries . . . . . . . . . . . . . . . . . . . . 7
5.5. Rate Limits . . . . . . . . . . . . . . . . . . . . . . . 7
5.6. Cross-Origin Resource Sharing (CORS) . . . . . . . . . . 8
6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 9
9. Internationalization Considerations . . . . . . . . . . . . . 10
9.1. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 10
9.2. Language Identifiers in Queries and Responses . . . . . . 10
9.3. Language Identifiers in HTTP Headers . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Protocol Example . . . . . . . . . . . . . . . . . . 13
Appendix B. Cache Busting . . . . . . . . . . . . . . . . . . . 13
Appendix C. Bootstrapping and Redirection . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Design Intents . . . . . . . . . . . . . . . . . . . . . . . 5
4. Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1. HTTP Methods . . . . . . . . . . . . . . . . . . . . . . 5
4.2. Accept Header . . . . . . . . . . . . . . . . . . . . . . 5
4.3. Query Parameters . . . . . . . . . . . . . . . . . . . . 6
5. Types of HTTP Response . . . . . . . . . . . . . . . . . . . 6
5.1. Positive Answers . . . . . . . . . . . . . . . . . . . . 6
5.2. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 6
5.3. Negative Answers . . . . . . . . . . . . . . . . . . . . 7
5.4. Malformed Queries . . . . . . . . . . . . . . . . . . . . 7
5.5. Rate Limits . . . . . . . . . . . . . . . . . . . . . . . 7
5.6. Cross-Origin Resource Sharing (CORS) . . . . . . . . . . 8
6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 9
9. Internationalization Considerations . . . . . . . . . . . . . 10
9.1. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 10
9.2. Language Identifiers in Queries and Responses . . . . . . 10
9.3. Language Identifiers in HTTP Headers . . . . . . . . . . 10
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
10.1. Normative References . . . . . . . . . . . . . . . . . . 11
10.2. Informative References . . . . . . . . . . . . . . . . . 12
Appendix A. Protocol Example . . . . . . . . . . . . . . . . . . 13
Appendix B. Cache Busting . . . . . . . . . . . . . . . . . . . 13
Appendix C. Bootstrapping and Redirection . . . . . . . . . . . 14
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16
This document describes the usage of the Hypertext Transfer Protocol (HTTP) [RFC7230] for the Registration Data Access Protocol (RDAP). The goal of this document is to tie together usage patterns of HTTP into a common profile applicable to the various types of directory services serving registration data using practices informed by the Representational State Transfer (REST) [REST] architectural style. By giving the various directory services common behavior, a single client is better able to retrieve data from directory services adhering to this behavior.
本文档描述了注册数据访问协议（RDAP）的超文本传输协议（HTTP）[RFC7230]的用法。本文档的目标是使用Representational State Transfer（REST）[REST]体系结构风格提供的实践，将HTTP的使用模式结合到一个通用概要文件中，该概要文件适用于为注册数据提供服务的各种类型的目录服务。通过为各种目录服务提供公共行为，单个客户机能够更好地从遵循此行为的目录服务检索数据。
Registration data expected to be presented by this service is Internet resource registration data -- registration of domain names and Internet number resources. This data is typically provided by WHOIS [RFC3912] services, but the WHOIS protocol is insufficient to modern registration data service requirements. A replacement protocol is expected to retain the simple transactional nature of WHOIS, while providing a specification for queries and responses, redirection to authoritative sources, support for Internationalized Domain Names (IDNs) [RFC5890], and support for localized registration data such as addresses and organization or person names.
该服务预期提供的注册数据是互联网资源注册数据——域名和互联网号码资源的注册。该数据通常由WHOIS[RFC3912]服务提供，但WHOIS协议不足以满足现代注册数据服务的要求。替代协议有望保留WHOIS的简单事务性质，同时提供查询和响应规范、重定向到权威来源、支持国际化域名（IDN）[RFC5890]，以及对本地化注册数据（如地址和组织或人名）的支持。
In designing these common usage patterns, this document introduces considerations for a simple use of HTTP. Where complexity may reside, it is the goal of this document to place it upon the server and to keep the client as simple as possible. A client implementation should be possible using common operating system scripting tools (e.g., bash and wget).
在设计这些常见的使用模式时，本文介绍了简单使用HTTP的注意事项。在可能存在复杂性的地方，本文档的目标是将其放在服务器上，并使客户机尽可能简单。客户端实现应该可以使用通用的操作系统脚本工具（例如bash和wget）。
This is the basic usage pattern for this protocol:
这是此协议的基本使用模式：
1. A client determines an appropriate server to query along with the appropriate base Uniform Resource Locator (URL) to use in such queries. [RFC7484] describes one method to determine the server and the base URL. See Appendix C for more information.
1. 客户机确定要查询的适当服务器以及要在此类查询中使用的适当基本统一资源定位器（URL）。[RFC7484]描述了一种确定服务器和基本URL的方法。详见附录C。
2. A client issues an HTTP (or HTTPS) query using GET [RFC7231]. As an example, a query URL for the network registration 192.0.2.0 might be
2. 客户端使用GET[RFC7231]发出HTTP（或HTTPS）查询。例如，网络注册192.0.2.0的查询URL可能是
http://example.com/rdap/ip/192.0.2.0
http://example.com/rdap/ip/192.0.2.0
[RFC7482] details the various queries used in RDAP.
[RFC7482]详细介绍了RDAP中使用的各种查询。
3. If the receiving server has the information for the query, it examines the Accept header field of the query and returns a 200 response with a response entity appropriate for the requested format. [RFC7483] details a response in JavaScript Object Notation (JSON).
3. 如果接收服务器具有查询的信息，它将检查查询的Accept header字段，并返回一个200响应，其中包含适合请求格式的响应实体。[RFC7483]以JavaScript对象表示法（JSON）详细说明响应。
4. If the receiving server does not have the information for the query but does have knowledge of where the information can be found, it will return a redirection response (3xx) with the Location header field containing an HTTP(S) URL pointing to the information or another server known to have knowledge of the location of the information. The client is expected to requery using that HTTP URL.
4. 如果接收服务器没有查询信息，但知道可以在何处找到信息，它将返回重定向响应（3xx），其中位置标头字段包含指向信息的HTTP（S）URL或已知知道信息位置的其他服务器。客户端需要使用该HTTP URL重新查询。
5. If the receiving server does not have the information being requested and does not have knowledge of where the information can be found, it returns a 404 response.
5. 如果接收服务器没有被请求的信息，并且不知道在哪里可以找到信息，它将返回404响应。
6. If the receiving server will not answer a request for policy reasons, it will return an error response (4xx) indicating the reason for giving no answer.
6. 如果接收服务器出于策略原因不响应请求，它将返回一个错误响应（4xx），指明不响应的原因。
It is not the intent of this document to redefine the meaning and semantics of HTTP. The purpose of this document is to clarify the use of standard HTTP mechanisms for this application.
本文档无意重新定义HTTP的含义和语义。本文档的目的是澄清此应用程序使用标准HTTP机制的情况。
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]中所述进行解释。
As is noted in "Security and Stability Advisory Committee (SSAC) Report on WHOIS Terminology and Structure" [SAC-051], the term "WHOIS" is overloaded, often referring to a protocol, a service, and data. In accordance with [SAC-051], this document describes the base behavior for an RDAP. [SAC-051] describes a protocol profile of RDAP for Domain Name Registries (DNRs), the Domain Name Registration Data Access Protocol (DNRD-AP).
正如“安全与稳定咨询委员会（SSAC）关于WHOIS术语和结构的报告”[SAC-051]中所指出的，“WHOIS”一词过载，通常指协议、服务和数据。根据[SAC-051]，本文件描述了RDAP的基本行为。[SAC-051]描述了域名注册（DNR）的RDAP协议配置文件，即域名注册数据访问协议（DNRD-AP）。
In this document, an RDAP client is an HTTP user agent performing an RDAP query, and an RDAP server is an HTTP server providing an RDAP response. RDAP query and response formats are described in [RFC7482] and [RFC7483], while this document describes how RDAP clients and servers use HTTP to exchange queries and responses. [RFC7481] describes security considerations for RDAP.
在本文档中，RDAP客户端是执行RDAP查询的HTTP用户代理，RDAP服务器是提供RDAP响应的HTTP服务器。[RFC7482]和[RFC7483]中描述了RDAP查询和响应格式，而本文档描述了RDAP客户端和服务器如何使用HTTP交换查询和响应。[RFC7481]介绍了RDAP的安全注意事项。
There are a few design criteria this document attempts to meet.
本文件试图满足一些设计标准。
First, each query is meant to require only one path of execution to obtain an answer. A response may contain an answer, no answer, or a redirect, and clients are not expected to fork multiple paths of execution to make a query.
首先，每个查询只需要一条执行路径即可获得答案。响应可能包含应答、无应答或重定向，并且客户端不需要分叉多条执行路径来进行查询。
Second, the semantics of the request/response allow for future and/or non-standard response formats. In this document, only a JSON [RFC7159] response media type is noted, with the response contents to be described separately (see [RFC7483]). This document only describes how RDAP is transported using HTTP with this format.
其次，请求/响应的语义允许将来和/或非标准响应格式。在本文档中，只记录了JSON[RFC7159]响应媒体类型，响应内容将单独描述（请参见[RFC7483]）。本文档仅描述如何使用此格式的HTTP传输RDAP。
Third, this protocol is intended to be able to make use of the range of mechanisms available for use with HTTP. HTTP offers a number of mechanisms not described further in this document. Operators are able to make use of these mechanisms according to their local policy, including cache control, authorization, compression, and redirection. HTTP also benefits from widespread investment in scalability, reliability, and performance, as well as widespread programmer understanding of client behaviors for web services styled after REST [REST], reducing the cost to deploy Registration Data Directory Services and clients. This protocol is forward compatible with HTTP 2.0.
第三，该协议旨在能够利用HTTP可用的一系列机制。HTTP提供了许多本文档中未进一步描述的机制。操作员可以根据其本地策略使用这些机制，包括缓存控制、授权、压缩和重定向。HTTP还得益于在可伸缩性、可靠性和性能方面的广泛投资，以及程序员对REST[REST]之后设计的web服务的客户端行为的广泛理解，从而降低了部署注册数据目录服务和客户端的成本。此协议与HTTP 2.0前向兼容。
Clients use the GET method to retrieve a response body and use the HEAD method to determine existence of data on the server. Clients SHOULD use either the HTTP GET or HEAD methods (see [RFC7231]). Servers are under no obligation to support other HTTP methods; therefore, clients using other methods will likely not interoperate properly.
客户端使用GET方法检索响应主体，并使用HEAD方法确定服务器上是否存在数据。客户端应使用HTTP GET或HEAD方法（请参见[RFC7231]）。服务器没有义务支持其他HTTP方法；因此，使用其他方法的客户端很可能无法正常互操作。
Clients and servers MUST support HTTPS to support security services.
客户端和服务器必须支持HTTPS以支持安全服务。
To indicate to servers that an RDAP response is desired, clients include an Accept header field with an RDAP-specific JSON media type, the generic JSON media type, or both. Servers receiving an RDAP request return an entity with a Content-Type header containing the RDAP-specific JSON media type.
为了向服务器表明需要RDAP响应，客户机包括一个带有RDAP特定JSON媒体类型、通用JSON媒体类型或两者的Accept标头字段。接收RDAP请求的服务器返回一个实体，该实体的内容类型头包含RDAP特定的JSON媒体类型。
This specification does not define the responses a server returns to a request with any other media types in the Accept header field, or with no Accept header field. One possibility would be to return a response in a media type suitable for rendering in a web browser.
本规范不定义服务器在“接受标头”字段或“不接受标头”字段中对具有任何其他媒体类型的请求返回的响应。一种可能是以适合在web浏览器中呈现的媒体类型返回响应。
Servers MUST ignore unknown query parameters. Use of unknown query parameters for cache busting is described in Appendix B.
服务器必须忽略未知的查询参数。附录B中描述了使用未知查询参数进行缓存破坏。
This section describes the various types of responses a server may send to a client. While no standard HTTP response code is forbidden in usage, this section defines the minimal set of response codes in common use by servers that a client will need to understand. While some clients may be constructed with simple tooling that does not account for all of these response codes, a more robust client accounting for these codes will likely provide a better user experience. It is expected that usage of response codes and types for this application not defined here will be described in subsequent documents.
本节介绍服务器可能发送给客户端的各种类型的响应。虽然没有禁止使用标准HTTP响应代码，但本节定义了客户端需要了解的服务器常用的最小响应代码集。虽然一些客户机可能使用简单的工具构建，而这些工具并不考虑所有这些响应代码，但考虑这些代码的更健壮的客户机可能会提供更好的用户体验。预期在后续文档中会描述此应用程序中未定义的响应代码和类型的用法。
If a server has the information requested by the client and wishes to respond to the client with the information according to its policies, it returns that answer in the body of a 200 (OK) response (see [RFC7231]).
如果服务器拥有客户机请求的信息，并且希望根据其策略使用该信息响应客户机，那么它将在200（确定）响应的主体中返回该答案（请参见[RFC7231]）。
If a server wishes to inform a client that the answer to a given query can be found elsewhere, it returns either a 301 (Moved Permanently) response code to indicate a permanent move or a 302 (Found), 303 (See Other), or 307 (Temporary Redirect) response code to indicate a non-permanent redirection, and it includes an HTTP(S) URL in the Location header field (see [RFC7231]). The client is expected to issue a subsequent request to satisfy the original query using the given URL without any processing of the URL. In other words, the server is to hand back a complete URL, and the client should not have to transform the URL to follow it. Servers are under no obligation to return a URL conformant to [RFC7482].
如果服务器希望通知客户机可以在别处找到给定查询的答案，它将返回301（永久移动）响应代码以指示永久移动，或者返回302（找到）、303（参见其他）或307（临时重定向）响应代码以指示非永久重定向，并且它包括HTTP（S）位置标头字段中的URL（请参见[RFC7231]）。客户机将使用给定的URL发出后续请求以满足原始查询，而无需对URL进行任何处理。换句话说，服务器将返回一个完整的URL，客户端不必转换URL来遵循它。服务器没有义务返回符合[RFC7482]的URL。
For this application, such an example of a permanent move might be a Top-Level Domain (TLD) operator informing a client the information
对于此应用程序，永久移动的示例可能是顶级域（TLD）操作员通知客户机该信息
being sought can be found with another TLD operator (i.e., a query for the domain bar in foo.example is found at http://foo.example/domain/bar).
可以通过另一个TLD操作符找到正在查找的内容（即，在foo中对域栏的查询。示例位于http://foo.example/domain/bar).
For example, if the client uses
例如，如果客户端使用
http://serv1.example.com/weirds/domain/example.com
http://serv1.example.com/weirds/domain/example.com
the server redirecting to
服务器正在重定向到
https://serv2.example.net/weirds2/
https://serv2.example.net/weirds2/
would set the Location: field to the value
将Location:字段设置为值
https://serv2.example.net/weirds2/domain/example.com
https://serv2.example.net/weirds2/domain/example.com
If a server wishes to respond that it has an empty result set (that is, no data appropriately satisfying the query), it returns a 404 (Not Found) response code. Optionally, it MAY include additional information regarding the negative answer in the HTTP entity body.
如果服务器希望响应它有一个空的结果集（即没有适当满足查询的数据），它将返回404（未找到）响应代码。可选地，它可以包括关于HTTP实体主体中的否定答案的附加信息。
If a server wishes to inform the client that information about the query is available, but cannot include the information in the response to the client for policy reasons, the server MUST respond with an appropriate response code out of HTTP's 4xx range. A client MAY retry the query if that is appropriate for the respective response code.
如果服务器希望通知客户端有关查询的信息可用，但由于策略原因无法在对客户端的响应中包含该信息，则服务器必须使用HTTP 4xx范围之外的适当响应代码进行响应。如果适用于相应的响应代码，客户端可以重试查询。
If a server receives a query that it cannot interpret as an RDAP query, it returns a 400 (Bad Request) response code. Optionally, it MAY include additional information regarding this negative answer in the HTTP entity body.
如果服务器接收到无法解释为RDAP查询的查询，它将返回400（错误请求）响应代码。可选地，它可以在HTTP实体体中包含有关此否定答案的附加信息。
Some servers apply rate limits to deter address scraping and other abuses. When a server declines to answer a query due to rate limits, it returns a 429 (Too Many Requests) response code as described in [RFC6585]. A client that receives a 429 response SHOULD decrease its query rate and honor the Retry-After header field if one is present. Servers may place stricter limits upon clients that do not honor the Retry-After header. Optionally, the server MAY include additional information regarding the rate limiting in the HTTP entity body.
一些服务器应用速率限制来阻止地址刮取和其他滥用。当服务器由于速率限制而拒绝回答查询时，它将返回429（太多请求）响应代码，如[RFC6585]中所述。接收到429响应的客户端应降低其查询速率，并在存在重试后报头字段的情况下遵守该字段。服务器可能会对不遵守“重试后”标头的客户端设置更严格的限制。可选地，服务器可以包括关于HTTP实体主体中的速率限制的附加信息。
Note that this is not a defense against denial-of-service (DoS) attacks, since a malicious client could ignore the code and continue to send queries at a high rate. A server might use another response code if it did not wish to reveal to a client that rate limiting is the reason for the denial of a reply.
请注意，这不是针对拒绝服务（DoS）攻击的防御措施，因为恶意客户端可能会忽略代码并继续以高速率发送查询。如果服务器不希望向客户端透露速率限制是拒绝回复的原因，则可能会使用另一个响应代码。
When responding to queries, it is RECOMMENDED that servers use the Access-Control-Allow-Origin header field, as specified by [W3C.REC-cors-20140116]. A value of "*" is suitable when RDAP is used for public resources.
响应查询时，建议服务器使用[W3C.REC-cors-20140116]指定的Access Control Allow Origin标头字段。当RDAP用于公共资源时，值“*”是合适的。
This header (often called the CORS header) helps in-browser web applications by lifting the "same-origin" restriction (i.e., a browser may load RDAP client code from one web server but query others for RDAP data).
此标头（通常称为CORS标头）通过取消“同源”限制（即，浏览器可以从一台web服务器加载RDAP客户端代码，但可以查询其他服务器的RDAP数据）来帮助浏览器web应用程序。
By default, browsers do not send cookies when cross origin requests are allowed. Setting the Access-Control-Allow-Credentials header field to "true" will send cookies. Use of the Access-Control-Allow-Credentials header field is NOT RECOMMENDED.
默认情况下，当允许跨源请求时，浏览器不发送cookie。将Access Control Allow Credentials标头字段设置为“true”将发送cookie。不建议使用访问控制允许凭据标头字段。
For extensibility purposes, this document defines an IANA registry for prefixes used in JSON [RFC7159] data serialization and URI path segments (see Section 8).
出于扩展性目的，本文档为JSON[RFC7159]数据序列化和URI路径段中使用的前缀定义了IANA注册表（请参见第8节）。
Prefixes and identifiers SHOULD only consist of the alphabetic US-ASCII characters A through Z in both uppercase and lowercase, the numerical digits 0 through 9, and the underscore character, and they SHOULD NOT begin with an underscore character, numerical digit, or the characters "xml". The following describes the production of JSON names in ABNF [RFC5234].
前缀和标识符应仅由大写和小写的字母US-ASCII字符A到Z、数字0到9以及下划线字符组成，并且它们不应以下划线字符、数字数字或字符“xml”开头。下面描述了在ABNF[RFC5234]中生成JSON名称的过程。
name = ALPHA *( ALPHA / DIGIT / "_" )
name = ALPHA *( ALPHA / DIGIT / "_" )
Figure 1: ABNF for JSON Names
图1:JSON名称的ABNF
This restriction is a union of the Ruby programming language identifier syntax and the XML element name syntax and has two purposes. First, client implementers using modern programming languages such as Ruby or Java can use libraries that automatically promote JSON names to first-order object attributes or members. Second, a clean mapping between JSON and XML is easy to accomplish using these rules.
这个限制是Ruby编程语言标识符语法和XML元素名语法的结合，有两个目的。首先，使用Ruby或Java等现代编程语言的客户机实现者可以使用自动将JSON名称提升为一阶对象属性或成员的库。其次，使用这些规则很容易实现JSON和XML之间的干净映射。
This document does not pose strong security requirements to the RDAP protocol. However, it does not restrict against the use of security mechanisms offered by the HTTP protocol. It does require that RDAP clients and servers MUST support HTTPS.
本文件并未对RDAP协议提出强烈的安全要求。但是，它并不限制使用HTTP协议提供的安全机制。它确实要求RDAP客户端和服务器必须支持HTTPS。
This document makes recommendations for server implementations against DoS (Section 5.5) and interoperability with existing security mechanisms in HTTP clients (Section 5.6).
本文档对针对DoS的服务器实现（第5.5节）以及与HTTP客户端中现有安全机制的互操作性（第5.6节）提出了建议。
Additional security considerations to the RDAP protocol are covered in [RFC7481].
[RFC7481]中介绍了RDAP协议的其他安全注意事项。
IANA has created a new category in the protocol registries labeled "Registration Data Access Protocol (RDAP)", and within that category, has established a URL-referenceable, stand-alone registry labeled "RDAP Extensions". The purpose of this registry is to ensure uniqueness of extension identifiers. The extension identifier is used as a prefix in JSON names and as a prefix of path segments in RDAP URLs.
IANA在协议注册表中创建了一个新类别，标记为“注册数据访问协议（RDAP）”，并在该类别中建立了一个URL可引用的独立注册表，标记为“RDAP扩展”。此注册表的目的是确保扩展标识符的唯一性。扩展标识符在JSON名称中用作前缀，在RDAPURL中用作路径段的前缀。
The production rule for these identifiers is specified in Section 6.
第6节规定了这些标识符的产生式规则。
In accordance with [RFC5226], the IANA policy for assigning new values, shall be Specification Required: values and their meanings must be documented in an RFC or in some other permanent and readily available reference, in sufficient detail that interoperability between independent implementations is possible.
根据[RFC5226]，IANA分配新值的政策应符合规范要求：值及其含义必须记录在RFC或其他永久性且随时可用的参考文件中，足够详细，以确保独立实现之间的互操作性。
The following is a template for an RDAP extension registration:
以下是RDAP扩展注册的模板：
Extension identifier: the identifier of the extension
扩展标识符：扩展的标识符
Registry operator: the name of the registry operator
注册表运算符：注册表运算符的名称
Published specification: RFC number, bibliographical reference, or URL to a permanent and readily available specification
已发布规范：RFC编号、参考书目或永久性且随时可用规范的URL
Person & email address to contact for further information: The names and email addresses of individuals to contact regarding this registry entry
联系人和电子邮件地址以获取更多信息：有关此注册表项的联系人姓名和电子邮件地址
Intended usage: brief reasons for this registry entry (as defined by [RFC5226]).
预期用途：此注册表项的简要原因（如[RFC5226]所定义）。
The following is an example of a registration in the RDAP extension registry:
以下是RDAP扩展注册表中的注册示例：
Extension identifier: lunarNic
扩展标识符：lunarNic
Registry operator: The Registry of the Moon, LLC
注册运营商：月球注册有限责任公司
Published specification: http://www.example/moon_apis/rdap
Published specification: http://www.example/moon_apis/rdap
Person & email address to contact for further information:
Professor Bernardo de la Paz <berny@moon.example>
Person & email address to contact for further information:
Professor Bernardo de la Paz <berny@moon.example>
Intended usage: COMMON
预期用途：普通
Clients can use Internationalized Resource Identifiers (IRIs) [RFC3987] for internal use as they see fit but MUST transform them to URIs [RFC3986] for interaction with RDAP servers. RDAP servers MUST use URIs in all responses, and again clients can transform these URIs to IRIs for internal use as they see fit.
客户机可以使用国际化资源标识符（IRI）[RFC3987]进行内部使用，但必须将其转换为URI[RFC3986]，以便与RDAP服务器交互。RDAP服务器必须在所有响应中使用URI，客户端也可以根据需要将这些URI转换为IRI供内部使用。
Under most scenarios, clients requesting data will not signal that the data be returned in a particular language or script. On the other hand, when servers return data and have knowledge that the data is in a language or script, the data SHOULD be annotated with language identifiers whenever they are available, thus allowing clients to process and display the data accordingly.
在大多数情况下，请求数据的客户端不会发出以特定语言或脚本返回数据的信号。另一方面，当服务器返回数据并知道数据是用语言或脚本编写的时，应在数据可用时使用语言标识符对其进行注释，从而允许客户端相应地处理和显示数据。
[RFC7483] provides such a mechanism.
[RFC7483]提供了这样一种机制。
Given the description of the use of language identifiers in Section 9.2, unless otherwise specified, servers SHOULD ignore the HTTP [RFC7231] Accept-Language header field when formulating HTTP entity responses, so that clients do not conflate the Accept-Language header with the 'lang' values in the entity body.
鉴于第9.2节中对语言标识符使用的描述，除非另有规定，否则在制定HTTP实体响应时，服务器应忽略HTTP[RFC7231]接受语言标头字段，以便客户端不会将接受语言标头与实体体中的“lang”值混为一谈。
However, servers MAY return language identifiers in the Content-Language header field so as to inform clients of the intended language of HTTP layer messages.
然而，服务器可以在内容语言报头字段中返回语言标识符，以便通知客户端HTTP层消息的预期语言。
[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>.
[RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005, <http://www.rfc-editor.org/info/rfc3987>.
[RFC3987]Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，2005年1月<http://www.rfc-editor.org/info/rfc3987>.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status Codes", RFC 6585, April 2012, <http://www.rfc-editor.org/info/rfc6585>.
[RFC6585]诺丁汉，M.和R.菲尔丁，“附加HTTP状态代码”，RFC6585，2012年4月<http://www.rfc-editor.org/info/rfc6585>.
[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>.
[RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the Registration Data Access Protocol (RDAP)", RFC 7481, February 2015, <http://www.rfc-editor.org/info/rfc7481>.
[RFC7481]Hollenbeck，S.和N.Kong，“注册数据访问协议（RDAP）的安全服务”，RFC 7481，2015年2月<http://www.rfc-editor.org/info/rfc7481>.
[RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access Protocol (RDAP) Query Format", RFC 7482, February 2015, <http://www.rfc-editor.org/info/rfc7482>.
[RFC7482]Newton，A.和S.Hollenbeck，“注册数据访问协议（RDAP）查询格式”，RFC 7482，2015年2月<http://www.rfc-editor.org/info/rfc7482>.
[RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the Registration Data Access Protocol (RDAP)", RFC 7483, February 2015, <http://www.rfc-editor.org/info/rfc7483>.
[RFC7483]Newton，A.和S.Hollenbeck，“注册数据访问协议（RDAP）的JSON响应”，RFC 7483，2015年2月<http://www.rfc-editor.org/info/rfc7483>.
[RFC7484] Blanchet, M., "Finding the Authoritative Registration Data (RDAP) Service", RFC 7484, February 2015, <http://www.rfc-editor.org/info/rfc7484>.
[RFC7484]Blanchet，M.“查找权威注册数据（RDAP）服务”，RFC 7484，2015年2月<http://www.rfc-editor.org/info/rfc7484>.
[W3C.REC-cors-20140116] Kesteren, A., "Cross-Origin Resource Sharing", W3C Recommendation, REC-cors-20140116, January 2014, <http://www.w3.org/TR/2014/REC-cors-20140116/>.
[W3C.REC-cors-20140116]Kesteren，A.，“跨来源资源共享”，W3C建议，REC-cors-201401616，2014年1月<http://www.w3.org/TR/2014/REC-cors-20140116/>.
[REST] Fielding, R. and R. Taylor, "Principled Design of the Modern Web Architecture", ACM Transactions on Internet Technology, Vol. 2, No. 2, May 2002.
[REST]Fielding，R.和R.Taylor，“现代Web架构的原则性设计”，ACM互联网技术交易，第2卷，第2期，2002年5月。
[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>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, <http://www.rfc-editor.org/info/rfc5234>.
[RFC5234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，STD 68，RFC 5234，2008年1月<http://www.rfc-editor.org/info/rfc5234>.
[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>.
[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.
[RFC7159]Bray，T.，Ed.“JavaScript对象表示法（JSON）数据交换格式”，RFC 7159，2014年3月<http://www.rfc-editor.org/info/rfc7159>.
[SAC-051] Piscitello, D., Ed., "SSAC Report on Domain Name WHOIS Terminology and Structure", A report from the ICANN Security and Stability Advisory Committee (SSAC), September 2011.
[SAC-051]Piscitello，D.，Ed.，“SSAC关于域名WHOIS术语和结构的报告”，ICANN安全与稳定咨询委员会（SSAC）的报告，2011年9月。
[lacnic-joint-whois] LACNIC, "Joint Whois", December 2005, <ftp://anonymous@ftp.registro.br/pub/gter/ gter20/02-jwhois-lacnic.pdf>.
[lacnic联合whois]lacnic，“联合whois”，2005年12月<ftp://anonymous@ftp.registro.br/pub/gter/gter20/02 jwhois lacnic.pdf>。
To demonstrate typical behavior of an RDAP client and server, the following is an example of an exchange, including a redirect. The data in the response has been elided for brevity, as the data format is not described in this document. The media type used here is described in [RFC7483].
为了演示RDAP客户端和服务器的典型行为，下面是一个交换示例，包括重定向。为简洁起见，响应中的数据已被省略，因为本文档中未描述数据格式。[RFC7483]中描述了此处使用的媒体类型。
An example of an RDAP client and server exchange:
RDAP客户端和服务器交换示例：
Client:
<TCP connect to rdap.example.com port 80>
GET /rdap/ip/203.0.113.0/24 HTTP/1.1
Host: rdap.example.com
Accept: application/rdap+json
Client:
<TCP connect to rdap.example.com port 80>
GET /rdap/ip/203.0.113.0/24 HTTP/1.1
Host: rdap.example.com
Accept: application/rdap+json
rdap.example.com:
HTTP/1.1 301 Moved Permanently
Location: http://rdap-ip.example.com/rdap/ip/203.0.113.0/24
Content-Length: 0
Content-Type: application/rdap+json
<TCP disconnect>
rdap.example.com:
HTTP/1.1 301 Moved Permanently
Location: http://rdap-ip.example.com/rdap/ip/203.0.113.0/24
Content-Length: 0
Content-Type: application/rdap+json
<TCP disconnect>
Client:
<TCP connect to rdap-ip.example.com port 80>
GET /rdap/ip/203.0.113.0/24 HTTP/1.1
Host: rdap-ip.example.com
Accept: application/rdap+json
Client:
<TCP connect to rdap-ip.example.com port 80>
GET /rdap/ip/203.0.113.0/24 HTTP/1.1
Host: rdap-ip.example.com
Accept: application/rdap+json
rdap-ip.example.com:
HTTP/1.1 200 OK
Content-Type: application/rdap+json
Content-Length: 9001
rdap-ip.example.com:
HTTP/1.1 200 OK
Content-Type: application/rdap+json
Content-Length: 9001
{ ... }
<TCP disconnect>
{ ... }
<TCP disconnect>
Some HTTP [RFC7230] cache infrastructures do not adhere to caching standards adequately and could cache responses longer than is intended by the server. To overcome these issues, clients can use an ad hoc and improbably used query parameter with a random value of their choosing. As Section 4.3 instructs servers to ignore unknown parameters, this is compatible with the RDAP definition.
一些HTTP[RFC7230]缓存基础设施没有充分遵守缓存标准，并且缓存响应的时间可能比服务器预期的时间长。为了克服这些问题，客户机可以使用一个临时的、不太可能使用的查询参数，并选择一个随机值。由于第4.3节指示服务器忽略未知参数，这与RDAP定义兼容。
An example of using an unknown query parameter to bust caches:
使用未知查询参数破坏缓存的示例如下：
http://example.com/ip/192.0.2.0?__fuhgetaboutit=xyz123
http://example.com/ip/192.0.2.0?__fuhgetaboutit=xyz123
Use of an unknown parameter to overcome misbehaving caches is not part of any specification and is offered here for informational purposes.
使用未知参数来克服行为不端的缓存不是任何规范的一部分，此处提供的参数仅供参考。
The traditional deployment model of WHOIS [RFC3912] does not provide a mechanism for determining the authoritative source for information.
WHOIS[RFC3912]的传统部署模型没有提供确定权威信息源的机制。
Some approaches have been implemented in the past, most notably the Joint WHOIS [lacnic-joint-whois] initiative. However, among other shortcomings, Joint WHOIS is implemented using proxies and server-side referrals.
过去已经实施了一些方法，最显著的是WHOIS联合倡议。然而，在其他缺点中，联合WHOIS是使用代理和服务器端引用实现的。
These issues are solved in RDAP using HTTP redirects and bootstrapping. Bootstrapping is discussed in [RFC7484]. In constrained environments, the processes outlined in [RFC7484] may not be viable, and there may be the need for servers acting as a "redirector".
这些问题在RDAP中使用HTTP重定向和引导解决。[RFC7484]中讨论了引导。在受限环境中，[RFC7484]中概述的流程可能不可行，可能需要服务器充当“重定向器”。
Redirector servers issue HTTP redirects to clients using a redirection table informed by [RFC7484]. Figure 2 diagrams a client using a redirector for bootstrapping.
重定向器服务器使用[RFC7484]通知的重定向表向客户端发出HTTP重定向。图2显示了使用重定向器进行引导的客户端。
REDIRECTOR ARIN
RDAP RDAP
. .
| |
Q: 23.1.1.1? -----------------> | |
| |
<---------- HTTP 301 --------| |
('Try ARIN RDAP') | |
| |
|
Q: 23.1.1.1? -------------------------------> |
|
<---------- HTTP 200 --------------------- |
(JSON response is returned) |
|
|
.
REDIRECTOR ARIN
RDAP RDAP
. .
| |
Q: 23.1.1.1? -----------------> | |
| |
<---------- HTTP 301 --------| |
('Try ARIN RDAP') | |
| |
|
Q: 23.1.1.1? -------------------------------> |
|
<---------- HTTP 200 --------------------- |
(JSON response is returned) |
|
|
.
Figure 2: Querying RDAP Data for 23.1.1.1
图2：查询23.1.1.1的RDAP数据
In some cases, particularly sub-delegations made between Regional Internet Registries (RIRs) known as "ERX space" and transfers of networks, multiple HTTP redirects will be issued. Figure 3 shows such a scenario.
在某些情况下，特别是在被称为“ERX空间”的区域互联网注册中心（RIR）和网络传输之间进行的分授权，将发布多个HTTP重定向。图3显示了这样一个场景。
REDIRECTOR LACNIC ARIN
RDAP RDAP RDAP
. . .
Q: 23.1.1.1? ----> | | |
| | |
<-- HTTP 301 --- | | |
('Try LACNIC') | | |
| | |
| | |
Q: 23.1.1.1? -----------------> | |
| |
<---------- HTTP 301 --------| |
('Try ARIN RDAP') | |
| |
|
Q: 23.1.1.1? -------------------------------> |
|
<---------- HTTP 200 --------------------- |
(JSON response is returned) |
|
|
.
REDIRECTOR LACNIC ARIN
RDAP RDAP RDAP
. . .
Q: 23.1.1.1? ----> | | |
| | |
<-- HTTP 301 --- | | |
('Try LACNIC') | | |
| | |
| | |
Q: 23.1.1.1? -----------------> | |
| |
<---------- HTTP 301 --------| |
('Try ARIN RDAP') | |
| |
|
Q: 23.1.1.1? -------------------------------> |
|
<---------- HTTP 200 --------------------- |
(JSON response is returned) |
|
|
.
Figure 3: Querying RDAP Data for Data That Has Been Transferred
图3：查询RDAP数据以查找已传输的数据
Acknowledgements
致谢
John Levine provided text to tighten up the Accept header field usage and the text for the section on 429 responses.
John Levine提供了文本以加强Accept标头字段的使用，以及429响应部分的文本。
Marc Blanchet provided some clarifying text regarding the use of URLs with redirects, as well as very useful feedback during Working Group Last Call (WGLC).
Marc Blanchet提供了一些关于URL重定向使用的澄清文本，以及工作组上次通话（WGLC）期间非常有用的反馈。
Normative language reviews were provided by Murray S. Kucherawy, Andrew Sullivan, Tom Harrison, Ed Lewis, and Alexander Mayrhofer.
规范性语言评论由Murray S.Kucherawy、Andrew Sullivan、Tom Harrison、Ed Lewis和Alexander Mayrhofer提供。
Jean-Phillipe Dionne provided text for the Security Considerations section.
Jean-Phillipe Dionne为安全考虑部分提供了文本。
The concept of the redirector server informatively discussed in Appendix C was documented by Carlos M. Martinez and Gerardo Rada of
附录C中非正式讨论的重定向服务器的概念由美国的Carlos M.Martinez和Gerardo Rada记录
LACNIC and Linlin Zhou of CNNIC and subsequently incorporated into this document.
中国互联网络信息中心的LACNIC和周林林，并随后纳入本文件。
This document is the work product of the IETF's WEIRDS working group, of which Olaf Kolkman and Murray Kucherawy were chairs.
本文件是IETF的WEIRDS工作组的工作成果，Olaf Kolkman和Murray Kucherawy是该工作组的主席。
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
Byron J. Ellacott Asia Pacific Network Information Centre 6 Cordelia Street South Brisbane QLD 4101 Australia
拜伦·J·埃拉科特亚太网络信息中心，地址：澳大利亚昆士兰州南布里斯班Cordelia街6号，邮编：4101
EMail: bje@apnic.net
URI: http://www.apnic.net
EMail: bje@apnic.net
URI: http://www.apnic.net
Ning Kong China Internet Network Information Center 4 South 4th Street, Zhongguancun, Haidian District Beijing 100190 China
中国北京市海淀区中关村南四街4号宁空中国互联网信息中心100190
Phone: +86 10 5881 3147
EMail: nkong@cnnic.cn
Phone: +86 10 5881 3147
EMail: nkong@cnnic.cn