[要約] RFC 9083は、登録データアクセスプロトコル（RDAP）のJSONレスポンスに関する規格です。この文書の目的は、インターネットリソースの登録情報を問い合わせる際のデータフォーマットを標準化することにあります。主にドメイン名、IPアドレス、AS番号などの情報を検索する際に利用されます。
Internet Engineering Task Force (IETF) S. Hollenbeck
Request for Comments: 9083 Verisign Labs
STD: 95 A. Newton
Obsoletes: 7483 AWS
Category: Standards Track June 2021
ISSN: 2070-1721
JSON Responses for the Registration Data Access Protocol (RDAP)
登録データアクセスプロトコル（RDAP）のJSON応答
Abstract
概要
This document describes JSON data structures representing registration information maintained by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs). These data structures are used to form Registration Data Access Protocol (RDAP) query responses. This document obsoletes RFC 7483.
この文書では、地域インターネットレジストリ（RIRS）とドメイン名レジストリ（DNRS）によって維持されている登録情報を表すJSONデータ構造について説明します。これらのデータ構造は、登録データアクセスプロトコル（RDAP）クエリ応答を形成するために使用されます。この文書はRFC 7483を廃止します。
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/rfc9083.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9083で入手できます。
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
1.1. Terminology and Definitions
1.2. Data Model
2. Use of JSON
2.1. Naming
3. Common Data Types
4. Common Data Structures
4.1. RDAP Conformance
4.2. Links
4.3. Notices and Remarks
4.4. Language Identifier
4.5. Events
4.6. Status
4.7. Port 43 WHOIS Server
4.8. Public IDs
4.9. Object Class Name
4.10. An Example
5. Object Classes
5.1. The Entity Object Class
5.2. The Nameserver Object Class
5.3. The Domain Object Class
5.4. The IP Network Object Class
5.5. The Autonomous System Number Object Class
6. Error Response Body
7. Responding to Help Queries
8. Responding To Searches
9. Indicating Truncated Responses
10. IANA Considerations
10.1. RDAP JSON Media Type Registration
10.2. JSON Values Registry
10.2.1. Notice and Remark Types
10.2.2. Status
10.2.3. Event Actions
10.2.4. Roles
10.2.5. Variant Relations
11. Security Considerations
12. Internationalization Considerations
12.1. Character Encoding
12.2. URIs and IRIs
12.3. Language Tags
12.4. Internationalized Domain Names
13. Privacy Considerations
14. References
14.1. Normative References
14.2. Informative References
Appendix A. Suggested Data Modeling with the Entity Object Class
A.1. Registrants and Contacts
A.2. Registrars
Appendix B. Modeling Events
Appendix C. Structured vs. Unstructured Addresses
Appendix D. Secure DNS
Appendix E. Motivations for Using JSON
Appendix F. Changes from RFC 7483
Acknowledgments
Authors' Addresses
This document describes responses in the JSON [RFC8259] format for the queries as defined by the Registration Data Access Protocol Query Format [RFC9082]. A communication protocol for exchanging queries and responses is described in [RFC7480]. This document obsoletes RFC 7483.
このドキュメントでは、登録データアクセスプロトコルクエリフォーマット[RFC9082]で定義されているクエリのJSON [RFC8259]フォーマットの応答について説明します。クエリと応答を交換するための通信プロトコルは[RFC7480]で説明されています。この文書はRFC 7483を廃止します。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
The following list describes terminology and definitions used throughout this document:
次のリストは、このドキュメントを通して使用される用語と定義について説明します。
DNR: Domain Name Registry or Domain Name Registrar
DNR：ドメイン名レジストリまたはドメイン名レジストラ
LDH: letters, digits, hyphen
LDH：手紙、数字、ハイフン
member: data found within an object as defined by JSON [RFC8259]
メンバー：JSONで定義されているオブジェクト内にあるデータ[RFC8259]
object: a data structure as defined by JSON [RFC8259]
オブジェクト：JSONで定義されたデータ構造[RFC8259]
object class: the definition of members that may be found in JSON objects described in this document
オブジェクトクラス：このドキュメントに記載されているJSONオブジェクトにあるメンバーの定義
object instance: an instantiation or specific instance of an object class
オブジェクトインスタンス：オブジェクトクラスのインスタンス化または特定のインスタンス
RDAP: Registration Data Access Protocol
RDAP：登録データアクセスプロトコル
RIR: Regional Internet Registry
RIR：地域インターネットレジストリ
The data model for JSON responses is specified in five sections:
JSON応答のデータモデルは、5つのセクションで指定されています。
1. simple data types conveyed in JSON primitive types (strings, numbers, booleans, and null)
1. JSONプリミティブ型（文字列、数字、ブール値、およびNULL）で伝達された単純なデータ型
2. data structures specified as JSON arrays or objects that are used repeatedly when building up larger objects
2. より大きなオブジェクトを構築するときに繰り返し使用されるJSON配列またはオブジェクトとして指定されたデータ構造
3. object classes representing structured data corresponding to a lookup of a single object
3. 単一のオブジェクトの検索に対応する構造化データを表すオブジェクトクラス
4. arrays of objects representing structured data corresponding to a search for multiple objects
4. 複数のオブジェクトの検索に対応する構造化データを表すオブジェクトの配列
5. the response to an error
5. エラーへの応答
The object classes represent responses for two major categories of data: responses returned by RIRs for registration data related to IP addresses, reverse DNS names, and Autonomous System numbers and responses returned by DNRs for registration data related to forward DNS names. The following object classes are returned by both RIRs and DNRs:
オブジェクトクラスは、データの2つの主要なカテゴリの応答を表します.IPアドレスに関連する登録データ、逆方向DNS名、およびPDNS名に関連する登録データのためにDNRSによって返された応答によって返される応答。次のオブジェクトクラスは、RIRSとDNRの両方によって返されます。
1. domains
1. ドメイン
2. nameservers
2. ネームサーバー
3. entities
3. エンティティ
The information served by both RIRs and DNRs for these object classes overlap extensively and are given in this document as a unified model for both classes of service.
これらのオブジェクトクラスの両方のRIRSとDNRによってサービスされる情報は広く重なり合い、このドキュメントには両方のサービスクラスの統合モデルとして指定されています。
In addition to the object classes listed above, RIRs also serve the following object classes:
上記のオブジェクトクラスに加えて、RIRSは次のオブジェクトクラスにも機能します。
1. IP networks
1. IPネットワーク
2. Autonomous System numbers
2. 自律システム番号
Object classes defined in this document represent a minimal set of what a compliant client/server needs to understand to function correctly; however, some deployments may want to include additional object classes to suit individual needs. Anticipating this need for extension, Section 2.1 of this document defines a mechanism for extending the JSON objects that are described in this document.
このドキュメントで定義されているオブジェクトクラスは、準拠しているクライアント/サーバーが正しく機能するのを理解する必要があるものの最小セットを表します。ただし、個々のニーズに合わせて追加のオブジェクトクラスを含めることができます。この文書のセクション2.1は、この文書に記載されているJSONオブジェクトを拡張するためのメカニズムを定義しています。
Positive responses take two forms. A response to a lookup of a single object in the registration system yields a JSON object, which is the subject of the lookup. A response to a search for multiple objects yields a JSON object that contains an array of JSON objects that are the subject of the search. In each type of response, other data structures are present within the topmost JSON object.
肯定的な回答は2つの形式を取ります。登録システム内の単一のオブジェクトの検索に対する応答は、ルックアップの主題であるJSONオブジェクトを生成します。複数のオブジェクトの検索に対する応答は、検索の主題であるJSONオブジェクトの配列を含むJSONオブジェクトを生成します。応答の各タイプでは、他のデータ構造が最上位のJSONオブジェクト内に存在します。
Clients of these JSON responses SHOULD ignore unrecognized JSON members in responses. Servers can insert members into the JSON responses, which are not specified in this document, but that does not constitute an error in the response. Servers that insert such unspecified members into JSON responses SHOULD have member names prefixed with a short identifier followed by an underscore followed by a meaningful name. It has been observed that these short identifiers aid software implementers with identifying the specification of the JSON member, and failure to use one could cause an implementer to assume the server is erroneously using a name from this specification. This allowance does not apply to jCard [RFC7095] objects. The full JSON name (the prefix plus the underscore plus the meaningful name) SHOULD adhere to the character and name limitations of the prefix registry described in [RFC7480]. Failure to use these limitations could result in slower adoption as these limitations have been observed to aid some client programming models.
これらのJSONレスポンスのクライアントは、回答の認識されていないJSONメンバーを無視します。サーバーは、このドキュメントでは指定されていないが、応答のエラーを構成しないJSON応答にメンバを挿入できます。このような不特定のメンバーをJSONレスポンスに挿入するサーバーには、短識別子が付いていたメンバー名が付いていた後にアンダースコアとそれに続く意味のある名前が付けられています。これらの短識別子は、JSONメンバーの仕様を識別してソフトウェアの実装者を援助し、使用できなかったことが観察され、使用できなかった可能性があり、実装者がこの仕様からの名前を使用してサーバーが誤っていると仮定する可能性があります。この許可はJCARD [RFC7095]オブジェクトには適用されません。フルJSON名（プレフィックスとアンダースコアと意味のある名前）は、[RFC7480]に記載されているプレフィックスレジストリの文字と名前の制限を遵守する必要があります。これらの制限を使用できなかった場合も、これらの制限がいくつかのクライアントプログラミングモデルを支援するために観察されたため、採用が遅くなる可能性があります。
Consider the following JSON response with JSON members, all of which are specified in this document.
JSONメンバーを使用した次のJSON応答を検討してください。そのすべてがこのドキュメントで指定されています。
{
"handle" : "ABC123",
"remarks" :
[
{
"description" :
[
"She sells sea shells down by the sea shore.",
"Originally written by Terry Sullivan."
]
}
]
}
Figure 1
図1
If The Registry of the Moon desires to express information not found in this specification, it might select "lunarNIC" as its identifying prefix and insert, as an example, the member named "lunarNIC_beforeOneSmallStep" to signify registrations occurring before the first moon landing and the member named "lunarNIC_harshMistressNotes" that contains other descriptive text.
この仕様に記載されていない情報を表現することを望む場合、最初の月の着陸の前に発生する登録を意味するために、「Lunarnic_BeforeSmallStep」という名前のメンバーは、識別されたプレフィックスとして「lunarnic」を選択することができます。他の記述テキストを含む「Lunarnic_HarshMistRessnotes」という名前のメンバー。
Consider the following JSON response with JSON names, some of which should be ignored by clients without knowledge of their meaning.
JSONの名前を使用した次のJSON応答を考えてください。そのうちのいくつかは、その意味についての知識なしにクライアントによって無視されるべきです。
{
"handle" : "ABC123",
"lunarNIC_beforeOneSmallStep" : "TRUE THAT!",
"remarks" :
[
{
"description" :
[
"She sells sea shells down by the sea shore.",
"Originally written by Terry Sullivan."
]
}
],
"lunarNIC_harshMistressNotes" :
[
"In space,",
"nobody can hear you scream."
]
}
Figure 2
図2.
Insertion of unrecognized members ignored by clients may also be used for future revisions to this specification.
クライアントによって無視された認識されていないメンバーの挿入は、この仕様に対する将来の修正にも使用される可能性があります。
Clients processing JSON responses need to be prepared for members representing registration data specified in this document to be absent from a response. In other words, servers are free to omit unrequired/optional JSON members containing registration data based on their own policies.
JSON応答を処理するクライアントは、この文書で指定された登録データを表すメンバーに対して、応答から欠けている必要があります。つまり、サーバーは自らのポリシーに基づいて登録データを含む未確認/オプションのJSONメンバーを自由に省略しています。
Finally, all JSON names specified in this document are case sensitive. Both servers and clients MUST transmit and process them using the specified character case.
最後に、この文書で指定されているすべてのJSON名は大文字と小文字が区別されます。サーバーとクライアントの両方が指定された文字の場合を使用して送信して処理する必要があります。
JSON [RFC8259] defines the data types of a number, character string, boolean, array, object, and null. This section describes the semantics and/or syntax reference for common, JSON character strings used in this document.
JSON [RFC8259]番号、文字列、ブール値、配列、オブジェクト、およびNULLのデータ型を定義します。このセクションでは、このドキュメントで使用されている一般的なJSON文字文字列のセマンティクスおよび/または構文参照について説明します。
handle: DNRs and RIRs have registry-unique identifiers that may be used to specifically reference an object instance. The semantics of this data type as found in this document are to be a registry-unique reference to the closest enclosing object where the value is found. The data type names "registryId", "roid", "nic-handle", "registrationNo", etc., are terms often synonymous with this data type. In this document, the term "handle" is used. The term exposed to users by clients is a presentation issue beyond the scope of this document. This value is a simple character string.
ハンドル：DNRSとRIRSには、オブジェクトインスタンスを具体的に参照するために使用できるレジストリ固有の識別子があります。このドキュメントにあるこのデータ型のセマンティクスは、値が見つかった最寄りの囲みオブジェクトへのレジストリ固有の参照です。データ型「RegistryID」、「ROID」、「NICハンドル」、「registanceNo」などは、このデータ型と同義語が多い用語です。この文書では、「ハンドル」という用語が使用されます。クライアントによってユーザーに公開されている用語は、この文書の範囲を超えてプレゼンテーションの問題です。この値は単純な文字列です。
IPv4 addresses: The representation of IPv4 addresses in this document uses the dotted-decimal notation. An example of this textual representation is "192.0.2.0".
IPv4アドレス：このドキュメントのIPv4アドレスの表現は、ドット付き10進表記を使用します。このテキスト表現の例は「192.0.2.0」です。
IPv6 addresses: The representation of IPv6 addresses in this document follow the forms outlined in [RFC5952]. An example of this textual representation is "2001:db8::1:0:0:1".
IPv6アドレス：このドキュメントのIPv6アドレスの表現は[RFC5952]で概説されている形式に従います。このテキスト表現の例は "2001：DB8 :: 1：0：0：1"です。
country codes: Where the identity of a geopolitical nation or country is needed, these identities are represented with the alpha-2 or two-character country code designation as defined in [ISO.3166.2020]. The alpha-2 representation is used because it is freely available, whereas the alpha-3 and numeric-3 standards are not.
国のコード：地政学的な国家または国の身元が必要な場合は、[ISO.3166.2020]で定義されているALPHA-2または2文字の国コード指定で表されます。Alpha-2表現は自由に利用可能であるため使用されますが、Alpha-3と数値3標準はそうではありません。
LDH names: Textual representations of DNS names where the labels of the domain are all "letters, digits, hyphen" labels as described by [RFC5890]. Trailing periods are optional.
LDH名：ドメインのラベルがすべて「RFC5890」で説明されているように、すべての「文字、数字、ハイフン」ラベルであるDNS名のテキスト表現。末尾期間はオプションです。
Unicode names: Textual representations of DNS names where one or more of the labels are U-labels as described by [RFC5890]. Trailing periods are optional.
Unicode Names：[RFC5890]によって記述されているように、1つ以上のラベルがUラベルであるDNS名のテキスト表現。末尾期間はオプションです。
dates and times: The syntax for values denoting dates and times is defined in [RFC3339].
日付と時間：日付と時間を示す値の構文は[RFC3339]で定義されています。
URIs: The syntax for values denoting a Uniform Resource Identifier (URI) is defined by [RFC3986].
URI：統一リソース識別子（URI）を示す値の構文は、[RFC3986]によって定義されます。
Contact information is defined using jCards as described in [RFC7095]. The "fn" member is required and MUST NOT be null according to [RFC6350]. An empty "fn" member MAY be used when the contact name does not exist or is redacted.
連絡先情報は、[RFC7095]に記載されているJCARDSを使用して定義されています。「FN」メンバーが必要で、[RFC6350]に従ってNULLでなければなりません。連絡先名が存在しないか縮小されているときに、空の「FN」メンバーを使用できます。
This section defines common data structures used in responses and object classes.
このセクションでは、応答クラスとオブジェクトクラスで使用される一般的なデータ構造を定義します。
The data structure named "rdapConformance" is an array of strings, each providing a hint as to the specifications used in the construction of the response. This data structure MUST appear in the topmost JSON object of a response and MUST NOT appear anywhere else. A response to a "help" request will include identifiers for all of the specifications supported by the server. A response to any other request will include only identifiers for the specifications used in the construction of the response. The set of returned identifiers MAY vary depending on the authorization level of the client.
"RDAPConformance"という名前のデータ構造は文字列の配列であり、それぞれは応答の構築で使用されている仕様に関してヒントを提供します。このデータ構造は、応答の最上位のJSONオブジェクトに表示されなければならず、他の場所に表示されてはいけません。「ヘルプ」要求に対する応答には、サーバーによってサポートされているすべての仕様の識別子が含まれます。他の要求に対する応答には、応答の構築で使用されている仕様の識別子のみが含まれます。返される識別子のセットは、クライアントの許可レベルによって異なる場合があります。
An example rdapConformance data structure:
RDAPConformanceデータ構造の例
"rdapConformance" : [ "rdap_level_0" ]
"RDAPConformance"：["RDAP_LEVEL_0"]
Figure 3
図3
The string literal "rdap_level_0" signifies conformance with this specification. When custom JSON values are inserted into responses, conformance to those custom specifications MUST be indicated by including a unique string literal value registered in the IANA RDAP Extensions registry specified in [RFC7480]. For example, if the fictional Registry of the Moon wants to signify that their JSON responses are conformant with their registered extensions, the string used might be "lunarNIC_level_0". These registered values aid the identification of specifications for software implementers, and failure to use them could result in slower adoption of extensions.
文字列リテラル「rdap_level_0」は、この仕様への適合を意味します。カスタムJSON値が応答に挿入されている場合は、[RFC7480]で指定されたIANA RDAP拡張レジストリに登録されている一意の文字列リテラル値を含めることで、それらのカスタム仕様への適合を示す必要があります。たとえば、月の架空のレジストリがJSON応答が登録された拡張機能に準拠していることを表している場合、使用されている文字列は "lunarnic_level_0"である可能性があります。これらの登録値は、ソフトウェア実装者の仕様の識別を支援し、それらを使用できなかったため、拡張機能が遅くなる可能性があります。
Example rdapConformance structure with custom extensions noted:
カスタム拡張機能を使用したRDAPConformance構造の例
"rdapConformance" : [ "rdap_level_0", "lunarNIC_level_0" ]
"RDAPConformance"：["rdap_level_0"、 "lunarnic_level_0"]
Figure 4
図4
The "links" array is found in data structures to signify links to other resources on the Internet. The relationship of these links is defined by the IANA registry described by [RFC8288].
「リンク」アレイは、インターネット上の他のリソースへのリンクを意味するためのデータ構造にあります。これらのリンクの関係は[RFC8288]で説明されているIANAレジストリによって定義されています。
The following is an example of the link structure:
リンク構造の例は次のとおりです。
{
"value" : "https://example.com/context_uri",
"rel" : "self",
"href" : "https://example.com/target_uri",
"hreflang" : [ "en", "ch" ],
"title" : "title",
"media" : "screen",
"type" : "application/json"
}
Figure 5
図5
The JSON name/values of "rel", "href", "hreflang", "title", "media", and "type" correspond to values found in Section 3 of [RFC8288]. The "value" JSON value is the context URI as described by [RFC8288]. The "value", "rel", and "href" JSON values MUST be specified. All other JSON values are OPTIONAL. A "related" link relation MUST NOT include an "href" URI that is the same as the "self" link relation "href" URI to reduce the risk of infinite client processing loops. Internationalized Domain Names (IDNs) returned in URIs SHOULD be consistently returned in LDH name format to allow clients to process these IDNs according to their capabilities.
"rel"、 "href"、 "hreflang"、 "title"、 "media"、 "type"のJSON名/値は、[RFC8288]のセクション3にある値に対応しています。「値」JSON値は、[RFC8288]によって説明されているコンテキストURIです。"value"、 "rel"、 "href" json値を指定する必要があります。他のすべてのJSON値はオプションです。「関連する」リンク関係は、無限のクライアント処理ループのリスクを軽減するために「自己」リンク関係「HREF」URIと同じ「HREF」URIを含んではいけません。URIで返された国際化ドメイン名（IDNS）は、クライアントがその機能に従ってこれらのIDNを処理できるように、LDH名形式で一貫して返されるべきです。
This is an example of the "links" array as it might be found in an object class:
これは、オブジェクトクラスにある場合の「リンク」配列の例です。
"links" :
[
{
"value" : "https://example.com/ip/2001:db8::123",
"rel" : "self",
"href" : "https://example.com/ip/2001:db8::123",
"type" : "application/rdap+json"
},
{
"value" : "https://example.com/ip/2001:db8::123",
"rel" : "up",
"href" : "https://example.com/ip/2001:db8::/48",
"type" : "application/rdap+json"
}
]
]
Figure 6
図6
The "notices" and "remarks" data structures take the same form. The notices structure denotes information about the service providing RDAP information and/or information about the entire response, whereas the remarks structure denotes information about the object class that contains it (see Section 5 regarding object classes).
「通知」および「備考」データ構造は同じ形式を取ります。通知構造は、RDAP情報および/または応答全体に関する情報を提供するサービスに関する情報を表しますが、備考構造はそれを含むオブジェクトクラスに関する情報を示します（オブジェクトクラスに関するセクション5を参照）。
Both are arrays of objects. Each object contains a "title" string representing the title of the object, a "type" string denoting a registered type of remark or notice (see Section 10.2.1), an array of strings named "description" for the purposes of conveying any descriptive text, and a "links" array as described in Section 4.2. The "description" array MUST be included. All other JSON values are OPTIONAL.
どちらもオブジェクトの配列です。各オブジェクトには、オブジェクトのタイトルを表す「タイトル」文字列、登録された述べのタイプを表す「タイプ」文字列（セクション10.2.1を参照）、キャビを伝える目的で「説明」という名前の文字列の配列が含まれています。説明されているテキスト、および4.2項で説明されているように、「リンク」アレイ。「説明」配列を含める必要があります。他のすべてのJSON値はオプションです。
An example of the notices data structure:
通知データ構造の例
"notices" :
[
{
"title" : "Terms of Use",
"description" :
[
"Service subject to The Registry of the Moon's TOS.",
"Copyright (c) 2020 LunarNIC"
],
"links" :
[
{
"value" : "https://example.net/entity/XXXX",
"rel" : "alternate",
"type" : "text/html",
"href" : "https://www.example.com/terms_of_use.html"
}
]
}
]
Figure 7
図7
It is the job of the clients to determine line breaks, spacing, and display issues for sentences within the character strings of the "description" array. Each string in the "description" array contains a single complete division of human-readable text indicating to clients where there are semantic breaks.
これは、「説明」アレイの文字列内の文のラインブレーク、スペース、および表示の問題を判断するのは、クライアントの仕事です。「説明」配列の各文字列には、セマンティックブレークがあるクライアントに示す人間が読めるテキストの単一の完全な分割が含まれています。
An example of the remarks data structure:
備考データ構造の例
"remarks" :
[
{
"description" :
[
"She sells sea shells down by the sea shore.",
"Originally written by Terry Sullivan."
]
}
]
Figure 8
図8
Note that objects in the "remarks" array may also have a "links" array.
「備考」アレイのオブジェクトには「リンク」アレイもあります。
While the "title" and "description" fields are intended primarily for human consumption, the "type" string contains a well-known value to be registered with IANA (see Section 10.2.1) for programmatic use.
「タイトル」フィールドと「説明」フィールドは主に人間の消費のために意図されていますが、「タイプ」文字列には、プログラム的な使用のためにIANAに登録される有名な価値があります（セクション10.2.1を参照）。
An example of the remarks data structure:
備考データ構造の例
"remarks" :
[
{
"type" : "object truncated due to authorization",
"description" :
[
"Some registration data may not have been given.",
"Use proper authorization credentials to see all of it."
]
}
]
Figure 9
図9
While the "remarks" array will appear in many object classes in a response, the "notices" array appears only in the topmost object of a response.
「備考」アレイが応答内の多くのオブジェクトクラスに表示されますが、 "NoticeS"配列は応答の一番上のオブジェクトにのみ表示されます。
This data structure consists solely of a name/value pair, where the name is "lang" and the value is a string containing a language identifier as described in [RFC5646].
このデータ構造は、名前/値のペアのみで構成されています。ここで、名前は "lang"で、値は[RFC5646]に記載されている言語識別子を含む文字列です。
"lang" : "mn-Cyrl-MN"
"Lang"： "Mn-Cyrl-Mn"
Figure 10
図10.
The "lang" attribute as defined in this section MAY appear anywhere in an object class or data structure, except for in jCard objects. vCard supports similar functionality by way of the LANGUAGE property parameter (see Section 5.1 of RFC 6350 [RFC6350]).
このセクションで定義されている "LANG"属性は、JCardオブジェクトを除いて、オブジェクトクラスまたはデータ構造内のどこにでも現れます。vCardは、言語プロパティパラメータによって類似の機能をサポートしています（RFC 6350 [RFC6350]のセクション5.1を参照）。
This data structure represents events that have occurred on an instance of an object class (see Section 5 regarding object classes).
このデータ構造は、オブジェクトクラスのインスタンスで発生したイベントを表します（オブジェクトクラスに関するセクション5を参照）。
This is an example of an "events" array.
これは「イベント」配列の例です。
"events" :
[
{
"eventAction" : "registration",
"eventActor" : "SOMEID-LUNARNIC",
"eventDate" : "1990-12-31T23:59:59Z"
},
{
"eventAction" : "last changed",
"eventActor" : "OTHERID-LUNARNIC",
"eventDate" : "1991-12-31T23:59:59Z"
}
]
Figure 11
図11.
The "events" array consists of objects, each with the following members:
「イベント」アレイは、それぞれ次のメンバーを持つオブジェクトで構成されています。
* "eventAction" -- a REQUIRED string denoting the reason for the event
* "ementAction" - イベントの理由を表す必要な文字列
* "eventActor" -- an OPTIONAL identifier denoting the actor responsible for the event
* "eventactor" - イベントを担当する俳優を示すオプションの識別子
* "eventDate" -- a REQUIRED string containing the time and date the event occurred
* "EventDate" - イベントが発生した日時を含む必要な文字列
* "links" -- OPTIONAL; see Section 4.2
Events can be future dated. One use case for future dating of events is to denote when an object expires from a registry.
イベントは未来の日付になります。イベントの将来のデートのための1つのユースケースは、オブジェクトがレジストリから有効期限が切れるのを示すことです。
The "links" array in this data structure is provided for references to the event actor. In order to reference an RDAP entity, a "rel" of "related" and a "type" of "application/rdap+json" is used in the link reference.
このデータ構造の「リンク」アレイは、イベントアクターへの参照のために提供されています。RDAPエンティティを参照するために、「関連する」の「REL」と「アプリケーション/ RDAP JSON」の「タイプ」がリンク参照で使用されます。
See Section 10.2.3 for a list of values for the "eventAction" string. See Appendix B regarding the various ways events can be modeled.
"EventAction"文字列の値のリストについては、10.2.3項を参照してください。イベントをモデル化できるさまざまな方法については付録Bを参照してください。
This data structure, named "status", is an array of strings indicating the state of a registered object (see Section 10.2.2 for a list of values).
このデータ構造は、 "status"という名前の登録オブジェクトの状態を示す文字列の配列です（値のリストについては、セクション10.2.2を参照）。
This data structure, a member named "port43", is a simple character string containing the fully qualified host name or IP address of the WHOIS [RFC3912] server where the containing object instance may be found. Note that this is not a URI, as there is no WHOIS URI scheme.
このデータ構造は、「PORT43」というメンバーで、包含オブジェクトインスタンスが見つかる可能性があるWhois [RFC3912]サーバーの完全修飾ホスト名またはIPアドレスを含む単純な文字列です。WHOIS URIスキームがないので、これはURIではありません。
This data structure maps a public identifier to an object class. It is named "publicIds" and is an array of objects, with each object containing the following REQUIRED members:
このデータ構造は、パブリック識別子をオブジェクトクラスにマッピングします。これは "Purnids"という名前で、オブジェクトの配列です。各オブジェクトは、次の要件メンバーを含むものです。
* type -- a string denoting the type of public identifier
* type - パブリック識別子の種類を示す文字列
* identifier -- a string denoting a public identifier of the type related to "type"
* 識別子 - 「タイプ」に関連する型の公開識別子を示す文字列
The following is an example of a publicIds structure.
以下は、PIXPID構造の一例です。
"publicIds":
[
{
"type":"IANA Registrar ID",
"identifier":"1"
}
]
Figure 12
図12
This data structure, a member named "objectClassName", gives the object class name of a particular object as a string. This identifies the type of object being processed. An objectClassName is REQUIRED in all RDAP response objects so that the type of the object can be interpreted.
このデータ構造は、 "objectclassname"という名前のメンバーで、特定のオブジェクトのオブジェクトクラス名を文字列として指定します。これにより、処理中のオブジェクトの種類が識別されます。オブジェクトの種類が解釈されることができるように、すべてのRDAP応答オブジェクトにObjectClassNameが必要です。
This is an example response with both rdapConformance and notices embedded:
これはRDAPConformanceとNoticeS埋め込みの両方の応答例です。
{
"rdapConformance" :
[
"rdap_level_0"
],
"notices" :
[
{
"title" : "Content Removed",
"description" :
[
"Without full authorization, content has been removed.",
"Sorry, dude!"
],
"links" :
[
{
"value" : "https://example.net/ip/192.0.2.0/24",
"rel" : "alternate",
"type" : "text/html",
"href" : "https://www.example.com/redaction_policy.html"
}
]
}
],
"lang" : "en",
"objectClassName" : "ip network",
"startAddress" : "192.0.2.0",
"endAddress" : "192.0.2.255",
"handle" : "XXXX-RIR",
"ipVersion" : "v4",
"name": "NET-RTR-1",
"parentHandle" : "YYYY-RIR",
"remarks" :
[
{
"description" :
[
"She sells sea shells down by the sea shore.",
"Originally written by Terry Sullivan."
]
}
]
}
Figure 13
図13.
Object classes represent structures appropriate for a response from the queries specified in [RFC9082].
オブジェクトクラスは、[RFC9082]で指定されたクエリからの応答に適した構造を表します。
Each object class contains a "links" array as specified in Section 4.2. For every object class instance in a response, whether the object class instance is directly representing the response to a query or is embedded in other object class instances or is an item in a search result set, servers SHOULD provide a link representing a URI for that object class instance using the "self" relationship as described in the IANA registry specified by [RFC8288]. As explained in Section 5.2, this may be not always be possible for nameserver data. Clients MUST be able to process object instances without a self link. When present, clients can use the self link for caching data. Servers MAY provide more than one self link for any given object instance. Failure to provide any self link by a server may result in clients being unable to cache object class instances.
各オブジェクトクラスには、セクション4.2で指定されているように「リンク」配列が含まれています。応答内のすべてのオブジェクトクラスインスタンスに対して、オブジェクトクラスインスタンスがクエリへの応答を直接表現しているか、他のオブジェクトクラスインスタンスに埋め込まれているか、検索結果セット内の項目である場合は、サーバーはそのためのURIを表すリンクを提供する必要があります。[RFC8288]で指定されたIANAレジストリに記載されているように、「自己」の関係を使用したオブジェクトクラスインスタンス。セクション5.2で説明したように、これはネームサーバーデータに対して必ずしも可能ではありません。クライアントは、セルフリンクなしでオブジェクトインスタンスを処理できる必要があります。存在する場合、クライアントはデータをキャッシュするためにセルフリンクを使用できます。サーバーは、特定のオブジェクトインスタンスに対して複数のセルフリンクを提供することがあります。サーバーによるセルフリンクを提供しなかった場合、クライアントはオブジェクトクラスインスタンスをキャッシュできません。
Clients using self links for caching SHOULD NOT cache any object class instances where the authority of the self link is different than the authority of the server returning the data. Failing to do so might result in cache poisoning.
キャッシングのためのセルフリンクを使用するクライアントは、セルフリンクの権限がデータを返すサーバーの権限とは異なるオブジェクトクラスインスタンスをキャッシュしないでください。その結果、キャッシュ中毒になる可能性があります。
Self links MUST contain a "type" element containing the "application/ rdap+json" media type when referencing RDAP object instances as defined by this document.
セルフリンクには、このドキュメントで定義されているRDAPオブジェクトインスタンスを参照するときに、 "Application / RDAP JSON"メディアタイプを含む "Type"要素が含まれている必要があります。
This is an example of the "links" array with a self link to an object class:
これは、オブジェクトクラスへのセルフリンクを持つ "Links"配列の例です。
"links" :
[
{
"value" : "https://example.com/ip/2001:db8::123",
"rel" : "self",
"href" : "https://example.com/ip/2001:db8::123",
"type" : "application/rdap+json"
}
]
Figure 14
図14
The entity object class appears throughout this document and is an appropriate response for the /entity/XXXX query defined in "Registration Data Access Protocol (RDAP) Query Format" [RFC9082]. This object class represents the information of organizations, corporations, governments, non-profits, clubs, individual persons, and informal groups of people. All of these representations are so similar that it is best to represent them in JSON [RFC8259] with one construct, the entity object class, to aid in the reuse of code by implementers.
エンティティオブジェクトクラスはこのドキュメント全体に表示され、「登録データアクセスプロトコル（RDAP）クエリフォーマット」[RFC9082]で定義されている/ entity / xxxxクエリの適切な応答です。このオブジェクトクラスは、組織、企業、政府、利益、クラブ、個々の人物、そして非公式の人々の情報を表しています。これらの表現はすべて、実装者によるコードの再利用を助けるために、JSON [RFC8259]でそれらをJSON [RFC8259]で表現することが最善です。
The entity object class uses jCard [RFC7095] to represent contact information, such as postal addresses, email addresses, phone numbers and names of organizations and individuals. Many of the types of information that can be represented with jCard have little or no use in RDAP, such as birthdays, anniversaries, and gender.
エンティティオブジェクトクラスは、郵便アドレス、電子メールアドレス、電話番号、組織の名前などの連絡先情報を表すためにJCARD [RFC7095]を使用します。JCardで表現できる情報の種類の多くは、誕生日、記念日、および性別などのRDAPではほとんどまたはまったく使用されていません。
The entity object is served by both RIRs and DNRs. The following is an example of an entity that might be served by an RIR.
エンティティオブジェクトは、RIRSとDNRの両方によって提供されます。以下は、RIRによって提供される可能性があるエンティティの例です。
{
"objectClassName" : "entity",
"handle":"XXXX",
"vcardArray":[
"vcard",
[
["version", {}, "text", "4.0"],
["fn", {}, "text", "Joe User"],
["n", {}, "text",
["User", "Joe", "", "", ["ing. jr", "M.Sc."]]
],
["kind", {}, "text", "individual"],
["lang", {
"pref":"1"
}, "language-tag", "fr"],
["lang", {
"pref":"2"
}, "language-tag", "en"],
["org", {
"type":"work"
}, "text", "Example"],
["title", {}, "text", "Research Scientist"],
["role", {}, "text", "Project Lead"],
["adr",
{ "type":"work" },
"text",
[
"",
"Suite 1234",
"4321 Rue Somewhere",
"Quebec",
"QC",
"G1V 2M2",
"Canada"
]
],
["adr",
{
"type":"home",
"label":"123 Maple Ave\nSuite 90001\nVancouver\nBC\n1239\n"
},
"text",
[
"", "", "", "", "", "", ""
]
],
["tel",
{
"type":["work", "voice"],
"pref":"1"
},
"uri",
"tel:+1-555-555-1234;ext=102"
],
["tel",
{ "type":["work", "cell", "voice", "video", "text"] },
"uri",
"tel:+1-555-555-4321"
],
["email",
{ "type":"work" },
"text",
"joe.user@example.com"
],
["geo", {
"type":"work"
}, "uri", "geo:46.772673,-71.282945"],
["key",
{ "type":"work" },
"uri",
"https://www.example.com/joe.user/joe.asc"
],
["tz", {},
"utc-offset", "-05:00"],
["url", { "type":"home" },
"uri", "https://example.org"]
]
],
"roles":[ "registrar" ],
"publicIds":[
{
"type":"IANA Registrar ID",
"identifier":"1"
}
],
"remarks":[
{
"description":[
"She sells sea shells down by the sea shore.",
"Originally written by Terry Sullivan."
]
}
],
"links":[
{
"value":"https://example.com/entity/XXXX",
"rel":"self",
"href":"https://example.com/entity/XXXX",
"type" : "application/rdap+json"
}
],
"events":[
{
"eventAction":"registration",
"eventDate":"1990-12-31T23:59:59Z"
}
],
"asEventActor":[
{
"eventAction":"last changed",
"eventDate":"1991-12-31T23:59:59Z"
}
]
}
Figure 15
図15
The entity object class can contain the following members:
エンティティオブジェクトクラスには、次のメンバーを含めることができます。
* objectClassName -- the string "entity"
* objectClassName - 文字列 "エンティティ"
* handle -- a string representing a registry-unique identifier of the entity
* handle - エンティティのレジストリ固有の識別子を表す文字列
* vcardArray -- a jCard with the entity's contact information
* vcardarray - エンティティの連絡先情報を持つJCard
* roles -- an array of strings, each signifying the relationship an object would have with its closest containing object (see Section 10.2.4 for a list of values)
* roles - 各文字列の配列、それぞれがオブジェクトの最も近いオブジェクトを含む関係を持つことになります（値のリストについては、セクション10.2.4を参照）。
* publicIds -- see Section 4.8
* PIXID - セクション4.8を参照してください
* entities -- an array of entity objects as defined by this section
* エンティティ - このセクションで定義されているエンティティオブジェクトの配列
* remarks -- see Section 4.3
* 備考 - セクション4.3を参照してください
* links -- see Section 4.2
* リンク - セクション4.2を参照してください
* events -- see Section 4.5
* イベント - セクション4.5を参照してください
* asEventActor -- this data structure takes the same form as the events data structure (see Section 4.5), but each object in the array MUST NOT have an "eventActor" member. These objects denote that the entity is an event actor for the given events. See Appendix B regarding the various ways events can be modeled.
* ASEventActor - このデータ構造は、イベントデータ構造と同じ形式を取ります（セクション4.5を参照）、配列内の各オブジェクトは「EventActor」メンバーを持たない必要があります。これらのオブジェクトは、エンティティが与えられたイベントのイベントアクターであることを示します。イベントをモデル化できるさまざまな方法については付録Bを参照してください。
* status -- see Section 4.6
* ステータス - 4.6項を参照
* port43 -- see Section 4.7
* PORT43 - セクション4.7を参照してください
* networks -- an array of IP network objects as defined in Section 5.4
* ネットワーク - セクション5.4で定義されているIPネットワークオブジェクトの配列
* autnums -- an array of autnum objects as defined in Section 5.5
* autnums - セクション5.5で定義されているAutnumオブジェクトの配列
Entities may also have other entities embedded with them in an array. This can be used to model an organization with specific individuals fulfilling designated roles of responsibility.
エンティティは、それらに埋め込まれた他のエンティティも配列内にあるかもしれません。これは、指定された責任の役割を果たす特定の個人との組織をモデル化するために使用できます。
The following is an elided example of an entity with embedded entities.
以下は、エンティティが組み込まれているエンティティの合わせた例です。
{
"objectClassName" : "entity",
"handle" : "ANENTITY",
"roles" : [ "registrar" ],
...
"entities" :
[
{
"objectClassName" : "entity",
"handle": "ANEMBEDDEDENTITY",
"roles" : [ "technical" ],
...
},
...
],
...
}
Figure 16
図16.
The following is an example of an entity that might be served by a DNR.
以下は、DNRによって提供される可能性があるエンティティの例です。
{
"objectClassName" : "entity",
"handle":"XXXX",
"vcardArray":[
"vcard",
[
["version", {}, "text", "4.0"],
["fn", {}, "text", "Joe User"],
["kind", {}, "text", "individual"],
["lang", {
"pref":"1"
}, "language-tag", "fr"],
["lang", {
"pref":"2"
}, "language-tag", "en"],
["org", {
"type":"work"
}, "text", "Example"],
["title", {}, "text", "Research Scientist"],
["role", {}, "text", "Project Lead"],
["adr",
{ "type":"work" },
"text",
[
"",
"Suite 1234",
"4321 Rue Somewhere",
"Quebec",
"QC",
"G1V 2M2",
"Canada"
]
],
["tel",
{ "type":["work", "voice"], "pref":"1" },
"uri", "tel:+1-555-555-1234;ext=102"
],
["email",
{ "type":"work" },
"text", "joe.user@example.com"
]
]
],
"status":[ "validated", "locked" ],
"remarks":[
{
"description":[
"She sells sea shells down by the sea shore.",
"Originally written by Terry Sullivan."
]
}
],
"links":[
{
"value":"https://example.com/entity/XXXX",
"rel":"self",
"href":"https://example.com/entity/XXXX",
"type":"application/rdap+json"
}
],
"port43":"whois.example.net",
"events":[
{
"eventAction":"registration",
"eventDate":"1990-12-31T23:59:59Z"
},
{
"eventAction":"last changed",
"eventDate":"1991-12-31T23:59:59Z",
"eventActor":"joe@example.com"
}
]
}
Figure 17
図17
See Appendix A for use of the entity object class to model various types of entities found in both RIRs and DNRs. See Appendix C regarding structured vs. unstructured postal addresses in entities.
RIRSとDNRの両方で見つかったさまざまな種類のエンティティをモデル化するためのエンティティオブジェクトクラスの使用については、付録Aを参照してください。エンティティの構造化されていない郵便アドレスに関する付録Cを参照してください。
The nameserver object class represents information regarding DNS nameservers used in both forward and reverse DNS. RIRs and some DNRs register or expose nameserver information as an attribute of a domain name, while other DNRs model nameservers as "first class objects". Please note that some of the examples in this section include lines that have been wrapped for reading clarity.
NameServerオブジェクトクラスは、順方向DNSと逆方向DNの両方で使用されているDNSネームサーバーに関する情報を表します。RIRSとDNRSは、ドメイン名の属性としてネームサーバー情報を登録または公開しますが、その他のDNRSモデルネームサーバーは「ファーストクラスオブジェクト」として。このセクションの例のいくつかは、明確さを読み取るために包まれた行を含みます。
The nameserver object class accommodates both models and degrees of variation in between.
ネームサーバオブジェクトクラスは、その間のモデルと変動度の両方を収容します。
The following is an example of a nameserver object.
以下は、ネームサーバオブジェクトの例です。
{
"objectClassName" : "nameserver",
"handle" : "XXXX",
"ldhName" : "ns1.xn--fo-5ja.example",
"unicodeName" : "ns.fóo.example",
"status" : [ "active" ],
"ipAddresses" :
{
"v4": [ "192.0.2.1", "192.0.2.2" ],
"v6": [ "2001:db8::123" ]
},
"remarks" :
[
{
"description" :
[
"She sells sea shells down by the sea shore.",
"Originally written by Terry Sullivan."
]
}
],
"links" :
[
{
"value" : "https://example.net/nameserver/
ns1.xn--fo-5ja.example",
"rel" : "self",
"href" : "https://example.net/nameserver/
ns1.xn--fo-5ja.example",
"type" : "application/rdap+json"
}
],
"port43" : "whois.example.net",
"events" :
[
{
"eventAction" : "registration",
"eventDate" : "1990-12-31T23:59:59Z"
},
{
"eventAction" : "last changed",
"eventDate" : "1991-12-31T23:59:59Z",
"eventActor" : "joe@example.com"
}
]
}
Figure 18
図18
Figure 18 is an example of a nameserver object with all appropriate values given. Registries using a first-class nameserver data model would embed this in domain objects as well as allowing references to it with the "/nameserver" query type (all depending on the registry operators policy). Other registries may pare back the information as needed. Figure 19 is an example of a nameserver object as would be found in RIRs and some DNRs, while Figure 20 is an example of a nameserver object as would be found in other DNRs.
図18は、与えられたすべての適切な値を持つネームサーバーオブジェクトの例です。ファーストクラスのネームサーバデータモデルを使用しているレジストリは、ドメインオブジェクトにこれを埋め込み、「/ nameserver」クエリの種類（レジストリ演算子ポリシーによっては常に）を参照することを可能にします。他のレジストリは、必要に応じて情報を避けてもよい。図19は、RIRSおよびDNRに見られるようにネームサーバオブジェクトの例であり、図20は他のDNRに見られるようにネームサーバオブジェクトの例である。
The following is an example of the simplest nameserver object:
以下は、最も簡単なNameServerオブジェクトの例です。
{
"objectClassName" : "nameserver",
"ldhName" : "ns1.example.com"
}
Figure 19
図19
The following is an example of a simple nameserver object that might be commonly used by DNRs:
以下は、DNRSによって一般的に使用される可能性がある単純なネームサーバーオブジェクトの例です。
{
"objectClassName" : "nameserver",
"ldhName" : "ns1.example.com",
"ipAddresses" : { "v6" : [ "2001:db8::123", "2001:db8::124" ] }
}
Figure 20
図20
As nameservers can be modeled by some registries to be first-class objects, they may also have an array of entities (Section 5.1) embedded to signify parties responsible for the maintenance, registrations, etc., of the nameservers.
ネームサーバーは一部のレジストリで最初のクラスのオブジェクトになるようにモデル化できるため、ネームサーバーのメンテナンス、登録などに責任がある締約国を示すために、埋め込まれたエンティティ（セクション5.1）の配列を埋め込むこともできます。
The following is an elided example of a nameserver with embedded entities.
以下は、エンティティが組み込まれたネームサーバーのとなりの例です。
{
"objectClassName" : "nameserver",
"handle" : "XXXX",
"ldhName" : "ns.xn--fo-5ja.example",
...
"entities" :
[
...
],
...
}
Figure 21
図21.
The nameserver object class can contain the following members:
Nameserverオブジェクトクラスには、次のメンバーを含めることができます。
* objectClassName -- the string "nameserver"
* objectClassName - 文字列 "nameserver"
* handle -- a string representing a registry-unique identifier of the nameserver
* handle - ネームサーバーのレジストリ固有の識別子を表す文字列
* ldhName -- a string containing the LDH name of the nameserver (see Section 3)
* ldhname - ネームサーバーのLDH名を含む文字列（セクション3を参照）
* unicodeName -- a string containing a DNS Unicode name of the nameserver (see Section 3)
* UnicoDename - ネームサーバのDNS Unicode名を含む文字列（セクション3を参照）
* ipAddresses -- an object containing the following members:
* ipaddresses - 次のメンバーを含むオブジェクト：
- v6 -- an array of strings containing IPv6 addresses of the nameserver
- v6 - ネームサーバーのIPv6アドレスを含む文字列の配列
- v4 -- an array of strings containing IPv4 addresses of the nameserver
- v4 - ネームサーバーのIPv4アドレスを含む文字列の配列
* entities -- an array of entity objects as defined by Section 5.1
* エンティティ - セクション5.1で定義されているエンティティオブジェクトの配列
* status -- see Section 4.6
* ステータス - 4.6項を参照
* remarks -- see Section 4.3
* 備考 - セクション4.3を参照してください
* links -- see Section 4.2
* リンク - セクション4.2を参照してください
* port43 -- see Section 4.7
* PORT43 - セクション4.7を参照してください
* events -- see Section 4.5
* イベント - セクション4.5を参照してください
The domain object class represents a DNS name and point of delegation. For RIRs, these delegation points are in the reverse DNS tree, whereas for DNRs, these delegation points are in the forward DNS tree.
ドメインオブジェクトクラスは、DNS名と委任点を表します。RIRSの場合、これらの委任ポイントは逆DNSツリーにありますが、DNRSの場合、これらの委任ポイントは順DNSツリーにあります。
In both cases, the high-level structure of the domain object class consists of information about the domain registration, nameserver information related to the domain name, and entities related to the domain name (e.g., registrant information, contacts, etc.).
どちらの場合も、ドメインオブジェクトクラスの高レベル構造は、ドメイン登録、ドメイン名に関連するネームサーバー情報、およびドメイン名（例えば、登録者情報、連絡先など）に関する情報で構成されています。
The following is an elided example of the domain object showing the high-level structure:
以下は、ハイレベルの構造を示すドメインオブジェクトの共合い例です。
{
"objectClassName" : "domain",
"handle" : "XXX",
"ldhName" : "blah.example.com",
...
"nameservers" :
[
...
],
...
"entities" :
[
...
]
}
Figure 22
図22
The domain object class can contain the following members:
ドメインオブジェクトクラスには、次のメンバーを含めることができます。
* objectClassName -- the string "domain"
* objectClassName - 文字列 "ドメイン"
* handle -- a string representing a registry-unique identifier of the domain object instance
* handle - ドメインオブジェクトインスタンスのレジストリ一意の識別子を表す文字列
* ldhName -- a string describing a domain name in LDH form as described in Section 3
* ldhname - セクション3の説明に従って、LDHフォームにドメイン名を記述する文字列
* unicodeName -- a string containing a domain name with U-labels as described in Section 3
* UnicoDeName - セクション3の説明に従って、Uラベルを持つドメイン名を含む文字列
* variants -- an array of objects, each containing the following values:
* variants - オブジェクトの配列、それぞれは次の値を含みます。
- relation -- an array of strings, with each string denoting the relationship between the variants and the containing domain object (see Section 10.2.5 for a list of suggested variant relations).
- 関係 - 各文字列は、バリアントと含有ドメインオブジェクトとの間の関係を示す文字列の配列（推奨されるバリアント関係のリストについては、セクション10.2.5を参照）。
- idnTable -- the character string literal that represents the Internationalized Domain Name (IDN) table that has been registered in the IANA Repository of IDN Practices [IANA_IDNTABLES].
- idntable - IDNプラクティスのIANAリポジトリに登録されている国際化されたドメイン名（IDN）テーブルを表す文字列リテラル。[IANA_IDNTABLES]。
- variantNames -- an array of objects, with each object containing an "ldhName" member and a "unicodeName" member (see Section 3).
- VARIANTNAMES - オブジェクトの配列、各オブジェクトは "LDHNAME"メンバーと "UnicoDename"メンバーを含むものです（セクション3を参照）。
* nameservers -- an array of nameserver objects as defined by Section 5.2
* NameServers - セクション5.2で定義されているネームサーバーオブジェクトの配列
* secureDNS -- an object with the following members:
* securedns - 次のメンバーを持つオブジェクト：
- zoneSigned -- boolean true if the zone has been signed, false otherwise.
- Zonesigned - ゾーンが署名されている場合はtrue、そうでない場合はfalse。
- delegationSigned -- boolean true if there are DS records in the parent, false otherwise.
- delegationsigned - 親にDSレコードがある場合はtrue、それ以外の場合はfalseです。
- maxSigLife -- an integer representing the signature lifetime in seconds to be used when creating the RRSIG DS record in the parent zone [RFC5910].
- MAXSIGLIFE - 親ゾーン[RFC5910]でRRSIG DSレコードを作成するときに使用される秒単位で署名の有効期間を表す整数。
- dsData -- an array of objects, each with the following members:
- DSDATA - オブジェクトの配列、それぞれ次のメンバーを使用しています。
o keyTag -- an integer as specified by the key tag field of a DNS DS record as specified by [RFC4034] in presentation format
o keytag - プレゼンテーション形式の[RFC4034]で指定されたDNS DSレコードの鍵タグフィールドで指定された整数
o algorithm -- an integer as specified by the algorithm field of a DNS DS record as described by RFC 4034 in presentation format
o アルゴリズム - PresentationフォーマットのRFC 4034で説明されているDNS DSレコードのアルゴリズムフィールドで指定された整数
o digest -- a string as specified by the digest field of a DNS DS record as specified by RFC 4034 in presentation format
o Digest - Presentation FormatのRFC 4034で指定されているDNS DSレコードのダイジェストフィールドで指定された文字列
o digestType -- an integer as specified by the digest type field of a DNS DS record as specified by RFC 4034 in presentation format
o DigestType - Presentation FormatのRFC 4034で指定されているDNS DSレコードのダイジェスト・タイプフィールドで指定された整数
o events -- see Section 4.5
o イベント - セクション4.5を参照してください
o links -- see Section 4.2
o リンク - セクション4.2を参照してください
- keyData -- an array of objects, each with the following members:
- keydata - オブジェクトの配列、それぞれ次のメンバーを持つ。
o flags -- an integer representing the flags field value in the DNSKEY record [RFC4034] in presentation format
o flags - PresentationフォーマットのDNSKeyレコード[RFC4034]のFlagsフィールド値を表す整数
o protocol -- an integer representation of the protocol field value of the DNSKEY record [RFC4034] in presentation format
o プロトコル - PresentationフォーマットのDNSKEYレコード[RFC4034]のプロトコルフィールド値の整数表現
o publicKey -- a string representation of the public key in the DNSKEY record [RFC4034] in presentation format
o publickey - PresentationフォーマットのDNSKEYレコード[RFC4034]の公開鍵の文字列表現
o algorithm -- an integer as specified by the algorithm field of a DNSKEY record as specified by [RFC4034] in presentation format
o アルゴリズム - Presentation Formatの[RFC4034]で指定されたDNSKEYレコードのアルゴリズムフィールドで指定された整数
o events -- see Section 4.5
o イベント - セクション4.5を参照してください
o links -- see Section 4.2
o リンク - セクション4.2を参照してください
See Appendix D for background information on these objects.
これらのオブジェクトの背景情報については付録Dを参照してください。
* entities -- an array of entity objects as defined by Section 5.1
* エンティティ - セクション5.1で定義されているエンティティオブジェクトの配列
* status -- see Section 4.6
* ステータス - 4.6項を参照
* publicIds -- see Section 4.8
* PIXID - セクション4.8を参照してください
* remarks -- see Section 4.3
* 備考 - セクション4.3を参照してください
* links -- see Section 4.2
* リンク - セクション4.2を参照してください
* port43 -- see Section 4.7
* PORT43 - セクション4.7を参照してください
* events -- see Section 4.5
* イベント - セクション4.5を参照してください
* network -- represents the IP network for which a reverse DNS domain is referenced; see Section 5.4
* ネットワーク - 逆DNSドメインが参照されているIPネットワークを表します。セクション5.4を参照してください
The following is an example of a JSON domain object representing a reverse DNS delegation point that might be served by an RIR (note that the dsData digest value has been modified to fit on one line).
以下は、RIRによってサービス提供される可能性がある逆DNS委任ポイントを表すJSONドメインオブジェクトの例です（DSDATAダイジェスト値は1行に収まるように変更されています）。
{
"objectClassName" : "domain",
"handle" : "XXXX",
"ldhName" : "0.2.192.in-addr.arpa",
"nameservers" :
[
{
"objectClassName" : "nameserver",
"ldhName" : "ns1.rir.example"
},
{
"objectClassName" : "nameserver",
"ldhName" : "ns2.rir.example"
}
],
"secureDNS":
{
"delegationSigned": true,
"dsData":
[
{
"keyTag": 25345,
"algorithm": 8,
"digestType": 2,
"digest": "2788970E18EA14...C890C85B8205B94"
}
]
},
"remarks" :
[
{
"description" :
[
"She sells sea shells down by the sea shore.",
"Originally written by Terry Sullivan."
]
}
],
"links" :
[
{
"value": "https://example.net/domain/0.2.192.in-addr.arpa",
"rel" : "self",
"href" : "https://example.net/domain/0.2.192.in-addr.arpa",
"type" : "application/rdap+json"
}
],
"events" :
[
{
"eventAction" : "registration",
"eventDate" : "1990-12-31T23:59:59Z"
},
{
"eventAction" : "last changed",
"eventDate" : "1991-12-31T23:59:59Z",
"eventActor" : "joe@example.com"
}
],
"entities" :
[
{
"objectClassName" : "entity",
"handle" : "XXXX",
"vcardArray":[
"vcard",
[
["version", {}, "text", "4.0"],
["fn", {}, "text", "Joe User"],
["kind", {}, "text", "individual"],
["lang", {
"pref":"1"
}, "language-tag", "fr"],
["lang", {
"pref":"2"
}, "language-tag", "en"],
["org", {
"type":"work"
}, "text", "Example"],
["title", {}, "text", "Research Scientist"],
["role", {}, "text", "Project Lead"],
["adr",
{ "type":"work" },
"text",
[
"",
"Suite 1234",
"4321 Rue Somewhere",
"Quebec",
"QC",
"G1V 2M2",
"Canada"
]
],
["tel",
{ "type":["work", "voice"], "pref":"1" },
"uri", "tel:+1-555-555-1234;ext=102"
],
["email",
{ "type":"work" },
"text", "joe.user@example.com"
]
]
],
"roles" : [ "registrant" ],
"remarks" :
[
{
"description" :
[
"She sells sea shells down by the sea shore.",
"Originally written by Terry Sullivan."
]
}
],
"links" :
[
{
"value": "https://example.net/entity/XXXX",
"rel" : "self",
"href" : "https://example.net/entity/XXXX",
"type" : "application/rdap+json"
}
],
"events" :
[
{
"eventAction" : "registration",
"eventDate" : "1990-12-31T23:59:59Z"
},
{
"eventAction" : "last changed",
"eventDate" : "1991-12-31T23:59:59Z",
"eventActor" : "joe@example.com"
}
]
}
],
"network" :
{
"objectClassName" : "ip network",
"handle" : "XXXX-RIR",
"startAddress" : "192.0.2.0",
"endAddress" : "192.0.2.255",
"ipVersion" : "v4",
"name": "NET-RTR-1",
"type" : "DIRECT ALLOCATION",
"country" : "AU",
"parentHandle" : "YYYY-RIR",
"status" : [ "active" ]
}
}
Figure 23
図23
The following is an example of a JSON domain object representing a forward DNS delegation point that might be served by a DNR. Note that the secureDNS keyData publicKey value has been modified to fit on a single line.
以下は、DNRによって提供される可能性がある順方向DNS委任ポイントを表すJSONドメインオブジェクトの例です。SecuredNS KeyData PublicKey値は1行に収まるように変更されました。
{
"objectClassName" : "domain",
"handle" : "XXXX",
"ldhName" : "xn--fo-5ja.example",
"unicodeName" : "fóo.example",
"variants" :
[
{
"relation" : [ "registered", "conjoined" ],
"variantNames" :
[
{
"ldhName" : "xn--fo-cka.example",
"unicodeName" : "fõo.example"
},
{
"ldhName" : "xn--fo-fka.example",
"unicodeName" : "föo.example"
}
]
},
{
"relation" : [ "unregistered", "registration restricted" ],
"idnTable": ".EXAMPLE Swedish",
"variantNames" :
[
{
"ldhName": "xn--fo-8ja.example",
"unicodeName" : "fôo.example"
}
]
}
],
"status" : [ "locked", "transfer prohibited" ],
"publicIds":[
{
"type":"ENS_Auth ID",
"identifier":"1234567890"
}
],
"nameservers" :
[
{
"objectClassName" : "nameserver",
"handle" : "XXXX",
"ldhName" : "ns1.example.com",
"status" : [ "active" ],
"ipAddresses" :
{
"v6": [ "2001:db8::123", "2001:db8::124" ],
"v4": [ "192.0.2.1", "192.0.2.2" ]
},
"remarks" :
[
{
"description" :
[
"She sells sea shells down by the sea shore.",
"Originally written by Terry Sullivan."
]
}
],
"links" :
[
{
"value" : "https://example.net/nameserver/ns1.example.com",
"rel" : "self",
"href" : "https://example.net/nameserver/ns1.example.com",
"type" : "application/rdap+json"
}
],
"events" :
[
{
"eventAction" : "registration",
"eventDate" : "1990-12-31T23:59:59Z"
},
{
"eventAction" : "last changed",
"eventDate" : "1991-12-31T23:59:59Z"
}
]
},
{
"objectClassName" : "nameserver",
"handle" : "XXXX",
"ldhName" : "ns2.example.com",
"status" : [ "active" ],
"ipAddresses" :
{
"v6" : [ "2001:db8::125", "2001:db8::126" ],
"v4" : [ "192.0.2.3", "192.0.2.4" ]
},
"remarks" :
[
{
"description" :
[
"She sells sea shells down by the sea shore.",
"Originally written by Terry Sullivan."
]
}
],
"links" :
[
{
"value" : "https://example.net/nameserver/ns2.example.com",
"rel" : "self",
"href" : "https://example.net/nameserver/ns2.example.com",
"type" : "application/rdap+json"
}
],
"events" :
[
{
"eventAction" : "registration",
"eventDate" : "1990-12-31T23:59:59Z"
},
{
"eventAction" : "last changed",
"eventDate" : "1991-12-31T23:59:59Z"
}
]
}
],
"secureDNS":
{
"zoneSigned": true,
"delegationSigned": true,
"maxSigLife": 604800,
"keyData":
[
{
"flags": 257,
"protocol": 3,
"algorithm": 8,
"publicKey": "AwEAAa6eDzronzjEDbT...Jg1M5N rBSPkuXpdFE=",
"events":
[
{
"eventAction": "last changed",
"eventDate": "2012-07-23T05:15:47Z"
}
]
}
]
},
"remarks" :
[
{
"description" :
[
"She sells sea shells down by the sea shore.",
"Originally written by Terry Sullivan."
]
}
],
"links" :
[
{
"value": "https://example.net/domain/xn--fo-5ja.example",
"rel" : "self",
"href" : "https://example.net/domain/xn--fo-5ja.example",
"type" : "application/rdap+json"
}
],
"port43" : "whois.example.net",
"events" :
[
{
"eventAction" : "registration",
"eventDate" : "1990-12-31T23:59:59Z"
},
{
"eventAction" : "last changed",
"eventDate" : "1991-12-31T23:59:59Z",
"eventActor" : "joe@example.com"
},
{
"eventAction" : "transfer",
"eventDate" : "1991-12-31T23:59:59Z",
"eventActor" : "joe@example.com"
},
{
"eventAction" : "expiration",
"eventDate" : "2016-12-31T23:59:59Z",
"eventActor" : "joe@example.com"
}
],
"entities" :
[
{
"objectClassName" : "entity",
"handle" : "XXXX",
"vcardArray":[
"vcard",
[
["version", {}, "text", "4.0"],
["fn", {}, "text", "Joe User"],
["kind", {}, "text", "individual"],
["lang", {
"pref":"1"
}, "language-tag", "fr"],
["lang", {
"pref":"2"
}, "language-tag", "en"],
["org", {
"type":"work"
}, "text", "Example"],
["title", {}, "text", "Research Scientist"],
["role", {}, "text", "Project Lead"],
["adr",
{ "type":"work" },
"text",
[
"",
"Suite 1234",
"4321 Rue Somewhere",
"Quebec",
"QC",
"G1V 2M2",
"Canada"
]
],
["tel",
{ "type":["work", "voice"], "pref":"1" },
"uri", "tel:+1-555-555-1234;ext=102"
],
["email",
{ "type":"work" },
"text", "joe.user@example.com"
]
]
],
"status" : [ "validated", "locked" ],
"roles" : [ "registrant" ],
"remarks" :
[
{
"description" :
[
"She sells sea shells down by the sea shore.",
"Originally written by Terry Sullivan."
]
}
],
"links" :
[
{
"value" : "https://example.net/entity/XXXX",
"rel" : "self",
"href" : "https://example.net/entity/XXXX",
"type" : "application/rdap+json"
}
],
"events" :
[
{
"eventAction" : "registration",
"eventDate" : "1990-12-31T23:59:59Z"
},
{
"eventAction" : "last changed",
"eventDate" : "1991-12-31T23:59:59Z"
}
]
}
]
}
Figure 24
図24.
The IP network object class models IP network registrations found in RIRs and is the expected response for the "/ip" query as defined by [RFC9082]. There is no equivalent object class for DNRs. The high-level structure of the IP network object class consists of information about the network registration and entities related to the IP network (e.g., registrant information, contacts, etc.).
IPネットワークオブジェクトクラスは、RIRSにあるIPネットワーク登録をモデル化し、[RFC9082]で定義されている「/ IP」クエリに対する予想される応答です。DNRの同等のオブジェクトクラスはありません。IPネットワークオブジェクトクラスの高レベル構造は、IPネットワークに関連するネットワーク登録とエンティティに関する情報（例えば、登録者情報、連絡先など）で構成されています。
The following is an elided example of the IP network object type showing the high-level structure:
以下は、ハイレベルの構造を示すIPネットワークオブジェクトタイプの合計例です。
{
"objectClassName" : "ip network",
"handle" : "XXX",
...
"entities" :
[
...
]
}
Figure 25
図25
The following is an example of the JSON object for the network registration information.
以下は、ネットワーク登録情報用のJSONオブジェクトの一例である。
{
"objectClassName" : "ip network",
"handle" : "XXXX-RIR",
"startAddress" : "2001:db8::",
"endAddress" : "2001:db8:0:ffff:ffff:ffff:ffff:ffff",
"ipVersion" : "v6",
"name": "NET-RTR-1",
"type" : "DIRECT ALLOCATION",
"country" : "AU",
"parentHandle" : "YYYY-RIR",
"status" : [ "active" ],
"remarks" :
[
{
"description" :
[
"She sells sea shells down by the sea shore.",
"Originally written by Terry Sullivan."
]
}
],
"links" :
[
{
"value" : "https://example.net/ip/2001:db8::/48",
"rel" : "self",
"href" : "https://example.net/ip/2001:db8::/48",
"type" : "application/rdap+json"
},
{
"value" : "https://example.net/ip/2001:db8::/48",
"rel" : "up",
"href" : "https://example.net/ip/2001:db8::/32",
"type" : "application/rdap+json"
}
],
"events" :
[
{
"eventAction" : "registration",
"eventDate" : "1990-12-31T23:59:59Z"
},
{
"eventAction" : "last changed",
"eventDate" : "1991-12-31T23:59:59Z"
}
],
"entities" :
[
{
"objectClassName" : "entity",
"handle" : "XXXX",
"vcardArray":[
"vcard",
[
["version", {}, "text", "4.0"],
["fn", {}, "text", "Joe User"],
["kind", {}, "text", "individual"],
["lang", {
"pref":"1"
}, "language-tag", "fr"],
["lang", {
"pref":"2"
}, "language-tag", "en"],
["org", {
"type":"work"
}, "text", "Example"],
["title", {}, "text", "Research Scientist"],
["role", {}, "text", "Project Lead"],
["adr",
{ "type":"work" },
"text",
[
"",
"Suite 1234",
"4321 Rue Somewhere",
"Quebec",
"QC",
"G1V 2M2",
"Canada"
]
],
["tel",
{ "type":["work", "voice"], "pref":"1" },
"uri", "tel:+1-555-555-1234;ext=102"
],
["email",
{ "type":"work" },
"text", "joe.user@example.com"
]
]
],
"roles" : [ "registrant" ],
"remarks" :
[
{
"description" :
[
"She sells sea shells down by the sea shore.",
"Originally written by Terry Sullivan."
]
}
],
"links" :
[
{
"value" : "https://example.net/entity/xxxx",
"rel" : "self",
"href" : "https://example.net/entity/xxxx",
"type" : "application/rdap+json"
}
],
"events" :
[
{
"eventAction" : "registration",
"eventDate" : "1990-12-31T23:59:59Z"
},
{
"eventAction" : "last changed",
"eventDate" : "1991-12-31T23:59:59Z"
}
]
}
]
}
Figure 26
図26.
The IP network object class can contain the following members:
IPネットワークオブジェクトクラスには、次のメンバーを含めることができます。
* objectClassName -- the string "ip network"
* objectClassName - 文字列 "IPネットワーク"
* handle -- a string representing the RIR-unique identifier of the network registration
* ハンドル - ネットワーク登録のRIR固有の識別子を表す文字列
* startAddress -- a string representing the starting IP address of the network, either IPv4 or IPv6
* startAddress - ネットワークの開始IPアドレスを表す文字列、IPv4またはIPv6
* endAddress -- a string representing the ending IP address of the network, either IPv4 or IPv6
* endAddress - ネットワークの終了IPアドレスを表す文字列、IPv4またはIPv6
* ipVersion -- a string signifying the IP protocol version of the network: "v4" signifies an IPv4 network, and "v6" signifies an IPv6 network
* ipversion - ネットワークのIPプロトコルバージョンを示す文字列： "v4"はIPv4ネットワークを意味し、 "v6"はIPv6ネットワークを意味します
* name -- a string representing an identifier assigned to the network registration by the registration holder
* name - 登録ホルダーによるネットワーク登録に割り当てられている識別子を表す文字列
* type -- a string containing an RIR-specific classification of the network per that RIR's registration model
* 型 - そのRIRの登録モデルごとのネットワークのRIR固有の分類を含む文字列
* country -- a string containing the two-character country code of the network
* 国 - ネットワークの2文字の国コードを含む文字列
* parentHandle -- a string containing an RIR-unique identifier of the parent network of this network registration
* ParentHandle - このネットワーク登録の親ネットワークのRIR固有の識別子を含む文字列
* status -- an array of strings indicating the state of the IP network as defined by Section 4.6
* status - セクション4.6で定義されているIPネットワークの状態を示す文字列の配列
* entities -- an array of entity objects as defined by Section 5.1
* エンティティ - セクション5.1で定義されているエンティティオブジェクトの配列
* remarks -- see Section 4.3
* 備考 - セクション4.3を参照してください
* links -- see Section 4.2
* リンク - セクション4.2を参照してください
* port43 -- see Section 4.7
* PORT43 - セクション4.7を参照してください
* events -- see Section 4.5
* イベント - セクション4.5を参照してください
The Autonomous System number (autnum) object class models Autonomous System number registrations found in RIRs and represents the expected response to an "/autnum" query as defined by [RFC9082]. There is no equivalent object class for DNRs. The high-level structure of the autnum object class consists of information about the Autonomous System number registration and entities related to the autnum registration (e.g., registrant information, contacts, etc.) and is similar to the IP network object class.
自律システム番号（autnum）オブジェクトクラスは、RIRSで見つかった自律型システム番号登録をモデル化し、[RFC9082]で定義されている「/ autnum」クエリに対する予想される応答を表します。DNRの同等のオブジェクトクラスはありません。AutNUMオブジェクトクラスの高レベル構造は、自律型システム登録に関する情報と、AUTNNUM登録に関連するエンティティ（例えば、登録者情報、連絡先など）とIPネットワークオブジェクトクラスと似ています。
The following is an example of a JSON object representing an autnum.
以下は、AUTNUMを表すJSONオブジェクトの例です。
{
"objectClassName" : "autnum",
"handle" : "XXXX-RIR",
"startAutnum" : 65536,
"endAutnum" : 65541,
"name": "AS-RTR-1",
"type" : "DIRECT ALLOCATION",
"status" : [ "active" ],
"country": "AU",
"remarks" :
[
{
"description" :
[
"She sells sea shells down by the sea shore.",
"Originally written by Terry Sullivan."
]
}
],
"links" :
[
{
"value" : "https://example.net/autnum/65537",
"rel" : "self",
"href" : "https://example.net/autnum/65537",
"type" : "application/rdap+json"
}
],
"events" :
[
{
"eventAction" : "registration",
"eventDate" : "1990-12-31T23:59:59Z"
},
{
"eventAction" : "last changed",
"eventDate" : "1991-12-31T23:59:59Z"
}
],
"entities" :
[
{
"objectClassName" : "entity",
"handle" : "XXXX",
"vcardArray":[
"vcard",
[
["version", {}, "text", "4.0"],
["fn", {}, "text", "Joe User"],
["kind", {}, "text", "individual"],
["lang", {
"pref":"1"
}, "language-tag", "fr"],
["lang", {
"pref":"2"
}, "language-tag", "en"],
["org", {
"type":"work"
}, "text", "Example"],
["title", {}, "text", "Research Scientist"],
["role", {}, "text", "Project Lead"],
["adr",
{ "type":"work" },
"text",
[
"",
"Suite 1234",
"4321 Rue Somewhere",
"Quebec",
"QC",
"G1V 2M2",
"Canada"
]
],
["tel",
{ "type":["work", "voice"], "pref":"1" },
"uri", "tel:+1-555-555-1234;ext=102"
],
["email",
{ "type":"work" },
"text", "joe.user@example.com"
]
]
],
"roles" : [ "registrant" ],
"remarks" :
[
{
"description" :
[
"She sells sea shells down by the sea shore.",
"Originally written by Terry Sullivan."
]
}
],
"links" :
[
{
"value" : "https://example.net/entity/XXXX",
"rel" : "self",
"href" : "https://example.net/entity/XXXX",
"type" : "application/rdap+json"
}
],
"events" :
[
{
"eventAction" : "registration",
"eventDate" : "1990-12-31T23:59:59Z"
},
{
"eventAction" : "last changed",
"eventDate" : "1991-12-31T23:59:59Z"
}
]
}
]
}
Figure 27
図27.
The Autonomous System number object class can contain the following members:
自律システム番号オブジェクトクラスには、次のメンバーを含めることができます。
* objectClassName -- the string "autnum"
* オブジェクトクラス名 - 文字列 "秋"
* handle -- a string representing the RIR-unique identifier of the autnum registration
* ハンドル - Autnum登録のRIR固有識別子を表す文字列
* startAutnum -- an unsigned 32-bit integer representing the starting number [RFC5396] in the block of Autonomous System numbers
* StartAutnum - 自律システム番号のブロック内の開始番号[RFC5396]を表す符号なし32ビット整数
* endAutnum -- an unsigned 32-bit integer representing the ending number [RFC5396] in the block of Autonomous System numbers
* Endautnum - 自律システム番号のブロック内の終了番号[RFC5396]を表す符号なし32ビット整数
* name -- a string representing an identifier assigned to the autnum registration by the registration holder
* name - 登録ホルダーによるAutnum登録に割り当てられている識別子を表す文字列
* type -- a string containing an RIR-specific classification of the autnum per that RIR's registration model
* type - そのRIRの登録モデルに対するAUTNNUMのRIR固有の分類を含む文字列
* status -- an array of strings indicating the state of the autnum as defined by Section 4.6
* status - セクション4.6で定義されているAUTNNUMの状態を示す文字列の配列
* country -- a string containing the two-character country code of the autnum
* 国 - 秋の2文字の国コードを含む文字列
* entities -- an array of entity objects as defined by Section 5.1
* エンティティ - セクション5.1で定義されているエンティティオブジェクトの配列
* remarks -- see Section 4.3
* 備考 - セクション4.3を参照してください
* links -- see Section 4.2
* リンク - セクション4.2を参照してください
* port43 -- see Section 4.7
* PORT43 - セクション4.7を参照してください
* events -- see Section 4.5
* イベント - セクション4.5を参照してください
Some non-answer responses MAY return entity bodies with information that could be more descriptive.
いくつかの非回答の回答は、より記述的な情報でエンティティ本体を返すかもしれません。
The basic structure of that response is an object class containing a REQUIRED error code number (corresponding to the HTTP response code) followed by an OPTIONAL string named "title" and an OPTIONAL array of strings named "description".
その応答の基本構造は、必要なエラーコード番号（HTTP応答コードに対応）とそれに続く「TITLE」という名前のオプションの文字列と「説明」という名前の文字列の配列を含むオブジェクトクラスです。
This is an example of the common response body.
これは一般的な応答体の一例です。
{
"errorCode": 418,
"title": "Your Beverage Choice is Not Available",
"description":
[
"I know coffee has more ummppphhh.",
"Sorry, dude!"
]
}
Figure 28
図28.
This is an example of the common response body with an rdapConformance and notices data structures:
これは、RDAPコンフォートと通知データ構造を持つ共通レスポンスボディの例です。
{
"rdapConformance" :
[
"rdap_level_0"
],
"notices" :
[
{
"title" : "Beverage Policy",
"description" :
[
"Beverages with caffeine for keeping horses awake."
],
"links" :
[
{
"value" : "https://example.net/ip/192.0.2.0/24",
"rel" : "alternate",
"type" : "text/html",
"href" : "https://www.example.com/redaction_policy.html"
}
]
}
],
"lang" : "en",
"errorCode": 418,
"title": "Your beverage choice is not available",
"description":
[
"I know coffee has more ummppphhh.",
"Sorry, dude!"
]
}
Figure 29
図29
The appropriate response to /help queries as defined by [RFC9082] is to use the notices structure as defined in Section 4.3.
[RFC9082]で定義されている/ヘルプクエリに対する適切な応答は、セクション4.3で定義されている通知構造を使用することです。
This is an example of a response to a /help query including the rdapConformance data structure.
これは、RDAPConformanceデータ構造を含むA /ヘルプクエリに対する応答の例です。
{
"rdapConformance" :
[
"rdap_level_0"
],
"notices" :
[
{
"title" : "Authentication Policy",
"description" :
[
"Access to sensitive data for users with proper credentials."
],
"links" :
[
{
"value" : "https://example.net/help",
"rel" : "alternate",
"type" : "text/html",
"href" : "https://www.example.com/auth_policy.html"
}
]
}
]
}
Figure 30
図30
[RFC9082] specifies three types of searches: domains, nameservers, and entities. Responses to these searches take the form of an array of object instances where each instance is an appropriate object class for the search (i.e., a search for /domains yields an array of domain object instances). These arrays are contained within the response object.
[RFC9082]ドメイン、ネームサーバー、エンティティの3種類の検索を指定します。これらの検索に対する応答は、各インスタンスが検索の適切なオブジェクトクラスであるオブジェクトインスタンスの配列の形式を取ります（すなわち、検索/ドメインはドメインオブジェクトインスタンスの配列をもたらします）。これらの配列は応答オブジェクト内に含まれています。
The names of the arrays are as follows:
配列の名前は次のとおりです。
* for /domains searches, the array is "domainSearchResults"
* /ドメインの検索は、配列は "DomainesearchResults"です。
* for /nameservers searches, the array is "nameserverSearchResults"
* / NameServersの検索では、配列は "NameServerSearchResults"です。
* for /entities searches, the array is "entitySearchResults"
* /エンティティの検索の検索、配列は "EntitySearchResults"です。
The following is an elided example of a response to a /domains search.
以下は、A / Domains検索に対する応答の合計例です。
{
"rdapConformance" :
[
"rdap_level_0"
],
...
"domainSearchResults" :
[
{
"objectClassName" : "domain",
"handle" : "1-XXXX",
"ldhName" : "1.example.com",
...
},
{
"objectClassName" : "domain",
"handle" : "2-XXXX",
"ldhName" : "2.example.com",
...
}
]
}
Figure 31
図31
In cases where the data of a response needs to be limited or parts of the data need to be omitted, the response is considered "truncated". A truncated response is still valid JSON, but some of the results in a search set or some of the data in an object are not provided by the server. A server may indicate this by including a typed notice in the response object.
応答のデータが制限される必要がある場合、またはデータの一部を省略する必要がある場合は、「切り捨て」と見なされます。切り捨てられた応答はまだ有効なJSONですが、検索セットまたはオブジェクト内の一部のデータの中にはサーバーによって提供されていません。サーバーは、応答オブジェクト内の型付き通知を含めることによってこれを示すことがあります。
The following is an elided example of a search response that has been truncated.
以下は、切り捨てられた検索応答の分解された例です。
{
"rdapConformance" :
[
"rdap_level_0"
],
"notices" :
[
{
"title" : "Search Policy",
"type" : "result set truncated due to authorization",
"description" :
[
"Search results are limited to 25 per day per querying IP."
],
"links" :
[
{
"value" : "https://example.net/help",
"rel" : "alternate",
"type" : "text/html",
"href" : "https://www.example.com/search_policy.html"
}
]
}
],
"domainSearchResults" :
[
...
]
}
Figure 32
図32
A similar technique can be used with a typed remark where a single object has been returned and data in that object has been truncated. Such an example might be an entity object with only a partial set of the IP networks associated with it.
単一のオブジェクトが返され、そのオブジェクトが切り捨てられたタイプの備考と同様の技術を使用できます。そのような例は、それに関連するIPネットワークの部分的なセットのみを持つエンティティオブジェクトであり得る。
The following is an elided example of an entity truncated data.
以下は、エンティティ切り捨てられたデータの分解された例である。
{
"objectClassName" : "entity",
"handle" : "ANENTITY",
"roles" : [ "registrant" ],
...
"entities" :
[
{
"objectClassName" : "entity",
"handle": "ANEMBEDDEDENTITY",
"roles" : [ "technical" ],
...
},
...
],
"networks" :
[
...
],
...
"remarks" :
[
{
"title" : "Data Policy",
"type" : "object truncated due to unexplainable reason",
"description" :
[
"Some of the data in this object has been removed."
],
"links" :
[
{
"value" : "https://example.net/help",
"rel" : "alternate",
"type" : "text/html",
"href" : "https://www.example.com/data_policy.html"
}
]
}
]
}
Figure 33
図33
IANA has updated the description of the "transfer" event action as described in Section 10.2.3.
IANAは、10.2.3項の説明に従って「転送」イベント動作の説明を更新しました。
IANA has updated the media type registration as described below.
IANAは以下のようにメディアタイプの登録を更新しました。
This specification registers the "application/rdap+json" media type.
この仕様は、「アプリケーション/ RDAP JSON」メディアタイプを登録します。
Type name: application
タイプ名：アプリケーション
Subtype name: rdap+json
サブタイプ名：RDAP JSON.
Required parameters: n/a
必要なパラメータ：N / A.
Encoding considerations: See Section 3.1 of [RFC6839].
エンコードに関する考慮事項：[RFC6839]のセクション3.1を参照してください。
Security considerations: The media represented by this identifier does not have security considerations beyond that found in Section 12 of [RFC8259].
セキュリティ上の考慮事項：この識別子によって表されるメディアには、[RFC8259]のセクション12で見つかったセキュリティ上の考慮事項はありません。
Interoperability considerations: There are no known interoperability problems regarding this media format.
相互運用性の考慮事項：このメディアフォーマットに関して既知の相互運用性の問題はありません。
Published specification: RFC 9083
公開仕様：RFC 9083
Applications that use this media type: Implementations of the Registration Data Access Protocol (RDAP).
このメディアタイプを使用するアプリケーション登録データアクセスプロトコル（RDAP）の実装。
Additional information: This media type is a product of the IETF REGEXT Working Group. The REGEXT charter, information on the REGEXT mailing list, and other documents produced by the REGEXT Working Group can be found at https://datatracker.ietf.org/wg/ regext/.
追加情報：このメディアタイプは、IETF正規XTワーキンググループの製品です。Regext憲章、Regextメーリングリストの情報、およびRegextワーキンググループによって生成されたその他の文書は、https://datatracker.ietf.org/wg/ regext /にあります。
Person & email address to contact for further information:
IESG <iesg@ietf.org>
Intended usage: COMMON
意図された使用法：一般的な
Restrictions on usage: none
使用制限：なし
Author: Andy Newton
著者：アンディニュートン
Change controller: IETF
変更コントローラ：IETF.
Provisional Registration: No
暫定登録：いいえ
IANA has created a category in the protocol registries labeled "Registration Data Access Protocol (RDAP)", and within that category, IANA has established a URL-referenceable, stand-alone registry labeled "RDAP JSON Values". This new registry is for use in the notices and remarks (Section 4.3), status (Section 4.6), role (Section 5.1), event action (Section 4.5), and domain variant relation (Section 5.3) fields specified in RDAP.
IANAは、「登録データアクセスプロトコル（RDAP）」と表示されているプロトコルレジストリにカテゴリを作成し、そのカテゴリ内では、IANAが「RDAP JSON値」というラベルの付いたURL参照可能なスタンドアロンレジストリを確立しました。この新しいレジストリは、通知と備考（4.3節）、「ステータス（4.6節）」、「イベントアクション（セクション4.5）」、およびRDAPで指定されたドメインバリアントリレーション（セクション5.5）、およびドメインバリアントリレーション（セクション5.5）。
Each entry in the registry contains the following fields:
レジストリ内の各エントリには、次のフィールドが含まれています。
1. Value -- the string value being registered.
1. value - 登録されている文字列値。
2. Type -- the type of value being registered. It should be one of the following:
2. type - 登録されている値の種類。それは次のいずれかです。
* "notice or remark type" -- denotes a type of notice or remark.
* 「通知または備考タイプ」 - 通知の種類や発言を表します。
* "status" -- denotes a value for the "status" object member as defined by Section 4.6.
* "status" - セクション4.6で定義されている「ステータス」オブジェクトメンバーの値を表します。
* "role" -- denotes a value for the "role" array as defined in Section 5.1.
* "role" - セクション5.1で定義されている「役割」配列の値を表します。
* "event action" -- denotes a value for an event action as defined in Section 4.5.
* "イベントアクション" - セクション4.5で定義されているイベントアクションの値を表します。
* "domain variant relation" -- denotes a relationship between a domain and a domain variant as defined in Section 5.3.
* 「ドメインバリアントリレーション」 - セクション5.3で定義されているドメインとドメインバリアントとの間の関係を表します。
3. Description -- a one- or two-sentence description regarding the meaning of the value, how it might be used, and/or how it should be interpreted by clients.
3. 説明 - 値の意味、使用方法、および/またはクライアントによってどのように解釈されるべきかに関する1つまたは2文の説明。
4. Registrant Name -- the name of the person registering the value.
4. 登録者名 - 値を登録する人の名前。
5. Registrant Contact Information -- an email address, postal address, or some other information to be used to contact the registrant.
5. 登録者連絡先情報 - 電子メールアドレス、郵便アドレス、または登録者に連絡するために使用されるその他の情報。
This registry is operated under the "Expert Review" policy defined in [RFC8126].
このレジストリは、[RFC8126]で定義されている「エキスパートレビュー」ポリシーで運営されています。
Review of registrations into this registry by the designated expert(s) should be narrowly judged on the following criteria:
指定された専門家による登録簿の見直しは、以下の基準で狭く判断されるべきである。
1. Values in need of being placed into multiple types must be assigned a separate registration for each type.
1. 複数のタイプに配置されている必要がある値は、各タイプに対して別々の登録を割り当てる必要があります。
2. Values must be strings. They should be multiple words separated by single space characters. Every character should be lowercased. If possible, every word should be given in English and each character should be US-ASCII.
2. 値は文字列でなければなりません。それらは単一のスペース文字で区切られた複数の単語であるべきです。すべての文字は下げられるべきです。可能であれば、すべての単語は英語で与えられ、各文字はUSCIIであるべきです。
3. Registrations should not duplicate the meaning of any existing registration. That is, if a request for a registration is significantly similar in nature to an existing registration, the request should be denied. For example, the terms "maintainer" and "registrant" are significantly similar in nature as they both denote a holder of a domain name or Internet number resource. In cases where it may be reasonably argued that machine interpretation of two similar values may alter the operation of client software, designated experts should not judge the values to be of significant similarity.
3. 登録は、既存の登録の意味を複製しないでください。つまり、登録の要求が既存の登録と既存の登録と著しく似ている場合は、要求を拒否する必要があります。例えば、「メンテナ」および「登録者」という用語は、それらが両方ともドメイン名またはインターネット番号リソースのホルダを示すので、本質的に著しく類似している。2つの同様の値の機械解釈がクライアントソフトウェアの操作を変更してもよく、指定された専門家が重大な類似性であることを判断するべきではない場合がある。
4. Registrations should be relevant to the common usages of RDAP. Designated experts may rely upon the serving of the value by a DNR or RIR to make this determination.
4. 登録はRDAPの一般的な使用法に関連する必要があります。指定された専門家は、この決定を下すためにDNRまたはRIRによる価値の役割に頼ることができる。
The following sections provide initial registrations into this registry.
次のセクションでは、このレジストリへの最初の登録を提供します。
The following values have been registered in the "RDAP JSON Values" registry:
次の値が "RDAP JSON値"レジストリに登録されています。
Value: result set truncated due to authorization Type: notice and remark type Description: The list of results does not contain all results due to lack of authorization. This may indicate to some clients that proper authorization will yield a longer result set. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：承認タイプのために結果セットが切り捨てられました。これは、適切な承認が長い結果セットを生成するクライアントには、一部のクライアントに表示されることがあります。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: result set truncated due to excessive load Type: notice and remark type Description: The list of results does not contain all results due to an excessively heavy load on the server. This may indicate to some clients that requerying at a later time will yield a longer result set. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：ロードタイプの過度のロードタイプのために結果セットが切り捨てられました。これは、後で再要因するクライアントには、より長い結果セットが生成されることを示している可能性があります。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: result set truncated due to unexplainable reasons Type: notice and remark type Description: The list of results does not contain all results for an unexplainable reason. This may indicate to some clients that requerying for any reason will not yield a longer result set. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：原因不可能な理由で結果セットが切り捨てられた結果：通知と備考タイプの説明：結果のリストは、説明不可能な理由ですべての結果を含まない。これは、何らかの理由でレコーティングが長い結果セットを生成しないようにする一部のクライアントに示すことがあります。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: object truncated due to authorization Type: notice and remark type Description: The object does not contain all data due to lack of authorization. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：許可タイプのために切り捨てられたオブジェクト：通知と備考タイプ説明：許可がないため、オブジェクトにすべてのデータが含まれていません。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: object truncated due to excessive load Type: notice and remark type Description: The object does not contain all data due to an excessively heavy load on the server. This may indicate to some clients that requerying at a later time will yield all data of the object. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：オブジェクトは過度のロードタイプのために切り捨てられました。これは、後で再要因がオブジェクトのすべてのデータを生み出すクライアントには、一部のクライアントに示している可能性があります。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: object truncated due to unexplainable reasons Type: notice and remark type Description: The object does not contain all data for an unexplainable reason. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：原因不可能な理由のために切り捨てられたオブジェクト：注意と備考タイプの説明：オブジェクトには、説明不可能な理由ですべてのデータが含まれていません。登録者名：IESG登録者連絡先情報：iesg@ietf.org
The following values have been registered in the "RDAP JSON Values" registry:
次の値が "RDAP JSON値"レジストリに登録されています。
Value: validated Type: status Description: Signifies that the data of the object instance has been found to be accurate. This type of status is usually found on entity object instances to note the validity of identifying contact information. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：検証済みタイプ：ステータス説明：オブジェクトインスタンスのデータが正確であることが判明したことを意味します。このタイプのステータスは通常、識別連絡先情報の妥当性に注意するためにEntityオブジェクトインスタンスにあります。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: renew prohibited Type: status Description: Renewal or reregistration of the object instance is forbidden. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：禁止タイプ：ステータス説明：オブジェクトインスタンスの更新または再登録は禁止されています。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: update prohibited Type: status Description: Updates to the object instance are forbidden. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：更新禁止タイプ：ステータス説明：オブジェクトインスタンスへの更新は禁止されています。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: transfer prohibited Type: status Description: Transfers of the registration from one registrar to another are forbidden. This type of status normally applies to DNR domain names. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：転送禁止タイプ：ステータス説明：あるレジストラから別のレジストラへの登録の転送は禁止されています。このタイプのステータスは通常、DNRドメイン名に適用されます。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: delete prohibited Type: status Description: Deletion of the registration of the object instance is forbidden. This type of status normally applies to DNR domain names. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：禁止タイプを削除：ステータス説明：オブジェクトインスタンスの登録の削除は禁止されています。このタイプのステータスは通常、DNRドメイン名に適用されます。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: proxy Type: status Description: The registration of the object instance has been performed by a third party. This is most commonly applied to entities. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：プロキシタイプ：ステータス説明：オブジェクトインスタンスの登録は、第三者によって実行されました。これは最も一般的にエンティティに適用されます。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: private Type: status Description: The information of the object instance is not designated for public consumption. This is most commonly applied to entities. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：プライベートタイプ：ステータス説明：オブジェクトインスタンスの情報は、公衆消費のために指定されていません。これは最も一般的にエンティティに適用されます。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: removed Type: status Description: Some of the information of the object instance has not been made available and has been removed. This is most commonly applied to entities. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：削除タイプ：ステータス説明：オブジェクトインスタンスの情報の一部は利用可能で、削除されました。これは最も一般的にエンティティに適用されます。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: obscured Type: status Description: Some of the information of the object instance has been altered for the purposes of not readily revealing the actual information of the object instance. This is most commonly applied to entities. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：曖昧な型：ステータス説明：オブジェクトインスタンスの実際の情報を容易に明らかにしない目的で、オブジェクトインスタンスの情報の一部が変更されました。これは最も一般的にエンティティに適用されます。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: associated Type: status Description: The object instance is associated with other object instances in the registry. This is most commonly used to signify that a nameserver is associated with a domain or that an entity is associated with a network resource or domain. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：関連付けられたタイプ：ステータス説明：オブジェクトインスタンスは、レジストリ内の他のオブジェクトインスタンスに関連付けられています。これは、ネームサーバーがドメインに関連付けられていること、またはエンティティがネットワークリソースまたはドメインに関連付けられていることを示すために最も一般的に使用されます。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: active Type: status Description: The object instance is in use. For domain names, it signifies that the domain name is published in DNS. For network and autnum registrations, it signifies that they are allocated or assigned for use in operational networks. This maps to the "OK" status of the Extensible Provisioning Protocol (EPP) [RFC5730]. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：アクティブタイプ：ステータス説明：オブジェクトインスタンスが使用されています。ドメイン名の場合、ドメイン名がDNSで公開されていることを意味します。ネットワーク登録とAutnum登録の場合、操作ネットワークで使用するために割り当てまたは割り当てられていることを意味します。これは拡張プロビジョニングプロトコル（EPP）[RFC5730]の「OK」ステータスにマッピングされます。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: inactive Type: status Description: The object instance is not in use. See "active". Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：非アクティブ型：ステータス説明：オブジェクトインスタンスは使用されていません。「アクティブ」を参照してください。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: locked Type: status Description: Changes to the object instance cannot be made, including the association of other object instances. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：ロックされたタイプ：ステータス説明：他のオブジェクトインスタンスの関連付けを含め、オブジェクトインスタンスへの変更はできません。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: pending create Type: status Description: A request has been received for the creation of the object instance, but this action is not yet complete. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：保留中の作成タイプ：ステータス説明：オブジェクトインスタンスを作成するために要求が受信されましたが、このアクションはまだ完了していません。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: pending renew Type: status Description: A request has been received for the renewal of the object instance, but this action is not yet complete. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：保留中の更新タイプ：ステータス説明：オブジェクトインスタンスの更新に対してリクエストが受信されましたが、このアクションはまだ完了していません。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: pending transfer Type: status Description: A request has been received for the transfer of the object instance, but this action is not yet complete. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：保留転送タイプ：ステータス説明：オブジェクトインスタンスの転送に対して要求が受信されましたが、このアクションはまだ完了していません。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: pending update Type: status Description: A request has been received for the update or modification of the object instance, but this action is not yet complete. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：保留中の更新タイプ：ステータス説明：オブジェクトインスタンスの更新または変更に対して要求が受信されましたが、このアクションはまだ完了していません。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: pending delete Type: status Description: A request has been received for the deletion or removal of the object instance, but this action is not yet complete. For domains, this might mean that the name is no longer published in DNS but has not yet been purged from the registry database. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：保留中の削除タイプ：ステータス説明：オブジェクトインスタンスの削除または削除に対してリクエストが受信されましたが、このアクションはまだ完了していません。ドメインの場合、これは名前がDNSで公開されなくなったが、まだレジストリデータベースから消去されていないことを意味します。登録者名：IESG登録者連絡先情報：iesg@ietf.org
The following values have been registered in the "RDAP JSON Values" registry:
次の値が "RDAP JSON値"レジストリに登録されています。
Value: registration Type: event action Description: The object instance was initially registered. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：登録タイプ：イベントアクション説明：オブジェクトインスタンスが最初に登録されました。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: reregistration Type: event action Description: The object instance was registered subsequently to initial registration. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：再登録タイプ：イベントアクション説明：オブジェクトインスタンスが最初の登録に続いて登録されました。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: last changed Type: event action Description: An action noting when the information in the object instance was last changed. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：最後に変更されたタイプ：イベントの操作説明：オブジェクトインスタンス内の情報が最後に変更されたときのアクション。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: expiration Type: event action Description: The object instance has been removed or will be removed at a predetermined date and time from the registry. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：有効期限タイプ：イベントアクション説明：オブジェクトインスタンスは削除されたか、レジストリから所定の日時に削除されます。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: deletion Type: event action Description: The object instance was removed from the registry at a point in time that was not predetermined. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：削除タイプ：イベントアクション説明：オブジェクトインスタンスは、予定されていない時点でレジストリから削除されました。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: reinstantiation Type: event action Description: The object instance was reregistered after having been removed from the registry. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：REANSTANITIATION型：イベントアクション説明：オブジェクトインスタンスはレジストリから削除された後に再登録されました。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: transfer Type: event action Description: The object instance was transferred from one registrar to another. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：転送タイプ：イベントアクション説明：オブジェクトインスタンスがあるレジストラから別のレジストラに転送されました。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: locked Type: event action Description: The object instance was locked (see the "locked" status). Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：ロックされたタイプ：イベントアクション説明：オブジェクトインスタンスがロックされていました（「ロック」ステータスを参照）。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: unlocked Type: event action Description: The object instance was unlocked (see the "locked" status). Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：ロック解除されたタイプ：イベントの操作説明：オブジェクトインスタンスがロック解除されました（「ロック」ステータスを参照）。登録者名：IESG登録者連絡先情報：iesg@ietf.org
The following values have been registered in the "RDAP JSON Values" registry:
次の値が "RDAP JSON値"レジストリに登録されています。
Value: registrant Type: role Description: The entity object instance is the registrant of the registration. In some registries, this is known as a maintainer. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：登録者タイプ：ロール説明：エンティティオブジェクトインスタンスは登録の登録者です。いくつかのレジストリでは、これはメンテナとして知られています。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: technical Type: role Description: The entity object instance is a technical contact for the registration. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：テクニカルタイプ：ロール説明：エンティティオブジェクトインスタンスは登録のための技術的な連絡です。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: administrative Type: role Description: The entity object instance is an administrative contact for the registration. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：管理タイプ：役割説明：エンティティオブジェクトインスタンスは登録の管理者連絡先です。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: abuse Type: role Description: The entity object instance handles network abuse issues on behalf of the registrant of the registration. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：乱用タイプ：ロール説明：エンティティオブジェクトインスタンスは、登録の登録者に代わってネットワークの乱用の問題を処理します。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: billing Type: role Description: The entity object instance handles payment and billing issues on behalf of the registrant of the registration. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：課金タイプ：役割説明：エンティティオブジェクトインスタンスは、登録の登録者に代わって支払いと請求の問題を処理します。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: registrar Type: role Description: The entity object instance represents the authority responsible for the registration in the registry. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：レジストラの種類：ロール説明：エンティティオブジェクトインスタンスは、レジストリ内の登録の責任者を表します。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: reseller Type: role Description: The entity object instance represents a third party through which the registration was conducted (i.e., not the registry or registrar). Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：releslerの種類：ロール説明：エンティティオブジェクトインスタンスは、登録が行われた第三者（すなわち、レジストリまたはレジストラではない）を表します。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: sponsor Type: role Description: The entity object instance represents a domain policy sponsor, such as an ICANN-approved sponsor. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：スポンサータイプ：ロール説明：エンティティオブジェクトインスタンスは、ICANN承認スポンサーなどのドメインポリシースポンサーを表します。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: proxy Type: role Description: The entity object instance represents a proxy for another entity object, such as a registrant. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：プロキシタイプ：ロール説明：エンティティオブジェクトインスタンスは、登録者などの別のエンティティオブジェクトのプロキシを表します。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: notifications Type: role Description: An entity object instance designated to receive notifications about association object instances. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：通知タイプ：ロール説明：Associationオブジェクトインスタンスに関する通知を受信するように指定されたエンティティオブジェクトインスタンス。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: noc Type: role Description: The entity object instance handles communications related to a network operations center (NOC). Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：NOCタイプ：ロール説明：エンティティオブジェクトインスタンスは、ネットワークオペレーションセンター（NOC）に関連する通信を処理します。登録者名：IESG登録者連絡先情報：iesg@ietf.org
The following values have been registered in the "RDAP JSON Values" registry:
次の値が "RDAP JSON値"レジストリに登録されています。
Value: registered Type: domain variant relation Description: The variant names are registered in the registry. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：登録タイプ：ドメインバリアントリレーション説明：バリアント名はレジストリに登録されています。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: unregistered Type: domain variant relation Description: The variant names are not found in the registry. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
value：未登録タイプ：ドメインバリアントリレーション説明：バリアント名はレジストリに見つかりません。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: registration restricted Type: domain variant relation Description: Registration of the variant names is restricted to certain parties or within certain rules. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：登録制限タイプ：ドメインバリアントの関係説明：バリアント名の登録は特定の締約国または特定の規則内に制限されています。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: open registration Type: domain variant relation Description: Registration of the variant names is available to generally qualified registrants. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：オープン登録タイプ：ドメインバリアントリレーション説明：バリアント名の登録は、一般に適格登録者に利用可能です。登録者名：IESG登録者連絡先情報：iesg@ietf.org
Value: conjoined Type: domain variant relation Description: Registration of the variant names occurs automatically with the registration of the containing domain registration. Registrant Name: IESG Registrant Contact Information: iesg@ietf.org
値：結合型：ドメインバリアントリレーション説明：バリアント名の登録は、含有ドメイン登録の登録で自動的に行われます。登録者名：IESG登録者連絡先情報：iesg@ietf.org
This specification models information serialized in JSON format. As JSON is a subset of JavaScript, implementations are advised to follow the security considerations outlined in Section 12 of [RFC8259] to prevent code injection.
この仕様モデルはJSON形式でシリアル化された情報です。JSONがJavaScriptのサブセットであるため、コード注入を防ぐために[RFC8259]のセクション12で概説されているセキュリティ上の考慮事項に従うことをお勧めします。
Though not specific to JSON, RDAP implementers should be aware of the security considerations specified in [RFC7480] and the security requirements and considerations in [RFC7481].
JSONに固有のものではありませんが、RDAP実装者は[RFC7480]で指定されているセキュリティ上の考慮事項と[RFC7481]のセキュリティ要件と考慮事項を認識する必要があります。
RDAP responses allow for retrieval of DNSSEC (key) related information, but the RRSIG DS from the parent zone is not conveyed alongside it. This means that the DNSSEC keys retrieved by RDAP are disconnected from their containing PKI, and as such are not generally expected to be trusted without additional information. In particular, the HTTPS channel protecting the RDAP connection is not expected to be authorized to certify the validity of the DNSSEC keys.
RDAP応答により、DNSSEC（キー）関連情報の検索が可能ですが、親ゾーンからのRRSIG DSはそれに沿って伝えられていません。これは、RDAPによって取得されたDNSSECキーがそれらの含有PKIから切断され、そのようにそのまま信頼されるとは限らないことを意味します。特に、RDAP接続を保護するHTTPSチャネルは、DNSSECキーの有効性を証明する権限があるとは予想されません。
Clients caching data, especially clients using RDAP-specific caches (instead of HTTP-layer caches), should have safeguards to prevent cache poisoning. See Section 5 for advice on using the self links for caching.
クライアントは、データ、特にRDAP固有のキャッシュを使用しているクライアント（HTTPレイヤキャッシュの代わりに）は、キャッシュ中毒を防ぐための保護措置を持つ必要があります。キャッシングのための自己リンクの使用に関するアドバイスについては、セクション5を参照してください。
Finally, service operators should be aware of the privacy mechanisms noted in Section 13.
最後に、サービスオペレータは、セクション13に記載されているプライバシーメカニズムを認識する必要があります。
The default text encoding for JSON responses in RDAP is UTF-8 [RFC3629], and all servers and clients MUST support UTF-8.
RDAPのJSON応答のデフォルトのテキストエンコーディングはUTF-8 [RFC3629]で、すべてのサーバーとクライアントはUTF-8をサポートしている必要があります。
[RFC7480] defines the use of URIs and IRIs in RDAP.
[RFC7480] RDAPのURIとIRISの使用を定義します。
Section 4.4 defines the use of language tags in the JSON responses defined in this document.
セクション4.4は、このドキュメントで定義されているJSON応答内の言語タグの使用を定義します。
IDNs are denoted in this specification by the separation of DNS names in LDH form and Unicode form (see Section 3). Representation of IDNs in registries is described by the "variants" object in Section 5.3 and the suggested values listed in Section 10.2.5.
IDNは、LDHフォームおよびUnicodeフォームのDNS名の分離によってこの仕様で示されます（セクション3を参照）。レジストリ内のIDNの表現は、セクション5.3の「バリアント」オブジェクトと、10.2.5項に示す推奨値によって説明されています。
This specification suggests status values to denote contact and registrant information that has been marked as private and/or has been removed or obscured. See Section 10.2.2 for the complete list of status values. A few of the status values indicate that there are privacy concerns associated with the object instance. The following status codes SHOULD be used to describe data elements of a response when appropriate:
この仕様は、プライベートとしてマークされている、および/または削除された、または削除された、および/または削除された連絡先および登録者情報を示すステータス値を示しています。ステータス値の完全なリストについては、10.2.2項を参照してください。いくつかのステータス値は、オブジェクトインスタンスに関連付けられているプライバシーに関する問題があることを示しています。必要に応じて、次のステータスコードを使用して応答のデータ要素を説明する必要があります。
* private -- The object is not be shared in query responses, unless the user is authorized to view this information.
* Private - ユーザーがこの情報を表示する権限がない限り、オブジェクトはクエリ応答で共有されません。
* removed -- Data elements within the object have been collected but have been omitted from the response. This option can be used to prevent unauthorized access to associated object instances without the need to mark them as private.
* 削除 - オブジェクト内のデータ要素は収集されましたが、応答から省略されました。このオプションは、個人としてマークする必要なしに、関連するオブジェクトインスタンスへの不正アクセスを防ぐために使用できます。
* obscured -- Data elements within the object have been collected, but the response value has been altered so that values are not easily discernible. A value changed from "1212" to "XXXX" is an example of obscured data. This option may reveal privacy sensitive information and should only be used when data sensitivity does not require a more protective option like "private" or "removed".
* 隠蔽 - オブジェクト内のデータ要素が収集されましたが、応答値は変更され、値が簡単には識別できません。「1212」から「XXXX」に変更された値は、隠れたデータの例です。このオプションは、プライバシーに敏感な情報を明らかにし、データの感度が「プライベート」または「削除」のようなより保護的なオプションを必要としない場合にのみ使用できます。
See Appendix A.1 for an example of applying those values to contacts and registrants.
これらの値を連絡先および登録に適用する例については、付録A.1を参照してください。
[ISO.3166.2020] International Organization for Standardization, "Codes for the representation of names of countries and their subdivisions", Fourth edition, ISO Standard 3166, August 2020.
[ISO.3166.2020]国際標準化のための国際機関、「国の名前とその区別の表現のコード」、第4版、ISO規格3166、2020年8月。
[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>。
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002, <https://www.rfc-editor.org/info/rfc3339>.
[RFC3339] Klyne、G.およびC. NEWMAN、「インターネット上の日時：Timestamps」、RFC 3339、DOI 10.17487 / RFC3339、2002年7月、<https：//www.rfc-editor.org/info/rfc3339>。
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, DOI 10.17487/RFC3629, November 2003, <https://www.rfc-editor.org/info/rfc3629>.
[RFC3629] YERGEAU、F。、「UTF-8、ISO 10646の変換フォーマット」、STD 63、RFC 3629、DOI 10.17487 / RFC3629、2003年11月、<https：//www.rfc-editor.org/info/RFC3629>。
[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>。
[RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, DOI 10.17487/RFC4034, March 2005, <https://www.rfc-editor.org/info/rfc4034>.
[RFC4034] Arends、R.、Austein、R.、Larson、M.、Massey、D.、およびS. Rose、「DNSセキュリティ拡張のためのリソースレコード」、RFC 4034、DOI 10.17487 / RFC4034、2005年3月、<https://www.rfc-editor.org/info/rfc4034>。
[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>。
[RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC5646] Phillips、A.、ED。そして、「言語を特定するためのタグ」、BCP 47、RFC 5646、DOI 10.17487 / RFC5646、2009年9月、<https：//www.rfc-editor.org/info/rfc5646>。
[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>。
[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>。
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, DOI 10.17487/RFC7095, January 2014, <https://www.rfc-editor.org/info/rfc7095>.
[RFC7095] Kewisch、P.、 "Jcard：VCARDのJSON形式"、RFC 7095、DOI 10.17487 / RFC7095、2014年1月、<https：//www.rfc-editor.org/info/rfc7095>。
[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>。
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, <https://www.rfc-editor.org/info/rfc8126>.
[RFC8126]綿、M.、Leiba、B.およびT.Narten、「RFCSのIANAに関する考察のためのガイドライン」、BCP 26、RFC 8126、DOI 10.17487 / RFC8126、2017年6月、<HTTPS：// WWW.rfc-editor.org / info / rfc8126>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259] Bray、T.、ED。、「JavaScriptオブジェクト表記（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https：//www.rfc-editor.org/ info / rfc8259>。
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, <https://www.rfc-editor.org/info/rfc8288>.
[RFC8288]ノッティンガム、M。、「Webリンク」、RFC 8288、DOI 10.17487 / RFC8288、2017年10月、<https：//www.rfc-editor.org/info/rfc8288>。
[RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access Protocol (RDAP) Query Format", STD 95, RFC 9082, DOI 10.17487/RFC9082, June 2021, <https://www.rfc-editor.org/info/rfc9082>.
[RFC9082] Hollenbeck、S.およびA.ニュートン、「登録データアクセスプロトコル（RDAP）クエリフォーマット」、STD 95、RFC 9082、DOI 10.17487 / RFC9082、2021年6月、<https://www.rfc-editor.org/ info / rfc9082>。
[IANA_IDNTABLES] IANA, "Repository of IDN Practices", <https://www.iana.org/domains/idn-tables>.
[IANA_IDNTABLES] IANA、「IDNプラクティスのリポジトリ」、<https：//www.iana.org/domains/idn-tables>。
[JSON_ascendancy] MacVittie, L., "The Stealthy Ascendancy of JSON", April 2011, <https://devcentral.f5.com/s/articles/the-stealthy-ascendancy-of-json>.
[JSON_ASCENDANY] MacVittie、L.、「JSONのステルスの優位」、2011年4月、<https：//devcentral.f5.com/s/articles/the-stealth-ascendany-of-json>。
[JSON_performance_study] Nurseitov, N., Paulson, M., Reynolds, R., and C. Izurieta, "Comparison of JSON and XML Data Interchange Formats: A Case Study", 2009, <https://www.cs.montana.edu/izurieta/pubs/caine2009.pdf>.
[JSON_PERFORMANCE_STUDY] NurSeitov、N.、Paulson、M.、Reynolds、R.、およびC.Izureieta、「JSONとXMLデータ交換フォーマットの比較：ケーススタディ」、2009、<HTTPS：//www.cs.montana.edu / Izureieta / Pubs / Caine2009.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>。
[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>。
[RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 5910, DOI 10.17487/RFC5910, May 2010, <https://www.rfc-editor.org/info/rfc5910>.
[RFC5910] Gould、J.およびS.Hollenbeck、「ドメインネームシステム（DNS）セキュリティ拡張（EPP）」、RFC 5910、DOI 10.17487 / RFC5910、2010年5月、<https：// www。rfc-editor.org/info/rfc5910>。
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, DOI 10.17487/RFC6350, August 2011, <https://www.rfc-editor.org/info/rfc6350>.
[RFC6350] PerreAll、S.、 "VCard Format Specification"、RFC 6350、DOI 10.17487 / RFC6350、2011年8月、<https：//www.rfc-editor.org/info/rfc6350>。
[RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type Structured Syntax Suffixes", RFC 6839, DOI 10.17487/RFC6839, January 2013, <https://www.rfc-editor.org/info/rfc6839>.
[RFC6839] Hansen、T.およびA.Melnikov、「追加メディアタイプの構造化構文接尾辞」、RFC 6839、DOI 10.17487 / RFC6839、2013年1月、<https：//www.rfc-editor.org/info/rfc6839>。
This document does not provide specific object classes for registrants and contacts. Instead, the entity object class may be used to represent a registrant or contact. When the entity object is embedded inside a containing object such as a domain name or IP network, the "roles" string array can be used to signify the relationship. It is recommended that the values from Section 10.2.4 be used.
この文書は、登録者と連絡先のための特定のオブジェクトクラスを提供しません。代わりに、エンティティオブジェクトクラスは、登録者または連絡先を表すために使用されてもよい。エンティティオブジェクトがドメイン名またはIPネットワークなどの含有オブジェクト内に埋め込まれている場合は、「役割」文字列配列を使用して関係を表すことができます。セクション10.2.4からの値を使用することをお勧めします。
The following is an example of an elided containing object with an embedded entity that is both a registrant and administrative contact:
以下は、登録者と管理者連絡先の両方である組み込みエンティティを備えたELEDED含有オブジェクトの例です。
{
...
"entities" :
[
{
"objectClassName" : "entity",
"handle" : "XXXX",
"vcardArray":[
"vcard",
[
["version", {}, "text", "4.0"],
["fn", {}, "text", "Joe User"],
["kind", {}, "text", "individual"],
["lang", {
"pref":"1"
}, "language-tag", "fr"],
["lang", {
"pref":"2"
}, "language-tag", "en"],
["org", {
"type":"work"
}, "text", "Example"],
["title", {}, "text", "Research Scientist"],
["role", {}, "text", "Project Lead"],
["adr",
{ "type":"work" },
"text",
[
"",
"Suite 1234",
"4321 Rue Somewhere",
"Quebec",
"QC",
"G1V 2M2",
"Canada"
]
],
["tel",
{ "type":["work", "voice"], "pref":"1" },
"uri", "tel:+1-555-555-1234;ext=102"
],
["email",
{ "type":"work" },
"text", "joe.user@example.com"
]
]
],
"roles" : [ "registrant", "administrative" ],
"remarks" :
[
{
"description" :
[
"She sells sea shells down by the sea shore.",
"Originally written by Terry Sullivan."
]
}
],
"events" :
[
{
"eventAction" : "registration",
"eventDate" : "1990-12-31T23:59:59Z"
},
{
"eventAction" : "last changed",
"eventDate" : "1991-12-31T23:59:59Z"
}
]
}
]
}
Figure 34
図34
In many use cases, it is necessary to hide or obscure the information of a registrant or contact due to policy or other operational matters. Registries can denote these situations with "status" values (see Section 10.2.2).
多くのユースケースでは、政策またはその他の運用上の事項による登録者または連絡先の情報を隠取または不明瞭にする必要があります。レジストリは、「ステータス」の値でこれらの状況を表すことができます（セクション10.2.2を参照）。
The following is an elided example of a registrant with information changed to reflect that of a third party.
以下は、第三者のそれを反映するように情報を変更した登録者の共合例である。
{
...
"entities" :
[
{
"objectClassName" : "entity",
"handle" : "XXXX",
...
"roles" : [ "registrant", "administrative" ],
"status" : [ "proxy", "private", "obscured" ]
}
]
}
Figure 35
図35
This document does not provide a specific object class for registrars, but like registrants and contacts (see Appendix A.1), the "roles" string array maybe used. Additionally, many registrars have publicly assigned identifiers. The publicIds structure (Section 4.8) represents that information.
この文書では、レジストラ用の特定のオブジェクトクラスは提供されていませんが、登録者や連絡先と同様に、「役割」文字列配列が使用されてもよい。さらに、多くのレジストラには、公に割り当てられた識別子があります。PIXPLIDS構造体（セクション4.8）はその情報を表します。
The following is an example of an elided containing object with an embedded entity that is a registrar:
以下は、レジストラである組み込みエンティティを備えたELEDED含有オブジェクトの例です。
{
...
"entities":[
{
"objectClassName" : "entity",
"handle":"XXXX",
"vcardArray":[
"vcard",
[
["version", {}, "text", "4.0"],
["fn", {}, "text", "Joe's Fish, Chips, and Domains"],
["kind", {}, "text", "org"],
["lang", {
"pref":"1"
}, "language-tag", "fr"],
["lang", {
"pref":"2"
}, "language-tag", "en"],
["org", {
"type":"work"
}, "text", "Example"],
["adr",
{ "type":"work" },
"text",
[
"",
"Suite 1234",
"4321 Rue Somewhere",
"Quebec",
"QC",
"G1V 2M2",
"Canada"
]
],
["tel",
{
"type":["work", "voice"],
"pref":"1"
},
"uri", "tel:+1-555-555-1234;ext=102"
],
["email",
{ "type":"work" },
"text", "joes_fish_chips_and_domains@example.com"
]
]
],
"roles":[ "registrar" ],
"publicIds":[
{
"type":"IANA Registrar ID",
"identifier":"1"
}
],
"remarks":[
{
"description":[
"She sells sea shells down by the sea shore.",
"Originally written by Terry Sullivan."
]
}
],
"links":[
{
"value":"https://example.net/entity/XXXX",
"rel":"alternate",
"type":"text/html",
"href":"https://www.example.com"
}
]
}
]
}
Figure 36
図36.
Events represent actions that have taken place against a registered object at a certain date and time. Events have three properties: the action, the actor, and the date and time of the event (which is sometimes in the future). In some cases, the identity of the actor is not captured.
イベントは、特定の日時に登録されたオブジェクトに対して行われたアクションを表します。イベントには、アクション、俳優、およびイベントの日時（これは将来時々）です。場合によっては、俳優のアイデンティティは捕捉されていません。
Events can be modeled in three ways:
イベントは3つの方法でモデル化できます。
1. events with no designated actor
1. 指定された俳優のないイベント
2. events where the actor is only designated by an identifier
2. 俳優が識別子によってのみ指定されているイベント
3. events where the actor can be modeled as an entity
3. 俳優がエンティティとしてモデル化できるイベント
For the first use case, the events data structure (Section 4.5) is used without the "eventActor" object member.
最初のユースケースでは、「EventActor」オブジェクトメンバーなしでイベントデータ構造（セクション4.5）が使用されます。
This is an example of an "events" array without the "eventActor".
これは、 "EventActor"なしの "イベント"配列の例です。
"events" :
[
{
"eventAction" : "registration",
"eventDate" : "1990-12-31T23:59:59Z"
}
]
Figure 37
図37
For the second use case, the events data structure (Section 4.5) is used with the "eventActor" object member.
2回目のユースケースでは、イベントデータ構造（セクション4.5）が「EventActor」オブジェクトメンバーで使用されます。
This is an example of an "events" array with the "eventActor".
これは、 "EventActor"を持つ "イベント"配列の例です。
"events" :
[
{
"eventAction" : "registration",
"eventActor" : "XYZ-NIC",
"eventDate" : "1990-12-31T23:59:59Z"
}
]
Figure 38
図38
For the third use case, the "asEventActor" array is used when an entity (Section 5.1) is embedded into another object class. The "asEventActor" array follows the same structure as the "events" array but does not have "eventActor" attributes.
3番目のユースケースでは、エンティティ（セクション5.1）が別のオブジェクトクラスに埋め込まれている場合に使用されます。"Aseventactor"アレイは "Events"配列と同じ構造に従いますが、 "EventActor"属性はありません。
The following is an elided example of a domain object with an entity as an event actor.
以下は、イベントアクターとしてのエンティティを持つドメインオブジェクトのとなった例です。
{
"objectClassName" : "domain",
"handle" : "XXXX",
"ldhName" : "foo.example",
"status" : [ "locked", "transfer prohibited" ],
...
"entities" :
[
{
"handle" : "XXXX",
...
"asEventActor" :
[
{
"eventAction" : "last changed",
"eventDate" : "1990-12-31T23:59:59Z"
}
]
}
]
}
Figure 39
図39
The entity (Section 5.1) object class uses jCard [RFC7095] to represent contact information, including postal addresses. jCard has the ability to represent multiple language preferences, multiple email address and phone numbers, and multiple postal addresses in both a structured and unstructured format. This section describes the use of jCard for representing structured and unstructured addresses.
エンティティ（セクション5.1）オブジェクトクラスはJCARD [RFC7095]を使用して、郵便アドレスを含む連絡先情報を表します。JCardには、構造化されていない形式と非構造化フォーマットの両方で、複数の言語設定、複数の電子メールアドレス、電話番号、および複数の郵便アドレスを表す機能があります。このセクションでは、構造化アドレスと非構造化アドレスを表すJCardの使用について説明します。
The following is an example of a jCard.
以下はJCARDの例です。
{
"vcardArray":[
"vcard",
[
["version", {}, "text", "4.0"],
["fn", {}, "text", "Joe User"],
["n", {}, "text",
["User", "Joe", "", "", ["ing. jr", "M.Sc."]]
],
["kind", {}, "text", "individual"],
["lang", {
"pref":"1"
}, "language-tag", "fr"],
["lang", {
"pref":"2"
}, "language-tag", "en"],
["org", {
"type":"work"
}, "text", "Example"],
["title", {}, "text", "Research Scientist"],
["role", {}, "text", "Project Lead"],
["adr",
{ "type":"work" },
"text",
[
"",
"Suite 1234",
"4321 Rue Somewhere",
"Quebec",
"QC",
"G1V 2M2",
"Canada"
]
],
["adr",
{
"type":"home",
"label":"123 Maple Ave\nSuite 90001\nVancouver\nBC\n1239\n"
},
"text",
[
"", "", "", "", "", "", ""
]
],
["tel",
{ "type":["work", "voice"], "pref":"1" },
"uri", "tel:+1-555-555-1234;ext=102"
],
["tel",
{
"type":["work", "cell", "voice", "video", "text"]
},
"uri",
"tel:+1-555-555-1234"
],
["email",
{ "type":"work" },
"text", "joe.user@example.com"
],
["geo", {
"type":"work"
}, "uri", "geo:46.772673,-71.282945"],
["key",
{ "type":"work" },
"uri", "https://www.example.com/joe.user/joe.asc"
],
["tz", {},
"utc-offset", "-05:00"],
["url", { "type":"home" },
"uri", "https://example.org"]
]
]
}
Figure 40
図40
The arrays in Figure 40 with the first member of "adr" represent postal addresses. In the first example, the postal address is given as an array of strings and constitutes a structured address. For components of the structured address that are not applicable, an empty string is given. Each member of that array aligns with the positions of a vCard as given in [RFC6350]. In this example, the following data corresponds to the following positional meanings:
「ADR」の第1のメンバーを有する図40のアレイは郵便アドレスを表す。第1の例では、郵便番号は文字列の配列として与えられ、構造化アドレスを構成する。適用されていない構造化アドレスの構成要素については、空の文字列が表示されます。そのアレイの各メンバーは、[RFC6350]に与えられたVCardの位置と整列します。この例では、以下のデータは以下の位置決めに対応する。
1. post office box -- not applicable; empty string
1. 郵便局ボックス - 該当なし。空の文字列
2. extended address (e.g., apartment or suite number) -- Suite 1234
2. 拡張アドレス（例えば、アパートまたはスイート番号） - スイート1234
3. street address -- 4321 Rue Somewhere
3. Street Address - 4321どこかに走っています
4. locality (e.g., city) -- Quebec
4. 地域（例えば、市） - ケベック
5. region (e.g., state or province) -- QC
5. 地域（例えば、州または州） - QC
6. postal code -- G1V 2M2
6. 郵便番号 - G1V 2M2
7. country name (full name) -- Canada
7. 国名（フルネーム） - カナダ
The second example is an unstructured address. It uses the "label" attribute, which is a string containing a newline (\n) character to separate address components in an unordered, unspecified manner. Note that in this example, the structured address array is still given but that each string is an empty string.
2番目の例は非構造化アドレスです。それは "Label"属性を使用します。これは、アドレスコンポーネントを順不同で指定されていない方法で分離するための改行（\ n）文字を含む文字列です。この例では、構造化アドレス配列はまだ指定されていますが、各文字列は空の文字列です。
Section 5.3 defines the "secureDNS" member to represent secure DNS information about domain names.
セクション5.3は、ドメイン名に関するセキュアDNS情報を表す「securedns」メンバーを定義します。
DNSSEC provides data integrity for DNS through the digital signing of resource records. To enable DNSSEC, the zone is signed by one or more private keys and the signatures are stored as RRSIG records. To complete the chain of trust in the DNS zone hierarchy, a digest of each DNSKEY record (which contains the public key) must be loaded into the parent zone, stored as DS records, and signed by the parent's private key (RRSIG DS record), as indicated in "Resource Records for the DNS Security Extensions" [RFC4034]. Creating the DS records in the parent zone can be done by the registration authority "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)" [RFC5910].
DNSSECは、リソースレコードのデジタル署名を通じてDNSのデータ整合性を提供します。DNSSECを有効にするには、ゾーンは1つ以上の秘密鍵によって署名され、署名はRRSIGレコードとして保存されます。DNS Zone階層内の信頼チェーンを完成させるには、各DNSKEYレコードのダイジェスト（パブリックキーを含む）をDSレコードとして保存し、親の秘密鍵（RRSIG DSレコード）によって署名する必要があります。、「DNSセキュリティ拡張のリソースレコード」で示されているように[RFC4034]。親ゾーン内のDSレコードを作成することは、拡張可能プロビジョニングプロトコル（EPP）の[RFC5910]のための登録局の「ドメイン名システム（DNS）セキュリティ拡張マッピング」によって行うことができます。
Only DS-related information is provided by RDAP, since other information is not generally stored in the registration database. Other DNSSEC-related information can be retrieved with other DNS tools such as dig.
他の情報は一般に登録データベースに格納されていないため、DS関連情報のみがRDAPによって提供されます。他のDNSSEC関連の情報は、DIGなどの他のDNSツールで検索できます。
The domain object class (Section 5.3) can represent this information using either the "dsData" or "keyData" object arrays. Client implementers should be aware that some registries do not collect or do not publish all of the secure DNS meta-information.
ドメインオブジェクトクラス（セクション5.3）は、 "DSDATA"オブジェクトアレイのいずれかを使用してこの情報を表すことができます。クライアント実装者は、一部のレジストリがセキュアDNSメタ情報をすべて収集したり、公開したりしないことに注意してください。
This section addresses a common question regarding the use of JSON over other data formats, most notably XML.
このセクションでは、他のデータフォーマット、最も注目に値するXMLよりもJSONの使用に関する一般的な質問です。
It is often pointed out that many DNRs and one RIR support the EPP [RFC5730] standard, which is an XML serialized protocol. The logic is that since EPP is a common protocol in the industry, it follows that XML would be a more natural choice. While EPP does influence this specification quite a bit, EPP serves a different purpose, which is the provisioning of Internet resources between registries and accredited registrars and serving a much narrower audience than that envisioned for RDAP.
多くのDNRと1つのRIRがEPP [RFC5730]規格をサポートしていることを指摘しており、これはXMLシリアル化プロトコルです。論理は、EPPが業界で一般的なプロトコルであるため、XMLがより自然な選択になることになります。EPPはこの仕様にかなりのビットに影響を与えますが、EPPはレジストリと認定レジストラとの間のインターネットリソースのプロビジョニングであり、RDAPの想定されているよりもはるかに狭い視聴者を提供しています。
By contrast, RDAP has a broader audience and is designed for public consumption of data. Experience from RIRs with first generation RESTful web services for WHOIS indicate that a large percentage of clients operate within browsers and other platforms where full-blown XML stacks are not readily available and where JSON is a better fit.
対照的に、RDAPはより広い視聴者を有し、データの公衆消費のために設計されています。whoisの最初の世代のRESTFUL Webサービスを使用したRIRSからの経験は、大量のクライアントがブラウザや他のプラットフォームで機能し、フルブローXMLスタックが容易に利用できる他のプラットフォームで、JSONが適していることを示しています。
Additionally, while EPP is used in much of the DNR community it is not a universal constant in that industry. And finally, EPP's use of XML predates the specification of JSON. If EPP had been defined today, it may very well have used JSON instead of XML.
さらに、EPPはDNRコミュニティの多くで使用されていますが、その業界では普遍的な定数ではありません。そして最後に、EPPのXMLの使用はJSONの仕様を述べています。EPPが今日定義されていたら、XMLの代わりにJSONを非常によく使用している可能性があります。
Beyond the specific DNR and RIR communities, the trend in the broader Internet industry is also switching to JSON over XML, especially in the area of RESTful web services (see [JSON_ascendancy]). Studies have also found that JSON is generally less bulky and consequently faster to parse (see [JSON_performance_study]).
特定のDNRとRIRコミュニティを超えて、より広いインターネット業界の傾向は、特にRESTful Webサービスの分野で、XML上でJSONに切り替えられています（[JSON_ASCENDANCY]を参照）。研究はまた、JSONが一般的にかさばり、その結果解析が速くなることを見出した（[JSON_PERFORMANCE_STUDY]を参照）。
* Addressed known errata.
* 既知の正誤表を扱った。
* Updated references to 7482 to RFC 9082. Adjusted case of "xxxx" used in examples where "XXXX" was previously used, and removed an "X" from "XXXXX". Changed IPv6 address example using "C00" to "c00". Added "a string representing" to the definitions of startAddress and endAddress. Removed "entity" from "Autonomous System Number Entity Object Class". Added "an unsigned 32-bit integer" to the definition of startAutnum and endAutnum. Added "a string representing" to the definition of name in the IP network and ASN object classes. Clarified rdapConformance identifier registration expectations in Section 4.1. Changed "lunarNic_level_0" to "lunarNIC_level_0".
* 7482からRFC 9082への参照を更新しました。「xxxx」が以前に使用された例で使用され、 "xxxxx"から "x"を削除しました。"C00"を使用してIPv6アドレスの例を "C00"に変更しました。StartAddressとEndAddressの定義に「表現する文字列」を追加しました。「自律システム番号エンティティオブジェクトクラス」から「エンティティ」を削除しました。StartautnumとEndautnumの定義に「符号なし32ビット整数」を追加しました。IPネットワークおよびASNオブジェクトクラスの名前の定義に「表現する文字列」を追加しました。セクション4.1のRDAPConformance識別子登録期待を明確にしました。"lunarnic_level_0"を "lunarnic_level_0"に変更しました。
* Clarified that the "value", "rel" and "href" JSON values MUST be specified in the "links" array.
* 「Links」アレイで「値」、「rel」、および「href」のJSON値を指定する必要があることを明確にしました。
* Clarified that the "description" array is required in the Notices and Remarks data structures and other values are OPTIONAL.
* 「説明」アレイが注意事項に必要とされ、備考データ構造および他の値はオプションであることを明確にした。
* Noted that all members of the "events" and "Public IDs" arrays are REQUIRED.
* 「イベント」と「パブリックID」アレイのすべてのメンバーが必要です。
* Fix "self" link values in examples. Changed "http" to "https" link values in examples. Noted that Figure 18 is an example of a nameserver object with all "appropriate" values given. In Appendix C, quoted the word "label" in "label attribute". Added reference to "status" definition in the descriptions for IP networks and autnums. Fixed a 404 for the informative reference to "The Stealthy Ascendancy of JSON". Added "boolean" to the definition of zoneSigned.
* 例の「自己」リンク値を修正してください。例の「HTTP」を「HTTPS」リンク値に変更しました。図18は、与えられたすべての「適切な」値を持つネームサーバーオブジェクトの例です。付録Cで、「LABEL属性」の「ラベル」という単語を引用しました。IPネットワークとAutnumsの説明内の「ステータス」定義への参照。「JSONのステルス的な優勢」への有益な参照のための404を修正しました。Zonesignedの定義に "Boolean"を追加しました。
* Clarified REQUIRED and OPTIONAL members of the "events" array.
* 「イベント」アレイの必須およびオプションのメンバーが明確になりました。
* Changed "SHOULD not" to "SHOULD NOT" in Section 5.
* セクション5で「しないでください」に変更されました。
* Updated normative references (RFC 5226 to RFC 8126, RFC 5988 to RFC 8288, RFC 7159 to RFC 8259). Changed examples using "ns1.xn-- fo-5ja.example" to split URLs to avoid long lines.
* 規範的参照（RFC 5226~RFC 8126、RFC 5988、RFC 8288、RFC 7159~RFC 8259）。"ns1.xn_fo-5ja.example"を使用して例を変更して、長い行を回避するためにURLを分割します。
* Added acknowledgments.
* 謝辞を追加しました。
* Changed "The "lang" attribute may appear anywhere in an object class or data structure except for in jCard objects" to "The "lang" attribute as defined in this section MAY appear anywhere in an object class or data structure, except for in jCard objects. jCard supports similar functionality by way of the LANGUAGE property parameter (see Section 5.1 of RFC 6350 [RFC6350]".
* "" LANG "属性は、JCardの定義された" LANG "属性を除くオブジェクトクラスまたはデータ構造の任意の場所に表示されることがあります。オブジェクトJCardは、言語プロパティパラメータによって同様の機能をサポートしています（RFC 6350 [RFC6350]のセクション5.1を参照）。
* Changed "simple data types conveyed in JSON strings" to "simple data types conveyed in JSON primitive types (strings, numbers, booleans, and null)". Changed "In other words, servers are free to not include JSON members containing registration data based on their own policies" to "In other words, servers are free to omit unrequired/optional JSON members containing registration data based on their own policies".
* 「JSON文字列に伝えられる単純なデータ型」を「JSONプリミティブ型」（文字列、数字、ブール値、およびNULL）に伝えられる単純なデータ型を変更しました。言い換えれば、「サーバは自分のポリシー」に基づいて登録データを含むJSONメンバーは自由に含まれておらず、サーバは自分のポリシーに基づく登録データを含む不要/オプションのJSONメンバーを自由に省略している」。
* Changed "This data structure appears only in the topmost JSON object of a response" to "This data structure MUST appear in the topmost JSON object of a response".
* 「このデータ構造は、このデータ構造の最上位のJSONオブジェクトにのみ表示されます。このデータ構造は、応答の最上位のJSONオブジェクトに表示されている必要があります」。
* Changed "Some non-answer responses may return entity bodies with information that could be more descriptive" to "Some non-answer responses MAY return entity bodies with information that could be more descriptive".
* 変更された「応答の中には、いくつかの非回答の回答は、いくつかの非回答の回答をよりわかりやすい回答になる可能性がある情報で、よりわかりやすい情報」をもっと説明的である可能性がある情報でエンティティ本体を返すかもしれません。
* Changed "The basic structure of that response is an object class containing an error code number (corresponding to the HTTP response code) followed by a string named "title" and an array of strings named "description"" to "The basic structure of that response is an object class containing a REQUIRED error code number (corresponding to the HTTP response code) followed by an OPTIONAL string named "title" and an OPTIONAL array of strings named "description"".
* 変更された「その応答の基本構造は、エラーコード番号（HTTPレスポンスコードに対応）とそれに続く "title"という名前の文字列と "description"という名前の文字列の配列がその基本構造を含むオブジェクトクラスです。Responseは、必要なエラーコード番号（HTTP応答コードに対応する）とそれに対応するオブジェクトクラスとそれに続く "title"という名前のオプションの文字列と "description" "という名前の文字列の配列が続きます。
* Changed the "Autonomous System Number Object Class" section title to "The Autonomous System Number Object Class" for consistency with other section titles. Removed trailing periods in the "Terminology and Definitions" section for consistency. Changed instances of "lunarNic" to "lunarNIC" for consistency. Removed an extraneous trailing period after the eventDate description. Changed a "." to ";" in the description of the "network" member of the domain object class. Changed "The high-level structure of the autnum object class consists of information about the network registration" to "The high-level structure of the autnum object class consists of information about the Autonomous System number registration". Changed "registry unique" to "registry-unique".
* 「自律システム番号オブジェクトクラス」の項のタイトルを「自律システム番号オブジェクトクラス」に変更して、他のセクションタイトルとの整合性を説明します。整合性については、「用語と定義」で末尾の期間を削除しました。コンシステンシーのために「lunarnic」のインスタンスを「lunarnic」に変更しました。EventDateの説明の後に余分な末尾の期間を削除しました。"。"を変更しました";"にするドメインオブジェクトクラスの「ネットワーク」メンバの説明で。変更された「AutNUMオブジェクトクラスの高レベル構造は、自己システム番号登録に関する情報で構成されているAutnumオブジェクトクラスのハイレベル構造についてのネットワーク登録に関する情報で構成されています」。「レジストリ固有」を「レジストリ固有」に変更しました。
* Changed "registrant" to "registrar" in the description of the "transfer" event action to address erratum 6158. Added IANA instructions to correct the description of the value in the registry.
* "転送"イベントアクションの説明で "Registrans"を "Registrar"に変更して、erratum 6158に対応しました。レジストリ内の値の説明を修正するためのIANA命令を追加しました。
* Added text to Section 4.2 to note that "self" and "related" "href" URIs MUST NOT be the same.
* 「self」と「関連する」「HREF」のURIが同じでなければならないことに注意するには、セクション4.2にテキストを追加しました。
* Added text to Section 4.2 to describe return of IDNs in LDH name format.
* LDH名形式でIDNのリターンを記述するには、セクション4.2にテキストを追加しました。
* Added text to note that the "fn" member of a contact object MAY be empty in Section 3.
* 連絡先オブジェクトの「FN」メンバーがセクション3で空になる可能性があることに注意するためのテキストを追加しました。
* Added text to clarify rdapConformance requirements in Section 4.1.
* セクション4.1のRDAPConformance要件を明確にするためのテキストを追加しました。
* Added "obsoletes 7483" to the headers, Abstract, and Introduction. Updated BCP 14 boilerplate. Updated IANA Considerations to note that this RFC (a product of the REGEXT Working Group) replaces RFC 7483. Changed "simple string" to "simple character string" in Sections 3 and 4.7. Clarified requirement for the "fn" member in Section 3. Modified the requirement for rdapConformance placement in Section 4.1. Changed "jCard" to "vCard" LANGUAGE property reference in Section 4.4. Changed "no use" to "little or no use" in Section 5.1. Added example line wrap note in Section 5.2. Modified the definition of "idnTable" in Section 5.3. Modified the dsData and keyData examples in Section 5.3. Changed "2001:c00::/23" to "2001:db8::/32" in Section 5.4. Expanded the definition of "type" in Sections 5.4 and 5.5. Modified example autnums in Section 5.5. Added text to the Security Considerations section to note that DNSSEC information returned in a response cannot be trusted directly.
* ヘッダー、要約、および紹介に「廃止された廃止7483」を追加しました。更新されたBCP 14のボイラープレート。このRFC（Regextワーキンググループの製品）がRFC 7483に代わるものに代わるIANAの考慮事項を更新しました。セクション3の「FN」メンバーの要件を明確にした。セクション4.1のRDAPCコンフォーター配置の要件を修正しました。セクション4.4で "jcard"を "vCard"言語プロパティ参照に変更しました。セクション5.1で "No Use"を "No Use"に変更しました。サクション5.2でラインラップノートの例を追加しました。セクション5.3の「idntable」の定義を修正しました。セクション5.3のDSDATAおよびKEYDATAの例を修正しました。「2001：C00 :: / 23」を「2001：DB8 :: / 32」に変更しました。セクション5.4と5.5の「タイプ」の定義を拡張しました。セクション5.5のautnumsの変更例。応答で返されたDNSSEC情報を直接信頼できないことに注意して、セキュリティ上の考慮事項セクションにテキストを追加しました。
Acknowledgments
謝辞
This document is derived from original work on RIR responses in JSON by Byron J. Ellacott, Arturo L. Servin, Kaveh Ranjbar, and Andrew L. Newton. Additionally, this document incorporates work on DNR responses in JSON by Ning Kong, Linlin Zhou, Jiagui Xie, and Sean Shen.
この文書は、バイロンJ. Ellacott、Arturo L. Servic、Kaveh Ranjbar、およびAndrew L. NewtonによるJSONのRIR回答に関する独自の作品から派生しています。さらに、この文書は、Kong、Linlin Zhou、Jiagui Xie、およびSean ShenによってJSONのDNR応答に関する研究を取り入れています。
The components of the DNR object classes are derived from a categorization of WHOIS response formats created by Ning Kong, Linlin Zhou, Guangqing Deng, Steve Sheng, Francisco Arias, Ray Bellis, and Frederico Neves.
DNRオブジェクトクラスのコンポーネントは、Kong、Linlin Zhou、Guangqing Deng、Steve Sheng、Francisco Arias、Ray Bellis、およびFrederico Nevesによって作成されたwhois応答フォーマットの分類から派生しています。
Tom Harrison, Murray Kucherawy, Ed Lewis, Audric Schiltknecht, Naoki Kambe, Maarten Bosteels, Mario Loffredo, and Jasdip Singh contributed significant review comments and provided clarifying text. James Mitchell provided text regarding the processing of unknown JSON attributes and identified issues leading to the remodeling of events. Ernie Dainow and Francisco Obispo provided concrete suggestions that led to a better variant model for domain names.
Tom Harrison、Murray Kucherawy、Ed Lewis、Auric Rescentknecht、Naoki Kambe、Maarten Bosteels、Mario Loffredo、およびJasdip Singhは、重要なレビューのコメントを貢献し、明確にしたテキストを提供しました。James Mitchell未知のJSON属性の処理とイベントの改訂につながる問題に関するテキストを提供しました。Ernie DainowおよびFrancisco Obispoは、ドメイン名のためのより良いバリアントモデルをもたらした具体的な提案を提供しました。
Ernie Dainow provided the background information on the secure DNS attributes and objects for domains, informative text on DNSSEC, and many other attributes that appear throughout the object classes of this document.
Ernie Dainowは、DNSSEC上の有益なテキスト、およびこのドキュメントのオブジェクトクラス全体に表示される他の多くの属性のためのバックグラウンド情報を提供しました。
The switch to and incorporation of jCard was performed by Simon Perreault.
Simon PerreAllによってJCardへの切り替えと組み込みが行われました。
Olaf Kolkman and Murray Kucherawy chaired the IETF's WEIRDS Working Group from which this document was originally created. James Galvin and Antoin Verschuren chaired the REGEXT Working Group that worked on this document.
Olaf KolkmanとMurray Kucherawyは、この文書が最初に作成されたIETFの奇妙なワーキンググループを議長しました。James GalvinとAntoin Verschurenは、この文書で働いていた正規X作業グループを議長しました。
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