Hi Jasdip,

> On 17 Dec 2025, at 5:15 pm, Jasdip Singh <[email protected]> wrote:
> 
> Hi Gavin, Andy,
> 
> After perusing the draft more carefully, wanted to share few more 
> observations (in no particular order):
> 
> "/referrals0_ref/<relation>/<lookup path>” … Should this not be 
> "referrals0_ref/<relation>/<lookup path>” without the leading slash since we 
> want this path to be relative?

Yes, it probably should. The next version will correct that.

> In case there were a successor extension in the future (say, “referrals1”), 
> would it help to return the “referrals0” extension id in the returned 
> Content-Type header for the redirection response, as part of the “exts_list” 
> parameter value for “application/rdap+json”?

I am unsure how appropriate it is to include a content-type header in a 
redirect response which does not include a body.

I note that there is a proprietary RDAP extension "RDAP Redirect with Content" 
which describes a server response with both a redirect and a body; for those 
responses, a server which implements draft-ietf-regext-rdap-x-media-type MUST 
include "referrals0" in the "exts_list" parameter.

> Since this is more likely for more generic relation types (say, “alternate” 
> or “related”), how should the server behave when there is a possibility to 
> pick from multiple links for the given relation type?

The document states that this is for the server to decide. While it is possible 
for there to be multiple links, we believe this is unlikely, and accounting for 
it greatly increases the complexity. So, the server can pick which one it sends.

> Do we want to allow “self” in <relation> since (IIUC) it could become an 
> attack vector (redirection loop)?

We'll add something to the security considerations about this.

> In examples, replace 200 with 3xx?

Noted, thanks.

> “Servers which implement this specification MUST include the string 
> "referrals0" in the "rdapConformance" array in all RDAP responses.” … Should 
> this exclude search responses given the applicability of this extension to 
> just lookups? Including in the help response should be ok.

No, I think it needs to be all responses, since it indicates *server* 
capability, not just the server's capability to extend search.

> In the returned Location header, could a relative URI be returned? Looks like 
> it could if the “href” for the selected link was so. Not sure if it would 
> help to include such an example for clarity.

The "location" header could return a relative URL. My guess is that any 
existing HTTP client handles relative URLs properly, but it's worth noting in 
the text. This will be added.

Thanks,

G.

--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)

https://www.icann.org

_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]

Reply via email to