The "exts_list" Parameter for the RDAP Media Type

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 6 July 2026.¶

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

Table of Contents

1. Background

[RFC7480] defines the "application/rdap+json" media type to be used with RDAP. This document defines a new parameter for this media type when an RDAP extension needs to be described during HTTP content negotiation.¶

This parameter enables an RDAP client to signal to an RDAP server the list of RDAP extensions supported by that client. For example, an RDAP client that supports the "foo" extension may use this mechanism as a signal to an RDAP server, thus allowing the server to respond with data using the "foo" extension inside an RDAP response only when it can be assured the client can understand the extension.¶

By using this method, there is no need for every RDAP extension to define their own unique signaling mechanism. Additionally, this method is designed to be backwards-compatible with the deployed RDAP ecosystem (see Appendix B for further information).¶

2. The RDAP Media Type With "exts_list" Parameter

The RDAP media type, "application/rdap+json", may have an optional parameter named "exts_list". This parameter is a whitespace-separated list of RDAP extension identifiers (as would be found in the "rdapConformance" array).¶

Here is an example:¶

application/rdap+json;exts_list="rdap_level_0 exts fred"

3. Using The "exts_list" Parameter

[RFC7480] specifies the usage of "application/json", "application/rdap+json" or both with HTTP "accept" header. The "exts_list" parameter may only be used with the "application/rdap+json" media type.¶

This is an example of the "accept" header using the RDAP media type with the "exts_list" parameter:¶

accept: application/json;q=0.9,
    application/rdap+json;exts_list="rdap_level_0 exts fred";q=1

If both a client and a server support the "exts_list" parameter, and the client requests an extension that is unimplemented by the server, the server MUST respond with only extensions included in the response by the server. This behavior is backwards-compatible as RDAP clients should ignore unknown RDAP extensions as specified by [RFC9083]. Responding with an HTTP 406 Not Acceptable status code is NOT RECOMMENDED because an RDAP client could interpret this status code to mean that the server does not understand RDAP in its entirety.¶

The extensions requested by the client represent a hint for the server in determining the extensions to include the response. If a server is required to use an extension in a response that was not requested by the client, the server MUST respond as if the client had requested the extension. This behavior is backwards-compatible as RDAP clients should ignore unknown extensions as specified by [RFC9083]. Responding with an HTTP 406 Not Acceptable status code is NOT RECOMMENDED for the reason stated above.¶

When the "exts_list" parameter is used in the RDAP media type in the "content-type" header, the values in the media type's "exts_list" parameter MUST match the values in the "rdapConformance" array in the returned JSON. However, implementation experience has shown that some HTTP server libraries do not support modification of the "content-type" header per query type. Therefore, use of the "exts_list" parameter with the media type of the "content-type" header is NOT REQUIRED. That is, when used in the "content-type" header, the values of the "exts_list" parameter must match that of the "rdapConformance" array but server may opt to omit the "exts_list" parameter from the media type in the "content-type" header.¶

If a server does use the "exts_list" parameter with the media type in the "content-type" header, the content of the "exts_list" parameter MUST mirror the content of the "rdapConformance" array in server responses. This includes the identifier "rdap_level_0", which is not an extension identifier but an identifier for the base RDAP specifications. Servers MUST follow the same rules for placing "rdap_level_0" in the content of the "exts_list" parameter and the "rdapConformance" array. Clients MUST interpret the "exts_list" parameter without "rdap_level_0" or one of its successor identifiers (e.g., "rdap_level_1") in the same manner as the interpretation of the "rdapConformance" array without "rdap_level_0" or one of its successors.¶

Nothing in this specification sidesteps or obviates the HTTP content negotiation defined in [RFC9110] for RDAP.¶

Likewise, nothing in this specification sidesteps or obviates the HTTP caching mechanisms defined in [RFC9110]. Further advice on the "vary" header can be found in Appendix A.¶

Some RDAP extensions, such as [RFC9560], have other protocol elements (e.g., extension-specific query parameters) passed from the client to the server, and the presence of these protocol elements may be used by servers to determine a client's capability to handle the related RDAP extension(s). This specification does not require the usage of those extension identifiers in the "exts_list" parameter, though clients SHOULD list the extension identifier in the "exts_list" parameter when using other protocol elements of those extensions for better compatibility with servers recognizing the "exts_list" parameter. Servers SHOULD NOT require the usage of extension identifiers in the "exts_list" parameter when these types of extension protocol elements are present in requests for better compatibility with the extensions using them.¶

GET /help HTTP/1.1
accept: application/rdap+json

HTTP/1.1 200 OK
content-type: application/rdap+json

{ "rdapConformance" : [ "rdap_level_0", "exts" ],
  "notices" : [
    { "description" : [ "my content includes a trailing CRLF" ] } ] }

GET /help HTTP/1.1
accept: application/rdap+json;exts_list="rdap_level_0 exts foo"

HTTP/1.1 200 OK
content-type: application/rdap+json

{ "rdapConformance" : [ "rdap_level_0", "exts", "foo" ],
  "notices" : [
    { "description" : [ "my content includes a trailing CRLF" ] } ] }

GET /help HTTP/1.1
accept: application/rdap+json;exts_list="rdap_level_0 exts foo"

HTTP/1.1 200 OK
content-type: application/rdap+json

{ "rdapConformance" : [ "rdap_level_0", "foo" ],
  "notices" : [
    { "description" : [ "my content includes a trailing CRLF" ] } ] }

GET /help HTTP/1.1
accept: application/rdap+json;exts_list="rdap_level_0 exts foo bar"

HTTP/1.1 200 OK
content-type: application/rdap+json

{ "rdapConformance" : [ "rdap_level_0", "exts", "foo" ],
  "notices" : [
    { "description" : [ "my content includes a trailing CRLF" ] } ] }

GET /entity/fizz1234 HTTP/1.1
accept: application/rdap+json;exts_list="rdap_level_0 jscontact"

HTTP/1.1 200 OK
content-type: application/rdap+json

{
  "rdapConformance": [ "rdap_level_0" ],
  "objectClassName": "entity",
  "handle": "fizz1234",
  "vcardArray": [
    "vcard",
    [
      [ "version", { }, "text", "4.0" ],
      [ "fn", { }, "text", "Bob Smurd" ],
      [ "email", { }, "text", "bob@example.com" ]
    ]
  ]
}

GET /entity/fizz1234 HTTP/1.1
accept: application/rdap+json;exts_list="rdap_level_0 jscontact"

HTTP/1.1 200 OK
content-type: application/rdap+json

{
  "rdapConformance": [ "rdap_level_0", "jscontact" ],
  "objectClassName": "entity",
  "handle": "fizz1234",
  "jscontact_card": {
    "@type": "Card",
    "version": "2.0",
    "name": { "full": "Bob Smurd" },
    "emails": { "email": { "address": "bob@example.com" } }
  }
}

4. Usage in RDAP Links

Section 4.2 of [RFC9083] defines a link structure used in RDAP.¶

{
  "value": "https://example.com/context_uri",
  "rel": "self",
  "href": "https://example.com/target_uri",
  "hreflang": [ "en", "ch" ],
  "title": "title",
  "media": "screen",
  "type": "application/json"
}

The link's "type" attribute signals to a client the expected media type of the resource referenced in the link's "href" attribute, and some clients use this information to determine if the URI in the "href" attribute should be de-referenced.¶

Usage of the "exts_list" parameter in the media type of the "type" attribute is allowed but the "type" attribute as a whole is only a hint, as noted by [RFC8288]:¶

The "type" attribute, when present, is a hint indicating what the media type of the result of dereferencing the link should be. Note that this is only a hint; for example, it does not override the Content-Type header field of a HTTP response obtained by actually following the link.¶

Using the "exts_list" parameter in the media type of the "type" attribute in RDAP links is NOT RECOMMENDED as it may describe client capabilities which the client may not possess.¶

5. Implementation Status

RFC EDITOR NOTE: Please remove this section and the reference to RFC 7942 prior to publication as an RFC.¶

This section records the status of known implementations of the protocol defined by this specification at the time of posting of this Internet-Draft, and is based on a proposal described in RFC 7942 [RFC7942]. The description of implementations in this section is intended to assist the IETF in its decision processes in progressing drafts to RFCs. Please note that the listing of any individual implementation here does not imply endorsement by the IETF. Furthermore, no effort has been spent to verify the information presented here that was supplied by IETF contributors. This is not intended as, and must not be construed to be, a catalog of available implementations or their features. Readers are advised to note that other implementations may exist.¶

According to RFC 7942, "this will allow reviewers and working groups to assign due consideration to documents that have the benefit of running code, which may serve as evidence of valuable experimentation and feedback that have made the implemented protocols more mature. It is up to the individual working groups to use this information as they see fit".¶

6. Security Considerations

As stated in Section 3, this specification does not override the protocol elements of RDAP security extensions, such as [RFC9560], nor does it override the protocol elements of other security features of HTTP.¶

This specification does contrast with solutions using query parameters in that those solutions require servers to blindly copy query parameters into redirect URLs in situations where such copying could cause harm, such as copying an API key intended for one server into the redirect URL of another server.¶

7. IANA Considerations

Extension identifier: exts

Registry operator: ALL

Published specification: [RFC Reference Once Published]

Person & email address to contact for further information:
The Internet Engineering Steering Group <iesg@ietf.org>

Intended usage: COMMON

8. Acknowledgements

Pawel Kowalik provided extensive review of this document and conducted a study that forms the basis of re-using the existing RDAP media type. James Mitchell has provided ideas and feedbacks that have contributed to the content of this document based on his RDAP server implementation experience. Murray Kucherawy and Alexey Melnikov provided guidance on the use of media types and media type parameters. Maarten Wullink and Jame Gould provided feedback that contributed to the content of this document. Mario Loffredo has provided valuable feedback on the contents of this specification, including feedback from his implementation, that has helped to reduce interoperability issues.¶

Appendix A. Using the Vary Header

Server implementers may want to consider using the "vary" header depending on the caching behavior desired of shared caches (i.e., middleboxes, not client caches).¶

Consider the following scenario where user Bob and user Alice send queries to the same RDAP server that is routed through a middlebox network element implementing a shared HTTP cache.¶

User Bob sends a query for the domain "example.com" (http://regy.example/domain/example.com) without the "exts_list" parameter. The "accept" header sent for Bob's query would be accept: application/rdap+json or accept: application/json.¶

User Alice later sends a query for the same domain, however her client uses the "exts_list" parameter. The "accept" header sent for Alice's query might be accept: application/rdap+json;exts_list="rdap_level_0 exts foo".¶

If no "vary" header is set in the response for these queries, the shared cache will compare only the URL of the query when processing cache items and therefore user Bob and user Alice would receive the same answer. In other words, since both queried "http://regy.example/domain/example.com" the shared cache would return the answer of the first query to the second query and all other subsequent queries until the item expired out of the cache.¶

If server implementers do not desire this behavior and would signal that caches consider each query separately, servers should also return a "vary: accept" header to inform the cache that the "accept" header should also be considered when processing cache items. Server implementers should also consult [RFC9110] regarding caching and other uses of the "vary" header.¶

Appendix B. Design Considerations

https://rdap.example/domain/foo.example?exts_list=fizzbuzz

curl -v https://rdap-bootstrap.arin.net/bootstrap/autnum/2830?exts_list=fizzbuzz

{
  "value" : "https://regy.example/domain/foo.example",
  "rel" : "related",
  "href" : "https://regr.example/domain/foo.example",
  "type" : "application/rdap+json"
}

{
  "value" : "https://regy.example/domain/foo.example",
  "rel" : "related",
  "href" : "https://regr.example/domain/foo.example?exts_list=jscontact,
  "type" : "application/rdap+json"
}

Authors' Addresses