Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: Gould, James <jgould=[e-mail]>
> Sent: Monday, July 18, 2022 1:06 PM
> To: Hollenbeck, Scott <[e-mail]>; [e-mail];
> [e-mail]
> Cc: [e-mail]
> Subject: [EXTERNAL] Re: RE: RE: Re: [regext] OK, What Next? (was RDAP
> Extensions Approach Analysis v2)
>
> Caution: This email originated from outside the organization. Do not click 
> links
> or open attachments unless you recognize the sender and know the content
> is safe.
>
> Scott,
>
> >    You can't give drafts, and the content they contain, implementation
> status
> >    that they don't have. I get the value of implementation experience, but
> that
> >    doesn't mean that we can add something to IETF processes that doesn't
> exist.

> I'm not stating that a draft has the implementation status, but by 
> supporting
> pointed versioning and minimal client / server impact to draft updates, it 
> will
> encourage implementations and contribute to the implementation status
> section.  We found the pointed versioning to be very useful with the EPP
> extensions, which should be reused for RDAP extensions.

[SAH] You're putting content into a document that has no formal status with 
the expectation that implementations will do something with version 
information that changes over time. It might be useful, but you really 
shouldn't be doing it.

> > [SAH] As I mentioned in my response to Mario, part of the answer may
> > lie in the server NOT removing support for older versions of an
> > extension if it wishes to provide backward compatibility.
>
> Eventually the support for the old version can and will go away on the 
> server-
> side, where embedding the version into all the extension elements can
> create interoperability issues without the prior knowledge of the server.
> There is no version negotiation in RDAP, so once the old version support is
> removed, a client implementation can be broken.  Using just the RDAP
> conformance for hinting / signaling the support of the versioned
> extension(s), can be adjusted by the server with little to no impact to the
> clients.

[SAH] "There is no version negotiation in RDAP"? It's not done the same way 
it's done in EPP, but it certainly is possible. Look at Section 3.1.6 of RFC 
9082:

"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."

A client can submit a "help" query to an RDAP server to request information 
before doing anything else. If the server publishes information describing 
supported extensions, versions of supported extensions, etc., the client can 
then choose which features it wishes to use based on the information received 
in the "help" response, which contains an rdapConformance data structure along 
with everything else the server returns. The server will know which versions 
of extensions are being requested by the client based on the prefix the client 
prepends to the extension elements sent in subsequent requests.

Scott