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?
-Tom
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
