Jasdip,
You state, “Since query parameters are considered part of the identifier for a resource”, which seems to discount the use of the query parameter as a client option or a preference. In RDAP, the query parameter is used as an option or preference. A statement was made that RFC 3986 supports your query parameter is a resource statement, but what is missed is the definition of a resource in RFC 3986 “This specification does not limit the scope of what might be a resource; rather, the term "resource" is used in a general sense for whatever might be identified by a URI.”, which pretty much means that it’s part of the URI. In REST the query parameters are commonly used to provide client-side options and preferences, so with RDAP being a REST protocol we should follow the common practice for REST. A client is not required to use a redirection service and the redirection service should not filter the query parameters, since it’s not the target of the query. If there is an inherent issue with your implementation of an RDAP redirection service that cannot retain the query parameters, then my recommendation is to make RDAP-X (renamed to RDAP-P for RDAP parameter) support all query parameters instead of scoping it to just signaling extension identifiers. I won’t distract the thread with my detailed feedback on Appendix A of the RDAP-X draft, since much of this thread is covering questionable statements made there about “architectural violations” by referencing RFC 3986 as well as morphing the ignore unknown query parameters language in RFC 7480 to justify the aggregators filtering query parameters. I believe the best approach is for RDAP to fully support query parameters and add support or providing the client parameters via something like RDAP-X to address the corner case of RDAP aggregation services that cannot preserve the query parameters. I don’t support the proposal of prohibiting the use of query parameters for a subset of RDAP queries (lookups), while pushing an RDAP-custom method for providing client-side preferences with HTTP headers. This will enable the creation of RDAP extensions that fully support the REST mechanics while providing the option for clients to choose the use of aggregation services not supporting query parameters. Are you willing to look to make RDAP-X more generic to support a general query parameter alternative? Thanks, -- 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: Jasdip Singh <jasd...@arin.net> Date: Wednesday, November 15, 2023 at 12:47 AM To: James Gould <jgo...@verisign.com>, "regext-cha...@ietf.org" <regext-cha...@ietf.org> Cc: "regext@ietf.org" <regext@ietf.org>, "a...@hxr.us" <a...@hxr.us> Subject: [EXTERNAL] Re: [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 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<https://secure-web.cisco.com/13hM_F3A06ogJlYq0UdRsRa7RsEWPpd-wzJJmpR5hpjop6Ph0rAYEK4z4vDtgNA65PUEOKWjpVU1JdS0T4DAEcgnRlC8aYdK5NxOnFkqelwi5ghvG2vwZE3t3kEW8nn_heqdpu9FE3RYKMKcx8riM8vPB-bsflIhLF2cVTz1SKKzf3pTkxmqzJlnznSOSRHZcbGGI53kRpXSLWLZrh992maqSp9C8NeipuJDkGglcYtqeXd_2YvdrbqhHV_t0_kX-RF3QJQCpeCaKckJVoY3luQnBGQAOR6e1SKKTK7dX0xI/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-newton-regext-rdap-x-media-type-01.html%23name-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://secure-web.cisco.com/1qdTizD9kPlky0fnS9J3WUX_nOV_SwqGWB3vEaUzpMA2l5d5FdOLpuXaUJk9PKYXaCVCuSSAHeCOBsnZ6tWfz_STUePrikiJcUZ_cjuqnu7wexBeiSluqt4pSs2l2vqCm6yxyk6k_Mq_X_xpKXXwiNaNx17ifhBjAraGHGtoHMpBzAonjhq92fUYcCVOQ6XfACndeFnSZQfupoIBq6tRncsEWwKHgOTNWmja1TO_CgvdNNQRKc6vO_T9oZYSRD27M3n0hl4gWjoxLjR1tnm1fZDKa7TRbFU1MWNXT283wMbs/http%3A%2F%2Fverisigninc.com%2F> 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
