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.
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.
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. -andy _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
