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.
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
}
Best,
Mario
Il 10/12/2025 08:02, Pawel Kowalik ha scritto:
Hi Andy,
I don't think it is a good proposal as it is limiting evolution of
extensions too much in the area,
where rfc9083 is very explicit about that it is intended to be allowed
even with a mention
that this method may be used to evolve rfc9083 itself.
A given example of new object classes does not resonate to me as a
problem,
as they will appear under own path segments which won't be a problem
for clients not knowing or using them.
Extensions draft may at most recommend usage of version signalling
facilities, such as ietf-regext-rdap-versioning,
but as long as it remains to be an extension and not an update to STD
95 we need to always consider clients
which do not implement or understand it. Those clients must be able to
work seamlessly (not break at least)
also without signalling like ietf-regext-rdap-versioning.
Therefore the extensions draft must mandate extensions authors to take
care that clients
do not break when adding non-braking changes (such as adding JSON fields)
and recommend using common signalling facilities (such as
ietf-regext-rdap-versioning) for minor version update
signalling and/or negotiation.
Last but not least, the extension itself may define its own versioning
schema and signalling mechanism.
Sometimes it may be derived from an existing specification (JSContact
for example has own versioning schema).
Finally, even an existence of a new field may be considered as
signalling, that an aware client may use, so the text in current form
is barely enforceable.
Kind Regards,
Pawel
On 04.12.25 21:25, Andy Newton wrote:
Hi all,
As mentioned at IETF 124, this version updates section 5 based on the
conversations at the IETF and on the mailing list prior.
I would like to draw your attention to section 5.4. The author team
believes
evolving extensions in that manner should be forbidden, but that's
more of
a proposal. If others have thoughts, please share.
-andy
On 04-12-2025 2:40 PM, [email protected] wrote:
Internet-Draft draft-ietf-regext-rdap-extensions-09.txt is now
available. It
is a work item of the Registration Protocols Extensions (REGEXT) WG
of the
IETF.
Title: RDAP Extensions
Authors: Andy Newton
Jasdip Singh
Tom Harrison
Name: draft-ietf-regext-rdap-extensions-09.txt
Pages: 28
Dates: 2025-12-04
Abstract:
This document describes and clarifies the usage of extensions in
RDAP.
The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-extensions/
There is also an HTML version available at:
https://www.ietf.org/archive/id/draft-ietf-regext-rdap-extensions-09.html
A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-regext-rdap-extensions-09
Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
_______________________________________________
regext mailing list [email protected]
To unsubscribe send an email [email protected]
--
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]
