Hi Pawel, Excellent email. I think much of this was brought up in the meeting, but I want to respond to the parts that I do not believe were discussed. Let me know if I missed anything. My response is inline...
On 21-07-2025 11:04 AM, Pawel Kowalik wrote:
- If identifiers are registered with IANA, the risk of naming conflicts is eliminated, making prefixes for identification purposes redundant. - Mandatory prefixes make the protocol less readable and can lead to awkwardly long or abbreviated identifiers, degrading the protocol's quality. - Other protocols, like JWT and JSContact, use a registry for bare identifiers without prefixes and function well.
I don't think JWT and JSContact are equivalent comparisons. RDAP extensions can do a lot more, and in cases where the more than one identifier of a type (e.g. more than one JSON name) prefixing is required so as one identifier does not have two separate meanings. Otherwise an RDAP extension would need a separate extension ID for every top-level name specified.
I would also want to respond to the "implementation experience" argument being brought up. This is a well known bias that you only hear back from people who may have experienced this problem. Likely a handful of them. Usually you won't hear it from people who didn't face this problem. The fact, that we have extensions not following the prefix recommendation when adding generic functionality is a proof, that it's very common for developers in REST environment to choose natural identifiers without a hidden non-common structuring element. This is even more true for LLMs and we cannot neglect the fact that they are and will be used heavily in software development so it should be relevant in our considerations. The fact that underscore is a prefix separator, which is very commonly used in the snake case notation does not help either. Trying to circumvent that in the current draft with enforcing camel case imposes yet another unnatural limitation. If we get rid of prefixes we could also drop this limitation.
Providing many examples is not only good for human coders but also LLM training. And I am far from an expert, but it should be possible to point an AI to an example and prompt it to output code.
2) Other alternatives missing As a next issue, I see that the draft is lacking alternatives, which was also in the discussion: - Bare identifiers for RFCs, prefix for private extensions
We did have the "two classes" of extensions, but there were opinions against it and removing the two classes simplifies the rules.
- Bare identifiers for "single identifier" extensions
I don't understand. That is in the draft as the position to allow bare identifiers: "... therefore this document updates [RFC9083] to explicitly allow this pattern when an extension defines only one namespaced identifier of a type (e.g. only one JSON name, only one query parameter, etc...)." -andy _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
