Gavin, I mirror the other feedback with the concern over duplicating the link information in the response header that is included in the response body for the HTTP GET. It would be best just to support the HTTP HEAD, but the question I have is whether the use of the HTTP HEAD is appropriate, where in RFC 7480 the HTTP HEAD is meant to determine the existence of data on the server and not meant to be used as a form of filtering. How about creating an RDAP extension that defines a query parameter that can be used for selecting / filtering of information to include in the response, where in this case all that the client desires is the "links" information? Keep the information in the response body and enable the client to specify the set of data desired, which can be leveraged for additional forms of selection to reduce client/server overhead and network bandwidth.
Thanks, -- JG James Gould Fellow Engineer jgo...@verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 5/24/24, 8:10 AM, "Gavin Brown" <gavin.br...@icann.org <mailto:gavin.br...@icann.org>> wrote: 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 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. Feedback is welcome! G. > Begin forwarded message: > > From: <internet-dra...@ietf.org <mailto: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 <mailto:andy.new...@icann.org>>, Gavin > Brown <gavin.br...@icann.org <mailto: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://secure-web.cisco.com/1C168OhqKLJlCMFOJMqKYyK1mU9oMD97408Qm6Tsa4rmaXMzltwMWmYL-yUeN6-c7R-Z-v7ZVISBMdESkinVPkqBScWVIxcGgnAforZOzqDLsZN99Sxd8eYqpZXvW9dJVomXAvCGknD-sz0EoK9fAqa504-oQ-I96r1QUQplWeEEuMJ1BZi-VDW4R6Zpapr-lqThOtzrbKzJHIiu2Z9z7VbcBc9V2-qejl9G3hytV0O4FnBRcVfANHwZrHvi-DqswQDK48nBnSdBSW4HQ-KdA_Ro5OjpCNFcnxtabGwXiFLHmK9ktMP1OgtewZKQGgRIh/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-brown-rdap-referrals-00.txt > > <https://secure-web.cisco.com/1C168OhqKLJlCMFOJMqKYyK1mU9oMD97408Qm6Tsa4rmaXMzltwMWmYL-yUeN6-c7R-Z-v7ZVISBMdESkinVPkqBScWVIxcGgnAforZOzqDLsZN99Sxd8eYqpZXvW9dJVomXAvCGknD-sz0EoK9fAqa504-oQ-I96r1QUQplWeEEuMJ1BZi-VDW4R6Zpapr-lqThOtzrbKzJHIiu2Z9z7VbcBc9V2-qejl9G3hytV0O4FnBRcVfANHwZrHvi-DqswQDK48nBnSdBSW4HQ-KdA_Ro5OjpCNFcnxtabGwXiFLHmK9ktMP1OgtewZKQGgRIh/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-brown-rdap-referrals-00.txt> > Status: > https://secure-web.cisco.com/1oTbhjgNGQpvfE9pE8qR7AFqXt_9f7gWY_tuPFHrEStdkpI_4TA4aRFmo5DKLJFwO-Ly5dKMOoKJNrZUSTlTi48Qud0Hc7Q7h3RIYDxQjuA1h81qdXm_J6IyLy8CyZJgFJlNJ50fd8AE_AGeVw6MyMg5gvdLgEQ6XlL_mg2AieN7oD-jsoZF9MCSw7HmLVX18WQMAJeVWV8Cx0rcPkliYKtMR-C8xlkbaR4kF3Eq2F9M_fVxasHPNHLn2Uym0HutoCfDKhBIoho7rDlCqhAOjeyhr2N7dssdYHb7Nq4SttAfTdGzTTTHtFisLOTUdOohQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-brown-rdap-referrals%2F > > <https://secure-web.cisco.com/1oTbhjgNGQpvfE9pE8qR7AFqXt_9f7gWY_tuPFHrEStdkpI_4TA4aRFmo5DKLJFwO-Ly5dKMOoKJNrZUSTlTi48Qud0Hc7Q7h3RIYDxQjuA1h81qdXm_J6IyLy8CyZJgFJlNJ50fd8AE_AGeVw6MyMg5gvdLgEQ6XlL_mg2AieN7oD-jsoZF9MCSw7HmLVX18WQMAJeVWV8Cx0rcPkliYKtMR-C8xlkbaR4kF3Eq2F9M_fVxasHPNHLn2Uym0HutoCfDKhBIoho7rDlCqhAOjeyhr2N7dssdYHb7Nq4SttAfTdGzTTTHtFisLOTUdOohQ/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-brown-rdap-referrals%2F> > HTML: > https://secure-web.cisco.com/1Le2oR6xwfRdtYw_7TLF_OfVubqaRx_JZYxpTjrEa4idaeLF4nOe_XBERkktweHUaIj7vyG4N4b8BY_x4N6o2Ezqc9wKjgeC3Bn4cQtFIV9hvjVFTT-JIR5RNapOCSX5Hufi3qSOuXI44gEWmGJIJkLi5B9xQT7M-XjuzHI2_lFKabL-_9PND6XF3IpSL2J7Ll0DbazTpuiBvjIonCMk4HWyomgkRYTlmZz4lP1uNYYsdmwTqwQTG_8-Ew2OVq0a5EjXpBdAWGukwpyYVMO6ajjRSlFA68zlitevRR__eO63HjbTqgBea3yJcQ-XFdvTk/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-brown-rdap-referrals-00.html > > <https://secure-web.cisco.com/1Le2oR6xwfRdtYw_7TLF_OfVubqaRx_JZYxpTjrEa4idaeLF4nOe_XBERkktweHUaIj7vyG4N4b8BY_x4N6o2Ezqc9wKjgeC3Bn4cQtFIV9hvjVFTT-JIR5RNapOCSX5Hufi3qSOuXI44gEWmGJIJkLi5B9xQT7M-XjuzHI2_lFKabL-_9PND6XF3IpSL2J7Ll0DbazTpuiBvjIonCMk4HWyomgkRYTlmZz4lP1uNYYsdmwTqwQTG_8-Ew2OVq0a5EjXpBdAWGukwpyYVMO6ajjRSlFA68zlitevRR__eO63HjbTqgBea3yJcQ-XFdvTk/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-brown-rdap-referrals-00.html> > HTMLized: > https://secure-web.cisco.com/1vb_1Kiw_Wv4PBnsJqopt-iGfgyT_1rZQYzQVGHqwk6D6V6qhHmwpoxg0gEp-uiIPKfK5AjxDItkn5E7pGlh9oSQD62YslI6fjeyAiypmDRiewTmxg7MxhVBGqcmHKR3BL8VjOqVmiB1cylDngr9vXv_ElIA3_tNbDdssHXDThS0scUFAy9JImmmRForxQW8PTqOBM5KYTEpErIR2rolrWnPIS4FfCqJN2ZDwVP-_hdLJPD1o30V1FZwUfr7tLmXy7MssDjXjEIm_eGCFw5XWhJULDqe_d9TbPokg1LdMs0OlxDys06dD8j7RLOPvVRvX/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-brown-rdap-referrals > > <https://secure-web.cisco.com/1vb_1Kiw_Wv4PBnsJqopt-iGfgyT_1rZQYzQVGHqwk6D6V6qhHmwpoxg0gEp-uiIPKfK5AjxDItkn5E7pGlh9oSQD62YslI6fjeyAiypmDRiewTmxg7MxhVBGqcmHKR3BL8VjOqVmiB1cylDngr9vXv_ElIA3_tNbDdssHXDThS0scUFAy9JImmmRForxQW8PTqOBM5KYTEpErIR2rolrWnPIS4FfCqJN2ZDwVP-_hdLJPD1o30V1FZwUfr7tLmXy7MssDjXjEIm_eGCFw5XWhJULDqe_d9TbPokg1LdMs0OlxDys06dD8j7RLOPvVRvX/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-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://secure-web.cisco.com/1oUfLmJmEWf2qzqo23N4W56CJKmOHoKe7j84n9n9AOOreSr7Gj44GCPGE1zWcM4xakWt35-IijXq530MD-XXt3EgTW8N3JwwU3bcHuIKNIDQqnsAIodX8AO_G4JxkPIInHy4R20dG1ZrnuwpDSBu6QTM97wfRstUsLthASqx5l5zZ8vM-kQNLn76FC3pyuf617Azz7EOyZDeKAIVZdYcBlQ307-IOtOvuGpDK3jS6sm1r9bqMoNDD3J6Zu65xEgrkRi0tx8C9RoQEpU_VeFU9jkHA6fj0KRqJO0-YDzlslSsA3Y1cep6Xgst636Io4P5k/https%3A%2F%2Fwww.icann.org > > <https://secure-web.cisco.com/1oUfLmJmEWf2qzqo23N4W56CJKmOHoKe7j84n9n9AOOreSr7Gj44GCPGE1zWcM4xakWt35-IijXq530MD-XXt3EgTW8N3JwwU3bcHuIKNIDQqnsAIodX8AO_G4JxkPIInHy4R20dG1ZrnuwpDSBu6QTM97wfRstUsLthASqx5l5zZ8vM-kQNLn76FC3pyuf617Azz7EOyZDeKAIVZdYcBlQ307-IOtOvuGpDK3jS6sm1r9bqMoNDD3J6Zu65xEgrkRi0tx8C9RoQEpU_VeFU9jkHA6fj0KRqJO0-YDzlslSsA3Y1cep6Xgst636Io4P5k/https%3A%2F%2Fwww.icann.org> _______________________________________________ regext mailing list -- regext@ietf.org <mailto:regext@ietf.org> To unsubscribe send an email to regext-le...@ietf.org <mailto:regext-le...@ietf.org> _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
