At noted previously, I don’t see any issue with the use of “bare identifiers”, since the extension identifier used as a “bare identifier” is registered in the RDAP extensions registry with a referenced specification. The use of the “versioning” query parameter is unique based on the extension identifier registration and doesn’t provide any confusion for implementers. Adding the “versioning” prefix, such as “versioning_versioning” or “versioning_param” doesn’t add any value in my opinion. We are planning on changing the “versioning” JSON member to “versioning_data”, since there is more than one JSON member in the extension with inclusion of the “versioning_help” JSON member. If there is a single data element (query parameter, path segment, JSON member, media type parameter), the use of a bare identifier should be fine, while if there is more than one of the same type in the extension, then the inclusion of the prefix provides for grouping to the registered extension.
Shouldn’t the x-media draft register the “extensions” RDAP extension identifier and use an extension identifier prefix in place of the bare identifier for the “extensions” media type parameter, such as “extensions_extensions”, “extensions_param”? I believe the x-media draft should include an RDAP extension registration, but I don’t believe there is the need to change from the use of the bare identifier. -- JG [cid87442*[email protected]] James Gould Fellow Engineer [email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: "[email protected]" <[email protected]> Date: Friday, June 13, 2025 at 8:26 AM To: "Hollenbeck, Scott" <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]> Cc: James Gould <[email protected]>, "[email protected]" <[email protected]> Subject: [EXTERNAL] Re: [regext] On bare identifiers in Extensions draft Hi Scott, On 13.06.25 14:00, Hollenbeck, Scott wrote: 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. 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. Kind Regards, Pawel
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
