Hi, As I gather from this thread, we all seem to agree that a bare identifier could co-exist with a prefix identifier for an extension as a namespace-collision prevention approach in RDAP. Albeit, for a qualified scenario when only a single JSON member, query path, query parameter and/or object class is to be named so.
In my mind, the bigger question is if a bare identifier is genuinely needed or not? Yes, from human-friendliness angle, a name using a prefix identifier is “uglier” to look at than a name using a bare identifier. But, since RDAP is meant more for programmatic purposes, the software could care less for a bare identifier’s “beauty”. Much more importantly, I think the WG decision should come down to simplicity versus complexity. RFC 5218 (What Makes for a Successful Protocol?) espouses a good technical design to be simpler [1], and further points to RFC 1958 (Architectural Principles of the Internet) which says [2], “If there are several ways of doing the same thing, choose one.” More recently, RFC 9413 (Maintaining Robust Protocols) cautioning against protocol decay says [3], “Divergent implementations of a specification emerge over time. When variations occur in the interpretation or expression of semantic components, implementations cease to be perfectly interoperable.” My point being: bare identifiers would unnecessarily increase complexity for RDAP. If this is still not convincing enough, IMHO, we could have a reasonable compromise -- allowing a bare identifier under limited conditions (mentioned above) with a “you SHOULD NOT use a bare identifier unless you can truly justify why it is needed when an uglier prefix identifier could most likely do the namespace-collision prevention job.” Thanks, Jasdip [1] https://datatracker.ietf.org/doc/html/rfc5218#autoid-15 [2] https://datatracker.ietf.org/doc/html/rfc1958#page-4 [3] https://datatracker.ietf.org/doc/html/rfc9413#name-protocol-decay From: Hollenbeck, Scott <[email protected]> Date: Tuesday, June 3, 2025 at 8:42 AM To: [email protected] <[email protected]>, [email protected] <[email protected]> Cc: Gould, James <[email protected]>, [email protected] <[email protected]> Subject: [regext] Re: On bare identifiers in Extensions draft > -----Original Message----- > From: Maarten Wullink <[email protected]> > Sent: Tuesday, June 3, 2025 2:12 AM > To: Andrew (andy) Newton <[email protected]> > Cc: Pawel Kowalik <[email protected]>; Hollenbeck, Scott > <[email protected]>; Gould, James <[email protected]>; > [email protected] > Subject: [EXTERNAL] Re: [regext] On bare identifiers in Extensions draft > > Caution: This email originated from outside the organization. Do not click > links > or open attachments unless you recognize the sender and know the content is > safe. > > > >>> > >> I mentioned it as it was referred to in -04 4.5. But you are right, paths, > >> query > parameters and object class names have the same properties. > >> If there is a single item added by the extension, and it's equal to > >> extension > identifier - it's all same. > >> For class names and query parameters if an extension would want to add > several there is no other choice than prefix, as the same name cannot be > duplicated. > >> For JSON names and paths one may do a container with one name and > include all needed values in there, or have a flat list with prefixes. It > would be > "foo_val1": "..." vs. "foo":{ "val1": "..." } for JSON, or foo_subpath1 vs > foo/subpath1 for paths. > > > > This and the various combinations of an extension using the bare id in a > > path > but not JSON, etc... adds unneeded complexity. That's why bare ids are not a > good idea. > > > > > 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. 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. 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. Scott _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
