OK. There are some things here that we need to discuss, but I'm convinced that they're worth discussing. +1 for adoption.
Scott From: Jasdip Singh <[email protected]> Sent: Tuesday, August 19, 2025 4:23 PM To: Registration Protocols Extensions <[email protected]>; Mario Loffredo <[email protected]> Subject: [EXTERNAL] [regext] Re: [Ext] request for adoption: draft-brown-rdap-referrals Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. 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<https://secure-web.cisco.com/1WyyWwUS9smsU0dQekLJ8GN1StOLLhnYZbAjpfp9AGRmmEeJLDzOnDtJ1Bpgz8jiS_l8NdXKtbSChooDpkCWORgEBikwraUo9Jwi-RUu1DH_ydEfmDtPuipjaekm8yfOPxvNbuzmBoDQXRVJIF8hpfoK759dvXBGmKBbUqtJ4aFELdA3wNH6UT_WJcSuiGkUuiVdASgmvIsIx4Gs_f5tLM6eAFp0oVbv0tIUyDVaotEZ7JkSeJ7D1Tc6VL9QQCN6aHjzGUzuSDZZRQXDBMS_yiKf40i9NfRhH25hj4uVCkRnbU3ElT3rmjH2-IpvClHOG/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Frfc1958%23autoid-3> From: Mario Loffredo <[email protected]<mailto:[email protected]>> Date: Tuesday, August 19, 2025 at 1:11 PM To: [email protected]<mailto:[email protected]> <[email protected]<mailto:[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]><mailto:[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<https://secure-web.cisco.com/1VmJvc_Q56NaB8wKsZ1SdU8pIqfMEQJw6Pc-ZssZbp-oFS93UqjkPB8gGCh4kj8tGWqB7M_px_OCZW-JpzS7PaIDdgTG2kOuB4g41qCoK5eNdqyOHdaXs2IjUtLXAvXVp0fp7JdmSS6NliUgr263g9AuFahJo2P4nf3xBKrWz-QISNF_HEsUV9p70aUugSLyLTdbcYCDstxM13gVJ369OSUFSXwoREoHUjwKOx1AUfrIKVUF7-qYbN6FNxGYdn8MVb2hg7P-Osi8nutoL2rXOKzyyrLOWnZrZ7w8vivag9I6ofPjHax01Fd1zkLxDkiDm/https%3A%2F%2Fwww.icann.org> _______________________________________________ regext mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[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<http://secure-web.cisco.com/1MLMF743ZOdMgIQFDXQYsiEyGhDQqc5PMmxF0MZys_o5mTLifL8RTCwA3ywUEFEq8QKD_pnqBLwLFl-m9bX0xTF4lv8iUWE4pgGHyydwe3nnAQ2Z5S_Mq8qJmUHBqtYCaV3YH4xHncVI-F0fmL4d1GBa5H2Y32QGUyBIxlhwJspRQ8Yf77_0W26WWPl_eWTC-011Dg0fuccPgZVOthH9nCuO6GbE8UqzLAWr40E0cEik6ofCCHqHI6T4NbeZtO3HFYlW9idKh9KHnUA7n9f1zyQETzP0JXl6uAhHax_EgQiS2AEl0ZZjMmd-hsb7yWB_F/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo>
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
