Sorry. Forgot to reply to the mailing list.
Thanks Andy for the heads up.
Best,
Mario
-------- Messaggio Inoltrato --------
Oggetto: Re: [regext] ACTION REQUESTED: split
draft-ietf-regext-rdap-jscontact
Data: Fri, 17 Nov 2023 10:25:37 +0100
Mittente: Mario Loffredo <mario.loffr...@iit.cnr.it>
A: Andrew Newton <a...@hxr.us>
Hi Andy,
please find my comments inline.
Il 16/11/2023 19:58, Andrew Newton ha scritto:
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.
[ML] No worries. You didn't offend me.
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?
[ML] Per what is stated in RFC 9083 Section 4.1, a pure request
extension doesn't have to be included in the rdapConformance array of
the related response when it is used in a query because the
rdapConformance array is used to signal to the client only the
extensions used in building the response.
Per what is stated in Section3 of rdap-x draft, clients SHOULD give
preference to the rdapConformance array in order to determine which
extensions (including those requested ) were used to build the response.
Let's suppose to use farv1_dnt in a query within an authenticated
session. Have some questions:
Should farv1 be included in the extensions parameter ?
What should be the server response when it's not included in the
extensions parameter but is used in the query string ?
Supposing that farv1 has to be included in the extensions parameter when
farv1_dnt is used, how should a client interpret that farv1 is missing
in rdapConformance ?
- 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.
[ML] Do you mean that servers should implement Vary too ?
- 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.
[ML] Yes. I have used Postman and Rester to test the implementation of
token-oriented approach of rdap-open. A bit trickier than using the
address bar.
- (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
--
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
