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

[Mario Loffredo <[e-mail]>]

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/
>
>  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.
>
[ML] Agreed.
>
> *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.
>
[ML] Agreed (see below the comment on Appendix B.2 for more details).
>
> *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.
>
> *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.
>
> *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.
>
> *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.

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.

Best,

Mario


> -- 
>
> JG
>
>
> cid87442*image001.png@01D960C5.C631DA40
>
> *James Gould
> *Fellow Engineer
> [e-mail] 
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
>
> _______________________________________________
> regext mailing list [e-mail]
> To unsubscribe send an email [e-mail]

-- 
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: [phone]
Web:http://www.iit.cnr.it/mario.loffredo