Pawel, Your Approach 1 is the issue that the versioning draft with the Semantic Versioning is hoping to solve, where there is a given static extension prefix represented by the extension identifier (e.g., “foo” in your Approach 2 that is associated with “foov1” and “foov2”). The extension identifier that is in the rdapConformance and used as the JSON member prefix is unchanged with many versions of the extension. The versioning extension includes the versioning information, where server can support v1 and v2 at the same time with a default version. Please review the Semantic Versioning in draft-ietf-regext-rdap-versioning to see if it effectively handles your use case.
In reviewing section 5.3.1 and 5.3.2 in draft-ietf-regext-rdap-extensions, I don’t believe they belong in draft-ietf-regext-rdap-extensions and should be left to draft-ietf-regext-rdap-versioning. I would just leave the language in section 5.3, which states that “there is no explicit version despite the fact that extension identifiers include trailing numbers”. Thanks, -- JG [cid87442*[email protected]] James Gould Fellow Engineer [email protected]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com<http://verisigninc.com/> From: Pawel Kowalik <[email protected]> Date: Tuesday, October 21, 2025 at 3:57 AM To: Andy Newton <[email protected]>, "[email protected]" <[email protected]>, Mario Loffredo <[email protected]> Subject: [EXTERNAL] [regext] Re: RDAP Extensions - opaque versions, extension identifiers and rdap conformance Hi Mario, In fact I am not proposing anything, just trying to comprehend what is now in the draft, namely what backward compatibility mentioned in 5.3.1 means to identifiers that an extension ought to register. As versioning draft is an extension, not an update to the protocol, the mechanisms have to work also without this extension. So far the approach of versioning an extension is to have new opaque identifier which by RDAP current specification MUST appear in the rdapConformance array. This is how foov1 and foov2 will get registered in IANA and populated to rdapConformance. Then I was wondering how would it work for back compatibility. Approach 1: foov1 and foov2 add JSON names using only their prefixes. They obviously never collide, data is just duplicated, but is it back compatible? foov1-aware client won't be able to read foov2-only output. So this is not back compatible. Of course one can keep foov1 in the response, but then the whole back compatibility topic is moot. foov2 would be just an unrelated extension. 5.3.1 and 5.3.2 would be in fact the same in this case. Approach 2: foov1 and foov2 have a common prefix that remains stable over the versions. It can be foo, bar or foov1. This would be back compatible if foov2 response in this common prefix can be read by foov1-only aware client. If this ought to be a valid and allowed approach, than few other questions are to clarify: - if foov1 can register a self-colliding prefix foo? - if foov2 can populate JSON names registered by a different (but related) extension foov1? I slowly tend to think that the real problem is the dual use of RDAP Extensions IANA registry. From one side it needs to keep full extension identifiers (to identify specifications) as they appear in the rdapConformance array. On the other side it registers namespace prefixes, which inherently collide with the extension identifiers. Kind Regards, Pawel On 21.10.25 09:01, Mario Loffredo wrote: Hi Pawel, As I understand it, you're proposing to use some of the extension identifiers as version identifiers. Aside from the fact that the purpose of the rdapConformance array would be redesigned, mixing them in the rdapConformance array could be misleading and would require clients to make additional effort to distinguish between extensions and related versions used in response construction. The versioning draft doesn't change the purpose of the rdapConformance array and describes a mechanism for keeping extension identifiers separate from version identifiers. Best, Mario Il 20/10/2025 14:27, Pawel Kowalik ha scritto: Hi Andy, On 20.10.25 13:01, Andy Newton wrote: On 18-10-2025 12:55 PM, Pawel Kowalik wrote: On 17.10.25 16:00, Andy Newton wrote: On 10/16/25 02:27, Pawel Kowalik wrote: The question was referring to the collision/registration scenario. Should it be allowed that: version 0 registers foo and foov0 version 1 registers foov1 If yes, collision rules defined in 2.2 need to be fine tuned to account for such versioning scenario, e.g. by saying that in case of versions of the same extensions collisions are allowed, or by disallowing collisions even on the level of the same extension - means that version 0 would not be allowed to register foov1 and foo and would need to register foov1 and bar instead. foov2 won't be in conflict with any of them in this case. These are opaque identifiers. There is no inherent connection between them, therefore the normal collision rules apply. Does it relate to version 1 or also version 0 registration? So to put it straight, would version 0 registers both foo and foov0 be allowed, or collision rules also apply to the registrations of the same extension? Hi Pawel, Upon further reflection, I think I was misunderstanding your idea. If I understand correctly, your idea is to specify a "base" extension id and then use other extension ids that are markers for new versions of the base extension.... essentially, extension versioning but with opaque identifiers. The rules in 2.2 are meant to avoid collisions between unrelated extensions and I am not certain they would prevent what you are seeking, but I could see how they might need to explicitly allow it. I do think the rules for such an idea could get complicated, so I think we would need to work through them in some proposed text. Maybe we can discuss this at 124. Cool. Let's discuss at 124. Kind Regards, Pawel _______________________________________________ regext mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]> -- Dott. Mario Loffredo Senior Technologist Technological Unit “Digital Innovation” Institute of Informatics and Telematics (IIT) National Research Council (CNR) Address: Via G. Moruzzi 1, I-56124 PISA, Italy Phone: +39.0503153497 Web: http://www.iit.cnr.it/mario.loffredo<http://secure-web.cisco.com/1-xzDeLeUiUPRj0DaZ3pE0YTITrz0cN39EEx2_fH_P-ivA8ypQhsxvXXRvjdhYk45oCZs50_gWfda1W4--zFJ4-LGfK7888iEZhxWDrHUgBkcO1AwiM-dWHhv6wxVYZ0quiTWbW9tm-MP9YoSO0-AcRVw-4ya0ki0YXr1K98bEAhaLjtD6-Ja-CgeJkhlxrNcrPenh1ZqxAVSYoOVmbxVkUJFyZ49v7ucUMK7HR-O0KyOhJRagNRhXeVX7nfPlHhJ2ZsoffsH9v08KqZXezCpYk0xTCFkK9RT9YatprI5dGw/http%3A%2F%2Fwww.iit.cnr.it%2Fmario.loffredo> _______________________________________________ regext mailing list -- [email protected]<mailto:[email protected]> To unsubscribe send an email to [email protected]<mailto:[email protected]>
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
