Hi Andy,
please find comments embedded prefixed with [ML]
Il 10/06/2026 14:39, Andy Newton ha scritto:
On 10-06-2026 5:58 AM, Mario Loffredo wrote:
Hi Andy,
most (perhaps all) of the extensions proposed so far aim to fix a
flaw in RDAP, as defined by the STD95 standard. Therefore, I believe
all clients and servers should implement these extensions to make
RDAP more efficient and interoperable.
I disagree. Things like geofeed, the rpki extension, and even
jscontact came around after RDAP was standardized. The only extension
that we probably should have put in RDAP from the start is cidr0, and
that is not even an IETF extension.
[ML] Perhaps I didn't explain myself clearly enough. What I meant was
that most of the extensions were proposed to address aspects that were
partially or not at all covered by the STD95 standard.
In all these cases, the working group agreed that the proposed extension
deserved standardization because it addressed a client and/or server need.
I think you'll agree with this.
Don't you think the signaling mechanism described in
rdap-x-media-type should be implemented by all clients and servers?
No. Only if they need to use it.
[ML] Sure, but it's designed to provide clients with a unique mechanism
to notify servers to use an extension.
For example, I've updated the rdap-jscontact draft to replace the jscard
parameter with the exts_list parameter.
IMO the question is whether we truly believe an extension is useful
or not.
Regarding versioning as defined in rdap-versioning, I believe sending
a /help query is currently the method used by clients to discover
which RDAP features servers implement.
Since these features might change over time, I expect clients to
regularly (not before each request, but periodically) send a /help
query to synchronize their implementations with those of the servers.
No clients do this today. But this confirms my earlier assertion that
what is being attempted with the versioning draft is not backwards
compatible with everything deployed today.
[ML] I'm sorry, but I don't understand why you think the versioning
extension is backwards-incompatible.
Being an extension, it's inherently backwards-compatible because servers
and clients aren't required to implement it. They can choose to do so.
If you think it's backwards-incompatible because it introduces a data
structure into the /help response that the client might not require,
there are examples of RFCs that do the same thing, such as RFC9560 and
RFC9537.
We agreed that this wasn't a problem because a JSON parser ignores what
it doesn't recognize, and by leveraging the rdapConformance array, a
client can detect that a response includes unhandled fields.
If a server implements the versioning specification, a client can not
only check which extensions, but also which versions of those
extensions are implemented by the server.
And what will the client do with that information? I have asked this
question multiple times and have yet to get an answer.
[ML] Clients may notice that a backwards-compatible change has occurred,
as explained in Section 5.4.5 of the rdap-extensions draft.
They can also clearly determine the relationship between two versions of
an extension that differ by a backwards-incompatible change, as
explained in Section 5.4.
Best,
Mario
-andy
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [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]
