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
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 toregext-le...@ietf.org
--
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: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
