> Le 24 mai 2024 à 12:04, Gould, James <jgould=40verisign....@dmarc.ietf.org> a > écrit : > > 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,
Right, but while « just supporting HEAD » is theoretically possible, it is just complicated for a high performance server, as it requires a special config and behaviour. I think the balance of advantages and inconvenience is just not there. Regards, Marc. > 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 _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
