Hi James, Thanks for the feedback, my responses are below.
> On 17 Dec 2025, at 8:23 am, James Mitchell <[email protected]> wrote: > > Hi Gavin, > > I've only given this a passing look but have a few comments: > > The registrar example is given as domain/link[rel=related]. I assume the use > of the related relation is defined in ICANN's RDAP profile; it might be best > to be explicit. Yes, it is. We'll add a reference to the next version. > It is worth noting that the server may not know the link's content-type and > therefore cannot be expected to match the requested Accept: header. This may > be important where a server uses a relation type for another purpose. You > should consider limiting redirects to known/assumed RDAP URLs. I believe this is already adequately addressed in Section 3.1. > If the server doesn't have a RDAP URL for a registrar (or requested > relation), how should it respond? Consider the nic.tld names that have a > special registrar as an example. I would assume that a 404 would be > misleading for a client given it wouldn't know whether the resource or > relation does not exist. It should respond with a 404. This will be added in the next version. > The path-based approach works where target of the initial redirect is the > organization that can answer for the desired object, but not if there is an > intermediate organization. This may be outside the design goals, but a > hypothetical TLD -> 2LD -> Registrar relationship would see the intent lost > on the first redirect, unless the first redirecting server knew the > capabilities of the intermediate. > Getting outside my knowledge here, there may be such relationships in the > number space when considering transfers between RIRs then referrals to LIRs. > Repeatedly following some relations would not make sense, e.g. rdap-up. > Again, may be outside the goals of this draft. This is worth thinking about, but I think we would like to hear more from the numbers people as to whether it is a use case we need to consider. If it is, how would you propose addressing it? If we can't use a path-based approach, then we can vary the HTTP method, define new header fields, or use request parameters. Thanks, -- 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]
