Hi Andy et al.,First thanks to the editors to incorporate clearly in the draft that there is no consensus yet on this point.
I see 3 issues with the current text that I would like to bring up. 1) Suggestive, one sided text in the alternativesI am not fully happy that the text in the options is very suggestive as to which option is "preferred", by including only the arguments of one side of the conversation.
I refer to this part which is repeated for all 3 options:"Implementation experience has shown that an extension using a bare identifier can be interoperable though more difficult to process and parse in some instances. Furthermore, bare identifier's blur the line between what can be interpreted as an extension to RDAP vs core RDAP mechanisms."
I would wish the text reflected also arguments preferring bare identifiers that were already expressed several times, including the recent interim meeting [1].
Here my short summary in my subjective list of importance:- Banning bare identifiers hinders the future evolution of the protocol, as it forces non-prefixed additions to go through the difficult process of updating a core RFC. - 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 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.
The fact that despite extensions not following the prefix recommendation the protocol works just fine and that there is no intention (or need) to rework those extensions proofs again that there is no technical (or social) issue of interoperability.
Finally, the harm of confusion expressed in rfc9083 2.1 is very limited in impact, as client is obliged to ignore unknown elements, and very easy to fix if IANA registry is a single point of truth.
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 extensions - Bare identifiers for "single identifier" extensions3) "technical solution cannot otherwise be defined" - almost impossible condition
This is a point I am sure I brought up already (just cannot find the reference anymore, sorry) that such condition is almost impossible to fulfil, as in any case an identifier with prefix will technically work.
[1] https://meetecho-player.ietf.org/playout/?session=IETF-REGEXT-20250508-1700
Kind regards, Pawel On 02.07.25 16:44, Andrew (andy) Newton wrote:
Hi all,This version of the draft lays out the 3 positions on bare identifiers that have been voiced on the mailing list. See section 2.3. Our plan is to have a discussion in Madrid on this and seek consensus on one of the 3 positions.-andy On 7/2/25 10:33, [email protected] wrote:Internet-Draft draft-ietf-regext-rdap-extensions-07.txt is now available. It is a work item of the Registration Protocols Extensions (REGEXT) WG of theIETF. Title: RDAP Extensions Authors: Andy Newton Jasdip Singh Tom Harrison Name: draft-ietf-regext-rdap-extensions-07.txt Pages: 26 Dates: 2025-07-02 Abstract: This document describes and clarifies the usage of extensions in RDAP. The IETF datatracker status page for this Internet-Draft is: https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-extensions/ There is also an HTML version available at:https://www.ietf.org/archive/id/draft-ietf-regext-rdap-extensions-07.htmlA diff from the previous version is available at:https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-extensions-07Internet-Drafts are also available by rsync at: rsync.ietf.org::internet-drafts _______________________________________________ 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]
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
