Jasdip, This is very impressive work, Jasdip. I've been trying to follow this conversation, and this doc is very helpful.
I note that in the analysis there are references to "put the new extension value in the help" (or something). What does this mean? First, /help is a query unto itself. Second, putting additional information in a "notice" without proper guidance of what to actually do may be kicking the ambiguity-can down the road. Is it part of the title for the notice? Is there a textual description, and if so how does that work with I18N issues? Does it go into a relative link structure? The aspect analysis section is interesting as it helps us to evaluate the trade-offs. In my opinion, interoperability is paramount otherwise we'll just be repeating this conversation again in a year. I view on-the-wire efficiency as the least-compelling objective for this protocol. And cost to clients should be given higher consideration than cost to servers given there are many more clients than servers. I believe this puts me in camp A even if it means we sacrifice some of the on-the-wire aesthetic. -andy On Mon, Jun 6, 2022 at 10:05 PM Jasdip Singh <jasd...@arin.net> wrote: > > Hi. > > > > Please find below the revised analysis of the current approach (A) and the 2 > newly proposed approaches (B and C) for RDAP extensions [1]. Hopefully, the > considered change scenarios are now granular enough ( @Mario :) ). > > > > My high-level observations: > > Approach C is much better than Approach B. > That said, would still go with Approach A since it consistently prevents > naming collisions for all change scenarios and affords sufficient transition > time for clients to “upgrade” to the next iteration of an extension. The > latter -- graceful upgrade -- could be quite important to most, if not all, > customers of the RDAP service at an RIR or a DNR, to the point of being an > operational requirement. The former – consistently preventing naming > collisions – helps keep the model simple, albeit at the expense of > occasionally sending more data in responses. > Approach C is closer to Approach A than to Approach B but requires a careful > scenario-by-scenario analysis to determine the need for a new prefix(es), and > that could be problematic at times. I think it’d come down to (sunk) cost > versus benefit when choosing between sticking with Approach A or moving to > Approach C. > > > > Please feel free to rectify this analysis. :) Hopefully, the discussion could > converge for the considered change scenarios. > > > > Thanks, > > Jasdip > > > > [1] > https://docs.google.com/document/d/1e3QD8z01KpYRd5LwdLBWjHHDoFVAVEL8u7Y52zsDdx0/edit?usp=sharing > > > > --- > > > > RDAP Extensions Analysis v2 > > > > Approaches > > Change Scenario Analysis > > Aspect Analysis > > Approaches > > > > Approach A: Tight coupling between extension identifier and rdapConformance > > > > Extension identifier = <opaque identifier> > > No version semantics > > Registered in the IANA RDAP Extensions registry > > A new spec provided for each new iteration of the extension > > rdapConformance = <extension identifier> > > > > Extension identifier used to prefix data member names, and in URIs (path > segment, segment parameter, and/or query parameters) > > > > Note: The phrase “new iteration” here simply connotes a new opaque identifier > for an extension when it evolves. > > > > Approach B: Lack of tight coupling between extension identifier and > rdapConformance > > > > Extension identifier = <prefix> > > Registered in the IANA RDAP Extensions registry > > rdapConformance = <prefix>[<version (suffix)>] [ ] means optional > > Needs version (suffix) semantics > > Registered in the IANA RDAP Extensions registry (or perhaps another > registry for rdapConformance) > > A new spec provided for each new version of rdapConformance > > > > Extension identifier used to prefix data member names, and in URIs (path > segment, segment parameter, and/or query parameters) > > > > Approach C: Decouple extension identifier from prefix(es) used for naming > > > > Extension identifier = <opaque identifier> > > Registered in the IANA RDAP Extensions registry > > A new spec provided for each new iteration of the extension; lists > prefix(es) used for naming > > Version semantics not needed for listed prefix(es) > > rdapConformance = <extension identifier> > > > > Listed prefix(es) used to prefix data member names, and in URIs (path > segment, segment parameter, and/or query parameters) > > Change Scenario Analysis > > Legend: > > ei - extension identifier > > rc - rdapConformance value > > p - prefix > > u - URI > > q - query parameter > > s - segment > > sp - segment parameter > > d - data member > > > > # > > Change Scenario > > Approach A - Tight coupling between extension identifier and rdapConformance > > Approach B - Lack of tight coupling between extension identifier and > rdapConformance > > Approach C - Decouple extension identifier from prefix(es) used for naming > > 1 > > Add a URI path (no parameters yet) > > ei = ext0 (registered) > > rc = ext0 > > p = ext0 (new) > > > > u0 = …/ext0/… > > ei = ext (registered) > > rc = ext0 (registered) > > p = ext (new) > > > > u0 = …/ext/… > > ei = ext0 (registered) > > rc = ext0 > > p = p0 (new) > > > > u0 = …/p0/… > > 2 > > Add a path segment (s1) > > ei = ext1 (registered) > > rc = ext1 > > p = ext1 (new) > > > > u1 = …/ext1/s1/… > > > > Old URI u0 continues to exist during transition > > ei = ext > > rc = ext1 (registered) > > p = ext > > > > u1 = …/ext/s1/… > > > > Clients still on rc ext0 when calling u0 break > > ei = ext1 (registered) > > rc = ext1 > > p = p1 (new) > > > > u1 = …/p1/s1/… > > > > Old URI u0 continues to exist during transition > > 3 > > Add a segment parameter (sp2) > > ei = ext2 (registered) > > rc = ext2 > > p = ext2 (new) > > > > u2 = …/ext2/s1;sp2=.../… > > ei = ext > > rc = ext2 (registered) > > p = ext > > > > u2 = …/ext/s1;sp2=.../… > > ei = ext2 (registered) > > rc = ext2 > > p = p1 > > > > u2 = …/p1/s1;sp2=.../… > > 4 > > Rename a segment parameter (sp2 -> sp3) > > ei = ext3 (registered) > > rc = ext3 > > p = ext3 (new) > > > > u3 = …/ext3/s1;sp3=.../… > > > > Old URI u2 continues to exist during transition > > ei = ext > > rc = ext3 (registered) > > p = ext > > > > u3 = …/ext/s1;sp3=.../… > > > > Clients still on rc ext2 when calling u2 break > > ei = ext3 (registered) > > rc = ext3 > > p = p3 (new) > > > > u3 = …/p3/s1;sp3=.../… > > > > Old URI u2 continues to exist during transition > > 5 > > Remove a path segment (s1) > > ei = ext4 (registered) > > rc = ext4 > > p = ext4 (new) > > > > u4 = …/ext4/… > > > > Old URI u3 continues to exist during transition > > ei = ext > > rc = ext4 (registered) > > p = ext > > > > u4 = …/ext/… > > > > Clients still on rc ext3 when calling u3 break > > ei = ext4 (registered) > > rc = ext4 > > p = p4 (new) > > > > u4 = …/p4/… > > > > Old URI u3 continues to exist during transition > > 6 > > Add a required query parameter (q5) > > ei = ext5 (registered) > > rc = ext5 > > p = ext5 (new) > > > > u5 = …/ext5/…?q5=... > > > > Old URI u4 continues to exist during transition > > ei = ext > > rc = ext5 (registered) > > p = ext > > > > u5 = …/ext/…?q5=... > > > > Clients still on rc ext4 when calling u4 break > > ei = ext5 (registered) > > rc = ext5 > > p = p5 (new) > > > > u5 = …/p5/…?q5=... > > > > Old URI u4 continues to exist during transition > > 7 > > Add an optional query parameter (q6) > > ei = ext6 (registered) > > rc = ext6 > > p = ext6 (new) > > > > u6 = …/ext6/…?q5=...&q6=... > > > > Old URI u5 continues to exist during transition > > ei = ext > > rc = ext6 (registered) > > p = ext > > > > u6 = …/ext/…?q5=...&q6=... > > > > Clients still on rc ext5 when calling u5 do not break > > ei = ext6 (registered) > > rc = ext6 > > p = p5 > > > > u6 = …/p5/…?q5=...&q6=... > > > > Clients still on rc ext5 when calling u5 do not break > > 8 > > Rename a required query parameter (q5 -> q7) > > ei = ext7 (registered) > > rc = ext7 > > p = ext7 (new) > > > > u7 = …/ext7/…?q7=...&q6=... > > > > Old URI u6 continues to exist during transition > > ei = ext > > rc = ext7 (registered) > > p = ext > > > > u7 = …/ext/…?q7=...&q6=... > > > > Clients still on rc ext6 when calling u6 break > > ei = ext7 (registered) > > rc = ext7 > > p = p7 (new) > > > > u7 = …/p7/…?q7=...&q6=... > > > > Old URI u6 continues to exist during transition > > 9 > > Rename an optional query parameter (q6 -> q8) > > ei = ext8 (registered) > > rc = ext8 > > p = ext8 (new) > > > > u8 = …/ext8/…?q7=...&q8=... > > > > Old URI u7 continues to exist during transition > > ei = ext > > rc = ext8 (registered) > > p = ext > > > > u8 = …/ext/…?q7=...&q8=... > > > > Clients still on rc ext7 when calling u7 break > > ei = ext8 (registered) > > rc = ext8 > > p = p8 (new) > > > > u8 = …/p8/…?q7=...&q8=... > > > > Old URI u7 continues to exist during transition > > 10 > > Add a new data member (object class, array, number, string, and/or literal) > (d object) for a new response > > ei = ext9 (registered) > > rc = ext9 > > p = ext9 (new) > > > > u9 = …/ext9/…?q7=...&q8=... > > > > Old URI u8 continues to exist during transition > > > > u9_d = …/ext9_d/… > > > > { > > “rdapConformance” : [ > > …, > > “ext9” > > ], > > “ext9_d” : { > > “d0” : “a” > > } > > } > > ei = ext > > rc = ext9 (registered) > > p = ext > > > > u8 = …/ext/…?q7=...&q8=... > > > > u9_d = …/ext_d/… > > > > { > > “rdapConformance” : [ > > …, > > “ext9” > > ], > > “ext_d” : { > > “d0” : “a” > > } > > } > > ei = ext9 (registered) > > rc = ext9 > > p = p8 > > > > u8 = …/p8/…?q7=...&q8=... > > > > u9_d = …/p8_d/… > > > > { > > “rdapConformance” : [ > > …, > > “ext9” > > ], > > “p8_d” : { > > “d0” : “a” > > } > > } > > 11 > > Add a required data member (d1) to an existing response > > ei = ext10 (registered) > > rc = ext10 > > p = ext10 (new) > > > > u10 = …/… > > > > { > > “rdapConformance” : [ > > …, > > “ext10” > > ], > > …, > > “ext10_d1” : 8 > > } > > ei = ext > > rc = ext10 (registered) > > p = ext > > > > u10 = …/… > > > > { > > “rdapConformance” : [ > > …, > > “ext10” > > ], > > …, > > “ext_d1” : 8 > > } > > ei = ext10 (registered) > > rc = ext10 > > p = p10 (new) > > > > u10 = …/… > > > > { > > “rdapConformance” : [ > > …, > > “ext10” > > ], > > …, > > “p10_d1” : 8 > > } > > 12 > > Add an optional data member (d2) to an existing response > > ei = ext11 (registered) > > rc = ext11 > > p = ext11 (new) > > > > u10 = …/… > > > > { > > “rdapConformance” : [ > > …, > > “ext10”, > > “ext11” > > ], > > …, > > “ext10_d1” : 8, > > “ext11_d1” : 8, > > “ext11_d2” : “abc” > > } > > > > Clients still on rc ext10 when calling u10 do not break, at the expense of > sending duplicate data for ext10 > > ei = ext > > rc = ext11 (registered) > > p = ext > > > > u10 = …/… > > > > { > > “rdapConformance” : [ > > …, > > “ext11” > > ], > > …, > > “ext_d1” : 8, > > “ext_d2” : “abc” > > } > > > > Clients still on rc ext10 when calling u10 do not break > > ei = ext11 (registered) > > rc = ext11 > > p = p10 > > > > u10 = …/… > > > > { > > “rdapConformance” : [ > > …, > > “ext11” > > ], > > …, > > “p10_d1” : 8, > > “p10_d2” : “abc” > > } > > > > Clients still on rc ext10 when calling u10 do not break > > 13 > > Rename a required data member (d1 -> d3) > > ei = ext12 (registered) > > rc = ext12 > > p = ext12 (new) > > > > u10 = …/… > > > > { > > “rdapConformance” : [ > > …, > > “ext11”, > > “ext12” > > ], > > …, > > “ext11_d1” : 8, > > “ext11_d2” : “abc”, > > “ext12_d3” : 8, > > “ext12_d2” : “abc” > > } > > > > Clients still on rc ext11 when calling u10 do not break, at the expense of > sending duplicate data for ext11 > > ei = ext > > rc = ext12 (registered) > > p = ext > > > > u10 = …/… > > > > { > > “rdapConformance” : [ > > …, > > “ext12” > > ], > > …, > > “ext_d3” : 8, > > “ext_d2” : “abc” > > } > > > > Clients still on rc ext11 when calling u10 break > > ei = ext12 (registered) > > rc = ext12 > > p = p12 (new) > > > > u10 = …/… > > > > { > > “rdapConformance” : [ > > …, > > “ext11”, > > “ext12” > > ], > > …, > > “p10_d1” : 8, > > “p10_d2” : “abc”, > > “p12_d3” : 8, > > “p12_d2” : “abc” > > } > > > > Clients still on rc ext11 when calling u10 do not break, at the expense of > sending duplicate data for ext11 > > 14 > > Modify a required data member’s type (d3 number -> string) > > ei = ext13 (registered) > > rc = ext13 > > p = ext13 (new) > > > > u10 = …/… > > > > { > > “rdapConformance” : [ > > …, > > “ext12”, > > “ext13” > > ], > > …, > > “ext12_d3” : 8, > > “ext12_d2” : “abc”, > > “ext13_d3” : “def”, > > “ext13_d2” : “abc” > > } > > > > Clients still on rc ext12 when calling u10 do not break, at the expense of > sending duplicate data for ext12 > > ei = ext > > rc = ext13 (registered) > > p = ext > > > > u10 = …/… > > > > { > > “rdapConformance” : [ > > …, > > “ext13” > > ], > > …, > > “ext_d3” : “def”, > > “ext_d2” : “abc” > > } > > > > Clients still on rc ext12 when calling u10 break > > ei = ext13 (registered) > > rc = ext13 > > p = p13 (new) > > > > u10 = …/… > > > > { > > “rdapConformance” : [ > > …, > > “ext12”, > > “ext13” > > ], > > …, > > “p12_d3” : 8, > > “p12_d2” : “abc”, > > “p13_d3” : “def”, > > “p13_d2” : “abc” > > } > > > > Clients still on rc ext12 when calling u10 do not break, at the expense of > sending duplicate data for ext12 > > 15 > > Rename an optional data member (d2 -> d4) > > ei = ext14 (registered) > > rc = ext14 > > p = ext14 (new) > > > > u10 = …/… > > > > { > > “rdapConformance” : [ > > …, > > “ext13”, > > “ext14” > > ], > > …, > > “ext13_d3” : “def”, > > “ext13_d2” : “abc”, > > “ext14_d3” : “def”, > > “ext14_d4” : “abc” > > } > > > > Clients still on rc ext13 when calling u10 do not break, at the expense of > sending duplicate data for ext13 > > ei = ext > > rc = ext14 (registered) > > p = ext > > > > u10 = …/… > > > > { > > “rdapConformance” : [ > > …, > > “ext14” > > ], > > …, > > “ext_d3” : “def”, > > “ext_d4” : “abc” > > } > > > > Clients still on rc ext13 when calling u10 break if they were processing the > optional data member > > ei = ext14 (registered) > > rc = ext14 > > p = p14 (new) > > > > u10 = …/… > > > > { > > “rdapConformance” : [ > > …, > > “ext13”, > > “ext14” > > ], > > …, > > “p13_d3” : “def”, > > “p13_d2” : “abc”, > > “p14_d3” : “def”, > > “p14_d4” : “abc” > > } > > > > Clients still on rc ext13 when calling u10 do not break, at the expense of > sending duplicate data for ext13 > > 16 > > Modify an optional data member’s type (d4 string -> number) > > ei = ext15 (registered) > > rc = ext15 > > p = ext15 (new) > > > > u10 = …/… > > > > { > > “rdapConformance” : [ > > …, > > “ext14”, > > “ext15” > > ], > > …, > > “ext14_d3” : “def”, > > “ext14_d4” : “abc”, > > “ext15_d3” : “def”, > > “ext15_d4” : 16 > > } > > > > Clients still on rc ext14 when calling u10 do not break, at the expense of > sending duplicate data for ext14 > > ei = ext > > rc = ext15 (registered) > > p = ext > > > > u10 = …/… > > > > { > > “rdapConformance” : [ > > …, > > “ext15” > > ], > > …, > > “ext_d3” : “def”, > > “ext_d4” : 16 > > } > > > > Clients still on rc ext14 when calling u10 break if they were processing the > optional data member > > ei = ext15 (registered) > > rc = ext15 > > p = p15 (new) > > > > u10 = …/… > > > > { > > “rdapConformance” : [ > > …, > > “ext14”, > > “ext15” > > ], > > …, > > “p14_d3” : “def”, > > “p14_d4” : “abc”, > > “p15_d3” : “def”, > > “p15_d4” : 16 > > } > > > > Clients still on rc ext14 when calling u10 do not break, at the expense of > sending duplicate data for ext14 > > 17 > > Remove a required data member (d3) > > ei = ext16 (registered) > > rc = ext16 > > p = ext16 (new) > > > > u10 = …/… > > > > { > > “rdapConformance” : [ > > …, > > “ext15”, > > “ext16” > > ], > > …, > > “ext15_d3” : “def”, > > “ext15_d4” : 16, > > “ext16_d4” : 16, > > } > > > > Clients still on rc ext15 when calling u10 do not break, at the expense of > sending duplicate data for ext15 > > ei = ext > > rc = ext16 (registered) > > p = ext > > > > u10 = …/… > > > > { > > “rdapConformance” : [ > > …, > > “ext16” > > ], > > …, > > “ext_d4” : 16 > > } > > > > Clients still on rc ext15 when calling u10 break > > ei = ext16 (registered) > > rc = ext16 > > p = p16 (new) > > > > u10 = …/… > > > > { > > “rdapConformance” : [ > > …, > > “ext15”, > > “ext16” > > ], > > …, > > “p15_d3” : “def”, > > “p15_d4” : 16, > > “p16_d4” : 16, > > } > > > > Clients still on rc ext15 when calling u10 do not break, at the expense of > sending duplicate data for ext15 > > 18 > > Remove an optional data member (d4) > > ei = ext17 (registered) > > rc = ext17 > > p = ext16 > > > > u10 = …/… > > > > { > > “rdapConformance” : [ > > …, > > “ext16”, > > “ext17” > > ], > > …, > > “ext16_d4” : 16 > > } > > > > Clients still on rc ext16 when calling u10 do not break, at the expense of > sending data for ext16 > > > > Note: This would be the case when phasing out jcard > > ei = ext > > rc = ext17 (registered) > > p = ext > > > > u10 = …/… > > > > { > > “rdapConformance” : [ > > …, > > “ext17” > > ], > > … > > } > > > > Clients still on rc ext16 when calling u10 break if they were processing the > optional data member > > ei = ext17 (registered) > > rc = ext17 > > p = p16 > > > > u10 = …/… > > > > { > > “rdapConformance” : [ > > …, > > “ext16”, > > “ext17” > > ], > > …, > > “p16_d4” : 16 > > } > > > > Clients still on rc ext16 when calling u10 do not break, at the expense of > sending data for ext16 > > 19 > > Remove a required query parameter (q7) > > ei = ext18 (registered) > > rc = ext18 > > p = ext18 (new) > > > > u18 = …/ext18/…?q8=... > > > > Old URI u9 continues to exist during transition > > ei = ext > > rc = ext18 (registered) > > p = ext > > > > u18 = …/ext/…?q8=... > > > > Clients still on rc ext9 when calling u8 break > > ei = ext18 (registered) > > rc = ext18 > > p = p18 (new) > > > > u18 = …/p18/…?q8=... > > > > Old URI u8 continues to exist during transition > > 20 > > Remove an optional query parameter (q8) > > ei = ext19 (registered) > > rc = ext19 > > p = ext19 (new) > > > > u19 = …/ext19/… > > > > Old URI u18 continues to exist during transition > > ei = ext > > rc = ext19 (registered) > > p = ext > > > > u19 = …/ext/… > > > > Clients still on rc ext18 when calling u18 break > > ei = ext19 (registered) > > rc = ext19 > > p = p19 (new) > > > > u19 = …/p19/… > > > > Old URI u18 continues to exist during transition > > 21 > > Remove a URI path (u19) > > ei = ext20 (registered) > > rc = ext20 > > p = ext19 > > > > u19 = …/ext19/… > > > > Old URI u19 continues to exist during transition, and not beyond > > ei = ext > > rc = ext20 (registered) > > p = ext > > > > u19 = …/ext/… > > > > Old URI u19 continues to exist during transition, and not beyond > > ei = ext20 (registered) > > rc = ext20 > > p = p19 > > > > u19 = …/p19/… > > > > Old URI u19 continues to exist during transition, and not beyond > > 22 > > Add a query parameter (q9) to an existing, non-extension URI > > ei = ext21 (registered) > > rc = ext21 > > p = ext21 (new) > > > > u21 = …?ext21_q9=... > > > > { > > “rdapConformance” : [ > > …, > > “ext21” > > ], > > … > > } > > ei = ext > > rc = ext21 (registered) > > p = ext > > > > u21 = …?ext_q9=... > > > > { > > “rdapConformance” : [ > > …, > > “ext21” > > ], > > … > > } > > ei = ext21 (registered) > > rc = ext21 > > p = p21 (new) > > > > u21 = …?p21_q9=... > > > > { > > “rdapConformance” : [ > > …, > > “ext21” > > ], > > … > > } > > 23 > > Remove a query parameter (q9) from an existing, non-extension URI, as well as > add a query parameter (q10) to it > > ei = ext22 (registered) > > rc = ext22 > > p = ext22 (new) > > > > u22 = …?ext21_q9=...&ext22_q10=... > > > > { > > “rdapConformance” : [ > > …, > > “ext21”, > > “ext22” > > ], > > … > > } > > > > Clients still on rc ext21 when calling u22 do not break > > ei = ext > > rc = ext22 (registered) > > p = ext > > > > u22 = …?ext_q10=... > > > > { > > “rdapConformance” : [ > > …, > > “ext22” > > ], > > … > > } > > > > Clients still on rc ext21 when calling u22 break > > ei = ext22 (registered) > > rc = ext22 > > p = p22 (new) > > > > u22 = …?p21_q9=...&p22_q10=... > > > > { > > “rdapConformance” : [ > > …, > > “ext21”, > > “ext22” > > ], > > … > > } > > > > Clients still on rc ext21 when calling u22 do not break > > > > Aspect Analysis > > > > # > > Aspect > > Approach A - Tight coupling between extension identifier and rdapConformance > > Approach B - Lack of tight coupling between extension identifier and > rdapConformance > > Approach C - Decouple extension identifier from prefix(es) used for naming > > 1 > > Providing a new spec to IANA for a new iteration of an extension > > Registry stays as-is > > > > Few non-compliant registrations need to be remedied > > Registry needs to evolve for: > > > > Versioned rdapConformance > > > > Tying spec to versioned rdapConformance > > Registry stays as-is > > > > Prefix(es) listed in the spec > > 2 > > Risk of breaking changes for RDAP clients > > Minimal since it would always be a controlled upgrade to the next iteration > of an extension with sufficient transition time > > Most risky out of all the approaches since there is no controlled way to > upgrade for quite a few change scenarios > > Risk is minimal, like for approach A > > > > However, requires carefully identifying the need for a new prefix on > scenario-by-scenario basis; otherwise inadvertent mistakes possible > > 3 > > Cost of reprogramming clients for the next iteration of an extension > > There is cost but not as high as it seems — replacing extension identifier in > multiple places, and accounting for primarily query parameter and data member > changes > > > > Longer grace period for clients to reprogram if the server supports multiple > iterations of an extension during transition > > Reprogramming could become exigent for clients if the server switches to the > new iteration without supporting the previous iteration > > Cost slightly lower than that for Approach A — replacing prefixes for a > majority (but not all) of scenarios > > 4 > > Cost of reprogramming servers for the next iteration of an extension > > Highest cost — to simultaneously support multiple iterations during > transition period, replicating code from the previous iteration and replacing > extension identifier in multiple places, and accounting for primarily query > parameter and data member changes > > > > Eventually retiring code for the previous iteration > > Lowest cost since only the latest iteration is supported > > Cost is lower than for that for Approach A but not too low — for a majority > (but not all) of scenarios, to simultaneously support multiple iterations > during transition period, replicating code from the previous iteration and > replacing prefixes in multiple places, and accounting for primarily query > parameter and data member changes > > > > Eventually retiring code for the previous iteration > > 5 > > Server-side signaling of the next iteration of an extension > > Add the new value of the rdapConformance in the help response and related > responses > > > > Make new URIs available > > Add the new value of the rdapConformance in the help response and related > responses > > > > No change in URIs for the new value of the rdapConformance > > Add the new value of the rdapConformance in the help response and related > responses > > > > To a lower extent than Approach A, make new URIs available > > 6 > > Collisions risk > > Zero since the new extension identifier is explicitly marked in data members > and URIs > > High since the new iteration of an extension is not marked in data members > and URIs, and is only discoverable through the rdapConformance value in a > response > > Zero since the new prefix is explicitly marked in data members and URIs, just > like the new extension identifier in Approach A > > > > > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
