Hi James,
thanks a lot for your feedback.
My comments are below.
Il 02/03/2022 14:01, Gould, James ha scritto:
Mario,
Thank you for sharing the draft. We implemented EPP/HTTPS in parallel
with EPP/TLS a while back for many years. In the end, there were very
few registrars that chose to use EPP/HTTPS, so it was shutdown. I’m
not sure at this point whether there is hunger from the registrars to
implement EPP/HTTPS.
[ML] Maybe one reason against the implementation of EPP over HTTP thus
far has been the lack of a specification about it :-)
I believe that, especially for those registries accostumed to develop
their systems in-house, EPP over HTTP can be more straightforward than
EPP over TCP.
Implementers are normally more knowledgeable about REST programming than
TCP sockets and web services can benefit from a lot of open-source
software managing automatically some features and providing support for
many others.
In reviewing the draft, one difference with our EPP/HTTPS
implementation is that establishing the HTTPS session was separate
from establishing the EPP session, like what is done with TLS. The
HTTPS session was established with returning the greeting, and the
only EPP command that impacted the HTTPS session was the logout
command by dropping the HTTPS session, like the logout command
dropping the TLS connection on the server-side. By not mixing the EPP
commands with the underlying transport, it was possible to configure
the transport (TLS or HTTPS) on the client-side, as was done in our
EPP SDK. My recommendation is to ensure to keep the transport purely
a transport and not have the login command intermingled with the HTTPS
session.
[ML] My opinion is that the approach described in the draft is still
compliant with RFC 5730.
Section 2.9.1 states that the EPP command starting a session is <login>
which appears to me also consistent with the fact that every session in
a REST service is established after a successful authentication phase.
Neither It seems to me that the proposal mixes the EPP commands with the
underlying transport. On the contrary, mapping an EPP session onto an
HTTP session makes the application layer completely independent on the
physical layer, for sure more independent than EPP over TCP.
One other difference was the use of the media type “text/xml” instead
of defining a new one with “application/epp+xml”.
[ML] Just realized that the "application/epp+xml" was already defined by
RFC 5730. I missed that . I'll remove the section regarding the media
type from the document.
The EPP packet length was set with the “Content-Length” header along
with relying on the HTTP keep-alive, which is consistent.
[ML] Don't think that strictly relying on the HTTP keep-alive feature is
good, especially in a load balancing scheme.
Anyway, I have booked a slot at next meeting to present the proposal. So
we can have time for a live discussion.
Best,
Mario
--
JG
*James Gould
*Fellow Engineer
jgo...@verisign.com
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgo...@verisign.com>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/>
*From: *regext <regext-boun...@ietf.org> on behalf of Mario Loffredo
<mario.loffr...@iit.cnr.it>
*Date: *Wednesday, March 2, 2022 at 6:47 AM
*To: *"regext@ietf.org" <regext@ietf.org>
*Subject: *[EXTERNAL] [regext] Fwd: New Version Notification for
draft-loffredo-regext-epp-over-http-00.txt
Hi folks,
Just posted a draft about EPP over HTTP. It aims to define rules for
the EPP implementations leveraging HTTP due to its simplicity and ease
of use.
The proposal preserves EPP commands semantics as HTTP is used merely
for transportation.
The appendix includes possible strategies about how to implement load
balancing in this context.
Even if EPP is largely implemented over TCP, some HTTP based
implementations exist and a standardization would be advisable.
Feedback is welcome and appreciated.
Best,
Mario
-------- Messaggio Inoltrato --------
*Oggetto: *
New Version Notification for draft-loffredo-regext-epp-over-http-00.txt
*Data: *
Wed, 02 Mar 2022 03:16:34 -0800
*Mittente: *
internet-dra...@ietf.org
*A: *
Jan Romanowski <jan.romanow...@nask.pl>
<mailto:jan.romanow...@nask.pl>, Lorenzo Luconi Trombacchi
<lorenzo.luc...@iit.cnr.it> <mailto:lorenzo.luc...@iit.cnr.it>,
Lorenzo Trombacchi <lorenzo.luc...@iit.cnr.it>
<mailto:lorenzo.luc...@iit.cnr.it>, Marcin Machnio <i...@dns.pl>
<mailto:i...@dns.pl>, Mario Loffredo <mario.loffr...@iit.cnr.it>
<mailto:mario.loffr...@iit.cnr.it>, Maurizio Martinelli
<maurizio.martine...@iit.cnr.it> <mailto:maurizio.martine...@iit.cnr.it>
A new version of I-D, draft-loffredo-regext-epp-over-http-00.txt
has been successfully submitted by Mario Loffredo and posted to the
IETF repository.
Name: draft-loffredo-regext-epp-over-http
Revision: 00
Title: Extensible Provisioning Protocol (EPP) Transport over HTTP
Document date: 2022-03-02
Group: Individual Submission
Pages: 15
URL:
https://www.ietf.org/archive/id/draft-loffredo-regext-epp-over-http-00.txt
<https://secure-web.cisco.com/1f30dq890q6OrF7oLq92m2FwCsaQYGofA9g5UVFZlHkmN0w_yAnbxq9DW0cng9yq1vWPgqDHusaG7I_pd7Fj4HY4k3E12N2lZ1KQR3XYcBxZ4Fuq9uL9cyPCZGPD3SOU9UVMWBvgLccCqeZcoPppgb79gEzOCSU6xUIxnQSxEIOdQ2IKNsK1iLRDUhVmqdA8sjpP4A2mavGo2L5DF-Rx07Nx3vWgTgiFN-5fKLapEn2ndXKhlxVnDE0uw7Et2CWck/https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-loffredo-regext-epp-over-http-00.txt>
Status:
https://datatracker.ietf.org/doc/draft-loffredo-regext-epp-over-http/
<https://secure-web.cisco.com/1e-EzKBW4F-ke3YB-EbSecmjRZQjNyGt_AMB9DoqHhXoy2emw5WScEOrERmcHKLufTmxRFNsSsmi2oDZHMu2PosarH3O8FtwH1h7eWpFvAWPvg_TxYpepR-EMI0eWP6gZukKJFDy0UrW-9LO27dgrGaoRyo53ZYM_1bvPZL3semd5_mD2xUD09Tx-pBTyR3lqjDXTV2_g_62iZ27ixUHPJNt6mDbIwagHhxDOeQByS1qTEuJMznqU19N9rhdi_JV4/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-loffredo-regext-epp-over-http%2F>
Htmlized:
https://datatracker.ietf.org/doc/html/draft-loffredo-regext-epp-over-http
<https://secure-web.cisco.com/1wiuZNeJDCZOU0TRLJxGBsMS3mMMkykHo-jJZpWgFbcjOdAwcTy9S0z2HvH9BdlOc063zPjm2eB0NDa3UBBVvNeZ3TdDbuj5ewbxTjc-VWO2ctIq10oOq_toZDXhDx-I469jfy6dBn3OxeBJfSQctig1xhdc5gOJlsHzlfbxkntqMg14jsEigdNdcXuV5YqBxO4d8vMNPugQX3z3bk-gE4ETukCyRhHsOIlM6DRumLe5OUtqKX74_yIT5Oc-ZoD0C/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-loffredo-regext-epp-over-http>
Abstract:
This document describes how the Extensible Provisioning Protocol
(EPP) is mapped over the Hypertext Transfer Protocol (HTTP). This
mapping requires the use of the Transport Layer Security (TLS)
protocol to protect information exchanged between an EPP client and
an EPP server.
The IETF Secretariat
--
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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
