Hi Jim, On 09.06.26 14:30, Gould, James wrote:
[PK] This is exactly what the client should not be forced to do. An extension identifier shall carry enough information to tell the client if it is able to parse the response. A breaking change shall make such clients aware of incompatible response they cannot or should not try to parse and this is where extension identifier is the right tool in the core protocol. Versioning or any other extension, if not in the core protocol, is not sufficient to deal with clients who do not know them.The client can easily leverage the extension of the help command to obtain the versioning information. Again, if the client is interested in versioning and breaking/non-breaking information then they can leverage the extension.
I don’t see how the extension identifier mitigates the breaking change impact, since the proposal is to change the extension identifier that will certainly break the client looking for the JSON members using the prior extension identifier prefix.[PK] Yes, if the change is breaking than it is breaking all the way down. Otherwise the extension authors shall keep the back compatibility and keep the extension identifier intact.
[PK] Sure it is, but still as extension cannot solve the problem for the clients who do not support it. It is unacceptable for the client to break on a response it considers valid based on extension identifier, just because of not knowing "versioning" extension which would by chance tell that the extension is incompatible. If this is the requirement, than we need to bake in versioning into the core protocol, with all the consequences.Additionally, changing the extension identifier will impact the query elements (path segment and query parameters). As Mario pointed out, changing the extension identifier causes maximum breakage, so it’s a very poor versioning signal for interoperability. The draft-ietf-regext-rdap-versioning extension supports the opaque versioning that can only use the extension identifier as a versioning signal, but I believe the point versioning type in draft-ietf-regext-rdap-versioning provides for a much better versioning signal.
[PK] You are again right, but this is the only tool we have in the core RDAP.The extension identifier is best suited as a namespace without attempting to embed versioning information, since it’s too coarse grained and doesn’t provide any standard versioning information.
Kind Regards, Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
