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]
To unsubscribe send an email [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
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
