Andy,
In reviewing draft-newton-regext-rdap-x-media-type-00 ahead of the REXEXT meeting tomorrow, I have the following feedback: 1. Are you saying that RDAP cannot use query parameters due to the cases that you present in the draft? 2. 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)? 3. 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” 4. 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. Thanks, -- 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/17/23, 2:44 PM, "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: On Mon, Jul 17, 2023 at 11:01 AM kowa...@denic.de <mailto:kowa...@denic.de> <kowa...@denic.de <mailto:kowa...@denic.de>> wrote: > > > [SAH] It's important to support *all* types of clients if possible. > > Anything less can lead to inconsistent user experiences, and that's bad for > > RDAP's long-term viability. I hope this is meant to surround "all types" with asterisks instead of just "all". Or better yet, "all types of RDAP clients". In other words, there are general purpose, user-focused clients that run in terminal emulators and browsers. There are also task-purpose clients that run in automation such as intrusion detection systems, etc...(almost certainly the bulk of queries). But they are all RDAP clients in that they were implemented for the purpose of communicating with an RDAP server. A stock web browser is no more an RDAP client than an Internet-connected refrigerator. Just because both can send bits down the wire using HTTP doesn't mean they were purpose built for RDAP nor do either hold themselves out to be RDAP clients. If we were to consider otherwise, then it could be said that telnet is an RDAP client; you could do it but the app store reviews would be vicious. > > [PK] if usage of only web browser is concerned, it would likely never > support application/rdap-x+json out of the box and send appropriate > headers with the request. Maybe with an extension, then not being a pure > browser anymore, but more a dedicated RDAP client. With an off-the-shelf web browser such as Firefox or Chrome, a user can alter the accept header by typing in a quick fetch statement in the Javascript console. Is that an absurd thing to do? Yes. But it is also equally absurd to expect JSON to be a usable interface for humans. BTW, there is a plugin for Chrome that allows altering request headers. > > An end user just operating the web browser won't be able to set > arbitrary http headers. Query parameters would be possible, but are not > considered by the authors (Appendix A.2). Not exactly. We did consider them and found them to have usability and compatibility issues. To support query parameters would mean undoing guidance in RFC 7480 and changing currently implemented and deployed software. > > So the choice is between not supporting pure web browser as a client > with this method, or allow for alternative with query parameters on top > of http headers (a bit like http-equiv but for request rather than for > response). That's a choice for many of the RDAP extensions as well. A pure web browser cannot interpret the redacted extension policies and apply them, and a pure web browser would be incapable of interpreting client discovery using /help. And a pure web browser would be incapable of supporting JSContact as it could not apply patch objects. -andy _______________________________________________ regext mailing list regext@ietf.org <mailto:regext@ietf.org> https://secure-web.cisco.com/1icxyIfSNGk7IqAlOaYAOSdnAgE-wxoyYIgLnxkW2m17A0ejMMXyGHZh_c8_KqdTCD5uSFpvTiBLCFUp0cU0gT-aLLmYYQqnpi937xE0vQ2fNxZAimh7oYK_B0vxAekIowQ-oFxAesAEy4s4yS8rZiA-b6Z_hFQWsEnyLvvka_eBtYcxp4JGx5NeIFLts5grGAfqaG-Pt-EuRCJYQYXkrKGO_r6QcDqGWlYijLlk_4naqMjMVTQEJgIwzsnXscJHxkyp-TV-9Q_9NjLIWWsrJS5a9Jfiuk3P7ge0F1GZHy5U/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext <https://secure-web.cisco.com/1icxyIfSNGk7IqAlOaYAOSdnAgE-wxoyYIgLnxkW2m17A0ejMMXyGHZh_c8_KqdTCD5uSFpvTiBLCFUp0cU0gT-aLLmYYQqnpi937xE0vQ2fNxZAimh7oYK_B0vxAekIowQ-oFxAesAEy4s4yS8rZiA-b6Z_hFQWsEnyLvvka_eBtYcxp4JGx5NeIFLts5grGAfqaG-Pt-EuRCJYQYXkrKGO_r6QcDqGWlYijLlk_4naqMjMVTQEJgIwzsnXscJHxkyp-TV-9Q_9NjLIWWsrJS5a9Jfiuk3P7ge0F1GZHy5U/https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fregext>
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
