Explicit RDAP Redirects
draft-ietf-regext-rdap-referrals-05

Registration Protocols Extensions (regext)                      G. Brown
Internet-Draft                                                 A. Newton
Intended status: Standards Track                                   ICANN
Expires: 16 April 2027                                   13 October 2026

                        Explicit RDAP Redirects
                  draft-ietf-regext-rdap-referrals-05

Abstract

   This document describes an RDAP extension that allows RDAP clients to
   request to be redirected to a related RDAP record for a resource, and
   an RDAP extension that gives RDAP clients the ability to request no
   redirection in other scenarios.  This document also defines new link
   relations that can be used in redirect requests that can be used in
   query bootstrapping and navigating hierarchies, such as the
   hierarchies described in RFC 9910.

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 16 April 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Brown & Newton            Expires 16 April 2027                 [Page 1]
Internet-Draft           Explicit RDAP Redirects            October 2026

   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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  redirects0 RDAP Extension . . . . . . . . . . . . . . . . . .   3
     2.1.  RDAP Redirect Request . . . . . . . . . . . . . . . . . .   3
     2.2.  RDAP Redirect Response  . . . . . . . . . . . . . . . . .   5
       2.2.1.  Selecting The Appropriate Link  . . . . . . . . . . .   6
       2.2.2.  Caching by Intermediaries . . . . . . . . . . . . . .   7
       2.2.3.  Client Processing of Redirect Responses . . . . . . .   7
     2.3.  RDAP Conformance  . . . . . . . . . . . . . . . . . . . .   7
     2.4.  Bootstrap Use Case  . . . . . . . . . . . . . . . . . . .   7
     2.5.  Multi-Hop Redirect Limitations  . . . . . . . . . . . . .   8
   3.  noRedirects0 RDAP Extension . . . . . . . . . . . . . . . . .   8
     3.1.  Usage of noRedirects0 . . . . . . . . . . . . . . . . . .   8
     3.2.  RDAP Conformance  . . . . . . . . . . . . . . . . . . . .   9
   4.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   9
     4.1.  redirects0 RDAP Extension Identifier  . . . . . . . . . .   9
     4.2.  noRedirects0 RDAP Extension Identifier  . . . . . . . . .   9
     4.3.  Link Relations  . . . . . . . . . . . . . . . . . . . . .  10
       4.3.1.  rdap-bootstrap  . . . . . . . . . . . . . . . . . . .  10
       4.3.2.  rdap-related-top  . . . . . . . . . . . . . . . . . .  10
       4.3.3.  rdap-related-bottom . . . . . . . . . . . . . . . . .  10
       4.3.4.  rdap-related-up . . . . . . . . . . . . . . . . . . .  11
       4.3.5.  rdap-related-down . . . . . . . . . . . . . . . . . .  11
     4.4.  RDAP JSON Values  . . . . . . . . . . . . . . . . . . . .  11
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
   6.  Operational Considerations  . . . . . . . . . . . . . . . . .  12
   7.  Change Log  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     7.1.  Changes from 04 to 05 . . . . . . . . . . . . . . . . . .  12
     7.2.  Changes from 03 to 04 . . . . . . . . . . . . . . . . . .  12
     7.3.  Changes from 02 to 03 . . . . . . . . . . . . . . . . . .  12
     7.4.  Changes from 01 to 02 . . . . . . . . . . . . . . . . . .  13
     7.5.  Changes from 00 to 01 . . . . . . . . . . . . . . . . . .  13
     7.6.  Changes from draft-brown-rdap-referrals-02 to
           draft-ietf-regext-rdap-referrals-00 . . . . . . . . . . .  13
     7.7.  Changes from 01 to 02 . . . . . . . . . . . . . . . . . .  13
     7.8.  Changes from 00 to 01 . . . . . . . . . . . . . . . . . .  13
   8.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  14
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  14

Brown & Newton            Expires 16 April 2027                 [Page 2]
Internet-Draft           Explicit RDAP Redirects            October 2026

     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  14
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  15
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  15

1.  Introduction

   Many Registration Data Access Protocol (RDAP, described in [RFC7480],
   [RFC7481], [RFC9082], [RFC9083] and others) resources contain links
   to related RDAP resources.

   For example, in the domain space, an RDAP record for a domain name
   received from the registry operator may include a link for the RDAP
   record for the same object provided by the sponsoring registrar (for
   example, see [gtld-rdap-profile], in which links to registrar RDAP
   URLs are provided by using a link object with the related relation),
   while in the IP address space, an RDAP record for an address
   allocation may include links to enclosing or sibling prefixes.

   In both cases, RDAP service users are often equally if not more
   interested in these related RDAP resources than the resource provided
   by the TLD registry or RIR.  However, to obtain the URL(s) of the
   related resource(s), the client must request the full RDAP record
   (which the server must then produce and deliver) in order to extract
   the relevant URL from the "links" property of the object.

   As deployed today, RDAP also has contrasting use cases for finding
   the registrations of IP resources.  As defined by [RFC9082], an RDAP
   server returns the most specific network registration containing the
   information sought by the client.  In practice, that information does
   not always sit on the server found through the bootstrapping process
   defined in [RFC9224], and the client is given a redirect to a target
   server with more specific information.  This practice is an
   optimization intended to satisfy the most common use case for this
   type of query.  However, there are use cases for which the client
   specifically seeks the information on the bootstrapped server and may
   wish to handle the referral to the more specific server itself.

   This document describes extensions to RDAP that allow clients to
   signal preferences regarding redirects issued by RDAP servers.

2.  redirects0 RDAP Extension

2.1.  RDAP Redirect Request

   To request a redirect to a related resource, the client sends an HTTP
   GET request with a URL of the form:

   <base URL>redirects0_ref/<relation>/<lookup path>

Brown & Newton            Expires 16 April 2027                 [Page 3]
Internet-Draft           Explicit RDAP Redirects            October 2026

   The client replaces <base URL> with the applicable base URL (which,
   as per [RFC9224], has a trailing / character), <relation> with the
   desired relationship type, and <lookup path> with the lookup path of
   the object being sought (which, as per [RFC9082], does not have a
   leading / character).

   For example, the URL of a redirect query for the domain example.com,
   where the base URL for the "com" TLD is https://rdap.example.com/
   rdap/, would be:

 https://rdap.example.com/rdap/redirects0_ref/related/domain/example.com

   The redirect query for the parent network of 192.0.2.42 with the base
   URL of https://rdap.example.net/ would be:

   https://rdap.example.net/redirects0_ref/rdap-up/ip/192.0.2.42

   As another example, the following URL would redirect the client to
   the appopriate Geolocation Feed ([RFC8805]) resource for 192.0.2.42,
   using the geofeed resource specified in [RFC9877]:

  https://rir-rdap.example.com/rdap/redirects0_ref/geofeed/ip/192.0.2.42

   Lookup paths for domain names, IP networks, autonomous system
   numbers, nameservers, and entities are described in [RFC9082].
   Lookups defined by RDAP extensions may also use this extension.

   Redirect requests for searches, where more than one object is
   returned, and help queries, as described by [RFC9083], are not
   supported.  Servers MUST return an HTTP 400 for these requests, and
   SHOULD return an RDAP error body containing a notice with the type
   value of "redirect not available":

Brown & Newton            Expires 16 April 2027                 [Page 4]
Internet-Draft           Explicit RDAP Redirects            October 2026

Client Request:

GET /redirects0_ref/related/help HTTP/1.1
Accept: application/rdap+json

Server Response:

HTTP/1.1 400 Bad Request
Content-Type: application/rdap+json

{
  "errorCode": 400,
  "type": "redirect not available",
  "title": "Redirect request for /help is not supported",
  "description": [
    "Only object lookups can be used with the redirects0_ref extension."
  ]
}

2.2.  RDAP Redirect Response

   If the object specified in the request exists, a single appropriate
   link exists, and the client is authorised to perform the request, the
   server response MUST:

   1.  have an HTTP status code of 301 (Moved Permanently), 302 (Found),
       303 (See Other), 307 (Temporary Redirect) or 308 (Permanent
       Redirect, see Section 15.4.9 of [RFC9110]); and

   2.  include an HTTP Location header field, whose value contains the
       URL of the linked resource.

   If the server cannot find an appropriate link, the response MUST have
   an HTTP status of 404.

   If an RDAP server holds in its datastore more than one relationship
   type for an object, a scenario that is possible but not common, only
   one of the URLs, as determined by server policy, can be returned.

   The following examples use the HTTP/1.1 message exchange syntax as
   seen in [RFC9110].

   An example of a redirect request from a domain registry to a domain
   registrar, where the registry implements [gtld-rdap-profile]:

Brown & Newton            Expires 16 April 2027                 [Page 5]
Internet-Draft           Explicit RDAP Redirects            October 2026

   Client Request:

   GET /redirects0_ref/related/domain/example.com HTTP/1.1
   Accept: application/rdap+json

   Server Response:

   HTTP/1.1 307 Temporary Redirect
   Location: https://registrar.example/domain/example.com

   An example of a redirect request for a parent IPv4 network:

   Client Request:

   GET /redirects0_ref/rdap-up/ip/192.0.2.42 HTTP/1.1
   Accept: application/rdap+json

   Server Response:

   HTTP/1.1 307 Temporary Redirect
   Location: https://rir.example/ip/192.0.2.0/24

   An example of a redirect request for a parent IPv6 network:

   Client Request:

   GET /redirects0_ref/rdap-up/ip/2001%3adb8%3a%3a1 HTTP/1.1
   Accept: application/rdap+json

   Server Response:

   HTTP/1.1 307 Temporary Redirect
   Location: https://rir.example/ip/2001%3adb8%3a%3a/32

2.2.1.  Selecting The Appropriate Link

   When the server receives a redirect request, it must select which of
   an object's links it should use to construct the response.

   The rel property of the selected link MUST match <relation> path
   segment of the request.  The type and hreflang properties of the
   link, if present, MUST match the Accept and (if specified) Accept-
   Language header fields of the request.

Brown & Newton            Expires 16 April 2027                 [Page 6]
Internet-Draft           Explicit RDAP Redirects            October 2026

2.2.2.  Caching by Intermediaries

   To facilitate caching of RDAP resources by intermediary proxies,
   servers which provide a redirect based on the value of the Accept
   header field in the request MUST include a Vary header field (See
   Section 12.5.5 of [RFC9110]) in the response.  This field MUST
   include accept, and MAY include other header field names.

   Example:

   Vary: accept, accept-language

2.2.3.  Client Processing of Redirect Responses

   Note that as per Section 10.2.2 of [RFC9110], the URI-reference in
   location header fields MAY be relative.  For relative references,
   RDAP clients MUST compute the full URI using the request URI.

2.3.  RDAP Conformance

   Servers which implement this extension MUST include the string
   "redirects0" in the "rdapConformance" array in responses to RDAP
   "help" queries.

2.4.  Bootstrap Use Case

   The primary use case of this extension is a one-hop redirect, where
   the client is not interested in the use of this extension beyond the
   first redirect.  Another use case is querying a bootstrap redirect
   server for the authoritative source of information according to the
   IANA RDAP bootstrap information.

   Client Request:

   GET /redirects0_ref/rdap-bootstrap/ip/2001%3adb8%3a%3a1 HTTP/1.1
   Accept: application/rdap+json"

   Server Response:

   HTTP/1.1 307 Temporary Redirect
   Location: https://rir1.example/ip/2001%3adb8%3a%3a/32

   Other uses cases may exist, but for this specific use case, this
   document registers the "rdap-bootstrap" link relationship type.

Brown & Newton            Expires 16 April 2027                 [Page 7]
Internet-Draft           Explicit RDAP Redirects            October 2026

2.5.  Multi-Hop Redirect Limitations

   In some scenarios, a target server might have a policy to issue
   another redirect using this extension.  For example:

Client Request to rdap1.example:

GET /redirects0_ref/rdap-example/exampleFoo_thing/abc HTTP/1.1
Accept: application/rdap+json"

Server Response:

HTTP/1.1 307 Temporary Redirect
Location: https://rdap2.example/redirects0_ref/rdap-example/exampleFoo_thing/abc

   Note "rdap-example" is not a real relationship and is provided only
   for demostration purposes.

   In this scenario rdap1.example is redirecting to rdap2.example with a
   "/redirects0_ref" path.  However, not all servers may support this
   extension.  Therefore, the "/redirects0_ref" path defined in this
   specification MUST only be used in an HTTP redirect if the server
   issuing the redirect is assured that the target server of the
   redirect supports this extension.

3.  noRedirects0 RDAP Extension

3.1.  Usage of noRedirects0

   A client can signal to a server, using the method specified in
   [I-D.ietf-regext-rdap-x-media-type], the preference to not receive a
   redirect using the noRedirect0 extension identifier.  Because there
   is no guarantee that a server can honor this signal, a client MUST be
   capable of processing a redirect if this signal is sent.

   If a server honors the noRedirects0 extension and does not issue a
   redirect, the server MUST respond with an RDAP resource as identified
   by the media type specified in [RFC7480] (i.e., the response cannot
   be a web page or some other resource that is not parsable as RDAP
   JSON).

   The following example demonstrates the noRedirects0 extension in the
   lookup of an IP address.

Brown & Newton            Expires 16 April 2027                 [Page 8]
Internet-Draft           Explicit RDAP Redirects            October 2026

   Client Request:

   GET /ip/192.0.2.42 HTTP/1.1
   Accept: application/rdap+json;exts_list=rdap_level_0+noRedirects0

   Server Response:

   HTTP/1.1 200 OK
   Content-Type: application/rdap+json

   { "rdapConformance" : [ "rdap_level_0", "noRedirects0" ],
     "objectClassName": "ip network",
     "ipVersion": "v4",
     "handle": "NET-EXAMPLE",
     "startAddress": "192.0.2.0",
     "endAddress": "192.0.2.255",
     "notices" : [
       { "description" : [ "Data from RFC9224 origin" ] } ]
   }

3.2.  RDAP Conformance

   Servers which implement this extension MUST include the string
   "noRedirects0" in the "rdapConformance" array in responses to RDAP
   "help" queries.

4.  IANA Considerations

4.1.  redirects0 RDAP Extension Identifier

   IANA is requested to register the following value in the
   [rdap-extensions] Registry:

   *Extension identifier:* redirects0

   *Registry operator:* any.

   *Published specification:* this document.

   *Contact:* the authors of this document.

   *Intended usage:* this extension allows clients to request to be
   redirected to a related resource for an RDAP resource.

4.2.  noRedirects0 RDAP Extension Identifier

   IANA is requested to register the following value in the
   [rdap-extensions] Registry:

Brown & Newton            Expires 16 April 2027                 [Page 9]
Internet-Draft           Explicit RDAP Redirects            October 2026

   *Extension identifier:* noRedirects0

   *Registry operator:* any.

   *Published specification:* this document.

   *Contact:* the authors of this document.

   *Intended usage:* this extension allows clients to signal a
   preference not to be redirected to a resource.

4.3.  Link Relations

   IANA is requested to register the following value into the
   [link-relations] registry.

4.3.1.  rdap-bootstrap

   *Relation Name:* rdap-bootstrap

   *Description:* Refers to an RDAP object for which a reference can be
   derived from RFC 9224.

   *Reference:* This document once published as an RFC.

4.3.2.  rdap-related-top

   *Relation Name:* rdap-related-top

   *Description:* Refers to an RDAP resource related to another RDAP
   resource at the top of a hierarchy, such as a hierarchy described in
   [RFC9910].

   *Reference:* This document once published as an RFC.

4.3.3.  rdap-related-bottom

   *Relation Name:* rdap-related-bottom

   *Description:* Refers to an RDAP resource related to another RDAP
   resource at the bottom of a hierarchy, such as a hierarchy described
   in [RFC9910].

   *Reference:* This document once published as an RFC.

Brown & Newton            Expires 16 April 2027                [Page 10]
Internet-Draft           Explicit RDAP Redirects            October 2026

4.3.4.  rdap-related-up

   *Relation Name:* rdap-related-up

   *Description:* Refers to an RDAP resource related to another RDAP
   resource one level up in a hierarchy, such as a hierarchy described
   in [RFC9910].

   *Reference:* This document once published as an RFC.

4.3.5.  rdap-related-down

   *Relation Name:* rdap-related-down

   *Description:* Refers to an RDAP resource related to another RDAP
   resource one level down in a hierarchy, such as a hierarchy described
   in [RFC9910].

   *Reference:* This document once published as an RFC.

4.4.  RDAP JSON Values

   IANA is requested to register the following value into the
   [rdap-json-values] registry:

   *Value:* redirect not available

   *Type:* notice and remark type

   *Description:* No redirect of the requested type is available for
   this resource.

   *Registrant Name:* IESG

   *Registrant Contact Information:* iesg@ietf.org

5.  Security Considerations

   A malicious HTTP redirect has the potential to create an infinite
   loop, which can exhaust resources on both client and server side.

   To prevent such loops, RDAP servers which receive redirect requests
   for the self relation MUST respond with a 400 HTTP status.

   As described in Section 15.4 of [RFC9110], when processing server
   responses, RDAP clients SHOULD detect and intervene in cyclical
   redirections.

Brown & Newton            Expires 16 April 2027                [Page 11]
Internet-Draft           Explicit RDAP Redirects            October 2026

6.  Operational Considerations

   The benefits of this extension will not materialize if a client
   issues a query using this extension, receives an error, and
   subsequently requeries a server without using this extension.
   Therefore, clients SHOULD NOT use this extension unless the client
   has _a priori_ knowledge of the target server's ability to process
   queries with this extension (because, for example, the server is a
   member of a class of servers which implement a common "profile" such
   as [gtld-rdap-profile]).

   Likewise, servers SHOULD NOT issue redirects in the manner described
   in Section 2.5 unless the origin server has _a priori_ knowledge of
   the target server's ability to process queries with this extension.

   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.

7.  Change Log

   This section is to be removed before publishing as an RFC.

7.1.  Changes from 04 to 05

   *  Documented the noRedirects0 extension which is used in queries.
   *  Switch back to 400 as the status for redirects for search and help
      requests, and provide an example response with a new notice type.
   *  Define new link relations and explain them in the Abstract.
   *  Updated Security Considerations as per WG feedback.
   *  Added Geofeed example (thanks Jasdip).

7.2.  Changes from 03 to 04

   *  Fixed some broken references.

   *  Updated Section 1 as clients will know whether or not the server
      supports this extension.

   *  Added Section 8.

7.3.  Changes from 02 to 03

   *  Consistely refer to "redirect" instead of "referral".  This
      includes changing the extension identifier to redirects0 and the
      document title.

Brown & Newton            Expires 16 April 2027                [Page 12]
Internet-Draft           Explicit RDAP Redirects            October 2026

   *  Added Section 2.4 and Section 4.3.

   *  Correct specification of the redirect query path.

   *  Updated Section 2.3 to limit the use of the extension identifier
      to help responses.

   *  Include 308 in the list of redirection HTTP status codes.

   Thanks to Jasdip Singh for identifying the last three of these
   issues.

7.4.  Changes from 01 to 02

   *  Add reference to [gtld-rdap-profile] which describes how gTLD RDAP
      servers link to registrar RDAP resoures.

   *  Include <base path> in the path specification, and remove the /
      between <relation> and <lookup path> so that naive URL
      construction works.

   *  Reuse the language from RFC 7480 on HTTP status codes used for
      redirection.

   *  Fix HTTP status code in the examples.

   *  Described the risk of redirection loops and things clients and
      servers have to do.

7.5.  Changes from 00 to 01

   *  Switch to using a path segment and a 30x redirect.

   *  Describe how the server behaves when multiple links exist.

7.6.  Changes from draft-brown-rdap-referrals-02 to draft-ietf-regext-
      rdap-referrals-00

   *  Nothing apart from the name.

7.7.  Changes from 01 to 02

   *  add this change log.

7.8.  Changes from 00 to 01

   *  change extension identifer from registrar_link_header to
      redirects0.

Brown & Newton            Expires 16 April 2027                [Page 13]
Internet-Draft           Explicit RDAP Redirects            October 2026

8.  Acknowledgements

   The authors would like to thank the following persons for their
   feedback and advice:

   Jasdip Singh, Pawel Kowalik, Tom Harrison, Ben Schwartz.

9.  References

9.1.  Normative References

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

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

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

   [RFC9910]  Harrison, T. and J. Singh, "Registration Data Access
              Protocol (RDAP) Regional Internet Registry (RIR) Search",
              RFC 9910, DOI 10.17487/RFC9910, January 2026,
              <https://www.rfc-editor.org/info/rfc9910>.

Brown & Newton            Expires 16 April 2027                [Page 14]
Internet-Draft           Explicit RDAP Redirects            October 2026

9.2.  Informative References

   [RFC8805]  Kline, E., Duleba, K., Szamonek, Z., Moser, S., and W.
              Kumari, "A Format for Self-Published IP Geolocation
              Feeds", RFC 8805, DOI 10.17487/RFC8805, August 2020,
              <https://www.rfc-editor.org/info/rfc8805>.

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

   [RFC9877]  Singh, J. and T. Harrison, "Registration Data Access
              Protocol (RDAP) Extension for Geofeed Data", RFC 9877,
              DOI 10.17487/RFC9877, October 2025,
              <https://www.rfc-editor.org/info/rfc9877>.

   [gtld-rdap-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>.

   [rdap-extensions]
              IANA, "RDAP Extensions",
              <https://www.iana.org/assignments/rdap-extensions/rdap-
              extensions.xhtml>.

   [rdap-json-values]
              IANA, "RDAP JSON Values",
              <https://www.iana.org/assignments/rdap-json-values/rdap-
              json-values.xhtml>.

Authors' Addresses

   Gavin Brown
   ICANN
   12025 Waterfront Drive, Suite 300
   Los Angeles, CA 90292
   United States of America
   Email: gavin.brown@fastmail.uk
   URI:   https://icann.org

Brown & Newton            Expires 16 April 2027                [Page 15]
Internet-Draft           Explicit RDAP Redirects            October 2026

   Andy Newton
   ICANN
   12025 Waterfront Drive, Suite 300
   Los Angeles, CA 90292
   United States of America
   Email: andy@hxr.us
   URI:   https://icann.org

Brown & Newton            Expires 16 April 2027                [Page 16]