Andy,
I'm bringing this thread back up for my latest review of draft-ietf-regext-rdap-x-media-type-05 to see whether my feedback had been addressed. My latest feedback is prefixed with "JG3-". -- 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/20/25, 8:15 PM, "Gould, James" <[email protected] <mailto:[email protected]>> wrote: Andy, My responses are embedded below, prefixed with "JG2-". -- JG James Gould Fellow Engineer [email protected] <mailto:[email protected]> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected] <mailto:[email protected]>> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com <http://verisigninc.com/> <http://verisigninc.com/>> On 7/19/25, 9:45 AM, "Andrew Newton (andy)" <[email protected] <mailto:[email protected]> <mailto:[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]> <mailto:[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. JG3- draft-ietf-regext-rdap-versioning-04 ABNF was updated in Section 3.1 to address the feedback from you, Andy Newton, Jasdip Singh, Pawel Kowalik, and Maarten Wullink. The draft-ietf-regext-rdap-x-media-type-05 language "This parameter is a whitespace-separated list of RDAP extension identifiers (as would be found in the "rdapConformance" array)." Should be updated to "This parameter is a whitespace-separated list of RDAP extension identifiers (as would be found in the "rdapConformance" array) or Extension Versioning Identifiers, as defined by [I-D.ietf-regext-rdap-versioning] ." This enables the use of both opaque and maturity versioning in draft-ietf-regext-rdap-versioning using the “exts_list” parameter in draft-ietf-regext-rdap-x-media-type. The existing language only supports opaque 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. JG3-Not addressed. My recommendation is to remove the sentence “This behavior is backwards-compatible as RDAP clients must ignore unknown RDAP extensions as specified by [RFC9083]”, since it’s not appliable to processing unknown extension identifiers in “exts_list” parameter. If this sentence needs to remain, it could be changed to “The server Ignoring unknown extensions in the “exts_list” parameter is consistent with RDAP clients ignoring unknown RDAP extensions as specified by [RFC9083]” > 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. JG3 – Addressed; although I would reuse the use of the word consistent instead of backward compatible, since RFC9083 is all about the client ignoring something unknown and not the server processing the “exts_list” parameter mismatch. The sentence “This behavior is backwards-compatible as RDAP clients should ignore unknown extensions as specified by [RFC9083<https://www.rfc-editor.org/info/rfc9083>].” Could be “This behavior is consistent as RDAP clients should ignore unknown extensions as specified by [RFC9083<https://www.rfc-editor.org/info/rfc9083>].”. > 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. JG3-The sentence “When the "exts_list" parameter is used in the RDAP media type in the "content-type" header, the values in the media type's "exts_list" parameter MUST match the values in the "rdapConformance" array in the returned JSON” looks to indicate that the server may include the “exts_list” parameter and that it must match the “rdapComformance” array. I don’t see any examples that include the “exts_list” parameter in the “content-type” header of the response. I recommend removing this paragraph and the following paragraph or modify them to be clear that the server does not return the “exts_list” parameter in the “content-type” parameter, such as “The “exts_list” parameter MUST NOT be included in the “content-type” header of the response.” > 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. JG3-If we continue to include the server use of the “exts_list” parameter in the response, we need to ensure that the Extension Version Identifier in draft-ietf-regext-rdap-versioning is supported. > 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. JG3-Section B.2 remains in the draft. How does inclusion of that section help in the clarity of this draft? I view it as the wrong place for guidance on the use of query parameters in RDAP. That is best suited for draft-ietf-regext-rdap-extensions. -andy
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
