From: [email protected] <[email protected]>
Sent: Friday, June 13, 2025 6:03 AM
To: Hollenbeck, Scott <[email protected]>; [email protected];
[email protected]
Cc: Gould, James <[email protected]>; [email protected]
Subject: [EXTERNAL] Re: [regext] On bare identifiers in Extensions draft
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.
[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.
Scott
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
