IETF Logo Mail Archive

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

Mario Loffredo <mario.loffredo@iit.cnr.it> Sat, 20 June 2026 06:02 UTC

Return-Path: <mario.loffredo@iit.cnr.it>
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 38E2E10458BB3 for <regext@mail2.ietf.org>; Fri, 19 Jun 2026 23:02:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1781935376; bh=m9hJTFhTtJ+gP8EUNK+qUD/xUNeaMmkIl60ZTtsz3Ww=; h=Date:Subject:To:References:From:In-Reply-To; b=KQzdwcXmm6/4DeUkw/Mw52ih26VCrykujqCjXp9vB29rfn193Ztv16cSoyv4pqRHw I1JXSD++/hyVKG9e3EOxReEYuDnydDzOuu0olLGWkvcWllNGJo60anuBT9IDDXHomG 0sIB6alMjN6WzeB3mfqIhMJ8FlD0sCqJH/azKvkc=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 8zp236mmYHNH for <regext@mail2.ietf.org>; Fri, 19 Jun 2026 23:02:55 -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 5126510458BAA for <regext@ietf.org>; Fri, 19 Jun 2026 23:02:55 -0700 (PDT)
DKIM-Filter: OpenDKIM Filter v2.11.0 mx5.iit.cnr.it 94D9FC05E5
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iit.cnr.it; s=mx520231221; t=1781935373; bh=m9hJTFhTtJ+gP8EUNK+qUD/xUNeaMmkIl60ZTtsz3Ww=; h=Date:Subject:To:References:From:In-Reply-To:From; b=lwMuKDZ1veztrD/fku50Ly7uv8rKZvQb6dkBMVfpjG29n8mLLhbLPmoNkXwSAEZeS Bhhm3XKB5DxDoVm7lX9ugTcHENWgy6tM8IeC/62dGb8kW3TPIOp6oy0dfdCGQhLHtx l4vUltkuol3HqcD9NEXVQsiCST3mhTfGJOE3H0u2akGkWxIXeSm59j1KdCveTJ0QHt GJAu8TZpiBfkpS1yM1sWhKLdMBz0iM33PmjpGlY2BT7cINjiXuIRqSZY6cIj2RLWmZ SkWhOtMgYX4mOkt1dl4JAbFqfs2tGhrx6KAm6Szguf88lQ/1KtGqh2V2BaWkfqEcwH qQ3Il2OYEHQ6g==
Received: from localhost (localhost [127.0.0.1]) by mx5.iit.cnr.it (Postfix) with ESMTP id 94D9FC05E5; Sat, 20 Jun 2026 08:02:53 +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 UdIZrYqyXHBm; Sat, 20 Jun 2026 08:02:53 +0200 (CEST)
X-Relay-Autenticated: yes
Message-ID: <fbafcb7d-6e95-4d33-9cf6-4e858c5e35ac@iit.cnr.it>
Date: Sat, 20 Jun 2026 08:02:18 +0200
Mime-Version: 1.0
Content-Language: it
To: Pawel Kowalik <kowalik=40denic.de@dmarc.ietf.org>, Andy Newton <andy@hxr.us>, "Gould, James" <jgould@verisign.com>, "regext@ietf.org" <regext@ietf.org>
References: <2331E2EC-2724-4180-AE01-40E60EAE6BBC@verisign.com> <8fdba77c-3f25-4e01-901d-8f797756a4e4@hxr.us> <A4A667C6-3CCF-428F-B134-89F72634C3A4@verisign.com> <eac5c1c1-9ade-423e-a283-191070e6968e@hxr.us> <8B84D932-D73E-4CEA-A137-B823C71F3CC7@verisign.com> <7b950404-daeb-4f57-a313-d4b92bf62669@hxr.us> <cfc38d89-3a99-4269-8b1b-e684dc344511@iit.cnr.it> <b863f9e4-1457-4f3c-b3a9-c83bf7392f6c@denic.de> <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> <b17f27d3-9649-40c7-985a-c7351fc22dca@hxr.us> <e7b7e67a-c567-4f42-a39a-c77d594e0988@iit.cnr.it> <f8f3d039-e7d0-4452-ae45-e01b45c0caef@hxr.us> <831c687d-0034-49a2-8737-ce8cad4b340a@iit.cnr.it> <1a7aaee2-b6a3-4f65-8786-38ab6f55c389@denic.de> <5d083983-fc82-4e27-ba00-c8a34241af0e@iit.cnr.it> <da1101bd-4a7b-4df3-a930-e56d832e8323@denic.de>
From: Mario Loffredo <mario.loffredo@iit.cnr.it>
In-Reply-To: <da1101bd-4a7b-4df3-a930-e56d832e8323@denic.de>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Message-ID-Hash: Q3HXPOCPPQ6NX4O3RMBQLXYARIA42JEA
X-Message-ID-Hash: Q3HXPOCPPQ6NX4O3RMBQLXYARIA42JEA
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: [regext] Re: draft-ietf-regext-rdap-x-media-type and draft-ietf-regext-rdap-versioning Compatibility Topic 1: Query Identifiers
List-Id: Registration Protocols Extensions Working Group <regext.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/gWB_HmFDBUXAdcbS0HiUU_mvfas>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Owner: <mailto:regext-owner@ietf.org>
List-Post: <mailto:regext@ietf.org>
List-Subscribe: <mailto:regext-join@ietf.org>
List-Unsubscribe: <mailto:regext-leave@ietf.org>

Il 19/06/2026 18:54, Pawel Kowalik ha scritto:
> Hi Mario,
>
> On 19.06.26 18:47, Mario Loffredo wrote:
>> [ML] This is an example of how the given backward-incompatible change 
>> can be handled by changing the extension identifier, thus maximizing 
>> the scope of the change.
>>
>> In both cases, a transition must be managed to deprecate an extension 
>> feature. However, in the first example, the transition aims to 
>> deprecate risk_ext.score; in the second example, the transition aims 
>> to deprecate the entire risk_ext member (and any other extension 
>> features).
>>
> Deprecation of risk_ext.score without change of extension identifier 
> is a complex decision, as in fact it would be breaking for unaware 
> client so in fact would again require a change of extension identifier.

Why would it break clients ?

What would be the difference between deprecating risk_ext1 in favor of 
risK_ext2 and deprecating risk_ext.score by adding 
risk_ext.normalizedScore and then managing the transition from 
risk_ext.score to risk_ext.normalizedScore ?

Best,

Mario

>
> Kind Regards,
> Pawel
>
-- 
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

v2.46.0 | Report a Bug | By Email | System Status