Re: [regext] RDAP-X draft adoption

["Gould, James" <[e-mail]>]

Jasdip,

It doesn’t look like you’re solving the generic “content negotiation using ephemeral query parameters” with RDAP-X, but only looking to address extension signaling that is a new feature and that overlaps with the approach being taken in draft-gould-regext-rdap-versioning.  As posted previously, we’re looking to update draft-gould-regext-rdap-versioning to support extension signaling via a query parameter as well as RDAP-X, where the extension signaling will support an extensible set of extension versioning types starting with opaque and semantic versioning.  I don’t view providing the client preference on what RDAP extensions to include in the response as HTTP “content negotiation”, since it’s at the level of the RDAP application protocol.  If the redirection services have an issue with query parameters, then RDAP-X can be used as an option for the clients of the redirection service if RDAP-X was made to be a more generic query parameter alternative in RDAP.

How about making the RDAP-X hedgehog broader into a super hedgehog by solving the more general query parameter issue with redirection services?

Thanks,

--

JG

[cid87442*image001.png@01D960C5.C631DA40]

James Gould
Fellow Engineer
[e-mail]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: Jasdip Singh <[e-mail]>
Date: Wednesday, November 15, 2023 at 10:27 AM
To: James Gould <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
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.

James,

Please find below my comments.

From: "Gould, James" <[e-mail]>
Date: Wednesday, November 15, 2023 at 8:29 AM
To: Jasdip Singh <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Andy Newton <[e-mail]>
Subject: Re: [regext] RDAP-X draft adoption


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.



[JS] AFAIK, RDAP does not prohibit use of query parameters and offers sane advice on how to deal with unknown query parameters. It is just that when it comes to content negotiation (extensions in the RDAP world), HTTP would recommend using Accept/Content-Type headers, given query parameters for such a purpose could be lost when redirecting and those headers won’t. That’s all we are proposing with RDAP-X. That way, RDAP would be architecturally better aligned with HTTP when it comes to content negotiation, and every new RDAP extension wouldn’t need to re-invent content negotiation using ephemeral query parameters.



Are you willing to look to make RDAP-X more generic to support a general query parameter alternative?



[JS] Nope, just extensions negotiation. That’s RDAP-X’s hedgehog. :)


Jasdip

From: Jasdip Singh <[e-mail]>
Date: Wednesday, November 15, 2023 at 12:47 AM
To: James Gould <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
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" <[e-mail]>
Date: Tuesday, November 14, 2023 at 7:46 PM
To: Jasdip Singh <[e-mail]>, "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Andy Newton <[e-mail]>
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
[e-mail]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

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 <[e-mail]> on behalf of Jasdip Singh <[e-mail]>
Date: Tuesday, November 14, 2023 at 6:27 PM
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, Andy Newton <[e-mail]>
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>