Hi Mario, On 12/15/25 3:32 AM, Mario Loffredo wrote: > Hi Andy, > > again my comments inline. > > Il 12/12/2025 15:16, Andy Newton ha scritto: >> 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. > > [ML2] Sorry but I don't understand. > > New object classes can be obtained in response to corresponding queries. > How can a client that sends a query like rpki1_roa/... not expect > the rpki1_roa object class in response ?
Object classes can also be embedded in other object classes (entities are the classic case), clients can dereference them via a referral, and they can appear in search results. Substituting "blockchain_domain" where the client expects "domain" may cause problems. >>>> 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. > [ML2] This is a well-known disadvantage of opaque versioning. > Furthermore, clients still need to be upgraded to consider > non-overlapping elements. > > Therefore, on the one hand, they can analyze non-overlapping > elements only when they are upgraded. On the other hand, once they are > upgraded, I dont' see the benefit of seeking information split across > multiple extensions. > > It seems to me a very complicated solution for both clients and servers > to address the concern of reducing the response size. There is also the motivation of backwards compatibility. -andy _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
