IETF Logo Mail Archive

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

Jasdip Singh <jasdips@arin.net> Fri, 31 July 2020 16:50 UTC

Return-Path: <jasdips@arin.net>
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 85E2B3A097F for <regext@ietfa.amsl.com>; Fri, 31 Jul 2020 09:50:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tvOEeK7kKWlK for <regext@ietfa.amsl.com>; Fri, 31 Jul 2020 09:49:59 -0700 (PDT)
Received: from smtp1.arin.net (smtp1.arin.net [192.136.136.51]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 258513A0884 for <regext@ietf.org>; Fri, 31 Jul 2020 09:49:59 -0700 (PDT)
Received: from CAS02CHA.corp.arin.net (cas02cha.corp.arin.net [10.1.30.63]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by smtp1.arin.net (Postfix) with ESMTPS id 2F8E0107581E; Fri, 31 Jul 2020 12:49:58 -0400 (EDT)
Received: from CAS01CHA.corp.arin.net (10.1.30.62) by CAS02CHA.corp.arin.net (10.1.30.63) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 31 Jul 2020 12:50:05 -0400
Received: from CAS01CHA.corp.arin.net ([fe80::51fb:9cc2:1f9a:288b]) by CAS01CHA.corp.arin.net ([fe80::988:2227:cf44:809%17]) with mapi id 15.00.1104.000; Fri, 31 Jul 2020 12:50:05 -0400
From: Jasdip Singh <jasdips@arin.net>
To: Patrick Mevzek <pm@dotandco.com>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [regext] IANA Considerations in draft-ietf-regext-rdap-reverse-search
Thread-Index: AQHWZ1e8zuK77FiYU0SkFTZwYNJXwqkh5o6A
Date: Fri, 31 Jul 2020 16:50:05 +0000
Message-ID: <A04C5274-4701-4578-9F4F-9290A5781F9C@arin.net>
References: <1cb2fde4261748afa8163333d090b84a@verisign.com> <df404a43-8284-5466-7d83-88e27d5691ef@iit.cnr.it> <0f361bcb-cd2d-4336-8f71-f06f72430e48@www.fastmail.com> <234b29a5-ab00-6f1e-64f7-1da48673dbe2@iit.cnr.it> <65ee0574-0a07-4bf4-a73c-2d5fe8ec57f4@www.fastmail.com> <abb138473ef245ce9eb3e263f2e85a57@verisign.com> <b52e75cd-0cdd-4ff8-8335-2e7423cfe94d@www.fastmail.com>
In-Reply-To: <b52e75cd-0cdd-4ff8-8335-2e7423cfe94d@www.fastmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [192.136.136.37]
Content-Type: text/plain; charset="utf-8"
Content-ID: <B958B372D250B44D9BC3F810BD13E1F2@corp.arin.net>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/jRvQvPHLMWckIb79CxlSNZgRrNE>
Subject: Re: [regext] 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: Fri, 31 Jul 2020 16:50:04 -0000

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

v2.23.0 | Report a Bug | By Email