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.
* 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
* This could be automated with the first error and then stored with the
correct extension versioning information for subsequent queries.
* 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
jgo...@verisign.com<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com<http://verisigninc.com/>
From: "kowa...@denic.de" <kowa...@denic.de>
Date: Thursday, November 21, 2024 at 12:36 PM
To: James Gould <jgo...@verisign.com>, "regext@ietf.org" <regext@ietf.org>
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
jgo...@verisign.com<mailto:jgo...@verisign.com>
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com><mailto:applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com>
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"
<kowa...@denic.de<mailto:kowa...@denic.de>
<mailto:kowa...@denic.de><mailto:kowa...@denic.de>> 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
_______________________________________________
regext mailing list -- regext@ietf.org
To unsubscribe send an email to regext-le...@ietf.org
