IETF Logo Mail Archive

Re: [regext] CALL FOR ADOPTION: draft-loffredo-regext-rdap-jcard-deprecation-03

Jasdip Singh <jasdips@arin.net> Fri, 29 January 2021 14:13 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 973F93A0D21 for <regext@ietfa.amsl.com>; Fri, 29 Jan 2021 06:13:23 -0800 (PST)
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 w-0IbWRqMSOz for <regext@ietfa.amsl.com>; Fri, 29 Jan 2021 06:13:22 -0800 (PST)
Received: from smtp2.arin.net (smtp2.arin.net [IPv6:2001:500:110:201::52]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 423433A0D24 for <regext@ietf.org>; Fri, 29 Jan 2021 06:13:22 -0800 (PST)
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 smtp2.arin.net (Postfix) with ESMTPS id 863591075817; Fri, 29 Jan 2021 09:13:19 -0500 (EST)
Received: from CAS02CHA.corp.arin.net (10.1.30.63) by CAS02CHA.corp.arin.net (10.1.30.63) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Fri, 29 Jan 2021 09:11:43 -0500
Received: from CAS02CHA.corp.arin.net ([fe80::70b5:fa43:96a0:efad]) by CAS02CHA.corp.arin.net ([fe80::70b5:fa43:96a0:efad%17]) with mapi id 15.00.1104.000; Fri, 29 Jan 2021 09:11:42 -0500
From: Jasdip Singh <jasdips@arin.net>
To: "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org>, "galvin@elistx.com" <galvin@elistx.com>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [regext] CALL FOR ADOPTION: draft-loffredo-regext-rdap-jcard-deprecation-03
Thread-Index: AQHW7aYlYYsQWWNe/ka1fW+689mTlao++quA//+70QA=
Date: Fri, 29 Jan 2021 14:11:42 +0000
Message-ID: <46AB9039-72A7-4A2D-BF82-E320EE44F2D7@arin.net>
References: <3163EFC6-C1B4-43E4-A24D-BF3F8410FE2A@elistx.com> <d081a5bbb1fb4553b9ea212843f45126@verisign.com>
In-Reply-To: <d081a5bbb1fb4553b9ea212843f45126@verisign.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: <02BF8FA1CA96E047959D05D6E8659E86@corp.arin.net>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/QaREFXrABAz8pfQjUTRj9YmxSbk>
Subject: Re: [regext] CALL FOR ADOPTION: draft-loffredo-regext-rdap-jcard-deprecation-03
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, 29 Jan 2021 14:13:24 -0000

Interesting point, Scott. Adopting JSContact (and deprecating jCard eventually) seems a tradeoff between ease-of-implementation for future servers/clients and diminishing returns for the current servers/clients. Should the latter (diminishing returns) prevent the former (easy-of-implementation)? It may help to gauge what other protocols have done in the past when presented with such a trade-off.

Jasdip  

On 1/29/21, 8:16 AM, "regext on behalf of Hollenbeck, Scott" <regext-bounces@ietf.org on behalf of shollenbeck=40verisign.com@dmarc.ietf.org> wrote:

    > -----Original Message-----
    > From: regext <regext-bounces@ietf.org> On Behalf Of James Galvin
    > Sent: Monday, January 18, 2021 9:29 AM
    > To: REGEXT WG <regext@ietf.org>
    > Subject: [EXTERNAL] [regext] CALL FOR ADOPTION: draft-loffredo-regext-
    > rdap-jcard-deprecation-03
    > 
    > Caution: This email originated from outside the organization. Do not click links
    > or open attachments unless you recognize the sender and know the content
    > is safe.
    > 
    > This is a formal adoption request for “Using JSContact in Registration Data
    > Access Protocol (RDAP) JSON Responses”:
    
    While I understand the motivation for this draft, I'm a little worried that it's trying to solve a problem that is no longer a problem for anyone who has completed a jCard implementation. At this point, RDAP implementations with jCard are quite widespread among registries, registrars, and RIRs.  
    
    Yes, we've heard that jCard can be cumbersome or tedious to implement, but once that work is done, an implementer has something that works.  Due to the nature of the problem domain, it is stable and doesn't require maintenance. 
    
    While an implementation involving jSContact would certainly be more elegant from a technical perspective, I see limited value in developing a specification that would imply re-doing what has already been implemented to produce something that does basically the same thing. There must be some material benefit for implementers (of both servers and then clients) to offset the development and deployment cost of re-implementing the contact representation. Section 2 of the draft describes differences from jCard - are they enough to justify this investment?
    
    Scott
    _______________________________________________
    regext mailing list
    regext@ietf.org
    https://www.ietf.org/mailman/listinfo/regext

v2.23.0 | Report a Bug | By Email