Hi Andy,
please find my comments below.
Il 02/10/2024 16:24, Andrew Newton (andy) ha scritto:
On Tue, Oct 1, 2024 at 3:53 AM Mario Loffredo<mario.loffr...@iit.cnr.it> wrote:
Hi Andy and Jasdip,
have some questions about draft-ietf-regext-rdap-x-media-type:
1) rdap_level_0 is included in "extensions" parameter, but it's not an
extension, i.e. it's not included in the RDAP Extensions registry. Should it be removed?
2) If rdap_level_0 is an extension, is it required to be provided?
It's not an extension but is RDAP's own versioning mechanism. It's
included for symmetry with the rdapConformance array and can be used
for the same purpose.
[ML] In that case I recommend to change the following sentence to
consider rdap_level_0 as a "special" extension as it's not included in
the RDAP Extensions registry:
The media type defined by this document is 'application/rdap-x+json'.
This media type has a parameter of "extensions" which is a
whitespace-separated list of RDAP extensions as defined in the IANA
RDAP Extensions registry.
The alternative is to add rdap_level_0 to the registry.
3) If rdap_level_0 is required, what should be the server response when the
client doesn't include it or any required extension in the extension parameter?
A very good question. It should be required and a server should
continue to serve information in conformance to rdap_level_0 (or
return a 415 if it cannot conform to rdap_level_0 in a futuristic
scenario where ther is an rdap_level_1 or whatever).
[ML] See my responses below.
4) Should the server distinguish the optional and required extensions supported?
What are the definitions of an optional and required extension?
[ML] Based on your response to the previous question:
- required extensions are those returned by default, i.e. regardless
they are included in the extensions parameter. rdap_level_0 is an
example but an RDAP server might always include a custom extension in
its responses;
- optional extensions are those returned only upon request.
If there will ever be rdap_level_1, only one between rdap_level_0 and
rdap_level_1 will be returned by default.
How is
that meaningful to a client?
[ML] It's not meaningful to a client as it can't influence the server
about returning the required extensions because they are returned
anyway, but I think it would be good to address the difference between
the two kind of extensions to make the server response consistent with
the client request. A client would interpret the return of an
unrequested extension as a server bug.
5) With regard to your concern about the usage of query parameters, what should
be used instead in order to specify values in RDAP queries?
I mean, I could be good with using content negotiation to request for response
extensions but it looks to me unfit to convey values in a query and we have
already used that kind of query parameters in some RFCs.
Indeed, apart from the query parameters used in search queries (e.g. those
defined by RFC8977 and RFC8982) which can hardly be redirected, section 4.2 of
RFC9560 includes query parameters that don't aim to request for a response
extension and can be used in lookup queries.
James Gould has already noted the hyperbolic heading in the rdap-x
document, and we plan to change it.
However, what you are looking for is in the rdap-extensions draft:
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-extensions-04#name-usage-in-query-parameters
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-extensions-04#redirects_author
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-extensions-04#referrals
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-extensions-04#security_considerations
https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-extensions-04#privacy_considerations
[ML] If we agree that query parameters are useful in some cases as the
rdap-extensions draft itself seems to admit, I would suggest to remove
or rearrange section B.2 of rdap-x draft.
Best,
Mario
-andy
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: 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
To unsubscribe send an email to regext-le...@ietf.org
