On Mon, Jul 17, 2023 at 11:01 AM kowa...@denic.de <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 https://www.ietf.org/mailman/listinfo/regext
