Hi Mario, Inline...
On 12/12/25 8:11 AM, Mario Loffredo wrote: > I agree that even non-breaking changes should generate either a new extension > (when opaque versioning is used) or a new version (when maturity versioning > is used) , simply because clients might lose information, not because they > might fail to parse the response. Object classes are different because they use a concept called internal tagging. Some parsers will throw an error on unknown internal tags. >> I think it is up to the extension author to determine the method that is >> right for them. > > [ML] In case of overlap, there should be only two options for servers: > duplicating the extension or providing a specific extension/version upon > request I disagree. The extension author should be able to make their own choice as it is not harmful to do backwards compatible overlaps. Duplicating everything with opague versioning means the clients must be upgraded even to take advantage of data that is the same in the previous version. If duplicating information in simple overlaps is to be forbidden, then why would it be acceptable in transitioning from jCard to JSContact which is a much, much more complicated scenario? -andy _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
