Hi, Inputting here to share thoughts on the discussion so far, and some more. :)
If the rationale for this extension is to help clients look for a target of the most appropriate web link (needle) in a lookup response (haystack), then wonder if that should simply be its focus and not links in other types of responses like search? Asking so while realizing that a search response with a single object response seems equivalent to a lookup. If this extension's purpose is to simply select the most appropriate link from a lookup response, then proposing a new “rdap-bootstrap” relation (and related use case) seems extraneous, given RFC 9224 already enables a server to redirect for IANA allocations to other registries. We might have discussed this before. :) If we end up limiting this extension to just lookup paths and no more, then a 400 (Bad Request) response can help simplify for all non-lookup scenarios (sections 2.1 and 5). That said, yes, both 409 and 422 don’t see appropriate here. As for the multi-hop redirect scenario, that should be ok as long as the redirect URL caters to the same lookup but with a different authority. One “taxonomy” input: Wonder if we should rename this extension as “redirect0” instead of “redirects0” since it is intended to return mostly one redirect URL (unless we take up Pawel’s 300 (Multiple Choices) response suggestion)? May be just me but found “redirects” confusing in the sense whether it is meant as a verb or as a plural. Regarding "<base URL>redirects0_ref/<relation>/<lookup path>”, if we stick with catering to non-lookup scenarios like search then for clarity the "<lookup path> with the lookup path of the object being sought” verbiage should be evolved. Minor observations: "an RDAP record for an address allocation may include links to enclosing or sibling prefixes” … AFAICT, a link for a sibling prefix is not so far returned in any number resource response. Unless missing something vis-a-vis relation searches from RFC 9910. :) Nit: resources(s) -> resource(s) ? Thanks, Jasdip From: Pawel Kowalik <[email protected]> Date: Friday, July 3, 2026 at 9:46 PM To: Andy Newton <[email protected]>; [email protected] <[email protected]> Subject: [regext] Re: I-D Action: draft-ietf-regext-rdap-referrals-04.txt Hi Andy, On 03.07.26 20:35, Andy Newton wrote: > > On 7/3/26 10:58 AM, Pawel Kowalik wrote: >> PK> 404 is imho the most appropriate response, especially if the answer >> to the above is that certain searches are not supported (case b). > 404 would be appropriate if there were no resources. But for searches where > there is too much data, what is the right answer? The client formulated the > query correctly and the data exists, it is just in a form that that would > yield an unpredictable result. > > Rereading the text, /help should yield a 501. That should be broken out into > a separate rule IMHO. PK2> This is why I was asking, what "searches" means. If it is about rfc9082 3.2 search path segments, than 404 is OK, because such resource basically does not exist, as long as single result search is not supposed to deliver a result. Example of search, where imho 404 is appropriate: https://example.com/rdap/redirects0_ref/related/domains?name=example*.com Reading the draft again I see in Section 2 <base URL>redirects0_ref/<relation>/<lookup path>, where <lookup path> suggests to apply only to rfc9082 3.1. If this is right, text shall be clear about it and the mention of /help should not be there at all, because it's also not a lookup path. In both cases 404 is also convenient for the implementation, because you would map the route {base}/redirects0_ref/{relation}/domain/{name} and not {base}/redirects0_ref/{relation}/domains/ or {base}/redirects0_ref/{relation}/help - these would yield 404 automatically in the frameworks I know. To generate any other response the path would need to be mapped, so 501 is not practical. If the sentence is about the situation, where lookup query returns one result, (e.g. http://rdap.example.com/ip/192.0.2.0/25) but contains more than one link of a relation type (e.g. 2 "down" links in http://rdap.example.com/redirects0_ref/down/ip/192.0.2.0/25), then 300 would be the best-fitting choice. 300 per rfc9110 should however deliver a list to choose from - rfc9264 can be helpful and appropriate here. 406 can be also an alternative - given a very broad interpretation of "acceptable representation". Assuming that the client expects to receive a Location URL and it cannot be given - maybe good enough. Both of those choices are related to content negotiation in rfc9110, so if one is of an opinion this is semantically too far, then 400 is likely the only possible choice. Kind Regards, Pawel
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
