Hi Andy,
Il 15/12/2025 13:55, Andy Newton ha scritto:
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.
[ML3] If they are embedded in other classes, they are essentially new
elements of those classes. Therefore, they should be parsed and then
ignored per section 2.1 of RFC9083.
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.
[ML3] All response extensions standardized so far leveraged JSON objects.
In contrast to this best practice, Section 5.4.2 seems to encourage
extension designers to scatter information across a set of simple
properties, related only by their common prefix.
I disagree with this approach, which apperas also inconsistent with
Section 2.5.2 and, in general, with object-oriented data modeling.
It's better to opt for an approach where servers can progressively
eliminate and deprecate a feature, and clients can opt for their
preferred version at any time.
Mario
-andy
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
