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

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

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]> 
> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com 
> <http://verisigninc.com/> On 11/21/24, 12:19 PM, "Pawel Kowalik" 
> <[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