Hi, On 03.06.25 14:42, Hollenbeck, Scott wrote:
having combinations of extension mechanism is not desired, but you can have bare identifier in url path and in json right?for example, url can be: /base/path/my-foo-extension/my-new-val is this not logically the same as this json example? { “standard-key1”: “val1”, “standard-key2”: “val2”, “my-foo-extension: { “my-new-key”: “my-new-val” , “more-key”: “more-val"} }[SAH] Sure, both bare identifiers and prefixed identifiers can be used from a syntax validity perspective.
PK> right
If I remember correctly, though, the idea behind consistent use of prefixed identifiers for extensions was to make extension identifiers visually and programmatically distinguishable from core protocol identifiers.
PK> the problem I see with the current approach is a missing definition of what is "core protocol" and what is not. In the narrow interpretation core can be seen as only what STD 95 contains. I argument, that healthy protocol evolution needs also a possibility to extend the functionality adding generic items which would be considered a "core protocol". Versioning is a perfect example of such extensions. If it goes through IETF WG process I see very little risk of not being able to distinguish between core extensions and specific use case extension.
If we were to adopt that practice consistently, it would be possible to unambiguously identify something like "foo_val", whether used in a URI or a JSON object, as an extension identifier. On the other hand, something like "fooval" can't be clearly identified as an extension identifier without additional context information.
PK> foo_val and fooval are not best examples to illustrate the problem. If I take draft-ietf-regext-rdap-versioning-02 as an example it includes "versioning" JSON member and "versioning" query parameter. "versioning" would be also the registered extension identifier, so very straightforward to locate the specification where the identifier is coming from. This is also an extension which I would consider a core protocol extension as the functionality is very generic and not likely that there will be 2 alternative versioning RFCs. Redefining the JSON member and query parameter to "versioning_versioning" brings very little value, especially that the extension draft clearly states that there is no intention to change or influence implementations of clients or servers, so existence of identifier prefix must not be used to steer processing paths (or may even lead to anti-patterns and bugs if someone does).
Kind Regards, Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
