> -----Original Message-----
> From: Gould, James <[email protected]>
> Sent: Monday, July 18, 2022 1:06 PM
> To: Hollenbeck, Scott <[email protected]>; [email protected];
> [email protected]
> Cc: [email protected]
> 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
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
