Hi Mario,
Inline....
On 12/11/25 3:27 AM, Mario Loffredo wrote:
> Hi Andy,
>
> please find my feedback below.
>
> 1) AFAIU, Secion 5.4.4 prohibits the server practice of updating an existing
> extension silently, i.e. without signaling clients about the updates.
>
> If that's the goal, I would rephrase section 5.4.4 as in the following:
>
> Because RDAP clients ignore unrecognized JSON names and query
> parameters, it is possible to extend an RDAP extension by adding new
> JSON names or query parameters within the same namespace of an
> existing RDAP extension without changing the extension identifier or
> adding a new extension version (see [I-D.ietf-regext-rdap-versioning]) or
> other signaling methods.
>
> In this scenario, clients that are not updated to recognize the new
> elements should simply ignore them. The same is also true for
> referrals (see Section 5.2).
>
> Extensions MUST NOT be evolved without explicitly signaling clients
> regarding the updates.
> This lack of signal will lead to difficulty in troubleshooting issues
> and could mislead client implementers to believe their software is
> fully conforming with the extension specification when it is not.
>
> I removed the original third paragraph because the only way I know of to
> cause RDAP clients to fail is to introduce breaking changes which is already
> covered by section 5.4.3.
See my message to Pawel regarding object classes.
> 2) The overlapping response extension feature, as described in Section 5.4.2,
> aimed at reducing response size seems very complicated, and I wouldn't
> recommend it.
>
> Perhaps It could be implemented when the next version updates an extension
> that previously extended both the response and the request, expecially when
> the next version extends only the response but not the request, or vice versa.
>
> However, it seems like a complex workaround to a clear limitation of opaque
> versioning, which is duplicating any part of the extension in any version of
> the extension.
>
> Therefore, the best way to achieve this is to have servers return one
> response extension version upon client request, as described in the
> rdap-versioning and rdap-x-media-type documents.
>
> With regard to the given example, the server could return either this:
>
> {
> "rdapConformance": [
> "rdap_level_0",
> "fizzbuzz0"
> ],
> "objectClassName": "domain",
> "ldhName": "example.com",
> "fizzbuzz0_malwareReputationId": 1234
> }
>
> or this:
>
> {
> "rdapConformance": [
> "rdap_level_0",
> "fizzbuzz1"
> ],
> "objectClassName": "domain",
> "ldhName": "example.com",
> "fizzbuzz1_malwareReputationId": 1234,
> "fizzbuzz1_spamReputationId": 7890
> }
The advantage to an overlapping successor is that it maintains backwards
compatibility with clients that don't yet understand the new extension.
Changing the extension ID breaks backwards compatibility.
You are correct that a versioning scheme would fix that, but not all extensions
may opt for it, especially the simpler ones. Additionally, there are a bunch of
current extensions that may want to do a simple forward compatible upgrade this
way.
I think it is up to the extension author to determine the method that is right
for them.
-andy
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
