IETF Logo Mail Archive

Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)

Mario Loffredo <mario.loffredo@iit.cnr.it> Mon, 18 July 2022 08:42 UTC

Return-Path: <mario.loffredo@iit.cnr.it>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4D866C13C51B for <regext@ietfa.amsl.com>; Mon, 18 Jul 2022 01:42:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ujf2_Wtpvr5P for <regext@ietfa.amsl.com>; Mon, 18 Jul 2022 01:42:07 -0700 (PDT)
Received: from smtp.iit.cnr.it (mx4.iit.cnr.it [146.48.58.11]) by ietfa.amsl.com (Postfix) with ESMTP id 5A802C157B32 for <regext@ietf.org>; Mon, 18 Jul 2022 01:42:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 4D662B80159; Mon, 18 Jul 2022 10:42:03 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mx4.iit.cnr.it
Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx4.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f-wtBkfwvfwm; Mon, 18 Jul 2022 10:42:00 +0200 (CEST)
Received: from [192.12.193.108] (pc-loffredo.staff.nic.it [192.12.193.108]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by smtp.iit.cnr.it (Postfix) with ESMTPSA id BD550B80110; Mon, 18 Jul 2022 10:42:00 +0200 (CEST)
Message-ID: <85387f48-2443-2e27-74f1-025e24ec8224@iit.cnr.it>
Date: Mon, 18 Jul 2022 10:39:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.11.0
To: "Gould, James" <jgould=40verisign.com@dmarc.ietf.org>, "andy@hxr.us" <andy@hxr.us>
Cc: "Hollenbeck, Scott" <shollenbeck@verisign.com>, "regext@ietf.org" <regext@ietf.org>
References: <0C87A351-7EC7-4684-BF7A-FAB0EA12677E@verisign.com>
From: Mario Loffredo <mario.loffredo@iit.cnr.it>
In-Reply-To: <0C87A351-7EC7-4684-BF7A-FAB0EA12677E@verisign.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/3beZnRADudZu9-lxaXnVc6PoH0M>
Subject: Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Jul 2022 08:42:11 -0000

I agree with James.

The drawback of Approach A is that even an additive change to an 
existing extension would result in a breaking change to the RDAP 
service. As a consequence,  servers should always manage the transition 
from two subsequent versions of an extension.

The above scenario seems to me harmful for both clients and servers.


Best,

Mario


Il 15/07/2022 14:13, Gould, James ha scritto:
> Andy,
>
> Thanks for weighing in on this.  I provide my replies embedded below.
>
-- 
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo

v2.23.0 | Report a Bug | By Email