Hi Mario,
From: Mario Loffredo <[email protected]> Date: Friday, September 18, 2026 at 3:53 AM To: Jasdip Singh <[email protected]>; [email protected] <[email protected]> Subject: Re: [regext] RDAP JSContact request with both "versioning_list" and "exts_list" media parameters The "Request for JSContact” section says: "If a server receives a request that uses both mechanisms, it MUST process the "versioning_list" parameter and MUST ignore the "exts_list" parameter for the purpose of selecting the contact representation.” It is better now that “versioning_list” emulates “exts_list” as a parameter of “application/rdap+json”, abandoning the problematic query parameter approach for content negotiation. :) One suggestion: since “exts_list” is purposed for negotiating extensions and “versioning_list” for semantic versions of extensions (motivated by the draft-authoring scenario), it would be good to clarify why “versioning_list” is preferred over “exts_list” here. An extension version identifier included in "versioning_list" takes precedence over the corresponding extension identifier in "exts_list," as it provides a more specific indication of the extension version requested by the client. Furthermore, the presence of an extension version identifier implies support for the extension itself. In my view, this should be a general rule; that is, it should apply to any extension supported by a server implementing Point Versioning. The .it public RDAP test server applies this policy to all extensions: when both media type parameters are included in the request, the content of the "exts_list" parameter is ignored. I do not believe a server should also consider extensions listed in "exts_list" but not in "versioning_list.” [JS] These seem fair points if a client is interested in greater specificity of semantic versioning. However, this specification is expected to provide guidance limited to the handling of this extension, rather than the handling of other extensions. To simplify server-side handling of cases where both RDAP media type parameters are included in a request, I believe the server policy should establish which parameter takes precedence, rather than leaving this aspect to be defined by any single extension. Therefore, upon further review, I am more inclined to replace that sentence with one that delegates to the server the task of specifying which parameter should be considered. [JS] That should help. Any feedback from you and others is appreciated. [JS] Thanks for highlighting this scenario. Jasdip
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
