Hello James, Allow me to walk through the rationale for preferring built-in HTTP headers (Accept and Content-Type) over a query parameter when negotiating extensions (content) between RDAP clients and servers.
Firstly, query parameters are part-n-parcel of RDAP, especially for searches. Lookups generally involve path parameters. Furthermore, redirection is also inherent to RDAP, be it for names or numbers through RDAP Bootstrap, and additionally for inter-RIR transfer scenarios. The heart of this debate is whether it is a good idea to use a query parameter to negotiate extensions. Since query parameters are considered part of the identifier for a resource (say, searching domains by name), when a query parameter connotes an extension value (say, simpleContact versus jsContact versus jCard), that’s more of a different representation of a resource rather than identifying that resource. Further, if there is a non-zero probability that a query parameter unbeknown to a server would be ignored, and in all likelihood not passed on during a redirection, why pick the query parameter approach for promulgating extensions info when there is a sure-shot approach with the Accept/Content-Type headers with zero probability of the extensions info getting lost during redirection. RDAP-X would help leverage the purposed, built-in HTTP approach to negotiate content (extensions). Lastly, to help focus this discussion, it would be helpful if you could please point out what parts of the “Appendix A. Design Considerations” in the RDAP-X draft [1] you might not agree with. Thanks, Jasdip [1] https://www.ietf.org/archive/id/draft-newton-regext-rdap-x-media-type-01.html#name-design-considerations From: "Gould, James" <jgo...@verisign.com> Date: Tuesday, November 14, 2023 at 7:46 PM To: Jasdip Singh <jasd...@arin.net>, "regext-cha...@ietf.org" <regext-cha...@ietf.org> Cc: "regext@ietf.org" <regext@ietf.org>, Andy Newton <a...@hxr.us> Subject: Re: [regext] RDAP-X draft adoption I don’t support adoption at this point until there is consensus around the use of query parameters for all RDAP queries, including RDAP searches and lookups. This is an item that could be added to a section in draft-newton-regext-rdap-extensions, but I certainly don’t agree with the prohibition of the use of query parameters in RDAP. The use of HTTP headers can be an alternative, but not the only option for providing client-side preferences. -- JG [cid87442*image001.png@01D960C5.C631DA40] 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/> From: regext <regext-boun...@ietf.org> on behalf of Jasdip Singh <jasd...@arin.net> Date: Tuesday, November 14, 2023 at 6:27 PM To: "regext-cha...@ietf.org" <regext-cha...@ietf.org> Cc: "regext@ietf.org" <regext@ietf.org>, Andy Newton <a...@hxr.us> Subject: [EXTERNAL] [regext] RDAP-X draft adoption 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. Hello Antoin, Jim, Given the ongoing discussion on how to negotiate extensions between RDAP clients and servers (using HTTP headers versus query parameters), be it for SimpleContact [1], JSContact [2], or versioning in RDAP [3], Andy and I want to request a call for WG adoption of the RDAP-X draft [4]. We believe that the HTTP headers-based approach could help unify extensions negotiation across the RDAP ecosystem. Thanks, Jasdip & Andy [1] https://datatracker.ietf.org/doc/draft-newton-regext-rdap-simple-contact/<https://secure-web.cisco.com/1nidWerWhpGBBUwsxHiQtlXvQAM7L1aAu0q_JW3tdDAm66fg4vS1xYsyXBVv58qpaxNlbAf-bpVfW-uJUZaPRq73cyVfbkKcjF1CJQ8Lp1V2BKQWst7SZhZeEcMiGN6qfZF2y9sn_TNhT_zoXf3poFbjXLh5oh1lknahcNbo3nA7EFKET1QCayveBWuRr5Lb2h6fmu2pY-FfI2il7lwrztrOY7OZOLOLJsIIqwBX6x7hg5tz9eh7QnmLNrUYS9-H9MXW3MDMELCO5rmHQR8aO46zNC1_yqvXrGQlltltumKA/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-newton-regext-rdap-simple-contact%2F> [2] https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-jscontact/<https://secure-web.cisco.com/1NjLx1IYD932sCtvtmvo9QaEJ-Vk5SAceard76o4unDbJx-u41DqXrvYW7kStw1drXp1z-zcguFGnx9esZ6PoXlmb7Go3SPK-ZOhNVB-sp653XbDtZ4RNBR7haZ7V0ja1ASGu28sQzpydz3aC_rfiXKgeYi_pCNRl9qpS4eafODV4ylIWUeZE7O82vW5iEOKIh179HRgjTYd5QsA8xzNIPYYITtK-r65OHedEJK9bofe6fHVGYdAw-9A19XVaLuJDpmblwYJkZwbTCy9BB3HoYHN529c14f8d8WNCxQ8OTGw/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rdap-jscontact%2F> [3] https://datatracker.ietf.org/doc/draft-gould-regext-rdap-versioning/<https://secure-web.cisco.com/1MJfAMLrl4vWqEAt3YAfB4oWtP2-00l4LW5XYysmDZnuktAv60M1NeTjykurNmNpoxTU9peTswBkNb9ry36Js0rI1LDyWjYQnXNQH5a5GFt_QiB9nkjkuUEVmXYRSYWVuOE-k6sLmpKL26oInw8WoZtD2iT1fmsKbvzi68Tsl8YmTPZDKyLaVYKQYI2duUs4qZmW5P7PNuBWzJGUMBMxLPtPda6F_y_kSoxoT5bpikYjzXofdT0CViLFCtW4w5A9pTQfznDF-6EarnIuuB_LJgs7rEDeOFi2M32HF6Y3P0cY/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-gould-regext-rdap-versioning%2F> [4] https://datatracker.ietf.org/doc/draft-newton-regext-rdap-x-media-type/<https://secure-web.cisco.com/1hHjs0yJeMskcqYcuoBtv4b_Lyq1_PGZLpmQS76TuMeSR6BBKFDELxAkJ2SkdUvy3kOK_DNt2VrSdnjHp-EtcL7jkpHvmqT0b_DT-kuS4AUph1DlALdgZqUoagHK4kgEFLASxdR0dAhsiwJLQekwVPGsOYrURpsBo-fe8JahCMn-1k5nBoFxCe38KHUhcrCfcyN2YmcIS6k8rqoXg0pHbQ5ah_7kyP2TtlCpi5OheD11VNdpXJN00pvCp7MwK37Y56VUg5JnGPqFgd7fe19phq28RHMS1TV0AK575vjj6BJ4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-newton-regext-rdap-x-media-type%2F>
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
