responding to both Mario and JGould in line... On Mon, Nov 4, 2024 at 5:50 AM Mario Loffredo <mario.loffredo=40iit.cnr...@dmarc.ietf.org> wrote: > > Hi, > > please find my comments inline prefixed with [ML]. > > Il 01/11/2024 12:49, Gould, James ha scritto: > > 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/ > > 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”. > 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 > > Make "I-D.ietf-regext-rdap-versioning" a Normative Reference instead of an > Informative Reference > Add RFC5234 as a Normative Reference to leverage ABNF to formally define the > format of the “extensions” parameter. > 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], separated by whitespace. This media type, > RDAP with Extensions, is referred to as RDAP-X. The Augmented Backus-Naur > Form (ABNF) grammar [RFC5234] format for the "extensions" parameter, using > the "extension-version-identifier" rule from Figure 1 of > [I-D.ietf-regext-rdap-versioning], 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. > > [ML] Agreed.
Thanks. Works for me. > > > > 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. > This is an interesting idea and I think it simplifies things. Thanks. > > > 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. > > [ML] Agreed (see below the comment on Appendix B.2 for more details). > I strongly disagree. We should not be encouraging the accidental leakage of security material. > > > Section 7 "IANA Considerations" > > I would add an RDAP Extensions Registry registration for "rdapx". > > [ML] I agree that this specification is itself an extension insofar it > extends the "application/rdap+json" media type by adding a new optional media > type. > As Homer Simpson would say, "Doh!" Good catch. > > > 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? > > [ML] Have a different opinion about this point. The use of Vary header is > strictly related to the presence of the Accept header. Hence IMO this > recommendation should stay in this document since just this document > describes an Accept-based method used by clients and servers to exchange > information about extensions. > Also note that it is informative text. > > > 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? > > [ML] Think it's worth investigating if this soultion could be feasible. > I think so. We'll look into it. See above. > > > 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. > > [ML] Totally agree on this point. If this document is finally published as > RFC, we'll have a document discouraging the use of query parameter along > with other existing documents presenting extensions that make use of query > parameters. > > Moreover, talking generically about scenarios where redirection is more > likely doesn't provide guidance about when query parameters are allowed and > when they aren't. It is not text that is "talking generically". It is text that describes why the approach was taken and specifically says "for this scenario" referencing the paragraph above which states "Another design approach to communicating RDAP extensions from the client to the server..." Appendix B is all about "why?" and is useful for the other IETF reviewers and for historical context. > > We should recognize that query parameters are the mostly used mean for > clients to provide servers with values, other than options, to be used in > queries. > > To make myself more clear, I'll make an example with RFC8977: > > - the count parameter might be replaced with a specific identifier that a > client may include in the extensions parameter of rdap-x media type to signal > the server that results counting should be applied; > > - conversely, we couldn't do likewise with the sort parameter since the > client needs not only to signal that sort should be applied but also the > sorting information, i.e. the sorting properties and, for each property, the > sorting order. We can change the text to to say: The scope and proper usage of query parameters as they relate to RDAP are further described in draft-ietf-regext-rdap-extensions" instead of the current verbiage which could be read as query parameters are always a problem. -andy _______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
