Hi Andy, On 15.10.25 21:25, Andy Newton wrote:
On 10/15/25 08:11, Pawel Kowalik wrote:Hi,Reviewing draft-ietf-regext-rdap-extensions-08 I stumbled upon section 5.3.1. Backwards-Compatible Changes.Backward compatible changes, as I understand them, are those which will use same JSON names as the previous version, with maybe added new fields which would be safely ignored by the old clients. If the keys are different, the change is like backwards-incompatible described in 5.3.2.So assuming we have an extension "foov0", it would define JSON names like "foov0_somekey".The extension identifier registration would be "foov0" and RDAP conformance entry would be also "foov0".Now, as new version comes out, it would have extension identifier registration for "foov1". The JSON name used will remain to be "foov0_somekey" to remain backward compatible.That's one scenario, but if "foov1" wants to use names specified in "foov0", then "foov0" will always be required whenever "foov1" is used. But that is not what 5.3.1 is talking about. The scenario for 5.3.1 is that "foov0" defines "foov0_somekey" and "foov1" defines "foov1_somekey". Both are in the response and clients use the one they are programmed to recognize.
OK, if the keys are distinct and always both in the output then it does not matter.
However is it a backward compatibility pattern that would we should be putting forward as default? It does not scale too well, if several versions would be considered. Either you will end up with having v0, v1, v2... all in the output, or if you drop some you are not back compatible.
I assumed back compatible means no matter which (future) version produces the response, older client can deal with it well.
For the transition period RDAP conformance would contain both "foov0" and "foov1".Now, after period of time one may want to remove "foov0". 5.3.1 indicates that scenario explicitly.Would that mean that from this point in time RDAP conformance would contain only "foov1" and JSON name will remain "foov0_somekey" ?Or in this case removal of the initial specification defining prefix "foov0" from the conformance won't be allowed? It is likely what 2.5.5 is stating, but in a bit indirect way as it focuses on clarification for profile extensions. Likely rephrasing of 2.5.5 would be needed as well as reference in 2.3.1 that rules of 2.5.5 must still apply when removing past version identifiers.Given my explanation above, I don't think so. But I don't know what 2.3.1 is. If you mean 5.3.1, I don't think 2.5.5 needs to change based on what I explained. However, we may need to enhance 5.3.1 to discuss the back-reference scenario you mention.
Yes, sorry for typo. 5.3.1 is what I was referring to. Yes, adding clarification to 5.3.1 is also a way to deal with this. Thanks for considering.
To avoid this dilemma maybe extensions draft shall promote or mention a pattern, where identifiers in the conformance would be less coupled to name prefixes by registering two extension identifiers, one with version and one without.Following the example above it would be "foov0" and "foo". JSON Name would be then "foo_somekey" and RDAP conformance "foov0". This pattern was btw used by extensions mentioned in Section 6.For "foov1" it would not make any difference if "foov0" is eventually removed from the conformance array or not.This approach would have a different problem though, that it would break the requirement of not colliding with existing identifiers (2.2 of extensions draft). "foov1" would collide with "foo" in an obvious way.Any thoughts?This is covered with simply back-referencing an earlier version. I don't think we need special mechanisms for it.
The question was referring to the collision/registration scenario. Should it be allowed that: version 0 registers foo and foov0 version 1 registers foov1If yes, collision rules defined in 2.2 need to be fine tuned to account for such versioning scenario, e.g. by saying that in case of versions of the same extensions collisions are allowed, or by disallowing collisions even on the level of the same extension - means that version 0 would not be allowed to register foov1 and foo and would need to register foov1 and bar instead. foov2 won't be in conflict with any of them in this case.
Kind Regards, Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
