inline...
On Mon, Nov 18, 2024 at 1:14 PM Gould, James <jgo...@verisign.com> wrote:
>
>
> 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.
I don't see the connection between your text and those slides.
But your text does not accurately describe the issue. rdapConformance
is a JSON array of JSON strings, where each string contains an
extension identifier. That array and those strings are machine
parsable and it is easy for a client to distinguish one string from
another. There is no structure to the value of those strings making
them opaque, but a client can certainly distinguish one from another
meaning a client can know the difference between "foo0" and "foo99".
>
> 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].”
+1
>
> 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.
Are you saying client implementers should not be given notice that one
of these methods has potential problems? And shouldn't the one with
problems be depreffed in favor of the other?
>
> 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.
See above.
>
> 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.
>
I agree this is scope beyond version extensions, however this document
already goes beyond the scope of extensions in Section 4.1 by bringing
in rdap_level_0 (and rdap_level_1), which is not an extension
identifier. Overall, I view this document as being very useful for
troubleshooting and my suggestion follows much of what you already
have.
-andy
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
