[regext] Re: draft-ietf-regext-rdap-x-media-type-02 Feedback

["Andrew Newton (andy)" <[e-mail]>]

responding to both Mario and JGould in line...

On Mon, Nov 4, 2024 at 5:50 AM Mario Loffredo
<mario.loffredo=[e-mail]> 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