Hi Marc, > On 17 Jun 2024, at 14:23, Marc Blanchet <marc.blanc...@viagenie.ca> wrote: > >> Le 17 juin 2024 à 07:45, Gavin Brown <gavin.br...@icann.org> a écrit : >> >> 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. > > If one look at just http patterns nowadays (just a single simple web page), > this extra query just disappears in the noise.
I don't think that is a statement that has any relevance to the use case I am trying to account for. >>> 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. > > I don’t understand your point. RDAP objects are relatively long-live. So one > can subscribe to a caching service and have its data cached. That's one way to implement RDAP but I suspect probably not the most common one. A much more likely implementation is live generation + a caching reverse proxy like Squid/Varnish/$CDN, just like every other web app. Those front-end servers will not keep warm caches, and their caches are probably not shared between instances, AZs or regions. And many RDAP server operators are required to invalidate their cache every so often in order to ensure that changes to registration data become visible within a time dictated by an SLA. >>> 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. > > Why not? When I do an async call in swift (like in JS or else), the > following code is put aside waiting for the answer. That code when answer > arrives, just get executed and then can redo another call. I don’t get your > point. Async in two steps is pretty straightforward. I think I misunderstood you when you said "asynchronous", I took that to mean "in parallel". Obviously an RDAP client cannot do query to the registrar RDAP server in parallel to the query to the registry RDAP server, as it needs to the registry response in order to learn the URL of the registrar server. But again, the use case you're basing your argument from is that of an interactive client, where the benefits of my proposal will not be all that great. That is not the only use case for RDAP. >>> 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. > > I have a hard time thinking that we would send partial responses. Not a good > idea in my mind. That is not something I am suggesting. >>> 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. > > I think we agree: as a client, given that data is at best identical, or maybe > not coherent, then the source of truth is the JSON. Therefore, I will just > ignore the HTTP headers. You do you :) > 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. > > Right. Which means that we are back to square 1. No, because for some subset of RDAP servers, the benefits will outweigh the costs, assuming a reasonable level of client adoption. Obviously I am not arguing that this extension be mandatory, but there will be some client and server implementers for whom it will be valuable. 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
