RFC 9910 - Registration Data Access Protocol (RDAP) Regional Internet Registry (RIR) Search 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc9910.html
タイトル : RFC 9910 - 登録データアクセスプロトコル (RDAP) 地域インターネットレジストリ (RIR) 検索
翻訳編集 : 自動生成

Internet Engineering Task Force (IETF)                       T. Harrison
Request for Comments: 9910                                         APNIC
Category: Standards Track                                       J. Singh
ISSN: 2070-1721                                                     ARIN
                                                            January 2026

Registration Data Access Protocol (RDAP) Regional Internet Registry (RIR) Search

登録データアクセスプロトコル (RDAP) 地域インターネットレジストリ (RIR) 検索

Abstract

概要

The Registration Data Access Protocol (RDAP) is used by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs) to provide access to their resource registration information. The core specifications for RDAP define basic search functionality, but there are various search options related to IP addresses, IP prefixes, and Autonomous System Numbers (ASNs), which are provided by RIRs via their WHOIS services, but for which there is no corresponding RDAP functionality. This document extends RDAP to support those search options.

登録データアクセスプロトコル (RDAP) は、地域インターネットレジストリ (RIR) およびドメイン名レジストリ (DNR) によって、リソース登録情報へのアクセスを提供するために使用されます。RDAP の中核仕様では基本的な検索機能が定義されていますが、IP アドレス、IP プレフィックス、自律システム番号 (ASN) に関連するさまざまな検索オプションがあり、これらは RIR によって WHOIS サービスを通じて提供されますが、これらに対応する RDAP 機能はありません。このドキュメントは、これらの検索オプションをサポートするために RDAP を拡張します。

Status of This Memo

本文書の位置付け

This is an Internet Standards Track document.

これはインターネット標準化トラックの文書です。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc9910.

この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc9910 で入手できます。

Copyright Notice

著作権表示

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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコードコンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンステキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。

   1.  Introduction
     1.1.  Conventions Used in This Document
   2.  Basic Searches
     2.1.  Path Segments
     2.2.  IP Network Search
     2.3.  Autonomous System Number Search
   3.  Relation Searches
     3.1.  Path Segments
     3.2.  Relation Search
       3.2.1.  Definitions
       3.2.2.  Relations
         3.2.2.1.  Single-Result Searches
         3.2.2.2.  Multiple-Result Searches
     3.3.  Status
     3.4.  Link Relations
   4.  Responding to Searches
     4.1.  Single-Result Searches
     4.2.  Multiple-Result Searches
   5.  Reverse Search
   6.  RDAP Conformance
   7.  Operational Considerations
   8.  Privacy Considerations
   9.  Security Considerations
   10. IANA Considerations
     10.1.  RDAP Extensions Registry
       10.1.1.  rirSearch1
       10.1.2.  ips
       10.1.3.  autnums
       10.1.4.  ipSearchResults
       10.1.5.  autnumSearchResults
     10.2.  Link Relations Registry
       10.2.1.  rdap-up
       10.2.2.  rdap-down
       10.2.3.  rdap-top
       10.2.4.  rdap-bottom
       10.2.5.  rdap-active
     10.3.  RDAP Reverse Search Registry
       10.3.1.  fn
       10.3.2.  handle
       10.3.3.  email
       10.3.4.  role
     10.4.  RDAP Reverse Search Mapping Registry
       10.4.1.  fn
       10.4.2.  handle
       10.4.3.  email
       10.4.4.  role
   11. References
     11.1.  Normative References
     11.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction

1. はじめに

The Registration Data Access Protocol (RDAP) [RFC7480] is used by Regional Internet Registries (RIRs) and Domain Name Registries (DNRs) to provide access to their resource registration information. The core specifications for RDAP define basic search functionality, but this is limited to domains, nameservers, and entities. No searches were defined for IP networks or autonomous system numbers. In an effort to have RDAP reach feature parity with the existing RIR WHOIS [RFC3912] services in this respect, this document defines additional search options for IP networks and autonomous system numbers.

登録データアクセスプロトコル (RDAP) [RFC7480] は、地域インターネットレジストリ (RIR) およびドメイン名レジストリ (DNR) によって、リソース登録情報へのアクセスを提供するために使用されます。RDAP の中核仕様では基本的な検索機能が定義されていますが、これはドメイン、ネームサーバー、エンティティに限定されています。IP ネットワークまたは自律システム番号の検索は定義されていません。この点で、RDAP が既存の RIR WHOIS [RFC3912] サービスと同等の機能を達成できるようにするために、この文書は IP ネットワークと自律システム番号の追加の検索オプションを定義します。

While this document is written in terms of RIRs and DNRs for the sake of consistency with earlier RDAP documents such as [RFC9082] and [RFC9083], the functionality described here may be used by any RDAP server operator that hosts Internet Number Resource (INR) objects.

この文書は、[RFC9082] や [RFC9083] などの以前の RDAP 文書との一貫性を保つために RIR と DNR の観点から書かれていますが、ここで説明されている機能は、インターネット番号リソース (INR) オブジェクトをホストする任意の RDAP サーバーオペレーターによって使用される可能性があります。

1.1. Conventions Used in This Document

1.1. この文書で使用される表記規則

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」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。

Indentation and whitespace in examples are provided only to illustrate element relationships and are not required features of this specification.

例におけるインデントと空白は、要素の関係を説明するためにのみ提供されており、この仕様の必須の機能ではありません。

"..." in examples is used as shorthand for elements defined outside of this document, as well as to abbreviate elements that are too long.

例中の「...」は、このドキュメントの外で定義された要素の短縮形として、また長すぎる要素を省略するために使用されます。

2. Basic Searches

2. 基本的な検索

2.1. Path Segments

2.1. パスセグメント

The new resource type path segments for basic search (similar to the searches defined in [RFC9082] and [RFC9083]) are:

基本検索 ([RFC9082] および [RFC9083] で定義されている検索と同様) の新しいリソースタイプパスセグメントは次のとおりです。

'ips':

「ips」:

Used to identify an IP network search using a pattern to match one of a set of IP network attributes.

IP ネットワーク属性のセットの 1 つに一致するパターンを使用して IP ネットワーク検索を識別するために使用されます。

'autnums':

「秋」:

Used to identify an autonomous system number search using a pattern to match one of a set of autonomous system number attributes.

自律システム番号属性のセットの 1 つに一致するパターンを使用して、自律システム番号検索を識別するために使用されます。

A search pattern matches a value where it equals the string representation of the value, or where it is a match for the value in accordance with the use of the asterisk ('*', ASCII value 0x2A) character for partial string matching as defined in Section 4.1 of [RFC9082]. For most searches, '*' may be used to match trailing characters only, and may appear in a search only once: see the previously mentioned section for a complete definition of the relevant behaviour.

検索パターンは、値の文字列表現と等しい値、または [RFC9082] のセクション 4.1 で定義されている部分文字列一致のためのアスタリスク ('*'、ASCII 値 0x2A) 文字の使用に従って値と一致する値と一致します。ほとんどの検索では、「*」は末尾の文字の一致のみに使用され、検索に 1 回だけ表示されます。関連する動作の完全な定義については、前述のセクションを参照してください。

Section 4.1 of [RFC9082] describes the use of a trailing domain label suffix in a partial string search. It is not necessary that servers support this type of search pattern for the basic searches defined in this document, since those searches do not relate to domain name members.

[RFC9082] のセクション 4.1 では、部分文字列検索における末尾のドメインラベルサフィックスの使用について説明しています。このドキュメントで定義されている基本検索では、サーバーがこのタイプの検索パターンをサポートする必要はありません。これらの検索はドメイン名メンバーに関連しないためです。

2.2. IP Network Search

2.2. IPネットワーク検索

Syntax:

構文：

ips?handle=<handle search pattern>

ips?handle=<ハンドル検索パターン>

Syntax:

構文：

ips?name=<name search pattern>

ips?name=<名前検索パターン>

Searches for IP network (see Section 5.4 of [RFC9083]) information by handle are specified using the form:

ハンドルによる IP ネットワーク ([RFC9083] のセクション 5.4 を参照) 情報の検索は、次の形式を使用して指定します。

ips?handle=XXXX

ips?ハンドル=XXXX

XXXX is a search pattern representing an IP network identifier whose syntax is specific to the registration provider. The following URL would be used to find information for IP networks with handles matching the "NET-199*" pattern:

XXXX は、登録プロバイダーに固有の構文を持つ IP ネットワーク識別子を表す検索パターンです。次の URL は、「NET-199*」パターンに一致するハンドルを持つ IP ネットワークの情報を検索するために使用されます。

https://example.com/rdap/ips?handle=NET-199*

Searches for IP network (see Section 5.4 of [RFC9083]) information by name are specified using the form:

IP ネットワーク ([RFC9083] のセクション 5.4 を参照) 情報を名前で検索する場合は、次の形式で指定します。

ips?name=XXXX

XXXX is a search pattern representing an IP network identifier that is assigned to the network registration by the registration holder. The following URL would be used to find information for IP networks with names matching the "NET-EXAMPLE-*" pattern:

XXXX は、登録所有者によってネットワーク登録に割り当てられた IP ネットワーク識別子を表す検索パターンです。次の URL は、「NET-EXAMPLE-*」パターンに一致する名前を持つ IP ネットワークの情報を検索するために使用されます。

https://example.com/rdap/ips?name=NET-EXAMPLE-*

2.3. Autonomous System Number Search

2.3. 自律システム番号検索

Syntax:

構文：

autnums?handle=<handle search pattern>

autnums?handle=<ハンドル検索パターン>

Syntax:

構文：

autnums?name=<name search pattern>

autnums?name=<名前の検索パターン>

Searches for autonomous system number (see Section 5.5 of [RFC9083]) information by handle are specified using the form:

ハンドルによる自律システム番号 ([RFC9083] のセクション 5.5 を参照) 情報の検索は、次の形式を使用して指定されます。

autnums?handle=XXXX

秋?ハンドル=XXXX

XXXX is a search pattern representing an autonomous system number identifier whose syntax is specific to the registration provider. The following URL would be used to find information for autonomous system numbers with handles matching the "AS1*" pattern:

XXXX は、自律システム番号識別子を表す検索パターンであり、その構文は登録プロバイダーに固有です。次の URL は、「AS1*」パターンに一致するハンドルを持つ自律システム番号の情報を検索するために使用されます。

https://example.com/rdap/autnums?handle=AS1*

Searches for autonomous system number (see Section 5.5 of [RFC9083]) information by name are specified using the form:

自律システム番号 ([RFC9083] のセクション 5.5 を参照) 情報を名前で検索する場合は、次の形式を使用して指定します。

autnums?name=XXXX

秋?名前=XXXX

XXXX is a search pattern representing an autonomous system number identifier that is assigned to the autonomous system number registration by the registration holder. The following URL would be used to find information for autonomous system numbers with names matching the "ASN-EXAMPLE-*" pattern:

XXXXは、登録保持者が自律システム番号登録に対して割り当てた自律システム番号識別子を表す検索パターンである。次の URL は、「ASN-EXAMPLE-*」パターンに一致する名前を持つ自律システム番号の情報を検索するために使用されます。

https://example.com/rdap/autnums?name=ASN-EXAMPLE-*

3. Relation Searches

3. 関連性検索

This section defines searches and link relations for finding objects and sets of objects with respect to their position within a hierarchy.

このセクションでは、階層内での位置に応じたオブジェクトおよびオブジェクトのセットを検索するための検索とリンク関係を定義します。

3.1. Path Segments

3.1. パスセグメント

The variables used in the path segments in this section include:

このセクションのパスセグメントで使用される変数には次のものが含まれます。

<relation>:

<関係>:

a relation type, as defined in Section 3.2.2 of this document.

このドキュメントのセクション 3.2.2 で定義されている関係タイプ。

<IP address>:

<IPアドレス>:

an IP address, as defined in Section 3.1.1 of [RFC9082].

[RFC9082] のセクション 3.1.1 で定義されている IP アドレス。

<CIDR prefix>:

<CIDR プレフィックス>:

the first address of a Classless Inter-Domain Routing (CIDR) block, as defined in Section 3.1.1 of [RFC9082].

[RFC9082] のセクション 3.1.1 で定義されている、クラスレスドメイン間ルーティング (CIDR) ブロックの最初のアドレス。

<CIDR length>:

<CIDR 長>:

the prefix length for a CIDR block, as defined in Section 3.1.1 of [RFC9082].

[RFC9082] のセクション 3.1.1 で定義されている、CIDR ブロックのプレフィックス長。

<domain name>:

<ドメイン名>:

a fully qualified domain name, as defined in Section 3.1.3 of [RFC9082].

[RFC9082] のセクション 3.1.3 で定義されている完全修飾ドメイン名。

<autonomous system number or range>:

<自律システム番号または範囲>:

an autonomous system number, as defined in Section 3.1.2 of [RFC9082], or two such numbers separated by a single hyphen ('-', ASCII value 0x2D), where the second number is greater than the first.

[RFC9082] のセクション 3.1.2 で定義されている自律システム番号、または 1 つのハイフン ('-'、ASCII 値 0x2D) で区切られた 2 つのそのような番号。2 番目の番号は最初の番号より大きくなります。

<resource type search path segment>:

<リソースタイプ検索パスセグメント>:

a search path segment corresponding to an Internet Number Resource (INR) object class (i.e., an IP network address or range, autonomous system number or number range, or reverse domain name).

インターネット番号リソース (INR) オブジェクトクラス (つまり、IP ネットワークアドレスまたは範囲、自律システム番号または番号範囲、または逆引きドメイン名) に対応する検索パスセグメント。

<object value>:

<オブジェクト値>:

a value used to identify an object for the purposes of a relation search relative to that object. One of <IP address>, <CIDR prefix> and <CIDR length> pair, <domain name>, or <autonomous system number or range>, depending on the type of search that is being performed.

オブジェクトに関する関係検索を目的として、オブジェクトを識別するために使用される値。実行される検索のタイプに応じて、<IP アドレス>、<CIDR プレフィックス> と <CIDR 長> のペア、<ドメイン名>、または <自律システム番号または範囲> のいずれか。

<status>:

<ステータス>:

an object status value, as defined in Section 4.6 of [RFC9083].

[RFC9083] のセクション 4.6 で定義されているオブジェクトのステータス値。

The new resource type path segments for relation search (similar to the searches defined in [RFC9082] and [RFC9083]) are:

関係検索 ([RFC9082] および [RFC9083] で定義されている検索と同様) の新しいリソースタイプパスセグメントは次のとおりです。

'ips/rirSearch1/<relation>/<IP address>':

'ips/rirSearch1/<関係>/<IP アドレス>':

Used to identify an IP network search using a relation and an IP address to match a set of IP networks.

一連の IP ネットワークに一致する関係と IP アドレスを使用して IP ネットワーク検索を識別するために使用されます。

'ips/rirSearch1/<relation>/<CIDR prefix>/<CIDR length>':

'ips/rirSearch1/<関係>/<CIDR プレフィックス>/<CIDR 長>':

Used to identify an IP network search using a relation and an IP address range to match a set of IP networks.

一連の IP ネットワークに一致する関係と IP アドレス範囲を使用して IP ネットワーク検索を識別するために使用されます。

'autnums/rirSearch1/<relation>/<autonomous system number or range>':

'autnums/rirSearch1/<関係>/<自律システム番号または範囲>':

Used to identify an autonomous system number search using a relation and a single ASN or an ASN range to match a set of ASN objects.

リレーションと単一の ASN または ASN 範囲を使用して、一連の ASN オブジェクトと一致する自律システム番号検索を識別するために使用されます。

'domains/rirSearch1/<relation>/<domain name>':

'domains/rirSearch1/<関係>/<ドメイン名>':

Used to identify a reverse domain search using a relation and a reverse domain name to match a set of reverse domains.

リレーションと逆引きドメイン名を使用して、一連の逆引きドメインと一致する逆引きドメイン検索を識別するために使用されます。

3.2. Relation Search

3.2. 関係検索

Syntax:

構文：

<resource type search path segment>/rirSearch1/<relation>/<object value>[?status=<status>]

<リソースタイプ検索パスセグメント>/rirSearch1/<関係>/<オブジェクト値>[?status=<ステータス>]

The relation searches defined in this document rely on the syntax described above. Each search works in the same way for each object class.

このドキュメントで定義されている関係検索は、上記の構文に依存しています。各検索は、オブジェクトクラスごとに同じように機能します。

The rirSearch1 path segment is used in the relation search URLs in order to provide a single namespace for those searches, and so that other searches can be defined underneath the top-level resource type search path segments.

rirSearch1 パスセグメントは、リレーション検索 URL で使用され、これらの検索に単一の名前空間を提供し、トップレベルのリソースタイプ検索パスセグメントの下に他の検索を定義できるようにします。

3.2.1. Definitions

3.2.1. 定義

An INR object value may have a "parent" object and one or more "child" objects. The "parent" object is the next-least-specific object that exists in the relevant registry, while the "child" objects are the next-most-specific objects that exist in the relevant registry. For example, let's say there is a registry with the following IP network objects:

INR オブジェクト値には、「親」オブジェクトと 1 つ以上の「子」オブジェクトが含まれる場合があります。「親」オブジェクトは、関連するレジストリに存在するオブジェクトの中で次に特異性が低いオブジェクトであり、「子」オブジェクトは、関連するレジストリに存在するオブジェクトの中で次に特異性が高いオブジェクトです。たとえば、次の IP ネットワークオブジェクトを含むレジストリがあるとします。

                           +--------------+
                           | 192.0.2.0/24 |
                           +--------------+
                              /        \
                 +--------------+    +----------------+
                 | 192.0.2.0/25 |    | 192.0.2.128/25 |
                 +--------------+    +----------------+
                    /                   /          \
        +--------------+   +----------------+  +----------------+
        | 192.0.2.0/28 |   | 192.0.2.128/26 |  | 192.0.2.192/26 |
        +--------------+   +----------------+  +----------------+
           /
    +--------------+
    | 192.0.2.0/32 |
    +--------------+

Figure 1: Example Registry Objects

図 1: レジストリオブジェクトの例

For this example registry, the INR object value to parent/child object relationships are:

このレジストリ例の場合、INR オブジェクト値と親/子オブジェクトの関係は次のとおりです。

                   +==================+================+
                   | INR object value | Parent object  |
                   +==================+================+
                   | 192.0.2.0/32     | 192.0.2.0/28   |
                   +------------------+----------------+
                   | 192.0.2.0/28     | 192.0.2.0/25   |
                   +------------------+----------------+
                   | 192.0.2.64/26    | 192.0.2.0/25   |
                   +------------------+----------------+
                   | 192.0.2.128/26   | 192.0.2.128/25 |
                   +------------------+----------------+
                   | 192.0.2.192/26   | 192.0.2.128/25 |
                   +------------------+----------------+
                   | 192.0.2.0/25     | 192.0.2.0/24   |
                   +------------------+----------------+
                   | 192.0.2.128/25   | 192.0.2.0/24   |
                   +------------------+----------------+
                   | 192.0.2.0/24     | N/A            |
                   +------------------+----------------+

Table 1: Parent Objects

表 1: 親オブジェクト

           +==================+================================+
           | INR object value | Child objects                  |
           +==================+================================+
           | 192.0.2.0/24     | 192.0.2.0/25, 192.0.2.128/25   |
           +------------------+--------------------------------+
           | 192.0.2.0/25     | 192.0.2.0/28                   |
           +------------------+--------------------------------+
           | 192.0.2.128/25   | 192.0.2.128/26, 192.0.2.192/26 |
           +------------------+--------------------------------+
           | 192.0.2.64/26    | N/A                            |
           +------------------+--------------------------------+
           | 192.0.2.128/26   | N/A                            |
           +------------------+--------------------------------+
           | 192.0.2.192/26   | N/A                            |
           +------------------+--------------------------------+
           | 192.0.2.0/28     | 192.0.2.0/32                   |
           +------------------+--------------------------------+
           | 192.0.2.0/32     | N/A                            |
           +------------------+--------------------------------+

Table 2: Child Objects

表 2: 子オブジェクト

(INR object values do not necessarily correspond to registry objects, because users can provide arbitrary object values as input to the searches defined in this document.)

(ユーザーはこのドキュメントで定義されている検索への入力として任意のオブジェクト値を指定できるため、INR オブジェクト値は必ずしもレジストリオブジェクトに対応するとは限りません。)

Similarly to the parent/child object relationships, each INR object value may have a "top" object, being the least-specific covering object that exists in the registry, and one or more "bottom" objects, being the most-specific objects that entirely cover the INR object value when taken together. Given the registry defined above, the top and bottom object relationships are:

親/子オブジェクトの関係と同様に、各 INR オブジェクト値には、レジストリ内に存在する最も具体性の低いカバーオブジェクトである「トップ」オブジェクトと、組み合わせたときに INR オブジェクト値を完全にカバーする最も具体性の高いオブジェクトである 1 つまたは複数の「ボトム」オブジェクトを持つことができます。上記で定義されたレジストリを考慮すると、上位と下位のオブジェクトの関係は次のようになります。

                    +==================+==============+
                    | INR object value | Top object   |
                    +==================+==============+
                    | 192.0.2.0/32     | 192.0.2.0/24 |
                    +------------------+--------------+
                    | 192.0.2.0/28     | 192.0.2.0/24 |
                    +------------------+--------------+
                    | 192.0.2.64/26    | 192.0.2.0/24 |
                    +------------------+--------------+
                    | 192.0.2.128/26   | 192.0.2.0/24 |
                    +------------------+--------------+
                    | 192.0.2.192/26   | 192.0.2.0/24 |
                    +------------------+--------------+
                    | 192.0.2.0/25     | 192.0.2.0/24 |
                    +------------------+--------------+
                    | 192.0.2.128/25   | 192.0.2.0/24 |
                    +------------------+--------------+
                    | 192.0.2.0/24     | N/A          |
                    +------------------+--------------+

Table 3: Top Objects

表 3: 上位オブジェクト

     +==================+===========================================+
     | INR object value | Bottom objects                            |
     +==================+===========================================+
     | 192.0.2.0/24     | 192.0.2.0/25, 192.0.2.0/28, 192.0.2.0/32, |
     |                  | 192.0.2.128/26, 192.0.2.192/26            |
     +------------------+-------------------------------------------+
     | 192.0.2.0/25     | 192.0.2.0/25, 192.0.2.0/28, 192.0.2.0/32  |
     +------------------+-------------------------------------------+
     | 192.0.2.128/25   | 192.0.2.128/26, 192.0.2.192/26            |
     +------------------+-------------------------------------------+
     | 192.0.2.64/26    | N/A                                       |
     +------------------+-------------------------------------------+
     | 192.0.2.128/26   | N/A                                       |
     +------------------+-------------------------------------------+
     | 192.0.2.192/26   | N/A                                       |
     +------------------+-------------------------------------------+
     | 192.0.2.0/28     | 192.0.2.0/28, 192.0.2.0/32                |
     +------------------+-------------------------------------------+
     | 192.0.2.0/31     | 192.0.2.0/28, 192.0.2.0/32                |
     +------------------+-------------------------------------------+
     | 192.0.2.0/32     | N/A                                       |
     +------------------+-------------------------------------------+

Table 4: Bottom Objects

表 4: 下部オブジェクト

If there are no more-specific objects for a given INR object value, then the set of bottom objects for that INR object value will be empty. 192.0.2.0/32 is an example of such an INR object value.

特定の INR オブジェクト値にさらに具体的なオブジェクトがない場合、その INR オブジェクト値の最下位オブジェクトのセットは空になります。192.0.2.0/32 は、そのような INR オブジェクト値の例です。

It is not necessarily the case that the bottom objects for a given INR object value will be disjoint. For example, 192.0.2.0/28's bottom objects are 192.0.2.0/28 and 192.0.2.0/32. 192.0.2.0/32 is included because it is one of the most-specific objects (i.e., an object at the bottom of the object hierarchy) for 192.0.2.0/28, while 192.0.2.0/28 itself is included because it is the most-specific object for the other addresses within the range (i.e., those aside from 192.0.2.0/32).

特定の INR オブジェクト値の下部オブジェクトが互いに素であるとは限りません。たとえば、192.0.2.0/28 の最下位オブジェクトは 192.0.2.0/28 と 192.0.2.0/32 です。192.0.2.0/32 は、192.0.2.0/28 にとって最も具体的なオブジェクト (つまり、オブジェクト階層の最下位にあるオブジェクト) の 1 つであるため含まれますが、192.0.2.0/28 自体は、範囲内の他のアドレス (つまり、192.0.2.0/32 以外のアドレス) にとって最も具体的なオブジェクトであるため含まれます。

The bottom objects for a given INR object value may include an object that is less specific than that INR object value. For example, 192.0.2.0/31 is an INR object value that has a more-specific object, being 192.0.2.0/32, so the set of bottom objects must include at least that object. The most-specific object that covers the residual (i.e., 192.0.2.1/32) is 192.0.2.0/28, so it is included in the results as well.

特定の INR オブジェクト値の下部オブジェクトには、その INR オブジェクト値よりも具体性が低いオブジェクトが含まれる場合があります。たとえば、192.0.2.0/31 は、より具体的なオブジェクト (192.0.2.0/32) を持つ INR オブジェクト値であるため、下部オブジェクトのセットには少なくともそのオブジェクトが含まれている必要があります。残差 (つまり、192.0.2.1/32) をカバーする最も具体的なオブジェクトは 192.0.2.0/28 であるため、これも結果に含まれます。

3.2.2. Relations

3.2.2. 関係

3.2.2.1. Single-Result Searches

3.2.2.1. 単一結果の検索

3.2.2.1.1. "rdap-up"

3.2.2.1.1. 「rdap-up」

If the server receives a search containing the relation value "rdap-up", it will return the parent object for the specified INR object value as though that object had been requested directly. If no such object exists, it will respond with an HTTP 404 (Not Found) [RFC9110] status code.

サーバーがリレーション値「rdap-up」を含む検索を受信した場合、そのオブジェクトが直接要求されたかのように、指定された INR オブジェクト値の親オブジェクトを返します。そのようなオブジェクトが存在しない場合、HTTP 404 (Not Found) [RFC9110] ステータスコードで応答します。

3.2.2.1.2. "rdap-top"

3.2.2.1.2. 「rdap-トップ」

If the server receives a search containing the relation value "rdap-top", it will return the top object for the specified INR object value as though that object had been requested directly. If no such object exists, it will respond with an HTTP 404 (Not Found) [RFC9110] status code.

サーバーがリレーション値「rdap-top」を含む検索を受信した場合、そのオブジェクトが直接要求されたかのように、指定された INR オブジェクト値の最上位オブジェクトを返します。そのようなオブジェクトが存在しない場合、HTTP 404 (Not Found) [RFC9110] ステータスコードで応答します。

3.2.2.2. Multiple-Result Searches

3.2.2.2. 複数結果の検索

3.2.2.2.1. "rdap-down"

3.2.2.2.1. 「rdapダウン」

If the server receives a search containing the relation value "rdap-down", it will return the child objects for the specified INR object value. If no such objects exist, it will return an empty search response. Per the definitions section, this includes only immediate child objects.

サーバーがリレーション値「rdap-down」を含む検索を受信した場合、指定された INR オブジェクト値の子オブジェクトを返します。そのようなオブジェクトが存在しない場合は、空の検索応答が返されます。定義セクションによると、これには直接の子オブジェクトのみが含まれます。

3.2.2.2.2. "rdap-bottom"

3.2.2.2.2. 「rdap-ボトム」

If the server receives a search containing the relation value "rdap-bottom", it will return the bottom objects for the specified INR object value. If no such objects exist, it will return an empty search response.

サーバーがリレーション値「rdap-bottom」を含む検索を受信した場合、指定された INR オブジェクト値の下部オブジェクトを返します。そのようなオブジェクトが存在しない場合は、空の検索応答が返されます。

3.3. Status

3.3. 状態

If the "status" argument is provided, then response processing will proceed as though all objects without the specified status had first been removed from the database. For example, if the registry objects from Section 3.2.1 had the following statuses:

「status」引数が指定されている場合、指定されたステータスを持たないすべてのオブジェクトが最初にデータベースから削除されたかのように、応答処理が続行されます。たとえば、セクション 3.2.1 のレジストリオブジェクトが次のステータスを持っていたとします。

                       +================+==========+
                       | Object         | Status   |
                       +================+==========+
                       | 192.0.2.0/25   | active   |
                       +----------------+----------+
                       | 192.0.2.128/25 | inactive |
                       +----------------+----------+
                       | 192.0.2.128/26 | active   |
                       +----------------+----------+
                       | 192.0.2.192/26 | active   |
                       +----------------+----------+

Table 5: Statuses

表 5: ステータス

then a server receiving a "rdap-down" search request with the INR object value 192.0.2.0/24 and a "status" argument of "active" would return the objects 192.0.2.0/25, 192.0.2.128/26, and 192.0.2.192/26.

この場合、INR オブジェクト値 192.0.2.0/24 と「status」引数「active」を持つ「rdap-down」検索リクエストを受信したサーバーは、オブジェクト 192.0.2.0/25、192.0.2.128/26、および 192.0.2.192/26 を返します。

Status filtering is useful, for example, where the client is trying to find the delegation from an RIR to an RIR account holder: by using the "rdap-top" relation with a "status" of "active", the delegation from IANA to the RIR will be ignored, and the client will receive the delegation from the RIR to the account holder in the response instead.

ステータスフィルタリングは、たとえば、クライアントが RIR から RIR アカウント所有者への委任を見つけようとしている場合に便利です。「ステータス」が「アクティブ」である「rdap-top」関係を使用すると、IANA から RIR への委任は無視され、クライアントは代わりに、RIR からアカウント所有者への委任を応答で受け取ります。

By default, any valid status value may be used for status filtering. Server operators MAY opt not to support "status" filtering for the "rdap-down" and "rdap-bottom" link relations, in which case the server responds with an HTTP 501 (Not Implemented) [RFC9110] response code if it receives such a request. Server operators MAY also opt not to support "status" filtering for values other than "active" for the "rdap-up" and "rdap-top" link relations, in which case the server responds with an HTTP 501 (Not Implemented) [RFC9110] response code if it receives such a request.

デフォルトでは、任意の有効なステータス値をステータスフィルタリングに使用できます。サーバーオペレーターは、「rdap-down」および「rdap-bottom」リンク関係に対する「status」フィルタリングをサポートしないことを選択してもよい(MAY)。その場合、サーバーは、そのようなリクエストを受信した場合、HTTP 501 (未実装) [RFC9110] 応答コードで応答する。サーバーオペレータは、「rdap-up」および「rdap-top」リンク関係の「active」以外の値に対する「status」フィルタリングをサポートしないことを選択してもよい（MAY）。その場合、サーバーは、そのようなリクエストを受信した場合、HTTP 501 (未実装) [RFC9110] 応答コードで応答する。

While any valid status value may be used for status filtering, a given RDAP server may make use of only a small number of those status values for INR objects. For example, a status value like "client hold" would typically only be used by a DNR for a forward domain name object.

ステータスフィルタリングには任意の有効なステータス値を使用できますが、特定の RDAP サーバーは INR オブジェクトに対して少数のステータス値しか使用しない場合があります。たとえば、「クライアント保留」のようなステータス値は、通常、フォワードドメイン名オブジェクトの DNR によってのみ使用されます。

3.4. Link Relations

3.4. リンク関係

Each of the relations defined in Section 3.2.2 has a corresponding link relation that can be used for a link object contained within another RDAP object. When constructing these link objects, the server MUST use the corresponding search URL for the link target, or a URL that yields the same response as for the corresponding search as at the time of the request. The following is an elided example of an IPv4 response that makes use of those link relations:

セクション 3.2.2 で定義された各関係には、別の RDAP オブジェクト内に含まれるリンクオブジェクトに使用できる対応するリンク関係があります。これらのリンクオブジェクトを構築するとき、サーバーは、リンクターゲットの対応する検索 URL、またはリクエスト時の対応する検索と同じ応答を生成する URL を使用しなければなりません (MUST)。以下は、これらのリンク関係を利用した IPv4 応答の省略された例です。

   {
     "startAddress": "192.0.2.0",
     "endAddress": "192.0.2.127",
     ...
     "links": [
       ...,
       {
         "value": "https://example.com/rdap/ip/192.0.2.0/25",
         "rel": "rdap-up",
         "href": ".../rdap/ips/rirSearch1/rdap-up/192.0.2.0/25",
         "type": "application/rdap+json"
       },
       {
         "value": "https://example.com/rdap/ip/192.0.2.0/25",
         "rel": "rdap-down",
         "href": ".../rdap/ips/rirSearch1/rdap-down/192.0.2.0/25",
         "type": "application/rdap+json"
       },
       {
         "value": "https://example.com/rdap/ip/192.0.2.0/25",
         "rel": "rdap-top",
         "href": ".../rdap/ips/rirSearch1/rdap-top/192.0.2.0/25",
         "type": "application/rdap+json"
       },
       {
         "value": "https://example.com/rdap/ip/192.0.2.0/25",
         "rel": "rdap-bottom",
         "href": ".../rdap/ips/rirSearch1/rdap-bottom/192.0.2.0/25",
         "type": "application/rdap+json"
       }
     ]
   }

Figure 2: Example Links in an IPv4 Response

図 2: IPv4 応答内のリンクの例

The following is an elided example of an IPv6 response that makes use of the link relations:

以下は、リンク関係を利用した IPv6 応答の省略された例です。

   {
     "startAddress": "2001:db8:a::",
     "endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff",
     ...
     "links": [
       ...,
       {
         "value": "https://example.com/rdap/ip/2001:db8:a::/48",
         "rel": "rdap-up",
         "href": ".../rdap/ips/rirSearch1/rdap-up/2001:db8:a::/48",
         "type": "application/rdap+json"
       },
       {
         "value": "https://example.com/rdap/ip/2001:db8:a::/48",
         "rel": "rdap-down",
         "href": ".../rdap/ips/rirSearch1/rdap-down/2001:db8:a::/48",
         "type": "application/rdap+json"
       },
       {
         "value": "https://example.com/rdap/ip/2001:db8:a::/48",
         "rel": "rdap-top",
         "href": ".../rdap/ips/rirSearch1/rdap-top/2001:db8:a::/48",
         "type": "application/rdap+json"
       },
       {
         "value": "https://example.com/rdap/ip/2001:db8:a::/48",
         "rel": "rdap-bottom",
         "href": ".../rdap/ips/rirSearch1/rdap-bottom/2001:db8:a::/48",
         "type": "application/rdap+json"
       }
     ]
   }

Figure 3: Example Links in an IPv6 Response

図 3: IPv6 応答内のリンクの例

One additional link relation, "rdap-active", is defined for denoting a search with a "status" of "active". No other status link relations are defined because the only known use cases for status filtering involve the "rdap-up" and "rdap-top" relations and the "active" status. The following is an elided example of an IPv4 response that makes use of those link relations:

追加のリンク関係の 1 つである「rdap-active」は、「ステータス」が「アクティブ」である検索を示すために定義されています。ステータスフィルタリングの既知の使用例は、「rdap-up」および「rdap-top」関係と「active」ステータスのみであるため、他のステータスリンク関係は定義されていません。以下は、これらのリンク関係を利用した IPv4 応答の省略された例です。

   {
     "startAddress": "192.0.2.0",
     "endAddress": "192.0.2.127",
     ...
     "links": [
       ...,
       {
         "value": "https://example.com/rdap/ip/192.0.2.0/25",
         "rel": "rdap-up rdap-active",
         "href":
          ".../rdap/ips/rirSearch1/rdap-up/192.0.2.0/25?status=active",
         "type": "application/rdap+json"
       },
       {
         "value": "https://example.com/rdap/ip/192.0.2.0/25",
         "rel": "rdap-top rdap-active",
         "href":
          ".../rdap/ips/rirSearch1/rdap-top/192.0.2.0/25?status=active",
         "type": "application/rdap+json"
       }
     ]
   }

Figure 4: Example Status Links in an IPv4 Response

図 4: IPv4 応答内のステータスリンクの例

The following is an elided example of an IPv6 response that makes use of the link relations:

以下は、リンク関係を利用した IPv6 応答の省略された例です。

   {
     "startAddress": "2001:db8:a::",
     "endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff",
     ...
     "links": [
       ...,
       {
         "value": "https://example.com/rdap/ip/2001:db8:a::/48",
         "rel": "rdap-up rdap-active",
         "href":
        ".../rdap/ips/rirSearch1/rdap-up/2001:db8:a::/48?status=active",
         "type": "application/rdap+json"
       },
       {
         "value": "https://example.com/rdap/ip/2001:db8:a::/48",
         "rel": "rdap-top rdap-active",
         "href":
       ".../rdap/ips/rirSearch1/rdap-top/2001:db8:a::/48?status=active",
         "type": "application/rdap+json"
       }
     ]
   }

Figure 5: Example Status Links in an IPv6 Response

図 5: IPv6 応答内のステータスリンクの例

"rdap-active" is used only as a link relation in a link object. It cannot be used as a value for <relation> in the relation search URL defined in Section 3.2. Section 3.3 details status filtering for relation search URLs.

「rdap-active」は、リンクオブジェクト内のリンク関係としてのみ使用されます。3.2 項で定義した関係検索 URL の <relation> の値として使用することはできません。セクション 3.3 では、関係検索 URL のステータスフィルタリングについて詳しく説明します。

Since the "rdap-top" and "rdap-up" link relations resolve either to a single object or to an HTTP 404 (Not Found) [RFC9110] response, it is possible for a server to use a lookup URL (see Section 3.1 of [RFC9082]) in the "href" attribute in the link object. The following is an elided example of an IPv4 response that uses this approach:

「rdap-top」と「rdap-up」のリンク関係は、単一のオブジェクトまたは HTTP 404 (Not Found) [RFC9110] 応答のいずれかに解決されるため、サーバーはリンクオブジェクトの「href」属性でルックアップ URL ([RFC9082] のセクション 3.1 を参照) を使用することができます。以下は、このアプローチを使用した IPv4 応答の省略された例です。

   {
     "startAddress": "192.0.2.0",
     "endAddress": "192.0.2.127",
     ...
     "links": [
       ...,
       {
         "value": "https://example.com/rdap/ip/192.0.2.0/25",
         "rel": "rdap-up",
         "href": "https://example.com/rdap/ip/192.0.2.0/24",
         "type": "application/rdap+json"
       }
     ]
   }

Figure 6: Example Single-Result Links in an IPv4 Response

図 6: IPv4 応答内の単一結果リンクの例

The following is an elided example of an IPv6 response that makes use of the approach:

以下は、このアプローチを利用した IPv6 応答の省略された例です。

   {
     "startAddress": "2001:db8:a::",
     "endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff",
     ...
     "links": [
       ...,
       {
         "value": "https://example.com/rdap/ip/2001:db8:a::/48",
         "rel": "rdap-up",
         "href": "https://example.com/rdap/ip/2001:db8::/32",
         "type": "application/rdap+json"
       }
     ]
   }

Figure 7: Example Single-Result Links in an IPv6 Response

図 7: IPv6 応答内の単一結果リンクの例

Use of these link relations in responses is OPTIONAL. The absence in a response of a link for a specific relation does not necessarily mean that the corresponding search will return no results.

応答でのこれらのリンク関係の使用はオプションです。特定の関係に対するリンクの応答が存在しないことは、必ずしも対応する検索で結果が返されないことを意味するわけではありません。

4. Responding to Searches

4. 検索への応答

4.1. Single-Result Searches

4.1. 単一結果の検索

The "rdap-up" and "rdap-top" relations are single-result searches. When processing these searches, if there is a result for the search, the server returns that object as though it were requested directly via a lookup URL (see Section 3.1 of [RFC9082]). If there is no result for the search, the server returns an HTTP 404 (Not Found) [RFC9110] response code.

「rdap-up」および「rdap-top」関係は、単一結果の検索です。これらの検索を処理するときに、検索結果がある場合、サーバーは、ルックアップ URL 経由で直接リクエストされたかのように、そのオブジェクトを返します ([RFC9082] のセクション 3.1 を参照)。検索結果がない場合、サーバーは HTTP 404 (Not Found) [RFC9110] 応答コードを返します。

4.2. Multiple-Result Searches

4.2. 複数結果の検索

The "rdap-down" and "rdap-bottom" relations are multiple-result searches. As with [RFC9083], responses for 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 beginning with /ips yields an array of IP network object instances, and a search beginning with /autnums yields an array of autonomous system number object instances). The IP network object class is defined in Section 5.4 of [RFC9083], and the autonomous system number object class is defined in Section 5.5 of [RFC9083]. The object instance arrays are contained within the response object.

「rdap-down」および「rdap-bottom」の関係は複数結果の検索です。[RFC9083] と同様、これらの検索に対する応答はオブジェクトインスタンスの配列の形式をとり、各インスタンスは検索に適切なオブジェクトクラスになります (つまり、/ips で始まる検索は IP ネットワークオブジェクトインスタンスの配列を生成し、/autnums で始まる検索は自律システム番号オブジェクトインスタンスの配列を生成します)。IP ネットワークオブジェクトクラスは [RFC9083] のセクション 5.4 で定義され、自律システム番号オブジェクトクラスは [RFC9083] のセクション 5.5 で定義されます。オブジェクトインスタンスの配列は応答オブジェクト内に含まれます。

The names of the arrays are as follows:

配列の名前は次のとおりです。

* for /ips searches, the array is "ipSearchResults"; and

* /ips 検索の場合、配列は「ipSearchResults」です。そして

* for /autnums searches, the array is "autnumSearchResults".

* /autnums 検索の場合、配列は「autnumSearchResults」です。

The following is an elided example of a response for an IPv4 network search:

以下は、IPv4 ネットワーク検索の応答の省略された例です。

   {
     "rdapConformance": [ "rdap_level_0", "rirSearch1",
                          "ips", "ipSearchResults", ... ],
     ...
     "ipSearchResults": [
       {
         "objectClassName": "ip network",
         "handle": "XXXX-RIR",
         "startAddress": "192.0.2.0",
         "endAddress": "192.0.2.127",
         ...
       },
       {
         "objectClassName": "ip network",
         "handle": "YYYY-RIR",
         "startAddress": "192.0.2.0",
         "endAddress": "192.0.2.255",
         ...
       }
     ]
   }

Figure 8: IPv4 Network Search Response

図 8: IPv4 ネットワーク検索応答

The following is an elided example of a response for an IPv6 network search:

以下は、IPv6 ネットワーク検索の応答の省略された例です。

   {
     "rdapConformance": [ "rdap_level_0", "rirSearch1",
                          "ips", "ipSearchResults", ... ],
     ...
     "ipSearchResults": [
       {
         "objectClassName": "ip network",
         "handle": "XXXX-RIR",
         "startAddress": "2001:db8:a::",
         "endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff",
         ...
       },
       {
         "objectClassName": "ip network",
         "handle": "YYYY-RIR",
         "startAddress": "2001:db8::",
         "endAddress": "2001:db8:ffff:ffff:ffff:ffff:ffff:ffff",
         ...
       }
     ]
   }

Figure 9: IPv6 Network Search Response

図 9: IPv6 ネットワーク検索応答

The following is an elided example of a response to an autonomous system number search:

以下は、自律システム番号検索に対する応答の省略された例です。

   {
     "rdapConformance": [ "rdap_level_0", "rirSearch1",
                          "autnums", "autnumSearchResults", ... ],
     ...
     "autnumSearchResults": [
       {
         "objectClassName": "autnum",
         "handle": "XXXX-RIR",
         "startAutnum": 64496,
         "endAutnum": 64496,
         ...
       },
       {
         "objectClassName": "autnum",
         "handle": "YYYY-RIR",
         "startAutnum": "64497",
         "endAutnum": "64497",
         ...
       }
     ]
   }

Figure 10: ASN Search Response

図 10: ASN 検索応答

Responses for relation searches for reverse domain objects have the same form as for a standard domain search response, per [RFC9083].

[RFC9083] によれば、逆ドメインオブジェクトの関係検索の応答は、標準のドメイン検索応答と同じ形式になります。

If the search can be processed by the server, but there are no results for the search, then the server returns an HTTP 404 (Not Found) [RFC9110] response code, with the body of the response containing an empty results array.

サーバーで検索を処理できるが、検索結果がない場合、サーバーは HTTP 404 (Not Found) [RFC9110] 応答コードを返します。応答の本文には空の結果配列が含まれます。

5. Reverse Search

5. 逆引き検索

RDAP reverse search is defined by [RFC9536]. That document limits reverse search to domains, nameservers, and entities. This document extends reverse search to cover IP networks and autonomous system numbers as well.

RDAP 逆引き検索は [RFC9536] で定義されています。この文書では、逆方向検索をドメイン、ネームサーバー、エンティティに限定しています。このドキュメントでは、逆検索を拡張して、IP ネットワークと自律システム番号もカバーします。

If a server receives a reverse search query with a searchable resource type (per the definition of that term in [RFC9536]) of "ips", then the reverse search will be performed on the IP network objects from its data store. Similarly, if a server receives a reverse search query with a searchable resource type of "autnums", then the reverse search will be performed on the autonomous system number objects from its data store.

サーバーが、検索可能なリソースタイプ ([RFC9536] の用語の定義による) 「ips」を持つ逆検索クエリを受信した場合、そのデータストアから IP ネットワークオブジェクトに対して逆検索が実行されます。同様に、サーバーが検索可能なリソースタイプが「autnums」である逆方向検索クエリを受信した場合、そのデータストアから自律システム番号オブジェクトに対して逆方向検索が実行されます。

Additionally, Section 10 notes that new registrations for IP network and autonomous system number searches have been made in the "RDAP Reverse Search" and "RDAP Reverse Search Mapping" IANA registries.

さらに、セクション 10 では、IP ネットワークおよび自律システム番号検索の新しい登録が「RDAP 逆検索」および「RDAP 逆検索マッピング」IANA レジストリで行われたことに注意してください。

6. RDAP Conformance

6. RDAP準拠

A server that supports the functionality specified in this document MUST include additional string literals in the rdapConformance array of its responses, in accordance with the following:

この文書で指定された機能をサポートするサーバーは、以下に従って、応答の rdapConformance 配列に追加の文字列リテラルを含めなければなりません (MUST)。

* any response that includes an IP network basic search link, an IP network relation search link, or an IP network reverse search link includes the "rirSearch1" and "ips" literals;

* IP ネットワーク基本検索リンク、IP ネットワーク関係検索リンク、または IP ネットワーク逆検索リンクを含む応答には、「rirSearch1」および「ips」リテラルが含まれます。

* any response for an IP network basic search request, an IP network relation search request, or an IP network reverse search request includes the "rirSearch1", "ips", and "ipSearchResults" literals;

* IP ネットワーク基本検索要求、IP ネットワーク関連検索要求、または IP ネットワーク逆検索要求に対する応答には、「rirSearch1」、「ips」、および「ipSearchResults」リテラルが含まれます。

* any response that includes an ASN basic search link, an ASN relation search link, or an ASN reverse search link includes the "rirSearch1" and "autnums" literals;

* ASN 基本検索リンク、ASN 関係検索リンク、または ASN 逆検索リンクを含む応答には、「rirSearch1」および「autnums」リテラルが含まれます。

* any response for an ASN basic search request, an ASN relation search request, or an ASN reverse search request includes the "rirSearch1", "autnums", and "autnumSearchResults" literals;

* ASN 基本検索リクエスト、ASN 関係検索リクエスト、または ASN 逆検索リクエストに対する応答には、「rirSearch1」、「autnums」、および「autnumSearchResults」リテラルが含まれます。

* any response that includes a domain relation search link includes the "rirSearch1" literal;

* ドメイン関係検索リンクを含む応答には、「rirSearch1」リテラルが含まれます。

* any response for a domain relation search request includes the "rirSearch1" literal; and

* ドメイン関係検索リクエストに対する応答には、「rirSearch1」リテラルが含まれます。そして

* a response to a "/help" request includes the "rirSearch1", "ips", "ipSearchResults", "autnums", and "autnumSearchResults" literals.

* 「/help」リクエストに対する応答には、「rirSearch1」、「ips」、「ipSearchResults」、「autnums」、および「autnumSearchResults」リテラルが含まれます。

Although responses will generally not include all of the rdapConformance string literals defined in this document, that is not meant to imply that a server can support only a portion of the functionality defined in this document.

通常、応答にはこのドキュメントで定義されているすべての rdapConformance 文字列リテラルが含まれるわけではありませんが、サーバーがこのドキュメントで定義されている機能の一部のみをサポートできることを意味するものではありません。

The "ips", "autnums", "ipSearchResults", and "autnumSearchResults" extension identifiers are included here due to the requirements and recommendations set out in [RFC7480], [RFC9082], and [RFC9083]. These requirements and recommendations are such that an RDAP extension identifier be used as a prefix in new path segments and JSON members introduced by the extension, and those strings are used as such as part of the basic searches defined in this document. Furthermore, using these strings as path segments helps to increase consistency among the basic searches for the core RDAP object classes.

[RFC7480]、[RFC9082]、および [RFC9083] に規定されている要件と推奨事項のため、「ips」、「autnums」、「ipSearchResults」、および「autnumSearchResults」拡張識別子がここに含まれています。これらの要件と推奨事項は、RDAP 拡張機能の識別子が、拡張機能によって導入される新しいパスセグメントおよび JSON メンバーのプレフィックスとして使用されること、およびそれらの文字列がこのドキュメントで定義されている基本検索の一部として使用されることなどです。さらに、これらの文字列をパスセグメントとして使用すると、コア RDAP オブジェクトクラスの基本検索間の一貫性が向上します。

As with the other core object classes (entity, domain, and nameserver), other documents may define additional reverse searches with IP networks and ASNs as the searchable resource type by registering those in the IANA RDAP reverse search registries. Because a given extension identifier must correspond to a single extension, though, any document making use of IP networks or ASNs as the searchable resource type must also implement the functionality described in this document.

他のコアオブジェクトクラス (エンティティ、ドメイン、ネームサーバー) と同様に、他の文書では、IP ネットワークと ASN を IANA RDAP 逆検索レジストリに登録することで、検索可能なリソースタイプとして追加の逆検索を定義できます。ただし、特定の拡張子識別子は 1 つの拡張子に対応する必要があるため、検索可能なリソースタイプとして IP ネットワークまたは ASN を使用するドキュメントは、このドキュメントで説明されている機能も実装する必要があります。

The "1" in "rirSearch1" denotes that this is version 1 of the RIR search extension. New versions of the RIR search extension will use different extension identifiers. A version suffix is not used for the remaining identifiers defined by this document, partly because such a suffix would reduce consistency with the corresponding functionality for the other core object classes, and partly because it is very unlikely that the functionality associated with those identifiers will change.

「rirSearch1」の「1」は、これが RIR 検索拡張機能のバージョン 1 であることを示します。RIR 検索拡張機能の新しいバージョンでは、異なる拡張機能識別子が使用されます。この文書で定義されている残りの識別子にはバージョン接尾辞は使用されません。その理由の 1 つは、そのような接尾辞を使用すると、他のコアオブジェクトクラスの対応する機能との一貫性が低下するためであり、また、これらの識別子に関連付けられた機能が変更される可能性が非常に低いためです。

7. Operational Considerations

7. 運用上の考慮事項

When using a link object for a single-result search, a server may replace a search URL with a lookup URL, because the behaviour of the lookup URL is the same as that of the search URL at the time the response is generated. One difference between these approaches is that when using the lookup URL, the server is effectively performing the search on behalf of the client as at the time of response generation. If there is no change to the relevant database state between the time when the original response is generated and the time when the client resolves the link relation target, then the search URL and the lookup URL will lead to the same result. However, if there is a change to the relevant database state, then the lookup URL may lead to a different result from that of the search URL. Server operators should consider which type of URL will be more effective for their clients when implementing this specification.

単一結果の検索にリンクオブジェクトを使用する場合、検索 URL の動作は応答生成時の検索 URL の動作と同じであるため、サーバーは検索 URL を検索 URL に置き換える場合があります。これらのアプローチの違いの 1 つは、ルックアップ URL を使用する場合、応答生成時と同様にサーバーがクライアントに代わって効率的に検索を実行することです。元の応答が生成されてからクライアントがリンク関係ターゲットを解決するまでの間に、関連するデータベースの状態に変化がない場合、検索 URL とルックアップ URL は同じ結果になります。ただし、関連するデータベースの状態に変更があった場合、ルックアップ URL は検索 URL の結果とは異なる結果になる可能性があります。サーバーオペレーターは、この仕様を実装するときに、クライアントにとってどのタイプの URL がより効果的かを考慮する必要があります。

Where this document includes HTTP reason phrases, that is purely for the benefit of the reader and is not an indication that those phrases need to be used as-is in responses.

このドキュメントに HTTP 理由フレーズが含まれている場合、これは純粋に読者の利益のためであり、応答でそれらのフレーズをそのまま使用する必要があることを示すものではありません。

8. Privacy Considerations

8. プライバシーへの配慮

The search functionality defined in this document may affect the privacy of entities in the registry (and elsewhere) in various ways: see [RFC6973] for a general treatment of privacy in protocol specifications, and [RFC7481] for specific discussion about privacy threats with respect to the registration data provided by RDAP. Server operators should be aware of the tradeoffs that result from implementation of this functionality.

この文書で定義されている検索機能は、さまざまな方法でレジストリ (およびその他の場所) 内のエンティティのプライバシーに影響を与える可能性があります。プロトコル仕様におけるプライバシーの一般的な扱いについては [RFC6973] を、RDAP によって提供される登録データに関するプライバシーの脅威に関する具体的な議論については [RFC7481] を参照してください。サーバーオペレーターは、この機能の実装によって生じるトレードオフを認識する必要があります。

Many jurisdictions have laws or regulations that restrict the use of "Personal Data", per the definition in [RFC6973]. Given that, server operators should ascertain whether the regulatory environment in which they operate permits implementation of the functionality defined in this document.

多くの法域には、[RFC6973] の定義に従って「個人データ」の使用を制限する法律または規制があります。そのため、サーバー運用者は、運用している規制環境がこの文書で定義されている機能の実装を許可しているかどうかを確認する必要があります。

9. Security Considerations

9. セキュリティに関する考慮事項

[RFC7481] describes security requirements and considerations for RDAP generally. Additionally, guidance as to the use of TLS has changed since that document was published: see [RFC8446] and [BCP195] for further detail.

[RFC7481] では、RDAP のセキュリティ要件と考慮事項全般について説明しています。さらに、TLS の使用に関するガイダンスは、この文書の発行以来変更されています。詳細については、[RFC8446] および [BCP195] を参照してください。

[RFC9082] includes security considerations relating to object retrieval in RDAP. Those considerations are relevant here as well.

[RFC9082] には、RDAP でのオブジェクトの取得に関するセキュリティに関する考慮事項が含まれています。それらの考慮事項はここでも当てはまります。

10. IANA Considerations

10. IANAの考慮事項

10.1. RDAP Extensions Registry

10.1. RDAP 拡張機能レジストリ

IANA has registered the following values in the "RDAP Extensions" registry <https://www.iana.org/assignments/rdap-extensions>.

IANA は、「RDAP Extensions」レジストリ <https://www.iana.org/assignments/rdap-extensions> に次の値を登録しました。

10.1.1. rirSearch1

Extension Identifier:

拡張機能の識別子:

rirSearch1

Registry operator:

レジストリ演算子:

Any

どれでも

Specification:

仕様：

RFC 9910

Contact:

接触：

IETF <iesg@ietf.org>

Intended Usage:

使用目的:

This extension identifier is used for INR-specific search operations.

この拡張識別子は、INR 固有の検索操作に使用されます。

10.1.2. ips

10.1.2. イプス

Extension Identifier:

拡張機能の識別子:

ips

イプス

Registry operator:

レジストリ演算子:

Any

どれでも

Specification:

仕様：

RFC 9910

Contact:

接触：

IETF <iesg@ietf.org>

Intended Usage:

使用目的:

This extension identifier is used for INR-specific search operations.

この拡張識別子は、INR 固有の検索操作に使用されます。

10.1.3. autnums

10.1.3. 秋

Extension Identifier:

拡張機能の識別子:

autnums

秋

Registry operator:

レジストリ演算子:

Any

どれでも

Specification:

仕様：

RFC 9910

Contact:

接触：

IETF <iesg@ietf.org>

Intended Usage:

使用目的:

This extension identifier is used for INR-specific search operations.

この拡張識別子は、INR 固有の検索操作に使用されます。

10.1.4. ipSearchResults

10.1.4. ip検索結果

Extension Identifier:

拡張機能の識別子:

ipSearchResults

ip検索結果

Registry operator:

レジストリ演算子:

Any

どれでも

Specification:

仕様：

RFC 9910

Contact:

接触：

IETF <iesg@ietf.org>

Intended Usage:

使用目的:

This extension identifier is used for INR-specific search operations.

この拡張識別子は、INR 固有の検索操作に使用されます。

10.1.5. autnumSearchResults

10.1.5. 秋の検索結果

Extension Identifier:

拡張機能の識別子:

autnumSearchResults

秋の検索結果

Registry operator:

レジストリ演算子:

Any

どれでも

Specification:

仕様：

RFC 9910

Contact:

接触：

IETF <iesg@ietf.org>

Intended Usage:

使用目的:

This extension identifier is used for INR-specific search operations.

この拡張識別子は、INR 固有の検索操作に使用されます。

10.2. Link Relations Registry

Reference:

参照：

RFC 9910

10.3. RDAP Reverse Search Registry

10.3. RDAP逆引き検索レジストリ

IANA has registered the following entries in the "RDAP Reverse Search" registry <https://www.iana.org/assignments/rdap-reverse-search/>.

IANA は、「RDAP 逆検索」レジストリ <https://www.iana.org/assignments/rdap-reverse-search/> に次のエントリを登録しました。

10.3.1. fn

10.3.1. ふん

Property:

財産：

ふん

Description:

説明：

The server supports the IP/autnum search based on the full name (a.k.a. formatted name) of an associated entity.

サーバーは、関連付けられたエンティティのフルネーム (別名、フォーマットされた名前) に基づいた IP/秋の検索をサポートします。

Searchable Resource Type:

検索可能なリソースの種類:

ips, autnums

ips、オータナムズ

Related Resource Type:

関連リソースの種類:

entity

実在物

Registrant:

登録者:

IETF

Contact Information:

連絡先：

iesg@ietf.org

Reference:

参照：

RFC 9910

10.3.2. handle

10.3.2. ハンドル

Property:

財産：

handle

ハンドル

Description:

説明：

The server supports the IP/autnum search based on the handle of an associated entity.

サーバーは、関連付けられたエンティティのハンドルに基づいた IP/秋の検索をサポートします。

Searchable Resource Type:

検索可能なリソースの種類:

ips, autnums

ips、オータナムズ

Related Resource Type:

関連リソースの種類:

entity

実在物

Registrant:

登録者:

IETF

Contact Information:

連絡先：

iesg@ietf.org

Reference:

参照：

RFC 9910

10.3.3. email

10.3.3. 電子メール

Property:

財産：

電子メール

Description:

説明：

The server supports the IP/autnum search based on the email address of an associated entity.

サーバーは、関連付けられたエンティティの電子メールアドレスに基づく IP/秋の検索をサポートします。

Searchable Resource Type:

検索可能なリソースの種類:

ips, autnums

ips、オータナムズ

Related Resource Type:

関連リソースの種類:

entity

実在物

Registrant:

登録者:

IETF

Contact Information:

連絡先：

iesg@ietf.org

Reference:

参照：

RFC 9910

10.3.4. role

10.3.4. 役割

Property:

財産：

role

役割

Description:

説明：

The server supports the IP/autnum search based on the role of an associated entity.

サーバーは、関連付けられたエンティティの役割に基づいて IP/秋の検索をサポートします。

Searchable Resource Type:

検索可能なリソースの種類:

ips, autnums

ips、オータナムズ

Related Resource Type:

関連リソースの種類:

entity

実在物

Registrant:

登録者:

IETF

Contact Information:

連絡先：

iesg@ietf.org

Reference:

参照：

RFC 9910

10.4. RDAP Reverse Search Mapping Registry

10.4. RDAP 逆検索マッピングレジストリ

IANA has registered the following entries in the "RDAP Reverse Search Mapping" registry <https://www.iana.org/assignments/rdap-reverse-search-mapping>.

IANA は、「RDAP 逆検索マッピング」レジストリ <https://www.iana.org/assignments/rdap-reverse-search-mapping> に次のエントリを登録しました。

10.4.1. fn

10.4.1. ふん

Property:

財産：

ふん

Property Path:

プロパティパス:

$.entities[*].vcardArray[1][?(@[0]=='fn')][3]

Searchable Resource Type:

検索可能なリソースの種類:

ips, autnums

ips、オータナムズ

Related Resource Type:

関連リソースの種類:

entity

実在物

Registrant:

登録者:

IETF

Contact Information:

連絡先：

iesg@ietf.org

Reference:

参照：

RFC 9910

10.4.2. handle

10.4.2. ハンドル

Property:

財産：

handle

ハンドル

Property Path:

プロパティパス:

$.entities[*].handle

$.entities[*].ハンドル

Searchable Resource Type:

検索可能なリソースの種類:

ips, autnums

ips、オータナムズ

Related Resource Type:

関連リソースの種類:

entity

実在物

Registrant:

登録者:

IETF

Contact Information:

連絡先：

iesg@ietf.org

Reference:

参照：

RFC 9910

10.4.3. email

10.4.3. 電子メール

Property:

財産：

電子メール

Property Path:

プロパティパス:

$.entities[*].vcardArray[1][?(@[0]=='email')][3]

$.entities[*].vcardArray[1][?(@[0]=='電子メール')][3]

Searchable Resource Type:

検索可能なリソースの種類:

ips, autnums

ips、オータナムズ

Related Resource Type:

関連リソースの種類:

entity

実在物

Registrant:

登録者:

IETF

Contact Information:

連絡先：

iesg@ietf.org

Reference:

参照：

RFC 9910

10.4.4. role

10.4.4. 役割

Property:

財産：

role

役割

Property Path:

プロパティパス:

$.entities[*].roles

Searchable Resource Type:

検索可能なリソースの種類:

ips, autnums

ips、オータナムズ

Related Resource Type:

関連リソースの種類:

entity

実在物

Registrant:

登録者:

IETF

Contact Information:

連絡先：

iesg@ietf.org

Reference:

参照：

RFC 9910

11. References

11. 参考文献

11.1. Normative References

11.1. 引用文献

   [BCP195]   Best Current Practice 195,
              <https://www.rfc-editor.org/info/bcp195>.
              At the time of writing, this BCP comprises the following:

              Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
              1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
              <https://www.rfc-editor.org/info/rfc8996>.

              Sheffer, Y., Saint-Andre, P., and T. Fossati,
              "Recommendations for Secure Use of Transport Layer
              Security (TLS) and Datagram Transport Layer Security
              (DTLS)", BCP 195, RFC 9325, DOI 10.17487/RFC9325, November
              2022, <https://www.rfc-editor.org/info/rfc9325>.

   [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>.

   [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>.

   [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>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [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>.

   [RFC9083]  Hollenbeck, S. and A. Newton, "JSON Responses for the
              Registration Data Access Protocol (RDAP)", STD 95,
              RFC 9083, DOI 10.17487/RFC9083, June 2021,
              <https://www.rfc-editor.org/info/rfc9083>.

   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/info/rfc9110>.

   [RFC9536]  Loffredo, M. and M. Martinelli, "Registration Data Access
              Protocol (RDAP) Reverse Search", RFC 9536,
              DOI 10.17487/RFC9536, April 2024,
              <https://www.rfc-editor.org/info/rfc9536>.

11.2. Informative References

11.2. 参考引用

   [RFC3912]  Daigle, L., "WHOIS Protocol Specification", RFC 3912,
              DOI 10.17487/RFC3912, September 2004,
              <https://www.rfc-editor.org/info/rfc3912>.

   [RFC6973]  Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
              Morris, J., Hansen, M., and R. Smith, "Privacy
              Considerations for Internet Protocols", RFC 6973,
              DOI 10.17487/RFC6973, July 2013,
              <https://www.rfc-editor.org/info/rfc6973>.

   [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>.

Acknowledgements

謝辞

The authors wish to thank Mario Loffredo, Andy Newton, Antoin Verschuren, James Gould, Scott Hollenbeck, Orie Steele, Russ Housley, John Levine, Stewart Bryant, Mark Nottingham, Mohamed Boucadair, Deb Cooley, Éric Vyncke, and Roman Danyliw for document review and associated comments.

著者らは、文書のレビューと関連するコメントについて、Mario Loffredo、Andy Newton、Antoin Verschuren、James Gould、Scott Hollenbeck、Orie Steele、Russ Housley、John Levine、Stewart Bryant、Mark Nottingham、Mohamed Boucadair、Deb Cooley、Éric Vyncke、および Roman Danyliw に感謝します。

Authors' Addresses

著者の住所

   Tom Harrison
   Asia Pacific Network Information Centre
   6 Cordelia St
   South Brisbane QLD 4101
   Australia
   Email: tomh@apnic.net

   Jasdip Singh
   American Registry for Internet Numbers
   PO Box 232290
   Centreville, VA 20120
   United States of America
   Email: jasdips@arin.net

RFC 9910 - Registration Data Access Protocol (RDAP) Regional Internet Registry (RIR) Search 日本語訳

Registration Data Access Protocol (RDAP) Regional Internet Registry (RIR) Search

登録データ アクセス プロトコル (RDAP) 地域インターネット レジストリ (RIR) 検索

Abstract

概要

Status of This Memo

本文書の位置付け

Copyright Notice

著作権表示

Table of Contents

目次

1. Introduction

1. はじめに

1.1. Conventions Used in This Document

1.1. この文書で使用される表記規則

2. Basic Searches

2. 基本的な検索

2.1. Path Segments

2.1. パスセグメント

2.2. IP Network Search

2.2. IPネットワーク検索

2.3. Autonomous System Number Search

2.3. 自律システム番号検索

3. Relation Searches

3. 関連性検索

3.1. Path Segments

3.1. パスセグメント

3.2. Relation Search

3.2. 関係検索

3.2.1. Definitions

3.2.1. 定義

3.2.2. Relations

3.2.2. 関係

3.2.2.1. Single-Result Searches

3.2.2.1. 単一結果の検索

3.2.2.1.1. "rdap-up"

3.2.2.1.1. 「rdap-up」

3.2.2.1.2. "rdap-top"

3.2.2.1.2. 「rdap-トップ」

3.2.2.2. Multiple-Result Searches

3.2.2.2. 複数結果の検索

3.2.2.2.1. "rdap-down"

3.2.2.2.1. 「rdapダウン」

3.2.2.2.2. "rdap-bottom"

3.2.2.2.2. 「rdap-ボトム」

3.3. Status

3.3. 状態

3.4. Link Relations

3.4. リンク関係

4. Responding to Searches

4. 検索への応答

4.1. Single-Result Searches

4.1. 単一結果の検索

4.2. Multiple-Result Searches

4.2. 複数結果の検索

5. Reverse Search

5. 逆引き検索

6. RDAP Conformance

6. RDAP準拠

7. Operational Considerations

7. 運用上の考慮事項

8. Privacy Considerations

8. プライバシーへの配慮

9. Security Considerations

9. セキュリティに関する考慮事項

10. IANA Considerations

10. IANAの考慮事項

10.1. RDAP Extensions Registry

10.1. RDAP 拡張機能レジストリ

10.1.1. rirSearch1

10.1.1. rirSearch1

10.1.2. ips

10.1.2. イプス

10.1.3. autnums

10.1.3. 秋

10.1.4. ipSearchResults

10.1.4. ip検索結果

10.1.5. autnumSearchResults

10.1.5. 秋の検索結果

10.2. Link Relations Registry

登録データアクセスプロトコル (RDAP) 地域インターネットレジストリ (RIR) 検索

10.4. RDAP 逆検索マッピングレジストリ