Re: [regext] Analysis of tight coupling between extension identifier and rdapConformance, versus lack of

[Jasdip Singh <[e-mail]>]

Hi.

Further evolved the analysis based on the ongoing discussion. Specifically:

  1.  Refined the definitions of the 2 approaches (sorry James, haven’t included approach C yet).
  2.  Added a “Breakage analysis” section to test-drive breakage/collision scenarios for the 2 approaches. IMO, easier to discuss while visualizing side-by-side the JSON response for each approach.
Thanks,
Jasdip


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 version of the extension
rdapConformance = <extension identifier>

Extension identifier used to name new data members (including new object classes), and in new path segments (including any new query or matrix parameters?)

Approach B: Lack of tight coupling between extension identifier and rdapConformance

Extension identifier = <prefix>
  Registered in the IANA RDAP Extensions registry
rdapConformance = <prefix>[<version>]        [ ] means optional       (needs version 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 name new data members (including new object classes), and in new path segments (including any new query or matrix parameters?)

Comparing the two approaches:

Aspect

Approach A - tight coupling

Approach B - lack of tight coupling

Providing a new spec to IANA for a new version

Registry stays as-is

Registry needs to evolve for:

  *   Versioned rdapConformance
  *   Tying spec to versioned rdapConformance

Risk of breaking changes for RDAP clients

Yes, if the server now only supports the new version and a client hasn’t evolved yet

Data member names and path segments change with each new version but not an issue if clients have re-programmed a priori

Clients would knowingly call the versioned path segments — no guesswork

If a path segment is not affected by a new version and only a newly versioned data sub-object is added in the response, that could break clients

Yes, when a field is removed, or a required field is added, for a new version

When a call is made using a non-versioned path segment, the newly versioned rdapConformance would be checked after the fact and that could break the client for above field additions and subtractions if not re-programmed a priori

Clients would call non-versioned path segments but could be broken by the new responses

Cost of reprogramming clients for the next version of an extension

There is cost but not as high as it seems — replacing version in multiple places and accounting for field and query parameter additions and subtractions

Longer grace period for clients to reprogram if the server supports multiple versions during transition

There is cost — accounting for a field removal or a required field addition

Reprogramming could become exigent for clients if the server switches to the new version without supporting the previous version

Cost of reprogramming servers for the next version of an extension

There is a higher cost — if multiple versions are simultaneously supported during a transition period, replicating code from the previous version and replacing version in multiple places and accounting for field and query parameter additions and subtractions

Eventually retiring code for the previous version

There is a lower cost — if only the latest version is supported, accounting for a field removal or a required field addition vis-a-vis the previous version

Server-side signaling of the next version of an extension

Add the new version of the rdapConformance in the help response and related responses

Make URLs for new versions of path segments available

Add the new version of the rdapConformance in the help response and related responses

No change in URLs for the new version of the rdapConformance

Potential confusion for clients

Zero since the new version is explicitly marked in data members and URLs

Not zero since the new version is not marked in data members and URLs, and would only be discovered through the rdapConformance value in a response

Aesthetics (does not matter to a machine but could for human friendliness)

Less

More


Breakage analysis

Change Scenario

Approach A - tight coupling

Approach B - lack of tight coupling

Initial registration with IANA

ei = ext0  (registered)
rc = ext0

ei = ext  (registered)
rc = ext0  (registered)

Initial response (elided)
  Field f1 required; string
  Field f2 optional; number

p = …/ext0/…

{
  “rdapConformance” : [
    “ext0”
  ],
  {
    “ext0_o” : {
      “d1” : “a”
    },
    “ext0_f1” : “foo”,
    “ext0_f2” : 8
  }
}

p = …/ext/…

{
  “rdapConformance” : [
    “ext0”
  ],
  {
    “ext_o” : {
      “d1” : “a”
    },
    “ext_f1” : “foo”,
    “ext_f2” : 8
  }
}

Required field f1 removed

ei = ext1
rc = ext1

p = …/ext1/…

{
  “rdapConformance” : [
    “ext1”
  ],
  {
    “ext1_o” : {
      “d1” : “a”
    },
    “ext1_f2” : 8
  }
}

ei = ext
rc = ext1

p = …/ext/…

{
  “rdapConformance” : [
    “ext1”
  ],
  {
    “ext_o” : {
      “d1” : “a”
    },
    “ext_f2” : 8
  }
}

Clients still on rc ext0 when calling p break

Field f2 type changes; string now, instead of number

Object o sub-data changes with a new required member d2

ei = ext2
rc = ext2

p = …/ext2/…

{
  “rdapConformance” : [
    “ext2”
  ],
  {
    “ext2_o” : {
      “d1” : “a”,
      “d2” : “b”
    },
    “ext2_f2” : “bar”
  }
}

ei = ext
rc = ext2

p = …/ext/…

{
  “rdapConformance” : [
    “ext2”
  ],
  {
    “ext_o” : {
      “d1” : “a”,
      “d2” : “b”
    },
    “ext_f2” : “bar”
  }
}

Clients still on rc ext0 or ext1 when calling p break

Supporting multiple extension versions (assuming ext0 and ext1 so far) when response part of an existing path and there is no new path defined for an extension

{
  “rdapConformance” : [
    “ext0”,
    “ext1”
  ],
  {
    “ext0_o” : {
      “d1” : “a”
    },
    “ext0_f1” : “foo”,
    “ext0_f2” : 8
  },
  {
    “ext1_o” : {
      “d1” : “a”
    },
    “ext1_f2” : 8
  }
}

No client should break since each such response part would be optional to start with

{
  “rdapConformance” : [
    “ext1”
  ],
  {
    “ext_o” : {
      “d1” : “a”
    },
    “ext_f2” : 8
  }
}

Only response part for the latest extension could be included; otherwise, naming collisions

Clients not converted to the latest extension break


Legend:
ei - extension identifier
rc - rdapConformance
p - path segment
o - data object
d - sub-data within data object
f - data field


From: "Gould, James" <[e-mail]>
Date: Monday, May 23, 2022 at 11:07 AM
To: Jasdip Singh <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: Re: [regext] Analysis of tight coupling between extension identifier and rdapConformance, versus lack of

Jasdip,

How about adding Approach C: decouple the extension identifier in the rdapConformance from the set of path segment, JSON response member, and objectClassName prefix values?

The ABNF for an element (path segment, JSON response member, objectClassName), based on the registration of an extension prefix.  More than one prefix can be registered in a single specification, like creating an extension for the 5 objects in RFC 9082 and 9083.

element = prefix [ suffix ]

prefix = name

suffix = “_” name

name = ALPHA *( ALPHA / DIGIT / “_” ) ; format from RFC 7480


The rdapConformance value is an identifier that provides signaling for supporting a version of an extension.  The format defined in RFC 7480 is flexible enough to support a versioned identifier with:

name = ALPHA *( ALPHA / DIGIT / “_” )

My recommendation is to follow the pattern defined in RFC 9083 for the rdapConformance value with the ABNF, but I would not make this a requirement.

identifier = name “_level_” version

version = DIGIT [ “_” DIGIT ]

name = ALPHA *( ALPHA / DIGIT / “_” ) ; format from RFC 7480


I don’t believe the intent is to model XML namespace URIs, namespace prefixes, and element names in REST, but to ensure that there is no conflict across the RDAP extensions when it comes to rdapConformance identifiers, path segments, JSON response members, and objectClassName values.  The rdapConformance value is meant for signaling the support for an extension and therefore should support versioning.  The path segments, JSON response members, and objectClassName values need to be ensure uniqueness and are not meant for signaling, where there is no requirement that implies a linkage with the rdapConformance identifier.  When defining a new object with a registered “objectClassName” value, there is no need to define all of the unique object RDAP response members in the RDAP Extension Registry, since the “objectClassName” ensures uniqueness with other objects.  An extension can be created that includes a single versioned rdapConformance value and a set of path segments, JSON response members, and objectClassName prefix values.  Imagine an RDAP extension that contains multiple objects, like how RFC 9082 and 9083 supports 5 objects.  Based on Approach A and B, there needs to be a mapping of the rdapConformance identifier with all 5 objects, which is unnatural for a REST interface.  We need to ensure that there is version signaling in the rdapConformance and ensure uniqueness of path segments, JSON response members, and objectClassName values across a variety of RDAP extensions (e.g., extending existing objects and defining new objects).  I believe Approach C will satisfy it.




--

JG

[cid:image001.png@01D870B1.33B100B0]

James Gould
Fellow Engineer
[e-mail]<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com<http://verisigninc.com/>

From: regext <[e-mail]> on behalf of Jasdip Singh <[e-mail]>
Date: Thursday, May 19, 2022 at 8:52 PM
To: "[e-mail]" <[e-mail]>
Subject: [EXTERNAL] Re: [regext] Analysis of tight coupling between extension identifier and rdapConformance, versus lack of

Hi.

Honed the analysis a bit more.

Jasdip

---

Approach A: Tight coupling between extension identifier and rdapConformance

Extension identifier = <prefix>[<version>]                   [ ] means optional
  Registered in the IANA RDAP Extensions registry
  A new spec provided for each new version of the extension
rdapConformance = <prefix>[<version>]

Extension identifier used in new data members, and in new path segments (including any new query or matrix parameters)

Approach B: Lack of tight coupling between extension identifier and rdapConformance

Extension identifier = <prefix>
  Registered in the IANA RDAP Extensions registry
rdapConformance = <prefix>[<version>]                     [ ] means optional
  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 in new data members, and in new path segments (including any new query or matrix parameters)

Comparing the two approaches:

Aspect

Approach A - tight coupling

Approach B - lack of tight coupling

Providing a new spec to IANA for a new version

Registry stays as-is

Registry needs to evolve for:

  *   Versioned rdapConformance
  *   Tying spec to versioned rdapConformance

Risk of breaking changes for RDAP clients

Yes, if the server now only supports the new version and a client hasn’t evolved yet

Data member names and path segments change with each new version but not an issue if clients have re-programmed a priori

Clients would knowingly call the versioned path segments — no guesswork

If a path segment is not affected by a new version and only a newly versioned data sub-object is added in the response, that could break clients

Yes, when a field is removed, or a required field is added, for a new version

When a call is made using a non-versioned path segment, the newly versioned rdapConformance would be checked after the fact and that could break the client for above field additions and subtractions if not re-programmed a priori

Clients would call non-versioned path segments but could be broken by the new responses

Cost of reprogramming clients for the next version of an extension

There is cost but not as high as it seems — replacing version in multiple places and accounting for field and query parameter additions and subtractions

Longer grace period for clients to reprogram if the server supports multiple versions during transition

There is cost — accounting for a field removal or a required field addition

Reprogramming could become exigent for clients if the server switches to the new version without supporting the previous version

Cost of reprogramming servers for the next version of an extension

There is a higher cost — if multiple versions are simultaneously supported during a transition period, replicating code from the previous version and replacing version in multiple places and accounting for field and query parameter additions and subtractions

Eventually retiring code for the previous version

There is a lower cost — if only the latest version is supported, accounting for a field removal or a required field addition vis-a-vis the previous version

Server-side signaling of the next version of an extension

Add the new version of the rdapConformance in the help response and related responses

Make URLs for new versions of path segments available

Add the new version of the rdapConformance in the help response and related responses

No change in URLs for the new version of the rdapConformance

Potential confusion for clients

Zero since the new version is explicitly marked in data members and URLs

Not zero since the new version is not marked in data members and URLs, and would only be discovered through the rdapConformance value in a response

Aesthetics (does not matter to a machine but could for human friendliness)

Less

More



From: regext <[e-mail]> on behalf of Jasdip Singh <[e-mail]>
Date: Thursday, May 19, 2022 at 2:15 PM
To: "[e-mail]" <[e-mail]>
Subject: [regext] Analysis of tight coupling between extension identifier and rdapConformance, versus lack of

Hi.

Not sure if it is totally correct but wanted to input a strawman analysis of the two approaches -- tight coupling between extension identifier and rdapConformance, versus lack of -- to our discussion. Hope this is useful.

Thanks,
Jasdip

---

Approach A: Tight coupling between extension identifier and rdapConformance

Extension identifier = <prefix>[<version>]                   [ ] means optional
  Registered in the IANA RDAP Extensions registry
  A new spec provided for each new version of the extension
rdapConformance = <prefix>[<version>]

Extension identifier used in new data members, and in new path segments (including any new query or matrix parameters)

Approach B: Lack of tight coupling between extension identifier and rdapConformance

Extension identifier = <prefix>
  Registered in the IANA RDAP Extensions registry
rdapConformance = <prefix>[<version>]                     [ ] means optional
  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 in new data members, and in new path segments (including any new query or matrix parameters)

Comparing the two approaches:

Aspect

Approach A - tight coupling

Approach B - lack of tight coupling

Providing a new spec to IANA for a new version

Registry stays as-is

Registry needs to evolve for:

  *   Versioned rdapConformance
  *   Tying spec to versioned rdapConformance

Risk of breaking changes for RDAP clients

Yes, if the server now only supports the new version and a client hasn’t evolved

Data member names and path segments change with each new version but not an issue if clients have re-programmed a priori

Clients would knowingly call the versioned path segments — no guesswork

Even if a path segment is not affected by a new version but only a newly versioned data sub-object is added in the response, that could break clients

Yes, when a field is removed, or a required field is added, in a new version

When a call is made using a non-versioned path segment, the newly versioned rdapConformance would be checked after the fact and could break the client for above field additions and subtractions if not re-programmed a priori

Clients would call non-versioned path segments but could be broken by the new responses

Cost of reprogramming clients for the next version of an extension

There is cost but not as high as it seems — replacing version in multiple places and accounting for field and query parameter additions and subtractions

There is cost but could be higher than it seems - client finds after the fact about a field removal or a required field addition

Cost of reprogramming servers for the next version of an extension

There is cost but not as high as it seems — replacing version in multiple places and accounting for field and query parameter additions and subtractions

There is cost for a field removal or a required field addition

Server-side signaling of the next version of an extension

Add the new version of the rdapConformance in the help response and related responses

Make URIs for new versions of path segments available

Add the new version of the rdapConformance in the help response and related responses

No change in URIs for the new version of the rdapConformance

Potential confusion for clients

Zero since the new version is explicitly marked in data members and URIs

Not zero since the new version is not marked in data members and URIs

Aesthetics (should not matter to a machine but could to a human)

Less

More