On Tue, Feb 17, 2026 at 07:09:16AM -0800, [email protected] wrote:
> Internet-Draft draft-ietf-regext-rdap-referrals-03.txt is now available. It is
> a work item of the Registration Protocols Extensions (REGEXT) WG of the IETF.
>
> Title: Explicit RDAP Redirects
> Authors: Gavin Brown
> Andy Newton
> Name: draft-ietf-regext-rdap-referrals-03.txt
> Pages: 10
> Dates: 2026-02-17
>
> Abstract:
>
> This document describes an RDAP extension that allows RDAP clients to
> request to be redirected to a related RDAP record for a resource.
>
> The IETF datatracker status page for this Internet-Draft is:
> https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-referrals/
>
> There is also an HTML version available at:
> https://www.ietf.org/archive/id/draft-ietf-regext-rdap-referrals-03.html
>
> A diff from the previous version is available at:
> https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-referrals-03
Thanks for this document. Some comments:
> 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]), while in the IP address space, an
> RDAP record for an address allocation may include links to enclosing
> or sibling prefixes.
Some IP address registries have a problem that is closer to the
registry-registrar problem in the domain name space, in that there are
delegated address registries that host their own information about the
relevant resources, but users might also be interested in the
information that the RIR has directly. At least for APNIC, those
delegated registries are national internet registries (NIRs). The way
we handle this problem is by using the redirect_with_content
extension. (This extension may not be a good fit for the domain name
use case, because the scenarios are not 1:1, but noting here in case
it might be helpful.)
> An example of a redirect request from a domain registry to a domain
> registrar:
>
> Client Request:
>
> GET /redirects0_ref/related/domain/example.com HTTP/1.1
James Mitchell had an earlier comment on this point:
The registrar example is given as domain/link[rel=related]. I
assume the use of the related relation is defined in ICANN's RDAP
profile; it might be best to be explicit.
It looks like there has been an attempt to address this, but I think
it needs to be clearer, in order to avoid any potential confusion.
Suggested (not sure where it should be put, but anyway):
The "related" link relation does not of itself indicate that the
associated link is for a registrar resource. There are profiles
that ascribe this behaviour to that link relation, though: see
e.g. [gtld-rdap-profile]. Clients should ensure that link
relation interpretations take into account the original link
relation definition, as well as any adjustments or refinements to
that definition that have occurred by way of extension
implementation.
(Though having said that, I can't find the part of the gTLD profile
that requires this behaviour with respect to "related" links. Would
you be able to point me to that?)
> 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.exampple.net/redirects0_ref/rdap-up/ip/192.0.2.42
RIR search already defines URLs for this, so while it might be
possible to use this specification in this way, I think it would be
better either to limit the examples to link relations that do not have
alternatives (like "related"), or to note that while the RIR search
link relation types are usable in the redirects0_ref context, clients
would be better off using the existing RIR search URLs directly. (A
concrete reason for preferring those URLs over the redirects0_ref
example above is that RIR search links are an optional element in RDAP
responses, and a server implementor may return 404s for such referral
queries even when the underlying search is supported by way of the
original RIR search URL.)
> 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.
I don't think this behaviour is a good idea. For a link relation type
like "related" (outside of the gTLD RDAP profile context), it's easy
to imagine there being multiple links having that type, and that new
links might be added/removed at arbitrary points in time. That would
lead to inconsistent results even within the context of a single
server. I think it would be better to say that servers implementing
this document must either:
- include in the response at most one link with a given relation
type; or
- return 400 (or similar) where a referral request is submitted and
the relevant object has two or more links with the specified type.
> 5. Bootstrap Use Case
A bootstrap link could be useful in some cases, but it's not clear to
me how it would be useful in the referral context. A client that
knows ahead of time that it wants bootstrap information should either
use the RFC 9224 process directly, or send its queries to a known
bootstrap server.
> 6. 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 rir1.example:
>
> GET /redirects0_ref/rdap-top/ip/2001%3adb8%3a%3a1 HTTP/1.1
> Accept: application/rdap+json"
>
> Server Response:
>
> HTTP/1.1 307 Temporary Redirect
> Location: https://rir2.example/redirects0_ref/rdap-top/ip/2001%3adb8%3a%3a/32
I think the better reading of the RIR search document is that it does
not support responding to requests in this way. See e.g. section
3.2.1: 'The "parent' object is the next-least-specific object that
exists *in the relevant registry*".
-Tom
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
