> 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. 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. 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. 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. 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. 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. While I see the idea behind your proposal, I think it may not be needed. At least, I don’t see value for me to implement it. :( Regards, Marc. > > Feedback is welcome! > > G. > >> Begin forwarded message: >> >> From: <internet-dra...@ietf.org> >> Subject: [Ext] New Version Notification for draft-brown-rdap-referrals-00.txt >> Date: 23 May 2024 at 20:42:19 BST >> To: Andy Newton <andy.new...@icann.org>, Gavin Brown <gavin.br...@icann.org> >> >> A new version of Internet-Draft draft-brown-rdap-referrals-00.txt has been >> successfully submitted by Gavin Brown and posted to the >> IETF repository. >> >> Name: draft-brown-rdap-referrals >> Revision: 00 >> Title: Efficient RDAP Referrals >> Date: 2024-05-23 >> Group: Individual Submission >> Pages: 6 >> URL: https://www.ietf.org/archive/id/draft-brown-rdap-referrals-00.txt >> Status: https://datatracker.ietf.org/doc/draft-brown-rdap-referrals/ >> HTML: https://www.ietf.org/archive/id/draft-brown-rdap-referrals-00.html >> HTMLized: https://datatracker.ietf.org/doc/html/draft-brown-rdap-referrals >> >> >> Abstract: >> >> This document describes how RDAP servers can provide HTTP "Link" >> header fields in RDAP responses to allow RDAP clients to efficiently >> determine the URL of related RDAP records for a resource. >> >> >> >> The IETF Secretariat >> >> >> -- >> 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 _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
