> On 26 Jan 2026, at 4:46 pm, Jasdip Singh <[email protected]> wrote: > > 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/ > [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?
Yes, you're right, as RFC 9082 specifies that <lookup path> does not have a trailing slash (so it can be concatenated with a Base URL, which always has a trailing slash). This will be fixed in the next version. > > 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. > :) Agreed. BTW, I had already planned to get some HTTP people to review this draft, but it would be good to hear from client implementers! 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]
