Re: [regext] Comments to the feedback about epp-over-http

"Thomas Corte (TANGO support)" <Thomas.Corte@knipp.de> Thu, 31 March 2022 12:36 UTC

Return-Path: <Thomas.Corte@knipp.de>
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 751703A1129 for <regext@ietfa.amsl.com>; Thu, 31 Mar 2022 05:36:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level:
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QhNTYuuSrTF5 for <regext@ietfa.amsl.com>; Thu, 31 Mar 2022 05:36:37 -0700 (PDT)
Received: from kmx5a.knipp.de (kmx5a.knipp.de [195.253.6.99]) (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 B86BD3A10CB for <regext@ietf.org>; Thu, 31 Mar 2022 05:36:37 -0700 (PDT)
Received: from hp9000.do.knipp.de (hp9000.do.knipp.de [195.253.2.54]) by kmx5a.knipp.de (Postfix) with ESMTP id 4KTjTv0P2Vz4vDh; Thu, 31 Mar 2022 14:36:35 +0200 (CEST)
Received: from [195.253.2.191] (dhcp191.intra.dtm.knipp.de [195.253.2.191]) by hp9000.do.knipp.de (Postfix) with ESMTP id E6BDB7260F; Thu, 31 Mar 2022 14:36:34 +0200 (MESZ)
Message-ID: <8346151e-acc1-8e9a-f8ce-ac4d2f6a8dac@knipp.de>
Date: Thu, 31 Mar 2022 14:36:34 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.7.0
Content-Language: en-US
To: regext@ietf.org
References: <0843A6FD-79B8-45B9-BE58-0BCED21C19B0@verisign.com> <1b87995b-700b-0d16-1241-c69cf142c3f7@iit.cnr.it>
Cc: support@tango-rs.com
From: "Thomas Corte (TANGO support)" <Thomas.Corte@knipp.de>
In-Reply-To: <1b87995b-700b-0d16-1241-c69cf142c3f7@iit.cnr.it>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Rspamd-Queue-Id: 4KTjTv0P2Vz4vDh
X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:8391, ipnet:195.253.0.0/16, country:DE]; LOCAL_WL_IP(0.00)[195.253.2.54]
Authentication-Results: kmx5a.knipp.de; none
X-Rspamd-Pre-Result: action=no action; module=multimap; Matched map: LOCAL_WL_IP
X-Rspamd-Server: v1117
X-Spamd-Bar: /
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/EIVl8Ti-dOP1OPNAXQ_RDpjMwGA>
Subject: Re: [regext] Comments to the feedback about epp-over-http
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: Thu, 31 Mar 2022 12:36:43 -0000

Hello Mario,

On 3/31/22 13:52, Mario Loffredo wrote:

> Hi James,
> 
> For what I have understood, your implementation is based on the 
> assumption that once the HTTP Connection is established, it is used for 
> the transit of all the HTTP requests of an EPP session, starting from the 
> Login and ending with the Logout.
> 
> Consequently, you rely on keeping the HTTP connection alive as long as 
> the EPP session works. Correct?
> 
> If so, in my opinion, that is a wrong assumption.
> 
> Clients should not be forced to keep alive the HTTP connections if HTTP 
> allows to maintain HTTP sessions alive across a sequence of HTTP  
> connections.
> ...

I might be wrong (it was hard to follow the entire discussion, mostly due 
to the lack of consistent e-mail quoting in the thread), but I don't 
think there really any disagreement here between James and you.

As James speaks of HTTP Session Cookies in many places, I don't think 
he's suggesting that the connection management should be required to make 
use of any HTTP keepalive features. Instead, I think that you're both 
agreeing that the EPP "session" over HTTP is simply managed by an initial 
cookie given to the client, which he'll need to send along with any 
subsequent request to indicate that it belong to the same session. This 
also means that, unlike with TCP, an EPP session over HTTP can indeed 
survice a server restart, as long as the server can retrieve sessions 
from permanent storage after its restart.

I think the only point of contention here is when exactly the cookie is 
supposed to be returned by the server, namely

a) at the time the very first request without a session cookie is 
received (i.e., when the EPP client sends a <hello>?) OR
b) only after the first <login> command is received with correct credentials

My preference would be a) as it more closely resembles the TCP transport 
(where the connection itself is established before the first valid <login>).

Best regards,

Thomas

-- 
TANGO REGISTRY SERVICES® is a product of:
Knipp Medien und Kommunikation GmbH
Technologiepark                             Phone: +49 231 9703-222
Martin-Schmeisser-Weg 9                       Fax: +49 231 9703-200
D-44227 Dortmund                       E-Mail: support@tango-rs.com
Germany