Hi Gavin, Can RFC 8982 (RDAP Partial Response) [1] not be leveraged to solve this?
Jasdip [1] https://www.rfc-editor.org/rfc/rfc8982.html From: Maarten Wullink <maarten.wullink=40sidn...@dmarc.ietf.org> Date: Friday, May 24, 2024 at 10:28 AM To: Marc Blanchet <marc.blanc...@viagenie.ca> Cc: Gavin Brown <gavin.br...@icann.org>, Registration Protocols Extensions <regext@ietf.org> Subject: [regext] Re: [Ext] New Version Notification for draft-brown-rdap-referrals-00.txt Hi Gavin, Like Marc, i’m not a big fan of duplicating the link information from the json response into the response headers. However, for the HEAD method request i do see a use case, because in this case there exists no data duplication and the client can efficiently navigate the Link headers in the response. anyway, just my 2 cent. Best, Maarten > Op 24 mei 2024, om 15:17 heeft Marc Blanchet <marc.blanc...@viagenie.ca> het > volgende geschreven: > > [You don't often get email from marc.blanc...@viagenie.ca. Learn why this is > important at https://aka.ms/LearnAboutSenderIdentification ] > >> 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 _______________________________________________ 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
