Inline... On Fri, Jul 18, 2025 at 4:50 PM Gould, James <[email protected]> wrote: > "This parameter is a whitespace-separated list of RDAP extensions as defined > in the IANA RDAP Extensions registry." should be "This parameter is a > whitespace-separated list of RDAP extensions as defined in the IANA RDAP > Extensions registry or the Extension Versioning Identifier, as defined by > [I-D.ietf-regext-rdap-versioning] ." to support the versioning extension. > > JG-Not Addressed: The language does not support the passing of the Extension > Version Identifier in the parameter. Additional incompatible language in > Section 3 with “the values in the media type's "exts_list" parameter MUST > match the values in the "rdapConformance" array in the returned JSON”, which > doesn’t support the inclusion of the Extension Version Identifier.
I guess I misunderstand how the versioning I-D is supposed to work. Does the versioning I-D not require the extension identifier with the versioning information be put in the "rdapConformance" array? If so, that seems to be overly complicated. > JG- Not Addressed: I recommend removing the sentence “This behavior is > backwards-compatible as RDAP clients must ignore unknown RDAP extensions as > specified by [RFC9083].”, since this is not referencing the extension JSON > members that is associated with the language in RFC 9083 with “Clients of > these JSON responses SHOULD ignore unrecognized JSON members in responses”. Ok. This can be modified to "This behavior is backwards-compatible as RDAP clients should ignore unknown RDAP extensions as specified by [RFC9083]". Or do you disagree that RDAP clients ignore unknown extensions? > With "Likewise, if a server is required to use an extension in a response > that was not requested by the client, the server MUST respond as if the > client had requested the extension.", it may be better simply to state > earlier that the extensions are a hint from the client what extensions to > include in the response. The query must not fail due to a mismatch of the > extensions specified in the query, since the server will return what > extensions are included in the response based on the client hint and server > policy. > > JG- Not Addressed: I don’t see specific updates in -04 associated with this > feedback item. I am not sure I understand the practical difference in what you are suggesting. Can you please provide exact text? > JG- Not Addressed: Why include the “exts_list” parameter in the response as a > duplicate to the “rdapConformance” array and the subset of the > “versioning_data” JSON member. The current draft says it must match if included but does not recommend using it all. So I don't know why you think this is not addressed. > JG- Not Addressed: it’s unclear the value in including the exts_list > parameter in the server response. I recommend removing the use of the > parameter in the server response. See above. What's not clear about saying the values in the "rdapConformance" array must match the "exts_list" parameter if the "exts_list" parameter is used? > JG-Not Addressed: -04 extended this section instead of removing it. Section > B.2 is not adding clarity to the draft and contains opinions that are not > aligned with the use of query parameters in RFC 9082 and many RDAP > extensions, including draft-ietf-regext-rdap-versioning. In your previous email you asked "Where in RFC 3986 does it state that the query parameter is part of the identity of the resource?" The draft now quotes that part of RFC 3986. Are you saying 3986 is wrong? And this is consistent with 9082, where those query parameters identify resources which are collections of RDAP objects but they do not change the way those objects are rendered. If you would like, I can expand the section to include an example using a 9082 query parameter. -andy _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
