Return-Path: X-Original-To: regext@mail2.ietf.org Delivered-To: regext@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id BEDCFFEBD214 for ; Wed, 10 Jun 2026 07:15:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1781100908; bh=FTWjEo6jwEFkHDubD6jv4gaOrMF/e4x6+hGWqsofwCg=; h=Date:Subject:To:References:From:In-Reply-To; b=GhFFCjWma6HWTZWU7kvsFm/E5HPbyP5gCh/6cQzIVKo7N3H1TmKZV5k2IotK7/Q9Y v89FmnkYYNlesNRjXzPLE4X18QaNQVD6f9S/gZklsrYJd7JaHRXtYXaeJEWryicdag 70mi0rK1HHBFS5ZpDa3w7tVYmPTCz6hSxUgAAiEs= X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=iit.cnr.it Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SXPJ5uHMKH0t for ; Wed, 10 Jun 2026 07:15:06 -0700 (PDT) Received: from mx5.iit.cnr.it (mx5.iit.cnr.it [146.48.58.12]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id E846FFEBD200 for ; Wed, 10 Jun 2026 07:15:05 -0700 (PDT) DKIM-Filter: OpenDKIM Filter v2.11.0 mx5.iit.cnr.it B5665C0BC6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iit.cnr.it; s=mx520231221; t=1781100904; bh=FTWjEo6jwEFkHDubD6jv4gaOrMF/e4x6+hGWqsofwCg=; h=Date:Subject:To:References:From:In-Reply-To:From; b=Z5UjnlBzoETTxSCKL7r1oej2u+nQx5GXOXOUp7xB6H0POlPQYZfxUIPCcsZU5C+Ax MsEkooP1NA9V+SuEnm2KCeJyV6i/aUhA9puLBwNEvnnpfjSrUaWV4zRMfITgdFzpwr Lyby/6e8tUrS4VkLwtXie8HuotyVzlB0yuGrV0m9X6vcZZ058ozBx0NBI+ljDX6bLn hZd31LlK0maWbVqyUgPuYb2HbHaUNFIPZ4vZ7/lnBTX2DuAxz6WhTmuQM5aE1z00qE AfUxAOvVjlUPjlcHAFuZ0WdIpikKo236vpeRKUfDFeyD3VVQiupdVbPCvAtbJmO0jm cFXnKXKfOGkpA== Received: from localhost (localhost [127.0.0.1]) by mx5.iit.cnr.it (Postfix) with ESMTP id B5665C0BC6; Wed, 10 Jun 2026 16:15:04 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mx5.iit.cnr.it Received: from mx5.iit.cnr.it ([127.0.0.1]) by localhost (mx5.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10028) with ESMTP id 4YL1QMaH5tEX; Wed, 10 Jun 2026 16:15:04 +0200 (CEST) X-Relay-Autenticated: yes Content-Type: multipart/alternative; boundary="------------ou57kVjjl0DGi0My0P4k1jhQ" Message-ID: Date: Wed, 10 Jun 2026 16:14:37 +0200 Mime-Version: 1.0 Content-Language: it To: Andy Newton , "Gould, James" , "kowalik=40denic.de@dmarc.ietf.org" , "regext@ietf.org" References: <2331E2EC-2724-4180-AE01-40E60EAE6BBC@verisign.com> <5b0fe67c-694c-4b0d-85e9-05cfe80d0a05@hxr.us> <3D0593A4-C893-4162-B3D8-ED38AD14A1F4@verisign.com> <8fdba77c-3f25-4e01-901d-8f797756a4e4@hxr.us> <8B84D932-D73E-4CEA-A137-B823C71F3CC7@verisign.com> <7b950404-daeb-4f57-a313-d4b92bf62669@hxr.us> <638BB998-8BC8-48DC-B715-9D33B987E80B@verisign.com> <38958367-d5b1-4f25-b52a-f0a85fb79112@denic.de> <835BCF2B-9B09-4A86-AE80-9A8C24E917F7@verisign.com> <5ca19b9e-7c0f-4dab-b9ae-2ee3b28c6a06@hxr.us> <243d05bb-5185-4061-be9f-ff7e10de4698@iit.cnr.it> From: Mario Loffredo In-Reply-To: Message-ID-Hash: RBMLCGGBF5ZRJ3RTMEQYGT3MEWBYSUIB X-Message-ID-Hash: RBMLCGGBF5ZRJ3RTMEQYGT3MEWBYSUIB X-MailFrom: mario.loffredo@iit.cnr.it X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-regext.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bregext=5D_Re=3A_draft-ietf-regext-rdap-x-media-type_and_draft-i?= =?utf-8?q?etf-regext-rdap-versioning_Compatibility_Topic_1=3A_Query_Identif?= =?utf-8?q?iers?= List-Id: Registration Protocols Extensions Working Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------ou57kVjjl0DGi0My0P4k1jhQ Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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=20 >> flaw in RDAP, as defined by the STD95 standard. Therefore, I believe=20 >> all clients and servers should implement these extensions to make=20 >> RDAP more efficient and interoperable. > > I disagree. Things like geofeed, the rpki extension, and even=20 > jscontact came around after RDAP was standardized. The only extension=20 > that we probably should have put in RDAP from the start is cidr0, and=20 > that is not even an IETF extension. [ML] Perhaps I didn't explain myself clearly enough. What I meant was=20 that most of the extensions were proposed to address aspects that were=20 partially or not at all covered by the STD95 standard. In all these cases, the working group agreed that the proposed extension=20 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=20 >> 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=20 to notify servers to use an extension. For example, I've updated the rdap-jscontact draft to replace the jscard=20 parameter with the exts_list parameter. >> IMO the question is whether we truly believe an extension is useful=20 >> or not. >> >> Regarding versioning as defined in rdap-versioning, I believe sending=20 >> a /help query is currently the method used by clients to discover=20 >> which RDAP features servers implement. >> >> Since these features might change over time, I expect clients to=20 >> regularly (not before each request, but periodically) send a /help=20 >> query to synchronize their implementations with those of the servers. > > No clients do this today. But this confirms my earlier assertion that=20 > what is being attempted with the versioning draft is not backwards=20 > compatible with everything deployed today. [ML] I'm sorry, but I don't understand why you think the versioning=20 extension is backwards-incompatible. Being an extension, it's inherently backwards-compatible because servers=20 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=20 structure into the /help response that the client might not require,=20 there are examples of RFCs that do the same thing, such as RFC9560 and=20 RFC9537. We agreed that this wasn't a problem because a JSON parser ignores what=20 it doesn't recognize, and by leveraging the rdapConformance array, a=20 client can detect that a response includes unhandled fields. > >> >> If a server implements the versioning specification, a client can not=20 >> only check which extensions, but also which versions of those=20 >> extensions are implemented by the server. > And what will the client do with that information? I have asked this=20 > question multiple times and have yet to get an answer. [ML] Clients may notice that a backwards-compatible change has occurred,=20 as explained in Section 5.4.5 of the rdap-extensions draft. They can also clearly determine the relationship between two versions of=20 an extension that differ by a backwards-incompatible change, as=20 explained in Section 5.4. Best, Mario > > -andy > > _______________________________________________ > regext mailing list -- regext@ietf.org > To unsubscribe send an email to regext-leave@ietf.org --=20 Dott. Mario Loffredo Senior Technologist Technological Unit =E2=80=9CDigital Innovation=E2=80=9D 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 --------------ou57kVjjl0DGi0My0P4k1jhQ Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

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.=C2=A0
[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.=C2=A0

[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.=C2=A0
[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.=C2=A0

[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 -- regext@ietf.org
To unsubscribe send an email to regext-leave@ietf.org 
--=20
Dott. Mario Loffredo
Senior Technologist
Technological Unit =E2=80=9CDigital Innovation=E2=80=9D
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
--------------ou57kVjjl0DGi0My0P4k1jhQ--