[regext] Re: draft-ietf-regext-rdap-x-media-type and draft-ietf-regext-rdap-versioning Compatibility Topic 1: Query Identifiers

[Mario Loffredo <[e-mail]>]

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 -- [e-mail]
> To unsubscribe send an email to [e-mail]

-- 
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: [phone]
Web:http://www.iit.cnr.it/mario.loffredo