Mario, On Thu, Nov 16, 2023 at 9:28 AM Mario Loffredo <mario.loffr...@iit.cnr.it> wrote: > > > Also, since you (and JG) have been arguing vehemently on your > position, did you find a technical flaw in the rdap-x draft? Have you > found a scenario where it does not work? > > [ML] Am not "arguing vehemently", I'm quietly explaining what does not > completely convince me. Your proposal would have many implications on > existing implementations and as many of them in the future, hence, it should > be carefully evaluated. >
My apologies. I did not mean to offend. > Here in the following some remarks/objections from my side sorted by > relevance: > > - RDAP extensions are not only response extensions. So, even assuming that > signaling preferences about response extensions is a matter of content > negotiation, pure request extensions wouldn't theoretically be covered. How > would they be manged ? Given that today there is no standardized means for a client to signal what extensions it prefers, I don't foresee a problem. They should probably be managed the same way as the others. Can you provide an example? > > - AFAIK caches generally ignore Accept by default, so when content > negotiation is first introduced, clients often get the wrong response type. > In this case, it would result in getting the default response by the RDAP > server. Implementers should add Accept to Vary. Should it be addressed by > rdap-x draft ? We can add language deferring to RFC 9110 guidance on this. > > - Requiring HTTP headers with media types makes it more difficult to test and > explore the API using a browser. During development, you can launch the > browser and easily see what the server is responding by simply using the > address bar. When relying on content negotiation it's a bit more tricky, and > you have to leverage plugins or cURL or anything else that can manipulate the > headers. There are other very good development tools as well. I see people use Postman a lot, and httpie looks good as well. > > - (Minor) I wonder how much tricky it could be to get the value of the > extensions parameter. At a quick glance, it doesn't look to me as > straightforward as getting the value of a query parameter. I'd be curious to > know if someone in the WG has already implemented it. This would depend on the server framework. But I can see about putting some code in the test server referenced in the draft. > > If not, then why do you insist on a path with known interoperability > issues over a path without them? > > [ML] Because I personally see drawbacks in such an approach as well as > possible inconsistencies in implying that lookup queries should not include > query parameters. > > Anyway, if the WG agreed on this way to go, some normative language should > be added somewhere to make it clear when query parameters are forbidden or > unrecommended. I'm fine with that. I don't think the rdap-x draft is the right place. Perhaps the rdap-extensions draft. -andy _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
