On Thu, Mar 26, 2026 at 09:15:47AM -0400, Andy Newton wrote:
> On 24-03-2026 2:43 AM, Tom Harrison wrote:
>> On Tue, Feb 17, 2026 at 07:09:16AM -0800, [email protected] wrote:
>>> 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.
>
> Is this the right doc to clear up what "related" means?
The problem is that if there isn't any clarifying text, it would be
very easy to interpret this document as saying that the "related" link
relation is specifically for registrar resource links. Maybe a
simpler way to address this is to replace:
An example of a redirect request from a domain registry to a
domain registrar
with:
An example of a redirect request from a domain registry to a
domain registrar, where the domain registry implements
[gtld-rdap-profile]:
>> (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?)
>
> It is 3.2 of the TIG:
> https://itp.cdn.icann.org/en/files/registry-operators/rdap-technical-implementation-guide-21feb24-en.pdf
Ah yep, thanks.
>>> 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.
>
> Except the request is not malformed. A 409 is probably a better candidate.
Yep, makes sense.
>>> 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*".
>
> Ok. We can create an example relationship type for demonstration
> purposes instead of using rdap-top.
>
> That said, does RIR Search not provide a way to express a
> relationship between a resource transferred into one RIR from
> another?
No, it's limited to the resources within a single registry. (If it
were cross-registry, then server implementors would be stuck trying to
merge objects from multiple servers in the multiple-object response
cases, and there wasn't an obvious way to deal with that problem.)
> If I have a /24 at LACNIC that was transferred from ARIN, when
> querying the LACNIC server is there no way to find my way back to
> the parent allocation at ARIN?
Not via RDAP, at least as far as I know.
-Tom
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
