[要約] RFC 9082は、登録データアクセスプロトコル（RDAP）のクエリフォーマットに関するもので、インターネットリソースの登録情報を検索するための標準化された方法を提供します。このプロトコルは、ドメイン名、IPアドレス、オートノミックシステム番号などの情報を効率的に取得するために利用されます。RDAPはWHOISプロトコルの後継として設計され、より安全で、データアクセスの制御が可能な方法を提供します。
Internet Engineering Task Force (IETF) S. Hollenbeck
Request for Comments: 9082 Verisign Labs
STD: 95 A. Newton
Obsoletes: 7482 AWS
Category: Standards Track June 2021
ISSN: 2070-1721
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). This document obsoletes RFC 7482.
この文書では、「Restful」Web Access Patternsを使用して、レジストリから登録情報を取得するために使用できるHTTP URLを構築するための統一パターンについて説明します。これらの均一なパターンは、登録データアクセスプロトコル（RDAP）のクエリ構文を定義します。この文書はRFC 7482を廃止します。
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 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、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/rfc9082.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9082で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 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）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Conventions Used in This Document
2.1. Acronyms and Abbreviations
3. Path Segment Specification
3.1. Lookup Path Segment Specification
3.1.1. IP Network Path Segment Specification
3.1.2. Autonomous System Path Segment Specification
3.1.3. Domain Path Segment Specification
3.1.4. Nameserver Path Segment Specification
3.1.5. Entity Path Segment Specification
3.1.6. Help Path Segment Specification
3.2. Search Path Segment Specification
3.2.1. Domain Search
3.2.2. Nameserver Search
3.2.3. Entity Search
4. Query Processing
4.1. Partial String Searching
4.2. Associated Records
5. Extensibility
6. Internationalization Considerations
6.1. Character Encoding Considerations
7. IANA Considerations
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Appendix A. Changes from RFC 7482
Acknowledgments
Authors' Addresses
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). This document obsoletes RFC 7482.
この文書では、RESTful Webサービスと統一クエリパターンを使用して登録データを照会するための仕様について説明します。サービスは、ハイパーテキスト転送プロトコル（HTTP）[RFC7230]と[RFC7480]に記載されている規則を使用して実装されています。これらの均一なパターンは、登録データアクセスプロトコル（RDAP）のクエリ構文を定義します。この文書はRFC 7482を廃止します。
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]との欠陥に対処することを目的としています。
* lack of standardized command structures;
* 標準化されたコマンド構造の欠如
* lack of standardized output and error structures;
* 標準化された出力とエラー構造の欠如。
* lack of support for internationalization and localization; and
* 国際化と地域化の支援の欠如そして
* lack of support for user identification, authentication, and access control.
* ユーザー識別、認証、およびアクセス制御のためのサポートの欠如。
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 is to enable queries of:
この文書に記載されているパターンは意図的に、RIRSおよびDNRによって使用されるwhisおよび他のRESTful Webサービスで採用されているすべての方法を網羅していません。ここで説明されているパターンの意図は、次のクエリを有効にすることです。
* networks by IP address;
* IPアドレスによるネットワーク
* Autonomous System (AS) numbers by number;
* 自律システム（AS）番号による数字。
* reverse DNS metadata by domain;
* ドメイン別にDNSメタデータをリバースします。
* nameservers by name; and
* ネームサーバーの名前。そして
* entities (such as registrars and contacts) by identifier.
* 識別子によるエンティティ（レジストラとコンタクトなど）。
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 specifications 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 specifications.
同様に、将来のIETFの仕様は、追加のクエリタイプの追加パターンを追加することがあります。この文書で定義されているパターンや将来のIETF仕様で定義されたパターンを妨害しないカスタム拡張機能に対応するために、シンプルなパターン名前空間スキームがセクション5に記載されています。
WHOIS services, in general, are read-only services. Accordingly, 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 [RFC9083].
この文書は、記載されているURLをHTTP GETで発行することから返された結果またはエンティティを説明しません。これらのエンティティの仕様は[RFC9083]に記載されています。
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", "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.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
IDN: Internationalized Domain Name, a fully-qualified domain name containing one or more labels that are intended to include one or more Unicode code points outside the ASCII range (cf. "domain name", "fully-qualified domain name", and "internationalized domain name" in RFC 8499 [RFC8499]).
IDN：国際化されたドメイン名、ASCII範囲外の1つ以上のUnicodeコードポイントを含むことを目的とした1つ以上のラベルを含む完全修飾ドメイン名（CF。ドメイン名 "、「完全修飾ドメイン名」、および」RFC 8499 [RFC8499]の国際化ドメイン名 "）。
IDNA: Internationalized Domain Names in Applications, a protocol for the handling of IDNs. In this document, "IDNA" refers specifically to the version of those specifications known as "IDNA2008" [RFC5890].
IDNA：アプリケーションにおける国際化されたドメイン名、IDNSの処理のためのプロトコル。この文献では、「IDNA」とは、「IDNA2008」[RFC5890]として知られているこれらの仕様のバージョンを指す。
DNR: Domain Name Registry or Domain Name Registrar
DNR：ドメイン名レジストリまたはドメイン名レジストラ
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
RDAP：登録データアクセスプロトコル
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を使用したサービスと残りの原則を説明する形容詞。
RIR: Regional Internet Registry
RIR：地域インターネットレジストリ
The base URLs used to construct RDAP queries are maintained in an IANA registry (the "bootstrap 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 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/".
RDAPクエリを構築するために使用される基本URLは、[RFC7484]に記載されているIANAレジストリ（「ブートストラップレジストリ」）に維持されます。クエリは、レジストリから適切なベースURLを検索し、どちらのセクション3.1または3.2で指定されたパスセグメントを追加することによって形成されます。一般に、レジストリまたは他のサービスプロバイダは、プロトコル、ホスト、およびポートを識別するベースURLを提供し、これはRFC 3986 [RFC3986]のセクション5に従って完全なURLが解決されるベースURLとして使用されます。。たとえば、ベース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. This limitation can be overcome for entities by using the practice described in RFC 8521 [RFC8521].
ブートストラップレジストリには、エンティティとヘルプを含む、グローバルネームスペースの一部ではないクエリオブジェクトの情報は含まれていません。関連付けられたオブジェクトのベースURLは、完全なクエリを構築するために必要です。この制限は、RFC 8521 [RFC8521]に記載されている慣行を使用して実体を克服することができます。
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 with 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 with 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ヘッドメソッドを使用して、RDAPエンコード結果を返すことなくオブジェクトが存在するかどうかを判断するための簡単な検索です。
The resource type path segments for exact match lookup are:
正確な一致検索のためのリソースタイプパスセグメントは次のとおりです。
'ip': Used to identify IP networks and associated data referenced using either an IPv4 or IPv6 address.
'ip'：IPv4またはIPv6アドレスを使用して参照されるIPネットワークと関連データを識別するために使用されます。
'autnum': Used to identify Autonomous System number registrations and associated data referenced using an asplain Autonomous System number.
'autnum'：ASPLAIN自律システム番号を使用して参照されている自律システム番号登録と関連データを識別するために使用されます。
'domain': Used to identify reverse DNS (RIR) or domain name (DNR) information and associated data referenced using a fully qualified domain name.
'domain'：逆DNS（RIR）またはドメイン名（DNR）情報と、完全修飾ドメイン名を使用して参照されているデータを識別するために使用されます。
'nameserver': Used to identify a nameserver information query using a host name.
'nameServer'：ホスト名を使用してネームサーバー情報クエリを識別するために使用されます。
'entity': Used to identify an entity information query using a string identifier.
'entity'：文字列識別子を使用してエンティティ情報クエリを識別するために使用されます。
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 prefix length of 32 for IPv4 and a prefix 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」に続くPATHセグメントは、IPv4ドット10進数[RFC5952]アドレス（XXX）またはIPv4のいずれかである。IPv6クラスレス間ドメインルーティング（CIDR）[RFC4632]表記アドレスブロック（すなわち、XXX / YY）。意味的には、アドレスを使用するより単純な形式は、IPv4のプレフィックス長が32のCIDRブロックとIPv6のプレフィックス長を考えることができます。特定の特定のアドレスまたは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 SHOULD ignore it.
このクエリでサポートされているIPv4およびIPv6アドレスフォーマットは、IPv4AddressおよびIPv6Address ABNF定義として、RFC 3986 [RFC3986]のセクション3.2.2で説明されています。有効なIPv6テキストアドレスフォーマット[RFC4291]を使用できます。これには、圧縮されたゼロと埋め込みIPv4アドレスを含むIPv6アドレスを使用して、またはIPv6アドレスを使用して書き込まれたIPv6アドレスが含まれます。IPv6アドレス[RFC5952]のテキスト表現を書く規則をお勧めします。ただし、ZONE_ID [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
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
The following URL would be used to find information for the most specific network containing 2001:db8::
次のURLは、2001：DB8 ::を含む最も具体的なネットワークの情報を見つけるために使用されます。
https://example.com/rdap/ip/2001:db8::
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.
自律システム番号登録に関する情報の問合せは、XXXがASPLAN自律システム番号[RFC5396]である形式/ autnum / xxxです。一部のレジストリでは、自律システム番号の登録は個々の数字で行われますが、他のレジストリは自律システム番号のブロックを登録することがあります。このクエリのセマンティクスは、数が登録されたブロックの範囲内にある場合、クエリのターゲットはブロック登録であり、個々の数登録は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
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
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.
ドメイン情報のクエリは、xxxxがin-addr.arpaまたはIP6のどちらかで（RFC0952の[RFC0952]および[RFC1123]で指定されている）ドメイン名（REOTからの相対）ドメイン名（REOT（RFC0952]および[RFC1123]）のいずれかのドメイン名です。ARPAゾーン（RIRS用）またはサーバー演算子によって管理されているゾーン内の完全修飾ドメイン名（DNRS用）。a-labelまたはu-label形式で表される国際化されたドメイン名（rfc5890]も有効なドメイン名です。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 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.
IDNは、AラベルとUラベルの混合物として表されるべきではありません。つまり、IDN内の国際化されたラベルは、すべてのAラベルまたはすべてのUラベルのいずれかです。RDAPクライアントが複数の独立したデータソースからクエリ文字列をアセンブルすることが可能です。そのようなクライアントは、AラベルとUラベルの間で変換を実行できない可能性があります。A-LABELとUラベルを組み合わせたクエリ文字列を受信するRDAPサーバーは、すべてのUラベルをA-LABELに変換したり、IDNA処理を実行したり、完全一致検索で進みます。そのような場合、クエリソースに返される応答は、クエリソースからの入力と一致しない可能性があります。あるいは、サーバはクエリを処理することを拒否することができる。
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-labelまたはu-labelフォームのいずれかを使用して一致を実行できます。すべてのラベルをマッチングするための1つの一貫したフォームを使用すると、信頼性が高くなる可能性があります。
The following URL would be used to find information describing the zone serving the network 192.0.2/24:
次のURLは、ネットワークにサービスを提供するゾーンを説明する情報を見つけるために使用されます。
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
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
The following URL would be used to find information for the xn--fo-5ja.example IDN:
次のURLがXN - FO-5JA.Example IDNの情報を見つけるために使用されます。
https://example.com/rdap/domain/xn--fo-5ja.example
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.
<nameserver name>パラメータは、[RFC0952]と[RFC1123]で指定されている完全修飾ホスト名を表します。AラベルフォーマットまたはUラベルフォーマット[RFC5890]で表される国際化された名前も有効なネームサーバー名です。NameServer Namesの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 Namneserverの情報を見つけるために使用されます。
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
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>パラメータは、構文が登録プロバイダに固有のエンティティ（連絡先、登録者、またはレジストラなど）を表します。たとえば、DNRSによっては、[RFC5730]と[RFC5733]で連絡先IDが指定されています。
The following URL would be used to find information for the entity associated with handle XXXX:
次のURLは、ハンドル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
Pattern matching semantics are described in Section 4.1. The resource type path segments for search are:
パターンマッチングセマンティクスはセクション4.1で説明されています。検索用のリソースタイプパスセグメントは次のとおりです。
'domains': Used to identify a domain name information search using a pattern to match a fully qualified domain name.
'Domains'：完全修飾ドメイン名と一致するパターンを使用してドメイン名情報検索を識別するために使用されます。
'nameservers': Used to identify a nameserver information search using a pattern to match a host name.
'NameServers'：ホスト名と一致するようにパターンを使用してネームサーバー情報検索を識別するために使用されます。
'entities': Used to identify an entity information search using a pattern to match a string identifier.
「エンティティ」：文字列識別子と一致するようにパターンを使用してエンティティ情報検索を識別するために使用されます。
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), a noun representing the JSON object property associated with the object being searched for, the equal sign character ('=', US-ASCII value 0x003D), and the search pattern (this is in contrast to the more generic HTTP query string that allows multiple simultaneous parameters). 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クエリ文字列は、検索されているオブジェクトに関連付けられているJSONオブジェクトプロパティを表す名詞である疑問符文字（ '？'、as-ASCII値0x003f）の連結を使用して形成されます。US-ASCII値0x003D）、および検索パターン（これは、複数の同時パラメータを許可するより一般的なHTTPクエリ文字列とは対照的です）。検索パターンクエリ処理は、この文書で説明されているドメイン、ネームサーバー、およびエンティティオブジェクトの場合、複数のオブジェクトフォームは「ドメイン」、「ネームサーバー」、および「エンティティ」です。
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?nsLdhName=<nameserver search pattern>
Syntax: domains?nsIp=<nameserver IP address>
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]. The following URL would be used to find DNR information for domain names matching the "example*.com" pattern:
XXXXは、「文字、数字、ハイフン」（LDH）形式のドメイン名を表す検索パターンです[RFC5890]。次のURLは、 "example * .com"パターンに一致するドメイン名のDNR情報を見つけるために使用されます。
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-Label FormatのIDNS [RFC5890]も検索パターンとして使用できます（セクション4を参照）。これらの名前の検索はフォーム/ドメインのものですか？name = xxxx。ここで、xxxxは、U-Labelフォーマット[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]. The following URL would be used to search for domains delegated to nameservers matching the "ns1.example*.com" pattern:
YYYYは、「文字、数字、ハイフン」形式[RFC5890]のホスト名を表す検索パターンです。次のURLは、 "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 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
Syntax: nameservers?name=<nameserver search pattern>
Syntax: nameservers?ip=<nameserver IP address>
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]. The following URL would be used to find information for nameserver names matching the "ns1.example*.com" pattern:
XXXXは、「文字、数字、ハイフン」形式[RFC5890]のホスト名を表す検索パターンです。次のURLは、 "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を参照）。これらの名前の検索はフォーム/ネームサーバーのものですか？name = xxxx。ここで、xxxxは、U-Labelフォーマットでネームサーバー名を表す検索パターンです[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 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
Syntax: entities?fn=<entity name 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 described in Section 5.1 of [RFC9083]. The following URL would be used to find information for entity names matching the "Bobby Joe*" pattern:
XXXXは、[RFC9083]のセクション5.1で説明されているように、エンティティ（連絡先、登録者、またはレジストラなど）の「FN」プロパティを表す検索パターンです。次のURLは、 "Bobby Joe *"パターンと一致するエンティティ名の情報を見つけるために使用されます。
https://example.com/rdap/entities?fn=Bobby%20Joe*
Searches for entity information by handle are specified using this form:
このフォームを使用して、ハンドルによるエンティティ情報の検索が指定されています。
entities?handle=XXXX
エンティティ？handle = 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*
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 0x2A) character to match zero or more trailing characters. A character string representing a domain label suffix 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. A partial string search MUST NOT include more than one asterisk. Additional pattern matching processing is beyond the scope of this specification.
部分文字列検索では、ゼロ以上の末尾の文字を一致させるために、アスタリスク（ '*'、US-ASCII値0x2a）文字を使用します。ドメインラベルのサフィックスを表す文字列は、検索の範囲を制限するために検索パターンの最後に連結されてもよい。たとえば、検索パターン「試験*」は「example.com」と「example.net」と一致します。検索パターン「試験* .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 (unless another response code is more appropriate based on a server's policy settings) to note that search functionality is supported, but this particular query cannot be processed. When returning a 422 error, the server MAY also return an error response body as specified in Section 6 of [RFC9083] if the requested media type is one that is specified in [RFC7480].
サーバーが検索要求を受信したが、部分的な一致検索の特定のスタイルをサポートしていないため、リクエストを処理できない場合は、HTTP 422（未処理のエンティティ）[RFC4918]応答を返します（別の応答コードがより適切でない限りサーバーのポリシー設定）検索機能がサポートされているが、この特定のクエリを処理できません。422エラーを返すとき、要求されたメディアタイプが[RFC7480]で指定されているものである場合は、[RFC9083]のセクション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 NOT submit 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とDNRの両方に一般的に登録されている限られた数のオブジェクトのパスセグメントの仕様について説明します。すべてのレジストリに登録されているすべてのオブジェクトのパスセグメントを説明しようとしません。ここでは指定されていないオブジェクトのカスタムパスセグメントを作成できます。登録データアクセスプロトコル（RDAP）のHTTP使用法（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）でプレフィックスすることによって作成できます。たとえば、カスタムエンティティパスセグメントは "Entity"を "custom_"でプレフィックスすることで作成でき、 "custom_entity"を作成できます。サーバーは、認識されていないパスセグメントを持つ要求のために適切な障害ステータスコードを返す必要があります。
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.
RDAPサービスへのクエリ引数として、Uラベル（IDNラベルのUnicode形式）またはAラベル（US-ASCII形式のIDNラベル）をサポートする機能をサポートする場合があります。US-ASCII文字以外の文字を処理できるクライアントは、ラベルの文字列よりも視覚的に認識可能でよく知られているが、プログラムインタフェースを使用するクライアントが不可能である場合は、プログラムのインターフェイスを使用するクライアントが読み取りやすくなる可能性があります。キーボード設定でUラベルを入力するには。どちらのクエリフォームも受け入れられます。
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)" [RFC9083].
国際化されたドメインとネームサーバーの名前には、[RFC4290]に記載されているように、文字亜種とバリアントラベルを含めることができます。国際化されたドメイン名およびネームサーバー名のクエリをサポートするクライアントは、「登録データアクセスプロトコル（RDAP）のJSON応答（RFC9083」で指定されているように、バリアントを記述するサービスプロバイダーの応答を受け入れる必要があります。
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.
US-ASCII文字を含むクエリ文字列を送信するRDAPクライアントは、そのような文字列を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（Bad Request）応答を返すことができます。
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 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).
クエリを処理するときは、推定Uラベルを持つものを含むDNS名の処理に違いがあります。DNS名は、RFC 1035 [RFC1035]のセクション3.1で説明されているDNSマッチング規則に従って、RFC 5891 [RFC5891]のセクション5.4の編集規則に従って扱われます。。DNS名の一致は、UラベルとNR-LDHラベルの組み合わせが単一のドメインまたはホスト名で見つけることが可能であるため、1つのラベルを1つ進めます。ラベルがUラベルかNR-LDHラベルであるかどうかの決定は、ラベルにUS-ASCII文字、数字、またはハイフン（いわゆる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]は、予測可能性と一致数を最大化するために使用されます。この場合、NFCとは対照的に、ケースフォールドNFKCの使用に注意してください。
This document has no IANA actions.
この文書にはIANAの行動がありません。
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）」[RFC7480]の「HTTP使用法」のセクション5.5に記載されているように、受信した検索要求のレートを制御するために使用できます。サーバー演算子はまた、検索要求に応答して返された情報の量を制限することによってリスクを減らすことができます。
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, DOI 10.17487/RFC0952, October 1985, <https://www.rfc-editor.org/info/rfc952>.
[RFC0952] Harrenstien、K.、Stahl、M.、E. Feinler、「DoDインターネットホストテーブル仕様」、RFC 952、DOI 10.17487 / RFC0952、1985年10月、<https：//www.rfc-editor.org/情報/ RFC952>。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, DOI 10.17487/RFC1035, November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[RFC1035] Mockapetris、P.、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、DOI 10.17487 / RFC1035、1987年11月、<https：//www.rfc-editor.org/info/rfc1035>。
[RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, <https://www.rfc-editor.org/info/rfc1123>.
[RFC1123] Braden、R.、Ed。、「インターネットホストの要求 - アプリケーションおよびサポートの要件」、STD 3、RFC 1123、DOI 10.17487 / RFC1123、1989年10月、<https：//www.rfc-editor.org/info/ RFC1123>。
[RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", RFC 1166, DOI 10.17487/RFC1166, July 1990, <https://www.rfc-editor.org/info/rfc1166>.
[RFC1166] Kirkpatrick、S.、Stahl、M.、およびM. Recker、「インターネット番号」、RFC 1166、DOI 10.17487 / RFC1166、1990年7月、<https：//www.rfc-editor.org/info/rfc1166>。
[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、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//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, DOI 10.17487/RFC3986, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC3986] Berners-Lee、T.、Field、R.、およびL.Masinter、「Uniform Resource Identifier（URI）：汎用構文」、STD 66、RFC 3986、DOI 10.17487 / RFC3986、2005年1月、<https：//www.rfc-editor.org/info/rfc3986>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <https://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R.およびS.Theering、 "IPバージョン6アドレッシングアーキテクチャ"、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<https：//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, DOI 10.17487/RFC4632, August 2006, <https://www.rfc-editor.org/info/rfc4632>.
[RFC4632] Fuller、V.およびT.Li、「クラスレスドメイン間ルーティング（CIDR）：インターネットアドレス割り当てと集約計画」、BCP 122、RFC 4632、DOI 10.17487 / RFC4632、2006年8月、<https：//www.rfc-editor.org/info/rfc4632>。
[RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, DOI 10.17487/RFC4918, June 2007, <https://www.rfc-editor.org/info/rfc4918>.
[RFC4918] DusseAll、L.、ED。、「Web分散オーサリングとバージョン管理（WebDAV）」、RFC 4918、DOI 10.17487 / RFC4918、2007年6月、<https://www.rfc-editor.org/info/ RFC4918>。
[RFC5396] Huston, G. and G. Michaelson, "Textual Representation of Autonomous System (AS) Numbers", RFC 5396, DOI 10.17487/RFC5396, December 2008, <https://www.rfc-editor.org/info/rfc5396>.
[RFC5396] Huston、G.およびG. Michaelson、「自律システムのテキスト表現」、RFC 5396、DOI 10.17487 / RFC5396、2008年12月、<https：//www.rfc-editor.org/info/RFC5396>。
[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.、「Extensible Provisioning Protocol（EPP）」、STD 69、RFC 5730、DOI 10.17487 / RFC5730、2009年8月、<https：//www.rfc-editor.org/info/rfc5730>。
[RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, August 2009, <https://www.rfc-editor.org/info/rfc5733>.
[RFC5733] Hollenbeck、S。、「Extensible Provisioning Protocol（EPP）連絡先マッピング」、STD 69、RFC 5733、DOI 10.17487 / RFC5733、2009年8月、<https：//www.rfc-editor.org/info/rfc5733>。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/info/rfc5890>.
[RFC5890] Klensin、J.、「アプリケーションの国際化ドメイン名（IDNA）：定義とドキュメントフレームワーク、RFC 5890、DOI 10.17487 / RFC5890、2010年8月、<https：//www.rfc-editor.org/info/RFC5890>。
[RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, <https://www.rfc-editor.org/info/rfc5891>.
[RFC5891] Klensin、J。、「アプリケーションの国際化ドメイン名（IDNA）：プロトコル」、RFC 5891、DOI 10.17487 / RFC5891、2010年8月、<https：//www.rfc-editor.org/info/rfc5891>。
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, <https://www.rfc-editor.org/info/rfc5952>.
[RFC5952]川村、S.およびM.川島、「IPv6アドレステキスト表現の推奨事項」、RFC 5952、DOI 10.17487 / RFC5952、2010年8月、<https：//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, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールド、R.、ED。J.Reschke、ED。、「Hypertext Transfer Protocol（HTTP / 1.1）：メッセージ構文とルーティング」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<https：//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, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231] Fielding、R.、Ed。J. Reschke、ED。、「Hypertext Transfer Protocol（HTTP / 1.1）：セマンティクスとコンテンツ」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<https://www.rfc-editor.org/info/rfc7231>。
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the Registration Data Access Protocol (RDAP)", STD 95, RFC 7480, DOI 10.17487/RFC7480, March 2015, <https://www.rfc-editor.org/info/rfc7480>.
[RFC7480]ニュートン、A.、Ellacott、B.およびN.Kong、「登録データアクセスプロトコル（RDAP）」、STD 95、RFC 7480、DOI 10.17487 / RFC7480、2015年3月、<https：//www.rfc-editor.org/info/rfc7480>。
[RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the Registration Data Access Protocol (RDAP)", STD 95, RFC 7481, DOI 10.17487/RFC7481, March 2015, <https://www.rfc-editor.org/info/rfc7481>.
[RFC7481] Hollenbeck、S.およびN.Kong、「登録データアクセスプロトコルのためのセキュリティサービス（RDAP）」、STD 95、RFC 7481、DOI 10.17487 / RFC7481、2015年3月、<https：//www.rfc-編集者.ORG / INFO / RFC7481>。
[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>。
[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>。
[RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, January 2019, <https://www.rfc-editor.org/info/rfc8499>.
[RFC8499] Hoffman、P.、Sullivan、A.、K. Fujiwara、「DNS用語」、BCP 219、RFC 8499、DOI 10.17487 / RFC8499、2019年1月、<https：//www.rfc-editor.org/情報/ RFC8499>。
[RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the Registration Data Access Protocol (RDAP)", STD 95, RFC 9083, DOI 10.17487/RFC9083, June 2021, <https://www.rfc-editor.org/info/rfc9083>.
[RFC9083] Hollenbeck、S.およびA.ニュートン「登録データアクセスプロトコル（RDAP）」、STD 95、RFC 9083、DOI 10.17487 / RFC9083、2021年6月、<https：///www.rfc-編集者.ORG / INFO / RFC9083>。
[Unicode-UAX15] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", September 2013, <https://www.unicode.org/reports/tr15/>.
[Unicode-UAX15] Unicodeコンソーシアム、「Unicode Standard Annex＃15：Unicode正規化フォーム」、2013年9月、<https：//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, <https://www.ics.uci.edu/~fielding/pubs/dissertation/ fielding_dissertation.pdf>.
[REST]フィールド、R.、「アーキテクチャスタイルとネットワークベースのソフトウェアアーキテクチャの設計」、Ph.D。<https://www.ics.uci.edu/~fielding/pubs/dissertation/ fielding_dissertation/ fielding_dissertation/ fielding_dissertation/ fielding_dissertation / fielding_dissertation / fielding_dissertation / fielding_dissertation.pdf>。
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, DOI 10.17487/RFC3912, September 2004, <https://www.rfc-editor.org/info/rfc3912>.
[RFC3912] Daigle、L.、 "Whoisプロトコル仕様"、RFC 3912、DOI 10.17487 / RFC3912、2004年9月、<https://www.rfc-editor.org/info/rfc3912>。
[RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, DOI 10.17487/RFC4007, March 2005, <https://www.rfc-editor.org/info/rfc4007>.
[RFC4007] Theering、S.、Haberman、B.、Jinmei、T.、Nordmark、E.、およびB.Zill、「IPv6スコープアドレスアーキテクチャ」、RFC 4007、DOI 10.17487 / RFC4007、2005年3月、<https：//ww.rfc-editor.org/info/rfc4007>。
[RFC4290] Klensin, J., "Suggested Practices for Registration of Internationalized Domain Names (IDN)", RFC 4290, DOI 10.17487/RFC4290, December 2005, <https://www.rfc-editor.org/info/rfc4290>.
[RFC4290] Klensin、J.、「国際化されたドメイン名の登録（IDN）」、RFC 4290、DOI 10.17487 / RFC4290、2005年12月、<https：//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, DOI 10.17487/RFC6874, February 2013, <https://www.rfc-editor.org/info/rfc6874>.
[RFC6874] Carpenter、B.、Cheshire、S.およびR.hinden、「アドレスリテラルおよび統一リソース識別子のIPv6ゾーン識別子の表現」、RFC 6874、DOI 10.17487 / RFC6874、2013年2月、<https：// www。rfc-editor.org/info/rfc6874>。
[RFC6927] Levine, J. and P. Hoffman, "Variants in Second-Level Names Registered in Top-Level Domains", RFC 6927, DOI 10.17487/RFC6927, May 2013, <https://www.rfc-editor.org/info/rfc6927>.
[RFC6927] Levine、J.およびP.HOFFMAN、「最上位ドメインに登録されている第2レベルの名前の変種」、RFC 6927、DOI 10.17487 / RFC6927、2013年5月、<https：//www.rfc-editor.org/ info / rfc6927>。
[RFC8521] Hollenbeck, S. and A. Newton, "Registration Data Access Protocol (RDAP) Object Tagging", BCP 221, RFC 8521, DOI 10.17487/RFC8521, November 2018, <https://www.rfc-editor.org/info/rfc8521>.
[RFC8521] Hollenbeck、S.およびA.ニュートン、「登録データアクセスプロトコル（RDAP）オブジェクトタグ付け」、BCP 221、RFC 8521、DOI 10.17487 / RFC8521、2018年11月、<https：//www.rfc-editor.org/ info / rfc8521>。
* Addressed known errata.
* 既知の正誤表を扱った。
* Addressed other reported clarifications and corrections: IDN, IDNA, and DNR definitions. Noted that registrars are entities. Added a reference to RFC 8521 to address the bootstrap registry limitation. Removed extraneous "...". Clarified HTTP query string, search pattern, name server search, domain label suffix, and asterisk search.
* 他の報告されている明確化と修正について説明しました：IDN、IDNA、およびDNRの定義。レジストラはエンティティです。ブートストラップレジストリ制限に対処するためにRFC 8521への参照を追加しました。無関係な「...」を削除しました。HTTPクエリ文字列、検索パターン、ネームサーバー検索、ドメインラベルサフィックス、およびアスタリスク検索。
* Addressed "The HTTP query string" clarification.
* 「HTTPクエリ文字列」の説明を説明します。
* Modified coauthor address.
* 修正されたCoAuthorアドレス
* Updated references to RFC 7483 to RFC 9083.
* RFC 7483への参照をRFC 9083に更新しました。
* Added an IANA Considerations section. Changed references to use HTTPS for targets.
* IANAの考慮事項セクションを追加しました。ターゲットにHTTPSを使用するための参照を変更しました。
* Changed "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" to "Changed "XXXX is a search pattern representing the "fn" property of an entity (such as a contact, registrant, or registrar) name as described in Section 5.1".
* 「XXXXは、セクション5.1で指定されているように、コンタクト、登録者、またはレジストラなどの「Fn」プロパティを表す検索パターン「変更」XXXXは、の「FN」プロパティを表す検索パターンです。セクション5.1で説明されているように、エンティティ（連絡先、登録者、またはレジストラ）の名前。
* Added acknowledgments.
* 謝辞を追加しました。
* Changed "The intent of the patterns described here are to enable queries" to "The intent of the patterns described here is to enable queries".
* 「ここで説明されているパターンの意図は、ここで説明されているパターンの意図を「クエリの意図」を有効にすることはクエリを有効にすることです」を変更しました。
* Changed "the corresponding syntax extension in RFC 6874 [RFC6874] MUST NOT be used, and servers are to ignore it if possible" to "the corresponding syntax extension in RFC 6874 [RFC6874] MUST NOT be used, and servers SHOULD ignore it".
* 「RFC 6874 [RFC6874の対応する構文拡張を使用してはいけません）を変更し、RFC 6874 [RFC6874]の対応する構文拡張は使用してはいけず、サーバーを無視する必要があります。
* Changed "Only a single asterisk is allowed for a partial string search" to "A partial string search MUST NOT include more than one asterisk".
* 「部分的な文字列検索では単一のアスタリスクのみが許可されている」と「部分的な文字列検索には、複数のアスタリスクを含めないでください」という変更。
* Changed "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" to "Clients SHOULD NOT submit a partial match search of Unicode characters where a Unicode character may be legally combined with another Unicode character or characters".
* 「クライアント」が、Unicode文字が別のUnicode文字と正当に組み合わせることができるUnicode文字の部分的な一致検索を送信しないでください。もう1つのUnicode文字または文字」
* Changed description of nameserver IP address "search pattern" in Sections 3.2.1 and 3.2.2.
* セクション3.2.1および3.2.2のネームサーバIPアドレス「検索パターン」の説明を変更しました。
* IESG review feedback: Added "obsoletes 7482" to the headers, Abstract, and Introduction. Changed "IETF standards" to "IETF specifications" and "Therefore" to "Accordingly" in Section 1. Updated the BCP 14 boilerplate. Added definition of "bootstrap registry" and changed "concatenating ... to" to "concatenating ... with" in Section 3. Changed "bitmask length" to "prefix length" and "2001:db8::0" to "2001:db8::" in Section 3.1.1. Added "in contrast to the more generic HTTP query string that admits multiple simultaneous parameters" in Section 3.2. Changed "0x002A" to "0x2A" in Section 4.1. Clarified use of HTTP 422 SHOULD in Section 4.1.
* IESGレビューフィードバック：ヘッダー、要約、および紹介に「廃止廃止7482」を追加しました。セクション1. BCP 14のボイラープレートを更新しました。「Bootstrap Registry」の定義を追加し、「連結...」を「連結...」に変更しました.3。「ビットマスク長」を「プレフィックス長」と「2001：DB8 :: 0」2001に変更しました。：3.1.1のDB8 :: "。セクション3.2では、「複数の同時パラメータを認めるより一般的なHTTPクエリ文字列とは対照的に」を追加しました。セクション4.1で "0x002a"を "0x2a"に変更しました。HTTP 422の使用を4.1節で明確にした。
Acknowledgments
謝辞
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.
この文書は、AnturoのArturo L. Ripe ranjbarのByron J. Ellacottによって開発されたRIRクエリフォーマットのRIRクエリフォーマット、およびAndrew L.ニュートンのオリジナル作業から導き出されています。さらに、このドキュメントは、Francisco AriasとSteve ShengのICANNとScott HollenbeckのSteve Shengによって、Verisign LabsのHollenbeckのSteve Shengを組み込んでいます。
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, Mario Loffredo, Patrick Mevzek, Mark Nottingham, Kaveh Ranjbar, Arturo L. Servin, Steve Sheng, Jasdip Singh, and Andrew Sullivan.
著者らは、この文書への貢献のために次の個人を承認したいと思います.Francisco Arias、Marc Blanchet、Ernie Dainow、Jean-Philippe Dionne、Byron J. Ellacott、John Klensin、John Levine、Edward Levedo、Mario Loffredo、Patrick Mevzek、Mark Nottingham、Kaveh Ranjbar、Arturo L. Servic、Steve Sheng、Jasdip Singh、Andrew Sullivan。
Authors' Addresses
著者の住所
Scott Hollenbeck Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States of America
Scott Hollenbeck Verisign Labs 12061 Bluemont Way Reston、VA 20190アメリカ合衆国
Email: shollenbeck@verisign.com
URI: https://www.verisignlabs.com/
Andy Newton Amazon Web Services, Inc. 13200 Woodland Park Road Herndon, VA 20171 United States of America
Andy Newton Amazon Web Services、Inc。13200 Woodland Park Road Herndon、VA 20171アメリカ合衆国
Email: andy@hxr.us