Hi Andy,
again my comments below.
Il 07/10/2024 13:44, Andrew Newton (andy) ha scritto:
On 10/4/24 04:44, Mario Loffredo wrote:
[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 ?
Either a client has code to handle an extension or it doesn't, so I
don't know how that is helpful to a piece of software. However, for
troubleshooting it might be worth putting it in the "version"
information in the versioning extension.
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 ?
That statement in Section 3 is only provided for guidance to clients
when there is a mismatch in a server response between the extensions
parameter and the rdapConformance array. In other words, the server
gave conflicting information therefore follow the "rdapConformance"
array. Why? Because we had to pick one.
I agree with you that the statement is needed to disambiguate the case
where the extensions parameter and the rdapConformance in the server
response are different.
But, provided that some custom and standard specifications allow a
server to return response extensions by itself, I do believe that the
document should clarify what the server is expected to do when the
client doesn't specify them in the extensions parameter.
Should the server return a response or should it return an error?
Per your answer to my prior question about the server handling the case
where the client omits rdap_level_0, I guess the first option because
otherwise this draft should also update some existing specifications.
But this means that the client could mention only the extensions which
are considered optional by the server and omit the other ones.
If we will ever deprecate rdap_level_0 to move to rdap_level_1, at any
time of the transition process, only one of them will be optional and
the other one will be returned by default.
Best,
Mario
-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
