Hi Tom,
please find my comment below.
Il 26/01/2024 04:29, Tom Harrison ha scritto:
Hi Mario,
Thanks for your feedback.
On Thu, Nov 30, 2023 at 08:21:42AM +0100, Mario Loffredo wrote:
+1
Have just two further notes:
1) Think it would be good to add normative language about partial
matching referencing Section 4.1 of RFC 9082 .
Thanks, this has been added.
2) Per what is stated in section 4.1 0f RFC9083, the rdapConformance
array in the examples Section 4 should include only the extensions
used in the response.
For sure the response including the ipSearchResults array will never
include the autnumSearchResults array and viceversa ;-)
The same goes for the responses including the links about ips or
autnums. Instead, the help response should include all the
extensions implemented. As a result of this, the first two
paragraphs of Section 6 should be modified as well.
We think that the existing text/behaviour should be left as-is in this
respect. Section 4.1 of 9083 says:
A response to a "help" request will include identifiers for all of
the specifications supported by the server. A response to any
other request will include only identifiers for the specifications
used in the construction of the response.
and that any response which makes use of any part of the RIR search
specification should therefore include all of the identifiers defined
by the RIR search specification, since each of those identifiers will
be "for [one of] the specifications used in the construction of the
response". An alternative reading along the lines of your suggestion
would require associating identifiers with specific functionality in
the document. While that's relatively straightforward in this case,
it would require extra, possibly unintuitive guidance in the document
as to when identifiers should be included. It's also not clear that
it yields much benefit for the client, either: while it would be
possible in theory for a client to implement/understand only part of
an extension, such that a response with a subset of the available
identifiers could be processed without having to go to the trouble of
implementing/understanding the whole extension, that doesn't seem like
something that would come up much in practice, given that most
extensions are quite short/straightforward. What do you think?
Think it would be good to involve the WG in the diiscussion. Literally
RFC 9083 states that only the identifiers of those extensions used in
building a response can be included in the rdapConformance array.
Have always thought that its purpose was to inform clients about the
extension prefixes they should be ready to recognize when deserializing
the response.
For this reason, including in the rdapConformance array an extension
identifier that is not used in the response could be misleading for
clients.
Besides, mentioning in rdapConformance only the extensions used in the
response doesn't mean that either the server or the client can have a
partial knowledge of the specification defining them.
Otherwise wouldn't understand the need to distinguish between the
rdapConformance value in the help response and that in the other responses.
But my interpretation might be too restrictive as well as yours might be
too permissive. Better to listen to other opinions and finally agree on
a shared interpretation.
Best,
Mario
-Tom
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
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
