> 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. > >> 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. > >> 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. > >> 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. > >> 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. > >> 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. Marc. > > 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
