Hi Gavin,
please find my comments inline prefixed with [ML]
Il 21/08/2025 11:46, Gavin Brown ha scritto:
Hi Mario,
On 19 Aug 2025, at 18:12, Mario
Loffredo<[email protected]> wrote:
RFC 8982 only applies to search queries. That's clunky but presumably we don't
care too much about that.
[ML] Its logical field of application is the RDAP search because it aims to
limit the amount of information returned, which in a search response could be
remarkable. But it can also be applied to RDAP lookups.
The RFC as written applies only to search queries. Another document would be
needed to expand its use to lookups.
[ML] Updating RFC8982 to also address lookups and add field set
registration would not be that complicated.
Honestly, it seems to me that parsing the content of a link header is more
complex than getting the same information from a JSON structure, and since the
payload of a search response is manageable, I wonder what the real benefit is.
1. reduced response payload size. For HTTP/2 (and presumably H3 also), HPACK
can additionally be used to compress the header.
2. to allow the use of the HEAD method, since responses cannot have a body.
[ML] The response payload would not be reduced compared to current
queries. In fact, responses to HEAD and GET requests would also include
Link headers.
The payload would only be reduced when the client sends the HEAD request
solely to obtain referrals.
Therefore, it seems advisable to limit the use of this extension to the
HEAD method which, after all, corresponds to the incipit of Section 4.1.
Contextually, RFC8982 could be extended to use lookup to get the
referrals on demand and reduce the GET response payload size.
It may be that all this document needs to do is standardize the value of the
"fieldSet" parameter. Unless clients and servers agree on that, there can be no
interoperability.
[ML] Don't see the complexity gap between agreeing on the value of the fieldSet
parameter and agreeing on an extension identifier.
Agreed, this is not complex.
What makes a difference IMO is that an extension identifier is registered while
the fieldSet parameter value isn't.
But RFC8982 can be updated to create a new IANA registry.
That is a separate question but I agree. Unless clients and servers can agree
without prior coordination, there is limited utility.
[ML] To improve interoperability, it doesn't make sense to me to use the
value of a free-text property, such as the title, to distinguish between
links.
Instead, the rel value should be specialized to achieve this goal, such
as rdap-related-rar, rdap-related-rant, rdap-related-tech, and so on.
Best,
Mario
G.
--
Gavin Brown
Principal Engineer, Global Domains & Strategy
Internet Corporation for Assigned Names and Numbers (ICANN)
https://www.icann.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 -- [email protected]
To unsubscribe send an email to [email protected]
