rfc9082.original.xml   rfc9082.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version='1.0' encoding='utf-8'?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [ <rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" category="std" conse
<!ENTITY RFC0952 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF nsus="true" docName="draft-ietf-regext-rfc7482bis-03" indexInclude="true" ipr="t
C.0952.xml"> rust200902" number="9082" obsoletes="7482" prepTime="2021-06-11T16:29:02" script
<!ENTITY RFC1035 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF s="Common,Latin" sortRefs="true" submissionType="IETF" symRefs="true" tocDepth="
C.1035.xml"> 3" tocInclude="true" xml:lang="en">
<!ENTITY RFC1123 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <link href="https://datatracker.ietf.org/doc/draft-ietf-regext-rfc7482bis-03"
C.1123.xml"> rel="prev"/>
<!ENTITY RFC1166 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <link href="https://dx.doi.org/10.17487/rfc9082" rel="alternate"/>
C.1166.xml"> <link href="urn:issn:2070-1721" rel="alternate"/>
<!ENTITY RFC2119 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <front>
C.2119.xml"> <title abbrev="RDAP Query Format">Registration Data Access Protocol (RDAP) Q
<!ENTITY RFC3986 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF uery Format</title>
C.3986.xml"> <seriesInfo name="RFC" value="9082" stream="IETF"/>
<!ENTITY RFC4291 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <seriesInfo name="STD" value="95" stream="IETF"/>
C.4291.xml"> <author fullname="Scott Hollenbeck" initials="S." surname="Hollenbeck">
<!ENTITY RFC4632 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <organization showOnFrontPage="true">Verisign Labs</organization>
C.4632.xml"> <address>
<!ENTITY RFC4918 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <postal>
C.4918.xml"> <street>12061 Bluemont Way</street>
<!ENTITY RFC5396 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <city>Reston</city>
C.5396.xml"> <region>VA</region>
<!ENTITY RFC5730 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <code>20190</code>
C.5730.xml"> <country>United States of America</country>
<!ENTITY RFC5733 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF </postal>
C.5733.xml"> <email>shollenbeck@verisign.com</email>
<!ENTITY RFC5890 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <uri>https://www.verisignlabs.com/</uri>
C.5890.xml"> </address>
<!ENTITY RFC5891 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF </author>
C.5891.xml"> <author fullname="Andy Newton" initials="A." surname="Newton">
<!ENTITY RFC5952 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <organization abbrev="AWS" showOnFrontPage="true">Amazon Web Services, Inc
C.5952.xml"> .</organization>
<!ENTITY RFC7230 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <address>
C.7230.xml"> <postal>
<!ENTITY RFC7231 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <street>13200 Woodland Park Road</street>
C.7231.xml"> <city>Herndon</city>
<!ENTITY RFC7480 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <region>VA</region>
C.7480.xml"> <code>20171</code>
<!ENTITY RFC7481 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <country>United States of America</country>
C.7481.xml"> </postal>
<!ENTITY RFC7484 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <email>andy@hxr.us</email>
C.7484.xml"> </address>
<!ENTITY RFC3912 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF </author>
C.3912.xml"> <date month="06" year="2021"/>
<!ENTITY RFC4007 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <area>Applications and Real-Time</area>
C.4007.xml"> <workgroup>REGEXT Working Group</workgroup>
<!ENTITY RFC4290 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF <abstract pn="section-abstract">
C.4290.xml"> <t indent="0" pn="section-abstract-1">
<!ENTITY RFC6874 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6874.xml">
<!ENTITY RFC6927 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.6927.xml">
<!ENTITY RFC7942 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.7942.xml">
<!ENTITY RFC8174 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8174.xml">
<!ENTITY RFC8499 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8499.xml">
<!ENTITY RFC8521 SYSTEM "https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RF
C.8521.xml">
<!ENTITY I-D.ietf-regext-rfc7483bis SYSTEM 'https://xml2rfc.tools.ietf.org/publi
c/rfc/bibxml3/reference.I-D.ietf-regext-rfc7483bis.xml'>
]>
<rfc category="std" docName="draft-ietf-regext-rfc7482bis-03" ipr="trust200902"
obsoletes="7482">
<!-- Generated by id2xml 1.5.0 on 2019-09-17T15:17:01Z -->
<?rfc compact="yes"?>
<?rfc text-list-symbols="o*+-"?>
<?rfc subcompact="no"?>
<?rfc sortrefs="no"?>
<?rfc symrefs="yes"?>
<?rfc strict="yes"?>
<?rfc toc="yes"?>
<front>
<title abbrev="RDAP Query Format">Registration Data Access Protocol (RDAP
) Query Format</title>
<author fullname="Scott Hollenbeck" initials="S." surname="Hollenbeck">
<organization>Verisign Labs</organization>
<address><postal><street>12061 Bluemont Way</street>
<city>Reston</city>
<region>VA</region>
<code>20190</code>
<country>United States of America</country>
</postal>
<email>shollenbeck@verisign.com</email>
<uri>https://www.verisignlabs.com/</uri>
</address>
</author>
<author fullname="Andy Newton" initials="A." surname="Newton">
<organization abbrev="AWS">Amazon Web Services, Inc.</organization>
<address><postal><street>13200 Woodland Park Road</street>
<city>Herndon</city>
<region>VA</region>
<code>20171</code>
<country>United States of America</country>
</postal>
<email>andy@hxr.us</email>
</address>
</author>
<date/>
<area>Applications and Real-Time</area>
<workgroup>REGEXT Working Group</workgroup>
<abstract><t>
This document describes uniform patterns to construct HTTP URLs that This document describes uniform patterns to construct HTTP URLs that
may be used to retrieve registration information from registries may be used to retrieve registration information from registries
(including both Regional Internet Registries (RIRs) and Domain Name (including both Regional Internet Registries (RIRs) and Domain Name
Registries (DNRs)) using "RESTful" web access patterns. These Registries (DNRs)) using "RESTful" web access patterns. These
uniform patterns define the query syntax for the Registration Data uniform patterns define the query syntax for the Registration Data
Access Protocol (RDAP). If approved, this document obsoletes RFC 7482.</t> Access Protocol (RDAP). This document obsoletes RFC 7482.</t>
</abstract> </abstract>
</front> <boilerplate>
<section anchor="status-of-memo" numbered="false" removeInRFC="false" toc=
<middle> "exclude" pn="section-boilerplate.1">
<section title="Introduction" anchor="sect-1"><t> <name slugifiedName="name-status-of-this-memo">Status of This Memo</name
>
<t indent="0" pn="section-boilerplate.1-1">
This is an Internet Standards Track document.
</t>
<t indent="0" pn="section-boilerplate.1-2">
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
</t>
<t indent="0" pn="section-boilerplate.1-3">
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
<eref target="https://www.rfc-editor.org/info/rfc9082" brackets="non
e"/>.
</t>
</section>
<section anchor="copyright" numbered="false" removeInRFC="false" toc="excl
ude" pn="section-boilerplate.2">
<name slugifiedName="name-copyright-notice">Copyright Notice</name>
<t indent="0" pn="section-boilerplate.2-1">
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
</t>
<t indent="0" pn="section-boilerplate.2-2">
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(<eref target="https://trustee.ietf.org/license-info" brackets="none
"/>) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
</t>
</section>
</boilerplate>
<toc>
<section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" p
n="section-toc.1">
<name slugifiedName="name-table-of-contents">Table of Contents</name>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="section-to
c.1-1">
<li pn="section-toc.1-1.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref der
ivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-introduction">
Introduction</xref></t>
</li>
<li pn="section-toc.1-1.2">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref der
ivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-conventions-us
ed-in-this-do">Conventions Used in This Document</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.2.2">
<li pn="section-toc.1-1.2.2.1">
<t indent="0" keepWithNext="true" pn="section-toc.1-1.2.2.1.1"><
xref derivedContent="2.1" format="counter" sectionFormat="of" target="section-2.
1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-ac
ronyms-and-abbreviations">Acronyms and Abbreviations</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3">
<t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" form
at="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-path-segment-specification">Path S
egment Specification</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.3.2">
<li pn="section-toc.1-1.3.2.1">
<t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent=
"3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-lookup-path-segment-sp
ecifi">Lookup Path Segment Specification</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.3.2.1.2">
<li pn="section-toc.1-1.3.2.1.2.1">
<t indent="0" pn="section-toc.1-1.3.2.1.2.1.1"><xref derived
Content="3.1.1" format="counter" sectionFormat="of" target="section-3.1.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-ip-network
-path-segment-spe">IP Network Path Segment Specification</xref></t>
</li>
<li pn="section-toc.1-1.3.2.1.2.2">
<t indent="0" pn="section-toc.1-1.3.2.1.2.2.1"><xref derived
Content="3.1.2" format="counter" sectionFormat="of" target="section-3.1.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-autonomous
-system-path-segm">Autonomous System Path Segment Specification</xref></t>
</li>
<li pn="section-toc.1-1.3.2.1.2.3">
<t indent="0" pn="section-toc.1-1.3.2.1.2.3.1"><xref derived
Content="3.1.3" format="counter" sectionFormat="of" target="section-3.1.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-domain-pat
h-segment-specifi">Domain Path Segment Specification</xref></t>
</li>
<li pn="section-toc.1-1.3.2.1.2.4">
<t indent="0" pn="section-toc.1-1.3.2.1.2.4.1"><xref derived
Content="3.1.4" format="counter" sectionFormat="of" target="section-3.1.4"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-nameserver
-path-segment-spe">Nameserver Path Segment Specification</xref></t>
</li>
<li pn="section-toc.1-1.3.2.1.2.5">
<t indent="0" pn="section-toc.1-1.3.2.1.2.5.1"><xref derived
Content="3.1.5" format="counter" sectionFormat="of" target="section-3.1.5"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-entity-pat
h-segment-specifi">Entity Path Segment Specification</xref></t>
</li>
<li pn="section-toc.1-1.3.2.1.2.6">
<t indent="0" pn="section-toc.1-1.3.2.1.2.6.1"><xref derived
Content="3.1.6" format="counter" sectionFormat="of" target="section-3.1.6"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-help-path-
segment-specifica">Help Path Segment Specification</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.3.2.2">
<t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent=
"3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-search-path-segment-sp
ecifi">Search Path Segment Specification</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="se
ction-toc.1-1.3.2.2.2">
<li pn="section-toc.1-1.3.2.2.2.1">
<t indent="0" pn="section-toc.1-1.3.2.2.2.1.1"><xref derived
Content="3.2.1" format="counter" sectionFormat="of" target="section-3.2.1"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-domain-sea
rch">Domain Search</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.2">
<t indent="0" pn="section-toc.1-1.3.2.2.2.2.1"><xref derived
Content="3.2.2" format="counter" sectionFormat="of" target="section-3.2.2"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-nameserver
-search">Nameserver Search</xref></t>
</li>
<li pn="section-toc.1-1.3.2.2.2.3">
<t indent="0" pn="section-toc.1-1.3.2.2.2.3.1"><xref derived
Content="3.2.3" format="counter" sectionFormat="of" target="section-3.2.3"/>.  <
xref derivedContent="" format="title" sectionFormat="of" target="name-entity-sea
rch">Entity Search</xref></t>
</li>
</ul>
</li>
</ul>
</li>
<li pn="section-toc.1-1.4">
<t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" form
at="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-query-processing">Query Processing
</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.4.2">
<li pn="section-toc.1-1.4.2.1">
<t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent=
"4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-partial-string-searchi
ng">Partial String Searching</xref></t>
</li>
<li pn="section-toc.1-1.4.2.2">
<t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent=
"4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-associated-records">As
sociated Records</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.5">
<t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" form
at="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-extensibility">Extensibility</xref
></t>
</li>
<li pn="section-toc.1-1.6">
<t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" form
at="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-internationalization-consid">Inter
nationalization Considerations</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.6.2">
<li pn="section-toc.1-1.6.2.1">
<t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent=
"6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-character-encoding-con
sider">Character Encoding Considerations</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.7">
<t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" form
at="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-iana-considerations">IANA Consider
ations</xref></t>
</li>
<li pn="section-toc.1-1.8">
<t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" form
at="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-security-considerations">Security
Considerations</xref></t>
</li>
<li pn="section-toc.1-1.9">
<t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" form
at="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" f
ormat="title" sectionFormat="of" target="name-references">References</xref></t>
<ul bare="true" empty="true" indent="2" spacing="compact" pn="sectio
n-toc.1-1.9.2">
<li pn="section-toc.1-1.9.2.1">
<t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent=
"9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-normative-references">
Normative References</xref></t>
</li>
<li pn="section-toc.1-1.9.2.2">
<t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent=
"9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derived
Content="" format="title" sectionFormat="of" target="name-informative-references
">Informative References</xref></t>
</li>
</ul>
</li>
<li pn="section-toc.1-1.10">
<t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="Append
ix A" format="default" sectionFormat="of" target="section-appendix.a"/>.  <xref
derivedContent="" format="title" sectionFormat="of" target="name-changes-from-rf
c-7482">Changes from RFC 7482</xref></t>
</li>
<li pn="section-toc.1-1.11">
<t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-acknowledgments">Acknowledgment
s</xref></t>
</li>
<li pn="section-toc.1-1.12">
<t indent="0" pn="section-toc.1-1.12.1"><xref derivedContent="" form
at="none" sectionFormat="of" target="section-appendix.c"/><xref derivedContent="
" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Add
resses</xref></t>
</li>
</ul>
</section>
</toc>
</front>
<middle>
<section anchor="sect-1" numbered="true" toc="include" removeInRFC="false" p
n="section-1">
<name slugifiedName="name-introduction">Introduction</name>
<t indent="0" pn="section-1-1">
This document describes a specification for querying registration This document describes a specification for querying registration
data using a RESTful web service and uniform query patterns. The data using a RESTful web service and uniform query patterns. The
service is implemented using the Hypertext Transfer Protocol (HTTP) service is implemented using the Hypertext Transfer Protocol (HTTP)
<xref target="RFC7230"/> and the conventions described in <xref target="RFC74 80"/>. These uniform <xref target="RFC7230" format="default" sectionFormat="of" derivedContent="RF C7230"/> and the conventions described in <xref target="RFC7480" format="default " sectionFormat="of" derivedContent="RFC7480"/>. These uniform
patterns define the query syntax for the Registration Data Access patterns define the query syntax for the Registration Data Access
Protocol (RDAP). If approved, this document obsoletes RFC 7482.</t> Protocol (RDAP). This document obsoletes RFC 7482.</t>
<t indent="0" pn="section-1-2">
<t>
The protocol described in this specification is intended to address The protocol described in this specification is intended to address
deficiencies with the WHOIS protocol <xref target="RFC3912"/> that have been deficiencies with the WHOIS protocol <xref target="RFC3912" format="default" sectionFormat="of" derivedContent="RFC3912"/> that have been
identified over time, including:</t> identified over time, including:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-3
<t><list style="symbols"><t>lack of standardized command structures;</t> ">
<li pn="section-1-3.1">lack of standardized command structures;</li>
<t>lack of standardized output and error structures;</t> <li pn="section-1-3.2">lack of standardized output and error structures;
</li>
<t>lack of support for internationalization and localization; and</t> <li pn="section-1-3.3">lack of support for internationalization and loca
lization; and</li>
<t>lack of support for user identification, authentication, and <li pn="section-1-3.4">lack of support for user identification, authenti
access control.</t> cation, and
access control.</li>
</list> </ul>
</t> <t indent="0" pn="section-1-4">
<t>
The patterns described in this document purposefully do not encompass The patterns described in this document purposefully do not encompass
all of the methods employed in the WHOIS and other RESTful web all of the methods employed in the WHOIS and other RESTful web
services used by the RIRs and DNRs. The intent of the patterns services used by the RIRs and DNRs. The intent of the patterns
described here is to enable queries of:</t> described here is to enable queries of:</t>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-1-5
<t><list style="symbols"><t>networks by IP address;</t> ">
<li pn="section-1-5.1">networks by IP address;</li>
<t>Autonomous System (AS) numbers by number;</t> <li pn="section-1-5.2">Autonomous System (AS) numbers by number;</li>
<li pn="section-1-5.3">reverse DNS metadata by domain;</li>
<t>reverse DNS metadata by domain;</t> <li pn="section-1-5.4">nameservers by name; and</li>
<li pn="section-1-5.5">entities (such as registrars and contacts) by ide
<t>nameservers by name; and</t> ntifier.</li>
</ul>
<t>entities (such as registrars and contacts) by identifier.</t> <t indent="0" pn="section-1-6">
</list>
</t>
<t>
Server implementations are free to support only a subset of these Server implementations are free to support only a subset of these
features depending on local requirements. Servers MUST return an features depending on local requirements. Servers <bcp14>MUST</bcp14> return
HTTP 501 (Not Implemented) <xref target="RFC7231"/> response to inform client an
s of HTTP 501 (Not Implemented) <xref target="RFC7231" format="default" sectionFor
mat="of" derivedContent="RFC7231"/> response to inform clients of
unsupported query types. It is also envisioned that each registry unsupported query types. It is also envisioned that each registry
will continue to maintain WHOIS and/or other RESTful web services will continue to maintain WHOIS and/or other RESTful web services
specific to their needs and those of their constituencies, and the specific to their needs and those of their constituencies, and the
information retrieved through the patterns described here may information retrieved through the patterns described here may
reference such services.</t> reference such services.</t>
<t indent="0" pn="section-1-7">
<t>
Likewise, future IETF specifications may add additional patterns for Likewise, future IETF specifications may add additional patterns for
additional query types. A simple pattern namespacing scheme is additional query types. A simple pattern namespacing scheme is
described in <xref target="sect-5"/> to accommodate custom extensions that wi ll not described in <xref target="sect-5" format="default" sectionFormat="of" derive dContent="Section 5"/> to accommodate custom extensions that will not
interfere with the patterns defined in this document or patterns interfere with the patterns defined in this document or patterns
defined in future IETF specifications.</t> defined in future IETF specifications.</t>
<t indent="0" pn="section-1-8">
<t>
WHOIS services, in general, are read-only services. Accordingly, URL WHOIS services, in general, are read-only services. Accordingly, URL
<xref target="RFC3986"/> patterns specified in this document are only applica <xref target="RFC3986" format="default" sectionFormat="of" derivedContent="RF
ble to C3986"/> patterns specified in this document are only applicable to
the HTTP <xref target="RFC7231"/> GET and HEAD methods.</t> the HTTP <xref target="RFC7231" format="default" sectionFormat="of" derivedCo
ntent="RFC7231"/> GET and HEAD methods.</t>
<t> <t indent="0" pn="section-1-9">
This document does not describe the results or entities returned from This document does not describe the results or entities returned from
issuing the described URLs with an HTTP GET. The specification of issuing the described URLs with an HTTP GET. The specification of
these entities is described in <xref target="I-D.ietf-regext-rfc7483bis"/>.</ these entities is described in <xref target="RFC9083" format="default" sectio
t> nFormat="of" derivedContent="RFC9083"/>.</t>
<t indent="0" pn="section-1-10">
<t>
Additionally, resource management, provisioning, and update functions Additionally, resource management, provisioning, and update functions
are out of scope for this document. Registries have various and are out of scope for this document. Registries have various and
divergent methods covering these functions, and it is unlikely a divergent methods covering these functions, and it is unlikely a
uniform approach is needed for interoperability.</t> uniform approach is needed for interoperability.</t>
<t indent="0" pn="section-1-11">
<t>
HTTP contains mechanisms for servers to authenticate clients and for HTTP contains mechanisms for servers to authenticate clients and for
clients to authenticate servers (from which authorization schemes may clients to authenticate servers (from which authorization schemes may
be built), so such mechanisms are not described in this document. be built), so such mechanisms are not described in this document.
Policy, provisioning, and processing of authentication and Policy, provisioning, and processing of authentication and
authorization are out of scope for this document as deployments will authorization are out of scope for this document as deployments will
have to make choices based on local criteria. Supported have to make choices based on local criteria. Supported
authentication mechanisms are described in <xref target="RFC7481"/>.</t> authentication mechanisms are described in <xref target="RFC7481" format="def
ault" sectionFormat="of" derivedContent="RFC7481"/>.</t>
</section> </section>
<section anchor="sect-2" numbered="true" toc="include" removeInRFC="false" p
<section title="Conventions Used in This Document" anchor="sect-2"><t> n="section-2">
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL <name slugifiedName="name-conventions-used-in-this-do">Conventions Used in
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", This Document</name>
"MAY", and "OPTIONAL" in this document are to be interpreted as <t indent="0" pn="section-2-1">
described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQU
, and only when, they IRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOUL
appear in all capitals, as shown here.</t> D</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>N
OT RECOMMENDED</bcp14>",
<section title="Acronyms and Abbreviations" anchor="sect-2.1"><t><list ha "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to
ngIndent="3" style="hanging"><t> be interpreted as
IDN: Internationalized Domain Name, a fully-qualified domain name described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="o
f" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFor
mat="of" derivedContent="RFC8174"/>
when, and only when, they appear in all capitals, as shown here.</t>
<section anchor="sect-2.1" numbered="true" toc="include" removeInRFC="fals
e" pn="section-2.1">
<name slugifiedName="name-acronyms-and-abbreviations">Acronyms and Abbre
viations</name>
<dl newline="false" spacing="normal" indent="3" pn="section-2.1-1">
<dt pn="section-2.1-1.1">IDN:</dt>
<dd pn="section-2.1-1.2">
Internationalized Domain Name, a fully-qualified domain name
containing one or more labels that are intended to include one or more containing one or more labels that are intended to include one or more
Unicode code points outside the ASCII range (cf. "domain name", Unicode code points outside the ASCII range (cf. "domain name",
"fully-qualified domain name" and "internationalized domain name" in "fully-qualified domain name", and "internationalized domain name" in
RFC 8499 <xref target="RFC8499"/>).</t> RFC 8499 <xref target="RFC8499" format="default" sectionFormat="of" derive
dContent="RFC8499"/>).</dd>
</list> <dt pn="section-2.1-1.3">IDNA:</dt>
</t> <dd pn="section-2.1-1.4">
Internationalized Domain Names in Applications, a protocol for
<t><list hangIndent="3" style="hanging"><t>
IDNA: Internationalized Domain Names in Applications, a protocol for
the handling of IDNs. In this document, "IDNA" refers specifically to the handling of IDNs. In this document, "IDNA" refers specifically to
the version of those specifications known as "IDNA2008" <xref target="RFC5 the version of those specifications known as "IDNA2008" <xref target="RFC5
890"/>.</t> 890" format="default" sectionFormat="of" derivedContent="RFC5890"/>.</dd>
<dt pn="section-2.1-1.5">DNR:</dt>
</list> <dd pn="section-2.1-1.6">
</t> Domain Name Registry or Domain Name Registrar</dd>
<dt pn="section-2.1-1.7">NFC:</dt>
<t><list hangIndent="3" style="hanging"><t> <dd pn="section-2.1-1.8">
DNR: Domain Name Registry or Domain Name Registrar</t> Unicode Normalization Form C <xref target="Unicode-UAX15" format="default"
sectionFormat="of" derivedContent="Unicode-UAX15"/></dd>
</list> <dt pn="section-2.1-1.9">NFKC:</dt>
</t> <dd pn="section-2.1-1.10">
Unicode Normalization Form KC <xref target="Unicode-UAX15" format="default
<t><list hangIndent="3" style="hanging"><t> " sectionFormat="of" derivedContent="Unicode-UAX15"/></dd>
NFC: Unicode Normalization Form C <xref target="Unicode-UAX15"/></t> <dt pn="section-2.1-1.11">RDAP:</dt>
<dd pn="section-2.1-1.12">
</list> Registration Data Access Protocol</dd>
</t> <dt pn="section-2.1-1.13">REST:</dt>
<dd pn="section-2.1-1.14">
<t><list hangIndent="3" style="hanging"><t> Representational State Transfer. The term was first
NFKC: Unicode Normalization Form KC <xref target="Unicode-UAX15"/></t> described in a doctoral dissertation <xref target="REST" format="default"
sectionFormat="of" derivedContent="REST"/>.</dd>
</list> <dt pn="section-2.1-1.15">RESTful:</dt>
</t> <dd pn="section-2.1-1.16">
An adjective that describes a service using HTTP and the
<t><list hangIndent="3" style="hanging"><t> principles of REST.</dd>
RDAP: Registration Data Access Protocol</t> <dt pn="section-2.1-1.17">RIR:</dt>
<dd pn="section-2.1-1.18">
</list> Regional Internet Registry</dd>
</t> </dl>
</section>
<t><list hangIndent="3" style="hanging"><t> </section>
REST: Representational State Transfer. The term was first <section anchor="sect-3" numbered="true" toc="include" removeInRFC="false" p
described in a doctoral dissertation [REST].</t> n="section-3">
<name slugifiedName="name-path-segment-specification">Path Segment Specifi
</list> cation</name>
</t> <t indent="0" pn="section-3-1">
<t><list hangIndent="3" style="hanging"><t>
RESTful: An adjective that describes a service using HTTP and the
principles of REST.</t>
</list>
</t>
<t><list hangIndent="3" style="hanging"><t>
RIR: Regional Internet Registry</t>
</list>
</t>
</section>
</section>
<section title="Path Segment Specification" anchor="sect-3"><t>
The base URLs used to construct RDAP queries are maintained in an The base URLs used to construct RDAP queries are maintained in an
IANA registry (the "bootstrap registry") described in <xref target="RFC7484"/ >. Queries are formed by IANA registry (the "bootstrap registry") described in <xref target="RFC7484" format="default" sectionFormat="of" derivedContent="RFC7484"/>. Queries are for med by
retrieving an appropriate base URL from the registry and appending a retrieving an appropriate base URL from the registry and appending a
path segment specified in either Sections 3.1 or 3.2. Generally, a path segment specified in either Sections <xref target="sect-3.1" format="cou nter" sectionFormat="of" derivedContent="3.1"/> or <xref target="sect-3.2" forma t="counter" sectionFormat="of" derivedContent="3.2"/>. Generally, a
registry or other service provider will provide a base URL that registry or other service provider will provide a base URL that
identifies the protocol, host, and port, and this will be used as a identifies the protocol, host, and port, and this will be used as a
base URL that the complete URL is resolved against, as per <xref target="sect base URL that the complete URL is resolved against, as per Section <xref targ
-5"/> et="RFC3986" section="5" sectionFormat="bare" format="default" derivedLink="http
of RFC 3986 <xref target="RFC3986"/>. For example, if the base URL is s://rfc-editor.org/rfc/rfc3986#section-5" derivedContent="RFC3986"/>
of RFC 3986 <xref target="RFC3986" format="default" sectionFormat="of" derive
dContent="RFC3986"/>. For example, if the base URL is
"https://example.com/rdap/", all RDAP query URLs will begin with "https://example.com/rdap/", all RDAP query URLs will begin with
"https://example.com/rdap/".</t> "https://example.com/rdap/".</t>
<t indent="0" pn="section-3-2">
<t>
The bootstrap registry does not contain information for query objects The bootstrap registry does not contain information for query objects
that are not part of a global namespace, including entities and help. that are not part of a global namespace, including entities and help.
A base URL for an associated object is required to construct a complete A base URL for an associated object is required to construct a complete
query. This limitation can be overcome for entities by using the practice query. This limitation can be overcome for entities by using the practice
described in RFC 8521 <xref target="RFC8521"/>.</t> described in RFC 8521 <xref target="RFC8521" format="default" sectionFormat="
of" derivedContent="RFC8521"/>.</t>
<t> <t indent="0" pn="section-3-3">
For entities, a base URL is retrieved for the service (domain, For entities, a base URL is retrieved for the service (domain,
address, etc.) associated with a given entity. The query URL is address, etc.) associated with a given entity. The query URL is
constructed by concatenating the base URL with the entity path segment constructed by concatenating the base URL with the entity path segment
specified in either Sections 3.1.5 or 3.2.3.</t> specified in either Sections <xref target="sect-3.1.5" format="counter" secti
onFormat="of" derivedContent="3.1.5"/> or <xref target="sect-3.2.3" format="coun
<t> ter" sectionFormat="of" derivedContent="3.2.3"/>.</t>
<t indent="0" pn="section-3-4">
For help, a base URL is retrieved for any service (domain, address, For help, a base URL is retrieved for any service (domain, address,
etc.) for which additional information is required. The query URL is etc.) for which additional information is required. The query URL is
constructed by concatenating the base URL with the help path segment constructed by concatenating the base URL with the help path segment
specified in <xref target="sect-3.1.6"/>.</t> specified in <xref target="sect-3.1.6" format="default" sectionFormat="of" de
rivedContent="Section 3.1.6"/>.</t>
<section title="Lookup Path Segment Specification" anchor="sect-3.1"><t> <section anchor="sect-3.1" numbered="true" toc="include" removeInRFC="fals
e" pn="section-3.1">
<name slugifiedName="name-lookup-path-segment-specifi">Lookup Path Segme
nt Specification</name>
<t indent="0" pn="section-3.1-1">
A simple lookup to determine if an object exists (or not) without A simple lookup to determine if an object exists (or not) without
returning RDAP-encoded results can be performed using the HTTP HEAD returning RDAP-encoded results can be performed using the HTTP HEAD
method as described in Section 4.1 of <xref target="RFC7480"/>.</t> method as described in <xref target="RFC7480" section="4.1" sectionFormat="of
" format="default" derivedLink="https://rfc-editor.org/rfc/rfc7480#section-4.1"
<t> derivedContent="RFC7480"/>.</t>
<t indent="0" pn="section-3.1-2">
The resource type path segments for exact match lookup are:</t> The resource type path segments for exact match lookup are:</t>
<dl spacing="normal" indent="3" newline="false" pn="section-3.1-3">
<t><list style="symbols"><t>'ip': Used to identify IP networks and associ <dt pn="section-3.1-3.1">'ip':</dt>
ated data referenced <dd pn="section-3.1-3.2"> Used to identify IP networks and associated
using either an IPv4 or IPv6 address.</t> data referenced
using either an IPv4 or IPv6 address.</dd>
<t>'autnum': Used to identify Autonomous System number registrations <dt pn="section-3.1-3.3">'autnum':</dt>
<dd pn="section-3.1-3.4"> Used to identify Autonomous System number re
gistrations
and associated data referenced using an asplain Autonomous System and associated data referenced using an asplain Autonomous System
number.</t> number.</dd>
<dt pn="section-3.1-3.5">'domain':</dt>
<t>'domain': Used to identify reverse DNS (RIR) or domain name (DNR) <dd pn="section-3.1-3.6"> Used to identify reverse DNS (RIR) or domain
name (DNR)
information and associated data referenced using a fully qualified information and associated data referenced using a fully qualified
domain name.</t> domain name.</dd>
<dt pn="section-3.1-3.7">'nameserver':</dt>
<t>'nameserver': Used to identify a nameserver information query <dd pn="section-3.1-3.8"> Used to identify a nameserver information qu
using a host name.</t> ery
using a host name.</dd>
<t>'entity': Used to identify an entity information query using a <dt pn="section-3.1-3.9">'entity':</dt>
string identifier.</t> <dd pn="section-3.1-3.10"> Used to identify an entity information quer
y using a
</list> string identifier.</dd>
</t> </dl>
<section anchor="sect-3.1.1" numbered="true" toc="include" removeInRFC="
<section title="IP Network Path Segment Specification" anchor="sect-3.1.1 false" pn="section-3.1.1">
"><t> <name slugifiedName="name-ip-network-path-segment-spe">IP Network Path
Syntax: ip/&lt;IP address&gt; or ip/&lt;CIDR prefix&gt;/&lt;CIDR length&gt;</ Segment Specification</name>
t> <dl indent="3" newline="false" spacing="normal" pn="section-3.1.1-1">
<dt pn="section-3.1.1-1.1">Syntax:</dt>
<t> <dd pn="section-3.1.1-1.2">ip/&lt;IP address&gt; or ip/&lt;CIDR pref
ix&gt;/&lt;CIDR length&gt;</dd>
</dl>
<t indent="0" pn="section-3.1.1-2">
Queries for information about IP networks are of the form /ip/XXX Queries for information about IP networks are of the form /ip/XXX
or /ip/XXX/YY where the path segment following 'ip' is either an or /ip/XXX/YY where the path segment following 'ip' is either an
IPv4 dotted decimal or IPv6 <xref target="RFC5952"/> address (i.e., XXX) or a IPv4 dotted decimal or IPv6 <xref target="RFC5952" format="default" sectionFo
n IPv4 rmat="of" derivedContent="RFC5952"/> address (i.e., XXX) or an IPv4
or IPv6 Classless Inter-domain Routing (CIDR) <xref target="RFC4632"/> notati or IPv6 Classless Inter-domain Routing (CIDR) <xref target="RFC4632" format="
on default" sectionFormat="of" derivedContent="RFC4632"/> notation
address block (i.e., XXX/YY). Semantically, the simpler form using address block (i.e., XXX/YY). Semantically, the simpler form using
the address can be thought of as a CIDR block with a prefix length the address can be thought of as a CIDR block with a prefix length
of 32 for IPv4 and a prefix length of 128 for IPv6. A given of 32 for IPv4 and a prefix length of 128 for IPv6. A given
specific address or CIDR may fall within multiple IP networks in a specific address or CIDR may fall within multiple IP networks in a
hierarchy of networks; therefore, this query targets the "most-specific" or s mallest IP network that completely encompasses it in a hierarchy of networks; therefore, this query targets the "most-specific" or s mallest IP network that completely encompasses it in a
hierarchy of IP networks.</t> hierarchy of IP networks.</t>
<t indent="0" pn="section-3.1.1-3">
<t>
The IPv4 and IPv6 address formats supported in this query are The IPv4 and IPv6 address formats supported in this query are
described in Section 3.2.2 of RFC 3986 <xref target="RFC3986"/> as IPv4addres s and described in Section <xref target="RFC3986" section="3.2.2" sectionFormat="ba re" format="default" derivedLink="https://rfc-editor.org/rfc/rfc3986#section-3.2 .2" derivedContent="RFC3986"/> of RFC 3986 <xref target="RFC3986" format="defaul t" sectionFormat="of" derivedContent="RFC3986"/> as IPv4address and
IPv6address ABNF definitions. Any valid IPv6 text address format IPv6address ABNF definitions. Any valid IPv6 text address format
<xref target="RFC4291"/> can be used. This includes IPv6 addresses written u sing <xref target="RFC4291" format="default" sectionFormat="of" derivedContent="RF C4291"/> can be used. This includes IPv6 addresses written using
with or without compressed zeros and IPv6 addresses containing with or without compressed zeros and IPv6 addresses containing
embedded IPv4 addresses. The rules to write a text representation of embedded IPv4 addresses. The rules to write a text representation of
an IPv6 address <xref target="RFC5952"/> are RECOMMENDED. However, the zone_ an IPv6 address <xref target="RFC5952" format="default" sectionFormat="of" de
id rivedContent="RFC5952"/> are <bcp14>RECOMMENDED</bcp14>. However, the zone_id
<xref target="RFC4007"/> is not appropriate in this context; therefore, the <xref target="RFC4007" format="default" sectionFormat="of" derivedContent="RF
corresponding syntax extension in RFC 6874 <xref target="RFC6874"/> MUST NOT C4007"/> is not appropriate in this context; therefore, the
be corresponding syntax extension in RFC 6874 <xref target="RFC6874" format="def
used, and servers SHOULD ignore it.</t> ault" sectionFormat="of" derivedContent="RFC6874"/> <bcp14>MUST NOT</bcp14> be
used, and servers <bcp14>SHOULD</bcp14> ignore it.</t>
<t> <t indent="0" pn="section-3.1.1-4">
For example, the following URL would be used to find information for For example, the following URL would be used to find information for
the most specific network containing 192.0.2.0:</t> the most specific network containing 192.0.2.0:</t>
<t indent="0" pn="section-3.1.1-5">https://example.com/rdap/ip/192.0.2
<t>https://example.com/rdap/ip/192.0.2.0</t> .0</t>
<t indent="0" pn="section-3.1.1-6">
<t>
The following URL would be used to find information for the most The following URL would be used to find information for the most
specific network containing 192.0.2.0/24:</t> specific network containing 192.0.2.0/24:</t>
<t indent="0" pn="section-3.1.1-7">https://example.com/rdap/ip/192.0.2
<t>https://example.com/rdap/ip/192.0.2.0/24</t> .0/24</t>
<t indent="0" pn="section-3.1.1-8">
<t>
The following URL would be used to find information for the most The following URL would be used to find information for the most
specific network containing 2001:db8::</t> specific network containing 2001:db8::</t>
<t indent="0" pn="section-3.1.1-9">https://example.com/rdap/ip/2001:db
<t>https://example.com/rdap/ip/2001:db8::</t> 8::</t>
</section>
</section> <section anchor="sect-3.1.2" numbered="true" toc="include" removeInRFC="
false" pn="section-3.1.2">
<section title="Autonomous System Path Segment Specification" anchor="sec <name slugifiedName="name-autonomous-system-path-segm">Autonomous Syst
t-3.1.2"><t> em Path Segment Specification</name>
Syntax: autnum/&lt;autonomous system number&gt;</t> <dl indent="3" newline="false" spacing="normal" pn="section-3.1.2-1">
<dt pn="section-3.1.2-1.1">Syntax:</dt>
<t> <dd pn="section-3.1.2-1.2"> autnum/&lt;autonomous system number&gt;<
/dd>
</dl>
<t indent="0" pn="section-3.1.2-2">
Queries for information regarding Autonomous System number Queries for information regarding Autonomous System number
registrations are of the form /autnum/XXX where XXX is an asplain registrations are of the form /autnum/XXX where XXX is an asplain
Autonomous System number <xref target="RFC5396"/>. In some registries, regis tration Autonomous System number <xref target="RFC5396" format="default" sectionForma t="of" derivedContent="RFC5396"/>. In some registries, registration
of Autonomous System numbers is done on an individual number basis, of Autonomous System numbers is done on an individual number basis,
while other registries may register blocks of Autonomous System while other registries may register blocks of Autonomous System
numbers. The semantics of this query are such that if a number falls numbers. The semantics of this query are such that if a number falls
within a range of registered blocks, the target of the query is the within a range of registered blocks, the target of the query is the
block registration and that individual number registrations are block registration and that individual number registrations are
considered a block of numbers with a size of 1.</t> considered a block of numbers with a size of 1.</t>
<t indent="0" pn="section-3.1.2-3">
<t>
For example, the following URL would be used to find information For example, the following URL would be used to find information
describing Autonomous System number 12 (a number within a range of describing Autonomous System number 12 (a number within a range of
registered blocks):</t> registered blocks):</t>
<t indent="0" pn="section-3.1.2-4">https://example.com/rdap/autnum/12<
<t>https://example.com/rdap/autnum/12</t> /t>
<t indent="0" pn="section-3.1.2-5">
<t>
The following URL would be used to find information describing 4-byte The following URL would be used to find information describing 4-byte
Autonomous System number 65538:</t> Autonomous System number 65538:</t>
<t indent="0" pn="section-3.1.2-6">https://example.com/rdap/autnum/655
<t>https://example.com/rdap/autnum/65538</t> 38</t>
</section>
</section> <section anchor="sect-3.1.3" numbered="true" toc="include" removeInRFC="
false" pn="section-3.1.3">
<section title="Domain Path Segment Specification" anchor="sect-3.1.3"><t <name slugifiedName="name-domain-path-segment-specifi">Domain Path Seg
> ment Specification</name>
Syntax: domain/&lt;domain name&gt;</t> <dl indent="3" newline="false" spacing="normal" pn="section-3.1.3-1">
<dt pn="section-3.1.3-1.1">Syntax:</dt>
<t> <dd pn="section-3.1.3-1.2"> domain/&lt;domain name&gt;</dd>
</dl>
<t indent="0" pn="section-3.1.3-2">
Queries for domain information are of the form /domain/XXXX, Queries for domain information are of the form /domain/XXXX,
where XXXX is a fully qualified (relative to the root) domain name where XXXX is a fully qualified (relative to the root) domain name
(as specified in <xref target="RFC0952"/> and <xref target="RFC1123"/>) in ei ther the in-addr.arpa (as specified in <xref target="RFC0952" format="default" sectionFormat="of" d erivedContent="RFC0952"/> and <xref target="RFC1123" format="default" sectionFor mat="of" derivedContent="RFC1123"/>) in either the in-addr.arpa
or ip6.arpa zones (for RIRs) or a fully qualified domain name in a or ip6.arpa zones (for RIRs) or a fully qualified domain name in a
zone administered by the server operator (for DNRs). zone administered by the server operator (for DNRs).
Internationalized Domain Names (IDNs) represented in either A-label Internationalized Domain Names (IDNs) represented in either A-label
or U-label format <xref target="RFC5890"/> are also valid domain names. See or U-label format <xref target="RFC5890" format="default" sectionFormat="of"
<xref target="sect-6.1"/> for information on character encoding for the U-lab derivedContent="RFC5890"/> are also valid domain names. See
el <xref target="sect-6.1" format="default" sectionFormat="of" derivedContent="S
ection 6.1"/> for information on character encoding for the U-label
format.</t> format.</t>
<t indent="0" pn="section-3.1.3-3">
<t> IDNs <bcp14>SHOULD NOT</bcp14> be represented as a mixture of A-labels and U-
IDNs SHOULD NOT be represented as a mixture of A-labels and U-labels; labels;
that is, internationalized labels in an IDN SHOULD be either all that is, internationalized labels in an IDN <bcp14>SHOULD</bcp14> be either a
ll
A-labels or all U-labels. It is possible for an RDAP client to A-labels or all U-labels. It is possible for an RDAP client to
assemble a query string from multiple independent data sources. Such assemble a query string from multiple independent data sources. Such
a client might not be able to perform conversions between A-labels a client might not be able to perform conversions between A-labels
and U-labels. An RDAP server that receives a query string with a and U-labels. An RDAP server that receives a query string with a
mixture of A-labels and U-labels MAY convert all the U-labels to mixture of A-labels and U-labels <bcp14>MAY</bcp14> convert all the U-labels to
A-labels, perform IDNA processing, and proceed with exact-match A-labels, perform IDNA processing, and proceed with exact-match
lookup. In such cases, the response to be returned to the query lookup. In such cases, the response to be returned to the query
source may not match the input from the query source. Alternatively, source may not match the input from the query source. Alternatively,
the server MAY refuse to process the query.</t> the server <bcp14>MAY</bcp14> refuse to process the query.</t>
<t indent="0" pn="section-3.1.3-4">
<t> The server <bcp14>MAY</bcp14> perform the match using either the A-label or U
The server MAY perform the match using either the A-label or U-label -label
form. Using one consistent form for matching every label is likely form. Using one consistent form for matching every label is likely
to be more reliable.</t> to be more reliable.</t>
<t indent="0" pn="section-3.1.3-5">
<t>
The following URL would be used to find information describing the The following URL would be used to find information describing the
zone serving the network 192.0.2/24:</t> zone serving the network 192.0.2/24:</t>
<t indent="0" pn="section-3.1.3-6">https://example.com/rdap/domain/2.0
<t>https://example.com/rdap/domain/2.0.192.in-addr.arpa</t> .192.in-addr.arpa</t>
<t indent="0" pn="section-3.1.3-7">
<t>
The following URL would be used to find information describing the The following URL would be used to find information describing the
zone serving the network 2001:db8:1::/48:</t> zone serving the network 2001:db8:1::/48:</t>
<t indent="0" pn="section-3.1.3-8">https://example.com/rdap/domain/1.0
<t>https://example.com/rdap/domain/1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa</t> .0.0.8.b.d.0.1.0.0.2.ip6.arpa</t>
<t indent="0" pn="section-3.1.3-9">
<t>
The following URL would be used to find information for the The following URL would be used to find information for the
blah.example.com domain name:</t> blah.example.com domain name:</t>
<t indent="0" pn="section-3.1.3-10">https://example.com/rdap/domain/bl
<t>https://example.com/rdap/domain/blah.example.com</t> ah.example.com</t>
<t indent="0" pn="section-3.1.3-11">
<t>
The following URL would be used to find information for the The following URL would be used to find information for the
xn--fo-5ja.example IDN:</t> xn‑‑fo‑5ja.example IDN:</t>
<t indent="0" pn="section-3.1.3-12">https://example.com/rdap/domain/xn
<t>https://example.com/rdap/domain/xn--fo-5ja.example</t> --fo-5ja.example</t>
</section>
</section> <section anchor="sect-3.1.4" numbered="true" toc="include" removeInRFC="
false" pn="section-3.1.4">
<section title="Nameserver Path Segment Specification" anchor="sect-3.1.4 <name slugifiedName="name-nameserver-path-segment-spe">Nameserver Path
"><t> Segment Specification</name>
Syntax: nameserver/&lt;nameserver name&gt;</t> <dl indent="3" newline="false" spacing="normal" pn="section-3.1.4-1">
<dt pn="section-3.1.4-1.1">Syntax:</dt>
<t> <dd pn="section-3.1.4-1.2">nameserver/&lt;nameserver name&gt;</dd>
</dl>
<t indent="0" pn="section-3.1.4-2">
The &lt;nameserver name&gt; parameter represents a fully qualified host The &lt;nameserver name&gt; parameter represents a fully qualified host
name as specified in <xref target="RFC0952"/> and <xref target="RFC1123"/>. name as specified in <xref target="RFC0952" format="default" sectionFormat="o
Internationalized f" derivedContent="RFC0952"/> and <xref target="RFC1123" format="default" sectio
names represented in either A-label or U-label format <xref target="RFC5890"/ nFormat="of" derivedContent="RFC1123"/>. Internationalized
> are names represented in either A-label or U-label format <xref target="RFC5890"
format="default" sectionFormat="of" derivedContent="RFC5890"/> are
also valid nameserver names. IDN processing for nameserver names also valid nameserver names. IDN processing for nameserver names
uses the domain name processing instructions specified in uses the domain name processing instructions specified in
<xref target="sect-3.1.3"/>. See <xref target="sect-6.1"/> for information o n character encoding <xref target="sect-3.1.3" format="default" sectionFormat="of" derivedContent= "Section 3.1.3"/>. See <xref target="sect-6.1" format="default" sectionFormat=" of" derivedContent="Section 6.1"/> for information on character encoding
for the U-label format.</t> for the U-label format.</t>
<t indent="0" pn="section-3.1.4-3">
<t>
The following URL would be used to find information for the The following URL would be used to find information for the
ns1.example.com nameserver:</t> ns1.example.com nameserver:</t>
<t indent="0" pn="section-3.1.4-4">https://example.com/rdap/nameserver
<t>https://example.com/rdap/nameserver/ns1.example.com</t> /ns1.example.com</t>
<t indent="0" pn="section-3.1.4-5">
<t>
The following URL would be used to find information for the The following URL would be used to find information for the
ns1.xn--fo-5ja.example nameserver:</t> ns1.xn‑‑fo-5ja.example nameserver:</t>
<t indent="0" pn="section-3.1.4-6">https://example.com/rdap/nameserver
<t>https://example.com/rdap/nameserver/ns1.xn--fo-5ja.example</t> /ns1.xn--fo-5ja.example</t>
</section>
</section> <section anchor="sect-3.1.5" numbered="true" toc="include" removeInRFC="
false" pn="section-3.1.5">
<section title="Entity Path Segment Specification" anchor="sect-3.1.5"><t <name slugifiedName="name-entity-path-segment-specifi">Entity Path Seg
> ment Specification</name>
Syntax: entity/&lt;handle&gt;</t> <dl indent="3" newline="false" spacing="normal" pn="section-3.1.5-1">
<dt pn="section-3.1.5-1.1">Syntax:</dt>
<t> <dd pn="section-3.1.5-1.2">entity/&lt;handle&gt;</dd>
</dl>
<t indent="0" pn="section-3.1.5-2">
The &lt;handle&gt; parameter represents an entity (such as a contact, The &lt;handle&gt; parameter represents an entity (such as a contact,
registrant, or registrar) identifier whose syntax is specific to the registrant, or registrar) identifier whose syntax is specific to the
registration provider. For example, for some DNRs, contact registration provider. For example, for some DNRs, contact
identifiers are specified in <xref target="RFC5730"/> and <xref target="RFC57 identifiers are specified in <xref target="RFC5730" format="default" sectionF
33"/>.</t> ormat="of" derivedContent="RFC5730"/> and <xref target="RFC5733" format="default
" sectionFormat="of" derivedContent="RFC5733"/>.</t>
<t> <t indent="0" pn="section-3.1.5-3">
The following URL would be used to find information for the entity The following URL would be used to find information for the entity
associated with handle XXXX:</t> associated with handle XXXX:</t>
<t indent="0" pn="section-3.1.5-4">https://example.com/rdap/entity/XXX
<t>https://example.com/rdap/entity/XXXX</t> X</t>
</section>
</section> <section anchor="sect-3.1.6" numbered="true" toc="include" removeInRFC="
false" pn="section-3.1.6">
<section title="Help Path Segment Specification" anchor="sect-3.1.6"><t> <name slugifiedName="name-help-path-segment-specifica">Help Path Segme
Syntax: help</t> nt Specification</name>
<dl indent="3" newline="false" spacing="normal" pn="section-3.1.6-1">
<t> <dt pn="section-3.1.6-1.1">Syntax:</dt>
<dd pn="section-3.1.6-1.2"> help</dd>
</dl>
<t indent="0" pn="section-3.1.6-2">
The help path segment can be used to request helpful information The help path segment can be used to request helpful information
(command syntax, terms of service, privacy policy, rate-limiting (command syntax, terms of service, privacy policy, rate-limiting
policy, supported authentication methods, supported extensions, policy, supported authentication methods, supported extensions,
technical support contact, etc.) from an RDAP server. The response technical support contact, etc.) from an RDAP server. The response
to "help" should provide basic information that a client needs to to "help" should provide basic information that a client needs to
successfully use the service. The following URL would be used to successfully use the service. The following URL would be used to
return "help" information:</t> return "help" information:</t>
<t indent="0" pn="section-3.1.6-3">https://example.com/rdap/help</t>
<t>https://example.com/rdap/help</t> </section>
</section>
</section> <section anchor="sect-3.2" numbered="true" toc="include" removeInRFC="fals
e" pn="section-3.2">
</section> <name slugifiedName="name-search-path-segment-specifi">Search Path Segme
nt Specification</name>
<section title="Search Path Segment Specification" anchor="sect-3.2"><t> <t indent="0" pn="section-3.2-1">
Pattern matching semantics are described in <xref target="sect-4.1"/>. The Pattern matching semantics are described in <xref target="sect-4.1" format="d
efault" sectionFormat="of" derivedContent="Section 4.1"/>. The
resource type path segments for search are:</t> resource type path segments for search are:</t>
<dl spacing="normal" indent="3" newline="false" pn="section-3.2-2">
<t><list style="symbols"><t>'domains': Used to identify a domain name inf <dt pn="section-3.2-2.1">'domains':</dt>
ormation search using <dd pn="section-3.2-2.2"> Used to identify a domain name information s
a pattern to match a fully qualified domain name.</t> earch using
a pattern to match a fully qualified domain name.</dd>
<t>'nameservers': Used to identify a nameserver information search <dt pn="section-3.2-2.3">'nameservers':</dt>
using a pattern to match a host name.</t> <dd pn="section-3.2-2.4"> Used to identify a nameserver information se
arch
<t>'entities': Used to identify an entity information search using a using a pattern to match a host name.</dd>
pattern to match a string identifier.</t> <dt pn="section-3.2-2.5">'entities':</dt>
<dd pn="section-3.2-2.6"> Used to identify an entity information searc
</list> h using a
</t> pattern to match a string identifier.</dd>
</dl>
<t> <t indent="0" pn="section-3.2-3">
RDAP search path segments are formed using a concatenation of the RDAP search path segments are formed using a concatenation of the
plural form of the object being searched for and an HTTP query plural form of the object being searched for and an HTTP query
string. The HTTP query string is formed using a concatenation of the string. The HTTP query string is formed using a concatenation of the
question mark character ('?', US-ASCII value 0x003F), a noun question mark character ('?', US-ASCII value 0x003F), a noun
representing the JSON object property associated with the object representing the JSON object property associated with the object
being searched for, the equal sign character ('=', US-ASCII value being searched for, the equal sign character ('=', US-ASCII value
0x003D), and the search pattern (this is in contrast to the more 0x003D), and the search pattern (this is in contrast to the more
generic HTTP query string that allows multiple simultaneous parameters). generic HTTP query string that allows multiple simultaneous parameters).
Search pattern query processing is Search pattern query processing is
described more fully in <xref target="sect-4"/>. For the domain, described more fully in <xref target="sect-4" format="default" sectionFormat= "of" derivedContent="Section 4"/>. For the domain,
nameserver, and entity objects described in this document, the nameserver, and entity objects described in this document, the
plural object forms are "domains", "nameservers", and "entities".</t> plural object forms are "domains", "nameservers", and "entities".</t>
<t indent="0" pn="section-3.2-4">
<t>
Detailed results can be retrieved using the HTTP GET method and the Detailed results can be retrieved using the HTTP GET method and the
path segments specified here.</t> path segments specified here.</t>
<section anchor="sect-3.2.1" numbered="true" toc="include" removeInRFC="
<section title="Domain Search" anchor="sect-3.2.1"><t> false" pn="section-3.2.1">
Syntax: domains?name=&lt;domain search pattern&gt;</t> <name slugifiedName="name-domain-search">Domain Search</name>
<dl indent="3" newline="false" spacing="normal" pn="section-3.2.1-1">
<t> <dt pn="section-3.2.1-1.1">Syntax:</dt>
Syntax: domains?nsLdhName=&lt;nameserver search pattern&gt;</t> <dd pn="section-3.2.1-1.2"> domains?name=&lt;domain search pattern&g
t;</dd>
<t> <dt pn="section-3.2.1-1.3">Syntax:</dt>
Syntax: domains?nsIp=&lt;nameserver IP address&gt;</t> <dd pn="section-3.2.1-1.4"> domains?nsLdhName=&lt;nameserver search
pattern&gt;</dd>
<t> <dt pn="section-3.2.1-1.5">Syntax:</dt>
<dd pn="section-3.2.1-1.6"> domains?nsIp=&lt;nameserver IP address&g
t;</dd>
</dl>
<t indent="0" pn="section-3.2.1-2">
Searches for domain information by name are specified using this Searches for domain information by name are specified using this
form:</t> form:</t>
<t indent="0" pn="section-3.2.1-3">
<t>
domains?name=XXXX</t> domains?name=XXXX</t>
<t indent="0" pn="section-3.2.1-4">
<t>
XXXX is a search pattern representing a domain name in "letters, digits, XXXX is a search pattern representing a domain name in "letters, digits,
hyphen" (LDH) format <xref target="RFC5890"/>. The following URL would be us ed to find hyphen" (LDH) format <xref target="RFC5890" format="default" sectionFormat="o f" derivedContent="RFC5890"/>. The following URL would be used to find
DNR information for domain names matching the "example*.com" pattern:</t> DNR information for domain names matching the "example*.com" pattern:</t>
<t indent="0" pn="section-3.2.1-5">https://example.com/rdap/domains?na
<t>https://example.com/rdap/domains?name=example*.com</t> me=example*.com</t>
<t indent="0" pn="section-3.2.1-6">
<t> IDNs in U-label format <xref target="RFC5890" format="default" sectionFormat=
IDNs in U-label format <xref target="RFC5890"/> can also be used as search pa "of" derivedContent="RFC5890"/> can also be used as search patterns
tterns (see <xref target="sect-4" format="default" sectionFormat="of" derivedContent
(see <xref target="sect-4"/>). Searches for these names are of the form ="Section 4"/>). Searches for these names are of the form
/domains?name=XXXX, where XXXX is a search pattern representing a /domains?name=XXXX, where XXXX is a search pattern representing a
domain name in U-label format <xref target="RFC5890"/>. See <xref target="se ct-6.1"/> for domain name in U-label format <xref target="RFC5890" format="default" section Format="of" derivedContent="RFC5890"/>. See <xref target="sect-6.1" format="def ault" sectionFormat="of" derivedContent="Section 6.1"/> for
information on character encoding for the U-label format.</t> information on character encoding for the U-label format.</t>
<t indent="0" pn="section-3.2.1-7">
<t>
Searches for domain information by nameserver name are specified Searches for domain information by nameserver name are specified
using this form:</t> using this form:</t>
<t indent="0" pn="section-3.2.1-8">
<t>
domains?nsLdhName=YYYY</t> domains?nsLdhName=YYYY</t>
<t indent="0" pn="section-3.2.1-9">
<t>
YYYY is a search pattern representing a host name in "letters, digits, YYYY is a search pattern representing a host name in "letters, digits,
hyphen" format <xref target="RFC5890"/>. The following URL would be used to search for hyphen" format <xref target="RFC5890" format="default" sectionFormat="of" der ivedContent="RFC5890"/>. The following URL would be used to search for
domains delegated to nameservers matching the "ns1.example*.com" domains delegated to nameservers matching the "ns1.example*.com"
pattern:</t> pattern:</t>
<t indent="0" pn="section-3.2.1-10">https://example.com/rdap/domains?n
<t>https://example.com/rdap/domains?nsLdhName=ns1.example*.com</t> sLdhName=ns1.example*.com</t>
<t indent="0" pn="section-3.2.1-11">
<t>
Searches for domain information by nameserver IP address are Searches for domain information by nameserver IP address are
specified using this form:</t> specified using this form:</t>
<t indent="0" pn="section-3.2.1-12">
<t>
domains?nsIp=ZZZZ</t> domains?nsIp=ZZZZ</t>
<t indent="0" pn="section-3.2.1-13">
<t> ZZZZ is an IPv4 <xref target="RFC1166" format="default" sectionFormat="of" de
ZZZZ is an IPv4 <xref target="RFC1166"/> or IPv6 rivedContent="RFC1166"/> or IPv6
<xref target="RFC5952"/> address. The following URL would be used to search <xref target="RFC5952" format="default" sectionFormat="of" derivedContent="RF
for C5952"/> address. The following URL would be used to search for
domains that have been delegated to nameservers that resolve to the domains that have been delegated to nameservers that resolve to the
"192.0.2.0" address:</t> "192.0.2.0" address:</t>
<t indent="0" pn="section-3.2.1-14">https://example.com/rdap/domains?n
<t>https://example.com/rdap/domains?nsIp=192.0.2.0</t> sIp=192.0.2.0</t>
</section>
</section> <section anchor="sect-3.2.2" numbered="true" toc="include" removeInRFC="
false" pn="section-3.2.2">
<section title="Nameserver Search" anchor="sect-3.2.2"><t> <name slugifiedName="name-nameserver-search">Nameserver Search</name>
Syntax: nameservers?name=&lt;nameserver search pattern&gt;</t> <dl indent="3" newline="false" spacing="normal" pn="section-3.2.2-1">
<dt pn="section-3.2.2-1.1">Syntax:</dt>
<t> <dd pn="section-3.2.2-1.2"> nameservers?name=&lt;nameserver search p
Syntax: nameservers?ip=&lt;nameserver IP address&gt;</t> attern&gt;</dd>
<dt pn="section-3.2.2-1.3">Syntax:</dt>
<t> <dd pn="section-3.2.2-1.4"> nameservers?ip=&lt;nameserver IP address
&gt;</dd>
</dl>
<t indent="0" pn="section-3.2.2-2">
Searches for nameserver information by nameserver name are specified Searches for nameserver information by nameserver name are specified
using this form:</t> using this form:</t>
<t indent="0" pn="section-3.2.2-3">
<t>
nameservers?name=XXXX</t> nameservers?name=XXXX</t>
<t indent="0" pn="section-3.2.2-4">
<t>
XXXX is a search pattern representing a host name in "letters, digits, XXXX is a search pattern representing a host name in "letters, digits,
hyphen" format <xref target="RFC5890"/>. The following URL would be used to find hyphen" format <xref target="RFC5890" format="default" sectionFormat="of" der ivedContent="RFC5890"/>. The following URL would be used to find
information for nameserver names matching the "ns1.example*.com" information for nameserver names matching the "ns1.example*.com"
pattern:</t> pattern:</t>
<t indent="0" pn="section-3.2.2-5">https://example.com/rdap/nameserver
<t>https://example.com/rdap/nameservers?name=ns1.example*.com</t> s?name=ns1.example*.com</t>
<t indent="0" pn="section-3.2.2-6">
<t> Internationalized nameserver names in U-label format <xref target="RFC5890" f
Internationalized nameserver names in U-label format <xref target="RFC5890"/> ormat="default" sectionFormat="of" derivedContent="RFC5890"/> can
can also be used as search patterns (see <xref target="sect-4" format="default" s
also be used as search patterns (see <xref target="sect-4"/>). Searches for ectionFormat="of" derivedContent="Section 4"/>). Searches for these
these
names are of the form /nameservers?name=XXXX, where XXXX is a search names are of the form /nameservers?name=XXXX, where XXXX is a search
pattern representing a nameserver name in U-label format <xref target="RFC589 pattern representing a nameserver name in U-label format <xref target="RFC589
0"/>. 0" format="default" sectionFormat="of" derivedContent="RFC5890"/>.
See <xref target="sect-6.1"/> for information on character encoding for the U See <xref target="sect-6.1" format="default" sectionFormat="of" derivedConten
-label t="Section 6.1"/> for information on character encoding for the U-label
format.</t> format.</t>
<t indent="0" pn="section-3.2.2-7">
<t>
Searches for nameserver information by nameserver IP address are Searches for nameserver information by nameserver IP address are
specified using this form:</t> specified using this form:</t>
<t indent="0" pn="section-3.2.2-8">
<t>
nameservers?ip=YYYY</t> nameservers?ip=YYYY</t>
<t indent="0" pn="section-3.2.2-9">
<t> YYYY is an IPv4 <xref target="RFC1166" format="default" sectionFormat="of" de
YYYY is an IPv4 <xref target="RFC1166"/> or IPv6 rivedContent="RFC1166"/> or IPv6
<xref target="RFC5952"/> address. The following URL would be used to search <xref target="RFC5952" format="default" sectionFormat="of" derivedContent="RF
for C5952"/> address. The following URL would be used to search for
nameserver names that resolve to the "192.0.2.0" address:</t> nameserver names that resolve to the "192.0.2.0" address:</t>
<t indent="0" pn="section-3.2.2-10">https://example.com/rdap/nameserve
<t>https://example.com/rdap/nameservers?ip=192.0.2.0</t> rs?ip=192.0.2.0</t>
</section>
</section> <section anchor="sect-3.2.3" numbered="true" toc="include" removeInRFC="
false" pn="section-3.2.3">
<section title="Entity Search" anchor="sect-3.2.3"><t> <name slugifiedName="name-entity-search">Entity Search</name>
Syntax: entities?fn=&lt;entity name search pattern&gt;</t> <dl indent="3" newline="false" spacing="normal" pn="section-3.2.3-1">
<dt pn="section-3.2.3-1.1">Syntax:</dt>
<t> <dd pn="section-3.2.3-1.2"> entities?fn=&lt;entity name search patte
Syntax: entities?handle=&lt;entity handle search pattern&gt;</t> rn&gt;</dd>
<dt pn="section-3.2.3-1.3">Syntax:</dt>
<t> <dd pn="section-3.2.3-1.4"> entities?handle=&lt;entity handle search
pattern&gt;</dd>
</dl>
<t indent="0" pn="section-3.2.3-2">
Searches for entity information by name are specified using this Searches for entity information by name are specified using this
form:</t> form:</t>
<t indent="0" pn="section-3.2.3-3">
<t>
entities?fn=XXXX</t> entities?fn=XXXX</t>
<t indent="0" pn="section-3.2.3-4">
<t>
XXXX is a search pattern representing the "fn" property of an entity XXXX is a search pattern representing the "fn" property of an entity
(such as a contact, registrant, or registrar) name as described in (such as a contact, registrant, or registrar) name as described in
Section 5.1 of <xref target="I-D.ietf-regext-rfc7483bis"/>. The following UR L would be used to find <xref target="RFC9083" section="5.1" sectionFormat="of" format="default" deri vedLink="https://rfc-editor.org/rfc/rfc9083#section-5.1" derivedContent="RFC9083 "/>. The following URL would be used to find
information for entity names matching the "Bobby Joe*" pattern:</t> information for entity names matching the "Bobby Joe*" pattern:</t>
<t indent="0" pn="section-3.2.3-5">https://example.com/rdap/entities?f
<t>https://example.com/rdap/entities?fn=Bobby%20Joe*</t> n=Bobby%20Joe*</t>
<t indent="0" pn="section-3.2.3-6">
<t>
Searches for entity information by handle are specified using this Searches for entity information by handle are specified using this
form:</t> form:</t>
<t indent="0" pn="section-3.2.3-7">
<t>
entities?handle=XXXX</t> entities?handle=XXXX</t>
<t indent="0" pn="section-3.2.3-8">
<t>
XXXX is a search pattern representing an entity (such as a contact, XXXX is a search pattern representing an entity (such as a contact,
registrant, or registrar) identifier whose syntax is specific to the registrant, or registrar) identifier whose syntax is specific to the
registration provider. The following URL would be used to find registration provider. The following URL would be used to find
information for entity handles matching the "CID-40*" pattern:</t> information for entity handles matching the "CID-40*" pattern:</t>
<t indent="0" pn="section-3.2.3-9">https://example.com/rdap/entities?h
<t>https://example.com/rdap/entities?handle=CID-40*</t> andle=CID-40*</t>
<t indent="0" pn="section-3.2.3-10">
<t> URLs <bcp14>MUST</bcp14> be properly encoded according to the rules of <xref
URLs MUST be properly encoded according to the rules of <xref target="RFC3986 target="RFC3986" format="default" sectionFormat="of" derivedContent="RFC3986"/>.
"/>.
In the example above, "Bobby Joe*" is encoded to "Bobby%20Joe*".</t> In the example above, "Bobby Joe*" is encoded to "Bobby%20Joe*".</t>
</section>
</section> </section>
</section>
</section> <section anchor="sect-4" numbered="true" toc="include" removeInRFC="false" p
n="section-4">
</section> <name slugifiedName="name-query-processing">Query Processing</name>
<t indent="0" pn="section-4-1">
<section title="Query Processing" anchor="sect-4"><t>
Servers indicate the success or failure of query processing by Servers indicate the success or failure of query processing by
returning an appropriate HTTP response code to the client. Response returning an appropriate HTTP response code to the client. Response
codes not specifically identified in this document are described in codes not specifically identified in this document are described in
<xref target="RFC7480"/>.</t> <xref target="RFC7480" format="default" sectionFormat="of" derivedContent="RF
C7480"/>.</t>
<section title="Partial String Searching" anchor="sect-4.1"><t> <section anchor="sect-4.1" numbered="true" toc="include" removeInRFC="fals
e" pn="section-4.1">
<name slugifiedName="name-partial-string-searching">Partial String Searc
hing</name>
<t indent="0" pn="section-4.1-1">
Partial string searching uses the asterisk ('*', US-ASCII value 0x2A) Partial string searching uses the asterisk ('*', US-ASCII value 0x2A)
character to match zero or more trailing characters. A character string character to match zero or more trailing characters. A character string
representing a domain label suffix MAY be concatenated to the end of the representing a domain label suffix <bcp14>MAY</bcp14> be concatenated to the end of the
search pattern to limit the scope of the search. For example, the search search pattern to limit the scope of the search. For example, the search
pattern "exam*" will match "example.com" and "example.net". The search pattern "exam*" will match "example.com" and "example.net". The search
pattern "exam*.com" will match "example.com". If an asterisk appears in pattern "exam*.com" will match "example.com". If an asterisk appears in
a search string, any label that contains the non-asterisk characters in a search string, any label that contains the non-asterisk characters in
sequence plus zero or more characters in sequence in place of the asterisk sequence plus zero or more characters in sequence in place of the asterisk
would match. A partial string search MUST NOT include more than one asterisk. would match. A partial string search <bcp14>MUST NOT</bcp14> include more tha n one asterisk.
Additional pattern matching processing is beyond the scope of this specificat ion.</t> Additional pattern matching processing is beyond the scope of this specificat ion.</t>
<t indent="0" pn="section-4.1-2">
<t>
If a server receives a search request but cannot process the request If a server receives a search request but cannot process the request
because it does not support a particular style of partial match because it does not support a particular style of partial match
searching, it SHOULD return an HTTP 422 (Unprocessable Entity) searching, it <bcp14>SHOULD</bcp14> return an HTTP 422 (Unprocessable Entity)
<xref target="RFC4918"/> response (unless another response code is <xref target="RFC4918" format="default" sectionFormat="of" derivedContent="RF
C4918"/> response (unless another response code is
more appropriate based on a server's policy settings) to note that search fun ctionality more appropriate based on a server's policy settings) to note that search fun ctionality
is supported, but this particular query cannot be processed. When is supported, but this particular query cannot be processed. When
returning a 422 error, the server MAY also return an error response returning a 422 error, the server <bcp14>MAY</bcp14> also return an error res
body as specified in Section 6 of <xref target="I-D.ietf-regext-rfc7483bis"/> ponse
if the requested media type is one that is specified in <xref target="RFC7480 body as specified in <xref target="RFC9083" section="6" sectionFormat="of" fo
"/>.</t> rmat="default" derivedLink="https://rfc-editor.org/rfc/rfc9083#section-6" derive
dContent="RFC9083"/>
<t> if the requested media type is one that is specified in <xref target="RFC7480
" format="default" sectionFormat="of" derivedContent="RFC7480"/>.</t>
<t indent="0" pn="section-4.1-3">
Partial matching is not feasible across combinations of Unicode Partial matching is not feasible across combinations of Unicode
characters because Unicode characters can be combined with each characters because Unicode characters can be combined with each
other. Servers SHOULD NOT partially match combinations of Unicode other. Servers <bcp14>SHOULD NOT</bcp14> partially match combinations of Uni code
characters where a legal combination is possible. It should be characters where a legal combination is possible. It should be
noted, though, that it may not always be possible to detect cases noted, though, that it may not always be possible to detect cases
where a character could have been combined with another character, where a character could have been combined with another character,
but was not, because characters can be combined in many different but was not, because characters can be combined in many different
ways.</t> ways.</t>
<t indent="0" pn="section-4.1-4">
<t> Clients <bcp14>SHOULD NOT</bcp14> submit a partial match search of Unicode
Clients SHOULD NOT submit a partial match search of Unicode
characters where a Unicode character may be legally combined with characters where a Unicode character may be legally combined with
another Unicode character or characters. Partial match searches with another Unicode character or characters. Partial match searches with
incomplete combinations of characters where a character must be incomplete combinations of characters where a character must be
combined with another character or characters are invalid. Partial combined with another character or characters are invalid. Partial
match searches with characters that may be combined with another match searches with characters that may be combined with another
character or characters are to be considered non-combined characters character or characters are to be considered non-combined characters
(that is, if character x may be combined with character y but (that is, if character x may be combined with character y but
character y is not submitted in the search string, then character x character y is not submitted in the search string, then character x
is a complete character and no combinations of character x are to be is a complete character and no combinations of character x are to be
searched).</t> searched).</t>
</section>
</section> <section anchor="sect-4.2" numbered="true" toc="include" removeInRFC="fals
e" pn="section-4.2">
<section title="Associated Records" anchor="sect-4.2"><t> <name slugifiedName="name-associated-records">Associated Records</name>
<t indent="0" pn="section-4.2-1">
Conceptually, any query-matching record in a server's database might Conceptually, any query-matching record in a server's database might
be a member of a set of related records, related in some fashion as be a member of a set of related records, related in some fashion as
defined by the server -- for example, variants of an IDN. The entire defined by the server -- for example, variants of an IDN. The entire
set ought to be considered as candidates for inclusion when set ought to be considered as candidates for inclusion when
constructing the response. However, the construction of the final constructing the response. However, the construction of the final
response needs to be mindful of privacy and other data-releasing response needs to be mindful of privacy and other data-releasing
policies when assembling the RDAP response set.</t> policies when assembling the RDAP response set.</t>
<t indent="0" pn="section-4.2-2">
<t>
Note too that due to the nature of searching, there may be a list of Note too that due to the nature of searching, there may be a list of
query-matching records. Each one of those is subject to being a query-matching records. Each one of those is subject to being a
member of a set as described in the previous paragraph. What is member of a set as described in the previous paragraph. What is
ultimately returned in a response will be the union of all the sets ultimately returned in a response will be the union of all the sets
that has been filtered by whatever policies are in place.</t> that has been filtered by whatever policies are in place.</t>
<t indent="0" pn="section-4.2-3">
<t>
Note that this model includes arrangements for associated names, Note that this model includes arrangements for associated names,
including those that are linked by policy mechanisms and names bound including those that are linked by policy mechanisms and names bound
together for some other purposes. Note also that returning together for some other purposes. Note also that returning
information that was not explicitly selected by an exact-match information that was not explicitly selected by an exact-match
lookup, including additional names that match a relatively fuzzy lookup, including additional names that match a relatively fuzzy
search as well as lists of names that are linked together, may cause search as well as lists of names that are linked together, may cause
privacy issues.</t> privacy issues.</t>
<t indent="0" pn="section-4.2-4">
<t>
Note that there might not be a single, static information return Note that there might not be a single, static information return
policy that applies to all clients equally. Client identity and policy that applies to all clients equally. Client identity and
associated authorizations can be a relevant factor in determining how associated authorizations can be a relevant factor in determining how
broad the response set will be for any particular query.</t> broad the response set will be for any particular query.</t>
</section>
</section> </section>
<section anchor="sect-5" numbered="true" toc="include" removeInRFC="false" p
</section> n="section-5">
<name slugifiedName="name-extensibility">Extensibility</name>
<section title="Extensibility" anchor="sect-5"><t> <t indent="0" pn="section-5-1">
This document describes path segment specifications for a limited This document describes path segment specifications for a limited
number of objects commonly registered in both RIRs and DNRs. It does number of objects commonly registered in both RIRs and DNRs. It does
not attempt to describe path segments for all of the objects not attempt to describe path segments for all of the objects
registered in all registries. Custom path segments can be created registered in all registries. Custom path segments can be created
for objects not specified here using the process described in for objects not specified here using the process described in
Section 6 of "HTTP Usage in the Registration Data Access Protocol (RDAP)" <xr Section <xref target="RFC7480" section="6" sectionFormat="bare" format="defau
ef target="RFC7480"/>.</t> lt" derivedLink="https://rfc-editor.org/rfc/rfc7480#section-6" derivedContent="R
FC7480"/> of "<xref target="RFC7480" format="title" sectionFormat="of" derivedCo
<t> ntent="HTTP Usage in the Registration Data Access Protocol (RDAP)"/>" <xref targ
et="RFC7480" format="default" sectionFormat="of" derivedContent="RFC7480"/>.</t>
<t indent="0" pn="section-5-2">
Custom path segments can be created by prefixing the segment with a Custom path segments can be created by prefixing the segment with a
unique identifier followed by an underscore character (0x5F). For unique identifier followed by an underscore character (0x5F). For
example, a custom entity path segment could be created by prefixing example, a custom entity path segment could be created by prefixing
"entity" with "custom_", producing "custom_entity". Servers MUST "entity" with "custom_", producing "custom_entity". Servers <bcp14>MUST</bcp 14>
return an appropriate failure status code for a request with an return an appropriate failure status code for a request with an
unrecognized path segment.</t> unrecognized path segment.</t>
</section>
</section> <section anchor="sect-6" numbered="true" toc="include" removeInRFC="false" p
n="section-6">
<section title="Internationalization Considerations" anchor="sect-6"><t> <name slugifiedName="name-internationalization-consid">Internationalizatio
n Considerations</name>
<t indent="0" pn="section-6-1">
There is value in supporting the ability to submit either a U-label There is value in supporting the ability to submit either a U-label
(Unicode form of an IDN label) or an A-label (US-ASCII form of an IDN (Unicode form of an IDN label) or an A-label (US-ASCII form of an IDN
label) as a query argument to an RDAP service. Clients capable of label) as a query argument to an RDAP service. Clients capable of
processing non-US-ASCII characters may prefer a U-label since this is processing non-US-ASCII characters may prefer a U-label since this is
more visually recognizable and familiar than A-label strings, but more visually recognizable and familiar than A-label strings, but
clients using programmatic interfaces might find it easier to submit clients using programmatic interfaces might find it easier to submit
and display A-labels if they are unable to input U-labels with their and display A-labels if they are unable to input U-labels with their
keyboard configuration. Both query forms are acceptable.</t> keyboard configuration. Both query forms are acceptable.</t>
<t indent="0" pn="section-6-2">
<t>
Internationalized domain and nameserver names can contain character Internationalized domain and nameserver names can contain character
variants and variant labels as described in <xref target="RFC4290"/>. Client s that variants and variant labels as described in <xref target="RFC4290" format="de fault" sectionFormat="of" derivedContent="RFC4290"/>. Clients that
support queries for internationalized domain and nameserver names support queries for internationalized domain and nameserver names
MUST accept service provider responses that describe variants as <bcp14>MUST</bcp14> accept service provider responses that describe variants
specified in "JSON Responses for the Registration Data Access Protocol (RDAP) as
" <xref target="I-D.ietf-regext-rfc7483bis"/>.</t> specified in "<xref target="RFC9083" format="title" sectionFormat="of" derive
dContent="JSON Responses for the Registration Data Access Protocol (RDAP)"/>" <x
<section title="Character Encoding Considerations" anchor="sect-6.1"><t> ref target="RFC9083" format="default" sectionFormat="of" derivedContent="RFC9083
"/>.</t>
<section anchor="sect-6.1" numbered="true" toc="include" removeInRFC="fals
e" pn="section-6.1">
<name slugifiedName="name-character-encoding-consider">Character Encodin
g Considerations</name>
<t indent="0" pn="section-6.1-1">
Servers can expect to receive search patterns from clients that Servers can expect to receive search patterns from clients that
contain character strings encoded in different forms supported by contain character strings encoded in different forms supported by
HTTP. It is entirely possible to apply filters and normalization HTTP. It is entirely possible to apply filters and normalization
rules to search patterns prior to making character comparisons, but rules to search patterns prior to making character comparisons, but
this type of processing is more typically needed to determine the this type of processing is more typically needed to determine the
validity of registered strings than to match patterns.</t> validity of registered strings than to match patterns.</t>
<t indent="0" pn="section-6.1-2">
<t>
An RDAP client submitting a query string containing non-US-ASCII An RDAP client submitting a query string containing non-US-ASCII
characters converts such strings into Unicode in UTF-8 encoding. It characters converts such strings into Unicode in UTF-8 encoding. It
then performs any local case mapping deemed necessary. Strings are then performs any local case mapping deemed necessary. Strings are
normalized using Normalization Form C (NFC) <xref target="Unicode-UAX15"/>; n ote normalized using Normalization Form C (NFC) <xref target="Unicode-UAX15" form at="default" sectionFormat="of" derivedContent="Unicode-UAX15"/>; note
that clients might not be able to do this reliably. UTF-8 encoded that clients might not be able to do this reliably. UTF-8 encoded
strings are then appropriately percent-encoded <xref target="RFC3986"/> in th e query strings are then appropriately percent-encoded <xref target="RFC3986" format= "default" sectionFormat="of" derivedContent="RFC3986"/> in the query
URL.</t> URL.</t>
<t indent="0" pn="section-6.1-3">
<t>
After parsing any percent-encoding, an RDAP server treats each query After parsing any percent-encoding, an RDAP server treats each query
string as Unicode in UTF-8 encoding. If a string is not valid UTF-8, string as Unicode in UTF-8 encoding. If a string is not valid UTF-8,
the server can immediately stop processing the query and return an the server can immediately stop processing the query and return an
HTTP 400 (Bad Request) response.</t> HTTP 400 (Bad Request) response.</t>
<t indent="0" pn="section-6.1-4">
<t>
When processing queries, there is a difference in handling DNS names, When processing queries, there is a difference in handling DNS names,
including those with putative U-labels, and everything else. DNS including those with putative U-labels, and everything else. DNS
names are treated according to the DNS matching rules as described in names are treated according to the DNS matching rules as described in
Section 3.1 of RFC 1035 <xref target="RFC1035"/> for Non-Reserved LDH (NR-LDH Section <xref target="RFC1035" section="3.1" sectionFormat="bare" format="def
) ault" derivedLink="https://rfc-editor.org/rfc/rfc1035#section-3.1" derivedConten
labels and the matching rules described in Section 5.4 of RFC 5891 t="RFC1035"/> of RFC 1035 <xref target="RFC1035" format="default" sectionFormat=
<xref target="RFC5891"/> for U-labels. Matching of DNS names proceeds one la "of" derivedContent="RFC1035"/> for Non-Reserved LDH (NR-LDH)
bel at labels and the matching rules described in Section <xref target="RFC5891" sec
tion="5.4" sectionFormat="bare" format="default" derivedLink="https://rfc-editor
.org/rfc/rfc5891#section-5.4" derivedContent="RFC5891"/> of RFC 5891
<xref target="RFC5891" format="default" sectionFormat="of" derivedContent="RF
C5891"/> for U-labels. Matching of DNS names proceeds one label at
a time because it is possible for a combination of U-labels and a time because it is possible for a combination of U-labels and
NR-LDH labels to be found in a single domain or host name. The NR-LDH labels to be found in a single domain or host name. The
determination of whether a label is a U-label or an NR-LDH label is determination of whether a label is a U-label or an NR-LDH label is
based on whether the label contains any characters outside of the based on whether the label contains any characters outside of the
US-ASCII letters, digits, or hyphen (the so-called LDH rule).</t> US-ASCII letters, digits, or hyphen (the so-called LDH rule).</t>
<t indent="0" pn="section-6.1-5">
<t>
For everything else, servers map fullwidth and halfwidth characters For everything else, servers map fullwidth and halfwidth characters
to their decomposition equivalents. Servers convert strings to the to their decomposition equivalents. Servers convert strings to the
same coded character set of the target data that is to be looked up same coded character set of the target data that is to be looked up
or searched, and each string is normalized using the same or searched, and each string is normalized using the same
normalization that was used on the target data. In general, storage normalization that was used on the target data. In general, storage
of strings as Unicode is RECOMMENDED. For the purposes of of strings as Unicode is <bcp14>RECOMMENDED</bcp14>. For the purposes of
comparison, Normalization Form KC (NFKC) <xref target="Unicode-UAX15"/> with comparison, Normalization Form KC (NFKC) <xref target="Unicode-UAX15" format=
case "default" sectionFormat="of" derivedContent="Unicode-UAX15"/> with case
folding is used to maximize predictability and the number of matches. folding is used to maximize predictability and the number of matches.
Note the use of case-folded NFKC as opposed to NFC in this case.</t> Note the use of case-folded NFKC as opposed to NFC in this case.</t>
</section>
</section>
<section anchor="impl-status" title="Implementation Status">
<t>NOTE: Please remove this section and the reference to RFC 7942 prior to
publication as an RFC.</t>
<t>This section records the status of known implementations of the protoco
l defined by this specification at the time of posting of this Internet-Draft, a
nd is based on a proposal described in RFC 7942 <xref target="RFC7942"/>. The de
scription of implementations in this section is intended to assist the IETF in i
ts decision processes in progressing drafts to RFCs. Please note that the listin
g of any individual implementation here does not imply endorsement by the IETF.
Furthermore, no effort has been spent to verify the information presented here t
hat was supplied by IETF contributors. This is not intended as, and must not be
construed to be, a catalog of available implementations or their features. Reade
rs are advised to note that other implementations may exist.</t>
<t>According to RFC 7942, "this will allow reviewers and working groups to
assign due consideration to documents that have the benefit of running code, wh
ich may serve as evidence of valuable experimentation and feedback that have mad
e the implemented protocols more mature. It is up to the individual working grou
ps to use this information as they see fit".</t>
<section anchor="verisign" title="Viagenie">
<t><list style="none">
<t>Responsible Organization: Viagenie</t>
<t>Location: RDAPBrowser (iOS and Android): https://viagenie.ca/rdapbro
wser</t>
<t>Description: Mobile app (iOS and Android) implementing an RDAP clien
t for domains, IP addresses and AS numbers.</t>
<t>Level of Maturity: Production</t>
<t>Coverage: All except for nameserver, entity, help, and search path s
egments.</t>
<t>Version Compatibility: RFC 7482</t>
<t>Licensing: Proprietary</t>
<t>Implementation Experience: Quite simple and easy to deploy. Response
s are much harder to parse because RDAP servers are not compliant.</t>
<t>Contact Information: Marc Blanchet, rdapbrowser@viagenie.ca</t>
<t>Date Last Updated: September 27, 2019</t>
</list></t>
</section>
<section anchor="arin" title="ARIN">
<t><list style="none">
<t>Responsible Organization: ARIN</t>
<t>Location: search.arin.net https://search.arin.net/rdap/</t>
<t>Description: search.arin.net is a public web page getting about 8k q
ueries per day.</t>
<t>Level of Maturity: Production.</t>
<t>Coverage: Search.arin.net supports lookup of entities by handle, sea
rch of entities by name, lookup of domain names, lookup of ip networks, lookup o
f autnums.</t>
<t>Version Compatibility: RFC 7482</t>
<t>Licensing: Search.arin.net is not publicly licensed.</t>
<t>Implementation Experience: The RDAP queries are straightforward for
the most part. The vast majority of logic goes into displaying information.</t>
<t>Contact Information: info@arin.net</t>
<t>Date Last Updated: July 2019.</t>
</list></t>
</section>
<section anchor="NicInfo" title="NicInfo">
<t><list style="none">
<t>Responsible Organization: ARIN</t>
<t>Location: NicInfo https://github.com/arineng/nicinfo</t>
<t>Description: NicInfo is a command line client written in Ruby.</t>
<t>Level of Maturity: NicInfo started as a research project, but is kno
wn to be used by some organizations in a production capacity.</t>
<t>Version Compatibility: RFC 7482</t>
<t>Licensing: NicInfo is published under the ISC license.</t>
<t>Implementation Experience: The RDAP queries are straightforward for
the most part. The vast majority of logic goes into displaying information.</t>
<t>Contact Information: info@arin.net</t>
<t>Date Last Updated: NicInfo was last updated in Feb 2018.</t>
</list></t>
</section>
<section anchor="lacnic" title="LACNIC">
<t><list style="none">
<t>Responsible Organization: LACNIC</t>
<t>Location: https://github.com/LACNIC/rdap-frontend-angular-dev</t>
<t>Description: The goal of this client is to have an RDAP client that
can be easily embedded in web pages. The original request was for a web whois/rd
ap feature that was to replace a very, very old web whois that just popen'd CLI
WHOIS and just copied back the output to html. We decided to implement something
that could, in the future, be embedded in any web page and is not tied to our c
urrent web portal CMS. The client is implemented in Javascript and AngularJS.</t
>
<t>Level of Maturity: We consider the current version production qualit
y, it has been in use in our web portal for more than a year now.</t>
<t>Coverage: The client implements /ip, /autnum, and /entity. The clien
t does not support searches. For these objects the implementation follows the st
andard closely. There may be a few gaps, but it’s mostly aligned to the RFCs.</t
>
<t>Version Compatibility: RFC 7482</t>
<t>Licensing: BSD-Style</t>
<t>Implementation Experience: Users of the traditional WHOIS service ar
e a bit confused at first when they realize that an RDAP query does not necessar
ily return the same
information and in some cases they need to "navigate" the RDAP tree to get data
that is normally returned in a single WHOIS query. In our experience, this gap i
n expectations has been one of the most significant hurdles in adoption of RDAP.
Our RDAP client makes this "navigation" easier as it presents results in the fo
rm of a web page where the "next" necessary RDAP query is a click on a link. On
the plus side, the protocol provides all the information needed to present this
links and clicks to the user. We have however introduced a few extensions into o
ur RDAP responses to
get both services to parity in the information presented in a single query.</t>
<t>Contact Information: Gerardo Rada (gerardo@lacnic.net), Carlos Marti
nez (carlos@lacnic.net)</t>
<t>Date Last Updated: This application is currently in maintenance mode
. Also, we employ a rolling release update. Latest updates are available in the
git log of the repo.</t>
</list></t>
</section>
<section anchor="icann" title="ICANN">
<t><list style="none">
<t>Responsible Organization: Internet Corporation for Assigned Names an
d Numbers (ICANN)</t>
<t>Location: Domain Name Registration Data Lookup: https://lookup.icann
.org/</t>
<t>Description: ICANN created the Domain Name Registration Data Lookup
web client as a free public service that gives users the ability to look up and
display publicly available registration data related to a domain name using the
top level domain's RDAP service location listed in the IANA bootstrap service re
gistry for domain name space (RFC 7484), and the sponsoring Registrar's RDAP ser
ver. This web client implementation also supports the specifications defined in
the "gTLD RDAP Profile" documents (https://www.icann.org/gtld-rdap-profile).</t>
<t>Level of Maturity: Production.</t>
<t>Coverage: This web client implements RFC 7482 section 3.1.3 "Domain
Path Segment Specification" to perform lookups exclusively for the domain object
class.</t>
<t>Version Compatibility: RFC 7482</t>
<t>Contact Information: globalSupport@icann.org</t>
<t>Date Last Updated: 07-Oct-2019</t>
</list></t>
</section> </section>
</section> </section>
<section anchor="IANA-Cons" numbered="true" toc="include" removeInRFC="false
<section title="IANA Considerations" anchor="IANA-Cons"> " pn="section-7">
<t>This document has no actions for IANA.</t> <name slugifiedName="name-iana-considerations">IANA Considerations</name>
</section> <t indent="0" pn="section-7-1">This document has no IANA actions.</t>
</section>
<section title="Security Considerations" anchor="sect-7"><t> <section anchor="sect-7" numbered="true" toc="include" removeInRFC="false" p
n="section-8">
<name slugifiedName="name-security-considerations">Security Considerations
</name>
<t indent="0" pn="section-8-1">
Security services for the operations specified in this document are Security services for the operations specified in this document are
described in "Security Services for the Registration Data Access Protocol (RD described in "<xref target="RFC7481" format="title" sectionFormat="of" derive
AP)" <xref target="RFC7481"/>.</t> dContent="Security Services for the Registration Data Access Protocol (RDAP)"/>"
<xref target="RFC7481" format="default" sectionFormat="of" derivedContent="RFC7
<t> 481"/>.</t>
<t indent="0" pn="section-8-2">
Search functionality typically requires more server resources (such Search functionality typically requires more server resources (such
as memory, CPU cycles, and network bandwidth) when compared to basic as memory, CPU cycles, and network bandwidth) when compared to basic
lookup functionality. This increases the risk of server resource lookup functionality. This increases the risk of server resource
exhaustion and subsequent denial of service due to abuse. This risk exhaustion and subsequent denial of service due to abuse. This risk
can be mitigated by developing and implementing controls to restrict can be mitigated by developing and implementing controls to restrict
search functionality to identified and authorized clients. If those search functionality to identified and authorized clients. If those
clients behave badly, their search privileges can be suspended or clients behave badly, their search privileges can be suspended or
revoked. Rate limiting as described in Section 5.5 of "HTTP Usage in the Reg istration Data Access Protocol (RDAP)" <xref target="RFC7480"/> can also be revoked. Rate limiting as described in Section <xref target="RFC7480" sectio n="5.5" sectionFormat="bare" format="default" derivedLink="https://rfc-editor.or g/rfc/rfc7480#section-5.5" derivedContent="RFC7480"/> of "<xref target="RFC7480" format="title" sectionFormat="of" derivedContent="HTTP Usage in the Registratio n Data Access Protocol (RDAP)"/>" <xref target="RFC7480" format="default" sectio nFormat="of" derivedContent="RFC7480"/> can also be
used to control the rate of received search requests. Server used to control the rate of received search requests. Server
operators can also reduce their risk by restricting the amount of operators can also reduce their risk by restricting the amount of
information returned in response to a search request.</t> information returned in response to a search request.</t>
<t indent="0" pn="section-8-3">
<t>
Search functionality also increases the privacy risk of disclosing Search functionality also increases the privacy risk of disclosing
object relationships that might not otherwise be obvious. For object relationships that might not otherwise be obvious. For
example, a search that returns IDN variants <xref target="RFC6927"/> that do not example, a search that returns IDN variants <xref target="RFC6927" format="de fault" sectionFormat="of" derivedContent="RFC6927"/> that do not
explicitly match a client-provided search pattern can disclose explicitly match a client-provided search pattern can disclose
information about registered domain names that might not be otherwise information about registered domain names that might not be otherwise
available. Implementers need to consider the policy and privacy available. Implementers need to consider the policy and privacy
implications of returning information that was not explicitly implications of returning information that was not explicitly
requested.</t> requested.</t>
<t indent="0" pn="section-8-4">
<t>
Note that there might not be a single, static information return Note that there might not be a single, static information return
policy that applies to all clients equally. Client identity and policy that applies to all clients equally. Client identity and
associated authorizations can be a relevant factor in determining how associated authorizations can be a relevant factor in determining how
broad the response set will be for any particular query.</t> broad the response set will be for any particular query.</t>
</section>
</section> </middle>
<back>
</middle> <references pn="section-9">
<name slugifiedName="name-references">References</name>
<back> <references pn="section-9.1">
<references title="Normative References"> <name slugifiedName="name-normative-references">Normative References</na
&RFC0952; me>
&RFC1035; <reference anchor="RFC0952" target="https://www.rfc-editor.org/info/rfc9
&RFC1123; 52" quoteTitle="true" derivedAnchor="RFC0952">
&RFC1166; <front>
&RFC2119; <title>DoD Internet host table specification</title>
&RFC3986; <author initials="K." surname="Harrenstien" fullname="K. Harrenstien
&RFC4291; ">
&RFC4632; <organization showOnFrontPage="true"/>
&RFC4918; </author>
&RFC5396; <author initials="M.K." surname="Stahl" fullname="M.K. Stahl">
&RFC5730; <organization showOnFrontPage="true"/>
&RFC5733; </author>
&RFC5890; <author initials="E.J." surname="Feinler" fullname="E.J. Feinler">
&RFC5891; <organization showOnFrontPage="true"/>
&RFC5952; </author>
&RFC7230; <date year="1985" month="October"/>
&RFC7231; <abstract>
&RFC7480; <t indent="0">This RFC is the official specification of the format
&RFC7481; of the Internet Host Table. This edition of the specification includes mino
&RFC7484; r revisions to RFC-810 which brings it up to date.</t>
&RFC8174; </abstract>
&RFC8499; </front>
&I-D.ietf-regext-rfc7483bis; <seriesInfo name="RFC" value="952"/>
<reference anchor="Unicode-UAX15" target="https://www.unicode.org/reports <seriesInfo name="DOI" value="10.17487/RFC0952"/>
/tr15/"><front> </reference>
<title>Unicode Standard Annex #15: Unicode Normalization Forms</title> <reference anchor="RFC1035" target="https://www.rfc-editor.org/info/rfc1
<author> 035" quoteTitle="true" derivedAnchor="RFC1035">
<organization>The Unicode Consortium</organization> <front>
</author> <title>Domain names - implementation and specification</title>
<author initials="P.V." surname="Mockapetris" fullname="P.V. Mockape
<date month="September" year="2013"/> tris">
</front> <organization showOnFrontPage="true"/>
</author>
</reference> <date year="1987" month="November"/>
</references> <abstract>
<references title="Informative References"> <t indent="0">This RFC is the revised specification of the protoco
<reference anchor="REST" target="https://www.ics.uci.edu/~fielding/pub l and format used in the implementation of the Domain Name System. It obsoletes
s/dissertation/fielding_dissertation.pdf"> RFC-883. This memo documents the details of the domain name client - server com
<front> munication.</t>
<title>Architectural Styles and the Design of Network-based S </abstract>
oftware Architectures</title> </front>
<author initials="R." surname="Fielding" fullname="Roy Fieldi <seriesInfo name="STD" value="13"/>
ng"> <seriesInfo name="RFC" value="1035"/>
<organization>University of California, Irvine</organizatio <seriesInfo name="DOI" value="10.17487/RFC1035"/>
n> </reference>
</author> <reference anchor="RFC1123" target="https://www.rfc-editor.org/info/rfc1
<date year="2000" /> 123" quoteTitle="true" derivedAnchor="RFC1123">
</front> <front>
<seriesInfo name="Ph.D. Dissertation," value="University of Calif <title>Requirements for Internet Hosts - Application and Support</ti
ornia, Irvine"/> tle>
</reference> <author initials="R." surname="Braden" fullname="R. Braden" role="ed
&RFC3912; itor">
&RFC4007; <organization showOnFrontPage="true"/>
&RFC4290; </author>
&RFC6874; <date year="1989" month="October"/>
&RFC6927; <abstract>
&RFC7942; <t indent="0">This RFC is an official specification for the Intern
&RFC8521; et community. It incorporates by reference, amends, corrects, and supplements t
</references> he primary protocol standards documents relating to hosts. [STANDARDS-TRACK]</t
<section title="Acknowledgments" numbered="no" anchor="acknowledgments">< >
t> </abstract>
</front>
<seriesInfo name="STD" value="3"/>
<seriesInfo name="RFC" value="1123"/>
<seriesInfo name="DOI" value="10.17487/RFC1123"/>
</reference>
<reference anchor="RFC1166" target="https://www.rfc-editor.org/info/rfc1
166" quoteTitle="true" derivedAnchor="RFC1166">
<front>
<title>Internet numbers</title>
<author initials="S." surname="Kirkpatrick" fullname="S. Kirkpatrick
">
<organization showOnFrontPage="true"/>
</author>
<author initials="M.K." surname="Stahl" fullname="M.K. Stahl">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Recker" fullname="M. Recker">
<organization showOnFrontPage="true"/>
</author>
<date year="1990" month="July"/>
<abstract>
<t indent="0">This memo is a status report on the network numbers
and autonomous system numbers used in the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="1166"/>
<seriesInfo name="DOI" value="10.17487/RFC1166"/>
</reference>
<reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2
119" quoteTitle="true" derivedAnchor="RFC2119">
<front>
<title>Key words for use in RFCs to Indicate Requirement Levels</tit
le>
<author initials="S." surname="Bradner" fullname="S. Bradner">
<organization showOnFrontPage="true"/>
</author>
<date year="1997" month="March"/>
<abstract>
<t indent="0">In many standards track documents several words are
used to signify the requirements in the specification. These words are often ca
pitalized. This document defines these words as they should be interpreted in IE
TF documents. This document specifies an Internet Best Current Practices for th
e Internet Community, and requests discussion and suggestions for improvements.<
/t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="2119"/>
<seriesInfo name="DOI" value="10.17487/RFC2119"/>
</reference>
<reference anchor="RFC3986" target="https://www.rfc-editor.org/info/rfc3
986" quoteTitle="true" derivedAnchor="RFC3986">
<front>
<title>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials="T." surname="Berners-Lee" fullname="T. Berners-Lee
">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Fielding" fullname="R. Fielding">
<organization showOnFrontPage="true"/>
</author>
<author initials="L." surname="Masinter" fullname="L. Masinter">
<organization showOnFrontPage="true"/>
</author>
<date year="2005" month="January"/>
<abstract>
<t indent="0">A Uniform Resource Identifier (URI) is a compact seq
uence of characters that identifies an abstract or physical resource. This spec
ification defines the generic URI syntax and a process for resolving URI referen
ces that might be in relative form, along with guidelines and security considera
tions for the use of URIs on the Internet. The URI syntax defines a grammar tha
t is a superset of all valid URIs, allowing an implementation to parse the commo
n components of a URI reference without knowing the scheme-specific requirements
of every possible identifier. This specification does not define a generative
grammar for URIs; that task is performed by the individual specifications of eac
h URI scheme. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="66"/>
<seriesInfo name="RFC" value="3986"/>
<seriesInfo name="DOI" value="10.17487/RFC3986"/>
</reference>
<reference anchor="RFC4291" target="https://www.rfc-editor.org/info/rfc4
291" quoteTitle="true" derivedAnchor="RFC4291">
<front>
<title>IP Version 6 Addressing Architecture</title>
<author initials="R." surname="Hinden" fullname="R. Hinden">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Deering" fullname="S. Deering">
<organization showOnFrontPage="true"/>
</author>
<date year="2006" month="February"/>
<abstract>
<t indent="0">This specification defines the addressing architectu
re of the IP Version 6 (IPv6) protocol. The document includes the IPv6 addressi
ng model, text representations of IPv6 addresses, definition of IPv6 unicast add
resses, anycast addresses, and multicast addresses, and an IPv6 node's required
addresses.</t>
<t indent="0">This document obsoletes RFC 3513, "IP Version 6 Addr
essing Architecture". [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4291"/>
<seriesInfo name="DOI" value="10.17487/RFC4291"/>
</reference>
<reference anchor="RFC4632" target="https://www.rfc-editor.org/info/rfc4
632" quoteTitle="true" derivedAnchor="RFC4632">
<front>
<title>Classless Inter-domain Routing (CIDR): The Internet Address A
ssignment and Aggregation Plan</title>
<author initials="V." surname="Fuller" fullname="V. Fuller">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Li" fullname="T. Li">
<organization showOnFrontPage="true"/>
</author>
<date year="2006" month="August"/>
<abstract>
<t indent="0">This memo discusses the strategy for address assignm
ent of the existing 32-bit IPv4 address space with a view toward conserving the
address space and limiting the growth rate of global routing state. This documen
t obsoletes the original Classless Inter-domain Routing (CIDR) spec in RFC 1519,
with changes made both to clarify the concepts it introduced and, after more th
an twelve years, to update the Internet community on the results of deploying th
e technology described. This document specifies an Internet Best Current Practi
ces for the Internet Community, and requests discussion and suggestions for impr
ovements.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="122"/>
<seriesInfo name="RFC" value="4632"/>
<seriesInfo name="DOI" value="10.17487/RFC4632"/>
</reference>
<reference anchor="RFC4918" target="https://www.rfc-editor.org/info/rfc4
918" quoteTitle="true" derivedAnchor="RFC4918">
<front>
<title>HTTP Extensions for Web Distributed Authoring and Versioning
(WebDAV)</title>
<author initials="L." surname="Dusseault" fullname="L. Dusseault" ro
le="editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2007" month="June"/>
<abstract>
<t indent="0">Web Distributed Authoring and Versioning (WebDAV) co
nsists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for
the management of resource properties, creation and management of resource coll
ections, URL namespace manipulation, and resource locking (collision avoidance).
</t>
<t indent="0">RFC 2518 was published in February 1999, and this sp
ecification obsoletes RFC 2518 with minor revisions mostly due to interoperabili
ty experience. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4918"/>
<seriesInfo name="DOI" value="10.17487/RFC4918"/>
</reference>
<reference anchor="RFC5396" target="https://www.rfc-editor.org/info/rfc5
396" quoteTitle="true" derivedAnchor="RFC5396">
<front>
<title>Textual Representation of Autonomous System (AS) Numbers</tit
le>
<author initials="G." surname="Huston" fullname="G. Huston">
<organization showOnFrontPage="true"/>
</author>
<author initials="G." surname="Michaelson" fullname="G. Michaelson">
<organization showOnFrontPage="true"/>
</author>
<date year="2008" month="December"/>
<abstract>
<t indent="0">A textual representation for Autonomous System (AS)
numbers is defined as the decimal value of the AS number. This textual represen
tation is to be used by all documents, systems, and user interfaces referring to
AS numbers. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5396"/>
<seriesInfo name="DOI" value="10.17487/RFC5396"/>
</reference>
<reference anchor="RFC5730" target="https://www.rfc-editor.org/info/rfc5
730" quoteTitle="true" derivedAnchor="RFC5730">
<front>
<title>Extensible Provisioning Protocol (EPP)</title>
<author initials="S." surname="Hollenbeck" fullname="S. Hollenbeck">
<organization showOnFrontPage="true"/>
</author>
<date year="2009" month="August"/>
<abstract>
<t indent="0">This document describes an application-layer client-
server protocol for the provisioning and management of objects stored in a share
d central repository. Specified in XML, the protocol defines generic object man
agement operations and an extensible framework that maps protocol operations to
objects. This document includes a protocol specification, an object mapping tem
plate, and an XML media type registration. This document obsoletes RFC 4930. [
STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="69"/>
<seriesInfo name="RFC" value="5730"/>
<seriesInfo name="DOI" value="10.17487/RFC5730"/>
</reference>
<reference anchor="RFC5733" target="https://www.rfc-editor.org/info/rfc5
733" quoteTitle="true" derivedAnchor="RFC5733">
<front>
<title>Extensible Provisioning Protocol (EPP) Contact Mapping</title
>
<author initials="S." surname="Hollenbeck" fullname="S. Hollenbeck">
<organization showOnFrontPage="true"/>
</author>
<date year="2009" month="August"/>
<abstract>
<t indent="0">This document describes an Extensible Provisioning P
rotocol (EPP) mapping for the provisioning and management of individual or organ
izational social information identifiers (known as "contacts") stored in a share
d central repository. Specified in Extensible Markup Language (XML), the mappin
g defines EPP command syntax and semantics as applied to contacts. This documen
t obsoletes RFC 4933. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="STD" value="69"/>
<seriesInfo name="RFC" value="5733"/>
<seriesInfo name="DOI" value="10.17487/RFC5733"/>
</reference>
<reference anchor="RFC5890" target="https://www.rfc-editor.org/info/rfc5
890" quoteTitle="true" derivedAnchor="RFC5890">
<front>
<title>Internationalized Domain Names for Applications (IDNA): Defin
itions and Document Framework</title>
<author initials="J." surname="Klensin" fullname="J. Klensin">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="August"/>
<abstract>
<t indent="0">This document is one of a collection that, together,
describe the protocol and usage context for a revision of Internationalized Dom
ain Names for Applications (IDNA), superseding the earlier version. It describe
s the document collection and provides definitions and other material that are c
ommon to the set. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5890"/>
<seriesInfo name="DOI" value="10.17487/RFC5890"/>
</reference>
<reference anchor="RFC5891" target="https://www.rfc-editor.org/info/rfc5
891" quoteTitle="true" derivedAnchor="RFC5891">
<front>
<title>Internationalized Domain Names in Applications (IDNA): Protoc
ol</title>
<author initials="J." surname="Klensin" fullname="J. Klensin">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="August"/>
<abstract>
<t indent="0">This document is the revised protocol definition for
Internationalized Domain Names (IDNs). The rationale for changes, the relation
ship to the older specification, and important terminology are provided in other
documents. This document specifies the protocol mechanism, called Internationa
lized Domain Names in Applications (IDNA), for registering and looking up IDNs i
n a way that does not require changes to the DNS itself. IDNA is only meant for
processing domain names, not free text. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5891"/>
<seriesInfo name="DOI" value="10.17487/RFC5891"/>
</reference>
<reference anchor="RFC5952" target="https://www.rfc-editor.org/info/rfc5
952" quoteTitle="true" derivedAnchor="RFC5952">
<front>
<title>A Recommendation for IPv6 Address Text Representation</title>
<author initials="S." surname="Kawamura" fullname="S. Kawamura">
<organization showOnFrontPage="true"/>
</author>
<author initials="M." surname="Kawashima" fullname="M. Kawashima">
<organization showOnFrontPage="true"/>
</author>
<date year="2010" month="August"/>
<abstract>
<t indent="0">As IPv6 deployment increases, there will be a dramat
ic increase in the need to use IPv6 addresses in text. While the IPv6 address a
rchitecture in Section 2.2 of RFC 4291 describes a flexible model for text repre
sentation of an IPv6 address, this flexibility has been causing problems for ope
rators, system engineers, and users. This document defines a canonical textual
representation format. It does not define a format for internal storage, such a
s within an application or database. It is expected that the canonical format w
ill be followed by humans and systems when representing IPv6 addresses as text,
but all implementations must accept and be able to handle any legitimate RFC 429
1 format. [STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="5952"/>
<seriesInfo name="DOI" value="10.17487/RFC5952"/>
</reference>
<reference anchor="RFC7230" target="https://www.rfc-editor.org/info/rfc7
230" quoteTitle="true" derivedAnchor="RFC7230">
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Ro
uting</title>
<author initials="R." surname="Fielding" fullname="R. Fielding" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Reschke" fullname="J. Reschke" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2014" month="June"/>
<abstract>
<t indent="0">The Hypertext Transfer Protocol (HTTP) is a stateles
s application-level protocol for distributed, collaborative, hypertext informati
on systems. This document provides an overview of HTTP architecture and its ass
ociated terminology, defines the "http" and "https" Uniform Resource Identifier
(URI) schemes, defines the HTTP/1.1 message syntax and parsing requirements, and
describes related security concerns for implementations.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7230"/>
<seriesInfo name="DOI" value="10.17487/RFC7230"/>
</reference>
<reference anchor="RFC7231" target="https://www.rfc-editor.org/info/rfc7
231" quoteTitle="true" derivedAnchor="RFC7231">
<front>
<title>Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content
</title>
<author initials="R." surname="Fielding" fullname="R. Fielding" role
="editor">
<organization showOnFrontPage="true"/>
</author>
<author initials="J." surname="Reschke" fullname="J. Reschke" role="
editor">
<organization showOnFrontPage="true"/>
</author>
<date year="2014" month="June"/>
<abstract>
<t indent="0">The Hypertext Transfer Protocol (HTTP) is a stateles
s \%application- level protocol for distributed, collaborative, hypertext inform
ation systems. This document defines the semantics of HTTP/1.1 messages, as exp
ressed by request methods, request header fields, response status codes, and res
ponse header fields, along with the payload of messages (metadata and body conte
nt) and mechanisms for content negotiation.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7231"/>
<seriesInfo name="DOI" value="10.17487/RFC7231"/>
</reference>
<reference anchor="RFC7480" target="https://www.rfc-editor.org/info/rfc7
480" quoteTitle="true" derivedAnchor="RFC7480">
<front>
<title>HTTP Usage in the Registration Data Access Protocol (RDAP)</t
itle>
<author initials="A." surname="Newton" fullname="A. Newton">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Ellacott" fullname="B. Ellacott">
<organization showOnFrontPage="true"/>
</author>
<author initials="N." surname="Kong" fullname="N. Kong">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="March"/>
<abstract>
<t indent="0">This document is one of a collection that together d
escribes the Registration Data Access Protocol (RDAP). It describes how RDAP is
transported using the Hypertext Transfer Protocol (HTTP). RDAP is a successor
protocol to the very old WHOIS protocol. The purpose of this document is to cla
rify the use of standard HTTP mechanisms for this application.</t>
</abstract>
</front>
<seriesInfo name="STD" value="95"/>
<seriesInfo name="RFC" value="7480"/>
<seriesInfo name="DOI" value="10.17487/RFC7480"/>
</reference>
<reference anchor="RFC7481" target="https://www.rfc-editor.org/info/rfc7
481" quoteTitle="true" derivedAnchor="RFC7481">
<front>
<title>Security Services for the Registration Data Access Protocol (
RDAP)</title>
<author initials="S." surname="Hollenbeck" fullname="S. Hollenbeck">
<organization showOnFrontPage="true"/>
</author>
<author initials="N." surname="Kong" fullname="N. Kong">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="March"/>
<abstract>
<t indent="0">The Registration Data Access Protocol (RDAP) provide
s "RESTful" web services to retrieve registration metadata from Domain Name and
Regional Internet Registries. This document describes information security serv
ices, including access control, authentication, authorization, availability, dat
a confidentiality, and data integrity for RDAP.</t>
</abstract>
</front>
<seriesInfo name="STD" value="95"/>
<seriesInfo name="RFC" value="7481"/>
<seriesInfo name="DOI" value="10.17487/RFC7481"/>
</reference>
<reference anchor="RFC7484" target="https://www.rfc-editor.org/info/rfc7
484" quoteTitle="true" derivedAnchor="RFC7484">
<front>
<title>Finding the Authoritative Registration Data (RDAP) Service</t
itle>
<author initials="M." surname="Blanchet" fullname="M. Blanchet">
<organization showOnFrontPage="true"/>
</author>
<date year="2015" month="March"/>
<abstract>
<t indent="0">This document specifies a method to find which Regis
tration Data Access Protocol (RDAP) server is authoritative to answer queries fo
r a requested scope, such as domain names, IP addresses, or Autonomous System nu
mbers.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7484"/>
<seriesInfo name="DOI" value="10.17487/RFC7484"/>
</reference>
<reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8
174" quoteTitle="true" derivedAnchor="RFC8174">
<front>
<title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</ti
tle>
<author initials="B." surname="Leiba" fullname="B. Leiba">
<organization showOnFrontPage="true"/>
</author>
<date year="2017" month="May"/>
<abstract>
<t indent="0">RFC 2119 specifies common key words that may be used
in protocol specifications. This document aims to reduce the ambiguity by cla
rifying that only UPPERCASE usage of the key words have the defined special mea
nings.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="14"/>
<seriesInfo name="RFC" value="8174"/>
<seriesInfo name="DOI" value="10.17487/RFC8174"/>
</reference>
<reference anchor="RFC8499" target="https://www.rfc-editor.org/info/rfc8
499" quoteTitle="true" derivedAnchor="RFC8499">
<front>
<title>DNS Terminology</title>
<author initials="P." surname="Hoffman" fullname="P. Hoffman">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Sullivan" fullname="A. Sullivan">
<organization showOnFrontPage="true"/>
</author>
<author initials="K." surname="Fujiwara" fullname="K. Fujiwara">
<organization showOnFrontPage="true"/>
</author>
<date year="2019" month="January"/>
<abstract>
<t indent="0">The Domain Name System (DNS) is defined in literally
dozens of different RFCs. The terminology used by implementers and developers
of DNS protocols, and by operators of DNS systems, has sometimes changed in the
decades since the DNS was first defined. This document gives current definition
s for many of the terms used in the DNS in a single document.</t>
<t indent="0">This document obsoletes RFC 7719 and updates RFC 230
8.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="219"/>
<seriesInfo name="RFC" value="8499"/>
<seriesInfo name="DOI" value="10.17487/RFC8499"/>
</reference>
<reference anchor="RFC9083" target="https://www.rfc-editor.org/info/rfc9
083" quoteTitle="true" derivedAnchor="RFC9083">
<front>
<title>JSON Responses for the Registration Data Access Protocol (RDA
P)</title>
<author initials="S" surname="Hollenbeck" fullname="Scott Hollenbeck
">
<organization showOnFrontPage="true"/>
</author>
<author initials="A" surname="Newton" fullname="Andrew Newton">
<organization showOnFrontPage="true"/>
</author>
<date month="June" year="2021"/>
</front>
<seriesInfo name="STD" value="95"/>
<seriesInfo name="RFC" value="9083"/>
<seriesInfo name="DOI" value="10.17487/RFC9083"/>
</reference>
<reference anchor="Unicode-UAX15" target="https://www.unicode.org/report
s/tr15/" quoteTitle="true" derivedAnchor="Unicode-UAX15">
<front>
<title>Unicode Standard Annex #15: Unicode Normalization Forms</titl
e>
<author>
<organization showOnFrontPage="true">The Unicode Consortium</organ
ization>
</author>
<date month="September" year="2013"/>
</front>
</reference>
</references>
<references pn="section-9.2">
<name slugifiedName="name-informative-references">Informative References
</name>
<reference anchor="REST" target="https://www.ics.uci.edu/~fielding/pubs/
dissertation/fielding_dissertation.pdf" quoteTitle="true" derivedAnchor="REST">
<front>
<title>Architectural Styles and the Design of Network-based Software
Architectures</title>
<author initials="R." surname="Fielding" fullname="Roy Fielding">
<organization showOnFrontPage="true">University of California, Irv
ine</organization>
</author>
<date year="2000"/>
</front>
<seriesInfo name="Ph.D. Dissertation," value="University of California
, Irvine"/>
</reference>
<reference anchor="RFC3912" target="https://www.rfc-editor.org/info/rfc3
912" quoteTitle="true" derivedAnchor="RFC3912">
<front>
<title>WHOIS Protocol Specification</title>
<author initials="L." surname="Daigle" fullname="L. Daigle">
<organization showOnFrontPage="true"/>
</author>
<date year="2004" month="September"/>
<abstract>
<t indent="0">This document updates the specification of the WHOIS
protocol, thereby obsoleting RFC 954. The update is intended to remove the mat
erial from RFC 954 that does not have to do with the on-the-wire protocol, and i
s no longer applicable in today's Internet. This document does not attempt to c
hange or update the protocol per se, or document other uses of the protocol that
have come into existence since the publication of RFC 954. [STANDARDS-TRACK]</
t>
</abstract>
</front>
<seriesInfo name="RFC" value="3912"/>
<seriesInfo name="DOI" value="10.17487/RFC3912"/>
</reference>
<reference anchor="RFC4007" target="https://www.rfc-editor.org/info/rfc4
007" quoteTitle="true" derivedAnchor="RFC4007">
<front>
<title>IPv6 Scoped Address Architecture</title>
<author initials="S." surname="Deering" fullname="S. Deering">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Haberman" fullname="B. Haberman">
<organization showOnFrontPage="true"/>
</author>
<author initials="T." surname="Jinmei" fullname="T. Jinmei">
<organization showOnFrontPage="true"/>
</author>
<author initials="E." surname="Nordmark" fullname="E. Nordmark">
<organization showOnFrontPage="true"/>
</author>
<author initials="B." surname="Zill" fullname="B. Zill">
<organization showOnFrontPage="true"/>
</author>
<date year="2005" month="March"/>
<abstract>
<t indent="0">This document specifies the architectural characteri
stics, expected behavior, textual representation, and usage of IPv6 addresses of
different scopes. According to a decision in the IPv6 working group, this docu
ment intentionally avoids the syntax and usage of unicast site-local addresses.
[STANDARDS-TRACK]</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4007"/>
<seriesInfo name="DOI" value="10.17487/RFC4007"/>
</reference>
<reference anchor="RFC4290" target="https://www.rfc-editor.org/info/rfc4
290" quoteTitle="true" derivedAnchor="RFC4290">
<front>
<title>Suggested Practices for Registration of Internationalized Dom
ain Names (IDN)</title>
<author initials="J." surname="Klensin" fullname="J. Klensin">
<organization showOnFrontPage="true"/>
</author>
<date year="2005" month="December"/>
<abstract>
<t indent="0">This document explores the issues in the registratio
n of internationalized domain names (IDNs). The basic IDN definition allows a v
ery large number of possible characters in domain names, and this richness may l
ead to serious user confusion about similar-looking names. To avoid this confus
ion, the IDN registration process must impose rules that disallow some otherwise
-valid name combinations. This document suggests a set of mechanisms that regist
ries might use to define and implement such rules for a broad range of languages
, including adaptation of methods developed for Chinese, Japanese, and Korean do
main names. This memo provides information for the Internet community.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="4290"/>
<seriesInfo name="DOI" value="10.17487/RFC4290"/>
</reference>
<reference anchor="RFC6874" target="https://www.rfc-editor.org/info/rfc6
874" quoteTitle="true" derivedAnchor="RFC6874">
<front>
<title>Representing IPv6 Zone Identifiers in Address Literals and Un
iform Resource Identifiers</title>
<author initials="B." surname="Carpenter" fullname="B. Carpenter">
<organization showOnFrontPage="true"/>
</author>
<author initials="S." surname="Cheshire" fullname="S. Cheshire">
<organization showOnFrontPage="true"/>
</author>
<author initials="R." surname="Hinden" fullname="R. Hinden">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="February"/>
<abstract>
<t indent="0">This document describes how the zone identifier of a
n IPv6 scoped address, defined as &lt;zone_id&gt; in the IPv6 Scoped Address Arc
hitecture (RFC 4007), can be represented in a literal IPv6 address and in a Unif
orm Resource Identifier that includes such a literal address. It updates the UR
I Generic Syntax specification (RFC 3986) accordingly.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6874"/>
<seriesInfo name="DOI" value="10.17487/RFC6874"/>
</reference>
<reference anchor="RFC6927" target="https://www.rfc-editor.org/info/rfc6
927" quoteTitle="true" derivedAnchor="RFC6927">
<front>
<title>Variants in Second-Level Names Registered in Top-Level Domain
s</title>
<author initials="J." surname="Levine" fullname="J. Levine">
<organization showOnFrontPage="true"/>
</author>
<author initials="P." surname="Hoffman" fullname="P. Hoffman">
<organization showOnFrontPage="true"/>
</author>
<date year="2013" month="May"/>
<abstract>
<t indent="0">Internationalized Domain Names for Applications (IDN
A) provides a method to map a subset of names written in Unicode into the DNS. B
ecause of Unicode decisions, appearance, language and writing system conventions
, and historical reasons, it often has been asserted that there is more than one
way to write what competent readers and writers think of as the same host name;
these different ways of writing are often called "variants". (The authors note
that there are many conflicting definitions for the term "variant" in the IDNA
community.) This document surveys the approaches that top-level domains have ta
ken to the registration and provisioning of domain names that have variants. Th
is document is not a product of the IETF, does not propose any method to make va
riants work "correctly", and is not an introduction to internationalization or I
DNA.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="6927"/>
<seriesInfo name="DOI" value="10.17487/RFC6927"/>
</reference>
<reference anchor="RFC8521" target="https://www.rfc-editor.org/info/rfc8
521" quoteTitle="true" derivedAnchor="RFC8521">
<front>
<title>Registration Data Access Protocol (RDAP) Object Tagging</titl
e>
<author initials="S." surname="Hollenbeck" fullname="S. Hollenbeck">
<organization showOnFrontPage="true"/>
</author>
<author initials="A." surname="Newton" fullname="A. Newton">
<organization showOnFrontPage="true"/>
</author>
<date year="2018" month="November"/>
<abstract>
<t indent="0">The Registration Data Access Protocol (RDAP) include
s a method that can be used to identify the authoritative server for processing
domain name, IP address, and autonomous system number queries. The method does
not describe how to identify the authoritative server for processing other RDAP
query types, such as entity queries. This limitation exists because the identif
iers associated with these query types are typically unstructured. This documen
t updates RFC 7484 by describing an operational practice that can be used to add
structure to RDAP identifiers and that makes it possible to identify the author
itative server for additional RDAP queries.</t>
</abstract>
</front>
<seriesInfo name="BCP" value="221"/>
<seriesInfo name="RFC" value="8521"/>
<seriesInfo name="DOI" value="10.17487/RFC8521"/>
</reference>
</references>
</references>
<section numbered="true" anchor="changes" toc="include" removeInRFC="false"
pn="section-appendix.a">
<name slugifiedName="name-changes-from-rfc-7482">Changes from RFC 7482</na
me>
<ul spacing="normal" bare="false" empty="false" indent="3" pn="section-app
endix.a-1">
<li pn="section-appendix.a-1.1">Addressed known errata.</li>
<li pn="section-appendix.a-1.2">Addressed other reported clarifications
and corrections: IDN, IDNA, and DNR definitions.
Noted that registrars are entities. Added a reference to RFC 8521
to address the bootstrap registry limitation.
Removed extraneous "...". Clarified HTTP query string, search pat
tern, name server search, domain label suffix, and asterisk search.</li>
<li pn="section-appendix.a-1.3">Addressed "The HTTP query string" clarif
ication.</li>
<li pn="section-appendix.a-1.4">Modified coauthor address.</li>
<li pn="section-appendix.a-1.5">Updated references to RFC 7483 to RFC 90
83.</li>
<li pn="section-appendix.a-1.6">Added an IANA Considerations section. Ch
anged references to use HTTPS for targets.</li>
<li pn="section-appendix.a-1.7">Changed "XXXX is a search pattern repres
enting the "FN" property of an entity (such as a contact, registrant, or registr
ar) name as specified in Section 5.1" to "Changed "XXXX is a search pattern repr
esenting the "fn" property of an entity (such as a contact, registrant, or regis
trar) name as described in Section 5.1".</li>
<li pn="section-appendix.a-1.8">Added acknowledgments.</li>
<li pn="section-appendix.a-1.9">Changed "The intent of the patterns desc
ribed here are to enable queries" to "The intent of the patterns described here
is to enable queries".</li>
<li pn="section-appendix.a-1.10">Changed "the corresponding syntax exten
sion in RFC 6874 <xref target="RFC6874" format="default" sectionFormat="of" deri
vedContent="RFC6874"/> <bcp14>MUST NOT</bcp14> be used, and servers are to ignor
e it if possible" to "the corresponding syntax extension in RFC 6874 <xref targe
t="RFC6874" format="default" sectionFormat="of" derivedContent="RFC6874"/> <bcp1
4>MUST NOT</bcp14> be used, and servers <bcp14>SHOULD</bcp14> ignore it".</li>
<li pn="section-appendix.a-1.11">Changed "Only a single asterisk is allo
wed for a partial string search" to "A partial string search <bcp14>MUST NOT</bc
p14> include more than one asterisk".</li>
<li pn="section-appendix.a-1.12">Changed "Clients should avoid submittin
g a partial match search of Unicode characters where a Unicode character may be
legally combined with another Unicode character or characters" to "Clients <bcp1
4>SHOULD NOT</bcp14> submit a partial match search of Unicode characters where a
Unicode character may be legally combined with another Unicode character or cha
racters".</li>
<li pn="section-appendix.a-1.13">Changed description of nameserver IP ad
dress "search pattern" in Sections <xref target="sect-3.2.1" format="counter" se
ctionFormat="of" derivedContent="3.2.1"/> and <xref target="sect-3.2.2" format="
counter" sectionFormat="of" derivedContent="3.2.2"/>.</li>
<li pn="section-appendix.a-1.14">IESG review feedback: Added "obsoletes
7482" to the headers, Abstract, and Introduction. Changed "IETF standards" to "
IETF specifications" and "Therefore" to "Accordingly" in <xref target="sect-1" f
ormat="default" sectionFormat="of" derivedContent="Section 1"/>. Updated the BCP
14 boilerplate. Added definition of "bootstrap registry" and changed "concatena
ting ... to" to "concatenating ... with" in <xref target="sect-3" format="defaul
t" sectionFormat="of" derivedContent="Section 3"/>. Changed "bitmask length" to
"prefix length" and "2001:db8::0" to "2001:db8::" in <xref target="sect-3.1.1"
format="default" sectionFormat="of" derivedContent="Section 3.1.1"/>. Added "in
contrast to the more generic HTTP query string that admits multiple simultaneou
s parameters" in <xref target="sect-3.2" format="default" sectionFormat="of" der
ivedContent="Section 3.2"/>. Changed "0x002A" to "0x2A" in <xref target="sect-4.
1" format="default" sectionFormat="of" derivedContent="Section 4.1"/>. Clarified
use of HTTP 422 <bcp14>SHOULD</bcp14> in <xref target="sect-4.1" format="defaul
t" sectionFormat="of" derivedContent="Section 4.1"/>.</li>
</ul>
</section>
<section numbered="false" anchor="acknowledgments" toc="include" removeInRFC
="false" pn="section-appendix.b">
<name slugifiedName="name-acknowledgments">Acknowledgments</name>
<t indent="0" pn="section-appendix.b-1">
This document is derived from original work on RIR query formats This document is derived from original work on RIR query formats
developed by Byron J. Ellacott of APNIC, Arturo L. Servin of LACNIC, developed by <contact fullname="Byron J. Ellacott"/> of APNIC, <contact fulln
Kaveh Ranjbar of the RIPE NCC, and Andrew L. Newton of ARIN. ame="Arturo L. Servin"/> of LACNIC,
<contact fullname="Kaveh Ranjbar"/> of the RIPE NCC, and <contact fullname="A
ndrew L. Newton"/> of ARIN.
Additionally, this document incorporates DNR query formats originally Additionally, this document incorporates DNR query formats originally
described by Francisco Arias and Steve Sheng of ICANN and Scott described by <contact fullname="Francisco Arias"/> and <contact fullname="Ste
Hollenbeck of Verisign Labs.</t> ve Sheng"/> of ICANN and <contact fullname="Scott Hollenbeck"/>
of Verisign Labs.</t>
<t> <t indent="0" pn="section-appendix.b-2">
The authors would like to acknowledge the following individuals for The authors would like to acknowledge the following individuals for
their contributions to this document: Francisco Arias, Marc Blanchet, their contributions to this document: <contact fullname="Francisco Arias"/>,
Ernie Dainow, Jean-Philippe Dionne, Byron J. Ellacott, Behnam <contact fullname="Marc Blanchet"/>,
Esfahbod, John Klensin, John Levine, Edward Lewis, Mario Loffredo, Patrick Me <contact fullname="Ernie Dainow"/>, <contact fullname="Jean-Philippe Dionne"/
vzek, Mark Nottingham, >, <contact fullname="Byron J. Ellacott"/>,
Kaveh Ranjbar, Arturo L. Servin, Steve Sheng, Jasdip Singh, and Andrew Sulliv <contact fullname="Behnam Esfahbod"/>, <contact fullname="John Klensin"/>, <c
an.</t> ontact fullname="John Levine"/>, <contact fullname="Edward Lewis"/>, <contact fu
llname="Mario Loffredo"/>, <contact fullname="Patrick Mevzek"/>, <contact fullna
</section> me="Mark Nottingham"/>,
<contact fullname="Kaveh Ranjbar"/>, <contact fullname="Arturo L. Servin"/>,
<section title="Changes from RFC 7482" numbered="no" anchor="changes"><t> <contact fullname="Steve Sheng"/>, <contact fullname="Jasdip Singh"/>, and <cont
<list style="hanging"> act fullname="Andrew Sullivan"/>.</t>
<t hangText="00:">Initial version ported from RFC 7482. Added Impleme </section>
ntation Status section. Addressed known errata.</t> <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc
<t hangText="01:">Addressed other reported clarifications and correct ="include" pn="section-appendix.c">
ions: IDN/IDNA definition, note that registrars are entities, <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
definition of "DNR", RFC 8521 to address bootstrap registry limit <author fullname="Scott Hollenbeck" initials="S." surname="Hollenbeck">
ation, removal of extraneous "...", HTTP query string clarification, <organization showOnFrontPage="true">Verisign Labs</organization>
search pattern clarification, name server search clarification, d <address>
omain label suffix and asterisk search clarification.</t> <postal>
<t hangText="02:">Addressed "The HTTP query string" clarification.</t <street>12061 Bluemont Way</street>
> <city>Reston</city>
<t hangText="03:">Modified co-author address.</t> <region>VA</region>
<t hangText="04:">Updated references to 7483 to 7483bis Internet-Draf <code>20190</code>
t. Updated "Change Log" to "Changes from RFC 7482". Added more detail to the cha <country>United States of America</country>
nges made in the -01 version.</t> </postal>
<t hangText="05:">Added an empty IANA Considerations section to s <email>shollenbeck@verisign.com</email>
atisfy IDNits. Changed references to use HTTPS for targets. Split ARIN and NicIn <uri>https://www.verisignlabs.com/</uri>
fo implementation status into two sections.</t> </address>
<t hangText="06:">Changed "XXXX is a search pattern representing </author>
the "FN" property of an entity (such as a contact, registrant, or registrar) nam <author fullname="Andy Newton" initials="A." surname="Newton">
e as specified in Section 5.1" to "Changed "XXXX is a search pattern representin <organization abbrev="AWS" showOnFrontPage="true">Amazon Web Services, I
g the "fn" property of an entity (such as a contact, registrant, or registrar) n nc.</organization>
ame as described in Section 5.1".</t> <address>
<t hangText="00:">Initial working group version. Added acknowledgment <postal>
s.</t> <street>13200 Woodland Park Road</street>
<t hangText="01:">Changed "The intent of the patterns described here <city>Herndon</city>
are to enable queries" to "The intent of the patterns described here is to enabl <region>VA</region>
e queries". Changed "the corresponding syntax extension in RFC 6874 [RFC6874] MU <code>20171</code>
ST NOT be used, and servers are to ignore it if possible" to "the corresponding <country>United States of America</country>
syntax extension in RFC 6874 [RFC6874] MUST NOT be used, and servers SHOULD igno </postal>
re it". Changed "Only a single asterisk is allowed for a partial string search" <email>andy@hxr.us</email>
to "A partial string search MUST NOT include more than one asterisk". Changed "C </address>
lients should avoid submitting a partial match search of Unicode characters wher </author>
e a Unicode character may be legally combined with another Unicode character or </section>
characters" to "Clients SHOULD NOT submit a partial match search of Unicode char </back>
acters where a Unicode character may be legally combined with another Unicode ch </rfc>
aracter or characters".</t>
<t hangText="02:">Changed description of nameserver IP address "searc
h pattern" in Sections 3.2.1 and 3.2.2.</t>
<t hangText="03:">IESG review feedback: Added "obsoletes 7482" to the
headers, Abstract, and Introduction. Changed "IETF standards" to "IETF specific
ations" and "Therefore" to "Accordingly" in Section 1. Updated BCP14 template. A
dded definition of "bootstrap registry" and changed "concatenating ... to" to "c
oncatenating ... with" in Section 3. Changed "bitmask length" to "prefix length"
and "2001:db8::0" to "2001:db8::" in Section 3.1.1. Added "in contrast to the m
ore generic HTTP query string that admits multiple simultaneous parameters" in S
ection 3.2. Changed "0x002A" to "0x2A" in Section 4.1. Clarified use of HTTP 422
SHOULD in Section 4.1.</t>
</list>
</t>
</section>
</back>
</rfc>
 End of changes. 130 change blocks. 
857 lines changed or deleted 1654 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/