Hi Jasdip, See my other E-mail I sent yesterday.
What you mention is variant 1.Data is 100% duplicated between the "versions" (even if JSON-wise the payloads under foo0_x and foo1_x are back compatible).
After foo0_x is removed and only foo1_x payload remains, the clients only knowing foo0_x break - so the statement that it is safe to remove is false.
Kind Regards, Pawel On 21.10.25 21:49, Jasdip Singh wrote:
Hi,AFAIU, "foo0" should be used to prefix whatever it needs to -- JSON names, query parameters, object class names, etc. (say, "foo0_x"). When "foo1" (or "foo99" for that matter) comes along, it holistically prefixes all it needs to, including what "foo0" prefixed (say, "foo1_x") and any additional ones (say, "foo1_y"). That way both these opaque extension ids can be used by clients based on the "exts_list" negotiation, and when "foo0" is retired, it should be safe from backwards-compatibility angle.Jasdip *From: *Pawel Kowalik <[email protected]> *Date: *Monday, October 20, 2025 at 8:27 AM *To: *Andy Newton <[email protected]>, [email protected] <[email protected]>*Subject: *[regext] Re: RDAP Extensions - opaque versions, extension identifiers and rdap conformanceHi 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] To unsubscribe send an email [email protected]
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
