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 ?
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.
Anyway, looking at the response extensions that we have standardized so
far, I'm pretty confident that it wouldn't be used.
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?
[ML2] The transition from jCard to JSContact, as described in
rdap-jscontact, does not require both jCard and JSContact to be returned
in the response.
Only one format is returned, depending on the preference a client can
indicate via the exts_list parameter or the versioning query parameter.
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]
