[regext] Re: RDAP versioning - on client-server interactions and 2-RTT flow

["[e-mail]" <[e-mail]>]

Hi Jim,

Got it. These are all optimisations of 2-RTT model.
I am missing your feedback to my 1-RTT proposal and risks related to 
redirects in 2-RTT scenario.

Kind Regards,

Pawel

On 21.11.24 19:00, Gould, James wrote:
>
> Pawel,
>
> The client has multiple options:
>
>  1. Proactively leverage the versioning help with every query (2-RTT)
>     or a pre-defined intervals to keep the configuration accurate.
>      1. I don’t see the extension versions changing frequently and the
>         versioning extension does support pre-publishing support for
>         an extension version to the client, so my recommendation would
>         be to check it daily or even less frequently in a single client.
>  2. Lazily leverage the versioning help when there is an identified
>     extension version issue
>      1. This could be automated with the first error and then stored
>         with the correct extension versioning information for
>         subsequent queries.
>      2. This could be manual when an error is reported, and operations
>         uses the versioning help to diagnose the issue for a fix.
>
> There are probably many additional options, where having the meta-data 
> along in the versioning help (e.g., “versioning_help” member) with the 
> extension versioning detail with each response (e.g., “versioning” 
> member) should provide value with any RDAP client to address extension 
> compatibility issues automatically or manually.
>
> Thanks,
>
> -- 
>
> 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/>
>
> *From: *"[e-mail]" <[e-mail]>
> *Date: *Thursday, November 21, 2024 at 12:36 PM
> *To: *James Gould <[e-mail]>, "[e-mail]" 
> <[e-mail]>
> *Subject: *[EXTERNAL] Re: [regext] RDAP versioning - on client-server 
> interactions and 2-RTT flow
>
> Hi Jim,
>
> If the client would like to benefit from machine readable version 
> information from versioning extension, there is no way around 2-RTT.
>
> If not, then this extension is basically of no practical meaning to 
> such client, so not really worth considering.
>
> Kind Regards,
>
> Pawel
>
> On 21.11.24 18:29, Gould, James wrote:
>
>     Pawel,
>
>     RFC 9082 states the following for the Help Path Segment:
>
>     The help path segment can be used to request helpful information (command syntax, terms of service, privacy policy, rate-limiting policy, supported authentication methods, supported extensions, technical support contact, etc.) from an RDAP server. The response to "help" should provide basic information that a client needs to successfully use the service.
>
>     This is exactly what the versioning extension is doing in the "versioning_help" member, by providing help information on supported extensions.  A client is not required to use the versioning extension to perform queries, since the server does have a default extension version that is specified in the "versioning_help" member.  If a client does run into an extension compatibility issue, it could use the help command to programmically (lazily) or manually determine the root cause of the issue for resolution.
>
>     There is no requirement or expectation that an RDAP client implement 2-RTT.
>
>     Thanks,
>
>     -- 
>
>     JG
>
>     James Gould
>
>     Fellow Engineer
>
>     [e-mail] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]> <mailto:applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
>     703-948-3271
>
>     12061 Bluemont Way
>
>     Reston, VA 20190
>
>     Verisign.com<http://verisigninc.com/> <http://secure-web.cisco.com/1i4F4XceuHxhs-b9i0KfN2SASQv-TqK69F2z5EdAqIhCxvhNvC3WwTfK6ANtRgjWLd-R8d-Cqyv-UD-CDH530aIlcZGBWm2yG1KKtbY1TC3EuirdyZQMdD6m8QZxEis3VeDni07o4rQRu8oP6EsH75zHCBqovfVVxdTQR2RG4TWq-JSOiQGFBxZo-rT98XqthLeXHhlNAGdU4WeXMwzWqT6EUQND3wycz-A1IZhl6TZs0OrUj1i16L6RWb2XC51tpxYvBo1-crVyGevQ5AGLM6MWtAFYuGnkJXhUPgBL98fI/http%3A%2F%2Fverisigninc.com%2F> 
>
>     On 11/21/24, 12:19 PM, "Pawel Kowalik" <[e-mail] <mailto:[e-mail]> <mailto:[e-mail]>> wrote:
>
>     Hi,
>
>     Thinking of interactions between the client and server that versioning
>
>     draft assumes I think we are heading towards 2-RTT model for every request.
>
>     Step 1: The client makes an HTTP GET request to the /help endpoint of
>
>     the RDAP server.
>
>     Step 2: The response is processed to extract rdapConformance and versioning.
>
>     Step 3: Compare the server's supported extensions and versions with
>
>     those supported by the client.
>
>     Step 4: If compatible configurations are found, the client makes target
>
>     request to a resource endpoint (e.g., domain/foo.com) using headers or
>
>     query parameters to specify the desired configuration.
>
>     So we have 2 full RTTs. Of course a client can cache it for some time
>
>     but not forever, as the server may change at any time its configuration.
>
>     In a cold state or a client without capability to cache this will be
>
>     always 2-RTT if the client would like to be aware of the versions.
>
>     I don't think this is in line with rfc7480, which assumes "a client
>
>     implementation should be possible using common operating system
>
>     scripting tools (e.g., bash and wget)". Also not with the usage pattern
>
>     defined in Section 1. None of it is normative, however I would not just
>
>     ignore it without discussing consequences of going this way.
>
>     I would like to see more that versioning draft would assume 1-RTT model
>
>     as a primary use-case, so that the client would put a range of versions
>
>     it supports into a request and the server would put best efforts to
>
>     fulfil it. This would be also more "redirect friendly", so that a
>
>     redirected request to another server (no matter if with query parameters
>
>     or headers) would have the same information about client capabilities
>
>     and able to serve the response as opposed to getting a request for
>
>     configuration crafted for the origin server of a redirect.
>
>     Kind Regards,
>
>     Pawel
>