Andy, I provide feedback embedded below.
-- 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 7/24/23, 5:17 PM, "Andrew Newton" <a...@hxr.us <mailto:a...@hxr.us>> 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 James, Thanks for the review. My response is in-line. On Mon, Jul 24, 2023 at 11:10 AM Gould, James <jgo...@verisign.com <mailto:jgo...@verisign.com>> wrote: > > Are you saying that RDAP cannot use query parameters due to the cases that > you present in the draft? Not at all. The appendix in the draft points out why client capabilities cannot be done with query parameters. But, as you point out below, there are places where they are specified for use. JG - The use of query parameters is a standard REST feature, is a core feature of RDAP in RFC 9082, and has been used in many RDAP extensions (RFC 8982, RFC 8977, draft-ietf-regext-rdap-reverse-search, draft-ietf-regext-rdap-openid, draft-ietf-regext-rdap-jscontact). You are defining a new media type with the Accept header as an alternative method that includes arguments against the use of query parameters in the Appendix. Much of the meat of the draft is associated with describing how a standard feature of RDAP with query parameters is considered harmful, which directly conflicts with the approach that is currently being used by RDAP extensions to pass client-side input. If the use of query parameters is truly harmful and should not be used and you have an alternative method to use, then I would prefer focusing on that in the body of the draft. I'm not convinced that the cases you represent in the draft make the use of RDAP query parameters a bad or harmful practice. > What should be done with the use of query parameters in RFC 9082 for search > (Domain Search, Nameserver Search, Entity Search) and other RDAP extensions > (RFC 8982, RFC 8977, draft-ietf-regext-rdap-reverse-search, > draft-ietf-regext-rdap-openid, draft-ietf-regext-rdap-jscontact)? This is an excellent question. In all the search cases above there is no expectation to be able to search all RDAP servers. How would that work? How could an RDAP client search for all entities with a fullname that starts with "Bob" across all RDAP servers? While there are data miners, that's not really an RDAP use case. Searches, sorting and paging, and authnz will always need to target a specific RDAP service. Trying to do any of that is difficult to reason about. In other words, there is no expectation of cooperation across all RDAP services to coordinate searches, sorting and paging, and authnz, and there is no expectation that it would work. "Lookups" on the other hand are an RDAP use case. That is, a query for a specific domain or IP address, not a search. That's why there are RDAP bootstrap files, and dealing with redirects is part of that solution. And that is why the usage of query parameters in JSContact is unworkable as contact data is part of an answer to a lookup. JG - I'm not sure where the "search all RDAP servers" use case is coming from. The RDAP RFCs and extensions provide bootstrapping and query features (lookup and search) that clients can use to query individual RDAP servers. The query parameters of an RDAP extension are additive to the queries and don't change the bootstrapping, query, and response model. Maybe you should define a draft associated with RDAP redirection and aggregation services that leverages the REST interface defined by RDAP and the RDAP extensions. > You make mention of extension versioning with “there is design intent to > allow the use of explicitly versioned RDAP extension identifiers where they > are also compatible with the identifiers used in the rdapConformance array of > RDAP”, that conflicts with what was agreed upon at IETF-114. The chairs > presented > https://secure-web.cisco.com/1MZz61KucqbjxOYF9sC8DpzI_abBGw5P33hoIJ25kiX1awuY79UOSX7MhuIJivpLGgysKmgtoT3Wr4FDvWgiA8Vg0vz15YYBzimEXNiuKXPEobgaQm5voI08HEKQt_-LwPuxvCnUt2g4KdFUvmMStM5t3ijpeNt9vgeMskcn-MfTjP5u9BVuDodErAAxJqPvDKWnFFZVxs08SWTGANTUM5oNOHY7rlQAo9ET4fGJIAtpPyIJ4n2f_TgJXv_8SoXE81eIqT6Sel4LPfbMqSKQ3VdSlEz3-cDGy8u4cBHu68e4D73YFrl8J-30U47NEEr1Q/https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F114%2Fmaterials%2Fslides-114-regext-rdap-extension-identifier-and-rdapconformance > > <https://secure-web.cisco.com/1MZz61KucqbjxOYF9sC8DpzI_abBGw5P33hoIJ25kiX1awuY79UOSX7MhuIJivpLGgysKmgtoT3Wr4FDvWgiA8Vg0vz15YYBzimEXNiuKXPEobgaQm5voI08HEKQt_-LwPuxvCnUt2g4KdFUvmMStM5t3ijpeNt9vgeMskcn-MfTjP5u9BVuDodErAAxJqPvDKWnFFZVxs08SWTGANTUM5oNOHY7rlQAo9ET4fGJIAtpPyIJ4n2f_TgJXv_8SoXE81eIqT6Sel4LPfbMqSKQ3VdSlEz3-cDGy8u4cBHu68e4D73YFrl8J-30U47NEEr1Q/https%3A%2F%2Fdatatracker.ietf.org%2Fmeeting%2F114%2Fmaterials%2Fslides-114-regext-rdap-extension-identifier-and-rdapconformance> > that included the below statements. The versioning extension > (draft-gould-regext-rdap-versioning) was created to address the versioning > issue. We have met privately on your feedback to > draft-gould-regext-rdap-versioning and we’re in the process of revising it > based on your feedback with the support for both opaque and semantic > versioning. > > “Explicit support for version is not an integral part of the extension > mechanism” > “Certainly, you can choose to include version inside the specification for > your extensions, but in the context of the base protocol an extension is > either supported or its not, and when supported it simply means there is a > shared understanding of what is to be done between the client and server” I don't understand the conflict you mention. Can you elaborate? That said, the intent in the draft is not to specify extension versioning but to allow it once specified. In other words, the intent is to be compatible with the work you are doing. If you believe it is incompatible, can you elaborate? JG - The draft defines an alternative mechanism for a client to specify the extensions that are desired in the RDAP response, which is in direct conflict with the use of the "versioning" query parameter in draft-gould-regext-rdap-versioning. The use of a media type could be leveraged in place of the query parameter or in addition to the query parameter in draft-gould-regext-rdap-versioning, but as defined draft-newton-regext-rdap-x-media-type does not define a generic feature that can be used by draft-gould-regext-rdap-versioning but instead defines a conflicting approach for signaling desired extensions by the client. > > I don’t believe that the RDAP application protocol concerns should move into > the transport layer with the use of a new HTTP header. The use of query > parameters is appropriate and as shown in #2 above is being used in many > places. This draft does not create a new HTTP header. And query parameters are part of the identifier system (URIs) which are intrinsic to HTTP, so both are aspects of HTTP as an application transport. JG - Correct, you are defining a new media type to use with the Accept header, which I believe moves the application signaling down to the transport layer. I prefer keeping the query information in the URI with the use of query parameters. -andy _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
