<?xml version="1.0" encoding="utf-8"?> 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"> nbsp    "&#160;">
  <!ENTITY RFC3912 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3912.xml"> zwsp   "&#8203;">
  <!ENTITY RFC6973 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6973.xml"> nbhy   "&#8209;">
  <!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.0195.xml"> wj     "&#8288;">
]>
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-regext-rdap-rir-search-19" ipr="trust200902"> number="9910" consensus="true"  ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en" tocInclude="true" tocDepth="4" symRefs="true" sortRefs="true" version="3">

  <front>
    <title abbrev="RDAP RIR Search">Registration Data Access Protocol (RDAP) Regional Internet Registry (RIR) Search</title>
    <seriesInfo name="RFC" value="9910"/>
    <author initials="T." surname="Harrison" fullname="Tom Harrison">
      <organization abbrev="APNIC">Asia Pacific Network Information Centre</organization>
      <address>
        <postal>
          <street>6 Cordelia St</street>
          <city>South Brisbane</city>
          <code>4101</code>
          <country>Australia</country>
          <region>QLD</region>
        </postal>
        <email>tomh@apnic.net</email>
      </address>
    </author>
    <author initials="J." fullname="Jasdip Singh" surname="Singh">
      <organization abbrev="ARIN">American Registry for Internet Numbers</organization>
      <address>
        <postal>
          <street>PO Box 232290</street>
          <city>Centreville</city>
          <region>VA</region>
          <code>20120</code>
          <country>United States of America</country>
        </postal>
        <email>jasdips@arin.net</email>
      </address>
    </author>

    <area>General</area>
    <workgroup>Internet Engineering Task Force</workgroup>
    <keyword>template</keyword>
    <date month="December" year="2025"/>
    <area>ART</area>
    <workgroup>regext</workgroup>

<!-- [rfced] Please insert any keywords (beyond those that appear in
the title) for use on https://www.rfc-editor.org/search. -->

<keyword>example</keyword>

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

      </t>
    </abstract>
  </front>
  <middle>
    <section anchor="introduction" title="Introduction"> numbered="true" toc="default">
      <name>Introduction</name>
      <t>
            The <xref target="RFC7480">Registration target="RFC7480" format="default">Registration Data Access
            Protocol (RDAP)</xref> is used by Regional Internet
            Registries (RIRs) and Domain Name Registries (DNRs) to
            provide access to their resource registration information.
            The core specifications for RDAP define basic search
            functionality, but this is limited to domains,
            nameservers, and entities.  No searches were defined for
            IP networks or autonomous system numbers.  In an effort to
            have RDAP reach feature parity with the existing RIR Whois WHOIS
            <xref target="RFC3912" format="default" sectionFormat="of" derivedContent="RFC3912"/>
            services in this respect, this document defines additional
            search options for IP networks and autonomous system
            numbers.

      </t>
      <t>

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

      </t>
      <section anchor="conventions" numbered="true" toc="default">
        <name>Conventions Used in This Document</name>

            <t>The
        <t>
    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
            "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
            RECOMMENDED", "MAY", "<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 "OPTIONAL" "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 BCP&nbsp;14 <xref
            target="RFC2119" format="default"/> target="RFC2119"/> <xref target="RFC8174"
            format="default"/>
    target="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.</t> here.
        </t>

        <t>Indentation and whitespace in examples are provided
            only to illustrate element relationships, and they are not a
            required feature of this protocol.</t>
        <t>"..." in examples is used as shorthand for elements
            defined outside of this document, as well as to abbreviate
            elements that are too long.</t>
      </section>
    </section>
    <section title="Basic Searches"> numbered="true" toc="default">
      <name>Basic Searches</name>
      <section title="Path Segments"> numbered="true" toc="default">
        <name>Path Segments</name>
        <t>

                The new resource type path segments for basic search (similar to
                the searches defined in <xref target="RFC9082" /> format="default"/> and <xref target="RFC9083" />) format="default"/>) are:

                <list>

                    <t>

                        'ips': Used

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

                    </t>

                    <t>

                        'autnums': Used 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.

                    </t>

                </list>

            </t>
  attributes.</dd>
</dl>
        <t>

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

        </t>
        <t>

                <xref target="RFC9082" sectionFormat="of" section="4.1" /> format="default"/> describes the use of a trailing
                domain label suffix in a partial string search.  It is
                not necessary that servers support this type of search
                pattern for the basic searches defined in this
                document, since those searches do not relate to domain
                name members.

        </t>
      </section>
      <section title="IP numbered="true" toc="default">
        <name>IP Network Search">

            <t>

                Syntax: ips?handle=&lt;handle Search</name>

<dl spacing="normal" newline="false">
  <dt>Syntax:</dt><dd>ips?handle=&lt;handle search pattern&gt;

            </t>

            <t>

                Syntax: ips?name=&lt;name pattern&gt;</dd>
  <dt>Syntax:</dt><dd>ips?name=&lt;name search pattern&gt;

            </t> pattern&gt;</dd>
</dl>
        <t>

                Searches for IP network (see <xref target="RFC9083" sectionFormat="of" section="5.4" />) format="default"/>) information by
                handle are specified using the form:

        </t>

            <t>
        <t indent="3">

                ips?handle=XXXX

        </t>
        <t>

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

        </t>

            <t>
        <t indent="3">

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

        </t>
        <t>

                Searches for IP network (see <xref target="RFC9083" sectionFormat="of" section="5.4" />) format="default"/>) information by
                name are specified using the form:

        </t>

            <t>
        <t indent="3">

                ips?name=XXXX

        </t>
        <t>

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

        </t>

            <t>
        <t indent="3">

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

        </t>
      </section>
      <section title="Autonomous numbered="true" toc="default">
        <name>Autonomous System Number Search">

            <t>

                Syntax: autnums?handle=&lt;handle Search</name>

<dl spacing="normal" newline="false">
  <dt>Syntax:</dt><dd>autnums?handle=&lt;handle search pattern&gt;

            </t>

            <t>

                Syntax: autnums?name=&lt;name pattern&gt;</dd>
  <dt>Syntax:</dt><dd>autnums?name=&lt;name search pattern&gt;

            </t> pattern&gt;</dd>
</dl>

        <t>
                Searches for autonomous system number (see <xref target="RFC9083" sectionFormat="of" section="5.5" />) format="default"/>)
                information by handle are specified using the form:

        </t>

            <t>
        <t indent="3">

                autnums?handle=XXXX

        </t>
        <t>

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

        </t>

            <t>
        <t indent="3">

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

        </t>
        <t>

                Searches for autonomous system number (see <xref target="RFC9083" sectionFormat="of" section="5.5" />) format="default"/>)
                information by name are specified using the form:

        </t>

            <t>
        <t indent="3">

                autnums?name=XXXX

        </t>
        <t>

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

        </t>

            <t>
        <t indent="3">

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

        </t>
      </section>
    </section>
    <section title="Relation Searches"> numbered="true" toc="default">
      <name>Relation Searches</name>
      <t>

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

      </t>
      <section title="Path Segments"> numbered="true" toc="default">
        <name>Path Segments</name>
        <t>

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

                <list>

                    <t>&lt;relation&gt;: A

        </t>

<dl spacing="normal" newline="false">
  <dt>&lt;relation&gt;:</dt><dd>a relation type, as defined in Section 3.2.2 <xref target="sec3.2.2"/>
  of this document.</t>

                    <t>&lt;IP address&gt;: An document.</dd>
  <dt>&lt;IP address&gt;:</dt><dd>an IP address, as defined in <xref
  target="RFC9082" sectionFormat="of" section="3.1.1" />.</t>

                    <t>&lt;CIDR prefix&gt;: The format="default"/>.</dd>
  <dt>&lt;CIDR prefix&gt;:</dt><dd>the first address of a CIDR Classless Inter-Domain Routing (CIDR) block, as
  defined in <xref target="RFC9082" sectionFormat="of" section="3.1.1" />.</t>

                    <t>&lt;CIDR length&gt;: The
  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" />.</t>

                    <t>&lt;domain name&gt;: A fully-qualified
  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" />.</t>

                    <t>&lt;autonomous
  format="default"/>.</dd>
  <dt>&lt;autonomous system number or range&gt;: An 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 ('-',
                    US-ASCII ASCII value 0x2D), where the second number is greater
  than the first.</t>

                    <t>&lt;resource first.</dd>
  <dt>&lt;resource type search path segment&gt;: A segment&gt;:</dt><dd>a search path segment
  corresponding to an Internet Number Resource (INR) object class (i.e. (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 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.</t>

                    <t>&lt;status&gt;: an performed.</dd>
  <dt>&lt;status&gt;:</dt><dd>an object status value, as defined in <xref
  target="RFC9083" sectionFormat="of" section="4.6"
                    />.</t>

                </list>

            </t> format="default"/>.</dd>
</dl>
        <t>

                The new resource type path segments for relation
                search (similar to the searches defined in <xref target="RFC9082" /> format="default"/> and <xref target="RFC9083" />) format="default"/>)
                are:

                <list>

                    <t>

                        'ips/rirSearch1/&lt;relation&gt;/&lt;IP address&gt;':
                        Used

        </t>
<dl spacing="normal" newline="false">
  <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
  to match a set of IP networks.

                    </t>

                    <t>

                        'ips/rirSearch1/&lt;relation&gt;/&lt;CIDR networks.</dd>
  <dt>'ips/rirSearch1/&lt;relation&gt;/&lt;CIDR prefix&gt;/&lt;CIDR length&gt;':
                        Used length&gt;':</dt>
  <dd>Used to identify an IP network search using a relation and an IP address
  range to match a set of IP networks.

                    </t>

                    <t>

                        'autnums/rirSearch1/&lt;relation&gt;/&lt;autonomous networks.</dd>
  <dt>'autnums/rirSearch1/&lt;relation&gt;/&lt;autonomous system number or range&gt;':
                        Used range&gt;':</dt>
  <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.

                    </t>

                    <t>

                        'domains/rirSearch1/&lt;relation&gt;/&lt;domain name&gt;':
                        Used objects.</dd>
  <dt>'domains/rirSearch1/&lt;relation&gt;/&lt;domain name&gt;':</dt>
  <dd>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> domains.</dd>
</dl>
      </section>
      <section title="Relation Search" anchor="relation-search">

            <t>

                Syntax: &lt;resource anchor="relation-search" numbered="true" toc="default">
        <name>Relation Search</name>

<dl spacing="normal" newline="false">
  <dt>Syntax:</dt><dd>&lt;resource type search path segment&gt;/rirSearch1/&lt;relation&gt;/&lt;object value&gt;[?status=&lt;status&gt;]

            </t> value&gt;[?status=&lt;status&gt;]</dd>
</dl>

        <t>

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

        </t>
        <t>

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

        </t>
        <section title="Definitions"> anchor="sec3.2.1" numbered="true" toc="default">
          <name>Definitions</name>
          <t>

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

          </t>
          <figure anchor="registry-objects">
            <name>Example registry objects</name>
                        <sourcecode type="drawing"><![CDATA[ Registry Objects</name>
            <artwork><![CDATA[
                        +--------------+
                        | 192.0.2.0/24 |
                        +--------------+
                           /        \
              +--------------+    +----------------+
              | 192.0.2.0/25 |    | 192.0.2.128/25 |
              +--------------+    +----------------+
                 /                   /          \
     +--------------+   +----------------+  +----------------+
     | 192.0.2.0/28 |   | 192.0.2.128/26 |  | 192.0.2.192/26 |
     +--------------+   +----------------+  +----------------+
        /
 +--------------+
 | 192.0.2.0/32 |
 +--------------+
]]></sourcecode>
 +--------------+]]></artwork>
          </figure>

                    the
          <t>

                    The relationships of INR object value to parent/child parent object
                    relationships (as
                    well as to child objects) 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">
            <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
                    to registry objects, because users can provide
                    arbitrary object values as input to the searches
                    defined in this document.)

          </t>
          <t>

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

          </t>
          <table anchor="top">
            <name>Top objects</name> Objects</name>
            <thead>
              <tr>
                <th>INR object value</th>
                <th>Top object</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td>192.0.2.0/32</td>
                <td>192.0.2.0/24</td>
              </tr>
              <tr>
                <td>192.0.2.0/28</td>
                <td>192.0.2.0/24</td>
              </tr>
              <tr>
                <td>192.0.2.64/26</td>
                <td>192.0.2.0/24</td>
              </tr>
              <tr>
                <td>192.0.2.128/26</td>
                <td>192.0.2.0/24</td>
              </tr>
              <tr>
                <td>192.0.2.192/26</td>
                <td>192.0.2.0/24</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="bottom">
            <name>Bottom objects</name> Objects</name>
            <thead>
              <tr>
                <th>INR object value</th>
                <th>Bottom objects</th>
              </tr>
            </thead>
            <tbody>
              <tr>
                <td>192.0.2.0/24</td>
                <td>192.0.2.0/25, 192.0.2.0/28, 192.0.2.0/32, 192.0.2.128/26, 192.0.2.192/26</td>
              </tr>
              <tr>
                <td>192.0.2.0/25</td>
                <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>
                <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/28, 192.0.2.0/32</td>
              </tr>
              <tr>
                <td>192.0.2.0/31</td>
                <td>192.0.2.0/28, 192.0.2.0/32</td>
              </tr>
              <tr>
                <td>192.0.2.0/32</td>
                <td>N/A</td>
              </tr>
            </tbody>
          </table>
          <t>

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

          </t>
          <t>

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

          </t>
          <t>

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

          </t>
        </section>
        <section title="Relations"> anchor="sec3.2.2" numbered="true" toc="default">
          <name>Relations</name>
          <section title="Single-Result Searches"> numbered="true" toc="default">
            <name>Single-Result Searches</name>
            <section title='"rdap-up"'> numbered="true" toc="default">
              <name>"rdap-up"</name>
              <t>

                            If the server receives a search containing
                            the relation value "rdap-up", it will
                            return the parent object for the specified
                            INR object value as though that object had
                            been requested directly.  If no such
                            object exists, it will respond with a an HTTP
                            404 (Not Found) <xref target="RFC9110" /> format="default"/>
                            search response.

              </t>
            </section>
            <section title='"rdap-top"'> numbered="true" toc="default">
              <name>"rdap-top"</name>
<!--[rfced] search response vs. response code vs. response

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:

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
                            the relation value "rdap-top", it will
                            return the top object for the specified
                            INR object value as though that object had
                            been requested directly.  If no such
                            object exists, it will respond with an
                            HTTP 404 (Not Found) <xref target="RFC9110" /> format="default"/> search response.

              </t>
            </section>
          </section>
          <section title="Multiple-Result Searches"> numbered="true" toc="default">
            <name>Multiple-Result Searches</name>
            <section title='"rdap-down"'> numbered="true" toc="default">
              <name>"rdap-down"</name>
              <t>

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

              </t>
            </section>
            <section title='"rdap-bottom"'> numbered="true" toc="default">
              <name>"rdap-bottom"</name>
              <t>

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

              </t>
            </section>
          </section>
        </section>
      </section>
      <section title="Status" anchor="status"> anchor="status" numbered="true" toc="default">
        <name>Status</name>
        <t>

                If the "status" argument is provided, then response
                processing will proceed as though all objects without
                the specified status had first been removed from the
                database.  For example, if the registry objects from
                section 3.2.1
                <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>

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

        </t>
        <t>

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

        </t>
        <t>

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

        </t>
        <t>

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

        </t>
      </section>
      <section title="Link Relations"> numbered="true" toc="default">
        <name>Link Relations</name>
        <t>

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

        </t>
        <figure anchor="example-links-ipv4">
          <name>Example links Links in an IPv4 response</name>
<artwork align="center" type="ascii-art" name="" alt=""><![CDATA[ Response</name>
          <sourcecode type="json"><![CDATA[
{
  "startAddress": "192.0.2.0",
  "endAddress": "192.0.2.127",
  ...
  "links": [
    ...,
    {
      "value": "https://example.com/rdap/ip/192.0.2.0/25",
      "rel": "rdap-up",
      "href": ".../rdap/ips/rirSearch1/rdap-up/192.0.2.0/25",
      "type": "application/rdap+json"
    },
    {
      "value": "https://example.com/rdap/ip/192.0.2.0/25",
      "rel": "rdap-down",
      "href": ".../rdap/ips/rirSearch1/rdap-down/192.0.2.0/25",
      "type": "application/rdap+json"
    },
    {
      "value": "https://example.com/rdap/ip/192.0.2.0/25",
      "rel": "rdap-top",
      "href": ".../rdap/ips/rirSearch1/rdap-top/192.0.2.0/25",
      "type": "application/rdap+json"
    },
    {
      "value": "https://example.com/rdap/ip/192.0.2.0/25",
      "rel": "rdap-bottom",
      "href": ".../rdap/ips/rirSearch1/rdap-bottom/192.0.2.0/25",
      "type": "application/rdap+json"
    }
  ]
}
]]></artwork>
}]]></sourcecode>
        </figure>
        <t>

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

        </t>
        <figure anchor="example-links-ipv6">
          <name>Example links Links in an IPv6 response</name>
<artwork align="center" type="ascii-art" name="" alt=""><![CDATA[ Response</name>
          <sourcecode type="json"><![CDATA[
{
  "startAddress": "2001:db8:a::",
  "endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff",
  ...
  "links": [
    ...,
    {
      "value": "https://example.com/rdap/ip/2001:db8:a::/48",
      "rel": "rdap-up",
      "href": ".../rdap/ips/rirSearch1/rdap-up/2001:db8:a::/48",
      "type": "application/rdap+json"
    },
    {
      "value": "https://example.com/rdap/ip/2001:db8:a::/48",
      "rel": "rdap-down",
      "href": ".../rdap/ips/rirSearch1/rdap-down/2001:db8:a::/48",
      "type": "application/rdap+json"
    },
    {
      "value": "https://example.com/rdap/ip/2001:db8:a::/48",
      "rel": "rdap-top",
      "href": ".../rdap/ips/rirSearch1/rdap-top/2001:db8:a::/48",
      "type": "application/rdap+json"
    },
    {
      "value": "https://example.com/rdap/ip/2001:db8:a::/48",
      "rel": "rdap-bottom",
      "href": ".../rdap/ips/rirSearch1/rdap-bottom/2001:db8:a::/48",
      "type": "application/rdap+json"
    }
  ]
}
]]></artwork>
}]]></sourcecode>
        </figure>
        <t>

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

        </t>
        <figure anchor="example-status-links-ipv4">
          <name>Example status links Status Links in an IPv4 response</name>
<artwork align="center" type="ascii-art" name="" alt=""><![CDATA[ Response</name>
          <sourcecode type="json"><![CDATA[
{
  "startAddress": "192.0.2.0",
  "endAddress": "192.0.2.127",
  ...
  "links": [
    ...,
    {
      "value": "https://example.com/rdap/ip/192.0.2.0/25",
      "rel": "rdap-up rdap-active",
      "href":
       ".../rdap/ips/rirSearch1/rdap-up/192.0.2.0/25?status=active",
      "type": "application/rdap+json"
    },
    {
      "value": "https://example.com/rdap/ip/192.0.2.0/25",
      "rel": "rdap-top rdap-active",
      "href":
       ".../rdap/ips/rirSearch1/rdap-top/192.0.2.0/25?status=active",
      "type": "application/rdap+json"
    }
  ]
}
]]></artwork>
}]]></sourcecode>
        </figure>
        <t>

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

        </t>
<!-- [rfced] In Figure 5, two lines are longer than the line limit.
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 characters:
         ".../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 characters:
         ".../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 Status Links in an IPv6 response</name>
<artwork align="center" type="ascii-art" name="" alt=""><![CDATA[ Response</name>
          <sourcecode type="json"><![CDATA[
{
  "startAddress": "2001:db8:a::",
  "endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff",
  ...
  "links": [
    ...,
    {
      "value": "https://example.com/rdap/ip/2001:db8:a::/48",
      "rel": "rdap-up rdap-active",
      "href":
      ".../rdap/ips/rirSearch1/rdap-up/2001:db8:a::/48?status=active",
      "type": "application/rdap+json"
    },
    {
      "value": "https://example.com/rdap/ip/2001:db8:a::/48",
      "rel": "rdap-top rdap-active",
      "href":
      ".../rdap/ips/rirSearch1/rdap-top/2001:db8:a::/48?status=active",
      "type": "application/rdap+json"
    }
  ]
}
]]></artwork>
}]]></sourcecode>
        </figure>
        <t>

                "rdap-active" is used only as a link relation in a
                link object.  It cannot be used as a value for
                &lt;relation&gt; in the relation search URL defined in
                <xref target="relation-search" />. format="default"/>.  <xref target="status" /> format="default"/> details status filtering for
                relation search URLs.

        </t>
        <t>

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

        </t>
        <figure anchor="example-object-links-ipv4">
          <name>Example single-result links Single-Result Links in an IPv4 response</name>
<artwork align="center" type="ascii-art" name="" alt=""><![CDATA[ Response</name>
          <sourcecode type="json"><![CDATA[
{
  "startAddress": "192.0.2.0",
  "endAddress": "192.0.2.127",
  ...
  "links": [
    ...,
    {
      "value": "https://example.com/rdap/ip/192.0.2.0/25",
      "rel": "rdap-up",
      "href": "https://example.com/rdap/ip/192.0.2.0/24",
      "type": "application/rdap+json"
    }
  ]
}
]]></artwork>
}]]></sourcecode>
        </figure>
        <t>

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

        </t>
        <figure anchor="example-object-links-ipv6">
          <name>Example single-result links in an IPv6 response</name>
<artwork align="center" type="ascii-art" name="" alt=""><![CDATA[
          <sourcecode type="json"><![CDATA[
{
  "startAddress": "2001:db8:a::",
  "endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff",
  ...
  "links": [
    ...,
    {
      "value": "https://example.com/rdap/ip/2001:db8:a::/48",
      "rel": "rdap-up",
      "href": "https://example.com/rdap/ip/2001:db8::/32",
      "type": "application/rdap+json"
    }
  ]
}
]]></artwork>
}]]></sourcecode>
        </figure>

            </t>
        <t>

                Use of these link relations in responses is OPTIONAL. <bcp14>OPTIONAL</bcp14>.
<!--[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".

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.

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
                relation does not necessarily mean that the
                corresponding search will return no results.

        </t>
      </section>
    </section>
    <section title="Responding To Searches"> numbered="true" toc="default">
      <name>Responding to Searches</name>
      <section title="Single-Result Searches"> numbered="true" toc="default">
        <name>Single-Result Searches</name>
        <t>

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

        </t>
      </section>
      <section title="Multiple-Result Searches"> numbered="true" toc="default">
        <name>Multiple-Result Searches</name>
        <t>

                The "rdap-down" and "rdap-bottom" relations are
                multiple-result searches.  As with <xref target="RFC9083" />, format="default"/>, responses for these searches take
                the form of an array of object instances, where each
                instance is an appropriate object class for the search
                (i.e., a search beginning with /ips yields an array of
                IP network object instances, and a search beginning
                with /autnums yields an array of autonomous system
                number object instances).  The IP network object class
                is defined in <xref target="RFC9083" sectionFormat="of" section="5.4" />, format="default"/>, and the
                autonomous system number object class is defined in
                <xref target="RFC9083" sectionFormat="of" section="5.5" />. format="default"/>.  The object instance arrays are
                contained within the response object.

        </t>
        <t>
                The names of the arrays are as follows:

                <list>
                    <t>

                        for
        </t>
        <ul spacing="normal">
          <li>for /ips searches, the array is "ipSearchResults"; and

                    </t>

                    <t>

                        for and</li>
          <li>for /autnums searches, the array is "autnumSearchResults".

                    </t>
                </list>

            </t> "autnumSearchResults".</li>
        </ul>
        <t>

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

        </t>
        <figure anchor="ip-network-search-response-ipv4">
          <name>IPv4 network 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</name> 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="drawing"><![CDATA[ type="json"><![CDATA[
{
  "rdapConformance": [ "rdap_level_0", "rirSearch1",
                       "ips", "ipSearchResults", ... ],
  ...
  "ipSearchResults": [
    {
      "objectClassName": "ip network",
      "handle": "XXXX-RIR",
      "startAddress": "192.0.2.0",
      "endAddress": "192.0.2.127",
      ...
    },
    {
      "objectClassName": "ip network",
      "handle": "YYYY-RIR",
      "startAddress": "192.0.2.0",
      "endAddress": "192.0.2.255",
      ...
    }
  ]
}
]]></sourcecode>
        </figure>

            </t>
        <t>

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

        </t>
        <figure anchor="ip-network-search-response-ipv6">
          <name>IPv6 network search response</name> Network Search Response</name>
          <sourcecode type="drawing"><![CDATA[ type="json"><![CDATA[
{
  "rdapConformance": [ "rdap_level_0", "rirSearch1",
                       "ips", "ipSearchResults", ... ],
  ...
  "ipSearchResults": [
    {
      "objectClassName": "ip network",
      "handle": "XXXX-RIR",
      "startAddress": "2001:db8:a::",
      "endAddress": "2001:db8:a:ffff:ffff:ffff:ffff:ffff",
      ...
    },
    {
      "objectClassName": "ip network",
      "handle": "YYYY-RIR",
      "startAddress": "2001:db8::",
      "endAddress": "2001:db8:ffff:ffff:ffff:ffff:ffff:ffff",
      ...
    }
  ]
}
]]></sourcecode>
        </figure>

            </t>
        <t>

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

        </t>
        <figure anchor="asn-search-response">
          <name>ASN search response</name> Search Response</name>
          <sourcecode type="drawing"><![CDATA[ type="json"><![CDATA[
{
  "rdapConformance": [ "rdap_level_0", "rirSearch1",
                       "autnums", "autnumSearchResults", ... ],
  ...
  "autnumSearchResults": [
    {
      "objectClassName": "autnum",
      "handle": "XXXX-RIR",
      "startAutnum": 64496,
      "endAutnum": 64496,
      ...
    },
    {
      "objectClassName": "autnum",
      "handle": "YYYY-RIR",
      "startAutnum": "64497",
      "endAutnum": "64497",
      ...
    }
  ]
}
]]></sourcecode>
        </figure>

            </t>
        <t>

                Responses for relation searches for reverse domain objects
                have the same form as for a standard domain search
                response, per <xref target="RFC9083" />. format="default"/>.

        </t>
        <t>

                If the search can be processed by the server, but
                there are no results for the search, then the server
                returns an HTTP 404 (Not Found) <xref target="RFC9110"
                /> format="default"/> response code, with the body of the response
                containing an empty results array.

        </t>
      </section>
    </section>
    <section title="Reverse Search"> numbered="true" toc="default">
      <name>Reverse Search</name>
      <t>

            RDAP reverse search is defined by <xref target="RFC9536"
            />. format="default"/>.  That document limits reverse search to domains,
            nameservers, and entities.  This document extends reverse
            search to cover IP networks and autonomous system numbers
            as well.

      </t>
      <t>

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

      </t>
      <t>

            Additionally, <xref target="IANA" /> includes requests to
            register format="default"/> notes that
            new entries registrations for IP network and autonomous system
            number searches have been made in the RDAP "RDAP Reverse Search Search" and RDAP "RDAP
            Reverse Search Mapping Mapping" IANA registries.

      </t>
    </section>
    <section title="RDAP Conformance"> numbered="true" toc="default">
      <name>RDAP Conformance</name>
      <t>

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

      </t>
      <ul>
        <li>any response that includes an IP network basic
                search link, an IP network relation search link, or an IP
                network reverse search link includes the "rirSearch1"
                and "ips" literals;</li>
        <li>any response for an IP network basic search
                request, an IP network relation search request, or an
                IP network reverse search request includes the
                "rirSearch1", "ips", and "ipSearchResults"
                literals;</li>
        <li>any response that includes an ASN basic search
                link, an ASN relation search link, or an ASN reverse
                search link includes the "rirSearch1" and "autnums"
                literals;</li>
        <li>any response for an ASN basic search request, an
                ASN relation search request, or an ASN reverse search
                request includes the "rirSearch1", "autnums", and
                "autnumSearchResults" literals;</li>
        <li>any response that includes a domain relation search
                link includes the "rirSearch1" literal;</li>
        <li>any response for a domain relation search request
                includes the "rirSearch1" literal; and</li>
        <li>a response to a "/help" request includes the
                "rirSearch1", "ips", "ipSearchResults", "autnums", and
                "autnumSearchResults" literals.</li>
      </ul>
      <t>
            Although responses will generally not include all of the
            rdapConformance string literals defined in this document,
            that is not meant to imply that a server can support only
            a portion of the functionality defined in this document.

      </t>
      <t>

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

      </t>
      <t>

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

      </t>
      <t>

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

      </t>
    </section>
    <section title="Operational Considerations"> 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.

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

      </t>
      <t>

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

      </t>
    </section>
    <section title="Privacy Considerations"> numbered="true" toc="default">
      <name>Privacy Considerations</name>
      <t>

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

      </t>
      <t>

            Many jurisdictions have laws or regulations that restrict
            the use of "Personal Data", per the definition in <xref target="RFC6973" />. format="default"/>.  Given that, server operators should
            ascertain whether the regulatory environment in which they
            operate permits implementation of the functionality
            defined in this document.

      </t>
    </section>
    <section title="Security Considerations"> numbered="true" toc="default">
      <name>Security Considerations</name>
      <t>

            <xref target="RFC7481" /> format="default"/> describes security requirements
            and considerations for RDAP generally.  Additionally,
            guidance as to the use of TLS has changed since that
            document was published: see <xref target="RFC8446" /> format="default"/> and
            <xref target="BCP195" /> format="default"/> for further detail.

      </t>
      <t>

            <xref target="RFC9082" /> format="default"/> includes security considerations
            relating to object retrieval in RDAP.  Those
            considerations are relevant here as well.

      </t>
    </section>
    <section anchor="IANA" title="IANA Considerations"> numbered="true" toc="default">
      <name>IANA Considerations</name>
      <section title="RDAP numbered="true" toc="default">
        <name>RDAP Extensions Registry"> Registry</name>
        <t>

                IANA is requested to register has registered the following values in
                the <eref
                target="https://www.iana.org/assignments/rdap-extensions/rdap-extensions.xhtml">RDAP
                Extensions Registry</eref>. brackets="angle" target="https://www.iana.org/assignments/rdap-extensions">"RDAP
                Extensions" registry</eref>.

        </t>
        <section title="rirSearch1">
                <list style="hanging" numbered="true" toc="default">
          <name>rirSearch1</name>
          <dl newline="false" 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
            <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 operations.</t>
                </list> operations.</dd>
          </dl>
        </section>
        <section title="ips">
                <list style="hanging" numbered="true" toc="default">
          <name>ips</name>
          <dl newline="false" 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
            <dt>Extension Identifier:</dt>
            <dd>ips</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 operations.</t>
                </list> operations.</dd>
          </dl>
        </section>
        <section title="autnums">
                <list style="hanging" numbered="true" toc="default">
          <name>autnums</name>
          <dl newline="false" 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
            <dt>Extension Identifier:</dt>
            <dd>autnums</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 operations.</t>
                </list> operations.</dd>
          </dl>
        </section>
        <section title="ipSearchResults">
                <list style="hanging" numbered="true" toc="default">
          <name>ipSearchResults</name>
          <dl newline="false" 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
            <dt>Extension Identifier:</dt>
            <dd>ipSearchResults</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 operations.</t>
                </list> operations.</dd>
          </dl>
        </section>
        <section title="autnumSearchResults">
                <list style="hanging" numbered="true" toc="default">
          <name>autnumSearchResults</name>
          <dl newline="false" 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
            <dt>Extension Identifier:</dt>
            <dd>autnumSearchResults</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 operations.</t>
                </list> operations.</dd>
          </dl>
        </section>
      </section>
      <section title="Link numbered="true" toc="default">
        <name>Link Relations Registry"> Registry</name>
        <t>

                IANA is requested to register has registered the following values in
                the <eref
                target="https://www.iana.org/assignments/link-relations/link-relations.xhtml">Link
                Relations Registry</eref>. brackets="angle" target="https://www.iana.org/assignments/link-relations">"Link
                Relations" registry</eref>.

        </t>
        <section title="rdap-up">
                <list style="hanging" numbered="true" toc="default">
          <name>rdap-up</name>
          <dl newline="false" spacing="compact">
                    <t hangText="Relation Name:">rdap-up</t>
                    <t hangText="Description:">Refers
            <dt>Relation Name:</dt>
            <dd>rdap-up</dd>
            <dt>Description:</dt>
            <dd>Refers to an RDAP parent object in a hierarchy of objects.</t>
                    <t hangText="Reference:">[this document]</t>
                </list> objects.</dd>
            <dt>Reference:</dt>
            <dd>RFC 9910</dd>
          </dl>
        </section>
        <section title="rdap-down">
                <list style="hanging" numbered="true" toc="default">
          <name>rdap-down</name>
          <dl newline="false" spacing="compact">
                    <t hangText="Relation Name:">rdap-down</t>
                    <t hangText="Description:">Refers
            <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.</t>
                    <t hangText="Reference:">[this document]</t>
                </list> objects.</dd>
            <dt>Reference:</dt>
            <dd>RFC 9910</dd>
          </dl>
        </section>
        <section title="rdap-top">
                <list style="hanging" numbered="true" toc="default">
          <name>rdap-top</name>
          <dl newline="false" spacing="compact">
                    <t hangText="Relation Name:">rdap-top</t>
                    <t hangText="Description:">Refers
            <dt>Relation Name:</dt>
            <dd>rdap-top</dd>
            <dt>Description:</dt>
            <dd>Refers to the topmost RDAP parent object in a hierarchy of objects.</t>
                    <t hangText="Reference:">[this document]</t>
                </list> objects.</dd>
            <dt>Reference:</dt>
            <dd>RFC 9910</dd>
          </dl>
        </section>
        <section title="rdap-bottom">
                <list style="hanging" numbered="true" toc="default">
          <name>rdap-bottom</name>
          <dl newline="false" spacing="compact">
                    <t hangText="Relation Name:">rdap-bottom</t>
                    <t hangText="Description:">Refers
            <dt>Relation Name:</dt>
            <dd>rdap-bottom</dd>
            <dt>Description:</dt>
            <dd>Refers to the set of child RDAP objects that do not themselves have child objects, in a hierarchy of objects.</t>
                    <t hangText="Reference:">[this document]</t>
                </list> objects.</dd>
            <dt>Reference:</dt>
            <dd>RFC 9910</dd>
          </dl>
        </section>
        <section title="rdap-active">
                <list style="hanging" numbered="true" toc="default">
          <name>rdap-active</name>
          <dl newline="false" spacing="compact">
                    <t hangText="Relation Name:">rdap-active</t>
                    <t hangText="Description:">The
            <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".</t>
                    <t hangText="Reference:">[this document]</t>
                </list> "active".</dd>
            <dt>Reference:</dt>
            <dd>RFC 9910</dd>
          </dl>
        </section>
      </section>
      <section title="RDAP numbered="true" toc="default">
        <name>RDAP Reverse Search Registry"> Registry</name>
        <t>

                IANA is requested to register has registered the following entries in
                the <eref
                target="https://www.iana.org/assignments/rdap-reverse-search/rdap-reverse-search.xhtml">RDAP brackets="angle" target="https://www.iana.org/assignments/rdap-reverse-search/">"RDAP
                Reverse Search</eref> Search"</eref> registry.

        </t>
        <section title="fn">
                <list style="hanging" numbered="true" toc="default">
          <name>fn</name>
          <dl newline="false" spacing="compact">
                    <t hangText="Property:">fn</t>
                    <t hangText="Description:">The
            <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 (a.k.a. formatted name) of an associated entity.</t>
                    <t hangText="Searchable entity.</dd>
            <dt>Searchable Resource Type:">ips, autnums</t>
                    <t hangText="Related Type:</dt>
            <dd>ips, autnums</dd>
            <dt>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> 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 title="handle">
                <list style="hanging" numbered="true" toc="default">
          <name>handle</name>
          <dl newline="false" spacing="compact">
                    <t hangText="Property:">handle</t>
                    <t hangText="Description:">The
            <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.</t>
                    <t hangText="Searchable entity.</dd>
            <dt>Searchable Resource Type:">ips, autnums</t>
                    <t hangText="Related Type:</dt>
            <dd>ips, autnums</dd>
            <dt>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> 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 title="email">
                <list style="hanging" numbered="true" toc="default">
          <name>email</name>
          <dl newline="false" spacing="compact">
                    <t hangText="Property:">email</t>
                    <t hangText="Description:">The
            <dt>Property:</dt>
            <dd>email</dd>
            <dt>Description:</dt>
            <dd>The server supports the IP/autnum search based on the email address of an associated entity.</t>
                    <t hangText="Searchable entity.</dd>
            <dt>Searchable Resource Type:">ips, autnums</t>
                    <t hangText="Related Type:</dt>
            <dd>ips, autnums</dd>
            <dt>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> 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 title="role">
                <list style="hanging" numbered="true" toc="default">
          <name>role</name>
          <dl newline="false" spacing="compact">
                    <t hangText="Property:">role</t>
                    <t hangText="Description:">The
            <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.</t>
                    <t hangText="Searchable entity.</dd>
            <dt>Searchable Resource Type:">ips, autnums</t>
                    <t hangText="Related Type:</dt>
            <dd>ips, autnums</dd>
            <dt>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> 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 title="RDAP numbered="true" toc="default">
        <name>RDAP Reverse Search Mapping Registry"> Registry</name>
        <t>

                IANA is requested to register has registered the following entries
                in the <eref
                target="https://www.iana.org/assignments/rdap-reverse-search-mapping/rdap-reverse-search-mapping.xhtml">RDAP brackets="angle" target="https://www.iana.org/assignments/rdap-reverse-search-mapping">"RDAP
                Reverse Search Mapping</eref> Mapping"</eref> registry.

        </t>
        <section title="fn">
                <list style="hanging" numbered="true" toc="default">
          <name>fn</name>
          <dl newline="false" spacing="compact">
                    <t hangText="Property:">fn</t>
                    <t hangText="Property Path:">$.entities[*].vcardArray[1][?(@[0]=='fn')][3]</t>
                    <t hangText="Searchable
            <dt>Property:</dt>
            <dd>fn</dd>
            <dt>Property Path:</dt>
            <dd>$.entities[*].vcardArray[1][?(@[0]=='fn')][3]</dd>
            <dt>Searchable Resource Type:">ips, autnums</t>
                    <t hangText="Related Type:</dt>
            <dd>ips, autnums</dd>
            <dt>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> 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 title="handle">
                <list style="hanging" numbered="true" toc="default">
          <name>handle</name>
          <dl newline="false" spacing="compact">
                    <t hangText="Property:">handle</t>
                    <t hangText="Property Path:">$.entities[*].handle</t>
                    <t hangText="Searchable
            <dt>Property:</dt>
            <dd>handle</dd>
            <dt>Property Path:</dt>
            <dd>$.entities[*].handle</dd>
            <dt>Searchable Resource Type:">ips, autnums</t>
                    <t hangText="Related Type:</dt>
            <dd>ips, autnums</dd>
            <dt>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> 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 title="email">
                <list style="hanging" numbered="true" toc="default">
          <name>email</name>
          <dl newline="false" spacing="compact">
                    <t hangText="Property:">email</t>
                    <t hangText="Property Path:">$.entities[*].vcardArray[1][?(@[0]=='email')][3]</t>
                    <t hangText="Searchable
            <dt>Property:</dt>
            <dd>email</dd>
            <dt>Property Path:</dt>
            <dd>$.entities[*].vcardArray[1][?(@[0]=='email')][3]</dd>
            <dt>Searchable Resource Type:">ips, autnums</t>
                    <t hangText="Related Type:</dt>
            <dd>ips, autnums</dd>
            <dt>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> 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 title="role">
                <list style="hanging" numbered="true" toc="default">
          <name>role</name>
          <dl newline="false" spacing="compact">
                    <t hangText="Property:">role</t>
                    <t hangText="Property Path:">$.entities[*].roles</t>
                    <t hangText="Searchable
            <dt>Property:</dt>
            <dd>role</dd>
            <dt>Property Path:</dt>
            <dd>$.entities[*].roles</dd>
            <dt>Searchable Resource Type:">ips, autnums</t>
                    <t hangText="Related Type:</dt>
            <dd>ips, autnums</dd>
            <dt>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> 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 anchor="implementation-status">
      <name>Implementation Status</name>

      <aside>
        <t>Note

  </middle>
  <back>
    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9110.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7481.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8446.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9082.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9083.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9536.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.3912.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.6973.xml"/>
        <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7480.xml"/>
      </references>
    </references>

<!-- [rfced] FYI, we updated "Whois" to "WHOIS" (2 instances) to
match the cited RFC Editor - remove this section before publication, [RFC3912] - 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 usage 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. STD 95. Please note that
let us know if you prefer otherwise.
-->

<!-- [rfced] Please review the listing "Inclusive Language" portion 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 online
Style Guide <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>
and let us know if any changes are advised to note that other implementations may
exist.</t>

      <t>According to <xref target="RFC7942"/>, "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of
running code, which may serve as evidence needed.  Updates 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 Implementation">
        <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-search<vspace blankLines='1' /></t>
          <t>Description: This implementation includes support for the various searches and responses described nature typically
result in this document.<vspace blankLines='1' /></t>
          <t>Level of Maturity: This more precise language, which is a proof-of-concept implementation.<vspace blankLines='1' /></t>
          <t>Coverage: This implementation includes all of the features described in this
          specification.<vspace blankLines='1' /></t>
          <t>Contact Information: Tom Harrison, tomh@apnic.net</t>
        </list></t>
      </section>

      <section anchor="ripe-ncc-rdap-implementation" title="RIPE NCC RDAP Implementation">
        <t><list style="none" spacing="compact">
          <t>Responsible Organization: RIPE NCC<vspace blankLines='1' /></t>
          <t>Location: https://github.com/RIPE-NCC/whois<vspace blankLines='1' /></t>
          <t>Description: This implementation includes support helpful for several of the searches and responses as at version 14 of this document.<vspace blankLines='1' /></t>
          <t>Level of Maturity: This is a production implementation.<vspace blankLines='1' /></t>
          <t>Coverage: This implementation includes IP and domain relation searches, as well as readers.

For example, please consider whether the links that correspond to those searches.<vspace blankLines='1' /></t>
          <t>Contact Information: Ed Shryane, eshryane@ripe.net</t>
        </list></t>
      </section>

    </section> following should be updated:
  whitespace
-->

    <section anchor="Acknowledgements" title="Acknowledgements">
        <t>

            The numbered="false" toc="default">
      <name>Acknowledgements</name>
      <t>The authors wish to thank Mario Loffredo, Andy Newton,
            Antoin Verschuren, James Gould, Scott Hollenbeck, Orie
            Steele, Russ Housley, John Levine, Stewart Bryant, Mark
            Nottingham, Mohamed Boucadair, Deb Cooley, Éric Vyncke,
            and Roman Danyliw <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> comments.</t>
    </section>

  </middle>

  <back>
    <references title="Normative References">
      &RFC2119;
      &RFC9110;
      &RFC7481;
      &RFC8446;
      &RFC9082;
      &RFC9083;
      &RFC8174;
      &RFC9536;
      &BCP195;
    </references>

    <references title="Informative References">
      &RFC3912;
      &RFC6973;
      &RFC7480;
      &RFC7942;
    </references>

  </back>
</rfc>