Mario (and JG), On Wed, Nov 15, 2023 at 5:17 AM Mario Loffredo <mario.loffr...@iit.cnr.it> wrote: > > [ML] About preserving query parameters in HTTP redirection, my opinion > is that it depends on each application protocol built over HTTP. > > There are a ton of protocols on the web preserving query parameters in > redirection and AFAIU there is nothing in RFC9110 stating that query > parameters must be purged. > > On the contrary, RFC 9110 itself admits that a POST could be redirected > and changed into a GET and I cannot imagine how it could be done without > using query parameters.
There is no disagreement on that. However, RFC 9110 does state that content negotiation is done with accept and content-type headers. > > If RDAP rules out preserving query parameters in redirection, this ought > to be explicitly stated in section 5.2 of RFC 7480. The counter to that is that nowhere is it specified that they do generally survive redirects, there exists RFC language to instruct servers to ignore unknown query parameters, and there exist current deployments that do not preserve them. > > Anyway, I wouldn't welcome such a policy for the following reasons: > > - RDAP is a relatively young protocol not yet largely used. At present, > I couldn't exclude such a feature from being useful in future developments. > > - It would result in a sort of confusion between using query parameters > in lookups and searches and also between different lookups. To be noted > that rdap-openid, just gone through the WGLC, allows to specify two > parameters which can be used in RDAP queries. > > - Bootstrapping is an optional feature. Would an RDAP provider be > allowed to define a request custom lookup extension incuding query > parameters if that kind of query will never be redirected ? The issue isn't that they are forbidden, the issue is that to use them in any scenario involving redirection, all servers participating in that redirection must behave in the same manner. At present, that is demonstrably untrue. > > > With regard to the content negotiation, I personally interpreted that > Accept header is used to negotiate a format involving the overall > response rather than a portion, i.e. the contact information. > > Just to give an example: at last meeting, you mentioned CBOR. The use of > CBOR would not be restricted to only the contact information. > > Anyway, I admit that this depends on different point of views. > > Instead, I am a bit doubtful about how the "extension" parameter is > defined in the rdap-x draft but I confess that I'm not knowledgeable > about media types so I asked an expert for a clarification. I'd be curious who he is and what he has to say. 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? If not, then why do you insist on a path with known interoperability issues over a path without them? -andy _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
