[regext] Fwd: Fwd: New Version Notification for draft-loffredo-regext-epp-over-http-02.txt

Mario Loffredo <mario.loffredo@iit.cnr.it> Fri, 24 June 2022 16:15 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 31FA3C15CF4A for <regext@ietfa.amsl.com>; Fri, 24 Jun 2022 09:15:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.907
X-Spam-Level:
X-Spam-Status: No, score=-1.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, 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
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 pHCMQVKW0Oof for <regext@ietfa.amsl.com>; Fri, 24 Jun 2022 09:15:09 -0700 (PDT)
Received: from smtp.iit.cnr.it (mx4.iit.cnr.it [146.48.58.11]) by ietfa.amsl.com (Postfix) with ESMTP id 0D0EDC157B53 for <regext@ietf.org>; Fri, 24 Jun 2022 09:15:08 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by smtp.iit.cnr.it (Postfix) with ESMTP id 8EE91B8100A for <regext@ietf.org>; Fri, 24 Jun 2022 18:15:05 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at mx4.iit.cnr.it
Received: from smtp.iit.cnr.it ([127.0.0.1]) by localhost (mx4.iit.cnr.it [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tMoQ5ZHWczpU for <regext@ietf.org>; Fri, 24 Jun 2022 18:14:59 +0200 (CEST)
Received: from [192.12.193.108] (pc-loffredo.staff.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 25FC0B81004 for <regext@ietf.org>; Fri, 24 Jun 2022 18:14:59 +0200 (CEST)
Content-Type: multipart/alternative; boundary="------------6ch5e9eyDB8fjxOeBvJlfwJ4"
Message-ID: <c205bb79-0fc1-e68b-57f1-7aa02495d2da@iit.cnr.it>
Date: Fri, 24 Jun 2022 18:12:38 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.10.0
References: <9a155165-f925-e007-816b-9d108a3daf78@iit.cnr.it>
To: "regext@ietf.org" <regext@ietf.org>
From: Mario Loffredo <mario.loffredo@iit.cnr.it>
In-Reply-To: <9a155165-f925-e007-816b-9d108a3daf78@iit.cnr.it>
X-Forwarded-Message-Id: <9a155165-f925-e007-816b-9d108a3daf78@iit.cnr.it>
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/LMS4QeJ2MlkTpYMu_MKvReHkyZQ>
Subject: [regext] Fwd: Fwd: New Version Notification for draft-loffredo-regext-epp-over-http-02.txt
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: Fri, 24 Jun 2022 16:15:13 -0000

Sorry, I forgot to reply to all ;-)



-------- Messaggio Inoltrato --------
Oggetto: 	Re: [regext] Fwd: New Version Notification for 
draft-loffredo-regext-epp-over-http-02.txt
Data: 	Fri, 24 Jun 2022 18:11:37 +0200
Mittente: 	Mario Loffredo <mario.loffredo@iit.cnr.it>
A: 	Patrick Mevzek <pm@dotandco.com>



Hi Patrick,

thanks for having shared yout thoughts.

Please find my comments below.

Il 21/06/2022 22:51, Patrick Mevzek ha scritto:
> On Tue, Jun 21, 2022, at 15:09, Eduardo Duarte wrote:
>> EPP is about 20 years old and I
>> think it needs some reshaping to the actual Internet state.
> Is the EPP *transport* really where people struggle most? Ok, XML over 
> TLS might not be the current trendy couple in Internet circles, but 
> among all the problems I see in EPP (having worked both on registrar 
> and registry side), I really do not have the transport in my top 10.
> The plethora of extensions to do the same thing, and the various 
> "quality" of extensions is more of a concern to me, as well as the 
> non-existent discoverability of features (there is one extension 
> solving part of the problem, not used by everyone). Or the lack of 
> standardization in error codes/messages/details extended from core 
> case. Or the now not good enough design of a contact. Or operations 
> being mixed where they shouldn't (like restore in update).
>
> We barely arrived only a few months ago to have "fees" finally being a 
> standard... and it
> will take years before all registries switch to it. This is certainly 
> where registrars struggle more than just having to use a TLS "socket" 
> (I count around 28 versions of the fees document, for 18 different XML 
> namespaces with more than a couple of them really used in the wild).
>
> Said differently, the transport part seems to me really the easy part 
> of the problem of EPP viewed globally. Of course, if that blocks some 
> actors, then the working group is certainly the relevant place to find 
> out a standardized solution, but will really a lot of registries 
> suddenly switch to it just for the sake of switching to it?
>
> Or: what EPP over TCP and/or a REST redesign really add as new 
> features, solving current problems? Besides "it looks similar to the 
> rest of the Internet, so it will attract more/better programmers" (a 
> statement I would certainly have an hard time to believe) or "the 
> crappy hosting I am using only allows HTTPS servers/clients and 
> nothing else, so now I have to adapt my whole word just because I 
> chose a bad system from the beginning".
>
> Just my personal views of course.

I agree with you that there are EPP issues that probably need to be 
fixed with higher priority. However, some registries using EPP over HTTP 
exist and, since RFC 5730 admits other transport than TCP, it seems 
logical to me to define the specification for another mapping currently 
in use.

The proposal doesn't aim to be the panacea to all of the EPP problems 
but just the attempt to regulate an existing practice.

Nevertheless, the authors believe that mapping EPP over HTTP could 
result in some benefits (those described In the introductiuon and the 
appendix) on both client and server side.

Best,

Mario

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