> 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.
My personal struggle with this is that it's hard to intuit from reading the RDAP RFCs. 9082 and 9083 discuss RDAP queries and responses, respectively; their titles are quite clear. Then consider 7480, with a title of "HTTP Usage in RDAP." Taken as a set, the three titles convey a mental model of application requirements separate from transport implementation details. Juxtaposed with the EPP specs (5730-5733, "EPP/Domains/Hosts/Contacts"; and 5734 "EPP over TCP") you can hopefully see how natural it is to align the mental models of both services. If reality is different, and RDAP has its own model different from EPP, fine. But there must be something we can do with the specs to make that clearer. One thought: if HTTP is truly baked into RDAP, then the HTTP spec (7480) should be baked into 9082 and 9083 and should not stand alone. --Dan On 8/1/23, 9:56 AM, "regext on behalf of Andrew Newton" <regext-boun...@ietf.org <mailto:regext-boun...@ietf.org> on behalf of 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. On Tue, Jul 25, 2023 at 9:01 AM Gould, James <jgo...@verisign.com <mailto: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://secure-web.cisco.com/13Mu9HYhdd0v27cmVedAQr2YmHhTyZyZxHkX6JhTe_P9skGRk20GtWg4_H3WPf1hnqzWnTN3LgO_NkpbEEkRt8jUmQont-zz9s3jGqS6Yd7Ih2lsvHuIELR9BE3BzatiEmvvaKy5UUvyW-H-lgUuIro5p5eT-Yu0ftrU4iNZlHwcQdDOH7MshAXh5p9FZrCJTFBp9GKj1yejEvi7gINiGdsiJPGjpxTh76oeu98NnALrgBwSlmL9EOs7m-w23Qu5_H32N3vd5D8ETnzvCOf6PnCxe-wV_-K0E6r5yIoNBqcE/https%3A%2F%2Fregiops.net%2Fsites%2Fdefault%2Ffiles%2Fdocuments%2F2-ROW12-Tom%2520Harrison-RIR%2520RDAP%2520profile%2520and%2520related%2520standardisation%2520work_0.pdf <https://secure-web.cisco.com/13Mu9HYhdd0v27cmVedAQr2YmHhTyZyZxHkX6JhTe_P9skGRk20GtWg4_H3WPf1hnqzWnTN3LgO_NkpbEEkRt8jUmQont-zz9s3jGqS6Yd7Ih2lsvHuIELR9BE3BzatiEmvvaKy5UUvyW-H-lgUuIro5p5eT-Yu0ftrU4iNZlHwcQdDOH7MshAXh5p9FZrCJTFBp9GKj1yejEvi7gINiGdsiJPGjpxTh76oeu98NnALrgBwSlmL9EOs7m-w23Qu5_H32N3vd5D8ETnzvCOf6PnCxe-wV_-K0E6r5yIoNBqcE/https%3A%2F%2Fregiops.net%2Fsites%2Fdefault%2Ffiles%2Fdocuments%2F2-ROW12-Tom%2520Harrison-RIR%2520RDAP%2520profile%2520and%2520related%2520standardisation%2520work_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 <mailto:regext@ietf.org> https://secure-web.cisco.com/1rxv_5X_30iCvjqzM9iW8loI42V3clo_7OmiQXBhhO9-1E66ktbSmrbyAuqH5t7JbOTgoL73O3ZovFDyOXoH3hQCqBCyDPE78Tt7qK5wPe3oDU2lEBkqCPHYUjT0Yc-a-k5p8OqryCgkjr8HvQHGlyYLF1HoCiDd6sLARvHnxYMY_hr3BsB9RvFPLfQdfS9lYDCD_N9vPNb10w4ke-SvicwOrGSo8vG5OFCBxR4g9oGwr-FcGDb9dj7JqGzMcvI9Qrk57uDGlnZ_cFljJXqb4AaQ9x1ybm0g5FPz9phfjOHztfVw1SGNQTzn4Cbp78T4o/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext <https://secure-web.cisco.com/1rxv_5X_30iCvjqzM9iW8loI42V3clo_7OmiQXBhhO9-1E66ktbSmrbyAuqH5t7JbOTgoL73O3ZovFDyOXoH3hQCqBCyDPE78Tt7qK5wPe3oDU2lEBkqCPHYUjT0Yc-a-k5p8OqryCgkjr8HvQHGlyYLF1HoCiDd6sLARvHnxYMY_hr3BsB9RvFPLfQdfS9lYDCD_N9vPNb10w4ke-SvicwOrGSo8vG5OFCBxR4g9oGwr-FcGDb9dj7JqGzMcvI9Qrk57uDGlnZ_cFljJXqb4AaQ9x1ybm0g5FPz9phfjOHztfVw1SGNQTzn4Cbp78T4o/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext> _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
