Hi Pawel,
On Wed, Dec 10, 2025 at 08:02:28AM +0100, Pawel Kowalik wrote:
> I don't think it is a good proposal as it is limiting evolution of
> extensions too much in the area, where rfc9083 is very explicit
> about that it is intended to be allowed even with a mention that
> this method may be used to evolve rfc9083 itself.
Evolving RFC 9083 is different from evolving an extension. For RDAP
itself to be extensible, clients have to ignore unknown JSON members,
since new extensions can be registered and deployed at any time. The
same is not true of an extension. If anything, the presence of the
extension facility is a strong indication that a given extension is
stable/immutable once published.
> A given example of new object classes does not resonate to me as a
> problem, as they will appear under own path segments which won't be
> a problem for clients not knowing or using them.
I agree that the object class example does not appear to support the
case for preventing changes to existing extensions.
> Extensions draft may at most recommend usage of version signalling
> facilities, such as ietf-regext-rdap-versioning, but as long as it
> remains to be an extension and not an update to STD 95 we need to
> always consider clients which do not implement or understand it.
> Those clients must be able to work seamlessly (not break at least)
> also without signalling like ietf-regext-rdap-versioning.
>
> Therefore the extensions draft must mandate extensions authors to
> take care that clients do not break when adding non-braking changes
> (such as adding JSON fields) and recommend using common signalling
> facilities (such as ietf-regext-rdap-versioning) for minor version
> update signalling and/or negotiation.
>
> Last but not least, the extension itself may define its own
> versioning schema and signalling mechanism. Sometimes it may be
> derived from an existing specification (JSContact for example has
> own versioning schema). Finally, even an existence of a new field
> may be considered as signalling, that an aware client may use, so
> the text in current form is barely enforceable.
The basic problem with this, per the previous text, is that if an
extension does not itself document how it will change in the future,
then a client could legitimately infer that it is stable/immutable.
Otherwise, a statement like "compliant with RDAP extension
nro_rdap_profile_0" becomes time-dependent, without that possibility
being documented anywhere in the core RDAP RFCs or the extension
itself. There is also no obvious reason why extensions need to be
evolved in this way, as compared with defining a new extension, or
having the extension itself document how it might change.
Suggested updated text, replacing "Evolving Extensions without
Signaled Changes":
### Changes to Existing Extensions
Because RDAP clients ignore unrecognized JSON names and query
parameters, it is theoretically possible to make non-breaking
changes to an existing extension without causing direct adverse
effects to existing clients that implement that extension.
However, such changes MUST NOT be made, unless the extension
itself provides for that in some way (e.g. by way of a signaling
method like [@?I-D.ietf-regext-rdap-versioning]).
-Tom
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
