Hi Pawel, Many thanks. Inline...
On 12/10/25 2:02 AM, Pawel Kowalik wrote: > 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. Just to be clear, are you suggesting evolving an extension without an evolution signal should be allowed? In other words, not MUST NOT and not NOT RECOMMENDED? My opinion (and just my opinion), we could do NOT RECOMMENDED by saying it should only be done in circumstances where there is not enough time to use other methods or where the impacted clients will be known to be updated. In other words, I am trying to find a scenario where this is the only reasonable approach. > > 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. The objectClassName property is how object classes are distinguished and how clients know how to parse them, at least for RFC 9083 objects, because it cannot be determined just by looking at the JSON because nearly all JSON members are optional. New object classes also can be embedded into existing objects, search results, and (most likely) linked to via referrals. Therefore, a client could encounter them even if it hasn't queried for them directly. > > 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. I agree. > > 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. Ok. So you are suggesting strong language in 5.4.4 about breaking changes as mentioned in 5.4.3? > > 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. That is a good point. We need to cover this. -andy _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
