Hi Andy,
please find my comments inline prefixed with [ML].
Il 11/12/2025 22:11, Andy Newton ha scritto:
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.
[ML] Adding elements isn't a problem because clients can continue
parsing the response without errors. Updating existing ones, however, is.
Because current JSON libraries allow for inserting members of unknown
objects into a map, clients can detect new elements in RDAP responses in
two ways:
- directly, by checking which response objects have been updated;
- indirectly, by checking for new rdapConformance tags or new extension
versions and then reading the related extension specifications.
I agree that even non-breaking changes should generate either a new
extension (when opaque versioning is used) or a new version (when
maturity versioning is used) , simply because clients might lose
information, not because they might fail to parse the response.
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.
[ML] The example in the draft supporting your idea seems very unusual to
me. The most common scenario is extending an existing object by adding
an optional element. In this case, the overlapping successor doesn't
work when using opaque versioning, but is handled naturally by maturity
versioning like any other change.
It gets very complicate when a server has to handle multiple versions of
the same extension.
It also seems misleading, meaning: will fizzbuzz1 simply add
spamReputationId or replace malwareReputationId with spamReputationId?
In other words, does fizzbuzz1 overlap with fizzbuzz0 or not?
Also, can a client deduce that fizzbuzz1_malwareReputationId can be
omitted by the server in the fizzbuzz1 extension, while
fizzbuzz0_malwareReputationId is always returned ?
FInally, per what is stated in section 5.4, fizbuzz0 e fizzbuzz1 are to
different extensions that might even have different purposes.
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.
[ML] Which extensions are you thinking of ? I guess none of the
extension already standardized because all of them extend the response
with on object.
I think it is up to the extension author to determine the method that is right
for them.
[ML] In case of overlap, there should be only two options for servers:
duplicating the extension or providing a specific extension/version upon
request
Best,
Mario
-andy
--
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]
