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.
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.
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? Kind Regards, Pawel
OpenPGP_0xABB62115F7BCDB04.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
