Hi Marc, > On 24 May 2024, at 14:17, Marc Blanchet <marc.blanc...@viagenie.ca> wrote: > >> >> Le 24 mai 2024 à 08:10, Gavin Brown <gavin.br...@icann.org> a écrit : >> >> Hi all, >> >> With my RDAP client implementer hat on, I've been ruminating about how the >> users of my client(s)[1] use them, and some anecdata suggests that in >> general, consumers of registration data - in the domain space at least - are >> often equally if not more interested in the RDAP record of the sponsoring >> registrar than of the registry. >> >> Currently, the only way for me to satisfy this user need is to get the RDAP >> record from the registry, parse it to find the "related" link, and then >> requery for that. >> >> This draft outlines a possible approach to improving the performance of this >> use case, by putting relevant links into the header of the response. The >> client can then use the HEAD method, saving bandwidth and compute resources >> on both sides, and offering a better experience for the user. > > I’m also an RDAP client implementer. ;-). and I’ll be playing devil’s > advocate. The extra query to me is not an issue.
I think it's not significant for ad-hoc queries, but if you are doing RDAP queries in bulk, it can make a difference. > Servers of RDAP data should already have various caching mechanisms (if not, > they are in big trouble…) so the hit to a server is insignificant. In my experience, cache hit rates for RDAP is quite low (20-30%), because a common usage pattern is: listOfDomains.forEach((domain) => doRDAPQuery(domain)); Therefore you don't get a lot of repeat queries, meaning that you have to generate fresh responses each time. Therefore substituring an expensive GET for a cheap HEAD has the potential to be quite helpful. > For the client, an extra http query is also insignificant (by comparison, a > single web page is often 10-20… queries). For the two step process (parsing > + query), it is something that a good design would do asynchronously so it > has no material impact on the user experience or UI or else. Again, you're right for activity driven by a user, but not for automated bulk activity. And on your second point, by its very nature it's not possible to do the "two step" process asynchronously, since the output of the first step is an input to the second. > On the bandwidth usage, for GET request, it will be duplication of all links > within the RDAP JSON into HTTP headers, therefore consuming more bandwidth > (and resources). And if we have a lot of related links (there are many > already), then we are just putting a lot of duplicated stuff in the HTTP > headers for no necessary use. Servers are not required to include all links, they could just include the "related" link(s), and in the gTLD space at least, there would only ever be one "related" link with the "application/rdap+json" media type. > As a client implementor, I’m not sure I should trust the HTTP headers, as > they may be missing links or maybe wrong: the source of truth is the JSON, so > I’ll be parsing the JSON anyway. I don't see why you would not trust the HTTP headers, they come from the same source as the body. And the draft does not suggest that clients can do away with parsing JSON, since the client would fall back to parsing the JSON body in the event that the links are not present in the header, and the ultimate aim is to parse the registrar response anyway. > On the server side implementation, my guess is that for generality, a server > implementor may not want to duplicate data, but instead itself parse the > JSON/database and then extract the links and create HTTP headers, in this > case, this will be way more work for the server to implement this. That seems like a perverse way to do it, given the whole point is to save the cost of generating the RDAP response. I can't imagine any server implementer would do it that way. They would just not implement the specification. G. -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://www.icann.org _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
