RDAP Extensions

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 and RDAP responses are defined in . RDAP contains a means to define extensions for queries not found in and responses not found in . RDAP extensions are also described in . 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.

Summary of Updates This document updates , , and for the purposes of constraining how extensions are defined. 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:

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 and .
URL Paths - New lookups and searches are defined using URL paths. This document clarifies the practice as described in .
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 .
HTTP Headers - Some extensions may use HTTP headers or header parameters not explicitly enumerated by .
HTTP Status Codes - Some extensions may use HTTP status codes not explicitly enumerated by .
Media type parameters - Some extensions may define additional media type parameters for the "application/rdap+json" media type.
Object Classes - Extensions may define new types of objects to be queried. This document clarifies this method as described in and .

Additionally, this document updates the IANA registry practices for RDAP. See .

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 when, and only when, they appear in all capitals, as shown here.

Extension Identifiers

Purpose describes the identifier used to signify RDAP extensions and the IANA registry () 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 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. 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 .

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 used by gTLD registries and registrars and the 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 : When defining the usage of link relations, extensions MUST specify the media types expected to be used with those link relations. Profile extensions may also leverage the appearance of their identifier in the "rdapConformance" array (i.e., clients are signaled that a profile is in use). Profile extensions that mandate the implementation of another extension MUST require that the implementer include the extension identifier for that other extension in the "rdapConformance" array. 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 ).

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.

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 and . 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 being an existing extension identifier appended with an underscore. For example, if there were a pre-existing identifier of "foo_bar", another extension could not define the identifier "foo". Likewise, if there were a pre-existing identifier of "foo_bar", another extension could not define the identifier "foo_bar_buzz". However, an extension could define "foo" if there were a pre-existing definition of "foobar", and vice versa. Extensions containing the word "ietf" in any mixed capitalization MUST have IETF consensus. For this reason, this document updates the guidance of regarding underscore characters: RDAP extensions MUST NOT use an underscore character in their RDAP extension identifier. Implementers should be aware that many existing extension identifiers do contain underscore characters. does not explicitly state that extension identifiers are case-sensitive. This document clarifies the formulation in 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 ). 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.

Bare Extension Identifiers states the following when using the names of JSON members:

Clients of these JSON responses SHOULD ignore unrecognized JSON members in responses. Servers can insert members into the JSON responses, which are not specified in this document, but that does not constitute an error in the response. Servers that insert such unspecified members into JSON responses SHOULD have member names prefixed with a short identifier followed by an underscore followed by a meaningful name. It has been observed that these short identifiers aid software implementers with identifying the specification of the JSON member, and failure to use one could cause an implementer to assume the server is erroneously using a name from this specification. This allowance does not apply to jCard objects. The full JSON name (the prefix plus the underscore plus the meaningful name) SHOULD adhere to the character and name limitations of the prefix registry described in . Failure to use these limitations could result in slower adoption as these limitations have been observed to aid some client programming models.

Despite this, some RDAP extensions define only one JSON value and do not prefix it with their RDAP extension identifier, instead using the extension identifier as the JSON name for that JSON value. That is, the extension identifier is used "bare" and not appended with an underscore character and subsequent names. Consider the example in . Using the bare extension identifier pattern, that example could be written as: While 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 , , and are referred to as namespaced identifiers. Usage of a bare extension identifier conflicts with the guidance in . Previously, extension authors have used this pattern when only one query path, JSON name, and/or object class is being defined by the extension. Implementation experience has shown that an extension using a bare identifier can be interoperable, though more difficult to process and parse in some instances. Furthermore, 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 similar. Due to these considerations, the bare extension identifier pattern MUST NOT be used for any namespaced identifier.

Usage in Requests

Usage in Paths 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 "foobar", then the path segments used in that extension are prepended with "foobar_". If the "foobar" extension defines paths "fizz" and "fazz", the URLs for this extension would be like so: While 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. Note that "bare" identifiers are now explicitly forbidden (see ). 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 , object classes or search results defined by the extension (see and below), or object classes or search results from other extensions. 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 "foo" defining "https://base.example/domain/foo" or "https://base.example/fizz_fazz/foo").

Usage in Query Parameters Although describes the use of URL query strings, it does not define their use with extensions. 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 and . Futhermore, and do not define the name=value pair format of a query string. This is defined in . Despite this, there are several extensions that do specify query parameters. This document updates 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 . 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). Note that "bare" identifiers are now explicitly forbidden (see ). See and for other guidance on the use of query parameters, and see and 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 . The reverse is also true: RDAP extensions using query parameters will be incompatible with extensions using other forms of URL query strings.

Usage in Responses

Basic Requirements 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. Just as with unknown query parameters in URLs, clients are to ignore unknown JSON names. The example given in is as follows: In this example, the extension identified by "lunarNIC" is prepended to the member names of both a JSON string and a JSON array. Note that "bare" identifiers are now explicitly forbidden (see ). As requires the use of the "rdapConformance" data structure, and the "objectClassName" string is required of all object class instances, the complete example from above would be:

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: Here the JSON name "lunarNIC_author" will separate the JSON from other extensions that may have an "author" structure. But the JSON contained within "lunarNIC_author" need not be prepended, as collision is avoided by the use of "lunarNIC_author".

Object Classes in Extensions As described in and , 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 . 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: Note that "bare" identifiers are now explicitly forbidden (see ). Extension authors are encouraged to use the "camel case" style described in . Though "objectClassName" is a string and 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.

Search Results in Extensions As described in and , 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 . For example:

rdapConformance Population offers the following guidance on including extension identifiers in the "rdapConformance" member of an RDAP response: A strict interpretation of this wording where "construction of the response" refers only to the JSON structure would rule out the use of extension identifiers, 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, and each extension identifier MUST be free from conflict with the other identifiers with respect to their syntax and semantics. Note that this document does not update the guidance from regarding "/help" responses and the "rdapConformance" array.

Camel Casing The styling convention used in 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. Extension authors are encouraged to use camel casing for JSON names defined in extensions.

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 . However, extensions MUST NOT redefine the meaning of any HTTP status codes in . 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 ). RDAP extensions defining the use of new HTTP headers, HTTP status codes, or media type parameters MUST have IETF consensus.

Extension Implementer Considerations

Redirects describes the use of redirects in RDAP. Redirects are prominent in the discovery of authoritative RIR servers, as the process outlined in , which uses IANA allocations, does not account for transfers of resources between RIRs. 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 , 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 is a proper target for the contents of the query parameter.

Extension Author Considerations

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 () 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. 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 exists to simplify clients, especially those constructed with shell scripts and HTTP command-line utilities.

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 and use the "application/rdap+json" media type. For example: 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 . 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 registry. The expert reviewers of this registry may require the relationship name be prepended with "rdap-".

Extensions Referencing Other Extensions As stated in , extensions may rely on other extensions by stipulating the usage of those other extensions. For example, the extension "bazz" may require the usage of structures defined in "fuzz" instead of redefining new, equivalent structures:

Extension Versioning As stated in , 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, "fizzbuzz1" may be the successor to "fizzbuzz0", but it may also be an extension for a completely separate purpose. Only consultation of the definition of "fizzbuzz1" will determine its relationship with "fizzbuzz0". Additionally, "fizzbuzz99" may be the predecessor of "fizzbuzz0". If an RDAP extension uses a versioning method, such as , it MUST be explicitly described in its specification.

Breaking Changes in Successors With the current extension model, an extension with a successor with breaking changes is indistinguishable from a new, unrelated extension. Additionally, there is no signaling mechanism in RDAP to specify successors with breaking changes. Implementers of such changes should consider the following:

whether the new version of the extension can be provided alongside the old version of the extension, 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 old or new version of the extension in responses that they receive (see for an example of how this might work); and
whether the extension itself should define how versioning is handled within the extension documentation.

When using a transition period between two versions of an extension by using both versions, the successor must not conflict with the predecessor. Typically, this is not an issue when the rules of RDAP namespaced identifiers are followed (see ), but care should be taken if the extensions specify other behaviors not protected by namespaces, particularly referrals (see ). 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 "new_domain" instead of "domain");
a referral (e.g., "related" produces "new_domain" instead of "domain");
search results; and
other JSON arrays and JSON members.

Breaking changes may occur in requirements for processing of data in protocol elements that appear in both a successor and a predecessor. For example, a profile extension (see ) may require domain names always end with a dot ("."). Should its successor remove this requirement, this could be considered a breaking change.

Non-breaking Changes in Successors The following are considered non-breaking changes between a successor and a predecessor.

new referrals
new JSON members
new URL paths
new 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.

Non-overlapping Successors Should an extension author desire to create a successor extension, the simplest method is to create a new extension (with a new extension identifier, as required) that replicates all the functionality of the previous extension. Take for example this RDAP response for "fizzbuzz0": A successor extension may define the same functionality with equivalent structures. During a transition period, both extensions could be in use.

Overlapping Successors If extension authors are concerned about the size of responses for successor extensions using non-overlapping structures (see ), they may overlap the functionality by requiring the use of the previous extension. For example: And at some future time, a successor such as "fizzbuzz9" may no longer need the function provided by "fizzbuzz0" and may cease to reference it. Note that because RDAP extension identifiers are opaque, overlapping successors is indistinguishable from one extension referencing another extension (see ).

Evolving Extensions without Signaled Changes Because RDAP clients ignore unrecognized JSON names and 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 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 ). 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 signaling method like ).

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:

Examples of RDAP JSON should be generously given, especially in areas of the specification which may be complex or difficult to describe with prose.
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.
Extension specifications MUST NOT define request and response exchanges over an unencrypted HTTP connection. Extensions should also be compliant with the security considerations of .
Extension specifications MUST NOT forbid the use of RDAP services over IPv6.
The use of the various RDAP extension points, as described in , should be clearly delineated.

Extension specifications should also consider if is applicable to the JSON data conveyed by the extension.

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. 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 and extensions, the extension may simply signal policy applied to previously-defined RDAP structures (see ).

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:

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.

IANA Considerations

RDAP Extensions Registry defines the 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.

Example Extension The IETF requests the IANA to register the following extension in : Extension identifier: example Registry operator: ALL Published specification: This RFC Reference Once Published Person & email address to contact for further information: The Internet Engineering Steering Group iesg@ietf.org Intended usage: COMMON

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 date format specified in . 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 20250821.

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

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, , , and . The following is a non-exhaustive checklist:

Does the extension define an extension identifier following the naming conventions described in and ?
If the extension defines new queries, does it clearly describe the expected results of each new query?
Does the extension follow the JSON naming requirements as described in ?
If the extension is a newer version of an older extension, does the extension specification clearly describe if it is backwards-compatible (see )?
If the extension registers new values in an IANA registry used by RDAP, does it describe how a client is to use those values?
If the extension is a new registration, is it a case-variant of an existing registration (see )?

As noted in : * 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. RDAP clients SHOULD match values in this registry using case-insensitive matching to handle server implementations incorrectly using the wrong case.

RDAP JSON Values Registry defines the . 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 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. 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 . Registrations containing the word "ietf" MUST have IETF consensus. 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. RDAP clients SHOULD match values in this registry using case-insensitive matching to handle scenarios in which servers incorrectly use the wrong case. Definitions of new types (see above) MAY additionally constrain the format of values for those new types beyond the specification of this document and . Designated experts MUST evaluate registrations with those criteria. The 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 .

Security Considerations describes the usage of query parameters and describes the restrictions extensions must follow to use them. 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 , 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.

Privacy Considerations describes the usage of query parameters and 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, server MUST NOT blindly copy query parameters from a request to a redirect URL as described in and extensions MUST follow the constraints of query parameter usage as defined in .

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.