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> 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. > 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. > 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://datatracker.ietf.org/meeting/114/materials/slides-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? > > 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. -andy _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
