Hi all,
just make some comments on Jim's reply .
Please find them below prefixed with [ML].
Il 18/11/2024 19:14, Gould, James ha scritto:
Andy,
Thanks for reviewing draft-ietf-regext-rdap-versioning. I provide responses to your
feedback embedded below, prefixed with "[JG]".
-- JG 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/> On 11/15/24, 4:18 PM, "Andrew Newton
(andy)" <a...@hxr.us <mailto:a...@hxr.us>> wrote: Caution: This email
originated from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content is
safe. Hi, I just read through the versioning draft and have some
feedback. 1. The first clause of the abstract is confusing to me.
Maybe something like this: OLD: This document describes an RDAP
extension for an extensible set of versioning types with the features
of identifying the RDAP extension versions supported by the server,
the RDAP extension versions included in an RDAP response, and enabling
a client to specify the desired RDAP extension versions to include in
the RDAP query and RDAP response. NEW: This document describes an RDAP
extension to describe versioning meta-data of RDAP extensions to be
included in RDAP response, and describes methods for client signaling
of supported extensions. This extension also specifies two versioning
types and a means to add future versioning types, Of course, which is
clearer is a matter of opinion so take it or leave it. [JG] I agree
with your simplified version. 2. In section 1, the sentence on RDAP
conformance values is misleading. I propose: OLD: The RDAP Conformance
values are identifiers with no standard mechanism to support
structured, machine-parseable version signaling by the server. NEW:
The RDAP Conformance values are identifiers that are by default opaque
in nature. [JG] I believe it's important to leave this sentence as is.
The language is based on the chairs proposal on slide 6 of
https://datatracker.ietf.org/meeting/114/materials/slides-114-regext-rdap-extension-identifier-and-rdapconformance,
where "explicit support for version is not an integral part of the
extension mechanism" and "Certainly, you can choose to include version
inside the specification for your extensions, but in the context of
the base protocol an extension is either supported or its not, and
when supported it simply means there is a shared understanding of what
is to be done between the client and server". We need to clear the
issue the versioning extension is addressing, which is to provide
support for a structured, machine-parseable version signal.
[ML] I agree with Jim, We should preserve the meaning of that sentence
that captures the goal of the document, i.e providing support for
structured versioning.
3. The first bulleted point of section 1 describes a client including
information in an RDAP response. It should be that the client signals
to the server and the server includes the information in the response.
[JG] The language is “Enabling a client to specify the desired RDAP
extension versions…”. The RDAP extensions can apply to the query and
the response, so the hint can apply to either. How about changing it
to read “Enabling a client to specify to the server the desired RDAP
extension versions included by the client in the RDAP query and for
the server to include in the RDAP response, using the Extension
Versioning Request (Section 3.2).” The second sentence can be
simplified to not have to repeat this with “The client can specify the
desired RDAP extension versions with the “versioning” query parameter
or the RDAP-X media type “extensions parameter
[I-D.ietf-regext-rdap-x-media-type].”
[ML] I agree that the sentence is a bit misleading and needs to be
clarified.
4. Section 3.2 paragraph 1 gives equivalency to both signaling
methods, but the query parameter may not always work. I suggest the
following: OLD: The client MAY provide an Extension Versioning Request
to indicate the desired extension versions to include in the RDAP
query and RDAP response. There are two Extension Versioning Request
methods with the Versioning Query Parameter (Section 3.2.1) and the
Versioning Extensions Media Type Parameter (Section 3.2.2). The server
MUST support both methods of Extension Versioning Request methods and
the client MUST use at most a single Extension Versioning Request
method in the RDAP query. NEW: The client MAY provide an Extension
Versioning Request to indicate the desired extension versions for
inclusion in an RDAP response by a server. There are two Extension
Versioning Request methods: Versioning Extensions Media Type Parameter
(Section 3.2.2) and Versioning Query Parameter (Section 3.2.1). The
Versioning Extensions Media Type Parameter should be the preferred
signaling method as there are known limitations regarding propagation
of query parameters (see draft-ietf-regext-rdap-extensions). The
Version Query Parameter is used provided to aid in troubleshooting of
RDAP services. The server MUST support both methods of Extension
Versioning Request methods and the client MUST use at most a single
Extension Versioning Request method in the RDAP query. [JG] I don’t
agree with including a preference between the two methods. The
extension supports both with a requirement for the server to implement
both and the client to choose what best meets their requirements. I
don’t believe the versioning extension should replicate the reason for
the X-Media extension considering that the X-Media extension is a
normative reference.
[ML] I don't agree too. Let's clients select their best option.
5. Swap section 3.2.2 and 3.2.1. [JG] I don’t see a reason to swap the
sections, considering that there is no preference between the two. 6.
The "version" JSON member should be marked required in the "versions"
array described in 3.3.2. [JG] Agreed 7. When troubleshooting RDAP
servers, there is other helpful information that would be greatly
beneficial regarding the server version. I propose defining two
objects for "versioning_help", one about the server and one about the
extensions. Here is prototype: "versioning_help": { "server" : {
"server_id": "1", "version": "1.2", "type": "semantic", ... }
"extensions": [ { "extension": "rdap_level_0", "type": "opaque", ...
}, { "extension": "versioning", "type": "semantic", ... } ] }
"extensions" would be the array currently defined in
"versioning_help". "server" would have all the same JSON members as a
"version" object with the addition of "server_id" which is a string
identifying a specific server in a cluster. [JG} This is an
interesting concept that needs more thought. The scope of the draft is
associated with extension versioning, so this would be a change in
scope (e.g., versioning type, server identifier, server meta-data to
include, and overlap with extension versioning). We would need to
cover the use cases and determine the applicability of the features
included in the versioning extension to apply to server versioning. I
don’t recommend inclusion of server versioning yet without more
discussion on the mailing list, since this may be better suited for
another RDAP extension targeted to the use case.
[ML] I wouldn't change the scope of this document. The document is about
extension versions which can be negotiated by clients and servers. If
there is a requirement for adding the server version along with other
server information, it should be addressed by a separate document.
Best,
Mario
-andy _______________________________________________ regext mailing
list -- regext@ietf.org <mailto:regext@ietf.org> To unsubscribe send
an email to regext-le...@ietf.org <mailto:regext-le...@ietf.org>
_______________________________________________ regext mailing list --
regext@ietf.org To unsubscribe send an email to regext-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
