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. "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. 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. 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? 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. "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. 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. 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. 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. 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/> _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
