Upon a re-review of draft-ietf-regext-rdap-x-media-type with draft-ietf-regext-rdap-x-media-type-02, I have the following feedback:
Section 2 "RDAP-X: The RDAP With Extensions Media Type" Needs to be updated to support the Extension Version Identifier implicitly or explicitly, defined in Section 3.1 "Extension Version Identifier" of draft-ietf-regext-rdap-versioning. The mailing list feedback https://mailarchive.ietf.org/arch/msg/regext/L377YVNleqV7s7tJPWTGBLJIIG4/ provided an implicit (compatible) recommendation with draft-ietf-regext-rdap-versioning, and below is an explicit recommendation as well. Implicit Support included in https://mailarchive.ietf.org/arch/msg/regext/L377YVNleqV7s7tJPWTGBLJIIG4/ 1. In Section 2: Change "This media type has a parameter of "extensions" which is a whitespace-separated list of RDAP extensions as defined in the IANA RDAP Extensions registry" to "This media type has a parameter of "extensions" which is a whitespace-separated list of RDAP extensions, such as defined in the IANA RDAP Extensions registry”. 2. In Section 3: Change “the values in the media type's extension parameter SHOULD match the values in the rdapConformance array in the return JSON.” to “the extension identifier values in the media type's extension parameter SHOULD match the values in the rdapConformance array in the return JSON.” Explicit Support 1. Make "I-D.ietf-regext-rdap-versioning" a Normative Reference instead of an Informative Reference 2. Add RFC5234 as a Normative Reference to leverage ABNF to formally define the format of the “extensions” parameter. 3. Update Section 2 to be modeled after Section 3.2.1” Versioning Query Parameter” in draft-ietf-regext-rdap-versioning, by using ABNF and referencing the extension-versioning-identifier ABNF rule from draft-ietf-regext-rdap-versioning, as in: The media type defined by this document is "application/rdap-x+json". This media type has a parameter of "extensions" that is a list of one or more Extension Version Identifiers, as defined in Section 3.1 of [I-D.ietf-regext-rdap-versioning<https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-versioning-02>], separated by whitespace. This media type, RDAP with Extensions, is referred to as RDAP-X. The Augmented Backus-Naur Form (ABNF) grammar<https://www.rfc-editor.org/info/rfc5234> [RFC5234<https://www.rfc-editor.org/info/rfc5234>] format for the "extensions" parameter, using the "extension-version-identifier" rule from Figure 1 of [I-D.ietf-regext-rdap-versioning<https://datatracker.ietf.org/doc/html/draft-ietf-regext-rdap-versioning-02>], is: extensions = "extensions=" DQUOTE extension-version-identifier *(WSP extension-version-identifier) DQUOTE Examples of RDAP-X: applications/rdap-x+json;extensions="rdap_level_0 rdapx" applications/rdap-x+json;extensions="rdap_level_0 rdapx fred" Note - It looks like the "rdapx" extension identifier is missing from the example, so I added it. Section 3 "Using The RDAP-X Media Type" My initial thought upon re-review of this section was to reuse the existing "application/rdap+json" media type by adding the optional parameter "extensions", or better "rdapx" to the media type registration, but then I got to Appendix B.1 that makes a good point with the language in RFC 6838. I really don't want to include RDAP-X in the content-type header of the response, since it duplicates the rdapConformance member, and requires updating RFC 7480 with no real positive value. Updating RFC 7480 may also trigger the need to bump rdap_level_0 to rdap_level_1, which is certainly not desired. We should re-evaluate the language of RFC 6838 in its application to an RDAP extension. How about adding support for RDAP-X in the accept header of the request and to have the response content-type header remain using the existing media type of "application/rdap+json"? This would meet the need of the client providing the RDAP extension hints without the negative side effects of updating RFC 7480 and bumping rdap_level_0 to rdap_level_1. Section 4 "Usage of RDAP Links" The point of this section is recursing the RDAP extension hints in the links, which would also apply to the use of the query parameter of the versioning extension. We can review for this applicability in the versioning draft. Section 6 "Security Considerations" You can remove the second paragraph, since that would be covered in an extension that supports query parameters, such as the versioning extension. Section 7 "IANA Considerations" I would add an RDAP Extensions Registry registration for "rdapx". Appendix A "Using the Vary Header" Wouldn't this recommendation be covered in a different draft, such as draft-ietf-regext-rdap-extensions since it's not specific to RDAP-X? Appendix B.1 "Not Reusing the Existing Media Type" This section helped me out since my thought was to reuse the existing "application/rdap+json" media type instead of defining the new RDAP-X media type. The language in RFC 6838 is clear and adding the capability of providing hints of the RDAP extensions is new functionality, but I really don't see that it's adding new functionality for the media type itself. We could define the existing "application/rdap+json" media type optional parameters as a form of extension in the extensions draft, where it will become an extension point without adding new functionality specific to the media type itself. The response is still RDAP using JSON independent of the mix of extensions that are used. If use of an optional media type parameter of the existing "application/rdap+json" media type cannot be done, can RDAP-X be used in the accept header and not returned in the content-type header to get the value of RDAP-X without the negative side effect of updating RFC 7480 and bumping rdap_level_0 to rdap_level_1? Appendix B.2 Inappropriate Use of Query Parameters This section should be removed and any relevant content covered in draft-ietf-regext-rdap-extensions. It adds confusion to the draft since there are many RDAP extensions and RFCs that have used query parameters with no issue. Specifying the value of living through an HTTP redirect should be good enough without having to list how query parameters are inappropriate, which will have a hard time finding consensus. I don't agree with many of the arguments against the use of query parameters, where I would leave the decision up to the client based on their needs. -- JG [cid87442*image001.png@01D960C5.C631DA40] James Gould Fellow Engineer jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/>
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
