IETF Logo Mail Archive

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

"Gould, James" <jgould@verisign.com> Tue, 19 July 2022 15:28 UTC

Return-Path: <jgould@verisign.com>
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 E85FDC188735 for <regext@ietfa.amsl.com>; Tue, 19 Jul 2022 08:28:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.409
X-Spam-Level:
X-Spam-Status: No, score=-4.409 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 Us9JEL1RtcPW for <regext@ietfa.amsl.com>; Tue, 19 Jul 2022 08:27:56 -0700 (PDT)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 596BEC188730 for <regext@ietf.org>; Tue, 19 Jul 2022 08:27:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=3048; q=dns/txt; s=VRSN; t=1658244477; h=from:to:cc:subject:date:message-id:content-id: content-transfer-encoding:mime-version; bh=k+MtidvG8q/zWNdzSO4r9uDggBONGqe0n5kNmq8rLYs=; b=Z1FXMAQglFoxjvl1CoaA81L//SEUTkCTYqFXmRrHlYomqvMWiQkvcpdX fWblMkHRKRfKfc6GFTBz6ThMXtwGSM6tKtRXAfl//tXRAhZWEtvL6Px8b b95qGiyyVGOV63/ScEV3oDBluDxibKzrX4aXIk0sa3F4NQid8Hk4iqXH4 BJd8c5ffdLto9IkeGqRjxB3Lu/9ymavOFyKzrFyAmbcKVa0wTc1P1Ht/r UwahBmZVTYCqgWVBzTee9DoqUUwVRTcTNBWokT6RKIoWH3JvoY9alJ9Wu 6s/OfN2G7leaBLBiOta29o2kKW8UjIVnRKvJFdiX9pINmT09338a2XIlN A==;
IronPort-Data: A9a23:4s3DN6isxk8347Vh736MWuFiX161NhEKZh0ujC45NGQN5FlHY01je htvUWmDP/fYMGPwftB+bYm38EoEvJeDyYNlTgNvqHg3Ri8W8JqUDtmndUqhZCn6wu8v7q5Ex 55HNoSfdpBcolv0/ErF3m3J9CEkvU2wqz6V5NfsYkidfyc9IMsaoU8lyrRRbrJA24DjWVvS4 IKq+aUzBXf+s9JKGjNMg068gE431BjCkGtwUosWPK0jUPf2zhH5PbpHTU2DByKQrrp8R4ZWc 93+IISRpQs1yT92U4/4zeyrGqE9auW60QCm0hK6UoD82kQS/nRaPqwTbJLwYm8P49mFckwYJ HygevVcRC9wVpAgltjxXDEJTwxsIq1kpoTlCmWjjfO99A7jbUPVlqAG4EEeZeX0+85dO0cXy to1GGhUKA6IgPiuhru3DPd2ncJlJ87uVG8dkig4i2iGVrB/HMuFH/WiCdxwhV/cguhMEvHDY 8Yxdzd1bQ/BbBsJMVASYH47tL712ienKGQHwL6TjattwU3MwCd86eHkDofVQdumYcxFwH/N8 woq+Ey8WHn2Lue3wDyJ41qslvWJgDiTcIcbDry/sPptjlOJy2AUIBwXSR2wp+P/i1LWc8hSJ EEE5gIvoLQ8skuxQbHAswaQqmSC5wEaVsoISqgh9hvLz6vPpgyeQGIeSGcHdsY9sok9QjlCO kK1ou4FzAdH6NW9IU9xPJ/Nxd9uEUD59VM/WBI=
IronPort-HdrOrdr: A9a23:z9fxyK2FoOcCK1H7dJSRIgqjBG8kLtp133Aq2lEZdPUzSL38qy nOpoV46faaslYssR0b9+xoW5PufZq0z/cc3WB7B8bAYOCJggqVBbAnw4fkzybpBiHyssVMvJ 0NT4FOTPn9F0Jzg8q/wgWpeuxL/PC3tISln/3XwXsodxxtcK0I1WpEIxyWCVJ7XzNLApcFFJ 6Rj/Atmwad
X-IronPort-AV: E=Sophos;i="5.92,284,1650931200"; d="scan'208";a="15460317"
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.28; Tue, 19 Jul 2022 11:27:53 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) by BRN1WNEX01.vcorp.ad.vrsn.com ([10.173.153.48]) with mapi id 15.01.2375.028; Tue, 19 Jul 2022 11:27:53 -0400
From: "Gould, James" <jgould@verisign.com>
To: "andy@hxr.us" <andy@hxr.us>
CC: "Hollenbeck, Scott" <shollenbeck@verisign.com>, "mario.loffredo@iit.cnr.it" <mario.loffredo@iit.cnr.it>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: Re: Re: Re: Re: [regext] OK, What Next? (was RDAP Extensions Approach Analysis v2)
Thread-Index: AQHYm4QcAsTLSNGtik6ejgdWElMRug==
Date: Tue, 19 Jul 2022 15:27:52 +0000
Message-ID: <64394414-B420-417D-A01E-1333D81FE5B4@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/16.62.22061100
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <F9170966C011FF46A4F419893CC06815@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/53eBGJVaS4OA2XdQLr_GhpJsyKU>
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 15:28:01 -0000

Andy,

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

Changing the definition of the rdapConformance from an array of strings to an array of objects is certainly new and has never been defined.  My recommendation is if true auto-discovery is intended that it should live within a new RDAP extension, which based on experience for EPP is ambitious, since it would provide a definition of both the extensions supported as well as the server-policies chosen for the extensions.  Look at draft-gould-regext-login-security-policy for an example of defining the server policies for the EPP Login Security Extension, defined in RFC 8807.  What MAYs and SHOULDs are supported by the server comes into play, so auto-discovery can get complex when digging into it.  The existing definition of the /help query doesn't respond with anything formal for automatic consumption by software clients for the purpose of auto-discovery.  

-- 
 
JG



James Gould
Fellow Engineer
jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 7/19/22, 11:10 AM, "Andrew Newton" <andy@hxr.us> wrote:

    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?

    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

v2.23.0 | Report a Bug | By Email