Re: [regext] RDAP Extensions Approach Analysis v2

[Andrew Newton <[e-mail]>]

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 <[e-mail]> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext