Hi Andrew, On 24.07.25 18:07, Andy Newton wrote:
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 like to use JWT as example, because it is highly used, very successful, and also the claim list is very often extended in both coordinated and uncoordinated way. This is also a security token, so I think the impact of things going wrong would be much higher compared to what RDAP is doing.
The registry has 128 entries, many of them coming from same specifications. Few of them used some distinct naming convention (namely 2 groups: sip and rdap), majority didn't. RDAP extension identifier also contains multiple (bare) registrations for RFC8977. 5 (also bare) will come from "to become RFC soon" RIR search.
JSContact was mentioned as an example we are familiar with. There are countless other examples, taking DNS as a very first and long lasting one. RRs can be added by specifications other that RFC 1035 and are not told to prefix RR names not to mix them up with 1035.
PK> show of hands in interim were 50/50 and to be clear I was against. But still this was an option with a very clean unambiguous cut, if clarity is a criteriaI 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 missingAs a next issue, I see that the draft is lacking alternatives, which was also in the discussion:- Bare identifiers for RFCs, prefix for private extensionsWe 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" extensionsI 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...)."
OK, I was misled by the title "BARE EXTENSIONS ALWAYS ALLOWED" which for me means "ALWAYS", no exceptions. So this is yet another option that should have been put on table. Just register all what you are using. Exactly like RIR search did. The rules are dead simple, no interpretation needed, fully in line with mentioned IETF RFCs on protocol design: RFC 1958, RFC 5218 & RFC 9413. One added advantage, that past extensions will remain compliant and no exception have to be considered on this end.
The option "allowed if only one" is nice but after current discussion I don't think this is a correct line. Either allow always or never - nothing in between.
Kind Regards, Pawel
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
