Hi Scott, On 13.06.25 14:00, Hollenbeck, Scott wrote:
PK2> Sure there was any choice made? To a man with a hammer, everything looks like a nail. This way there was never a discussion about anything else than extensions and applying extension rules to it. Adding new optional element and parameter, like "versioning" is also back compatible, so rdapConformance would still look like [ "rdap_level_0", "versioninig"], or maybe ["rdap_level_0", "rdap_versioning"] if we insist that conformance strings for core elements shall distinguish from extensions.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.*/[SAH] I don’t think that definition is missing at all. The narrow interpretation is correct, and yes, it’s possible to add new capabilities to the core. Just add new specifications to STD 95, or update the existing specifications. Versioning, for example, could say something like “this specifications adds new stuff that’s included in "rdap_level_0". The WG can then do what’s necessary to add a versioning RFC to STD 95 after the requirements are met./*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).*/[SAH] Isn’t the versioning case a function of the choices made in writing that draft? It could very easily have been written differently. As I noted above, if the WG really thinks the versioning draft should be added to the protocol core, it can be. Stop thinking about it as an extension, start thinking about how to define it as core functionality, and the whole extension identifier problem goes away./*
Kind Regards, Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- regext@ietf.org To unsubscribe send an email to regext-le...@ietf.org
