Hi Andy,
again my comments inline.
Il 27/11/2023 22:58, Andrew Newton ha scritto:
My comments are inline:
On Fri, Nov 17, 2023 at 7:18 AM Mario Loffredo
<mario.loffr...@iit.cnr.it> wrote:
[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 ?
Good question. My inclination is to say that farv1 is about
authentication and not content negotiation and therefore does not need
to be in the extensions parameter.
[ML] Since it talks about "content negotiation", rdap-x regards clients
signaling their preferences about response extensions or, at most,
extensions involving both the response and the request.
With regard to pure request extensions, clients should signal
preferences by using query parameters prefixed by opaque extension
identifiers as defined in rdap-extensions.
This in turn implies that, on one hand, rdap-x is strictly bound to
rdap-extensions and, on the other hand, instead of what is stated in
Section 6 of rdap-extensions, even the extensions created by IETF MUST
use the extension identifier as a prefix.
Do you agree ?
What should be the server response when it's not included in the extensions
parameter but is used in the query string ?
It should continue processing the query parameters.
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 ?
I'm confused. Isn't this what the SHOULD above is about. Or are you
suggesting that SHOULD is to be a MUST?
[ML] No. Was simply trying to understand if the purpose of rdap-x was
to signal client preferences about which extensions, regardless of their
type, should be used by the server for processing the request.
In the case of pure request extensions, the use of rdapConformance value
looked a bit misleading to me.
But you just clarified that the purpose of rdap-x is limited to signal
only the response extensions.
- 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 ?
If that is what they need to do. I don't think this changes any
current caching strategies and deference to RFC 9110 is the proper
guidance. My understanding of the current state of the Vary header is
that it is mostly used by servers. That said, I have yet to see this
as a real-world issue in the RDAP space.
[ML] It could be an issue if we decide to start using content
negotiation. The media type has not influenced the RDAP response so far.
AFAIU, since the same URL may produce different responses based on the
value of the Accept header, any cache that store responses needs to know
that the header is important to determine if the cached response is
valid or not and save clients from receiving
a wrong response.
Think it should be further investigated.
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
