Hi Gavin, Just saw -02 come in but nevertheless few more comments here. :)
Thanks, Jasdip From: Gavin Brown <[email protected]> Date: Thursday, January 22, 2026 at 11:13 AM To: Jasdip Singh <[email protected]> Cc: [email protected] <[email protected]> Subject: Re: [regext] [Ext] I-D Action: draft-ietf-regext-rdap-referrals-01.txt > 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. [JS] Yah, this is a bit tricky. E.g., a 301 response might include a body. Don’t have a strong opinion here. 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. [JS] Yep. > 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. [JS] OK. > “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. [JS] I think this extension id should only be included in the “rdapConformance” array for the help response, since that signals server capabilities. For non-help responses, an extension id is expected to be included in the “rdapConformance” array only if the server used that extension to construct the response, which would be moot for these referral responses, no? -02 feedback: Section 2: Wonder if the “<base path>” introduction is necessary? In the base spec (RFC 9082), typically a new path segment is introduced as a relative path and the examples start with the “https” scheme. IMO, might be good to emulate that. Section 3: Curious why we are still limiting 3xx responses to section 5.2 of RFC 7480? Granted 308 (Permanent Redirect) happened after RFC 7480 (AFAIK) but it seems a more appropriate response code than 301 (Moved Permanently) if one wants the HTTP method in the request to not be changed in the redirect.
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
