RDAP Extensions
draft-ietf-regext-rdap-extensions-15
| Document | Type | Active Internet-Draft (regext WG) | |
|---|---|---|---|
| Authors | Andy Newton , Jasdip Singh , Tom Harrison | ||
| Last updated | 2026-08-13 | ||
| Replaces | draft-newton-regext-rdap-extensions | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | Proposed Standard | ||
| Formats | |||
| Reviews |
GENART Early review
by Sue Hares
On the right track
HTTPDIR Early Review due 2026-03-13
Incomplete
|
||
| Additional resources |
GitHub Repository
Mailing list discussion |
||
| Stream | WG state | WG Document | |
| Document shepherd | Paweł Kowalik | ||
| IESG | IESG state | I-D Exists | |
| Consensus boilerplate | Yes | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | kowalik@denic.de |
draft-ietf-regext-rdap-extensions-15
Registration Protocols Extensions (regext) A. Newton
Internet-Draft ICANN
Updates: 7480, 9082, 9083 (if approved) J. Singh
Intended status: Standards Track ARIN
Expires: 14 February 2027 T. Harrison
APNIC
13 August 2026
RDAP Extensions
draft-ietf-regext-rdap-extensions-15
Abstract
This document describes and clarifies the usage of extensions in
RDAP.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 14 February 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Newton, et al. Expires 14 February 2027 [Page 1]
Internet-Draft rdap-extensions August 2026
Table of Contents
1. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Summary of Updates . . . . . . . . . . . . . . . . . . . 3
1.2. Document Terms . . . . . . . . . . . . . . . . . . . . . 4
2. Extension Identifiers . . . . . . . . . . . . . . . . . . . . 4
2.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.1. Profile Extensions . . . . . . . . . . . . . . . . . 5
2.1.2. Multiple Identifiers in Single Extension . . . . . . 6
2.2. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Usage in Requests . . . . . . . . . . . . . . . . . . . . 9
2.3.1. Usage in Paths . . . . . . . . . . . . . . . . . . . 9
2.3.2. Usage in Query Parameters . . . . . . . . . . . . . . 10
2.4. Usage in Responses . . . . . . . . . . . . . . . . . . . 10
2.4.1. Basic Requirements . . . . . . . . . . . . . . . . . 10
2.4.2. Child JSON Values . . . . . . . . . . . . . . . . . . 11
2.4.3. Object Classes in Extensions . . . . . . . . . . . . 12
2.4.4. Search Results in Extensions . . . . . . . . . . . . 13
2.4.5. rdapConformance Population . . . . . . . . . . . . . 14
2.4.6. Camel Casing . . . . . . . . . . . . . . . . . . . . 15
3. Usage with HTTP . . . . . . . . . . . . . . . . . . . . . . . 15
4. Extension Implementer Considerations . . . . . . . . . . . . 15
4.1. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 15
5. Extension Author Considerations . . . . . . . . . . . . . . . 16
5.1. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 16
5.2. Referrals . . . . . . . . . . . . . . . . . . . . . . . . 17
5.3. Extensions Referencing Other Extensions . . . . . . . . . 17
5.4. Extension Versioning . . . . . . . . . . . . . . . . . . 18
5.4.1. Breaking Changes in Revisions . . . . . . . . . . . . 19
5.4.2. Non-breaking Changes in Revisions . . . . . . . . . . 20
5.4.3. Considerations for Superseders . . . . . . . . . . . 20
5.4.4. Evolving Extensions without Describing Changes . . . 23
5.5. Extension Specification Content . . . . . . . . . . . . . 23
5.6. Extension Definitions . . . . . . . . . . . . . . . . . . 24
6. Existing Extension Registrations . . . . . . . . . . . . . . 24
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25
7.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 25
7.1.1. Deprecation Date . . . . . . . . . . . . . . . . . . 25
7.1.2. Registration Procedures . . . . . . . . . . . . . . . 26
7.1.3. Expert Review . . . . . . . . . . . . . . . . . . . . 26
7.2. RDAP JSON Values Registry . . . . . . . . . . . . . . . . 27
8. Operational Considerations . . . . . . . . . . . . . . . . . 28
8.1. Interpretation of IANA Registry Values . . . . . . . . . 28
8.2. Referral and Redirect Loops . . . . . . . . . . . . . . . 28
9. Security Considerations . . . . . . . . . . . . . . . . . . . 29
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 29
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 29
Newton, et al. Expires 14 February 2027 [Page 2]
Internet-Draft rdap-extensions August 2026
12.1. Normative References . . . . . . . . . . . . . . . . . . 29
12.2. Informative References . . . . . . . . . . . . . . . . . 31
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32
1. Background
The Registration Data Access Protocol (RDAP) defines a uniform
protocol for accessing data from Internet operations registries,
specifically Domain Name Registries (DNRs), Regional Internet
Registries (RIRs), and other registries in the Internet Number
Registry System (INRS). RDAP queries are defined in [RFC9082] and
RDAP responses are defined in [RFC9083].
RDAP contains a means to define extensions for queries not found in
[RFC9082] and responses not found in [RFC9083]. RDAP extensions are
also described in [RFC7480]. This document describes the
requirements for RDAP extension definition and use, clarifying
ambiguities and defining additional semantics and options that were
previously implicit or under-specified, and places some constraints
on the definition of RDAP extensions to prevent collisions with
various extension mechanisms.
As deployed, RDAP is an ecosystem of servers operated by separate
authorities of information, where information is interlinked from one
authority to another. Bootstrap servers issue HTTP redirects to
authoritative TLD and RIR servers, and those servers may directly
refer to information held by domain registrars or other Internet
Number registries. Each redirect and referral must be correctly
interpreted and followed by a client. Therefore, RDAP extensions
must be constructed with regard to the whole ecosystem, and be
specified in such a manner as to accommodate these interconnections
and the various paths and mechanisms used by clients to navigate
them.
1.1. Summary of Updates
This document updates [RFC7480], [RFC9082], and [RFC9083] for the
purposes of constraining how extensions are defined and interpreted.
This document does not update any core RDAP requests or responses nor
does it update or obsolete any existing RDAP extensions. The updates
in this document should require no changes to either client or server
implementations.
This document describes the following methods for extending RDAP by
registered extensions:
Newton, et al. Expires 14 February 2027 [Page 3]
Internet-Draft rdap-extensions August 2026
1. JSON Names - The most common extension point for RDAP is the
definition of new JSON names. Guidance for JSON names is
provided in this document with regard to [RFC7480] and [RFC9083].
2. URL Paths - New lookups and searches are defined using URL paths.
This document clarifies the practice as described in [RFC9082].
3. Query Strings and Parameters - Many queries use URL query strings
and parameters to scope and/or enhance RDAP results. This
document clarifies the practice as described in [RFC9082].
4. HTTP Headers - Some extensions may use HTTP headers or header
parameters not explicitly enumerated by [RFC7480].
5. HTTP Status Codes - Some extensions may use HTTP status codes not
explicitly enumerated by [RFC7480].
6. Media Type Parameters - Some extensions may define additional
media type parameters for the "application/rdap+json" media type
(Section 10.1 of [RFC9083]).
7. Object Classes - Extensions may define new types of objects to be
queried. This document clarifies this method as described in
[RFC9082] and [RFC9083].
Additionally, this document updates the IANA registry practices for
RDAP. See Section 7.
1.2. Document Terms
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. Extension Identifiers
2.1. Purpose
Section 6 of [RFC7480] describes the identifier used to signify RDAP
extensions and the IANA registry ([rdap-extensions]) into which RDAP
extensions are to be registered.
When in use in RDAP, extension identifiers are prepended to URL path
segments, URL query parameters, and JSON object member names. They
are also included in the "rdapConformance" array (Section 4.1 of
[RFC9083]) member of each response that relies on the extension, so
that clients can determine the extensions being used by the server
for that response. The "/help" query returns a response with an
"rdapConformance" member containing the identifiers for all
extensions used by the server.
Newton, et al. Expires 14 February 2027 [Page 4]
Internet-Draft rdap-extensions August 2026
The main purpose of the extension identifier is to act as a
namespace, preventing collisions between elements from different
extensions. Additionally, implementers and operators can use the
extension identifiers to find extension definitions via
[rdap-extensions].
2.1.1. Profile Extensions
While the RDAP extension mechanism was created to extend RDAP queries
and/or responses, extensions can also be used to signal server policy
(for example, specifying the conditions of use for existing response
structures). Extensions that are primarily about signaling server
policy are called "profiles". Profile extensions are often used by a
class of RDAP server operators, such as the [icann-profile] used by
gTLD registries and registrars and the [nro-profile] used by RIRs.
Profile extensions may do the following:
* Specify some specific extensions (and versions thereof) as
required.
* Specify some specific optional queries, object classes, or JSON
structures as required.
* Limit or restrict the values of specific JSON structures.
Some profile extensions exist to denote the usage of values placed
into an IANA registry, such as the IANA RDAP registries, or the usage
of extensions for specifications used in RDAP responses, such as
extended vCard/jCard properties.
For example, an extension may be used to signal desired processing of
a "rel" attribute in a "links" array, where the "rel" value is
registered in the [link-relations]:
Newton, et al. Expires 14 February 2027 [Page 5]
Internet-Draft rdap-extensions August 2026
{
"rdapConformance": [
"rdap_level_0",
"exampleExt"
],
"objectClassName": "domain",
"ldhName": "example.com",
"links": [
{
"value": "https://example.com/domain/example.com",
"href": "https://example.com/sideways_href",
"rel": "sideways",
"type": "application/rdap+json"
}
]
}
Profile extensions leverage the appearance of their identifier in the
"rdapConformance" array to signal to clients that a profile is in
use. Profile extensions that mandate the implementation of another
extension MUST require that the implementers include the extension
identifier for that other extension in the "rdapConformance" array.
[RFC7480] mandates the implementation of HTTPS but does not mandate
its use. Some profile extensions, especially those used by classes
of server operators, specify the required use of HTTPS and disallow
the use of unencrypted HTTP. Similarly, some profile extensions
specify the availability of service over IPv6.
As described above, these characteristics are not exclusive to
profile extensions and may be found in extensions defining new
queries, JSON, and other RDAP extension points (see Section 1.1).
2.1.2. Multiple Identifiers in Single Extension
Extension specifications MAY define more than one extension
identifier. The servers MUST list all extension identifiers used to
generate a response in the "rdapConformance" array. The server MUST
list all supported extension identifiers in the "rdapConformance"
array of a response to a "/help" request.
Newton, et al. Expires 14 February 2027 [Page 6]
Internet-Draft rdap-extensions August 2026
2.2. Syntax
In brief, RDAP extension identifiers start with an alphabetic
character and may contain alphanumeric characters and "_"
(underscore) characters. This formulation was explicitly chosen to
allow compatibility with variable names in programming languages and
transliteration with XML. See Section 6 of [RFC7480] and Section 2.1
of [RFC9083].
RDAP extension identifiers have no explicit structure, and are opaque
insofar as no inner-meaning can be "seen" in them.
RDAP extensions MUST NOT define an extension identifier that may
collide with an existing extension identifier. RDAP extensions MUST
NOT define an extension identifier, which when appended with an
underscore character would be a substring starting from the first
character of an existing extension identifier. Similarly, RDAP
extensions MUST NOT define an extension identifier starting with a
substring of an existing extension identifier appended with an
underscore. For example, if there were a pre-existing identifier of
"example1_bar", another extension could not define the identifier
"example1". Likewise, if there were a pre-existing identifier of
"example1_bar", another extension could not define the identifier
"example1_bar_buzz". However, an extension could define
"exampleThing" if there were a pre-existing definition of
"exampleThingOther", and vice versa.
This document updates the ABNF “name” rule in [RFC7480] to not allow
the use of an underscore character in the RDAP extension identifier.
The revised ABNF [RFC5234] “name” rule is:
name = ALPHA *( ALPHA / DIGIT )
Implementers should be aware that existing extension identifiers do
contain underscore characters.
Extension identifiers containing the word "ietf" in any mixed
capitalization MUST have IETF consensus.
Extension identifiers MUST NOT start with "example" in any mixed
capitalization because these identifiers are reserved for use as
examples in documentation.
Extension identifiers starting with "draft" are reserved for
descriptions of works in-progress and MUST NOT be registered in the
[rdap-extensions] registry.
Newton, et al. Expires 14 February 2027 [Page 7]
Internet-Draft rdap-extensions August 2026
[RFC7480] does not explicitly state that extension identifiers are
case-sensitive. This document clarifies the formulation in [RFC7480]
to explicitly note that extension identifiers are case-sensitive, and
extension identifiers MUST NOT be registered where a new identifier
is a mixed-case version of an existing identifier (see Section 7.1).
For example, given "lunarNIC" is already registered as an identifier,
then a new registration with "lunarNic" (note the lowercase "ic" in
"Nic") would not be allowed.
The [RFC7480] ABNF "name" rule referenced JSON names, where there was
no requirement to include the suffix for JSON members, and
Section 2.1 of [RFC9083] included the language “JSON responses SHOULD
have member names prefixed with a short identifier followed by an
underscore followed by a meaningful name”. This contradiction led to
the use of a bare extension identifier, where a JSON member uses the
extension identifier without the use of an underscore followed by a
meaningful name. That is, the extension identifier is used "bare"
and not appended with an underscore character and subsequent names.
Consider the example in Section 2.4.2. Using the bare extension
identifier pattern, that example could be written as:
{
"rdapConformance": [
"rdap_level_0",
"exampleExt"
],
"objectClassName": "domain",
"ldhName": "example.com",
"remarks":
[
{
"description":
[
"Query the database.",
"JSON replaces the Whois.",
"Structured data flows."
]
}
],
"exampleExt":
{
"firstInitial": "R",
"lastName": "SomePerson"
}
}
Newton, et al. Expires 14 February 2027 [Page 8]
Internet-Draft rdap-extensions August 2026
While [RFC9083] is specific to JSON, the use of a bare extension
identifier also applies to other identifiers of RDAP extensions, such
as query parameters and object class names. Identifiers of an RDAP
extension which need a prefix to avoid name collision with
identifiers of other RDAP extensions or RDAP as specified in
[RFC7480], [RFC9082], and [RFC9083] are referred to as namespaced
identifiers. Prefixed identifiers are clearly syntactically
distinguishable from identifiers defined by the core RDAP
specifications, which provides more flexibility to implementers and
helps with debugging and operational issues.
The syntax for extension elements (JSON member, query parameters,
object class name, HTTP headers, path segments, media type parameter,
etc.) is defined by the "extension-element" ABNF rule:
extension-element = name "_" ALPHA *( ALPHA / DIGIT / "_" )
Implementers should be aware that existing extension elements use
bare extension identifiers.
2.3. Usage in Requests
2.3.1. Usage in Paths
Section 5 of [RFC9082] describes the use of extension identifiers in
formulating URLs for RDAP queries. The extension identifiers are to
be prepended to the path segments they use. For example, if an
extension uses the identifier "exampleExt", then the path segments
used in that extension are prepended with "exampleExt_". If the
"exampleExt" extension defines paths "fizz" and "fazz", the URLs for
this extension would be like so:
https://base.example/exampleExt_fizz
https://base.example/exampleExt_fazz
While [RFC9082] describes the extension identifier as a prepended
string to a path segment, it does not describe the usage of the
extension identifier as a path segment.
Extensions defining new URL paths MUST explicitly define the expected
responses for each new URL path. New URL paths may return existing
object classes or search results as defined in [RFC9083], object
classes or search results defined by the extension (see Section 2.4.3
and Section 2.4.4 below), or object classes or search results from
other extensions.
Newton, et al. Expires 14 February 2027 [Page 9]
Internet-Draft rdap-extensions August 2026
Additionally, RDAP extensions MUST NOT append a path segment to an
existing path segment as this practice increases the likelihood of
collisions with the queries defined by an extension (e.g., extension
"example2" defining "/domain/example2" or "/example1_fazz/example2").
2.3.2. Usage in Query Parameters
Although [RFC9082] describes the use of URL query strings, it does
not define their use with extensions. [RFC7480] instructs servers to
ignore unknown query parameters, where a query parameter is defined
as an explicitly named value in a query string. Therefore, the use
of query parameters, whether prefixed with an extension identifier or
not, is not supported by [RFC9082] and [RFC7480].
Furthermore, [RFC3986] and [RFC9110] do not define the name=value
pair format of a query string. This is defined in [RFC1866].
Despite this, there are several extensions that do specify query
parameters. This document updates [RFC9082] with regard to the use
of RDAP extension identifiers in URL query parameters. Query
parameters are to follow the form for form-urlencoded media type as
defined in [RFC1866].
When an RDAP extension defines query parameters, those query
parameter names MUST be constructed in the same manner as URL path
segments (that is, extension identifier + '_' + parameter name).
See Section 5.1 and Section 5.2 for other guidance on the use of
query parameters, and see Section 9 and Section 10 regarding
constraints on the usage of query parameters.
RDAP extensions MAY define other forms of URL query strings, but they
will be incompatible with RDAP extensions using query parameters and
the searches defined in [RFC9083]. The reverse is also true: RDAP
extensions using query parameters will be incompatible with
extensions using other forms of URL query strings.
2.4. Usage in Responses
2.4.1. Basic Requirements
Section 2 of [RFC9083] describes the use of extension identifiers in
the JSON returned by RDAP servers. Just as in URLs, the extension
identifier is prepended to JSON names to create a namespace so that
the JSON name from one extension will not collide with the JSON name
from another extension.
Newton, et al. Expires 14 February 2027 [Page 10]
Internet-Draft rdap-extensions August 2026
[RFC9083] states: Clients of these JSON responses SHOULD ignore
unrecognized JSON members in responses.
This document updates this guidance: clients MUST ignore unknown JSON
names.
As Section 4.1 of [RFC9083] requires the use of the "rdapConformance"
data structure, and the "objectClassName" string is required of all
object class instances, a complete example based on the example from
[RFC9083] would be:
{
"rdapConformance": [
"rdap_level_0",
"lunarNIC"
],
"objectClassName": "domain",
"handle": "ABC123",
"ldhName": "example.com",
"lunarNIC_beforeOneSmallStep": "TRUE THAT!",
"remarks":
[
{
"description":
[
"She sells sea shells down by the sea shore.",
"Originally written by Terry Sullivan."
]
}
],
"lunarNIC_spaceNotes":
[
"Because space is so vast",
"you must use IPv6."
]
}
2.4.2. Child JSON Values
Prefixing with the extension identifier is not required for children
of a prefixed JSON object defined by an RDAP extension.
The following example shows this use with a JSON object:
Newton, et al. Expires 14 February 2027 [Page 11]
Internet-Draft rdap-extensions August 2026
{
"rdapConformance": [
"rdap_level_0",
"exampleExt"
],
"objectClassName": "domain",
"ldhName": "example.com",
"remarks":
[
{
"description":
[
"Query the database."
"JSON replaces the Whois."
"Structured data flows."
]
}
],
"exampleExt_author":
{
"firstInitial": "R",
"lastName": "SomePerson"
}
}
Here the JSON name "exampleExt_author" will separate the JSON from
other extensions that may have an "author" structure. But the JSON
contained within "exampleExt_author" need not be prepended, as
collision is avoided by the use of "exampleExt_author".
2.4.3. Object Classes in Extensions
As described in [RFC9082] and Section 2.3, an extension may define
new paths in URLs. If the extension describes the behavior of an
RDAP query using that path to return an instance of a new class of
RDAP object, the JSON names are not required to be prepended with the
extension identifier as described in Section 2.4.2. However, the
extension MUST define the value for the "objectClassName" string
which is used by clients to evaluate the type of the response. To
avoid collisions with object classes defined in other extensions, the
value for the "objectClassName" MUST be prepended with the extension
identifier, in the same way as for URL paths, query parameters, and
JSON names:
Newton, et al. Expires 14 February 2027 [Page 12]
Internet-Draft rdap-extensions August 2026
{
"rdapConformance": [
"rdap_level_0",
"exampleExt"
],
"objectClassName": "exampleExt_author",
"author":
{
"firstInitial": "R",
"lastName": "SomePerson"
}
}
Extension authors are encouraged to use the "camel case" style
described in Section 2.4.6.
Though "objectClassName" is a string and [RFC9083] does define one
object class name with a space separator (i.e., "ip network"), this
document disallows further use of a space character in object class
names. Extensions MUST NOT define object class names using the space
character or any other character that requires URL-encoding.
2.4.4. Search Results in Extensions
As described in [RFC9082] and Section 2.3, an extension may define
new paths in URLs. If the extension describes the behavior of an
RDAP query using the path to return an RDAP search result for a new
object class, the JSON name of the search result MUST be prepended
with the extension identifier to avoid collision with search results
defined in other extensions.
If the search result contains object class instances defined by the
extension, each instance MUST have an "objectClassName" string as
defined in Section 2.4.3. For example:
Newton, et al. Expires 14 February 2027 [Page 13]
Internet-Draft rdap-extensions August 2026
{
"rdapConformance": [
"rdap_level_0",
"exampleExt"
],
"exampleExt_authorSearchResult": [
{
"objectClassName": "exampleExt_author",
"author":
{
"firstInitial": "R",
"lastName": "SomePerson"
}
},
{
"objectClassName": "exampleExt_author",
"author":
{
"firstInitial": "J",
"lastName": "SomePerson"
}
}
]
}
2.4.5. rdapConformance Population
Section 4.1 of [RFC9083] offers the following guidance on including
extension identifiers in the "rdapConformance" member of an RDAP
response:
A response to a "help" request will include identifiers for all of
the specifications supported by the server. A response to any
other request will include only identifiers for the specifications
used in the construction of the response.
A strict interpretation of this wording where "construction of the
response" refers only to the JSON structure would rule out the use of
profile extensions (see Section 2.1.1), which are in common use in
RDAP. This document clarifies the guidance. For responses to
queries other than "/help", a response MUST include in the
"rdapConformance" array only those extension identifiers necessary
for a client to deserialize the JSON and understand the semantic
meaning of the content within the JSON, which includes profile
extension identifiers (see Section 2.1.1). Each extension identifier
MUST be free from conflict with the other identifiers with respect to
their syntax and semantics.
Newton, et al. Expires 14 February 2027 [Page 14]
Internet-Draft rdap-extensions August 2026
Note that this document does not update the guidance from Section 4.1
of [RFC9083] regarding "/help" responses and the "rdapConformance"
array.
2.4.6. Camel Casing
The styling convention used in [RFC9083] for JSON names is often
called "camel casing", in reference to the hump of a camel. In this
style, the first letter of every word, except the first word,
composing a name is capitalized. This convention was adopted to
visually separate the namespace from the name, with an underscore
between them (e.g., "example_someData"). Extension authors are
encouraged to use camel casing for JSON names defined in extensions.
3. Usage with HTTP
Extensions MUST NOT redefine the meaning of HTTP semantics.
Extensions MAY require the use of specific HTTP headers but MUST NOT
redefine their meanings.
Extensions MAY require the use of HTTP status codes not explicitly
enumerated in [RFC7480]. However, extensions MUST NOT redefine the
meaning of any HTTP status codes in [http-status-codes].
Extensions MAY define new media type parameters for the "application/
rdap+json" media type. Extensions MUST NOT redefine the meaning of
existing media type parameters. Media type parameters MUST be
prefixed with an extension identifier (see Section 2.2).
RDAP extensions defining the use of new HTTP headers, HTTP status
codes, or media type parameters MUST have IETF consensus.
4. Extension Implementer Considerations
4.1. Redirects
[RFC7480] describes the use of redirects in RDAP. Redirects are
prominent in the discovery of authoritative RIR servers, as the
process outlined in [RFC9224], which uses IANA allocations, does not
account for transfers of resources between RIRs. Section 4.3 of
[RFC7480] instructs servers to ignore unknown query parameters (where
"unknown" generally means no defined implementation behavior). As it
relates to issuing URLs for redirects, servers MUST NOT blindly copy
query parameters from a request to a redirect URL as query parameters
may contain sensitive information, such as security credentials, not
relevant to the target server of the URL. Following the advice in
[RFC7480], servers MUST only place query parameters in redirect URLs
when it is known by the origin server (the server issuing the
Newton, et al. Expires 14 February 2027 [Page 15]
Internet-Draft rdap-extensions August 2026
redirect) that the target server (the server referenced by the
redirect) can process the query parameter and is a proper target for
the contents of the query parameter.
5. Extension Author Considerations
5.1. Redirects
As it is unlikely that every server in a cross-authority, redirect
scenario will be upgraded to process every new extension, extensions
should not rely on query parameters alone to convey information about
a resource, as query parameters are not guaranteed to survive a
redirect.
This does not mean extensions are prohibited from using query
parameters, but rather that the use of query parameters must be
applied for the scenarios appropriate for the use of the extension.
Therefore, extensions MUST NOT rely on query parameters when the
extension is to be used in scenarios requiring clients to find
authoritative servers, or other scenarios using redirects among
servers of differing authorities.
Extensions MAY use query parameters in scenarios where the client has
a priori knowledge of the authoritative server to which queries are
to be sent, and will be sending queries to that server directly.
Searches (Section 8 of [RFC9083]) are an example scenario where a
client will be operating in this way.
In general, extension authors should be mindful of situations
requiring clients to directly handle redirects at the RDAP layer.
Some clients may not be utilizing HTTP libraries that provide such an
option, and some HTTP client libraries that do provide the option do
not provide it as a default behavior.
While HTTP does allow RDAP content to be returned in a redirect, some
clients will not have access to that content, in particular browser-
based clients.
Additionally, requiring clients to handle redirects at the RDAP layer
adds complexity to the client in that additional logic must be
implemented to handle redirect loops, parameter deconfliction, and
URL encoding. The guidance given in Section 5.2 of [RFC7480] exists
to simplify clients, especially those constructed with shell scripts
and HTTP command-line utilities.
Newton, et al. Expires 14 February 2027 [Page 16]
Internet-Draft rdap-extensions August 2026
5.2. Referrals
It is common in the RDAP ecosystem to link from one RDAP resource to
another, such as can be found in domain registrations in gTLD DNRs.
These are typically conveyed in the link structure defined in
Section 4.2 of [RFC9083] and use the "application/rdap+json" media
type. For example:
{
"value": "https://regy.example/domain/foo.example",
"rel": "related",
"href": "https://regr.example/domain/foo.example",
"type": "application/rdap+json"
}
Extensions MUST explicitly define any required behavioral changes to
the processing of referrals. If an extension does not make any
provision in this respect, clients MUST assume the information
provided by referrals requires no additional processing or
modification to use in the dereferencing of the referral.
Extensions MAY define referral processing behaviors of referrals
defined in other extensions or in [RFC9083].
Servers MUST NOT use multiple extensions in a response with
processing requirements over the same referrals where clients would
not be able to process the referrals in a deterministic way.
Extensions MUST register new link relations in the [link-relations]
registry. The expert reviewers of this registry may require the
relationship name be prepended with "rdap-".
When defining the usage of link relations, extensions MUST specify
the media types expected to be used with those link relations.
5.3. Extensions Referencing Other Extensions
As stated for profile extensions (see Section 2.1.1), extensions may
rely on other extensions by stipulating the usage of those other
extensions. Dependencies between extensions MUST be defined using a
normative reference in the dependent extension and MUST include an
explicit description of the dependency.
For example, the extension "exampleExt1" may require the usage of
structures defined in "exampleExt2" instead of redefining new,
equivalent structures:
Newton, et al. Expires 14 February 2027 [Page 17]
Internet-Draft rdap-extensions August 2026
{
"rdapConformance": [
"rdap_level_0",
"exampleExt1",
"exampleExt2"
],
"objectClassName": "autnum",
"startAutnum": 64496,
"endAutnum": 64497,
"exampleExt1_cones": [ 64498, 64499],
"exampleExt2_adjacents": [ 64500, 64501 ]
}
5.4. Extension Versioning
As stated in Section 2.1, RDAP extension identifiers and RDAP
conformance strings are opaque, and they possess no explicit version
despite the fact that some extension identifiers include trailing
numbers. That is, RDAP extensions without an explicitly-defined
versioning scheme are opaquely versioned.
For example, "exampleExt1" may be the successor to "exampleExt0", but
it may also be an extension for a completely separate purpose. Only
consultation of the definition of "exampleExt1" will determine its
relationship with "exampleExt0". Additionally, "exampleExt99" may be
the predecessor to "exampleExt0".
The following terms are used to describe an extension that takes the
place of another:
* A revision is an extension that succeeds another extension where
both the successor and the predecessor use the same extension
identifier.
* A superseder is an extension that succeeds another extension where
the successor uses an extension identifier different from the one
used by the predecessor.
Compatibility of revisions and superseders with their predecessors is
taken from the rules in [!@RFC7480], [!@RFC9082], and [!@RFC9083]
regarding the recognition of protocol elements, where a protocol
element is considered to be, but not limited to, JSON names, JSON
values, query parameters, query paths, etc. Some of these rules are
explicit, such as ignoring unknown query parameters and JSON names,
while others are implicit to the operation of HTTP and JSON, such as
when a JSON name is specified to have a specific data type.
Newton, et al. Expires 14 February 2027 [Page 18]
Internet-Draft rdap-extensions August 2026
Because there is no relationship between an RDAP client and an RDAP
server, there is no way to absolutely determine if a breaking change
will have no impact on all clients. Therefore, breaking changes
described in this document concern only interoperability and not
policy. Changes in policy may result in breakage of
interoperability. Such policy changes cannot be outright forbidden,
and the description of breaking changes and non-breaking changes in
this document serves to inform policy-makers of interoperability
concerns.
5.4.1. Breaking Changes in Revisions
A breaking change (also known as a backwards-incompatible change)
occurs when a modification in a revision causes clients conforming to
the predecessor to malfunction, experience degradation of
functionality, or fail to interoperate in some other manner.
Determining that a change is a breaking change will generally be
trivial when the change is syntactical, like with the deprecation of
a member in a response. It may be more difficult with non-
syntactical elements, like referrals (see Section 5.2). Extension
authors should take care when determining whether a change is a
breaking change.
Another breaking change is to introduce a new object class where a
client previously expected another, such as:
* A query using a path and/or query parameters (e.g., "/domain/
foo.example" produces "example_domain" instead of "domain");
* A referral (e.g., "related" produces "example_domain" instead of
"domain");
* Search results; and
* Other JSON arrays and JSON members that may contain object
classes.
Breaking changes may occur in requirements for processing of data in
protocol elements that appear in both a predecessor and a revision.
For example, a profile extension (see Section 2.1.1) may require
domain names always end with a dot ("."). Should its successor
remove this requirement, this could be considered a breaking change.
The following is a non-exhaustive list of other types of breaking
changes:
* Changing the data type of a protocol element (e.g., "hello": 1 to
"hello": "world");
* Changing the name of a protocol element;
Newton, et al. Expires 14 February 2027 [Page 19]
Internet-Draft rdap-extensions August 2026
* Changing the interpreted or semantic meaning of a protocol element
(e.g., "secure" changes from signed to encrypted);
* Changing the inferences to be drawn from the absence of a protocol
element (e.g., a default changes from true to false);
* Expanding the expected range (e.g., 0 to 9 becomes 0 to 10) to be
found in a protocol element in a response;
* Contracting the expected range (e.g., 0 to 10 becomes 0 to 9) to
be found in a protocol element in a request;
* Expanding a set of values when that set is not defined in an IANA
registry to be found in a protocol element in a response;
* Contracting a set of values when that set is not defined in an
IANA registry to be found in a protocol element in a request;
* Removing a required protocol element from a response;
* Changing a required protocol element in a response to optional;
and
* Requiring new protocol elements in a request.
5.4.2. Non-breaking Changes in Revisions
The following are considered non-breaking changes between a revision
and its predecessor.
* New referrals
* New JSON members
* New URL paths
* New, optional query parameters
The use of a new HTTP header (i.e., one previously not in-use with
the predecessor), may either be a breaking change or a non-breaking
change, depending on the usage of the header with underlying HTTP
software and infrastructure.
5.4.3. Considerations for Superseders
A superseder is indistinguishable from a new, unrelated extension and
is not backwards-compatible with its predecessor due to the rules of
RDAP namespaced identifiers (see Section 2.2). Implementers of such
changes should consider the following:
* Whether a superseder can be provided alongside the predecessor, so
that a service can simply support both during a transition period;
* Whether some sort of client signaling should be supported, so that
clients can opt for the predecessor or superseder of the extension
in responses that they receive (see
[I-D.ietf-regext-rdap-x-media-type] for an example of how this
might work); and
Newton, et al. Expires 14 February 2027 [Page 20]
Internet-Draft rdap-extensions August 2026
* Whether the extension itself should define how versioning is
handled within the extension documentation (see
[I-D.ietf-regext-rdap-versioning] for an example of how this might
work).
When using a transition period between a predecessor and its
superseder, the superseder must not conflict with the predecessor.
Typically, this is not an issue when the rules of RDAP namespaced
identifiers are followed (see Section 2.2), but similar to
compatibility of revisions there are some non-obvious compatibility
issues with superseders regarding behaviors not protected by
namespaces, such as with referrals (see Section 5.2).
Known strategies compatible with [RFC7480], [RFC9082], and [RFC9083]
using a superseder are described below.
5.4.3.1. Non-overlapping Superseders
Should an extension author desire to create a successor extension,
one method is to create a superseder that replicates all the
functionality of the predecessor.
Take for example this RDAP response for "example0":
{
"rdapConformance": [
"rdap_level_0",
"example0"
],
"objectClassName": "domain",
"ldhName": "example.com",
"example0_malwareReputationId": 1234
}
Figure 1: note "example0_malwareReputationId"
A superseder may define the same functionality with equivalent
structures.
Newton, et al. Expires 14 February 2027 [Page 21]
Internet-Draft rdap-extensions August 2026
{
"rdapConformance": [
"rdap_level_0",
"example1"
],
"objectClassName": "domain",
"ldhName": "example.com",
"example1_malwareReputationId": 1234,
"example1_spamReputationId": 7890
}
Figure 2: note "example1" replicates "example0" and adds new members
During a transition period, both extensions could be in use.
{
"rdapConformance": [
"rdap_level_0",
"example0",
"example1"
],
"objectClassName": "domain",
"ldhName": "example.com",
"example0_malwareReputationId": 1234,
"example1_malwareReputationId": 1234,
"example1_spamReputationId": 7890
}
Figure 3: note "example0" and "example1" both have
"malwareReputationId"
5.4.3.2. Overlapping Superseders
If extension authors are concerned about the size of responses for
superseders using non-overlapping structures (see Section 5.4.3.1),
they may overlap the functionality by requiring the use of the
previous extension. For example:
Newton, et al. Expires 14 February 2027 [Page 22]
Internet-Draft rdap-extensions August 2026
{
"rdapConformance": [
"rdap_level_0",
"example0",
"example1"
],
"objectClassName": "domain",
"ldhName": "example.com",
"example0_malwareReputationId": 1234,
"example1_spamReputationId": 7890
}
Figure 4: note "example0" is required and "example1" adds the new
member
And at some future time, another overlapping superseder such as
"example9" may no longer need the function provided by "example0" and
may cease to reference it.
Note that because RDAP extension identifiers are opaque, an
overlapping superseder is indistinguishable from one extension
referencing another extension (see Section 5.3).
5.4.4. Evolving Extensions without Describing Changes
Because RDAP clients ignore unrecognized JSON names, and RDAP servers
ignore unknown query parameters, it is possible to extend an RDAP
extension by adding new JSON names or query parameters within the
same namespace of an existing RDAP extension without changing the
extension identifier (i.e., a revision) or using other signaling
methods.
In this scenario, clients that are not updated to recognize the new
elements would simply ignore them. This is true for all non-breaking
changes (see Section 5.4.2).
However, when such changes are made, the extension MUST describe
mechanisms for the clients to recognize and properly process such a
changed response (e.g., by way of a method like
[I-D.ietf-regext-rdap-versioning]).
5.5. Extension Specification Content
The primary purpose of an RDAP extension specification is to aid in
the implementation of RDAP clients. Extension authors should
consider the following content guidelines:
Newton, et al. Expires 14 February 2027 [Page 23]
Internet-Draft rdap-extensions August 2026
1. Examples of RDAP JSON should be generously given, especially in
areas of the specification which may be complex or difficult to
describe with prose.
2. Normative references, i.e., references to materials that are
required for the interoperability of the extension, MUST be
stable and non-changing and MUST NOT be denoted as a "work in
progress" or similar description.
3. Extension specifications MUST NOT define request and response
exchanges over an unencrypted HTTP connection. Extensions should
also be compliant with the security considerations of [RFC7481].
4. Extension specifications MUST NOT forbid the use of RDAP services
over IPv6.
5. The use of the various RDAP extension points, as described in
Section 1.1, should be clearly delineated.
Extension specifications should also consider if Section 2.2 of
[RFC9839] is applicable to the JSON data conveyed by the extension.
When generically describing interactions with other extensions,
specifications may use extension identifiers beginning with
"example".
5.6. Extension Definitions
Extensions must be documented in an RFC or in some other permanent,
stable, and readily available reference, in sufficient detail that
interoperability between independent implementations is possible.
Though RDAP gives each extension its own namespace, the definition of
an extension may reuse definitions found in the base RDAP
specification or in any other registered extension.
[RFC9083] notes that the extension identifiers provide a "hint" to
the client as to how to interpret the response. This wording does
not intentionally restrict the extension to defining only JSON values
within the extension's namespace. Therefore, an extension may define
the use of its own JSON values together with the use of JSON values
from other extensions or RDAP specifications. As with the
[icann-profile] and [nro-profile] extensions, the extension may
simply signal policy applied to previously-defined RDAP structures
(see Section 2.1.1).
6. Existing Extension Registrations
The following extensions have been registered with IANA, but do not
comply with the requirements set out in the base specifications, as
clarified by this document:
Newton, et al. Expires 14 February 2027 [Page 24]
Internet-Draft rdap-extensions August 2026
* Extension identifier: fred
- RDAP conformance value: fred_version_0
- Field/path prefix: fred
* Extension identifier: artRecord
- RDAP conformance value: artRecord_level_0
- Field/path prefix: artRecord
* Extension identifier: platformNS
- RDAP conformance value: platformNS_level_0
- Field/path prefix: platformNS
* Extension identifier: regType
- RDAP conformance value: regType_level_0
- Field/path prefix: regType
Client authors should be aware that responses that make use of these
extensions may require special handling on the part of the client.
Also, while these extensions will be retained in the registry, future
extensions that are similarly non-compliant will not be registered.
7. IANA Considerations
7.1. RDAP Extensions Registry
[RFC7480] defines the [rdap-extensions] registry. This document does
not change the purpose of this registry but does update the structure
and procedures to be used by its expert reviewers.
7.1.1. Deprecation Date
IANA is instructed to add a new "Deprecation Date" field to each
registration in the registry. This field is to remain empty unless
IANA is given a date to place in the field. A registrant, as denoted
by the contact field of the registry, may request of IANA to
deprecate their RDAP extension. The IESG may request of the IANA to
deprecate any RDAP extension in the registry. The "Deprecation Date"
field should use the full-date ABNF rule specified in [RFC3339].
IANA is requested to record the RDAP extensions
"icann_rdap_response_profile_0" and
"icann_rdap_technical_implementation_guide_0", currently marked as
obsolete, with the deprecation date of 2025-08-21.
Newton, et al. Expires 14 February 2027 [Page 25]
Internet-Draft rdap-extensions August 2026
7.1.2. Registration Procedures
Extension authors are encouraged but not required to seek an informal
review of their extension by sending a request for review to
regext@ietf.org or its successor.
The registration template of this registry is found in [RFC7480] and
is unchanged by this document. It is requested of the IANA that all
registrations be copied to regext@ietf.org or its successor.
Extensions MUST be documented in a stable, non-changing, and readily
available reference, in sufficient detail that interoperability
between independent implementations is possible, and MUST NOT be
denoted as a "work in progress" or similar description.
7.1.3. Expert Review
The RDAP Extensions Registry should have as a minimum three expert
reviewers and ideally four or five. An expert reviewer assigned to
the review of an RDAP extension registration must have another expert
reviewer double-check any submitted registration.
Expert reviewers are to use the following criteria for extensions
defined in this document, [RFC7480], [RFC9082], and [RFC9083]. The
following is a non-exhaustive checklist:
1. Does the extension define an extension identifier following the
naming conventions described in Section 2.2 and Section 2.4.6?
2. If the extension defines new queries, does it clearly describe
the expected results of each new query?
3. Does the extension follow the JSON naming requirements as
described in Section 2.4?
4. If the extension is a newer version of an older extension, does
the extension specification clearly describe if it is backwards-
compatible (see Section 5.4)?
5. If the extension registers new values in an IANA registry used by
RDAP, does it describe how a client is to use those values?
6. If the extension is a new registration, is it a case-variant of
an existing registration (see Section 2.2)?
As noted in Section 2.2:
* Any new registration that is a case-variant of an existing
registration MUST be rejected.
* Any registration containing the word "ietf" MUST have IETF
consensus.
* Registrations MUST NOT start with "example".
* Registrations MUST NOT start with "draft".
Newton, et al. Expires 14 February 2027 [Page 26]
Internet-Draft rdap-extensions August 2026
As expert reviewers are considered to be subject-matter experts with
regard to RDAP, they are also expected to use their good technical
judgement when evaluating requests.
7.2. RDAP JSON Values Registry
Section 10.2 of [RFC9083] defines the [rdap-json-values]. This
registry contains values to be used in the JSON values of RDAP
responses. Registrations into this registry may occur in IETF-
defined RDAP extensions or via requests to the IANA. Authors of RDAP
extensions not defined by the IETF MAY register values in this
registry via requests to the IANA. IANA is requested to send a copy
of any request not originating from the IETF to regext@ietf.org or
its successor.
This document does not change the [rdap-json-values] nor its purpose.
However, this document does update the procedures for registrations
and the processes to be used by its expert reviewers.
In addition to the registration of values, RDAP extensions defined by
the IETF and other IETF specifications MAY define additional value
types (the "type" field). These specifications MUST describe the
specific JSON field to be used for each new value type.
Section 10.2 of [RFC9083] defines the criteria for the values. Of
these, criteria two states:
| Values must be strings. They should be multiple words separated
| by single space characters. Every character should be lowercased.
| If possible, every word should be given in English and each
| character should be US-ASCII.
All registrations SHOULD meet these requirements. However, there may
be scenarios in which it is more appropriate for the values to follow
other requirements, such as for values also used in other
specifications or documents.
Registrations MUST NOT contain problematic code points as defined by
Section 2.2 of [RFC9839].
Registrations containing the word "ietf" MUST have IETF consensus.
Registrations MUST NOT start with "example" because these JSON values
are reserved for use as examples in documentation.
Newton, et al. Expires 14 February 2027 [Page 27]
Internet-Draft rdap-extensions August 2026
In all cases, it should be understood that additional registrations
of RDAP JSON values occurring after the specification of the value's
type in the registry may not be recognized by clients, and therefore
either ignored or passed on to users without processing.
Designated experts MUST reject any registration that is a duplicate
of an existing registration, and all registrations are to be
considered case-insensitive. That is, any new registration that is a
case-variant of an existing registration MUST be rejected.
Definitions of new types (see above) MAY additionally constrain the
format of values for those new types beyond the specification of this
document and [RFC9083]. Designated experts MUST evaluate
registrations with those criteria.
The [rdap-json-values] registry should have as a minimum three expert
reviewers and ideally four or five. An expert reviewer assigned to
the review of an RDAP JSON values registration must have another
expert reviewer double-check any submitted registration.
Expert reviewers are to use the criteria defined in Section 10.2 of
[RFC9083]. As expert reviewers are considered to be subject-matter
experts with regard to RDAP, they are also expected to use their good
technical judgement when evaluating requests.
8. Operational Considerations
8.1. Interpretation of IANA Registry Values
RDAP clients SHOULD match values of "rdapConformance" array with the
values in the [rdap-extensions] registry using case-insensitive
matching to handle server implementations incorrectly using the wrong
case.
RDAP clients SHOULD match values in the [rdap-json-values] registry
using case-insensitive matching to handle scenarios in which servers
incorrectly use the wrong case.
8.2. Referral and Redirect Loops
A redirect loop will occur if a server issues a redirect causing a
client to follow redirects back to a previous server queried during
the processing of the same query. Clients MUST cancel any queries
when a redirect loop is detected. Servers MUST NOT issue responses
that cause redirect loops.
Newton, et al. Expires 14 February 2027 [Page 28]
Internet-Draft rdap-extensions August 2026
The same is also true of referrals. Clients MUST cancel any query
when a referral loop is detected. Servers MUST NOT issue responses
that cause referral loops.
9. Security Considerations
Section 2.3.2 describes the usage of query parameters and Section 5.1
describes the restrictions extensions must follow to use them.
Section 4.3 of [RFC7480] instructs servers to ignore unknown query
parameters. As it relates to issuing URLs for redirects, servers
MUST NOT blindly copy query parameters from a request to a redirect
URL as query parameters may contain sensitive information, such as
security credentials or tracking information, not relevant to the
target server of the URL. Following the advice in [RFC7480], servers
MUST only place query parameters in redirect URLs when it is known by
the origin server (the server issuing the redirect) that the target
server (the server referenced by the redirect) can process the query
parameter and the contents of the query parameter are appropriate to
be received by the target.
10. Privacy Considerations
Section 2.3.2 describes the usage of query parameters and Section 5.1
describes the restrictions extensions must follow to use them. As
query parameters have been known to be used to subvert the privacy
preferences of users in HTTP-based protocols, servers MUST NOT
blindly copy query parameters from a request to a redirect URL as
described in Section 9 and extensions MUST follow the constraints of
query parameter usage as defined in Section 5.1.
11. Acknowledgments
The following individuals have provided feedback and contributions to
the content and direction of this document: James Gould, Scott
Hollenbeck, Ties de Kock, Pawel Kowalik, Daniel Keathley, and Mario
Loffredo.
12. References
12.1. Normative References
[RFC1866] Berners-Lee, T. and D. Connolly, "Hypertext Markup
Language - 2.0", RFC 1866, DOI 10.17487/RFC1866, November
1995, <https://www.rfc-editor.org/info/rfc1866>.
Newton, et al. Expires 14 February 2027 [Page 29]
Internet-Draft rdap-extensions August 2026
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC3339] Klyne, G. and C. Newman, "Date and Time on the Internet:
Timestamps", RFC 3339, DOI 10.17487/RFC3339, July 2002,
<https://www.rfc-editor.org/info/rfc3339>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 7480, DOI 10.17487/RFC7480, March 2015,
<https://www.rfc-editor.org/info/rfc7480>.
[RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 7481, DOI 10.17487/RFC7481, March 2015,
<https://www.rfc-editor.org/info/rfc7481>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9082] Hollenbeck, S. and A. Newton, "Registration Data Access
Protocol (RDAP) Query Format", STD 95, RFC 9082,
DOI 10.17487/RFC9082, June 2021,
<https://www.rfc-editor.org/info/rfc9082>.
[RFC9083] Hollenbeck, S. and A. Newton, "JSON Responses for the
Registration Data Access Protocol (RDAP)", STD 95,
RFC 9083, DOI 10.17487/RFC9083, June 2021,
<https://www.rfc-editor.org/info/rfc9083>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
Newton, et al. Expires 14 February 2027 [Page 30]
Internet-Draft rdap-extensions August 2026
[RFC9224] Blanchet, M., "Finding the Authoritative Registration Data
Access Protocol (RDAP) Service", STD 95, RFC 9224,
DOI 10.17487/RFC9224, March 2022,
<https://www.rfc-editor.org/info/rfc9224>.
[RFC9839] Bray, T. and P. Hoffman, "Unicode Character Repertoire
Subsets", RFC 9839, DOI 10.17487/RFC9839, August 2025,
<https://www.rfc-editor.org/info/rfc9839>.
12.2. Informative References
[I-D.ietf-regext-rdap-versioning]
Gould, J., Keathley, D., and M. Loffredo, "Versioning in
the Registration Data Access Protocol (RDAP)", Work in
Progress, Internet-Draft, draft-ietf-regext-rdap-
versioning-07, 31 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-regext-
rdap-versioning-07>.
[I-D.ietf-regext-rdap-x-media-type]
Newton, A. and J. Singh, "The "exts_list" Parameter for
the RDAP Media Type", Work in Progress, Internet-Draft,
draft-ietf-regext-rdap-x-media-type-06, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-regext-
rdap-x-media-type-06>.
[http-status-codes]
IANA, "Hypertext Transfer Protocol (HTTP) Status Code
Registry", <https://www.iana.org/assignments/http-status-
codes/http-status-codes.xhtml>.
[icann-profile]
ICANN, "gTLD RDAP Profile", 2024,
<https://www.icann.org/gtld-rdap-profile>.
[link-relations]
IANA, "Link Relations", <https://www.iana.org/assignments/
link-relations/link-relations.xhtml>.
[nro-profile]
NRO, "NRO RDAP Profile", 2021,
<https://bitbucket.org/nroecg/nro-rdap-profile/raw/v1/nro-
rdap-profile.txt>.
[rdap-extensions]
IANA, "RDAP Extensions",
<https://www.iana.org/assignments/rdap-extensions/rdap-
extensions.xhtml>.
Newton, et al. Expires 14 February 2027 [Page 31]
Internet-Draft rdap-extensions August 2026
[rdap-json-values]
IANA, "RDAP JSON Values",
<https://www.iana.org/assignments/rdap-json-values/rdap-
json-values.xhtml>.
Authors' Addresses
Andy Newton
ICANN
Email: andy@hxr.us
Jasdip Singh
ARIN
Email: jasdips@arin.net
Tom Harrison
APNIC
Email: tomh@apnic.net
Newton, et al. Expires 14 February 2027 [Page 32]