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
OpenPGP_0xABB62115F7BCDB04.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
