Hi, I reviewed draft-ietf-regext-rdap-x-media-type-04 and include the feedback items that were addressed and not addressed embedded below, prefixed with "JG-". From a high level, we need to ensure that draft-ietf-regext-rdap-x-media-type is fully compatible with draft-ietf-regext-rdap-versioning.
Thanks, -- 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 6/20/25, 8:33 AM, "Gould, James" <[email protected] <mailto:[email protected]>> wrote: I did a fresh review of draft-ietf-regext-rdap-x-media-type-03 and below is my feedback. Section 2 “The RDAP Media Type with Extensions Parameter The “extensions” parameter needs to be associated with the registered extension identifier. It could be “rdapExtensions1" if that's the intended extension identifier, which is a bare identifier or " rdapExtensions1_list" as discussed on the mailing list. This the first reference to the "extensions" parameter, but the feedback applies throughout the draft. JG- Addressed: Updated to use “exts” as the extension identifier and the use of “exts_list” as the parameter "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. Section 3 "Using the Extensions Parameter" "If both a client and a server support the "extensions" parameter, and the client requests an extension that is unimplemented by the server, the server MUST respond with only extensions implemented by the server." should be updated to " If both "a client and a server support the "extensions" parameter, and the client requests an extension that is unimplemented by the server, the server MUST respond with only extensions included in the response by the server." I don't believe that the "extensions" parameter is meant to return all possible implemented extensions by the server but only the extensions included or implemented in the response by the server. JG- Addressed I'm unclear what unknown extensions "This behavior is backwards-compatible as RDAP clients must ignore unknown extensions as specified by [RFC9083]." Is referring to. Is this referring to the inclusion of the x-media extensions parameter in the response, since the prior sentence is referring to the server receiving a reference to an unimplemented extension? 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”. 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. "the values in the media type's "extensions" parameter MUST match the values in the "rdapConformance" array in the returned JSON." indicates duplication of data with no additional value. Why include the extensions in the response in two places? I agree with Maarten that it may be best to just include the "extensions" parameter in the query, since the information is in the rdapConformance list and if the versioning extension is implemented more specific extension versioning information is included in the "versioning_data" JSON member. 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. Section 3.1 "Extension Identifier" I don't view x-media as being an RDAP "profile" extension since it is adding an extension element to the RDAP query and response with the use of a media type parameter. JG- Addressed Section 3.2.5 "Extension Versioning and Meta-Data" During my review, I was thinking about the use case of what to include in the "extensions" parameter of the response when the server implements the versioning extension. I agree with the approach outlined in section 3.2.5, where the client provides its hint in the query and the server responds with only the extension identifiers, although it may be better not to return the "extensions" parameter in the response since it's a duplicate of the rdapConformance member. 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. Section B.2 "Inappropriate Use of Query Parameters" This section should be removed or modified to only define the use cases where the media type parameter is needed (e.g., make it a positive instead of a negative). Where in RFC 3986 does it state that the query parameter is part of the identity of the resource? Query parameters can provide additional hints and options in the query that applies to the hint of extensions as well. In RFC 9110, the format of the content would be negotiated via the media type, where nothing is changing in the format, languages, or encodings of the data by providing the hint of RDAP extensions. I recommend removing section B.2.4, since the use of a query parameter for signaling desired RDAP extensions is not an architectural violation of HTTP. 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. Thanks, -- 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/>> _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
