Hi Andy,
again my comments below.
Il 03/10/2024 12:49, Andrew Newton (andy) ha scritto:
On 10/2/24 12:33, Mario Loffredo wrote:
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).
Well, its not an extension so it shouldn't go in the extensions
registry. I have added an issue in the tracker to add text noting that
rdap_level_0 is not an extension and is "special" in this scenario:
https://github.com/anewton1998/draft-regext-ext-json-media-type/issues/34
[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.
That is not how RDAP works. Clients are suppose to ignore unknown
extensions.
[ML] I was talking about "unrequested extensions" which can be different
from "unknown extensions". I remind you that:
1) some custom extensions reported in the RDAP Extensions registry are
returned by default, most likely to make the RDAP response consistent
with the WHOIS response. After all, up to now, clients haven't been
allowed to specify their preferences about response extensions hence
servers have been free to extend their responses as needed;
2) based on what is stated by some RFCs, the server may autonomously
return response extensions when certain conditions occurred (see the
redacted property in RFC9537 and the paging_metadata property in
RFC8977) or to provide clients with additional information about its
capabilities (see the properties added to the "/help"response in RFC9536
and RFC9560).
All of the response extensions above may be returned by servers without
being requested by clients.
What do you propose to address this topic ?
In addition to it, I see a potential issue with a "/help" request
including the extensions parameter and the related response.
Quoting Section 4.1 of RFC9083, Section 2.1 of
draft-ietf-regext-rdap-extensions states that:
The "/help" response returns an
"rdapConformance" member containing the identifiers for all
extensions used by the server.
Section 3 of draft-ietf-regext-rdap-x-media-type states that:
When there is a mismatch between extension parameters and the rdapConformance
array, clients SHOULD give preference to the rdapConformance array
So, in general, whatever could be the extensions parameter of a "/help"
request (most likely only "rdap_level_0"), the server would ignore it
to build the response.
Don't you think the client could response could misunderstand that
response ?
Best,
Mario
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.
We already have this issue noted:
https://github.com/anewton1998/draft-regext-ext-json-media-type/issues/30
However, the text should stand as it notes the issues of using query
parameters in some situations.
-andy
_______________________________________________
regext mailing list --regext@ietf.org
To unsubscribe send an email toregext-le...@ietf.org
--
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
