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

Mario Loffredo <mario.loffredo@iit.cnr.it> Tue, 19 July 2022 16:22 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 2D735C14F72E for <regext@ietfa.amsl.com>; Tue, 19 Jul 2022 09:22:01 -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 QvBvtHqWKvn3 for <regext@ietfa.amsl.com>; Tue, 19 Jul 2022 09:21:56 -0700 (PDT)
Received: from smtp.iit.cnr.it (mx4.iit.cnr.it [146.48.58.11]) by ietfa.amsl.com (Postfix) with ESMTP id 90687C14F743 for <regext@ietf.org>; Tue, 19 Jul 2022 09:21:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id C135EB80935; Tue, 19 Jul 2022 18:21:53 +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 OTDH1JH01SJf; Tue, 19 Jul 2022 18:21:50 +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 CCBAFB80858; Tue, 19 Jul 2022 18:21:50 +0200 (CEST)
Message-ID: <8be4182a-c540-0f96-c3ba-2849fcd399d4@iit.cnr.it>
Date: Tue, 19 Jul 2022 18:19:23 +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: Andrew Newton <andy@hxr.us>, "Gould, James" <jgould@verisign.com>
Cc: "Hollenbeck, Scott" <shollenbeck@verisign.com>, "regext@ietf.org" <regext@ietf.org>
References: <DB38F1D3-FC41-4B42-8C00-AB408FD1F204@verisign.com> <CAAQiQReG1MTF8EFuSMASoeuct+h+wmLUZRmgyvyo-fHL2g918g@mail.gmail.com>
From: Mario Loffredo <mario.loffredo@iit.cnr.it>
In-Reply-To: <CAAQiQReG1MTF8EFuSMASoeuct+h+wmLUZRmgyvyo-fHL2g918g@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/2LeViVzvY0j_ufr_fecQTrWJ18I>
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: Tue, 19 Jul 2022 16:22:01 -0000

HI Andy,

Il 19/07/2022 17:10, Andrew Newton ha scritto:
> On Tue, Jul 19, 2022 at 10:58 AM Gould, James <jgould@verisign.com> wrote:
>> Since rdapConformance is defined as an array of strings, adding the sub-element definition in the rdapConformance is something new.
> It is not new. Adding another string to the array is exactly how it is
> supposed to work. I'm not in favor of creating entirely new mechanisms
> if the ones we have will suffice. Can you please demonstrate why it
> will not work?

In my opinion, it doesn't work when the extension is related to a 
specification defined out of the RDAP context but is used in RDAP such 
as JSContact or VCARD itself. In this case, a server can simply update 
the hint in rdapConformance to signal that a new version of the external 
specification is supported.

As a matter of fact, we have already done it (even if unconsciously) 
without either passing from "rdap_level_0" to "rdap_level_1".

I'm referring to the fact that the RDAP response format has indirectly 
been extended to support the VCARD CC parameter when RDAP responses were 
already provided by servers and consumed by clients.


Best,

Mario

>
> As for auto-discovery, I am not discounting your call-out for that
> feature. I just don't think it applies to the use cases you have
> provided. Additionally, I don't know if it is a problem yet, as Scott
> has pointed out the /help query allows a client to discover a server's
> capabilities.
>
> -andy
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

-- 
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