On Tue, Jul 25, 2023 at 9:01 AM Gould, James <jgo...@verisign.com> wrote: > > 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.
Let me try to restate this. The use case of search and authnz do not lend themselves to either bootstrapping or redirection to authoritative servers by their very nature. But finding authoritative servers via bootstrapping and redirects is integral to the operations of RDAP lookups which makeup the vast majority of RDAP queries. Any feature that intends to be used in lookups needs to be compatible with finding authoritative servers in RDAP. Tom Harrison gives an excellent example of this in his recent talk at ROW 12: https://regiops.net/sites/default/files/documents/2-ROW12-Tom%20Harrison-RIR%20RDAP%20profile%20and%20related%20standardisation%20work_0.pdf > The query parameters of an RDAP extension are additive to the queries and > don't change the bootstrapping, query, and response model. No they are not. See Section 4.3 of RFC 7480. Additionally, see Appendix A.2.2 of the RDAP-X draft which demonstrates how this is not true with currently deployed RDAP servers. > 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. No need. Please see Section 5.2 and Appendix C of RFC 7480. > 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. Correct. The intent is to define a generic mechanism that can be used by both your semantic versioning scheme and other versioning schemes including the current opaque versioning in RDAP. I'd be happy to work with you on incorporating the use of RDAP-X with your semantic versioning idea. > > 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. The only problem is that RDAP is specifically intended to use the features of HTTP. See Section 3 of RFC 7480. RDAP also currently defines the use of HTTP headers, as do many REST protocols. In fact, the idea behind RDAP-X is not novel as it was inspired by the W3C's ActivityPub protocol which uses multiple media types, one of which can have parameters. RDAP does not have the mental model of EPP when it comes to application vs transport. -andy _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
