[regext] Re: RDAP versioning draft feedback

[[e-mail]]

Hi Jim,

To recap on what we discussed in Dublin and to also have input from the 
working group.

Jasdip stated a very valid question. Reading through the draft in more 
detail I also have a feeling that we are trying to use a sledgehammer to 
crack a nut.

The problem to solve was that RDAP was lacking of clear way of 
signalling that there is a different version of the same extension, so 
the client would know that foo1 and foo99 are indeed version of the same 
extension and not different unrelated extensions.

What the draft proposes is very feature reach, but does not tell a lot 
about why clients and servers should spend time implementing all of its 
features. Do we expect an RDAP extensions to have tens or hundreds of 
versions, so that the clients would need to apply a logic of semantic 
versioning to work on ranges of versions and distinguishing major and 
minor versions? If we talk about extensions from IETF control this is 
not likely to happen, just because of how IETF process works. Why do we 
need extensibility to even support more versioning semantics (Versioning 
Type)?

What we expect clients to do with all the related lifecycle information 
(start/end/default)? I can make some usefulness for the "end" attribute 
(like warning about using deprecated interface), but mandating the 
server (normative MUST) to remove the support exactly at this time seems 
like a void requirement, as operationally quite hard to fulfil unless 
the server would implement special logic for management of versions of 
extensions. A bit of overhead for very little gain if you ask me. 
"start" is something with even less usefulness as we are talking about 
future version. Here there are a lot of assumptions that the server 
deploys a future version and only activates it later at a given point in 
time. Again a logic not really needed. The client will learn about new 
version when it's there and supported by client anywhere.

I would double what Jasdip stated below, that opaque versioning - with 
just adding semantics to one symbol "-" splitting extension identifier 
into name and version would do the same good job and be a way simpler.

If someone would like to release a new version of their extension every 
month (as sais likely outside of IETF), another semantic for versioning 
would be good for it and within the opaque version part. But then it 
might be a part of their particular specification and would only concern 
clients dealing with this particular extension.

K.I.S.S.

Kind Regards,

Pawel

On 03.11.24 22:50, Gould, James wrote:
>
> Rationale for versioning:
>
> Section 1 says, “The RDAP Conformance values are identifiers with no 
> standard mechanism to support structured, machine-parseable version 
> signaling by the server.” It’d be good to elaborate with usage 
> scenarios where such structured versioning is a value-add for clients 
> beyond what the opaque (no inner meaning) extension identifiers from 
> STD 95 afford. Let’s say an extension is “foo1”, then “foo99”, and 
> later “foo2” in terms of “versions”. The server announces its support 
> for these non-structured extensions, say, on its web site or through 
> the “rdapConformance” member in a /help response, and the clients can 
> then negotiate a particular non-structured version of this extension 
> using the standard HTTP content negotiation methodology (e.g., using 
> the RDAP-X media type). In the spirit of what-not-to-do, it is fair 
> for a client to ask: Why should I go through the overhead of 
> processing the “versioning_help” member? What value-add does it get 
> me? Is it in some way a better discovery and/or negotiation method for 
> RDAP extensions? Would be good to beef up the rationale for structured 
> versioning.
>
> JG – We need to ensure that RDAP-X supports the extension version 
> identifier as well, so there should be no variance between the 
> versioning extension and the RDAP-X extension.  We can add more 
> rationale in Section 2 “Semantic Versioning”, where a server could 
> support multiple versions of an extensions that are signaled as 
> related.  For the versioning extension itself, there have been 
> multiple versions of it that are not structurally different and not 
> backward compatible, with the latest version being “versioning-0.3”.  
> Other RDAP extensions could leverage semantic versioning during 
> development to encourage implementation with version isolation and 
> with clear relationship between the extension version identifiers. Do 
> you believe that we should look to add the concept of relationships 
> between opaque version identifiers?
>
Kind Regards,

Pawel