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

Patrick Mevzek <pm@dotandco.com> Tue, 21 June 2022 20:53 UTC

Return-Path: <pm@dotandco.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 7DF96C15791C for <regext@ietfa.amsl.com>; Tue, 21 Jun 2022 13:53:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.11
X-Spam-Level:
X-Spam-Status: No, score=-2.11 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, 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=dotandco.com header.b=0glHrIx1; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=UJ0rdAqT
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 UrzRri2AD1Ht for <regext@ietfa.amsl.com>; Tue, 21 Jun 2022 13:53:41 -0700 (PDT)
Received: from wout4-smtp.messagingengine.com (wout4-smtp.messagingengine.com [64.147.123.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B3187C1527AF for <regext@ietf.org>; Tue, 21 Jun 2022 13:53:41 -0700 (PDT)
Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id DDB303200902 for <regext@ietf.org>; Tue, 21 Jun 2022 16:53:40 -0400 (EDT)
Received: from imap49 ([10.202.2.99]) by compute4.internal (MEProxy); Tue, 21 Jun 2022 16:53:41 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dotandco.com; h= cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; t=1655844820; x=1655931220; bh=yashmXLHqf /eyvDHf59p7WFZ1nf1JAzPawq9ZRVm+TY=; b=0glHrIx18lSB04fuSBymS3fQCn GD/UqWVvPnujkwKlkrcQnSVdj8w4KrUllIdh739oNQAUPnNH5coc6whSV4T4JO9/ kXVZoVRRJJg1xPswJXgtmq6hQXs5m5luiPRFa+KRAx4Hmd9xz0873qj5SQtCbqGL vZFr5LDY3WSS4Muad0lpOYwLE8VPs0c3i0qx9u3IHmmDtxdjXrJYEASSDzgDBojb M48JfFINEoVJy2eD1VbmDNg0EEHKVPvH/7CAFQyIgs+gw4hAMoahH67xiDvP+4MO AH27V6rTtN9cJVHl3gpIFnq7qD6h51rJ/Z91dYcJSLV86XccMG9G8h8jJVuw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm2; t=1655844820; x=1655931220; bh=yashmXLHqf/eyvDHf59p7WFZ1nf1 JAzPawq9ZRVm+TY=; b=UJ0rdAqTB2aJY/06PZY8ZlU1DlV/uROkVUoAEj6sI/xZ 1ZMHeUskLo+pB5F8UoiPsuq0q1r8NhhJ+B1K4Ntzms+RD3lU2GMWcYeVIU9Bl/gT nSYt9n69uuSDmo2NsL3Q36mSLz45qc+ItaYRrMKAMokZpUQ6BYii/+2Z/Rpj818c dYQNNVd3TyjENoadVmB5icfF0zvII2D3LEqm1mk1FhJUFW65kBQfyPlJRTvSyD9R QIjrkqy/FKn5iUkujDjbvZkzcSspxEhYFiXo5b1iGGHFBM+Wko+7PUnohb3Qn2Kx VuHSm7LJZ5spyEcsRJ6SSPnl9RSiMZCQCAUcZTsu3g==
X-ME-Sender: <xms:1C-yYrcYxgdUWiVZuy01kSfOXtefx52UAK-YcYip4EmaUhmD1ySDSAf1BL8> <xme:1C-yYhMMNwxIXzgEfNiULN6Q12hcFJ4Nkg7aDHg_DmC_Sz5hKAM0PGft_yqS7upJS K5AJwUAnL_8cWa2tA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvfedrudeffedgudehgecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecunecujfgurhepofgfggfkjghffffhvffutgesth dtredtreertdenucfhrhhomhepfdfrrghtrhhitghkucfovghviigvkhdfuceophhmsegu ohhtrghnuggtohdrtghomheqnecuggftrfgrthhtvghrnhepudfgffeiheffjeekudfhvd ekveffudefueeikeehueffjeefjeeiteeihedugfeknecuvehluhhsthgvrhfuihiivgep tdenucfrrghrrghmpehmrghilhhfrhhomhepphhmseguohhtrghnuggtohdrtghomh
X-ME-Proxy: <xmx:1C-yYkiOLTvXbR5WSdYi-GGTyhifKeahvlBPyqvx9WX8xj1gn5iSxQ> <xmx:1C-yYs-wff_3I6Do-x4hrPoPmSf9fF81GrvWiUqOqF6mRJ6E-dXRWQ> <xmx:1C-yYnsGdnLv9_Kshy7KEQQR8TySdV_gu0T32gAfX0JIAeaKbgxQPg> <xmx:1C-yYl5DptHgApskKVHnN0wWj5bAyuWFgZsfeyXvQWocuoVVC9sMsA>
Feedback-ID: i8d29425f:Fastmail
Received: by mailuser.nyi.internal (Postfix, from userid 501) id 2772E15A0080; Tue, 21 Jun 2022 16:53:40 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
User-Agent: Cyrus-JMAP/3.7.0-alpha0-713-g1f035dc716-fm-20220617.001-g1f035dc7
Mime-Version: 1.0
Message-Id: <9546f6aa-12cf-4aa2-aa37-e8e3b4a3bf7f@www.fastmail.com>
In-Reply-To: <b0eaef4c-561f-8521-551a-eab43b3c4d8a@dns.pt>
References: <165518968762.47341.9585661643895092316@ietfa.amsl.com> <fd16af67-b4d5-9ff6-2f3c-cacebc2c52bc@iit.cnr.it> <b0eaef4c-561f-8521-551a-eab43b3c4d8a@dns.pt>
Date: Tue, 21 Jun 2022 15:51:48 -0500
From: Patrick Mevzek <pm@dotandco.com>
To: regext@ietf.org
Content-Type: text/plain
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/txFFf2QOSE0t2K_1YvA2GtNRIPA>
Subject: Re: [regext] 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: Tue, 21 Jun 2022 20:53:46 -0000

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.

-- 
  Patrick Mevzek
  pm@dotandco.com