Re: [regext] ACTION REQUESTED: split draft-ietf-regext-rdap-jscontact

[Mario Loffredo <[e-mail]>]

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
> <[e-mail]>  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: [phone]
Web:http://www.iit.cnr.it/mario.loffredo