Hi Tom, On 05.01.26 07:23, Tom Harrison wrote:
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.
[PK] The facility in RFC 9083 is there to assure not only extensibility but also base protocol evolution. I don't see any valid reason where the same rules should not apply to the extensions, especially
that RFC 9083 does not make any distinction in this area.
[PK] There is no promise of stable/immutable in the core protocol so why should it be more strict for extensions? Strictness of that kind is producing harder coupling between clients and serversA 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.
which in result leads harder life-cycles and client migrations. Just imagine adding one field to the extension output:A) new extension (with new ext. identifier) -> servers have to maintain both versions forever, or decomission and break clients. For RDAP it is super hard, as server don't know their clients. B) same extension (with same ext. identifier) -> server can smoothly just switch, clients are not affected, no migration. Signalling with versioning adds transparency.
[PK] such reference to be stable in time would have to refer to a version. I don't see why it would be a problem.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]).
I would however prefer a positive MUST, which semantically is the same.
My proposed text:
### Changes to Existing Extensions
Because RDAP clients ignore unrecognized JSON names and query
parameters, it is possible to make non-breaking changes to an existing
extension without causing direct adverse effects to existing clients
that implement that extension.
However, when such changes are made, the extension MUST describe
mechanisms for the clients to recognise and properly process
such a changed response (e.g. by way of a signaling
method like [@?I-D.ietf-regext-rdap-versioning]).
Kind Regards,
Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
