rfc9910xml2.original.xml   rfc9910.xml 
<?xml version="1.0" encoding="utf-8"?> <?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.2119.xml">
<!ENTITY RFC3912 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.3912.xml">
<!ENTITY RFC6973 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.6973.xml">
<!ENTITY RFC9110 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.9110.xml">
<!ENTITY RFC7481 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7481.xml">
<!ENTITY RFC7480 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7480.xml">
<!ENTITY RFC7942 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.7942.xml">
<!ENTITY RFC8446 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8446.xml">
<!ENTITY RFC9082 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.9082.xml">
<!ENTITY RFC9083 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.9083.xml">
<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.8174.xml">
<!ENTITY RFC9536 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
.9536.xml">
<!ENTITY BCP195 SYSTEM "https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.0
195.xml">
<!DOCTYPE rfc [
<!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;">
]> ]>
<?rfc strict="yes" ?>
<?rfc toc="yes"?> <rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ie
<?rfc tocdepth="4"?> tf-regext-rdap-rir-search-19" number="9910" consensus="true" ipr="trust200902"
<?rfc symrefs="yes"?> obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" to
<?rfc sortrefs="yes" ?> cDepth="4" symRefs="true" sortRefs="true" version="3">
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<rfc category="std" docName="draft-ietf-regext-rdap-rir-search-19" ipr="trust200
902">
<front> <front>
<title abbrev="RDAP RIR Search">Registration Data Access Protocol (RDAP) Reg ional Internet Registry (RIR) Search</title> <title abbrev="RDAP RIR Search">Registration Data Access Protocol (RDAP) Reg ional Internet Registry (RIR) Search</title>
<seriesInfo name="RFC" value="9910"/>
<author initials="T." surname="Harrison" fullname="Tom Harrison"> <author initials="T." surname="Harrison" fullname="Tom Harrison">
<organization abbrev="APNIC">Asia Pacific Network Information Centre</or <organization abbrev="APNIC">Asia Pacific Network Information Centre</orga
ganization> nization>
<address> <address>
<postal> <postal>
<street>6 Cordelia St</street> <street>6 Cordelia St</street>
<city>South Brisbane</city> <city>South Brisbane</city>
<code>4101</code> <code>4101</code>
<country>Australia</country> <country>Australia</country>
<region>QLD</region> <region>QLD</region>
</postal> </postal>
<email>tomh@apnic.net</email> <email>tomh@apnic.net</email>
</address> </address>
</author> </author>
<author initials="J." fullname="Jasdip Singh" surname="Singh"> <author initials="J." fullname="Jasdip Singh" surname="Singh">
<organization abbrev="ARIN">American Registry for Internet Numbers</orga <organization abbrev="ARIN">American Registry for Internet Numbers</organi
nization> zation>
<address>
<address> <postal>
<postal> <street>PO Box 232290</street>
<street>PO Box 232290</street> <city>Centreville</city>
<city>Centreville</city> <region>VA</region>
<region>VA</region> <code>20120</code>
<code>20120</code> <country>United States of America</country>
<country>United States of America</country> </postal>
</postal> <email>jasdips@arin.net</email>
<email>jasdips@arin.net</email> </address>
</address>
</author> </author>
<date month="December" year="2025"/>
<area>ART</area>
<workgroup>regext</workgroup>
<area>General</area> <!-- [rfced] Please insert any keywords (beyond those that appear in
<workgroup>Internet Engineering Task Force</workgroup> the title) for use on https://www.rfc-editor.org/search. -->
<keyword>template</keyword>
<abstract> <keyword>example</keyword>
<t>
<abstract>
<t>
The Registration Data Access Protocol (RDAP) is used by The Registration Data Access Protocol (RDAP) is used by
Regional Internet Registries (RIRs) and Domain Name Regional Internet Registries (RIRs) and Domain Name
Registries (DNRs) to provide access to their resource Registries (DNRs) to provide access to their resource
registration information. The core specifications for registration information. The core specifications for
RDAP define basic search functionality, but there are RDAP define basic search functionality, but there are
various search options related to IP addresses, IP various search options related to IP addresses, IP
prefixes, and ASNs, which are provided by RIRs via their prefixes, and Autonomous System Numbers (ASNs), which are provided b
Whois services, but for which there is no corresponding y RIRs via their
WHOIS services, but for which there is no corresponding
RDAP functionality. This document extends RDAP to support RDAP functionality. This document extends RDAP to support
those search options. those search options.
</t> </t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<section anchor="introduction" title="Introduction"> <section anchor="introduction" numbered="true" toc="default">
<t> <name>Introduction</name>
<t>
The <xref target="RFC7480">Registration Data Access The <xref target="RFC7480" format="default">Registration Data Access
Protocol (RDAP)</xref> is used by Regional Internet Protocol (RDAP)</xref> is used by Regional Internet
Registries (RIRs) and Domain Name Registries (DNRs) to Registries (RIRs) and Domain Name Registries (DNRs) to
provide access to their resource registration information. provide access to their resource registration information.
The core specifications for RDAP define basic search The core specifications for RDAP define basic search
functionality, but this is limited to domains, functionality, but this is limited to domains,
nameservers, and entities. No searches were defined for nameservers, and entities. No searches were defined for
IP networks or autonomous system numbers. In an effort to IP networks or autonomous system numbers. In an effort to
have RDAP reach feature parity with the existing RIR Whois have RDAP reach feature parity with the existing RIR WHOIS
<xref target="RFC3912" format="default" sectionFormat="of" <xref target="RFC3912" format="default" sectionFormat="of" derivedCo
derivedContent="RFC3912"/> ntent="RFC3912"/>
services in this respect, this document defines additional services in this respect, this document defines additional
search options for IP networks and autonomous system search options for IP networks and autonomous system
numbers. numbers.
</t> </t>
<t>
<t>
While this document is in terms of RIRs and DNRs for the While this document is written in terms of RIRs and DNRs for the
sake of consistency with earlier RDAP documents such as <xref sake of consistency with earlier RDAP documents such as <xref target
target="RFC9082" /> and <xref target="RFC9083" />, the ="RFC9082" format="default"/> and <xref target="RFC9083" format="default"/>, the
functionality described here may be used by any RDAP functionality described here may be used by any RDAP
server operator that hosts Internet Number Resource (INR) server operator that hosts Internet Number Resource (INR)
objects. objects.
</t>
<section anchor="conventions" numbered="true" toc="default">
<name>Conventions Used in This Document</name>
<t>
The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>
",
"<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
be
interpreted as described in BCP&nbsp;14 <xref target="RFC2119"/> <xref
target="RFC8174"/> when, and only when, they appear in all capitals, as
shown here.
</t> </t>
<section anchor="conventions" numbered="true" toc="default"> <t>Indentation and whitespace in examples are provided
<name>Conventions Used in This Document</name> only to illustrate element relationships, and they are not a
<t>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 <xref
target="RFC2119" format="default"/> <xref target="RFC8174"
format="default"/> when, and only when, they appear in all
capitals, as shown here.</t>
<t>Indentation and whitespace in examples are provided
only to illustrate element relationships, and are not a
required feature of this protocol.</t> required feature of this protocol.</t>
<t>"..." in examples is used as shorthand for elements
<t>"..." in examples is used as shorthand for elements
defined outside of this document, as well as to abbreviate defined outside of this document, as well as to abbreviate
elements that are too long.</t> elements that are too long.</t>
</section> </section>
</section> </section>
<section numbered="true" toc="default">
<section title="Basic Searches"> <name>Basic Searches</name>
<section numbered="true" toc="default">
<section title="Path Segments"> <name>Path Segments</name>
<t>
<t>
The new resource type path segments for basic search (similar to The new resource type path segments for basic search (similar to
the searches defined in <xref target="RFC9082" /> and <xref the searches defined in <xref target="RFC9082" format="default"/
target="RFC9083" />) are: > and <xref target="RFC9083" format="default"/>) are:
<list>
<t>
'ips': Used to identify an IP network search using
a pattern to match one of a set of IP network
attributes.
</t>
<t>
'autnums': Used to identify an autonomous system
number search using a pattern to match one of a
set of autonomous system number attributes.
</t>
</list>
</t>
<t> </t>
<dl spacing="normal" newline="false">
<dt>'ips':</dt><dd>Used to identify an IP network search using a pattern to
match one of a set of IP network attributes.</dd>
<dt>'autnums':</dt><dd>Used to identify an autonomous system number search
using a pattern to match one of a set of autonomous system number
attributes.</dd>
</dl>
<t>
A search pattern matches a value where it equals the A search pattern matches a value where it equals the
string representation of the value, or where it is a string representation of the value, or where it is a
match for the value in accordance with the use of the match for the value in accordance with the use of the
asterisk ('*', US-ASCII value 0x2A) character for asterisk ('*', ASCII value 0x2A) character for
partial string matching as defined in <xref partial string matching as defined in <xref target="RFC9082" sec
target="RFC9082" sectionFormat="of" section="4.1" />. tionFormat="of" section="4.1" format="default"/>.
For most searches, '*' may be used to match trailing For most searches, '*' may be used to match trailing
characters only, and may appear in a search only once: characters only, and may appear in a search only once:
see the previously-mentioned section for a complete see the previously mentioned section for a complete
definition of the relevant behaviour. definition of the relevant behaviour.
</t> </t>
<t>
<t>
<xref target="RFC9082" sectionFormat="of" <xref target="RFC9082" sectionFormat="of" section="4.1" format="
section="4.1" /> describes the use of a trailing default"/> describes the use of a trailing
domain label suffix in a partial string search. It is domain label suffix in a partial string search. It is
not necessary that servers support this type of search not necessary that servers support this type of search
pattern for the basic searches defined in this pattern for the basic searches defined in this
document, since those searches do not relate to domain document, since those searches do not relate to domain
name members. name members.
</t> </t>
</section>
</section> <section numbered="true" toc="default">
<name>IP Network Search</name>
<section title="IP Network Search">
<t>
Syntax: ips?handle=&lt;handle search pattern&gt;
</t>
<t>
Syntax: ips?name=&lt;name search pattern&gt;
</t>
<t> <dl spacing="normal" newline="false">
<dt>Syntax:</dt><dd>ips?handle=&lt;handle search pattern&gt;</dd>
<dt>Syntax:</dt><dd>ips?name=&lt;name search pattern&gt;</dd>
</dl>
<t>
Searches for IP network (see <xref target="RFC9083" Searches for IP network (see <xref target="RFC9083" sectionForma
sectionFormat="of" section="5.4" />) information by t="of" section="5.4" format="default"/>) information by
handle are specified using the form: handle are specified using the form:
</t> </t>
<t indent="3">
<t>
ips?handle=XXXX ips?handle=XXXX
</t> </t>
<t>
<t>
XXXX is a search pattern representing an IP network XXXX is a search pattern representing an IP network
identifier whose syntax is specific to the identifier whose syntax is specific to the
registration provider. The following URL would be registration provider. The following URL would be
used to find information for IP networks with handles used to find information for IP networks with handles
matching the "NET-199*" pattern: matching the "NET-199*" pattern:
</t> </t>
<t indent="3">
<t>
https://example.com/rdap/ips?handle=NET-199* https://example.com/rdap/ips?handle=NET-199*
</t> </t>
<t>
<t>
Searches for IP network (see <xref target="RFC9083" Searches for IP network (see <xref target="RFC9083" sectionForma
sectionFormat="of" section="5.4" />) information by t="of" section="5.4" format="default"/>) information by
name are specified using the form: name are specified using the form:
</t> </t>
<t indent="3">
<t>
ips?name=XXXX ips?name=XXXX
</t> </t>
<t>
<t>
XXXX is a search pattern representing an IP network XXXX is a search pattern representing an IP network
identifier that is assigned to the network identifier that is assigned to the network
registration by the registration holder. The registration by the registration holder. The
following URL would be used to find information for IP following URL would be used to find information for IP
networks with names matching the "NET-EXAMPLE-*" networks with names matching the "NET-EXAMPLE-*"
pattern: pattern:
</t> </t>
<t indent="3">
<t>
https://example.com/rdap/ips?name=NET-EXAMPLE-* https://example.com/rdap/ips?name=NET-EXAMPLE-*
</t> </t>
</section>
</section> <section numbered="true" toc="default">
<name>Autonomous System Number Search</name>
<section title="Autonomous System Number Search">
<t>
Syntax: autnums?handle=&lt;handle search pattern&gt;
</t>
<t>
Syntax: autnums?name=&lt;name search pattern&gt;
</t>
<t> <dl spacing="normal" newline="false">
<dt>Syntax:</dt><dd>autnums?handle=&lt;handle search pattern&gt;</dd>
<dt>Syntax:</dt><dd>autnums?name=&lt;name search pattern&gt;</dd>
</dl>
Searches for autonomous system number (see <xref <t>
target="RFC9083" sectionFormat="of" section="5.5" />) Searches for autonomous system number (see <xref target="RFC9083
" sectionFormat="of" section="5.5" format="default"/>)
information by handle are specified using the form: information by handle are specified using the form:
</t> </t>
<t indent="3">
<t>
autnums?handle=XXXX autnums?handle=XXXX
</t> </t>
<t>
<t>
XXXX is a search pattern representing an autonomous XXXX is a search pattern representing an autonomous
system number identifier whose syntax is specific to system number identifier whose syntax is specific to
the registration provider. The following URL would be the registration provider. The following URL would be
used to find information for autonomous system numbers used to find information for autonomous system numbers
with handles matching the "AS1*" pattern: with handles matching the "AS1*" pattern:
</t> </t>
<t indent="3">
<t>
https://example.com/rdap/autnums?handle=AS1* https://example.com/rdap/autnums?handle=AS1*
</t> </t>
<t>
<t>
Searches for autonomous system number (see <xref Searches for autonomous system number (see <xref target="RFC9083
target="RFC9083" sectionFormat="of" section="5.5" />) " sectionFormat="of" section="5.5" format="default"/>)
information by name are specified using the form: information by name are specified using the form:
</t> </t>
<t indent="3">
<t>
autnums?name=XXXX autnums?name=XXXX
</t> </t>
<t>
<t>
XXXX is a search pattern representing an autonomous XXXX is a search pattern representing an autonomous
system number identifier that is assigned to the system number identifier that is assigned to the
autonomous system number registration by the autonomous system number registration by the
registration holder. The following URL would be used registration holder. The following URL would be used
to find information for autonomous system numbers with to find information for autonomous system numbers with
names matching the "ASN-EXAMPLE-*" pattern: names matching the "ASN-EXAMPLE-*" pattern:
</t> </t>
<t indent="3">
<t>
https://example.com/rdap/autnums?name=ASN-EXAMPLE-* https://example.com/rdap/autnums?name=ASN-EXAMPLE-*
</t> </t>
</section>
</section>
</section> </section>
<section numbered="true" toc="default">
<section title="Relation Searches"> <name>Relation Searches</name>
<t>
<t>
This section defines searches and link relations for This section defines searches and link relations for
finding objects and sets of objects with respect to their finding objects and sets of objects with respect to their
position within a hierarchy. position within a hierarchy.
</t> </t>
<section numbered="true" toc="default">
<section title="Path Segments"> <name>Path Segments</name>
<t>
<t>
The variables used in the path segments in this The variables used in the path segments in this
section include: section include:
<list> </t>
<t>&lt;relation&gt;: A relation type, as defined
in Section 3.2.2 of this document.</t>
<t>&lt;IP address&gt;: An IP address, as defined in
<xref target="RFC9082"
sectionFormat="of" section="3.1.1" />.</t>
<t>&lt;CIDR prefix&gt;: The first address of a CIDR
block, as defined in
<xref target="RFC9082"
sectionFormat="of" section="3.1.1" />.</t>
<t>&lt;CIDR length&gt;: The prefix length for a
CIDR block, as defined in
<xref target="RFC9082"
sectionFormat="of" section="3.1.1" />.</t>
<t>&lt;domain name&gt;: A fully-qualified domain
name, as defined in
<xref target="RFC9082"
sectionFormat="of" section="3.1.3" />.</t>
<t>&lt;autonomous system number or range&gt;: An
autonomous system number, as defined in <xref
target="RFC9082" sectionFormat="of"
section="3.1.2" />, or two such
numbers separated by a single hyphen ('-',
US-ASCII value 0x2D), where the second number is
greater than the first.</t>
<t>&lt;resource type search path segment&gt;: 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).</t>
<t>&lt;object value&gt;: a value used to identify
an object for the purposes of a relation search
relative to that object. One of &lt;IP
address&gt;, &lt;CIDR prefix&gt; and &lt;CIDR
length&gt; pair, &lt;domain name&gt;, or
&lt;autonomous system number or range&gt;,
depending on the type of search that is being
performed.</t>
<t>&lt;status&gt;: an object status value, as
defined in <xref target="RFC9083"
sectionFormat="of" section="4.6"
/>.</t>
</list>
</t>
<t> <dl spacing="normal" newline="false">
<dt>&lt;relation&gt;:</dt><dd>a relation type, as defined in <xref target="sec
3.2.2"/>
of this document.</dd>
<dt>&lt;IP address&gt;:</dt><dd>an IP address, as defined in <xref
target="RFC9082" sectionFormat="of" section="3.1.1" format="default"/>.</dd>
<dt>&lt;CIDR prefix&gt;:</dt><dd>the first address of a Classless Inter-Domain
Routing (CIDR) block, as
defined in <xref target="RFC9082" sectionFormat="of" section="3.1.1"
format="default"/>.</dd>
<dt>&lt;CIDR length&gt;:</dt><dd>the prefix length for a CIDR block, as
defined in <xref target="RFC9082" sectionFormat="of" section="3.1.1"
format="default"/>.</dd>
<dt>&lt;domain name&gt;:</dt><dd>a fully qualified domain name, as defined
in <xref target="RFC9082" sectionFormat="of" section="3.1.3"
format="default"/>.</dd>
<dt>&lt;autonomous system number or range&gt;:</dt><dd>an autonomous system
number, as defined in <xref target="RFC9082" sectionFormat="of"
section="3.1.2" format="default"/>, or two such numbers separated by a
single hyphen ('-', ASCII value 0x2D), where the second number is greater
than the first.</dd>
<dt>&lt;resource type search path segment&gt;:</dt><dd>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).</dd>
<dt>&lt;object value&gt;:</dt><dd>a value used to identify an object for the
purposes of a relation search relative to that object. One of &lt;IP
address&gt;, &lt;CIDR prefix&gt; and &lt;CIDR length&gt; pair, &lt;domain
name&gt;, or &lt;autonomous system number or range&gt;, depending on the
type of search that is being performed.</dd>
<dt>&lt;status&gt;:</dt><dd>an object status value, as defined in <xref
target="RFC9083" sectionFormat="of" section="4.6" format="default"/>.</dd>
</dl>
<t>
The new resource type path segments for relation The new resource type path segments for relation
search (similar to the searches defined in <xref search (similar to the searches defined in <xref target="RFC9082
target="RFC9082" /> and <xref target="RFC9083" />) " format="default"/> and <xref target="RFC9083" format="default"/>)
are: are:
<list> </t>
<dl spacing="normal" newline="false">
<t> <dt>'ips/rirSearch1/&lt;relation&gt;/&lt;IP address&gt;':</dt>
<dd>Used to identify an IP network search using a relation and an IP address
'ips/rirSearch1/&lt;relation&gt;/&lt;IP address&gt;': to match a set of IP networks.</dd>
Used to identify an IP network search using a <dt>'ips/rirSearch1/&lt;relation&gt;/&lt;CIDR prefix&gt;/&lt;CIDR length&gt;':
relation and an IP address to match a set of </dt>
IP networks. <dd>Used to identify an IP network search using a relation and an IP address
range to match a set of IP networks.</dd>
</t> <dt>'autnums/rirSearch1/&lt;relation&gt;/&lt;autonomous system number or range
&gt;':</dt>
<t> <dd>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.</dd>
'ips/rirSearch1/&lt;relation&gt;/&lt;CIDR prefix&gt;/&lt <dt>'domains/rirSearch1/&lt;relation&gt;/&lt;domain name&gt;':</dt>
;CIDR length&gt;': <dd>Used to identify a reverse domain search using a relation and a reverse
Used to identify an IP network search using a domain name to match a set of reverse domains.</dd>
relation and an IP address range to match a </dl>
set of IP networks. </section>
<section anchor="relation-search" numbered="true" toc="default">
</t> <name>Relation Search</name>
<t>
'autnums/rirSearch1/&lt;relation&gt;/&lt;autonomous syst
em number or range&gt;':
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.
</t>
<t>
'domains/rirSearch1/&lt;relation&gt;/&lt;domain name&gt;
':
Used to identify a reverse domain search using
a relation and a reverse domain name to match
a set of reverse domains.
</t>
</list>
</t>
</section>
<section title="Relation Search" anchor="relation-search">
<t>
Syntax: &lt;resource type search path segment&gt;/rirSearch1/&lt
;relation&gt;/&lt;object value&gt;[?status=&lt;status&gt;]
</t> <dl spacing="normal" newline="false">
<dt>Syntax:</dt><dd>&lt;resource type search path segment&gt;/rirSearch1/&lt;r
elation&gt;/&lt;object value&gt;[?status=&lt;status&gt;]</dd>
</dl>
<t> <t>
The relation searches defined in this document rely on The relation searches defined in this document rely on
the syntax described above. Each search works in the the syntax described above. Each search works in the
same way for each object class. same way for each object class.
</t> </t>
<t>
<t>
The rirSearch1 path segment is used in the relation The rirSearch1 path segment is used in the relation
search URLs in order to provide a single namespace for search URLs in order to provide a single namespace for
those searches, and so that other searches can be those searches, and so that other searches can be
defined underneath the top-level resource type search defined underneath the top-level resource type search
path segments. path segments.
</t> </t>
<section anchor="sec3.2.1" numbered="true" toc="default">
<section title="Definitions"> <name>Definitions</name>
<t>
<t>
An INR object value may have a "parent" object and An INR object value may have a "parent" object and
one or more "child" objects. The "parent" object one or more "child" objects. The "parent" object
is the next-least-specific object that exists in is the next-least-specific object that exists in
the relevant registry, while the "child" objects the relevant registry, while the "child" objects
are the next-most-specific objects that exist in are the next-most-specific objects that exist in
the relevant registry. For example, for a the relevant registry. For example, let's say there is a
registry with the following IP network objects: registry with the following IP network objects:
<figure anchor="registry-objects"> </t>
<name>Example registry objects</name> <figure anchor="registry-objects">
<sourcecode type="drawing"><![CDATA[ <name>Example Registry Objects</name>
<artwork><![CDATA[
+--------------+ +--------------+
| 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 |
+--------------+ +--------------+]]></artwork>
]]></sourcecode> </figure>
</figure> <t>
the INR object value to parent/child object
relationships are:
</t>
<table anchor="parent">
<name>Parent objects</name>
<thead>
<tr>
<th>INR object value</th>
<th>Parent object</th>
</tr>
</thead>
<tbody>
<tr>
<td>192.0.2.0/32</td>
<td>192.0.2.0/28</td>
</tr>
<tr>
<td>192.0.2.0/28</td>
<td>192.0.2.0/25</td>
</tr>
<tr>
<td>192.0.2.64/26</td>
<td>192.0.2.0/25</td>
</tr>
<tr>
<td>192.0.2.128/26</td>
<td>192.0.2.128/25</td>
</tr>
<tr>
<td>192.0.2.192/26</td>
<td>192.0.2.128/25</td>
</tr>
<tr>
<td>192.0.2.0/25</td>
<td>192.0.2.0/24</td>
</tr>
<tr>
<td>192.0.2.128/25</td>
<td>192.0.2.0/24</td>
</tr>
<tr>
<td>192.0.2.0/24</td>
<td>N/A</td>
</tr>
</tbody>
</table>
<table anchor="children"> The relationships of INR object value to parent object (as
<name>Child objects</name> well as to child objects) are:
<thead>
<tr>
<th>INR object value</th>
<th>Child objects</th>
</tr>
</thead>
<tbody>
<tr>
<td>192.0.2.0/24</td>
<td>192.0.2.0/25, 192.0.2.128/25</td>
</tr>
<tr>
<td>192.0.2.0/25</td>
<td>192.0.2.0/28</td>
</tr>
<tr>
<td>192.0.2.128/25</td>
<td>192.0.2.128/26, 192.0.2.192/26</td>
</tr>
<tr>
<td>192.0.2.64/26</td>
<td>N/A</td>
</tr>
<tr>
<td>192.0.2.128/26</td>
<td>N/A</td>
</tr>
<tr>
<td>192.0.2.192/26</td>
<td>N/A</td>
</tr>
<tr>
<td>192.0.2.0/28</td>
<td>192.0.2.0/32</td>
</tr>
<tr>
<td>192.0.2.0/32</td>
<td>N/A</td>
</tr>
</tbody>
</table>
<t> </t>
<table anchor="parent">
<name>Parent objects</name>
<thead>
<tr>
<th>INR object value</th>
<th>Parent object</th>
</tr>
</thead>
<tbody>
<tr>
<td>192.0.2.0/32</td>
<td>192.0.2.0/28</td>
</tr>
<tr>
<td>192.0.2.0/28</td>
<td>192.0.2.0/25</td>
</tr>
<tr>
<td>192.0.2.64/26</td>
<td>192.0.2.0/25</td>
</tr>
<tr>
<td>192.0.2.128/26</td>
<td>192.0.2.128/25</td>
</tr>
<tr>
<td>192.0.2.192/26</td>
<td>192.0.2.128/25</td>
</tr>
<tr>
<td>192.0.2.0/25</td>
<td>192.0.2.0/24</td>
</tr>
<tr>
<td>192.0.2.128/25</td>
<td>192.0.2.0/24</td>
</tr>
<tr>
<td>192.0.2.0/24</td>
<td>N/A</td>
</tr>
</tbody>
</table>
<table anchor="children">
<name>Child objects</name>
<thead>
<tr>
<th>INR object value</th>
<th>Child objects</th>
</tr>
</thead>
<tbody>
<tr>
<td>192.0.2.0/24</td>
<td>192.0.2.0/25, 192.0.2.128/25</td>
</tr>
<tr>
<td>192.0.2.0/25</td>
<td>192.0.2.0/28</td>
</tr>
<tr>
<td>192.0.2.128/25</td>
<td>192.0.2.128/26, 192.0.2.192/26</td>
</tr>
<tr>
<td>192.0.2.64/26</td>
<td>N/A</td>
</tr>
<tr>
<td>192.0.2.128/26</td>
<td>N/A</td>
</tr>
<tr>
<td>192.0.2.192/26</td>
<td>N/A</td>
</tr>
<tr>
<td>192.0.2.0/28</td>
<td>192.0.2.0/32</td>
</tr>
<tr>
<td>192.0.2.0/32</td>
<td>N/A</td>
</tr>
</tbody>
</table>
<t>
(INR object values do not necessarily correspond (INR object values do not necessarily correspond
to registry objects, because users can provide to registry objects, because users can provide
arbitrary object values as input to the searches arbitrary object values as input to the searches
defined in this document.) defined in this document.)
</t> </t>
<t>
<t>
Similarly to the parent/child object Similarly to the parent/child object
relationships, each INR object value may have a relationships, each INR object value may have a
"top" object, being the least-specific covering "top" object, being the least-specific covering
object that exists in the registry, and one or object that exists in the registry, and one or
more "bottom" objects, being the most-specific more "bottom" objects, being the most-specific
objects that entirely cover the INR object value objects that entirely cover the INR object value
when taken together. Given the registry defined when taken together. Given the registry defined
in the previous paragraph, the top and bottom above, the top and bottom
object relationships are: object relationships are:
</t> </t>
<table anchor="top">
<table anchor="top"> <name>Top Objects</name>
<name>Top objects</name> <thead>
<thead> <tr>
<tr> <th>INR object value</th>
<th>INR object value</th> <th>Top object</th>
<th>Top object</th> </tr>
</tr> </thead>
</thead> <tbody>
<tbody> <tr>
<tr> <td>192.0.2.0/32</td>
<td>192.0.2.0/32</td> <td>192.0.2.0/24</td>
<td>192.0.2.0/24</td> </tr>
</tr> <tr>
<tr> <td>192.0.2.0/28</td>
<td>192.0.2.0/28</td> <td>192.0.2.0/24</td>
<td>192.0.2.0/24</td> </tr>
</tr> <tr>
<tr> <td>192.0.2.64/26</td>
<td>192.0.2.64/26</td> <td>192.0.2.0/24</td>
<td>192.0.2.0/24</td> </tr>
</tr> <tr>
<tr> <td>192.0.2.128/26</td>
<td>192.0.2.128/26</td> <td>192.0.2.0/24</td>
<td>192.0.2.0/24</td> </tr>
</tr> <tr>
<tr> <td>192.0.2.192/26</td>
<td>192.0.2.192/26</td> <td>192.0.2.0/24</td>
<td>192.0.2.0/24</td> </tr>
</tr> <tr>
<tr> <td>192.0.2.0/25</td>
<td>192.0.2.0/25</td> <td>192.0.2.0/24</td>
<td>192.0.2.0/24</td> </tr>
</tr> <tr>
<tr> <td>192.0.2.128/25</td>
<td>192.0.2.128/25</td> <td>192.0.2.0/24</td>
<td>192.0.2.0/24</td> </tr>
</tr> <tr>
<tr> <td>192.0.2.0/24</td>
<td>192.0.2.0/24</td> <td>N/A</td>
<td>N/A</td> </tr>
</tr> </tbody>
</tbody> </table>
</table> <table anchor="bottom">
<name>Bottom Objects</name>
<table anchor="bottom"> <thead>
<name>Bottom objects</name> <tr>
<thead> <th>INR object value</th>
<tr> <th>Bottom objects</th>
<th>INR object value</th> </tr>
<th>Bottom objects</th> </thead>
</tr> <tbody>
</thead> <tr>
<tbody> <td>192.0.2.0/24</td>
<tr> <td>192.0.2.0/25, 192.0.2.0/28, 192.0.2.0/32, 192.0.2.128/26, 19
<td>192.0.2.0/24</td> 2.0.2.192/26</td>
<td>192.0.2.0/25, 192.0.2.0/28, 192.0.2.0/32, 192.0. </tr>
2.128/26, 192.0.2.192/26</td> <tr>
</tr> <td>192.0.2.0/25</td>
<tr> <td>192.0.2.0/25, 192.0.2.0/28, 192.0.2.0/32</td>
<td>192.0.2.0/25</td> </tr>
<td>192.0.2.0/25, 192.0.2.0/28, 192.0.2.0/32</td> <tr>
</tr> <td>192.0.2.128/25</td>
<tr> <td>192.0.2.128/26, 192.0.2.192/26</td>
<td>192.0.2.128/25</td> </tr>
<td>192.0.2.128/26, 192.0.2.192/26</td> <tr>
</tr> <td>192.0.2.64/26</td>
<tr> <td>N/A</td>
<td>192.0.2.64/26</td> </tr>
<td>N/A</td> <tr>
</tr> <td>192.0.2.128/26</td>
<tr> <td>N/A</td>
<td>192.0.2.128/26</td> </tr>
<td>N/A</td> <tr>
</tr> <td>192.0.2.192/26</td>
<tr> <td>N/A</td>
<td>192.0.2.192/26</td> </tr>
<td>N/A</td> <tr>
</tr> <td>192.0.2.0/28</td>
<tr> <td>192.0.2.0/28, 192.0.2.0/32</td>
<td>192.0.2.0/28</td> </tr>
<td>192.0.2.0/28, 192.0.2.0/32</td> <tr>
</tr> <td>192.0.2.0/31</td>
<tr> <td>192.0.2.0/28, 192.0.2.0/32</td>
<td>192.0.2.0/31</td> </tr>
<td>192.0.2.0/28, 192.0.2.0/32</td> <tr>
</tr> <td>192.0.2.0/32</td>
<tr> <td>N/A</td>
<td>192.0.2.0/32</td> </tr>
<td>N/A</td> </tbody>
</tr> </table>
</tbody> <t>
</table>
<t>
If there are no more-specific objects for a given If there are no more-specific objects for a given
INR object value, then the set of bottom objects INR object value, then the set of bottom objects
for that INR object value will be empty. for that INR object value will be empty.
192.0.2.0/32 is an example of such an INR object 192.0.2.0/32 is an example of such an INR object
value. value.
</t> </t>
<t>
<t>
It is not necessarily the case that the bottom It is not necessarily the case that the bottom
objects for a given INR object value will be objects for a given INR object value will be
disjoint. For example, 192.0.2.0/28's bottom disjoint. For example, 192.0.2.0/28's bottom
objects are 192.0.2.0/28 and 192.0.2.0/32. 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 192.0.2.0/32 is included because it is one of the
most-specific objects (i.e. an object at the bottom most-specific objects (i.e., an object at the bottom
of the object hierarchy) for 192.0.2.0/28, while of the object hierarchy) for 192.0.2.0/28, while
192.0.2.0/28 itself is included because it is the 192.0.2.0/28 itself is included because it is the
most-specific object for the other addresses most-specific object for the other addresses
within the range (i.e. those aside from within the range (i.e., those aside from
192.0.2.0/32). 192.0.2.0/32).
</t> </t>
<t>
<t>
The bottom objects for a given INR object value The bottom objects for a given INR object value
may include an object that is less-specific than may include an object that is less specific than
that INR object value. For example, 192.0.2.0/31 that INR object value. For example, 192.0.2.0/31
is an INR object value that has a more-specific is an INR object value that has a more-specific
object, being 192.0.2.0/32, so the set of bottom object, being 192.0.2.0/32, so the set of bottom
objects must include at least that object. The objects must include at least that object. The
most-specific object that covers the residual most-specific object that covers the residual
(i.e. 192.0.2.1/32) is 192.0.2.0/28, so it is (i.e., 192.0.2.1/32) is 192.0.2.0/28, so it is
included in the results as well. included in the results as well.
</t> </t>
</section>
</section> <section anchor="sec3.2.2" numbered="true" toc="default">
<name>Relations</name>
<section title="Relations"> <section numbered="true" toc="default">
<name>Single-Result Searches</name>
<section title="Single-Result Searches"> <section numbered="true" toc="default">
<name>"rdap-up"</name>
<section title='"rdap-up"'> <t>
<t>
If the server receives a search containing If the server receives a search containing
the relation value "rdap-up", it will the relation value "rdap-up", it will
return the parent object for the specified return the parent object for the specified
INR object value as though that object had INR object value as though that object had
been requested directly. If no such been requested directly. If no such
object exists, it will respond with a HTTP object exists, it will respond with an HTTP
404 (Not Found) <xref target="RFC9110" /> 404 (Not Found) <xref target="RFC9110" format="defau
lt"/>
search response. search response.
</t> </t>
</section>
</section> <section numbered="true" toc="default">
<name>"rdap-top"</name>
<!--[rfced] search response vs. response code vs. response
<section title='"rdap-top"'> The original uses various terms ("search response" and "response code"
and "response") after an HTTP status code. Would you like to update
"search response" to "response code" to match 2 instances in this document
or "status code" to match the cited document (RFC 9110) or otherwise?
For example:
<t> Original: ... with a HTTP 404 (Not Found) [RFC9110] search response.
Option A: ... with an HTTP 404 (Not Found) [RFC9110] response code.
Option B: ... with an HTTP 404 (Not Found) [RFC9110] status code.
-->
<t>
If the server receives a search containing If the server receives a search containing
the relation value "rdap-top", it will the relation value "rdap-top", it will
return the top object for the specified return the top object for the specified
INR object value as though that object had INR object value as though that object had
been requested directly. If no such been requested directly. If no such
object exists, it will respond with an object exists, it will respond with an
HTTP 404 (Not Found) <xref HTTP 404 (Not Found) <xref target="RFC9110" format="
target="RFC9110" /> search response. default"/> search response.
</t>
</section>
</section>
<section title="Multiple-Result Searches">
<section title='"rdap-down"'>
<t> </t>
</section>
</section>
<section numbered="true" toc="default">
<name>Multiple-Result Searches</name>
<section numbered="true" toc="default">
<name>"rdap-down"</name>
<t>
If the server receives a search containing If the server receives a search containing
the relation value "rdap-down", it will the relation value "rdap-down", it will
return the child objects for the specified return the child objects for the specified
INR object value. If no such objects INR object value. If no such objects
exist, it will return an empty search exist, it will return an empty search
response. Per the definitions section, response. Per the definitions section,
this includes only immediate child this includes only immediate child
objects. objects.
</t> </t>
</section>
</section> <section numbered="true" toc="default">
<name>"rdap-bottom"</name>
<section title='"rdap-bottom"'> <t>
<t>
If the server receives a search containing If the server receives a search containing
the relation value "rdap-bottom", it will the relation value "rdap-bottom", it will
return the bottom objects for the return the bottom objects for the
specified INR object value. If no such specified INR object value. If no such
objects exist, it will return an empty objects exist, it will return an empty
search response. search response.
</t> </t>
</section>
</section>
</section> </section>
</section>
</section> </section>
</section>
<section title="Status" anchor="status"> <section anchor="status" numbered="true" toc="default">
<name>Status</name>
<t> <t>
If the "status" argument is provided, then response If the "status" argument is provided, then response
processing will proceed as though all objects without processing will proceed as though all objects without
the specified status had first been removed from the the specified status had first been removed from the
database. For example, if the registry objects from database. For example, if the registry objects from
section 3.2.1 had the following statuses: <xref target="sec3.2.1"/> had the following statuses:
</t>
<table anchor="statuses">
<name>Statuses</name>
<thead>
<tr>
<th>Object</th>
<th>Status</th>
</tr>
</thead>
<tbody>
<tr>
<td>192.0.2.0/25</td>
<td>active</td>
</tr>
<tr>
<td>192.0.2.128/25</td>
<td>inactive</td>
</tr>
<tr>
<td>192.0.2.128/26</td>
<td>active</td>
</tr>
<tr>
<td>192.0.2.192/26</td>
<td>active</td>
</tr>
</tbody>
</table>
<t> </t>
<table anchor="statuses">
<name>Statuses</name>
<thead>
<tr>
<th>Object</th>
<th>Status</th>
</tr>
</thead>
<tbody>
<tr>
<td>192.0.2.0/25</td>
<td>active</td>
</tr>
<tr>
<td>192.0.2.128/25</td>
<td>inactive</td>
</tr>
<tr>
<td>192.0.2.128/26</td>
<td>active</td>
</tr>
<tr>
<td>192.0.2.192/26</td>
<td>active</td>
</tr>
</tbody>
</table>
<t>
then a server receiving a "rdap-down" search request then a server receiving a "rdap-down" search request
with the INR object value 192.0.2.0/24 and a "status" with the INR object value 192.0.2.0/24 and a "status"
argument of "active" would return the objects argument of "active" would return the objects
192.0.2.0/25, 192.0.2.128/26, and 192.0.2.192/26. 192.0.2.0/25, 192.0.2.128/26, and 192.0.2.192/26.
</t> </t>
<t>
<t>
Status filtering is useful, for example, where the Status filtering is useful, for example, where the
client is trying to find the delegation from an RIR to client is trying to find the delegation from an RIR to
an RIR account holder: by using the "rdap-top" an RIR account holder: by using the "rdap-top"
relation with a "status" of "active", the delegation relation with a "status" of "active", the delegation
from IANA to the RIR will be ignored, and the client from IANA to the RIR will be ignored, and the client
will receive the delegation from the RIR to the will receive the delegation from the RIR to the
account holder in the response instead. account holder in the response instead.
</t> </t>
<t>
<t>
By default, any valid status value may be used for By default, any valid status value may be used for
status filtering. Server operators MAY opt not to status filtering. Server operators <bcp14>MAY</bcp14> opt not t o
support "status" filtering for the "rdap-down" and support "status" filtering for the "rdap-down" and
"rdap-bottom" link relations, in which case the server "rdap-bottom" link relations, in which case the server
responds with an HTTP 501 (Not Implemented) <xref responds with an HTTP 501 (Not Implemented) <xref target="RFC911
target="RFC9110" /> response code if it receives such 0" format="default"/> response code if it receives such
a request. Server operators MAY also opt not to a request. Server operators <bcp14>MAY</bcp14> also opt not to
support "status" filtering for values other than support "status" filtering for values other than
"active" for the "rdap-up" and "rdap-top" link "active" for the "rdap-up" and "rdap-top" link
relations, in which case the server responds with an relations, in which case the server responds with an
HTTP 501 (Not Implemented) <xref target="RFC9110" /> HTTP 501 (Not Implemented) <xref target="RFC9110" format="defaul t"/>
response code if it receives such a request. response code if it receives such a request.
</t> </t>
<t>
<t>
While any valid status value may be used for status While any valid status value may be used for status
filtering, a given RDAP server may make use of only a filtering, a given RDAP server may make use of only a
small number of those status values for INR objects. small number of those status values for INR objects.
For example, a status value like "client hold" would For example, a status value like "client hold" would
typically only be used by a DNR for a forward domain typically only be used by a DNR for a forward domain
name object. name object.
</t> </t>
</section>
</section> <section numbered="true" toc="default">
<name>Link Relations</name>
<section title="Link Relations"> <t>
<t>
Each of the relations defined in section 3.2.2 has a Each of the relations defined in <xref target="sec3.2.2"/> has a
corresponding link relation that can be used for a corresponding link relation that can be used for a
link object contained within another RDAP object. link object contained within another RDAP object.
When constructing these link objects, the server MUST When constructing these link objects, the server <bcp14>MUST</bc p14>
use the corresponding search URL for the link target, use the corresponding search URL for the link target,
or a URL that yields the same response as for the or a URL that yields the same response as for the
corresponding search as at the time of the request. corresponding search as at the time of the request.
The following is an elided example of an IPv4 response The following is an elided example of an IPv4 response
that makes use of those link relations: that makes use of those link relations:
<figure anchor="example-links-ipv4"> </t>
<name>Example links in an IPv4 response</name> <figure anchor="example-links-ipv4">
<artwork align="center" type="ascii-art" name="" alt=""><![CDATA[ <name>Example Links in an IPv4 Response</name>
<sourcecode type="json"><![CDATA[
{ {
"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",
skipping to change at line 1002 skipping to change at line 853
"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"
} }
] ]
} }]]></sourcecode>
]]></artwork> </figure>
</figure> <t>
The following is an elided example of an IPv6 response The following is an elided example of an IPv6 response
that makes use of the link relations: that makes use of the link relations:
<figure anchor="example-links-ipv6"> </t>
<name>Example links in an IPv6 response</name> <figure anchor="example-links-ipv6">
<artwork align="center" type="ascii-art" name="" alt=""><![CDATA[ <name>Example Links in an IPv6 Response</name>
<sourcecode type="json"><![CDATA[
{ {
"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", "rel": "rdap-up",
"href": ".../rdap/ips/rirSearch1/rdap-up/2001:db8:a::/48", "href": ".../rdap/ips/rirSearch1/rdap-up/2001:db8:a::/48",
skipping to change at line 1043 skipping to change at line 895
"href": ".../rdap/ips/rirSearch1/rdap-top/2001:db8:a::/48", "href": ".../rdap/ips/rirSearch1/rdap-top/2001:db8:a::/48",
"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-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"
} }
] ]
} }]]></sourcecode>
]]></artwork> </figure>
</figure> <t>
One additional link relation, "rdap-active", is One additional link relation, "rdap-active", is
defined for denoting a search with a "status" of defined for denoting a search with a "status" of
"active". No other status link relations are defined, "active". No other status link relations are defined
because the only known use cases for status filtering because the only known use cases for status filtering
involve the "rdap-up" and "rdap-top" relations and the involve the "rdap-up" and "rdap-top" relations and the
"active" status. The following is an elided example "active" status. The following is an elided example
of an IPv4 response that makes use of those link of an IPv4 response that makes use of those link
relations: relations:
<figure anchor="example-status-links-ipv4"> </t>
<name>Example status links in an IPv4 response</name> <figure anchor="example-status-links-ipv4">
<artwork align="center" type="ascii-art" name="" alt=""><![CDATA[ <name>Example Status Links in an IPv4 Response</name>
<sourcecode type="json"><![CDATA[
{ {
"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"
} }
] ]
} }]]></sourcecode>
]]></artwork> </figure>
</figure> <t>
The following is an elided example of an IPv6 response The following is an elided example of an IPv6 response
that makes use of the link relations: that makes use of the link relations:
<figure anchor="example-status-links-ipv6"> </t>
<name>Example status links in an IPv6 response</name> <!-- [rfced] In Figure 5, two lines are longer than the line limit.
<artwork align="center" type="ascii-art" name="" alt=""><![CDATA[ To resolve this, is moving the two lines to the left as shown below
accetable? If not, please provide your preferred solution.
-19.xml(940): Warning: Too long line found (L677), 1 characters longer than 72 c
haracters:
".../rdap/ips/rirSearch1/rdap-up/2001:db8:a::/48?status=active",
-19.xml(940): Warning: Too long line found (L684), 2 characters longer than 72 c
haracters:
".../rdap/ips/rirSearch1/rdap-top/2001:db8:a::/48?status=active",
Current:
"href":
".../rdap/ips/rirSearch1/rdap-up/2001:db8:a::/48?status=active",
[...]
"href":
".../rdap/ips/rirSearch1/rdap-top/2001:db8:a::/48?status=active",
Perhaps:
"href":
".../rdap/ips/rirSearch1/rdap-up/2001:db8:a::/48?status=active",
[...]
"href":
".../rdap/ips/rirSearch1/rdap-top/2001:db8:a::/48?status=active",
-->
<figure anchor="example-status-links-ipv6">
<name>Example Status Links in an IPv6 Response</name>
<sourcecode type="json"><![CDATA[
{ {
"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":
skipping to change at line 1111 skipping to change at line 988
"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"
} }
] ]
} }]]></sourcecode>
]]></artwork> </figure>
</figure> <t>
"rdap-active" is used only as a link relation in a "rdap-active" is used only as a link relation in a
link object. It cannot be used as a value for link object. It cannot be used as a value for
&lt;relation&gt; in the relation search URL defined in &lt;relation&gt; in the relation search URL defined in
<xref target="relation-search" />. <xref <xref target="relation-search" format="default"/>. <xref target
target="status" /> details status filtering for ="status" format="default"/> details status filtering for
relation search URLs. relation search URLs.
</t> </t>
<t>
<t>
Since the "rdap-top" and "rdap-up" link relations Since the "rdap-top" and "rdap-up" link relations
resolve either to a single object or to an HTTP 404 resolve either to a single object or to an HTTP 404
(Not Found) <xref target="RFC9110" /> response, it is (Not Found) <xref target="RFC9110" format="default"/> response,
possible for a server to use a lookup URL (see <xref it is
target="RFC9082" sectionFormat="of" section="3.1" />) possible for a server to use a lookup URL (see <xref target="RFC
9082" sectionFormat="of" section="3.1" format="default"/>)
in the "href" attribute in the link object. The in the "href" attribute in the link object. The
following is an elided example of an IPv4 response following is an elided example of an IPv4 response
that uses this approach: that uses this approach:
<figure anchor="example-object-links-ipv4"> </t>
<name>Example single-result links in an IPv4 response</name> <figure anchor="example-object-links-ipv4">
<artwork align="center" type="ascii-art" name="" alt=""><![CDATA[ <name>Example Single-Result Links in an IPv4 Response</name>
<sourcecode type="json"><![CDATA[
{ {
"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"
} }
] ]
} }]]></sourcecode>
]]></artwork> </figure>
</figure> <t>
The following is an elided example of an IPv6 response The following is an elided example of an IPv6 response
that makes use of the approach: that makes use of the approach:
<figure anchor="example-object-links-ipv6"> </t>
<name>Example single-result links in an IPv6 response</name> <figure anchor="example-object-links-ipv6">
<artwork align="center" type="ascii-art" name="" alt=""><![CDATA[ <name>Example single-result links in an IPv6 response</name>
<sourcecode type="json"><![CDATA[
{ {
"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", "rel": "rdap-up",
"href": "https://example.com/rdap/ip/2001:db8::/32", "href": "https://example.com/rdap/ip/2001:db8::/32",
"type": "application/rdap+json" "type": "application/rdap+json"
} }
] ]
} }]]></sourcecode>
]]></artwork> </figure>
</figure> <t>
</t> Use of these link relations in responses is <bcp14>OPTIONAL</bcp
14>.
<!--[rfced] For clarity, how may this be rephrased?
Specifically, is there a way to clarify "not necesarily mean"? Does
this mean it can go either way (results or no results)?
The original is of the form "the absence of X does not necessarily
mean that Y will return no results".
<t> Original:
The absence in
a response of a link for a specific relation does not necessarily
mean that the corresponding search will return no results.
Use of these link relations in responses is OPTIONAL. Option A (using "may or may not"):
In a response, the absence of a link for a specific relation may
or may not mean that the corresponding search returns zero results.
Option B (using "may or may not", and "cause" instead of "mean"):
In a response, the absence of a link for a specific relation may
or may not cause the corresponding search to return zero results.
-->
The absence in a response of a link for a specific The absence in a response of a link for a specific
relation does not necessarily mean that the relation does not necessarily mean that the
corresponding search will return no results. corresponding search will return no results.
</t> </t>
</section>
</section>
</section> </section>
<section numbered="true" toc="default">
<section title="Responding To Searches"> <name>Responding to Searches</name>
<section numbered="true" toc="default">
<section title="Single-Result Searches"> <name>Single-Result Searches</name>
<t>
<t>
The "rdap-up" and "rdap-top" relations are The "rdap-up" and "rdap-top" relations are
single-result searches. When processing these single-result searches. When processing these
searches, if there is a result for the search, the searches, if there is a result for the search, the
server returns that object as though it were requested server returns that object as though it were requested
directly via a lookup URL (see <xref target="RFC9082" directly via a lookup URL (see <xref target="RFC9082" sectionFor
sectionFormat="of" section="3.1" />). If there is no mat="of" section="3.1" format="default"/>). If there is no
result for the search, the server returns an HTTP 404 result for the search, the server returns an HTTP 404
(Not Found) <xref target="RFC9110" /> response code. (Not Found) <xref target="RFC9110" format="default"/> response c
ode.
</t>
</section>
<section title="Multiple-Result Searches">
<t> </t>
</section>
<section numbered="true" toc="default">
<name>Multiple-Result Searches</name>
<t>
The "rdap-down" and "rdap-bottom" relations are The "rdap-down" and "rdap-bottom" relations are
multiple-result searches. As with <xref multiple-result searches. As with <xref target="RFC9083" format
target="RFC9083" />, responses for these searches take ="default"/>, responses for these searches take
the form of an array of object instances, where each the form of an array of object instances, where each
instance is an appropriate object class for the search instance is an appropriate object class for the search
(i.e., a search beginning with /ips yields an array of (i.e., a search beginning with /ips yields an array of
IP network object instances, and a search beginning IP network object instances, and a search beginning
with /autnums yields an array of autonomous system with /autnums yields an array of autonomous system
number object instances). The IP network object class number object instances). The IP network object class
is defined in <xref target="RFC9083" is defined in <xref target="RFC9083" sectionFormat="of" section=
sectionFormat="of" section="5.4" />, and the "5.4" format="default"/>, and the
autonomous system number object class is defined in autonomous system number object class is defined in
<xref target="RFC9083" sectionFormat="of" <xref target="RFC9083" sectionFormat="of" section="5.5" format="
section="5.5" />. The object instance arrays are default"/>. The object instance arrays are
contained within the response object. contained within the response object.
</t> </t>
<t>
<t>
The names of the arrays are as follows: The names of the arrays are as follows:
</t>
<list> <ul spacing="normal">
<t> <li>for /ips searches, the array is "ipSearchResults"; and</li>
<li>for /autnums searches, the array is "autnumSearchResults".</li>
for /ips searches, the array is "ipSearchResults"; and </ul>
<t>
</t>
<t>
for /autnums searches, the array is "autnumSearchResults
".
</t>
</list>
</t>
<t>
The following is an elided example of a response for The following is an elided example of a response for
an IPv4 network search: an IPv4 network search:
<figure anchor="ip-network-search-response-ipv4"> </t>
<name>IPv4 network search response</name> <figure anchor="ip-network-search-response-ipv4">
<sourcecode type="drawing"><![CDATA[ <name>IPv4 Network Search Response</name>
<!-- [rfced] Please review whether the "type" attribute is set as
intended for sourcecode elements in the XML file. If the current list
of preferred values for "type"
(https://www.rfc-editor.org/rpc/wiki/doku.php?id=sourcecode-types) does not
contain an applicable type, then feel free to suggest a new one.
Also, it is acceptable to leave the "type" attribute not set.
FYI, in Figure 8 (IPv4 Network Search Response) and similar, we changed
sourcecode type="drawing" to type="json", as "drawing" is not a type
of sourcecode - and because of usage in STD 95 (on the intake form,
you wrote to follow STD 95): we see RFC 9083, Figure 32 contains a
search response in sourcecode with type="json"
(https://www.rfc-editor.org/rfc/rfc9083.html#figure-32).
Please let us know if you prefer otherwise.
-->
<sourcecode type="json"><![CDATA[
{ {
"rdapConformance": [ "rdap_level_0", "rirSearch1", "rdapConformance": [ "rdap_level_0", "rirSearch1",
"ips", "ipSearchResults", ... ], "ips", "ipSearchResults", ... ],
... ...
"ipSearchResults": [ "ipSearchResults": [
{ {
"objectClassName": "ip network", "objectClassName": "ip network",
"handle": "XXXX-RIR", "handle": "XXXX-RIR",
"startAddress": "192.0.2.0", "startAddress": "192.0.2.0",
"endAddress": "192.0.2.127", "endAddress": "192.0.2.127",
skipping to change at line 1284 skipping to change at line 1169
{ {
"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",
... ...
} }
] ]
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>
</t>
<t>
The following is an elided example of a response for The following is an elided example of a response for
an IPv6 network search: an IPv6 network search:
<figure anchor="ip-network-search-response-ipv6"> </t>
<name>IPv6 network search response</name> <figure anchor="ip-network-search-response-ipv6">
<sourcecode type="drawing"><![CDATA[ <name>IPv6 Network Search Response</name>
<sourcecode type="json"><![CDATA[
{ {
"rdapConformance": [ "rdap_level_0", "rirSearch1", "rdapConformance": [ "rdap_level_0", "rirSearch1",
"ips", "ipSearchResults", ... ], "ips", "ipSearchResults", ... ],
... ...
"ipSearchResults": [ "ipSearchResults": [
{ {
"objectClassName": "ip network", "objectClassName": "ip network",
"handle": "XXXX-RIR", "handle": "XXXX-RIR",
"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",
skipping to change at line 1318 skipping to change at line 1201
{ {
"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",
... ...
} }
] ]
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>
</t>
<t>
The following is an elided example of a response to an The following is an elided example of a response to an
autonomous system number search: autonomous system number search:
<figure anchor="asn-search-response"> </t>
<name>ASN search response</name> <figure anchor="asn-search-response">
<sourcecode type="drawing"><![CDATA[ <name>ASN Search Response</name>
<sourcecode type="json"><![CDATA[
{ {
"rdapConformance": [ "rdap_level_0", "rirSearch1", "rdapConformance": [ "rdap_level_0", "rirSearch1",
"autnums", "autnumSearchResults", ... ], "autnums", "autnumSearchResults", ... ],
... ...
"autnumSearchResults": [ "autnumSearchResults": [
{ {
"objectClassName": "autnum", "objectClassName": "autnum",
"handle": "XXXX-RIR", "handle": "XXXX-RIR",
"startAutnum": 64496, "startAutnum": 64496,
"endAutnum": 64496, "endAutnum": 64496,
skipping to change at line 1352 skipping to change at line 1233
{ {
"objectClassName": "autnum", "objectClassName": "autnum",
"handle": "YYYY-RIR", "handle": "YYYY-RIR",
"startAutnum": "64497", "startAutnum": "64497",
"endAutnum": "64497", "endAutnum": "64497",
... ...
} }
] ]
} }
]]></sourcecode> ]]></sourcecode>
</figure> </figure>
<t>
</t>
<t>
Responses for relation searches for reverse domain objects Responses for relation searches for reverse domain objects
have the same form as for a standard domain search have the same form as for a standard domain search
response, per <xref target="RFC9083" />. response, per <xref target="RFC9083" format="default"/>.
</t>
<t> </t>
<t>
If the search can be processed by the server, but If the search can be processed by the server, but
there are no results for the search, then the server there are no results for the search, then the server
returns an HTTP 404 (Not Found) <xref target="RFC9110" returns an HTTP 404 (Not Found) <xref target="RFC9110" format="d
/> response code, with the body of the response efault"/> response code, with the body of the response
containing an empty results array. containing an empty results array.
</t> </t>
</section>
</section>
</section> </section>
<section numbered="true" toc="default">
<name>Reverse Search</name>
<t>
<section title="Reverse Search"> RDAP reverse search is defined by <xref target="RFC9536" format="def
ault"/>. That document limits reverse search to domains,
<t>
RDAP reverse search is defined by <xref target="RFC9536"
/>. That document limits reverse search to domains,
nameservers, and entities. This document extends reverse nameservers, and entities. This document extends reverse
search to cover IP networks and autonomous system numbers search to cover IP networks and autonomous system numbers
as well. as well.
</t> </t>
<t>
<t>
If a server receives a reverse search query with a If a server receives a reverse search query with a
searchable resource type (per the definition of that term searchable resource type (per the definition of that term
in <xref target="RFC9536" />) of "ips", then the reverse in <xref target="RFC9536" format="default"/>) of "ips", then the rev erse
search will be performed on the IP network objects from search will be performed on the IP network objects from
its data store. Similarly, if a server receives a reverse its data store. Similarly, if a server receives a reverse
search query with a searchable resource type of "autnums", search query with a searchable resource type of "autnums",
then the reverse search will be performed on the then the reverse search will be performed on the
autonomous system number objects from its data store. autonomous system number objects from its data store.
</t> </t>
<t>
<t>
Additionally, <xref target="IANA" /> includes requests to
register new entries for IP network and autonomous system
number searches in the RDAP Reverse Search and RDAP
Reverse Search Mapping IANA registries.
</t> Additionally, <xref target="IANA" format="default"/> notes that
new registrations for IP network and autonomous system
number searches have been made in the "RDAP Reverse Search" and "RDA
P
Reverse Search Mapping" IANA registries.
</t>
</section> </section>
<section numbered="true" toc="default">
<section title="RDAP Conformance"> <name>RDAP Conformance</name>
<t> <t>
A server that supports the functionality specified in this A server that supports the functionality specified in this
document MUST include additional string literals in the document <bcp14>MUST</bcp14> include additional string literals in t he
rdapConformance array of its responses, in accordance with rdapConformance array of its responses, in accordance with
the following: the following:
<ul> </t>
<ul>
<li>any response that includes an IP network basic <li>any response that includes an IP network basic
search link, an IP network relation search link, or an IP search link, an IP network relation search link, or an IP
network reverse search link includes the "rirSearch1" network reverse search link includes the "rirSearch1"
and "ips" literals;</li> and "ips" literals;</li>
<li>any response for an IP network basic search
<li>any response for an IP network basic search
request, an IP network relation search request, or an request, an IP network relation search request, or an
IP network reverse search request includes the IP network reverse search request includes the
"rirSearch1", "ips", and "ipSearchResults" "rirSearch1", "ips", and "ipSearchResults"
literals;</li> literals;</li>
<li>any response that includes an ASN basic search
<li>any response that includes an ASN basic search
link, an ASN relation search link, or an ASN reverse link, an ASN relation search link, or an ASN reverse
search link includes the "rirSearch1" and "autnums" search link includes the "rirSearch1" and "autnums"
literals;</li> literals;</li>
<li>any response for an ASN basic search request, an
<li>any response for an ASN basic search request, an
ASN relation search request, or an ASN reverse search ASN relation search request, or an ASN reverse search
request includes the "rirSearch1", "autnums", and request includes the "rirSearch1", "autnums", and
"autnumSearchResults" literals;</li> "autnumSearchResults" literals;</li>
<li>any response that includes a domain relation search
<li>any response that includes a domain relation search
link includes the "rirSearch1" literal;</li> link includes the "rirSearch1" literal;</li>
<li>any response for a domain relation search request
<li>any response for a domain relation search request
includes the "rirSearch1" literal; and</li> includes the "rirSearch1" literal; and</li>
<li>a response to a "/help" request includes the
<li>a response to a "/help" request includes the
"rirSearch1", "ips", "ipSearchResults", "autnums", and "rirSearch1", "ips", "ipSearchResults", "autnums", and
"autnumSearchResults" literals.</li> "autnumSearchResults" literals.</li>
</ul>
</ul> <t>
Although responses will generally not include all of the Although responses will generally not include all of the
rdapConformance string literals defined in this document, rdapConformance string literals defined in this document,
that is not meant to imply that a server can support only that is not meant to imply that a server can support only
a portion of the functionality defined in this document. a portion of the functionality defined in this document.
</t> </t>
<t>
<t>
The "ips", "autnums", "ipSearchResults", and The "ips", "autnums", "ipSearchResults", and
"autnumSearchResults" extension identifiers are included "autnumSearchResults" extension identifiers are included
here due to the requirements and recommendations set out here due to the requirements and recommendations set out
in <xref target="RFC7480" />, <xref target="RFC9082" />, in <xref target="RFC7480" format="default"/>, <xref target="RFC9082
and <xref target="RFC9083" />. These requirements and " format="default"/>,
and <xref target="RFC9083" format="default"/>. These requirements a
nd
recommendations are such that an RDAP extension identifier recommendations are such that an RDAP extension identifier
be used as a prefix in new path segments and JSON members be used as a prefix in new path segments and JSON members
introduced by the extension, and those strings are used as introduced by the extension, and those strings are used as
such as part of the basic searches defined in this such as part of the basic searches defined in this
document. Furthermore, using these strings as path document. Furthermore, using these strings as path
segments helps to increase consistency among the basic segments helps to increase consistency among the basic
searches for the core RDAP object classes. searches for the core RDAP object classes.
</t> </t>
<t>
<t>
As with the other core object classes (entity, domain, and As with the other core object classes (entity, domain, and
nameserver), other documents may define additional reverse nameserver), other documents may define additional reverse
searches with IP networks and ASNs as the searchable searches with IP networks and ASNs as the searchable
resource type by registering those in the IANA RDAP resource type by registering those in the IANA RDAP
reverse search registries. Because a given extension reverse search registries. Because a given extension
identifier must correspond to a single extension, though, identifier must correspond to a single extension, though,
any document making use of IP networks or ASNs as the any document making use of IP networks or ASNs as the
searchable resource type must also implement the searchable resource type must also implement the
functionality described in this document. functionality described in this document.
</t> </t>
<t>
<t>
The "1" in "rirSearch1" denotes that this is version 1 of The "1" in "rirSearch1" denotes that this is version 1 of
the RIR search extension. New versions of the RIR search the RIR search extension. New versions of the RIR search
extension will use different extension identifiers. A extension will use different extension identifiers. A
version suffix is not used for the remaining identifiers version suffix is not used for the remaining identifiers
defined by this document, partly because such a suffix defined by this document, partly because such a suffix
would reduce consistency with the corresponding would reduce consistency with the corresponding
functionality for the other core object classes, and functionality for the other core object classes, and
partly because it is very unlikely that the functionality partly because it is very unlikely that the functionality
associated with those identifiers will change. associated with those identifiers will change.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<name>Operational Considerations</name>
<!--[rfced] For clarity, may this be rephrased?
Specifically, may "for" be changed to "that of" in
"the behaviour of the lookup URL is the same as for the search URL"?
Regarding "is the same as for the search URL as at the time when":
- The use of "as" twice in this phrase is unclear.
- "at the time when" is redundant. (Suggest removing "when".)
Please review whether the suggested text conveys the intended meaning.
<section title="Operational Considerations"> Original:
When using a link object for a single-result search, a server may
<t> replace a search URL with a lookup URL, because the behaviour of the
lookup URL is the same as for the search URL as at the time when the
response is generated.
Perhaps:
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.
-->
<t>
When using a link object for a single-result search, a When using a link object for a single-result search, a
server may replace a search URL with a lookup URL, because server may replace a search URL with a lookup URL, because
the behaviour of the lookup URL is the same as for the the behaviour of the lookup URL is the same as for the
search URL as at the time when the response is generated. search URL as at the time when the response is generated.
One difference between these approaches is that when using One difference between these approaches is that when using
the lookup URL, the server is effectively performing the the lookup URL, the server is effectively performing the
search on behalf of the client as at the time of response search on behalf of the client as at the time of response
generation. If there is no change to the relevant generation. If there is no change to the relevant
database state between the time when the original response database state between the time when the original response
is generated and the time when the client resolves the is generated and the time when the client resolves the
link relation target, then the search URL and the lookup link relation target, then the search URL and the lookup
URL will lead to the same result. However, if there is a URL will lead to the same result. However, if there is a
change to the relevant database state, then the lookup URL change to the relevant database state, then the lookup URL
may lead to a different result from that of the search may lead to a different result from that of the search
URL. Server operators should consider which type of URL URL. Server operators should consider which type of URL
will be more effective for their clients when implementing will be more effective for their clients when implementing
this specification. this specification.
</t> </t>
<t>
<t>
Where this document includes HTTP reason phrases, that is Where this document includes HTTP reason phrases, that is
purely for the benefit of the reader, and is not an purely for the benefit of the reader and is not an
indication that those phrases need to be used as-is in indication that those phrases need to be used as-is in
responses. responses.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<section title="Privacy Considerations"> <name>Privacy Considerations</name>
<t>
<t>
The search functionality defined in this document may The search functionality defined in this document may
affect the privacy of entities in the registry (and affect the privacy of entities in the registry (and
elsewhere) in various ways: see <xref target="RFC6973" /> elsewhere) in various ways: see <xref target="RFC6973" format="defau lt"/>
for a general treatment of privacy in protocol for a general treatment of privacy in protocol
specifications, and <xref target="RFC7481" /> for specific specifications, and <xref target="RFC7481" format="default"/> for sp ecific
discussion about privacy threats with respect to the discussion about privacy threats with respect to the
registration data provided by RDAP. Server operators registration data provided by RDAP. Server operators
should be aware of the tradeoffs that result from should be aware of the tradeoffs that result from
implementation of this functionality. implementation of this functionality.
</t> </t>
<t>
<t>
Many jurisdictions have laws or regulations that restrict Many jurisdictions have laws or regulations that restrict
the use of "Personal Data", per the definition in <xref the use of "Personal Data", per the definition in <xref target="RFC6
target="RFC6973" />. Given that, server operators should 973" format="default"/>. Given that, server operators should
ascertain whether the regulatory environment in which they ascertain whether the regulatory environment in which they
operate permits implementation of the functionality operate permits implementation of the functionality
defined in this document. defined in this document.
</t> </t>
</section> </section>
<section numbered="true" toc="default">
<name>Security Considerations</name>
<t>
<section title="Security Considerations"> <xref target="RFC7481" format="default"/> describes security require
ments
<t>
<xref target="RFC7481" /> describes security requirements
and considerations for RDAP generally. Additionally, and considerations for RDAP generally. Additionally,
guidance as to the use of TLS has changed since that guidance as to the use of TLS has changed since that
document was published: see <xref target="RFC8446" /> and document was published: see <xref target="RFC8446" format="default"/
<xref target="BCP195" /> for further detail. > and
<xref target="BCP195" format="default"/> for further detail.
</t>
<t> </t>
<t>
<xref target="RFC9082" /> includes security considerations <xref target="RFC9082" format="default"/> includes security consider ations
relating to object retrieval in RDAP. Those relating to object retrieval in RDAP. Those
considerations are relevant here as well. considerations are relevant here as well.
</t> </t>
</section> </section>
<section anchor="IANA" numbered="true" toc="default">
<name>IANA Considerations</name>
<section numbered="true" toc="default">
<name>RDAP Extensions Registry</name>
<t>
<section anchor="IANA" title="IANA Considerations"> IANA has registered the following values in
the <eref brackets="angle" target="https://www.iana.org/assignme
<section title="RDAP Extensions Registry"> nts/rdap-extensions">"RDAP
Extensions" registry</eref>.
<t>
IANA is requested to register the following values in
the <eref
target="https://www.iana.org/assignments/rdap-extensions/rdap-ex
tensions.xhtml">RDAP
Extensions Registry</eref>.
</t>
<section title="rirSearch1">
<list style="hanging" spacing="compact">
<t hangText="Extension identifier:">rirSearch1</t>
<t hangText="Registry operator:">Any</t>
<t hangText="Published specification:">[this document]</t>
<t hangText="Contact:">IETF &lt;iesg@ietf.org&gt;</t>
<t hangText="Intended usage:">This extension identifier is u
sed for INR-specific search operations.</t>
</list>
</section>
<section title="ips">
<list style="hanging" spacing="compact">
<t hangText="Extension identifier:">ips</t>
<t hangText="Registry operator:">Any</t>
<t hangText="Published specification:">[this document]</t>
<t hangText="Contact:">IETF &lt;iesg@ietf.org&gt;</t>
<t hangText="Intended usage:">This extension identifier is u
sed for INR-specific search operations.</t>
</list>
</section>
<section title="autnums">
<list style="hanging" spacing="compact">
<t hangText="Extension identifier:">autnums</t>
<t hangText="Registry operator:">Any</t>
<t hangText="Published specification:">[this document]</t>
<t hangText="Contact:">IETF &lt;iesg@ietf.org&gt;</t>
<t hangText="Intended usage:">This extension identifier is u
sed for INR-specific search operations.</t>
</list>
</section>
<section title="ipSearchResults">
<list style="hanging" spacing="compact">
<t hangText="Extension identifier:">ipSearchResults</t>
<t hangText="Registry operator:">Any</t>
<t hangText="Published specification:">[this document]</t>
<t hangText="Contact:">IETF &lt;iesg@ietf.org&gt;</t>
<t hangText="Intended usage:">This extension identifier is u
sed for INR-specific search operations.</t>
</list>
</section>
<section title="autnumSearchResults">
<list style="hanging" spacing="compact">
<t hangText="Extension identifier:">autnumSearchResults</t>
<t hangText="Registry operator:">Any</t>
<t hangText="Published specification:">[this document]</t>
<t hangText="Contact:">IETF &lt;iesg@ietf.org&gt;</t>
<t hangText="Intended usage:">This extension identifier is u
sed for INR-specific search operations.</t>
</list>
</section>
</t>
<section numbered="true" toc="default">
<name>rirSearch1</name>
<dl newline="false" spacing="compact">
<dt>Extension Identifier:</dt>
<dd>rirSearch1</dd>
<dt>Registry operator:</dt>
<dd>Any</dd>
<dt>Specification:</dt>
<dd>RFC 9910</dd>
<dt>Contact:</dt>
<dd>IETF &lt;iesg@ietf.org&gt;</dd>
<dt>Intended Usage:</dt>
<dd>This extension identifier is used for INR-specific search operat
ions.</dd>
</dl>
</section> </section>
<section numbered="true" toc="default">
<section title="Link Relations Registry"> <name>ips</name>
<dl newline="false" spacing="compact">
<t> <dt>Extension Identifier:</dt>
<dd>ips</dd>
IANA is requested to register the following values in <dt>Registry operator:</dt>
the <eref <dd>Any</dd>
target="https://www.iana.org/assignments/link-relations/link-rel <dt>Specification:</dt>
ations.xhtml">Link <dd>RFC 9910</dd>
Relations Registry</eref>. <dt>Contact:</dt>
<dd>IETF &lt;iesg@ietf.org&gt;</dd>
</t> <dt>Intended Usage:</dt>
<dd>This extension identifier is used for INR-specific search operat
<section title="rdap-up"> ions.</dd>
<list style="hanging" spacing="compact"> </dl>
<t hangText="Relation Name:">rdap-up</t>
<t hangText="Description:">Refers to an RDAP parent object i
n a hierarchy of objects.</t>
<t hangText="Reference:">[this document]</t>
</list>
</section>
<section title="rdap-down">
<list style="hanging" spacing="compact">
<t hangText="Relation Name:">rdap-down</t>
<t hangText="Description:">Refers to a set of RDAP child obj
ects in a hierarchy of objects.</t>
<t hangText="Reference:">[this document]</t>
</list>
</section>
<section title="rdap-top">
<list style="hanging" spacing="compact">
<t hangText="Relation Name:">rdap-top</t>
<t hangText="Description:">Refers to the topmost RDAP parent
object in a hierarchy of objects.</t>
<t hangText="Reference:">[this document]</t>
</list>
</section>
<section title="rdap-bottom">
<list style="hanging" spacing="compact">
<t hangText="Relation Name:">rdap-bottom</t>
<t hangText="Description:">Refers to the set of child RDAP o
bjects that do not themselves have child objects, in a hierarchy of objects.</t>
<t hangText="Reference:">[this document]</t>
</list>
</section>
<section title="rdap-active">
<list style="hanging" spacing="compact">
<t hangText="Relation Name:">rdap-active</t>
<t hangText="Description:">The target is for an RDAP RIR sea
rch that filters for the status "active".</t>
<t hangText="Reference:">[this document]</t>
</list>
</section>
</section> </section>
<section numbered="true" toc="default">
<section title="RDAP Reverse Search Registry"> <name>autnums</name>
<dl newline="false" spacing="compact">
<t> <dt>Extension Identifier:</dt>
<dd>autnums</dd>
IANA is requested to register the following entries in <dt>Registry operator:</dt>
the <eref <dd>Any</dd>
target="https://www.iana.org/assignments/rdap-reverse-search/rda <dt>Specification:</dt>
p-reverse-search.xhtml">RDAP <dd>RFC 9910</dd>
Reverse Search</eref> registry. <dt>Contact:</dt>
<dd>IETF &lt;iesg@ietf.org&gt;</dd>
</t> <dt>Intended Usage:</dt>
<dd>This extension identifier is used for INR-specific search operat
<section title="fn"> ions.</dd>
<list style="hanging" spacing="compact"> </dl>
<t hangText="Property:">fn</t>
<t hangText="Description:">The server supports the IP/autnum
search based on the full name (a.k.a formatted name) of an associated entity.</
t>
<t hangText="Searchable Resource Type:">ips, autnums</t>
<t hangText="Related Resource Type:">entity</t>
<t hangText="Registrant:">IETF</t>
<t hangText="Contact Information:">iesg@ietf.org</t>
<t hangText="Reference:">[this document]</t>
</list>
</section>
<section title="handle">
<list style="hanging" spacing="compact">
<t hangText="Property:">handle</t>
<t hangText="Description:">The server supports the IP/autnum
search based on the handle of an associated entity.</t>
<t hangText="Searchable Resource Type:">ips, autnums</t>
<t hangText="Related Resource Type:">entity</t>
<t hangText="Registrant:">IETF</t>
<t hangText="Contact Information:">iesg@ietf.org</t>
<t hangText="Reference:">[this document]</t>
</list>
</section>
<section title="email">
<list style="hanging" spacing="compact">
<t hangText="Property:">email</t>
<t hangText="Description:">The server supports the IP/autnum
search based on the email address of an associated entity.</t>
<t hangText="Searchable Resource Type:">ips, autnums</t>
<t hangText="Related Resource Type:">entity</t>
<t hangText="Registrant:">IETF</t>
<t hangText="Contact Information:">iesg@ietf.org</t>
<t hangText="Reference:">[this document]</t>
</list>
</section>
<section title="role">
<list style="hanging" spacing="compact">
<t hangText="Property:">role</t>
<t hangText="Description:">The server supports the IP/autnum
search based on the role of an associated entity.</t>
<t hangText="Searchable Resource Type:">ips, autnums</t>
<t hangText="Related Resource Type:">entity</t>
<t hangText="Registrant:">IETF</t>
<t hangText="Contact Information:">iesg@ietf.org</t>
<t hangText="Reference:">[this document]</t>
</list>
</section>
</section> </section>
<section numbered="true" toc="default">
<section title="RDAP Reverse Search Mapping Registry"> <name>ipSearchResults</name>
<dl newline="false" spacing="compact">
<t> <dt>Extension Identifier:</dt>
<dd>ipSearchResults</dd>
IANA is requested to register the following entries <dt>Registry operator:</dt>
in the <eref <dd>Any</dd>
target="https://www.iana.org/assignments/rdap-reverse-search-map <dt>Specification:</dt>
ping/rdap-reverse-search-mapping.xhtml">RDAP <dd>RFC 9910</dd>
Reverse Search Mapping</eref> registry. <dt>Contact:</dt>
<dd>IETF &lt;iesg@ietf.org&gt;</dd>
</t> <dt>Intended Usage:</dt>
<dd>This extension identifier is used for INR-specific search operat
<section title="fn"> ions.</dd>
<list style="hanging" spacing="compact"> </dl>
<t hangText="Property:">fn</t> </section>
<t hangText="Property Path:">$.entities[*].vcardArray[1][?(@ <section numbered="true" toc="default">
[0]=='fn')][3]</t> <name>autnumSearchResults</name>
<t hangText="Searchable Resource Type:">ips, autnums</t> <dl newline="false" spacing="compact">
<t hangText="Related Resource Type:">entity</t> <dt>Extension Identifier:</dt>
<t hangText="Registrant:">IETF</t> <dd>autnumSearchResults</dd>
<t hangText="Contact Information:">iesg@ietf.org</t> <dt>Registry operator:</dt>
<t hangText="Reference:">[this document]</t> <dd>Any</dd>
</list> <dt>Specification:</dt>
</section> <dd>RFC 9910</dd>
<dt>Contact:</dt>
<section title="handle"> <dd>IETF &lt;iesg@ietf.org&gt;</dd>
<list style="hanging" spacing="compact"> <dt>Intended Usage:</dt>
<t hangText="Property:">handle</t> <dd>This extension identifier is used for INR-specific search operat
<t hangText="Property Path:">$.entities[*].handle</t> ions.</dd>
<t hangText="Searchable Resource Type:">ips, autnums</t> </dl>
<t hangText="Related Resource Type:">entity</t>
<t hangText="Registrant:">IETF</t>
<t hangText="Contact Information:">iesg@ietf.org</t>
<t hangText="Reference:">[this document]</t>
</list>
</section>
<section title="email">
<list style="hanging" spacing="compact">
<t hangText="Property:">email</t>
<t hangText="Property Path:">$.entities[*].vcardArray[1][?(@
[0]=='email')][3]</t>
<t hangText="Searchable Resource Type:">ips, autnums</t>
<t hangText="Related Resource Type:">entity</t>
<t hangText="Registrant:">IETF</t>
<t hangText="Contact Information:">iesg@ietf.org</t>
<t hangText="Reference:">[this document]</t>
</list>
</section>
<section title="role">
<list style="hanging" spacing="compact">
<t hangText="Property:">role</t>
<t hangText="Property Path:">$.entities[*].roles</t>
<t hangText="Searchable Resource Type:">ips, autnums</t>
<t hangText="Related Resource Type:">entity</t>
<t hangText="Registrant:">IETF</t>
<t hangText="Contact Information:">iesg@ietf.org</t>
<t hangText="Reference:">[this document]</t>
</list>
</section>
</section> </section>
</section>
<section anchor="implementation-status">
<name>Implementation Status</name>
<aside>
<t>Note to the RFC Editor - remove this section before publication, as
well as the reference to RFC 7942.</t>
</aside>
<t>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 <xref target="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.</t>
<t>According to <xref target="RFC7942"/>, "this will allow reviewers and w
orking 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".</t>
<section anchor="apnic-rdap-implementation" title="APNIC RDAP Implementati
on">
<t><list style="none" spacing="compact">
<t>Responsible Organization: Asia-Pacific Network Information Centre (
APNIC)<vspace blankLines='1' /></t>
<t>Location: https://github.com/APNIC-net/rdap-rmp-demo/tree/rir-searc
h<vspace blankLines='1' /></t>
<t>Description: This implementation includes support for the various s
earches and responses described in this document.<vspace blankLines='1' /></t>
<t>Level of Maturity: This is a proof-of-concept implementation.<vspac
e blankLines='1' /></t>
<t>Coverage: This implementation includes all of the features describe
d in this
specification.<vspace blankLines='1' /></t>
<t>Contact Information: Tom Harrison, tomh@apnic.net</t>
</list></t>
</section> </section>
<section numbered="true" toc="default">
<name>Link Relations Registry</name>
<t>
<section anchor="ripe-ncc-rdap-implementation" title="RIPE NCC RDAP Implem IANA has registered the following values in
entation"> the <eref brackets="angle" target="https://www.iana.org/assignme
<t><list style="none" spacing="compact"> nts/link-relations">"Link
<t>Responsible Organization: RIPE NCC<vspace blankLines='1' /></t> Relations" registry</eref>.
<t>Location: https://github.com/RIPE-NCC/whois<vspace blankLines='1' /
></t> </t>
<t>Description: This implementation includes support for several of th <section numbered="true" toc="default">
e searches and responses as at version 14 of this document.<vspace blankLines='1 <name>rdap-up</name>
' /></t> <dl newline="false" spacing="compact">
<t>Level of Maturity: This is a production implementation.<vspace blan <dt>Relation Name:</dt>
kLines='1' /></t> <dd>rdap-up</dd>
<t>Coverage: This implementation includes IP and domain relation searc <dt>Description:</dt>
hes, as well as the links that correspond to those searches.<vspace blankLines=' <dd>Refers to an RDAP parent object in a hierarchy of objects.</dd>
1' /></t> <dt>Reference:</dt>
<t>Contact Information: Ed Shryane, eshryane@ripe.net</t> <dd>RFC 9910</dd>
</list></t> </dl>
</section>
<section numbered="true" toc="default">
<name>rdap-down</name>
<dl newline="false" spacing="compact">
<dt>Relation Name:</dt>
<dd>rdap-down</dd>
<dt>Description:</dt>
<dd>Refers to a set of RDAP child objects in a hierarchy of objects.
</dd>
<dt>Reference:</dt>
<dd>RFC 9910</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>rdap-top</name>
<dl newline="false" spacing="compact">
<dt>Relation Name:</dt>
<dd>rdap-top</dd>
<dt>Description:</dt>
<dd>Refers to the topmost RDAP parent object in a hierarchy of objec
ts.</dd>
<dt>Reference:</dt>
<dd>RFC 9910</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>rdap-bottom</name>
<dl newline="false" spacing="compact">
<dt>Relation Name:</dt>
<dd>rdap-bottom</dd>
<dt>Description:</dt>
<dd>Refers to the set of child RDAP objects that do not themselves h
ave child objects, in a hierarchy of objects.</dd>
<dt>Reference:</dt>
<dd>RFC 9910</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>rdap-active</name>
<dl newline="false" spacing="compact">
<dt>Relation Name:</dt>
<dd>rdap-active</dd>
<dt>Description:</dt>
<dd>The target is for an RDAP RIR search that filters for the status
"active".</dd>
<dt>Reference:</dt>
<dd>RFC 9910</dd>
</dl>
</section>
</section> </section>
<section numbered="true" toc="default">
<name>RDAP Reverse Search Registry</name>
<t>
</section> IANA has registered the following entries in
the <eref brackets="angle" target="https://www.iana.org/assignme
nts/rdap-reverse-search/">"RDAP
Reverse Search"</eref> registry.
<section anchor="Acknowledgements" title="Acknowledgements"> </t>
<section numbered="true" toc="default">
<name>fn</name>
<dl newline="false" spacing="compact">
<dt>Property:</dt>
<dd>fn</dd>
<dt>Description:</dt>
<dd>The server supports the IP/autnum search based on the full name
(a.k.a. formatted name) of an associated entity.</dd>
<dt>Searchable Resource Type:</dt>
<dd>ips, autnums</dd>
<dt>Related Resource Type:</dt>
<dd>entity</dd>
<dt>Registrant:</dt>
<dd>IETF</dd>
<dt>Contact Information:</dt>
<dd>iesg@ietf.org</dd>
<dt>Reference:</dt>
<dd>RFC 9910</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>handle</name>
<dl newline="false" spacing="compact">
<dt>Property:</dt>
<dd>handle</dd>
<dt>Description:</dt>
<dd>The server supports the IP/autnum search based on the handle of
an associated entity.</dd>
<dt>Searchable Resource Type:</dt>
<dd>ips, autnums</dd>
<dt>Related Resource Type:</dt>
<dd>entity</dd>
<dt>Registrant:</dt>
<dd>IETF</dd>
<dt>Contact Information:</dt>
<dd>iesg@ietf.org</dd>
<dt>Reference:</dt>
<dd>RFC 9910</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>email</name>
<dl newline="false" spacing="compact">
<dt>Property:</dt>
<dd>email</dd>
<dt>Description:</dt>
<dd>The server supports the IP/autnum search based on the email addr
ess of an associated entity.</dd>
<dt>Searchable Resource Type:</dt>
<dd>ips, autnums</dd>
<dt>Related Resource Type:</dt>
<dd>entity</dd>
<dt>Registrant:</dt>
<dd>IETF</dd>
<dt>Contact Information:</dt>
<dd>iesg@ietf.org</dd>
<dt>Reference:</dt>
<dd>RFC 9910</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>role</name>
<dl newline="false" spacing="compact">
<dt>Property:</dt>
<dd>role</dd>
<dt>Description:</dt>
<dd>The server supports the IP/autnum search based on the role of an
associated entity.</dd>
<dt>Searchable Resource Type:</dt>
<dd>ips, autnums</dd>
<dt>Related Resource Type:</dt>
<dd>entity</dd>
<dt>Registrant:</dt>
<dd>IETF</dd>
<dt>Contact Information:</dt>
<dd>iesg@ietf.org</dd>
<dt>Reference:</dt>
<dd>RFC 9910</dd>
</dl>
</section>
</section>
<section numbered="true" toc="default">
<name>RDAP Reverse Search Mapping Registry</name>
<t> <t>
The authors wish to thank Mario Loffredo, Andy Newton, IANA has registered the following entries
Antoin Verschuren, James Gould, Scott Hollenbeck, Orie in the <eref brackets="angle" target="https://www.iana.org/assig
Steele, Russ Housley, John Levine, Stewart Bryant, Mark nments/rdap-reverse-search-mapping">"RDAP
Nottingham, Mohamed Boucadair, Deb Cooley, Éric Vyncke, Reverse Search Mapping"</eref> registry.
and Roman Danyliw for document review and associated
comments.
</t> </t>
<section numbered="true" toc="default">
<name>fn</name>
<dl newline="false" spacing="compact">
<dt>Property:</dt>
<dd>fn</dd>
<dt>Property Path:</dt>
<dd>$.entities[*].vcardArray[1][?(@[0]=='fn')][3]</dd>
<dt>Searchable Resource Type:</dt>
<dd>ips, autnums</dd>
<dt>Related Resource Type:</dt>
<dd>entity</dd>
<dt>Registrant:</dt>
<dd>IETF</dd>
<dt>Contact Information:</dt>
<dd>iesg@ietf.org</dd>
<dt>Reference:</dt>
<dd>RFC 9910</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>handle</name>
<dl newline="false" spacing="compact">
<dt>Property:</dt>
<dd>handle</dd>
<dt>Property Path:</dt>
<dd>$.entities[*].handle</dd>
<dt>Searchable Resource Type:</dt>
<dd>ips, autnums</dd>
<dt>Related Resource Type:</dt>
<dd>entity</dd>
<dt>Registrant:</dt>
<dd>IETF</dd>
<dt>Contact Information:</dt>
<dd>iesg@ietf.org</dd>
<dt>Reference:</dt>
<dd>RFC 9910</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>email</name>
<dl newline="false" spacing="compact">
<dt>Property:</dt>
<dd>email</dd>
<dt>Property Path:</dt>
<dd>$.entities[*].vcardArray[1][?(@[0]=='email')][3]</dd>
<dt>Searchable Resource Type:</dt>
<dd>ips, autnums</dd>
<dt>Related Resource Type:</dt>
<dd>entity</dd>
<dt>Registrant:</dt>
<dd>IETF</dd>
<dt>Contact Information:</dt>
<dd>iesg@ietf.org</dd>
<dt>Reference:</dt>
<dd>RFC 9910</dd>
</dl>
</section>
<section numbered="true" toc="default">
<name>role</name>
<dl newline="false" spacing="compact">
<dt>Property:</dt>
<dd>role</dd>
<dt>Property Path:</dt>
<dd>$.entities[*].roles</dd>
<dt>Searchable Resource Type:</dt>
<dd>ips, autnums</dd>
<dt>Related Resource Type:</dt>
<dd>entity</dd>
<dt>Registrant:</dt>
<dd>IETF</dd>
<dt>Contact Information:</dt>
<dd>iesg@ietf.org</dd>
<dt>Reference:</dt>
<dd>RFC 9910</dd>
</dl>
</section>
</section>
</section> </section>
</middle> </middle>
<back> <back>
<references title="Normative References"> <references>
&RFC2119; <name>References</name>
&RFC9110; <references>
&RFC7481; <name>Normative References</name>
&RFC8446; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2
&RFC9082; 119.xml"/>
&RFC9083; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
&RFC8174; 110.xml"/>
&RFC9536; <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
&BCP195; 481.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
446.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
082.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
083.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8
174.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9
536.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml9/reference.BCP.
0195.xml"/>
</references>
<references>
<name>Informative References</name>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3
912.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6
973.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7
480.xml"/>
</references>
</references> </references>
<references title="Informative References"> <!-- [rfced] FYI, we updated "Whois" to "WHOIS" (2 instances) to
&RFC3912; match the cited RFC - [RFC3912] - as well as usage in STD 95. Please
&RFC6973; let us know if you prefer otherwise.
&RFC7480; -->
&RFC7942;
</references> <!-- [rfced] Please review the "Inclusive Language" portion of the online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are needed. Updates of this nature typically
result in more precise language, which is helpful for readers.
For example, please consider whether the following should be updated:
whitespace
-->
<section anchor="Acknowledgements" numbered="false" toc="default">
<name>Acknowledgements</name>
<t>The authors wish to thank <contact fullname="Mario Loffredo"/>,
<contact fullname="Andy Newton"/>, <contact fullname="Antoin
Verschuren"/>, <contact fullname="James Gould"/>, <contact
fullname="Scott Hollenbeck"/>, <contact fullname="Orie Steele"/>,
<contact fullname="Russ Housley"/>, <contact fullname="John Levine"/>,
<contact fullname="Stewart Bryant"/>, <contact fullname="Mark
Nottingham"/>, <contact fullname="Mohamed Boucadair"/>, <contact
fullname="Deb Cooley"/>, <contact fullname="Éric Vyncke"/>, and <contact
fullname="Roman Danyliw"/> for document review and associated comments.</t
>
</section>
</back> </back>
</rfc> </rfc>
 End of changes. 195 change blocks. 
1243 lines changed or deleted 1175 lines changed or added

This html diff was produced by rfcdiff 1.48.