Hi Andy,
please find my comments inline.
Il 15/11/2023 14:41, Andrew Newton ha scritto:
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.
[ML] I agree with you on "unknown parameters" but RDAP has already
defined many well known parameters for searches as well as lookups (i.e.
dnt and qp in rdap-openid).
Besides, there exist also current deployments that preserve them in
redirection.
For example, my RDAP server preserve the jscard parameter of
rdap-jscontact in redirection.
Since a normative language is missing, everyone is allowed to interpret
RFC7480 and implement their own redirection strategy.
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.
[ML] As I wrote, the applicable query parameters are defined and well
known by each HTTP-based application protocol. In RDAP, they have
already been defined for both kinds of query and can be either ignored
or implemented. As a consequence, I think it would be more consistent to
allow for them in general, to preserve them in redirection and let the
target servers to implement them rather than to try to delimit the cases
where they are allowed and those where they aren't.
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.
[ML] Nothing special. It was just for my better understanding of RFC6838.
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.
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 ?
- 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 ?
- 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.
- (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.
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.
Best,
Mario
-andy
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
