Hey, I'm +1 for this, I think it's a great idea. However, below is my best attempt to argue the other side of this. Mind you, I'm not actually sure this is a good argument against but I'm trying to come up with something.
1. Let's say I'm a registry operator, and I receive a HEAD request for example.com 2. I return the Link headers, but since I'm the authoritative registry for .com, I'm essentially saying "yeah, I have this data" 3. Client Behavior: The client then makes a GET request to retrieve the full record 4. Result: I've now handled 2 requests instead of 1, doubling my connection overhead In terms of overhead I still have to: - Authenticate the request (maybe) - Check authorization/access controls (maybe) - Query the database - Apply redaction policies - Generate the response structure The only thing saved by HEAD is bandwidth for the JSON body, but most processing still happens and I had to do it twice now. A On Tue, Aug 19, 2025 at 4:22 PM Jasdip Singh <[email protected]> wrote: > > Hi, > > Not sure yet if we should adopt this draft but some input to help decide: > > The Link header approach, using the HEAD method, seems a simpler and more > efficient way to just get the web links info; especially for > bandwidth-constrained environments. It however seems more complex > parsing-wise (to Mario’s point) but that should not be a problem if > programming libraries already support getting them from an HTTP response. > > Since the web links are grouped together for each RDAP object returned in an > RDAP query response, not sure if that grouping knowledge would be lost when > they are “unionized" in one or more Link headers returned. Probably, this > seems a minor concern. > > Comparing it with the RDAP Partial Response (RFC 8982) approach, only the > HEAD method use seems closer response size-wise. Obviously, including Link > headers in a GET response for RDAP would end up increasing the response size > but probably not that significantly. > > As for using RDAP Partial Response extension for lookup queries (besides > search queries), not sure if we intended so. :) AFAICT, that RFC does not > explicitly seem to cover RDAP lookups. > > Architecturally, heeding the advice from RFC 1958 3.2 [1], would additionally > doing Link headers beside RDAP partial responses be considered another way to > get the same info (bad), or an improvement over the latter (good)? Seems an > improvement, no? :) > > Thanks, > Jasdip > > [1] https://datatracker.ietf.org/doc/html/rfc1958#autoid-3 > > From: Mario Loffredo <[email protected]> > Date: Tuesday, August 19, 2025 at 1:11 PM > To: [email protected] <[email protected]> > Subject: [regext] Re: [Ext] request for adoption: draft-brown-rdap-referrals > > Hi Gavin, > > please find my comments inline. > > Il 19/08/2025 17:42, Gavin Brown ha scritto: > > Hi Scott, > > On 15 Aug 2025, at 19:32, Hollenbeck, Scott <[email protected]> wrote: > > [snip] > > RFC 8982 may or may not provide the model, but we will need a document in > either case. If the WG adopts this document, it can be developed with the > input > and guidance of the WG. > > [SAH] We already have a document in 8982. I'd like to understand if this > draft solves a problem that isn't solved by 8982. > > RFC 8982 only applies to search queries. That's clunky but presumably we > don't care too much about that. > > [ML] Its logical field of application is the RDAP search because it aims to > limit the amount of information returned, which in a search response could be > remarkable. But it can also be applied to RDAP lookups. > > Honestly, it seems to me that parsing the content of a link header is more > complex than getting the same information from a JSON structure, and since > the payload of a search response is manageable, I wonder what the real > benefit is. > > It may be that all this document needs to do is standardize the value of the > "fieldSet" parameter. Unless clients and servers agree on that, there can be > no interoperability. > > [ML] Don't see the complexity gap between agreeing on the value of the > fieldSet parameter and agreeing on an extension identifier. > > What makes a difference IMO is that an extension identifier is registered > while the fieldSet parameter value isn't. > > But RFC8982 can be updated to create a new IANA registry. > > > Best, > > Mario > > > G. > > -- > Gavin Brown > Principal Engineer, Global Domains & Strategy > Internet Corporation for Assigned Names and Numbers (ICANN) > > https://www.icann.org > > _______________________________________________ > regext mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > -- > Dott. Mario Loffredo > Senior Technologist > Technological Unit “Digital Innovation” > Institute of Informatics and Telematics (IIT) > National Research Council (CNR) > Address: Via G. Moruzzi 1, I-56124 PISA, Italy > Phone: +39.0503153497 > Web: http://www.iit.cnr.it/mario.loffredo > > _______________________________________________ > regext mailing list -- [email protected] > To unsubscribe send an email to [email protected] _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
