[regext] Fwd: Re: IANA Considerations in draft-ietf-regext-rdap-reverse-search

Mario Loffredo <mario.loffredo@iit.cnr.it> Tue, 20 October 2020 12:45 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 9F1383A09F3 for <regext@ietfa.amsl.com>; Tue, 20 Oct 2020 05:45:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dlMV5NO5jnk for <regext@ietfa.amsl.com>; Tue, 20 Oct 2020 05:45:46 -0700 (PDT)
Received: from smtp.iit.cnr.it (mx5.iit.cnr.it [146.48.98.152]) by ietfa.amsl.com (Postfix) with ESMTP id 0CB383A09F0 for <regext@ietf.org>; Tue, 20 Oct 2020 05:45:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id D20B5C05B3 for <regext@ietf.org>; Tue, 20 Oct 2020 14:45:43 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mx5.iit.cnr.it
Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx5.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DbbiQcjRUf6X for <regext@ietf.org>; Tue, 20 Oct 2020 14:45:40 +0200 (CEST)
Received: from [192.12.193.108] (pc-loffredo.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 8E69AC0077 for <regext@ietf.org>; Tue, 20 Oct 2020 14:45:40 +0200 (CEST)
References: <d2c4accd-0182-57b7-6fbc-e63fd1aae2b9@iit.cnr.it>
To: "regext@ietf.org" <regext@ietf.org>
From: Mario Loffredo <mario.loffredo@iit.cnr.it>
X-Forwarded-Message-Id: <d2c4accd-0182-57b7-6fbc-e63fd1aae2b9@iit.cnr.it>
Message-ID: <b55a5f35-535d-68b5-b028-1eceb05df6a1@iit.cnr.it>
Date: Tue, 20 Oct 2020 14:42:17 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.12.1
MIME-Version: 1.0
In-Reply-To: <d2c4accd-0182-57b7-6fbc-e63fd1aae2b9@iit.cnr.it>
Content-Type: multipart/alternative; boundary="------------B0CF47902EB2F054E0D51471"
Content-Language: it
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/qlluhSvEu0-GtJ1UEh_JKK8F8QQ>
Subject: [regext] Fwd: Re: IANA Considerations in draft-ietf-regext-rdap-reverse-search
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
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, 20 Oct 2020 12:45:49 -0000

Hi all,

as a consequence of last discussion about rdapConformance, I propose to 
update RFC7483bis in order to clarify that rdapConformance in the help 
response must be used to signal the conformances with all the 
specifications implemented by the RDAP server. For any other response, 
rdapConformance must provide only hints as to the specifications used in 
the construction of the response.

Additionally, I wonder whether or not the rdapConformance values should 
be returned according to the user profile. Does an RDAP user really need 
to know about services that he won't be able to request?

Best,
Mario

-------- Messaggio Inoltrato --------
Oggetto: 	Re: [regext] IANA Considerations in 
draft-ietf-regext-rdap-reverse-search
Data: 	Fri, 31 Jul 2020 19:12:36 +0200
Mittente: 	Mario Loffredo <mario.loffredo@iit.cnr.it>
A: 	Jasdip Singh <jasdips@arin.net>, Patrick Mevzek <pm@dotandco.com>, 
regext@ietf.org <regext@ietf.org>



Hi all,

if I understood well the rdapConformance content in the help response 
should be different from that included in the other responses. Right?

I misunderstood Scott's proposal as a mean by which a server could 
inform a client about the supported features any time regardless the 
response content.

In that sense, I proposed the server could distinguish the 
rdapConformance content according the user profile.


I have no objection to this solution but I think that the two cases 
above should be outlined in RFC7483bis.

Best,

Mario

Il 31/07/2020 18:50, Jasdip Singh ha scritto:
> Agree with Patrick's points about rdapConformance in the help response 
> informing about all capabilities and rdapConformance being more 
> specific for a particular query response.
>
> Jasdip
>
> On 7/31/20, 12:29 PM, "regext on behalf of Patrick Mevzek" 
> <regext-bounces@ietf.org on behalf of pm@dotandco.com> wrote:
>
> On Fri, Jul 31, 2020, at 11:21, Hollenbeck, Scott wrote:
> > Note "supported extensions". This is why I'm saying that we need to
> > register all extensions with IANA
> I agree.
> > and include them in the
> > rdapConformance data structure even if they don't describe a response
> > extension.
> I agree, everything should be listed in the reply to an help query.
> I am just saying that for any other reply that is a specific one on a 
> specific resource
> then the rdapConformance should just list the "extensions" needed to 
> understand this
> specific response, and not list absolutely all extensions the server 
> knows about
> (and that are irrelevant for this specific response).
> The list of what is written in the response should certainly not be 
> just server policy,
> especially if there is no automated way to learn about this policy. 
> Otherwise if you include
> options like that (the list presented might be the list of all server 
> extensions OR only the subset needed for this specific response) AND 
> there is no way for the client to know which
> case he is in, it immediately creates interoperability problems. I 
> prefer no such options
> and the protocol clearly defining the content. Or if such options are 
> really needed
> (if help response is always all extensions, and any other response is 
> just the specific extensions needed, then nothing more is needed), 
> there should be a signal to know which
> case we are in.
> > The help response should include supported
> > extensions that are available to that client.
> Yes, the help response allows to "discover" all possible extensions 
> from a specific client.
> --
> Patrick Mevzek
> pm@dotandco.com
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext

-- 
Dr. Mario Loffredo
Systems and Technological Development Unit
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Mobile: +39.3462122240
Web: http://www.iit.cnr.it/mario.loffredo

_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext