Re: [regext] EAI in EPP from a registrar point of view

Taras Heichenko <tasic@academ.kiev.ua> Fri, 20 November 2020 20:22 UTC

Return-Path: <tasic@academ.kiev.ua>
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 1E4633A10E3; Fri, 20 Nov 2020 12:22:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 egc0S6Afaw3C; Fri, 20 Nov 2020 12:22:05 -0800 (PST)
Received: from academ.kiev.ua (academ.kiev.ua [194.143.145.237]) (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 BE1F73A10E2; Fri, 20 Nov 2020 12:22:04 -0800 (PST)
Received: from [10.0.3.72] by academ.kiev.ua with esmtpsa (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94 (FreeBSD)) (envelope-from <tasic@academ.kiev.ua>) id 1kgCun-00044J-NL; Fri, 20 Nov 2020 22:21:59 +0200
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.20.0.2.21\))
From: Taras Heichenko <tasic@academ.kiev.ua>
In-Reply-To: <1546999d-5f9d-29e1-dbcc-c9f5c198be8a@knipp.de>
Date: Fri, 20 Nov 2020 22:21:52 +0200
Cc: "Hollenbeck, Scott" <shollenbeck=40verisign.com@dmarc.ietf.org>, "regext@ietf.org" <regext@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <844F0BE7-9978-486F-858E-DBF981713E51@academ.kiev.ua>
References: <CADqLbz+VPXYAgrCQY9g-0_vuUxioY7H6GApt4ek2u3gJHXqMPg@mail.gmail.com> <b1b6d23d272f4540aee047911992093b@verisign.com> <24320259-8CB2-404A-8C5E-AC9B02E1A8FE@academ.kiev.ua> <2fab0d51b573476d886fd93803a46f5e@verisign.com> <07B00DB7-4B46-43CF-A107-EE371166AFEC@academ.kiev.ua> <ccba89a963434c569685a3623dcd2f23@verisign.com> <322968FB-513F-42B9-B786-BA8FDFE14085@academ.kiev.ua> <1546999d-5f9d-29e1-dbcc-c9f5c198be8a@knipp.de>
To: Klaus Malorny <Klaus.Malorny@knipp.de>
X-Mailer: Apple Mail (2.3654.20.0.2.21)
X-Spam-Score_int: [academ.kiev.ua] -28
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/myWUkJKq9wWGJLWR8LeWduMjkgM>
Subject: Re: [regext] EAI in EPP from a registrar point of view
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, 20 Nov 2020 20:22:07 -0000


> On 20 Nov 2020, at 19:32, Klaus Malorny <Klaus.Malorny@knipp.de> wrote:
> 
> On 20.11.20 14:37, Taras Heichenko wrote:
>>> Right - it's a lot MORE work.
>> Let's ask Klaus what takes more developer's work, changing namespace, or adding the extension generation and parsing.
>> (In the neighbor thread Klaus wrote that his company is developing EPP software.)
> 
> Hi,
> 
> well, for the first case our EPP toolkit already allows the use of the domain, host and contact objects with different XML namespaces. The changes would mostly comprise creating subclasses for the respective commands and responses that simply override the previous (RFC 5733) namespace, since the schema would not change. This is less work than creating a brand new extension.
> 
> For the registrar system, I would have to introduce a configuration parameter to select EAI support in any case. For the login process, the work would also be more or less the same. For the code actually issuing the contact commands only changes for the creation of the toolkit objects would be required in the first case, whereas the extension version would require additional logic to create the extension resp. check for the presence of the extension and fiddle around with it. This is some more work and an additional source of bugs.
> 
> For the namespace solution, when some time in the future all supported registries have phased out the RFC 5733 contact object, I could clean up my code. In contrast, the code for the extension would stay forever and clutter up my code.

Thank you for your answers. You entirely confirmed my thoughts about these issues.

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

--
Taras Heichenko
tasic@academ.kiev.ua