Hi Gavin, From: Gavin Brown <[email protected]> Date: Monday, January 26, 2026 at 10:24 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
> > “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? I stand corrected. RFC 9083 says "A response to a "help" request will include identifiers for all of the specifications supported by the server. A response to any other request will include only identifiers for the specifications used in the construction of the response." So the next version will correct this statement. [JS] Great! > -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. There are two reasons: 1. naive clients which just concatenate path segments together 2. servers which do not "normalise" request paths. If you have a base path which is "/", a format for the request path which is "/referrals0_ref/<relation>/<lookup path>", a relation of "related" and a lookup path which is "/domain/example.com <http://example.com/>", and you do naive concatenation, you end up with a request path of "//referrals0_ref/related//domain/example.com". For many HTTP servers, those double slashes are normalised, but there are also many HTTP servers which don't do this. So for some servers the above request path works, and for some servers it doesn't. Without explicit instruction in how to construct the request path, you have an interoperability problem. [JS] OK. One further observation. The -02 draft currently says: "<base path>referrals0_ref/<relation><lookup path>”. To your point, should it be “<base path>referrals0_ref/<relation>/<lookup path>” instead, and that the “<lookup path>” is relative? > 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. While RFC 7480 says (at the top of Section 5) that "no standard HTTP response code is forbidden", Section 5.2 then seems quite clear on the HTTP status codes that should be used to do redirects, even if it doesn't use a BCP14 keyword. Would an RDAP client implementation sticking solely to RFC 7480 struggle to process a 308 response, because RFC 7480 does appear to limit redirects to 301, 302, 303 or 307? [JS] Since this spec is presently explicit about which 3xx responses (currently limited to those from section 5.2 of RFC 7480) to return, not explicitly including a more recent 308 in that list might confuse some server implementors as to picking a less-appropriate 302 instead. Though, to your question, clients shouldn't struggle processing a 308 even if a server sends it in spite of exclusion from that 3xx list. Good to get other opinions here. :) Thanks, Jasdip
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
