Andy, My responses are embedded below, prefixed with "JG2-".
-- JG James Gould Fellow Engineer [email protected] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> On 7/19/25, 9:45 AM, "Andrew Newton (andy)" <[email protected] <mailto:[email protected]>> wrote: Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Inline... On Fri, Jul 18, 2025 at 4:50 PM Gould, James <[email protected] <mailto:[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. JG2-The versioning extension does not touch the "rdapConformance" array, other than inclusion of the versioning extension identifier. The "exts_list" parameter in draft-ietf-regext-rdap-x-media-type needs to support the passing of Extension Version Identifiers, defined in Section 3.1 of draft-ietf-regext-rdap-versioning, where the Extension Version Identifier supports opaque versioning and semantic versioning. > 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? JG2-I believe that RDAP clients should ignore unknown extensions, but I don't believe references to extensions via draft-ietf-regext-rdap-x-media-type and draft-ietf-regext-rdap-versioning has anything to do with the reference in RFC 9083. RFC 9083 is referring to the JSON members and not extension identifiers. > 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? JG2-How about "The extensions requested by the client represent a hint for the server in determining the extensions to include the response. 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." The use of a "hint" should help make it clear that it's not a contract that should result in a server error. t > 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. JG2-What part of the -04 draft recommends not including the parameter in the response? It may be there, but I don't see it. There are plenty of references of the server including it in the response that is mirrored in the examples. It would be better just to drop inclusion of the "exts_lists" parameter in the response and to remove it from the examples. > 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? JG2-The question is whether the server should include the "exts_list" parameter at all in the response and not what it needs to match. The "exts_list" won't match the "rdapConformance" array if it supports the Extension Version Identifier, as defined in Section 3.1 of draft-ietf-regext-rdap-versioning. > 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. JG2-I'm not exactly sure why draft-ietf-regext-rdap-x-media-type is attempting to make the argument at all. If you want to define the recommendations for the use of query parameters, then update draft-ietf-regext-rdap-extensions to do so. Section B.2 does not add value to the understanding of draft-ietf-regext-rdap-x-media-type and should be removed. You can add the reference to RFC 3986 in draft-ietf-regext-rdap-extensions to have the discussion of it. -andy _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
