rfc9910.original   rfc9910.txt 
Internet Engineering Task Force T. Harrison Internet Engineering Task Force (IETF) T. Harrison
Internet-Draft APNIC Request for Comments: 9910 APNIC
Intended status: Standards Track J. Singh Category: Standards Track J. Singh
Expires: 6 December 2025 ARIN ISSN: 2070-1721 ARIN
4 June 2025 December 2025
Registration Data Access Protocol (RDAP) Regional Internet Registry Registration Data Access Protocol (RDAP) Regional Internet Registry
(RIR) Search (RIR) Search
draft-ietf-regext-rdap-rir-search-19
Abstract Abstract
The Registration Data Access Protocol (RDAP) is used by Regional The Registration Data Access Protocol (RDAP) is used by Regional
Internet Registries (RIRs) and Domain Name Registries (DNRs) to Internet Registries (RIRs) and Domain Name Registries (DNRs) to
provide access to their resource registration information. The core provide access to their resource registration information. The core
specifications for RDAP define basic search functionality, but there specifications for RDAP define basic search functionality, but there
are various search options related to IP addresses, IP prefixes, and are various search options related to IP addresses, IP prefixes, and
ASNs, which are provided by RIRs via their Whois services, but for Autonomous System Numbers (ASNs), which are provided by RIRs via
which there is no corresponding RDAP functionality. This document their WHOIS services, but for which there is no corresponding RDAP
extends RDAP to support those search options. functionality. This document extends RDAP to support those search
options.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This is an Internet Standards Track document.
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
This Internet-Draft will expire on 6 December 2025. 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.
Copyright Notice Copyright Notice
Copyright (c) 2025 IETF Trust and the persons identified as the Copyright (c) 2025 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents
license-info) in effect on the date of publication of this document. (https://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. Code Components carefully, as they describe your rights and restrictions with respect
extracted from this document must include Revised BSD License text as to this document. Code Components extracted from this document must
described in Section 4.e of the Trust Legal Provisions and are include Revised BSD License text as described in Section 4.e of the
provided without warranty as described in the Revised BSD License. Trust Legal Provisions and are provided without warranty as described
in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction
1.1. Conventions Used in This Document . . . . . . . . . . . . 3 1.1. Conventions Used in This Document
2. Basic Searches . . . . . . . . . . . . . . . . . . . . . . . 4 2. Basic Searches
2.1. Path Segments . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Path Segments
2.2. IP Network Search . . . . . . . . . . . . . . . . . . . . 4 2.2. IP Network Search
2.3. Autonomous System Number Search . . . . . . . . . . . . . 5 2.3. Autonomous System Number Search
3. Relation Searches . . . . . . . . . . . . . . . . . . . . . . 5 3. Relation Searches
3.1. Path Segments . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Path Segments
3.2. Relation Search . . . . . . . . . . . . . . . . . . . . . 7 3.2. Relation Search
3.2.1. Definitions . . . . . . . . . . . . . . . . . . . . . 7 3.2.1. Definitions
3.2.2. Relations . . . . . . . . . . . . . . . . . . . . . . 10 3.2.2. Relations
3.2.2.1. Single-Result Searches . . . . . . . . . . . . . 11 3.2.2.1. Single-Result Searches
3.2.2.2. Multiple-Result Searches . . . . . . . . . . . . 11 3.2.2.2. Multiple-Result Searches
3.3. Status . . . . . . . . . . . . . . . . . . . . . . . . . 11 3.3. Status
3.4. Link Relations . . . . . . . . . . . . . . . . . . . . . 13 3.4. Link Relations
4. Responding To Searches . . . . . . . . . . . . . . . . . . . 17 4. Responding to Searches
4.1. Single-Result Searches . . . . . . . . . . . . . . . . . 18 4.1. Single-Result Searches
4.2. Multiple-Result Searches . . . . . . . . . . . . . . . . 18 4.2. Multiple-Result Searches
5. Reverse Search . . . . . . . . . . . . . . . . . . . . . . . 20 5. Reverse Search
6. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 21 6. RDAP Conformance
7. Operational Considerations . . . . . . . . . . . . . . . . . 22 7. Operational Considerations
8. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 8. Privacy Considerations
9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Security Considerations
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 10. IANA Considerations
10.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 23 10.1. RDAP Extensions Registry
10.1.1. rirSearch1 . . . . . . . . . . . . . . . . . . . . . 23 10.1.1. rirSearch1
10.1.2. ips . . . . . . . . . . . . . . . . . . . . . . . . 23 10.1.2. ips
10.1.3. autnums . . . . . . . . . . . . . . . . . . . . . . 24 10.1.3. autnums
10.1.4. ipSearchResults . . . . . . . . . . . . . . . . . . 24 10.1.4. ipSearchResults
10.1.5. autnumSearchResults . . . . . . . . . . . . . . . . 24 10.1.5. autnumSearchResults
10.2. Link Relations Registry . . . . . . . . . . . . . . . . 24 10.2. Link Relations Registry
10.2.1. rdap-up . . . . . . . . . . . . . . . . . . . . . . 24 10.2.1. rdap-up
10.2.2. rdap-down . . . . . . . . . . . . . . . . . . . . . 24 10.2.2. rdap-down
10.2.3. rdap-top . . . . . . . . . . . . . . . . . . . . . . 25 10.2.3. rdap-top
10.2.4. rdap-bottom . . . . . . . . . . . . . . . . . . . . 25 10.2.4. rdap-bottom
10.2.5. rdap-active . . . . . . . . . . . . . . . . . . . . 25 10.2.5. rdap-active
10.3. RDAP Reverse Search Registry . . . . . . . . . . . . . . 25 10.3. RDAP Reverse Search Registry
10.3.1. fn . . . . . . . . . . . . . . . . . . . . . . . . . 25 10.3.1. fn
10.3.2. handle . . . . . . . . . . . . . . . . . . . . . . . 25 10.3.2. handle
10.3.3. email . . . . . . . . . . . . . . . . . . . . . . . 26 10.3.3. email
10.3.4. role . . . . . . . . . . . . . . . . . . . . . . . . 26 10.3.4. role
10.4. RDAP Reverse Search Mapping Registry
10.4. RDAP Reverse Search Mapping Registry . . . . . . . . . . 26 10.4.1. fn
10.4.1. fn . . . . . . . . . . . . . . . . . . . . . . . . . 26 10.4.2. handle
10.4.2. handle . . . . . . . . . . . . . . . . . . . . . . . 26 10.4.3. email
10.4.3. email . . . . . . . . . . . . . . . . . . . . . . . 27 10.4.4. role
10.4.4. role . . . . . . . . . . . . . . . . . . . . . . . . 27 11. References
11. Implementation Status . . . . . . . . . . . . . . . . . . . . 27 11.1. Normative References
11.1. APNIC RDAP Implementation . . . . . . . . . . . . . . . 28 11.2. Informative References
11.2. RIPE NCC RDAP Implementation . . . . . . . . . . . . . . 28 Acknowledgements
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 28 Authors' Addresses
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 28
13.1. Normative References . . . . . . . . . . . . . . . . . . 28
13.2. Informative References . . . . . . . . . . . . . . . . . 29
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30
1. Introduction 1. Introduction
The Registration Data Access Protocol (RDAP) [RFC7480] is used by The Registration Data Access Protocol (RDAP) [RFC7480] is used by
Regional Internet Registries (RIRs) and Domain Name Registries (DNRs) Regional Internet Registries (RIRs) and Domain Name Registries (DNRs)
to provide access to their resource registration information. The to provide access to their resource registration information. The
core specifications for RDAP define basic search functionality, but core specifications for RDAP define basic search functionality, but
this is limited to domains, nameservers, and entities. No searches this is limited to domains, nameservers, and entities. No searches
were defined for IP networks or autonomous system numbers. In an were defined for IP networks or autonomous system numbers. In an
effort to have RDAP reach feature parity with the existing RIR Whois effort to have RDAP reach feature parity with the existing RIR WHOIS
[RFC3912] services in this respect, this document defines additional [RFC3912] services in this respect, this document defines additional
search options for IP networks and autonomous system numbers. search options for IP networks and autonomous system numbers.
While this document is in terms of RIRs and DNRs for the sake of While this document is written in terms of RIRs and DNRs for the sake
consistency with earlier RDAP documents such as [RFC9082] and of consistency with earlier RDAP documents such as [RFC9082] and
[RFC9083], the functionality described here may be used by any RDAP [RFC9083], the functionality described here may be used by any RDAP
server operator that hosts Internet Number Resource (INR) objects. server operator that hosts Internet Number Resource (INR) objects.
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in
14 [RFC2119] [RFC8174] when, and only when, they appear in all BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
Indentation and whitespace in examples are provided only to Indentation and whitespace in examples are provided only to
illustrate element relationships, and are not a required feature of illustrate element relationships, and they are not a required feature
this protocol. of this protocol.
"..." in examples is used as shorthand for elements defined outside "..." in examples is used as shorthand for elements defined outside
of this document, as well as to abbreviate elements that are too of this document, as well as to abbreviate elements that are too
long. long.
2. Basic Searches 2. Basic Searches
2.1. Path Segments 2.1. Path Segments
The new resource type path segments for basic search (similar to the The new resource type path segments for basic search (similar to the
searches defined in [RFC9082] and [RFC9083]) are: searches defined in [RFC9082] and [RFC9083]) are:
'ips': Used to identify an IP network search using a pattern to 'ips': Used to identify an IP network search using a pattern to
match one of a set of IP network attributes. match one of a set of IP network attributes.
'autnums': Used to identify an autonomous system number search 'autnums': Used to identify an autonomous system number search using
using a pattern to match one of a set of autonomous system number a pattern to match one of a set of autonomous system number
attributes. attributes.
A search pattern matches a value where it equals the string 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 representation of the value, or where it is a match for the value in
accordance with the use of the asterisk ('*', US-ASCII value 0x2A) accordance with the use of the asterisk ('*', ASCII value 0x2A)
character for partial string matching as defined in Section 4.1 of character for partial string matching as defined in Section 4.1 of
[RFC9082]. For most searches, '*' may be used to match trailing [RFC9082]. For most searches, '*' may be used to match trailing
characters only, and may appear in a search only once: see the characters only, and may appear in a search only once: see the
previously-mentioned section for a complete definition of the previously mentioned section for a complete definition of the
relevant behaviour. relevant behaviour.
Section 4.1 of [RFC9082] describes the use of a trailing domain label 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 suffix in a partial string search. It is not necessary that servers
support this type of search pattern for the basic searches defined in support this type of search pattern for the basic searches defined in
this document, since those searches do not relate to domain name this document, since those searches do not relate to domain name
members. members.
2.2. IP Network Search 2.2. IP Network Search
Syntax: ips?handle=<handle search pattern> Syntax: ips?handle=<handle search pattern>
Syntax: ips?name=<name search pattern> Syntax: ips?name=<name search pattern>
Searches for IP network (see Section 5.4 of [RFC9083]) information by Searches for IP network (see Section 5.4 of [RFC9083]) information by
handle are specified using the form: handle are specified using the form:
ips?handle=XXXX ips?handle=XXXX
XXXX is a search pattern representing an IP network identifier whose XXXX is a search pattern representing an IP network identifier whose
syntax is specific to the registration provider. The following URL syntax is specific to the registration provider. The following URL
would be used to find information for IP networks with handles would be used to find information for IP networks with handles
matching the "NET-199*" pattern: matching the "NET-199*" pattern:
https://example.com/rdap/ips?handle=NET-199* https://example.com/rdap/ips?handle=NET-199*
Searches for IP network (see Section 5.4 of [RFC9083]) information by Searches for IP network (see Section 5.4 of [RFC9083]) information by
name are specified using the form: name are specified using the form:
ips?name=XXXX ips?name=XXXX
XXXX is a search pattern representing an IP network identifier that XXXX is a search pattern representing an IP network identifier that
is assigned to the network registration by the registration holder. is assigned to the network registration by the registration holder.
The following URL would be used to find information for IP networks The following URL would be used to find information for IP networks
with names matching the "NET-EXAMPLE-*" pattern: with names matching the "NET-EXAMPLE-*" pattern:
https://example.com/rdap/ips?name=NET-EXAMPLE-* https://example.com/rdap/ips?name=NET-EXAMPLE-*
2.3. Autonomous System Number Search 2.3. Autonomous System Number Search
Syntax: autnums?handle=<handle search pattern> Syntax: autnums?handle=<handle search pattern>
Syntax: autnums?name=<name search pattern> Syntax: autnums?name=<name search pattern>
Searches for autonomous system number (see Section 5.5 of [RFC9083]) Searches for autonomous system number (see Section 5.5 of [RFC9083])
information by handle are specified using the form: information by handle are specified using the form:
autnums?handle=XXXX autnums?handle=XXXX
XXXX is a search pattern representing an autonomous system number XXXX is a search pattern representing an autonomous system number
identifier whose syntax is specific to the registration provider. identifier whose syntax is specific to the registration provider.
The following URL would be used to find information for autonomous The following URL would be used to find information for autonomous
system numbers with handles matching the "AS1*" pattern: system numbers with handles matching the "AS1*" pattern:
https://example.com/rdap/autnums?handle=AS1* https://example.com/rdap/autnums?handle=AS1*
Searches for autonomous system number (see Section 5.5 of [RFC9083]) Searches for autonomous system number (see Section 5.5 of [RFC9083])
information by name are specified using the form: information by name are specified using the form:
autnums?name=XXXX autnums?name=XXXX
XXXX is a search pattern representing an autonomous system number XXXX is a search pattern representing an autonomous system number
identifier that is assigned to the autonomous system number identifier that is assigned to the autonomous system number
registration by the registration holder. The following URL would be registration by the registration holder. The following URL would be
used to find information for autonomous system numbers with names used to find information for autonomous system numbers with names
matching the "ASN-EXAMPLE-*" pattern: matching the "ASN-EXAMPLE-*" pattern:
https://example.com/rdap/autnums?name=ASN-EXAMPLE-* https://example.com/rdap/autnums?name=ASN-EXAMPLE-*
3. Relation Searches 3. Relation Searches
This section defines searches and link relations for finding objects This section defines searches and link relations for finding objects
and sets of objects with respect to their position within a and sets of objects with respect to their position within a
hierarchy. hierarchy.
3.1. Path Segments 3.1. Path Segments
The variables used in the path segments in this section include: The variables used in the path segments in this section include:
<relation>: A relation type, as defined in Section 3.2.2 of this <relation>: a relation type, as defined in Section 3.2.2 of this
document. document.
<IP address>: An IP address, as defined in Section 3.1.1 of <IP address>: an IP address, as defined in Section 3.1.1 of
[RFC9082]. [RFC9082].
<CIDR prefix>: The first address of a CIDR block, as defined in <CIDR prefix>: the first address of a Classless Inter-Domain Routing
Section 3.1.1 of [RFC9082]. (CIDR) block, as defined in Section 3.1.1 of [RFC9082].
<CIDR length>: The prefix length for a CIDR block, as defined in <CIDR length>: the prefix length for a CIDR block, as defined in
Section 3.1.1 of [RFC9082]. Section 3.1.1 of [RFC9082].
<domain name>: A fully-qualified domain name, as defined in <domain name>: a fully qualified domain name, as defined in
Section 3.1.3 of [RFC9082]. Section 3.1.3 of [RFC9082].
<autonomous system number or range>: An autonomous system number, <autonomous system number or range>: an autonomous system number, as
as defined in Section 3.1.2 of [RFC9082], or two such numbers defined in Section 3.1.2 of [RFC9082], or two such numbers
separated by a single hyphen ('-', US-ASCII value 0x2D), where the separated by a single hyphen ('-', ASCII value 0x2D), where the
second number is greater than the first. second number is greater than the first.
<resource type search path segment>: A search path segment <resource type search path segment>: a search path segment
corresponding to an Internet Number Resource (INR) object class corresponding to an Internet Number Resource (INR) object class
(i.e. an IP network address or range, autonomous system number or (i.e., an IP network address or range, autonomous system number or
number range, or reverse domain name). number range, or reverse domain name).
<object value>: a value used to identify an object for the <object value>: a value used to identify an object for the purposes
purposes of a relation search relative to that object. One of <IP of a relation search relative to that object. One of <IP
address>, <CIDR prefix> and <CIDR length> pair, <domain name>, or address>, <CIDR prefix> and <CIDR length> pair, <domain name>, or
<autonomous system number or range>, depending on the type of <autonomous system number or range>, depending on the type of
search that is being performed. search that is being performed.
<status>: an object status value, as defined in Section 4.6 of <status>: an object status value, as defined in Section 4.6 of
[RFC9083]. [RFC9083].
The new resource type path segments for relation search (similar to The new resource type path segments for relation search (similar to
the searches defined in [RFC9082] and [RFC9083]) are: the searches defined in [RFC9082] and [RFC9083]) are:
'ips/rirSearch1/<relation>/<IP address>': Used to identify an IP 'ips/rirSearch1/<relation>/<IP address>': Used to identify an IP
network search using a relation and an IP address to match a set network search using a relation and an IP address to match a set
of IP networks. of IP networks.
'ips/rirSearch1/<relation>/<CIDR prefix>/<CIDR length>': Used to 'ips/rirSearch1/<relation>/<CIDR prefix>/<CIDR length>': Used to
identify an IP network search using a relation and an IP address identify an IP network search using a relation and an IP address
range to match a set of IP networks. range to match a set of IP networks.
'autnums/rirSearch1/<relation>/<autonomous system number or 'autnums/rirSearch1/<relation>/<autonomous system number or
range>': Used to identify an autonomous system number search using range>': Used to identify an autonomous system number search using a
a relation and a single ASN or an ASN range to match a set of ASN relation and a single ASN or an ASN range to match a set of ASN
objects. objects.
'domains/rirSearch1/<relation>/<domain name>': Used to identify a 'domains/rirSearch1/<relation>/<domain name>': Used to identify a
reverse domain search using a relation and a reverse domain name reverse domain search using a relation and a reverse domain name
to match a set of reverse domains. to match a set of reverse domains.
3.2. Relation Search 3.2. Relation Search
Syntax: <resource type search path Syntax: <resource type search path
segment>/rirSearch1/<relation>/<object value>[?status=<status>] segment>/rirSearch1/<relation>/<object value>[?status=<status>]
The relation searches defined in this document rely on the syntax The relation searches defined in this document rely on the syntax
described above. Each search works in the same way for each object described above. Each search works in the same way for each object
class. class.
The rirSearch1 path segment is used in the relation search URLs in The rirSearch1 path segment is used in the relation search URLs in
order to provide a single namespace for those searches, and so that order to provide a single namespace for those searches, and so that
other searches can be defined underneath the top-level resource type other searches can be defined underneath the top-level resource type
search path segments. search path segments.
3.2.1. Definitions 3.2.1. Definitions
An INR object value may have a "parent" object and one or more An INR object value may have a "parent" object and one or more
"child" objects. The "parent" object is the next-least-specific "child" objects. The "parent" object is the next-least-specific
object that exists in the relevant registry, while the "child" object that exists in the relevant registry, while the "child"
objects are the next-most-specific objects that exist in the relevant objects are the next-most-specific objects that exist in the relevant
registry. For example, for a registry with the following IP network registry. For example, let's say there is a registry with the
objects: following IP network objects:
+--------------+ +--------------+
| 192.0.2.0/24 | | 192.0.2.0/24 |
+--------------+ +--------------+
/ \ / \
+--------------+ +----------------+ +--------------+ +----------------+
| 192.0.2.0/25 | | 192.0.2.128/25 | | 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/28 | | 192.0.2.128/26 | | 192.0.2.192/26 |
+--------------+ +----------------+ +----------------+ +--------------+ +----------------+ +----------------+
/ /
+--------------+ +--------------+
| 192.0.2.0/32 | | 192.0.2.0/32 |
+--------------+ +--------------+
Figure 1: Example registry objects
the INR object value to parent/child object relationships are: Figure 1: Example Registry Objects
The relationships of INR object value to parent object (as well as to
child objects) are:
+==================+================+ +==================+================+
| INR object value | Parent object | | INR object value | Parent object |
+==================+================+ +==================+================+
| 192.0.2.0/32 | 192.0.2.0/28 | | 192.0.2.0/32 | 192.0.2.0/28 |
+------------------+----------------+ +------------------+----------------+
| 192.0.2.0/28 | 192.0.2.0/25 | | 192.0.2.0/28 | 192.0.2.0/25 |
+------------------+----------------+ +------------------+----------------+
| 192.0.2.64/26 | 192.0.2.0/25 | | 192.0.2.64/26 | 192.0.2.0/25 |
+------------------+----------------+ +------------------+----------------+
skipping to change at page 9, line 13 skipping to change at line 389
Table 2: Child objects Table 2: Child objects
(INR object values do not necessarily correspond to registry objects, (INR object values do not necessarily correspond to registry objects,
because users can provide arbitrary object values as input to the because users can provide arbitrary object values as input to the
searches defined in this document.) searches defined in this document.)
Similarly to the parent/child object relationships, each INR object Similarly to the parent/child object relationships, each INR object
value may have a "top" object, being the least-specific covering value may have a "top" object, being the least-specific covering
object that exists in the registry, and one or more "bottom" objects, object that exists in the registry, and one or more "bottom" objects,
being the most-specific objects that entirely cover the INR object being the most-specific objects that entirely cover the INR object
value when taken together. Given the registry defined in the value when taken together. Given the registry defined above, the top
previous paragraph, the top and bottom object relationships are: and bottom object relationships are:
+==================+==============+ +==================+==============+
| INR object value | Top object | | INR object value | Top object |
+==================+==============+ +==================+==============+
| 192.0.2.0/32 | 192.0.2.0/24 | | 192.0.2.0/32 | 192.0.2.0/24 |
+------------------+--------------+ +------------------+--------------+
| 192.0.2.0/28 | 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.64/26 | 192.0.2.0/24 |
+------------------+--------------+ +------------------+--------------+
skipping to change at page 9, line 36 skipping to change at line 412
+------------------+--------------+ +------------------+--------------+
| 192.0.2.192/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.0/25 | 192.0.2.0/24 |
+------------------+--------------+ +------------------+--------------+
| 192.0.2.128/25 | 192.0.2.0/24 | | 192.0.2.128/25 | 192.0.2.0/24 |
+------------------+--------------+ +------------------+--------------+
| 192.0.2.0/24 | N/A | | 192.0.2.0/24 | N/A |
+------------------+--------------+ +------------------+--------------+
Table 3: Top objects Table 3: Top Objects
+==================+===========================================+ +==================+===========================================+
| INR object value | Bottom objects | | 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.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.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.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.128/25 | 192.0.2.128/26, 192.0.2.192/26 |
skipping to change at page 10, line 28 skipping to change at line 437
+------------------+-------------------------------------------+ +------------------+-------------------------------------------+
| 192.0.2.192/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/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/31 | 192.0.2.0/28, 192.0.2.0/32 |
+------------------+-------------------------------------------+ +------------------+-------------------------------------------+
| 192.0.2.0/32 | N/A | | 192.0.2.0/32 | N/A |
+------------------+-------------------------------------------+ +------------------+-------------------------------------------+
Table 4: Bottom objects Table 4: Bottom Objects
If there are no more-specific objects for a given INR object value, 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 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. empty. 192.0.2.0/32 is an example of such an INR object value.
It is not necessarily the case that the bottom objects for a given 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 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 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 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 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 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 object for the other addresses within the range (i.e., those aside
from 192.0.2.0/32). from 192.0.2.0/32).
The bottom objects for a given INR object value may include an object The bottom objects for a given INR object value may include an object
that is less-specific than that INR object value. For example, 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, 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 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 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 (i.e., 192.0.2.1/32) is 192.0.2.0/28, so it is included in the
as well. results as well.
3.2.2. Relations 3.2.2. Relations
3.2.2.1. Single-Result Searches 3.2.2.1. Single-Result Searches
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- If the server receives a search containing the relation value "rdap-
up", it will return the parent object for the specified INR object up", it will return the parent object for the specified INR object
value as though that object had been requested directly. If no such value as though that object had been requested directly. If no such
object exists, it will respond with a HTTP 404 (Not Found) [RFC9110] object exists, it will respond with an HTTP 404 (Not Found) [RFC9110]
search response. search response.
3.2.2.1.2. "rdap-top" 3.2.2.1.2. "rdap-top"
If the server receives a search containing the relation value "rdap- If the server receives a search containing the relation value "rdap-
top", it will return the top object for the specified INR object top", it will return the top object for the specified INR object
value as though that object had been requested directly. If no such value as though that object had been requested directly. If no such
object exists, it will respond with an HTTP 404 (Not Found) [RFC9110] object exists, it will respond with an HTTP 404 (Not Found) [RFC9110]
search response. search response.
skipping to change at page 11, line 44 skipping to change at line 502
If the server receives a search containing the relation value "rdap- If the server receives a search containing the relation value "rdap-
bottom", it will return the bottom objects for the specified INR bottom", it will return the bottom objects for the specified INR
object value. If no such objects exist, it will return an empty object value. If no such objects exist, it will return an empty
search response. search response.
3.3. Status 3.3. Status
If the "status" argument is provided, then response processing will If the "status" argument is provided, then response processing will
proceed as though all objects without the specified status had first proceed as though all objects without the specified status had first
been removed from the database. For example, if the registry objects been removed from the database. For example, if the registry objects
from section 3.2.1 had the following statuses: from Section 3.2.1 had the following statuses:
+================+==========+ +================+==========+
| Object | Status | | Object | Status |
+================+==========+ +================+==========+
| 192.0.2.0/25 | active | | 192.0.2.0/25 | active |
+----------------+----------+ +----------------+----------+
| 192.0.2.128/25 | inactive | | 192.0.2.128/25 | inactive |
+----------------+----------+ +----------------+----------+
| 192.0.2.128/26 | active | | 192.0.2.128/26 | active |
+----------------+----------+ +----------------+----------+
skipping to change at page 13, line 7 skipping to change at line 547
if it receives such a request. if it receives such a request.
While any valid status value may be used for status filtering, a 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 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 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 hold" would typically only be used by a DNR for a forward domain name
object. object.
3.4. Link Relations 3.4. Link Relations
Each of the relations defined in section 3.2.2 has a corresponding 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 link relation that can be used for a link object contained within
another RDAP object. When constructing these link objects, the another RDAP object. When constructing these link objects, the
server MUST use the corresponding search URL for the link target, or server MUST use the corresponding search URL for the link target, or
a URL that yields the same response as for the corresponding search 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 as at the time of the request. The following is an elided example of
an IPv4 response that makes use of those link relations: an IPv4 response that makes use of those link relations:
{ {
"startAddress": "192.0.2.0", "startAddress": "192.0.2.0",
"endAddress": "192.0.2.127", "endAddress": "192.0.2.127",
... ...
"links": [ "links": [
..., ...,
{ {
"value": "https://example.com/rdap/ip/192.0.2.0/25", "value": "https://example.com/rdap/ip/192.0.2.0/25",
"rel": "rdap-up", "rel": "rdap-up",
"href": ".../rdap/ips/rirSearch1/rdap-up/192.0.2.0/25", "href": ".../rdap/ips/rirSearch1/rdap-up/192.0.2.0/25",
"type": "application/rdap+json" "type": "application/rdap+json"
}, },
{ {
"value": "https://example.com/rdap/ip/192.0.2.0/25", "value": "https://example.com/rdap/ip/192.0.2.0/25",
"rel": "rdap-down", "rel": "rdap-down",
"href": ".../rdap/ips/rirSearch1/rdap-down/192.0.2.0/25", "href": ".../rdap/ips/rirSearch1/rdap-down/192.0.2.0/25",
"type": "application/rdap+json" "type": "application/rdap+json"
}, },
{ {
"value": "https://example.com/rdap/ip/192.0.2.0/25", "value": "https://example.com/rdap/ip/192.0.2.0/25",
"rel": "rdap-top", "rel": "rdap-top",
"href": ".../rdap/ips/rirSearch1/rdap-top/192.0.2.0/25", "href": ".../rdap/ips/rirSearch1/rdap-top/192.0.2.0/25",
"type": "application/rdap+json" "type": "application/rdap+json"
}, },
{ {
"value": "https://example.com/rdap/ip/192.0.2.0/25", "value": "https://example.com/rdap/ip/192.0.2.0/25",
"rel": "rdap-bottom", "rel": "rdap-bottom",
"href": ".../rdap/ips/rirSearch1/rdap-bottom/192.0.2.0/25", "href": ".../rdap/ips/rirSearch1/rdap-bottom/192.0.2.0/25",
"type": "application/rdap+json" "type": "application/rdap+json"
} }
] ]
} }
Figure 2: Example links in an IPv4 response Figure 2: Example Links in an IPv4 Response
The following is an elided example of an IPv6 response that makes use The following is an elided example of an IPv6 response that makes use
of the link relations: of the link relations:
{ {
"startAddress": "2001:db8:a::", "startAddress": "2001:db8:a::",
"endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff", "endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff",
... ...
"links": [ "links": [
..., ...,
skipping to change at page 14, line 38 skipping to change at line 626
}, },
{ {
"value": "https://example.com/rdap/ip/2001:db8:a::/48", "value": "https://example.com/rdap/ip/2001:db8:a::/48",
"rel": "rdap-bottom", "rel": "rdap-bottom",
"href": ".../rdap/ips/rirSearch1/rdap-bottom/2001:db8:a::/48", "href": ".../rdap/ips/rirSearch1/rdap-bottom/2001:db8:a::/48",
"type": "application/rdap+json" "type": "application/rdap+json"
} }
] ]
} }
Figure 3: Example links in an IPv6 response Figure 3: Example Links in an IPv6 Response
One additional link relation, "rdap-active", is defined for denoting One additional link relation, "rdap-active", is defined for denoting
a search with a "status" of "active". No other status link relations a search with a "status" of "active". No other status link relations
are defined, because the only known use cases for status filtering are defined because the only known use cases for status filtering
involve the "rdap-up" and "rdap-top" relations and the "active" involve the "rdap-up" and "rdap-top" relations and the "active"
status. The following is an elided example of an IPv4 response that status. The following is an elided example of an IPv4 response that
makes use of those link relations: makes use of those link relations:
{ {
"startAddress": "192.0.2.0", "startAddress": "192.0.2.0",
"endAddress": "192.0.2.127", "endAddress": "192.0.2.127",
... ...
"links": [ "links": [
..., ...,
{ {
"value": "https://example.com/rdap/ip/192.0.2.0/25", "value": "https://example.com/rdap/ip/192.0.2.0/25",
"rel": "rdap-up rdap-active", "rel": "rdap-up rdap-active",
"href": "href":
".../rdap/ips/rirSearch1/rdap-up/192.0.2.0/25?status=active", ".../rdap/ips/rirSearch1/rdap-up/192.0.2.0/25?status=active",
"type": "application/rdap+json" "type": "application/rdap+json"
}, },
{ {
"value": "https://example.com/rdap/ip/192.0.2.0/25", "value": "https://example.com/rdap/ip/192.0.2.0/25",
"rel": "rdap-top rdap-active", "rel": "rdap-top rdap-active",
"href": "href":
".../rdap/ips/rirSearch1/rdap-top/192.0.2.0/25?status=active", ".../rdap/ips/rirSearch1/rdap-top/192.0.2.0/25?status=active",
"type": "application/rdap+json" "type": "application/rdap+json"
} }
] ]
} }
Figure 4: Example status links in an IPv4 response Figure 4: Example Status Links in an IPv4 Response
The following is an elided example of an IPv6 response that makes use The following is an elided example of an IPv6 response that makes use
of the link relations: of the link relations:
{ {
"startAddress": "2001:db8:a::", "startAddress": "2001:db8:a::",
"endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff", "endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff",
... ...
"links": [ "links": [
..., ...,
{ {
"value": "https://example.com/rdap/ip/2001:db8:a::/48", "value": "https://example.com/rdap/ip/2001:db8:a::/48",
"rel": "rdap-up rdap-active", "rel": "rdap-up rdap-active",
"href": "href":
".../rdap/ips/rirSearch1/rdap-up/2001:db8:a::/48?status=active", ".../rdap/ips/rirSearch1/rdap-up/2001:db8:a::/48?status=active",
"type": "application/rdap+json" "type": "application/rdap+json"
}, },
{ {
"value": "https://example.com/rdap/ip/2001:db8:a::/48", "value": "https://example.com/rdap/ip/2001:db8:a::/48",
"rel": "rdap-top rdap-active", "rel": "rdap-top rdap-active",
"href": "href":
".../rdap/ips/rirSearch1/rdap-top/2001:db8:a::/48?status=active", ".../rdap/ips/rirSearch1/rdap-top/2001:db8:a::/48?status=active",
"type": "application/rdap+json" "type": "application/rdap+json"
} }
] ]
} }
Figure 5: Example status links in an IPv6 response Figure 5: Example Status Links in an IPv6 Response
"rdap-active" is used only as a link relation in a link object. It "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 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 defined in Section 3.2. Section 3.3 details status filtering for
relation search URLs. relation search URLs.
Since the "rdap-top" and "rdap-up" link relations resolve either to a 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 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 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 [RFC9082]) in the "href" attribute in the link object. The following
is an elided example of an IPv4 response that uses this approach: is an elided example of an IPv4 response that uses this approach:
{ {
"startAddress": "192.0.2.0", "startAddress": "192.0.2.0",
"endAddress": "192.0.2.127", "endAddress": "192.0.2.127",
... ...
"links": [ "links": [
..., ...,
{ {
"value": "https://example.com/rdap/ip/192.0.2.0/25", "value": "https://example.com/rdap/ip/192.0.2.0/25",
"rel": "rdap-up", "rel": "rdap-up",
"href": "https://example.com/rdap/ip/192.0.2.0/24", "href": "https://example.com/rdap/ip/192.0.2.0/24",
"type": "application/rdap+json" "type": "application/rdap+json"
} }
] ]
} }
Figure 6: Example single-result links in an IPv4 response Figure 6: Example Single-Result Links in an IPv4 Response
The following is an elided example of an IPv6 response that makes use The following is an elided example of an IPv6 response that makes use
of the approach: of the approach:
{
"startAddress": "2001:db8:a::",
"endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff",
...
"links": [
...,
{ {
"startAddress": "2001:db8:a::", "value": "https://example.com/rdap/ip/2001:db8:a::/48",
"endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff", "rel": "rdap-up",
... "href": "https://example.com/rdap/ip/2001:db8::/32",
"links": [ "type": "application/rdap+json"
...,
{
"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 Figure 7: Example single-result links in an IPv6 response
Use of these link relations in responses is OPTIONAL. The absence in Use of these link relations in responses is OPTIONAL. The absence in
a response of a link for a specific relation does not necessarily a response of a link for a specific relation does not necessarily
mean that the corresponding search will return no results. mean that the corresponding search will return no results.
4. Responding To Searches 4. Responding to Searches
4.1. Single-Result Searches 4.1. Single-Result Searches
The "rdap-up" and "rdap-top" relations are single-result searches. The "rdap-up" and "rdap-top" relations are single-result searches.
When processing these searches, if there is a result for the search, When processing these searches, if there is a result for the search,
the server returns that object as though it were requested directly 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 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) result for the search, the server returns an HTTP 404 (Not Found)
[RFC9110] response code. [RFC9110] response code.
4.2. Multiple-Result Searches 4.2. Multiple-Result Searches
skipping to change at page 18, line 28 skipping to change at line 766
appropriate object class for the search (i.e., a search beginning appropriate object class for the search (i.e., a search beginning
with /ips yields an array of IP network object instances, and a with /ips yields an array of IP network object instances, and a
search beginning with /autnums yields an array of autonomous system search beginning with /autnums yields an array of autonomous system
number object instances). The IP network object class is defined in number object instances). The IP network object class is defined in
Section 5.4 of [RFC9083], and the autonomous system number object Section 5.4 of [RFC9083], and the autonomous system number object
class is defined in Section 5.5 of [RFC9083]. The object instance class is defined in Section 5.5 of [RFC9083]. The object instance
arrays are contained within the response object. arrays are contained within the response object.
The names of the arrays are as follows: The names of the arrays are as follows:
for /ips searches, the array is "ipSearchResults"; and * for /ips searches, the array is "ipSearchResults"; and
for /autnums searches, the array is "autnumSearchResults". * for /autnums searches, the array is "autnumSearchResults".
The following is an elided example of a response for an IPv4 network The following is an elided example of a response for an IPv4 network
search: search:
{ {
"rdapConformance": [ "rdap_level_0", "rirSearch1", "rdapConformance": [ "rdap_level_0", "rirSearch1",
"ips", "ipSearchResults", ... ], "ips", "ipSearchResults", ... ],
... ...
"ipSearchResults": [ "ipSearchResults": [
{ {
skipping to change at page 19, line 27 skipping to change at line 795
{ {
"objectClassName": "ip network", "objectClassName": "ip network",
"handle": "YYYY-RIR", "handle": "YYYY-RIR",
"startAddress": "192.0.2.0", "startAddress": "192.0.2.0",
"endAddress": "192.0.2.255", "endAddress": "192.0.2.255",
... ...
} }
] ]
} }
Figure 8: IPv4 network search response Figure 8: IPv4 Network Search Response
The following is an elided example of a response for an IPv6 network The following is an elided example of a response for an IPv6 network
search: search:
{ {
"rdapConformance": [ "rdap_level_0", "rirSearch1", "rdapConformance": [ "rdap_level_0", "rirSearch1",
"ips", "ipSearchResults", ... ], "ips", "ipSearchResults", ... ],
... ...
"ipSearchResults": [ "ipSearchResults": [
{ {
skipping to change at page 20, line 4 skipping to change at line 821
}, },
{ {
"objectClassName": "ip network", "objectClassName": "ip network",
"handle": "YYYY-RIR", "handle": "YYYY-RIR",
"startAddress": "2001:db8::", "startAddress": "2001:db8::",
"endAddress": "2001:db8:ffff:ffff:ffff:ffff:ffff:ffff", "endAddress": "2001:db8:ffff:ffff:ffff:ffff:ffff:ffff",
... ...
} }
] ]
} }
Figure 9: IPv6 network search response
Figure 9: IPv6 Network Search Response
The following is an elided example of a response to an autonomous The following is an elided example of a response to an autonomous
system number search: system number search:
{ {
"rdapConformance": [ "rdap_level_0", "rirSearch1", "rdapConformance": [ "rdap_level_0", "rirSearch1",
"autnums", "autnumSearchResults", ... ], "autnums", "autnumSearchResults", ... ],
... ...
"autnumSearchResults": [ "autnumSearchResults": [
{ {
skipping to change at page 20, line 31 skipping to change at line 849
{ {
"objectClassName": "autnum", "objectClassName": "autnum",
"handle": "YYYY-RIR", "handle": "YYYY-RIR",
"startAutnum": "64497", "startAutnum": "64497",
"endAutnum": "64497", "endAutnum": "64497",
... ...
} }
] ]
} }
Figure 10: ASN search response Figure 10: ASN Search Response
Responses for relation searches for reverse domain objects have the Responses for relation searches for reverse domain objects have the
same form as for a standard domain search response, per [RFC9083]. same form as for a standard domain search response, per [RFC9083].
If the search can be processed by the server, but there are no 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 results for the search, then the server returns an HTTP 404 (Not
Found) [RFC9110] response code, with the body of the response Found) [RFC9110] response code, with the body of the response
containing an empty results array. containing an empty results array.
5. Reverse Search 5. Reverse Search
skipping to change at page 21, line 8 skipping to change at line 874
numbers as well. numbers as well.
If a server receives a reverse search query with a searchable If a server receives a reverse search query with a searchable
resource type (per the definition of that term in [RFC9536]) of resource type (per the definition of that term in [RFC9536]) of
"ips", then the reverse search will be performed on the IP network "ips", then the reverse search will be performed on the IP network
objects from its data store. Similarly, if a server receives a objects from its data store. Similarly, if a server receives a
reverse search query with a searchable resource type of "autnums", reverse search query with a searchable resource type of "autnums",
then the reverse search will be performed on the autonomous system then the reverse search will be performed on the autonomous system
number objects from its data store. number objects from its data store.
Additionally, Section 10 includes requests to register new entries Additionally, Section 10 notes that new registrations for IP network
for IP network and autonomous system number searches in the RDAP and autonomous system number searches have been made in the "RDAP
Reverse Search and RDAP Reverse Search Mapping IANA registries. Reverse Search" and "RDAP Reverse Search Mapping" IANA registries.
6. RDAP Conformance 6. RDAP Conformance
A server that supports the functionality specified in this document A server that supports the functionality specified in this document
MUST include additional string literals in the rdapConformance array MUST include additional string literals in the rdapConformance array
of its responses, in accordance with the following: of its responses, in accordance with the following:
* any response that includes an IP network basic search link, an IP * any response that includes an IP network basic search link, an IP
network relation search link, or an IP network reverse search link network relation search link, or an IP network reverse search link
includes the "rirSearch1" and "ips" literals; includes the "rirSearch1" and "ips" literals;
skipping to change at page 22, line 47 skipping to change at line 961
generation. If there is no change to the relevant database state generation. If there is no change to the relevant database state
between the time when the original response is generated and the time between the time when the original response is generated and the time
when the client resolves the link relation target, then the search when the client resolves the link relation target, then the search
URL and the lookup URL will lead to the same result. However, if 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 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 may lead to a different result from that of the search URL. Server
operators should consider which type of URL will be more effective operators should consider which type of URL will be more effective
for their clients when implementing this specification. for their clients when implementing this specification.
Where this document includes HTTP reason phrases, that is purely for Where this document includes HTTP reason phrases, that is purely for
the benefit of the reader, and is not an indication that those the benefit of the reader and is not an indication that those phrases
phrases need to be used as-is in responses. need to be used as-is in responses.
8. Privacy Considerations 8. Privacy Considerations
The search functionality defined in this document may affect the The search functionality defined in this document may affect the
privacy of entities in the registry (and elsewhere) in various ways: privacy of entities in the registry (and elsewhere) in various ways:
see [RFC6973] for a general treatment of privacy in protocol see [RFC6973] for a general treatment of privacy in protocol
specifications, and [RFC7481] for specific discussion about privacy specifications, and [RFC7481] for specific discussion about privacy
threats with respect to the registration data provided by RDAP. threats with respect to the registration data provided by RDAP.
Server operators should be aware of the tradeoffs that result from Server operators should be aware of the tradeoffs that result from
implementation of this functionality. implementation of this functionality.
skipping to change at page 23, line 35 skipping to change at line 994
since that document was published: see [RFC8446] and [BCP195] for since that document was published: see [RFC8446] and [BCP195] for
further detail. further detail.
[RFC9082] includes security considerations relating to object [RFC9082] includes security considerations relating to object
retrieval in RDAP. Those considerations are relevant here as well. retrieval in RDAP. Those considerations are relevant here as well.
10. IANA Considerations 10. IANA Considerations
10.1. RDAP Extensions Registry 10.1. RDAP Extensions Registry
IANA is requested to register the following values in the RDAP IANA has registered the following values in the "RDAP Extensions"
Extensions Registry (https://www.iana.org/assignments/rdap- registry <https://www.iana.org/assignments/rdap-extensions>.
extensions/rdap-extensions.xhtml).
10.1.1. rirSearch1 10.1.1. rirSearch1
Extension identifier: rirSearch1 Extension Identifier: rirSearch1
Registry operator: Any Registry operator: Any
Published specification: [this document] Specification: RFC 9910
Contact: IETF <iesg@ietf.org> Contact: IETF <iesg@ietf.org>
Intended usage: This extension identifier is used for INR-specific Intended Usage: This extension identifier is used for INR-specific
search operations. search operations.
10.1.2. ips 10.1.2. ips
Extension identifier: ips Extension Identifier: ips
Registry operator: Any Registry operator: Any
Published specification: [this document] Specification: RFC 9910
Contact: IETF <iesg@ietf.org> Contact: IETF <iesg@ietf.org>
Intended usage: This extension identifier is used for INR-specific Intended Usage: This extension identifier is used for INR-specific
search operations. search operations.
10.1.3. autnums 10.1.3. autnums
Extension identifier: autnums Extension Identifier: autnums
Registry operator: Any Registry operator: Any
Published specification: [this document] Specification: RFC 9910
Contact: IETF <iesg@ietf.org> Contact: IETF <iesg@ietf.org>
Intended usage: This extension identifier is used for INR-specific Intended Usage: This extension identifier is used for INR-specific
search operations. search operations.
10.1.4. ipSearchResults 10.1.4. ipSearchResults
Extension identifier: ipSearchResults Extension Identifier: ipSearchResults
Registry operator: Any Registry operator: Any
Published specification: [this document] Specification: RFC 9910
Contact: IETF <iesg@ietf.org> Contact: IETF <iesg@ietf.org>
Intended usage: This extension identifier is used for INR-specific Intended Usage: This extension identifier is used for INR-specific
search operations. search operations.
10.1.5. autnumSearchResults 10.1.5. autnumSearchResults
Extension identifier: autnumSearchResults Extension Identifier: autnumSearchResults
Registry operator: Any Registry operator: Any
Published specification: [this document] Specification: RFC 9910
Contact: IETF <iesg@ietf.org> Contact: IETF <iesg@ietf.org>
Intended usage: This extension identifier is used for INR-specific Intended Usage: This extension identifier is used for INR-specific
search operations. search operations.
10.2. Link Relations Registry 10.2. Link Relations Registry
IANA is requested to register the following values in the Link IANA has registered the following values in the "Link Relations"
Relations Registry (https://www.iana.org/assignments/link-relations/ registry <https://www.iana.org/assignments/link-relations>.
link-relations.xhtml).
10.2.1. rdap-up 10.2.1. rdap-up
Relation Name: rdap-up Relation Name: rdap-up
Description: Refers to an RDAP parent object in a hierarchy of Description: Refers to an RDAP parent object in a hierarchy of
objects. objects.
Reference: [this document] Reference: RFC 9910
10.2.2. rdap-down 10.2.2. rdap-down
Relation Name: rdap-down Relation Name: rdap-down
Description: Refers to a set of RDAP child objects in a hierarchy of Description: Refers to a set of RDAP child objects in a hierarchy of
objects. objects.
Reference: [this document] Reference: RFC 9910
10.2.3. rdap-top 10.2.3. rdap-top
Relation Name: rdap-top Relation Name: rdap-top
Description: Refers to the topmost RDAP parent object in a hierarchy Description: Refers to the topmost RDAP parent object in a hierarchy
of objects. of objects.
Reference: [this document] Reference: RFC 9910
10.2.4. rdap-bottom 10.2.4. rdap-bottom
Relation Name: rdap-bottom Relation Name: rdap-bottom
Description: Refers to the set of child RDAP objects that do not Description: Refers to the set of child RDAP objects that do not
themselves have child objects, in a hierarchy of objects. themselves have child objects, in a hierarchy of objects.
Reference: [this document] Reference: RFC 9910
10.2.5. rdap-active 10.2.5. rdap-active
Relation Name: rdap-active Relation Name: rdap-active
Description: The target is for an RDAP RIR search that filters for Description: The target is for an RDAP RIR search that filters for
the status "active". the status "active".
Reference: [this document] Reference: RFC 9910
10.3. RDAP Reverse Search Registry 10.3. RDAP Reverse Search Registry
IANA is requested to register the following entries in the RDAP IANA has registered the following entries in the "RDAP Reverse
Reverse Search (https://www.iana.org/assignments/rdap-reverse-search/ Search" <https://www.iana.org/assignments/rdap-reverse-search/>
rdap-reverse-search.xhtml) registry. registry.
10.3.1. fn 10.3.1. fn
Property: fn Property: fn
Description: The server supports the IP/autnum search based on the Description: The server supports the IP/autnum search based on the
full name (a.k.a formatted name) of an associated entity. full name (a.k.a. formatted name) of an associated entity.
Searchable Resource Type: ips, autnums Searchable Resource Type: ips, autnums
Related Resource Type: entity Related Resource Type: entity
Registrant: IETF Registrant: IETF
Contact Information: iesg@ietf.org Contact Information: iesg@ietf.org
Reference: [this document] Reference: RFC 9910
10.3.2. handle 10.3.2. handle
Property: handle Property: handle
Description: The server supports the IP/autnum search based on the Description: The server supports the IP/autnum search based on the
handle of an associated entity. handle of an associated entity.
Searchable Resource Type: ips, autnums Searchable Resource Type: ips, autnums
Related Resource Type: entity Related Resource Type: entity
Registrant: IETF Registrant: IETF
Contact Information: iesg@ietf.org Contact Information: iesg@ietf.org
Reference: [this document] Reference: RFC 9910
10.3.3. email 10.3.3. email
Property: email Property: email
Description: The server supports the IP/autnum search based on the Description: The server supports the IP/autnum search based on the
email address of an associated entity. email address of an associated entity.
Searchable Resource Type: ips, autnums Searchable Resource Type: ips, autnums
Related Resource Type: entity Related Resource Type: entity
Registrant: IETF Registrant: IETF
Contact Information: iesg@ietf.org Contact Information: iesg@ietf.org
Reference: [this document] Reference: RFC 9910
10.3.4. role 10.3.4. role
Property: role Property: role
Description: The server supports the IP/autnum search based on the Description: The server supports the IP/autnum search based on the
role of an associated entity. role of an associated entity.
Searchable Resource Type: ips, autnums Searchable Resource Type: ips, autnums
Related Resource Type: entity Related Resource Type: entity
Registrant: IETF Registrant: IETF
Contact Information: iesg@ietf.org Contact Information: iesg@ietf.org
Reference: [this document] Reference: RFC 9910
10.4. RDAP Reverse Search Mapping Registry 10.4. RDAP Reverse Search Mapping Registry
IANA is requested to register the following entries in the RDAP IANA has registered the following entries in the "RDAP Reverse Search
Reverse Search Mapping (https://www.iana.org/assignments/rdap- Mapping" <https://www.iana.org/assignments/rdap-reverse-search-
reverse-search-mapping/rdap-reverse-search-mapping.xhtml) registry. mapping> registry.
10.4.1. fn 10.4.1. fn
Property: fn Property: fn
Property Path: $.entities[*].vcardArray[1][?(@[0]=='fn')][3] Property Path: $.entities[*].vcardArray[1][?(@[0]=='fn')][3]
Searchable Resource Type: ips, autnums Searchable Resource Type: ips, autnums
Related Resource Type: entity Related Resource Type: entity
Registrant: IETF Registrant: IETF
Contact Information: iesg@ietf.org Contact Information: iesg@ietf.org
Reference: [this document] Reference: RFC 9910
10.4.2. handle 10.4.2. handle
Property: handle Property: handle
Property Path: $.entities[*].handle Property Path: $.entities[*].handle
Searchable Resource Type: ips, autnums Searchable Resource Type: ips, autnums
Related Resource Type: entity Related Resource Type: entity
Registrant: IETF Registrant: IETF
Contact Information: iesg@ietf.org Contact Information: iesg@ietf.org
Reference: [this document] Reference: RFC 9910
10.4.3. email 10.4.3. email
Property: email Property: email
Property Path: $.entities[*].vcardArray[1][?(@[0]=='email')][3] Property Path: $.entities[*].vcardArray[1][?(@[0]=='email')][3]
Searchable Resource Type: ips, autnums Searchable Resource Type: ips, autnums
Related Resource Type: entity Related Resource Type: entity
Registrant: IETF Registrant: IETF
Contact Information: iesg@ietf.org Contact Information: iesg@ietf.org
Reference: [this document] Reference: RFC 9910
10.4.4. role 10.4.4. role
Property: role Property: role
Property Path: $.entities[*].roles Property Path: $.entities[*].roles
Searchable Resource Type: ips, autnums Searchable Resource Type: ips, autnums
Related Resource Type: entity Related Resource Type: entity
Registrant: IETF Registrant: IETF
Contact Information: iesg@ietf.org Contact Information: iesg@ietf.org
Reference: [this document] Reference: RFC 9910
11. Implementation Status
| Note to the RFC Editor - remove this section before
| publication, as well as the reference to RFC 7942.
This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in [RFC7942].
The description of implementations in this section is intended to
assist the IETF in its decision processes in progressing drafts to
RFCs. Please note that the listing of any individual implementation
here does not imply endorsement by the IETF. Furthermore, no effort
has been spent to verify the information presented here that was
supplied by IETF contributors. This is not intended as, and must not
be construed to be, a catalogue of available implementations or their
features. Readers are advised to note that other implementations may
exist.
According to [RFC7942], "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as
they see fit".
11.1. APNIC RDAP Implementation
* Responsible Organization: Asia-Pacific Network Information Centre
(APNIC)
* Location: https://github.com/APNIC-net/rdap-rmp-demo/tree/rir-
search
* Description: This implementation includes support for the various
searches and responses described in this document.
* Level of Maturity: This is a proof-of-concept implementation.
* Coverage: This implementation includes all of the features
described in this specification.
* Contact Information: Tom Harrison, tomh@apnic.net
11.2. RIPE NCC RDAP Implementation
* Responsible Organization: RIPE NCC
* Location: https://github.com/RIPE-NCC/whois
* Description: This implementation includes support for several of
the searches and responses as at version 14 of this document.
* Level of Maturity: This is a production implementation.
* Coverage: This implementation includes IP and domain relation
searches, as well as the links that correspond to those searches.
* Contact Information: Ed Shryane, eshryane@ripe.net
12. 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.
13. References 11. References
13.1. Normative References 11.1. Normative References
[BCP195] Best Current Practice 195, [BCP195] Best Current Practice 195,
<https://www.rfc-editor.org/info/bcp195>. <https://www.rfc-editor.org/info/bcp195>.
At the time of writing, this BCP comprises the following: At the time of writing, this BCP comprises the following:
Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS Moriarty, K. and S. Farrell, "Deprecating TLS 1.0 and TLS
1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021, 1.1", BCP 195, RFC 8996, DOI 10.17487/RFC8996, March 2021,
<https://www.rfc-editor.org/info/rfc8996>. <https://www.rfc-editor.org/info/rfc8996>.
Sheffer, Y., Saint-Andre, P., and T. Fossati, Sheffer, Y., Saint-Andre, P., and T. Fossati,
skipping to change at page 29, line 49 skipping to change at line 1234
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, [RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110, Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>. <https://www.rfc-editor.org/info/rfc9110>.
[RFC9536] Loffredo, M. and M. Martinelli, "Registration Data Access [RFC9536] Loffredo, M. and M. Martinelli, "Registration Data Access
Protocol (RDAP) Reverse Search", RFC 9536, Protocol (RDAP) Reverse Search", RFC 9536,
DOI 10.17487/RFC9536, April 2024, DOI 10.17487/RFC9536, April 2024,
<https://www.rfc-editor.org/info/rfc9536>. <https://www.rfc-editor.org/info/rfc9536>.
13.2. Informative References 11.2. Informative References
[RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912,
DOI 10.17487/RFC3912, September 2004, DOI 10.17487/RFC3912, September 2004,
<https://www.rfc-editor.org/info/rfc3912>. <https://www.rfc-editor.org/info/rfc3912>.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973, Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013, DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>. <https://www.rfc-editor.org/info/rfc6973>.
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
Registration Data Access Protocol (RDAP)", STD 95, Registration Data Access Protocol (RDAP)", STD 95,
RFC 7480, DOI 10.17487/RFC7480, March 2015, RFC 7480, DOI 10.17487/RFC7480, March 2015,
<https://www.rfc-editor.org/info/rfc7480>. <https://www.rfc-editor.org/info/rfc7480>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Acknowledgements
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016, The authors wish to thank Mario Loffredo, Andy Newton, Antoin
<https://www.rfc-editor.org/info/rfc7942>. 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.
Authors' Addresses Authors' Addresses
Tom Harrison Tom Harrison
Asia Pacific Network Information Centre Asia Pacific Network Information Centre
6 Cordelia St 6 Cordelia St
South Brisbane QLD 4101 South Brisbane QLD 4101
Australia Australia
Email: tomh@apnic.net Email: tomh@apnic.net
 End of changes. 117 change blocks. 
367 lines changed or deleted 311 lines changed or added

This html diff was produced by rfcdiff 1.48.