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

[Mario Loffredo <[e-mail]>]

Hi Pawel,

Il 21/11/2024 21:46, Gould, James ha scritto:
>
> Pawel,
>
> The client doesn’t pass a range of versions but passes the extension 
> versions that they want to override from the default set of versions 
> supported by the server.  The version provided by the client is a hint 
> and not a directive that would result in a failure in processing the 
> request.  The client may be concerned about the version of an 
> individual RDAP extension, so they would specify which version that 
> they prefer to be returned.  The server returns in the “versioning” 
> member of the response, which extension version was used.  “Best 
> fitting” sounds interesting, but I’m not sure how that will work in 
> practice.  The client can determine on a per server basis what 
> extension versions are supported and provide the hint to the server 
> what extension versions it wants included in the response and it’s up 
> to the server to determine how to apply the hint.  If the hint 
> provided by the client doesn’t match one supported by the server, I 
> would simply return the default version, since determining the “best 
> fit” is not very deterministic and won’t be clear to the client why 
> their extension version hint wasn’t honored.
>
> Do others feel that providing version ranges and the server applying a 
> best fit is preferable over having a default set of extensions 
> versions in the server that the client can override by provided a 
> match with one of the supported extension versions in the query?
>
Can you please elaborate on which use case corresponds to support a 
default version that is six versions back to the next version and no 
version in between ?

Honestly, can't imagine any practical case like the one you described.

One coming in my mind is that all the versions between 0.4 to 0.9 could 
be related to additive changes and the server is able to support all of 
them.

Instead, it seems more likely to me the scenario where the client 
requests for an extension version not yet supported by the server but 
supported elsewhere (e.g the client requests for version 0.9, but the 
higher version supported is 0.8).

In that case, the server could return version 0.8 as the best fitting 
compatible but that would be based on an assumption made by the server 
that the client couldn't always share and I agree with James that the 
server operation wouldn't be deterministic.

Therefore, IMO  it's better for the server to have a default version as 
a fallback. Likewise the client would have to manage only two options: 
the server returns the requested version or the server returns the 
default version.

Please note also that as a general rule the default version corresponds 
to the last one stable hence it wouldn't be received by the client as 
something unexpected.  Further versions are normally provided for testing.

Finally, it seems to me that the implementation of the "best fitting" 
strategy can be tricky when dealing with opaque extension identifiers  
as the versioning information is embedded or even missing in that case.


Best,

Mario

> -- 
>
> 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 2:06 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,
>
> Again, the proposal for 1-RTT model is that the client would put a 
> range of versions it supports into a request and the server would put 
> best efforts to fulfil it. Like 
> ?versioning=versioning-0.3-versioning-0.9,versioning-1.0+. Current 
> draft allows listing all supported versions one by one, but this list 
> may grow big in this case. The draft is not clear about what to do if 
> server does not support the requested version. Say server supports 0.3 
> (default) and 0.9 and client requests 0.6. It would be better for the 
> client that the server responds with 0.9 (best fitting compatible 
> version with 0.6) rather than with default 0.3.
>
> Also a redirect target server can deliver the best fitting response 
> rather than falling back to default.
>
> Kind Regards,
>
> Pawel
>
> On 21.11.24 19:26, Gould, James wrote:
>
>     Pawel,
>
>     The server has a default set of extensions with or without the
>     versioning extension and will return the defaults.  I don’t see
>     your concern with exposing the supported extension versions in the
>     help response, since it really doesn’t require a 2-RTT flow.  The
>     lazily option includes the sub-option of manually using the
>     meta-data to address an error.  If there was no versioning
>     extension, there would be no meta-data within RDAP to use to
>     determine the root cause of the extension issue when the server
>     supports more than one version of an extension at a time.
>
>     The versioning extension is optional for the RDAP client to
>     implement, as should be the case for other RDAP extensions,
>     provides help information in the help response per RFC 9082, and
>     the help information can be used at any time automatically or
>     manually when needed.  Introducing an optional RDAP extension that
>     provides extra meta-data in the help response in no way implies
>     the need for a 2-RTT flow.
>
>     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://secure-web.cisco.com/1Wv2EPn7C7-lq0WVPWcTsrUPEGLQP0VH_PZJ6W3FGEMShJ6WQrFGrV00PI1XZH6wmHJxSHxXEviOqbCXI7AKeQw0R9_BY6fjiPgX6X3B-ugjuTyXJ8a_xSOzZCVVjf4g154WAMHR288btNwdVKRalmjuYjLY_EE5IHPFIadaRsKUyPjNAdhjJiVDWPeyGtqcPwXPBuqSP-3FjmzjaAKydvLNPrRuhllWtvIQB9S1-eblJKIHkIDy5fcgre6NiJNVuIbBba_rUchnLxVuGaGHkNiWpU01GHMDj7gClM71wgpk/http%3A%2F%2Fverisigninc.com%2F>
>
>     *From: *"[e-mail]" <mailto:[e-mail]>
>     <[e-mail]> <mailto:[e-mail]>
>     *Date: *Thursday, November 21, 2024 at 1:16 PM
>     *To: *James Gould <[e-mail]>
>     <mailto:[e-mail]>, "[e-mail]"
>     <mailto:[e-mail]> <[e-mail]> <mailto:[e-mail]>
>     *Subject: *[EXTERNAL] Re: [regext] RDAP versioning - on
>     client-server interactions and 2-RTT flow
>
>     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://secure-web.cisco.com/11KWO61ONP3_D4UFnzav5ddD672ljzIQFbvruzfwmY-UufG83Q9qeOASRq90wZO8rDn82Gl4ezO8LFsywN9iX3eaC5gYTNS0Ozvj6CU2GBLBBSRCuB6e9EGJKiN-NcQtPiB-HOey2X25gQ3_nyB0nxGbKVW4I55_OmmuVgZhhNnOt8694hHAgDJ3cpDNm5pqCcCUsdenKtJtfBm-zU1I_FIaakyB7wjBqGUrVlscG4wTNhTveqTvx8r4FVlGeYNJygo_yFL8fQACGVkqOV9ksrUYTvvW5KIx1v_eOO6w4acI/http%3A%2F%2Fverisigninc.com%2F>
>
>         *From: *"[e-mail]" <mailto:[e-mail]>
>         <[e-mail]> <mailto:[e-mail]>
>         *Date: *Thursday, November 21, 2024 at 12:36 PM
>         *To: *James Gould <[e-mail]>
>         <mailto:[e-mail]>, "[e-mail]"
>         <mailto:[e-mail]> <[e-mail]>
>         <mailto:[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
>
>               
>
>               
>
>               
>
>               
>
>               
>
>
> _______________________________________________
> regext mailing list [e-mail]
> To unsubscribe send an email [e-mail]

-- 
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: [phone]
Web:http://www.iit.cnr.it/mario.loffredo