Hi Jasdip, inline...
On 7/4/26 1:07 PM, Jasdip Singh wrote: > 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. I was confused. I think we want lookups only. > > 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. :) We probably did, and I forgot where we landed. So, without previous recollection... the rdap-bootstrap case can be used when a bootstrap server has other redirect behavior. For example, it is possible that a bootstrap server can construct its redirects from the NRO extended stats files thus offering clients a direct path to the server holding the resource instead of bouncing between RIRs. And there are other example I can think about, such as a bootstrap server that offers IP to ASN mapped redirects. All this is to say that "rdap-bootstrap" is a way for the client to say "I want the 9224 redirect". It also allows a typical resource server to function as a bootstrap server. For example, the server at .example should produce a 404 for "foo.not_an_example" but if handed "rdap-bootstrap" could then redirect to a more appropriate place. > > 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. Agreed. My apologies for the confusion. > > 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. The Operational Considerations section says don't create redirect loops, which should cover this. > > 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. Probably. -andy _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
