Hi Andy,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.
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.
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.
Kind Regards, Pawel On 04.12.25 21:25, Andy Newton wrote:
Hi all, As mentioned at IETF 124, this version updates section 5 based on the conversations at the IETF and on the mailing list prior.I would like to draw your attention to section 5.4. The author team believes evolving extensions in that manner should be forbidden, but that's more ofa proposal. If others have thoughts, please share. -andy On 04-12-2025 2:40 PM, [email protected] wrote:Internet-Draft draft-ietf-regext-rdap-extensions-09.txt is now available. It is a work item of the Registration Protocols Extensions (REGEXT) WG of theIETF. Title: RDAP Extensions Authors: Andy Newton Jasdip Singh Tom Harrison Name: draft-ietf-regext-rdap-extensions-09.txt Pages: 28 Dates: 2025-12-04 Abstract: This document describes and clarifies the usage of extensions in RDAP. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-extensions/ There is also an HTML version available at:https://www.ietf.org/archive/id/draft-ietf-regext-rdap-extensions-09.htmlA diff from the previous version is available at:https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-extensions-09Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
