Hi Ben,
Il 04/02/2026 20:39, Ben Schwartz ha scritto:
RFC 8484 DoH was prepared with careful attention to BCP 56, so I hope
it won't be used as an argument for ignoring BCP 56.
As an example of why BCP 56 is important, the current EPP-over-HTTPS
draft uses POST requests to signal "login" and "logout" commands, with
the intervening POST requests being part of this session. However, in
typical large-scale HTTP gateways, requests issued on a single
connection are commonly forwarded to distinct backend servers (i.e.
"load balancing"). A naive implementation of this protocol would seem
likely to fail in such a deployment, with the "login", "command", and
"logout" requests all being forwarded to distinct servers.
.it has been running the EPP server over HTTPS since 2009. We opted for
EoH to take advantage from being independent on TCP. We've explored
every solution for managing HTTP sessions on a load-balancing
architecture, from sticky sessions to outsourcing session management to
a Redis cluster. The latter solution offers us maximum flexibility,
scalability, and fault tolerance and implement load balancing very
efficiently.
I am not sure I understand the concern about HTTP CONNECT. However, I
do agree that the CONNECT method is not as widely supported as POST on
HTTP CDNs. If the goal is to benefit from the performance,
monitoring, control, and defense capabilities of major HTTP CDNs,
while minimizing changes to the EPP protocol, I think an
EPP-over-WebSocket specification would likely be a better solution.
My opinion is that WebSocket would not be the right solution, at least
not as efficient as traditional HTTP connections, since WebSocket
connections between client and server are stateful and long-lived via
the load balancer.
In this scenario, sticky sessions would be the only option to implement
load balancing for WebSocket, but based on our nearly twenty years of
experience and also widely described in literature, this wouldn't
balance the load efficiently and would require addressing some
additional issues, such as maintaining connection limits, keeping the
service up during maintenance operations, and handling a huge volume of
requests.
Best,
Mario
--Ben Schwartz
------------------------------------------------------------------------
*From:* Pawel Kowalik
*Sent:* Tuesday, February 3, 2026 11:39 AM
*To:* Gould, James; [email protected]
*Cc:* [email protected]; [email protected];
[email protected]
*Subject:* Re: [regext] Re: draft-ietf-regext-epp-https-02 early
Httpdir review
Hi Jim,
I see it the same way as you do, that the use of http in EoH to
"tunnel" EPP payloads is equivalent to the use of http in DoH RFC 8484.
HTTP CONNECT would fail to fulfil design objectives of this extension
(more cloud friendly deployment).
Mark's proposals are reasonable and understandable, however we had
this discussion in REGEXT already, that such radical change to map all
EPP commands to http semantics would require a major rework to the
protocol, which would not be RFC 5730 EPP anymore, but something else.
This is where we started the work on RPP, as an approach fully
leveraging on http and following recommendations of BCP56.
BCP56 in Section 2 is quite direct in saying that either you use http
and BCP56 applies, or if not then define something else and don't call
it http. It's quite a hard call.
On the flip side BCP56 contains few normative MUST/MUST NOTs and I
think it is worth a review which of them, if any, are indeed violated
and whether the draft could address them better.
Kind Regards,
Pawel
On 03.02.26 16:06, Gould, James wrote:
I'm following up to my prior response for the REGEXT working group
to weigh in on this. I believe that draft-ietf-regext-epp-https
(EoH) does not apply to BCP56, since it's defining a transport for
an existing application protocol, just like DNS over HTTP (DoH) in
RFC 8484. The goal of EoH is to provide a Cloud-friendly
transport for the EPP application protocol that is compliant with
section 2.1 of RFC 5730. The definition of Cloud-friendly was
provided in the prior message below. Please review the draft and
provide your feedback, since the draft is ready for WGLC using the
current approach. Thanks,
-- JG James Gould Fellow Engineer [email protected]
<mailto:[email protected]>
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
<mailto:applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com
<http://verisigninc.com/> <http://verisigninc.com/> On 1/5/26,
1:10 PM, "Gould, James" <[email protected]
<mailto:[email protected]> <mailto:[email protected]>
<mailto:[email protected]>> wrote: Mark, Thank you for your
reply. In reviewing Section 2 of BCP56,
draft-ietf-regext-epp-https (EoH) is using HTTP, but EoH is not
defining a new application protocol. I don't believe EoH is
applicable to BCP56, since it's defining a HTTP transport for an
existing application protocol of EPP. How would DNS over HTTP
(DoH) in RFC 8484 apply to BCP56, since it defines an HTTP
transport for an existing application protocol of DNS? I realize
that DoH was defined prior to BCP56, but would you have the same
recommendation of using the CONNECT HTTP method over GET and POST?
If we did agree that BCP56 was applicable, can you provide a list
of BCP56 violations with EoH? Cloud-friendly means that an EoH can
be deployed to a public cloud provider without the need to build a
custom gateway, like is the case of the existing EoT in RFC 5734.
The CONNECT method wouldn't work with a L7 load balancer, which
would be the main advantage of using EoH in a cloud environment.
EoH makes EPP sessions independent of TCP connections. Along with
using a L7 load balancer, it makes an EPP server more flexible,
scalable and fault tolerant. Thanks,
-- JG James Gould Fellow Engineer [email protected]
<mailto:[email protected]> <mailto:[email protected]>
<mailto:[email protected]>
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]
<mailto:applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
<mailto:[email protected]> <mailto:[email protected]>>
703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com
<http://verisigninc.com/> <http://verisigninc.com/>
<http://verisigninc.com/>> <http://verisigninc.com/>> On
12/29/25, 7:57 PM, "Mark Nottingham" <[email protected]
<mailto:[email protected]> <mailto:[email protected]>
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]>
<mailto:[email protected]>>> wrote: Caution: This email originated
from outside the organization. Do not click links or open
attachments unless you recognize the sender and know the content
is safe. Hi James, Regarding whether you're building a protocol
with HTTP, see Section 2 of BCP56. If you don't fit those
criteria, it indeed isn't using HTTP, but your draft isn't clear
about that. The approach you've taken is to tunnel the protocol
over POST. As I said, the safer, better approach if your intent is
to tunnel would be to use HTTP's dedicated tunnelling method,
CONNECT. HTTP is not a transport protocol, it's a representation
transfer protocol. There are many benefits to using it well,
including operability, scalability, and security improvements -
ones that may not be apparent immediately but are likely to be
appreciated in time (at least, that's our experience in deploying
many HTTP-based protocols). What does "cloud-friendly" mean? Cheers,
On 2 Dec 2025, at 1:36 am, Gould, James <[email protected]
<mailto:[email protected]> <mailto:[email protected]>
<mailto:[email protected]> <mailto:[email protected]
<mailto:[email protected]> <mailto:[email protected]>
<mailto:[email protected]>>> wrote: Mark, Thank you for
reviewing draft-ietf-regext-epp-https. Can you provide a list
of BCP56 violations with draft-ietf-regext-epp-https? What's
important to understand with EoH (draft-ietf-regext-epp-https)
is that it's not building a protocol with HTTP but defining an
application packet protocol transport based on an existing
IETF standard protocol. The only HTTP actions needed as a
packet protocol transport is to establish a stateful session
and to push packets. Intermingling the application packet
protocol semantics with the HTTP semantics by mapping the EPP
command types to HTTP methods adds complexity with no defined
benefit. Use of the CONNECT method doesn't match the intent of
enabling EPP to be Cloud-friendly, since CONNECT is a
specialized method that creates a pure tunnel (e.g., having
EoT tunnel through HTTP). Can you clarify the interoperability
concerns? Thanks, -- JG James Gould Fellow Engineer
[email protected] <mailto:[email protected]>
<mailto:[email protected]> <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected]> <mailto:[email protected]>>
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]
<mailto:applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
<mailto:[email protected]> <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected]> <mailto:[email protected]>>>
703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com
<http://secure-web.cisco.com/1HBfWxc3rSLo8-JlnTCv8UuQJ7L33Ftu57xslVdB9Dl9hGo6XcCGaOcAIRKpaTtwnGNTDjmlvH5qvxtvnCphtQWCoygFXoTczFrh7uwiE1uE1vsZpXMnKUP0ejMM-fNayWZt038WfcGMPuytMu-3WI5BsWFoQkUOPDQz5mBV9MYB_Z2VliIwLnrNwjdeG0l3cftzkKIFO036cnjxMj7yRyTYHkEpSoX6HsHuocCWFVS9T3ENS8o2o-uTSRtVcWd6Zxt41OOO2F4hw9URThTqjn1pYp_dvdtC1NbbPbIKXpP4/http%3A%2F%2Fverisigninc.com%2F>
<http://secure-web.cisco.com/1HBfWxc3rSLo8-JlnTCv8UuQJ7L33Ftu57xslVdB9Dl9hGo6XcCGaOcAIRKpaTtwnGNTDjmlvH5qvxtvnCphtQWCoygFXoTczFrh7uwiE1uE1vsZpXMnKUP0ejMM-fNayWZt038WfcGMPuytMu-3WI5BsWFoQkUOPDQz5mBV9MYB_Z2VliIwLnrNwjdeG0l3cftzkKIFO036cnjxMj7yRyTYHkEpSoX6HsHuocCWFVS9T3ENS8o2o-uTSRtVcWd6Zxt41OOO2F4hw9URThTqjn1pYp_dvdtC1NbbPbIKXpP4/http%3A%2F%2Fverisigninc.com%2F>
<http://secure-web.cisco.com/1HBfWxc3rSLo8-JlnTCv8UuQJ7L33Ftu57xslVdB9Dl9hGo6XcCGaOcAIRKpaTtwnGNTDjmlvH5qvxtvnCphtQWCoygFXoTczFrh7uwiE1uE1vsZpXMnKUP0ejMM-fNayWZt038WfcGMPuytMu-3WI5BsWFoQkUOPDQz5mBV9MYB_Z2VliIwLnrNwjdeG0l3cftzkKIFO036cnjxMj7yRyTYHkEpSoX6HsHuocCWFVS9T3ENS8o2o-uTSRtVcWd6Zxt41OOO2F4hw9URThTqjn1pYp_dvdtC1NbbPbIKXpP4/http%3A%2F%2Fverisigninc.com%2F>>
<http://secure-web.cisco.com/1HBfWxc3rSLo8-JlnTCv8UuQJ7L33Ftu57xslVdB9Dl9hGo6XcCGaOcAIRKpaTtwnGNTDjmlvH5qvxtvnCphtQWCoygFXoTczFrh7uwiE1uE1vsZpXMnKUP0ejMM-fNayWZt038WfcGMPuytMu-3WI5BsWFoQkUOPDQz5mBV9MYB_Z2VliIwLnrNwjdeG0l3cftzkKIFO036cnjxMj7yRyTYHkEpSoX6HsHuocCWFVS9T3ENS8o2o-uTSRtVcWd6Zxt41OOO2F4hw9URThTqjn1pYp_dvdtC1NbbPbIKXpP4/http%3A%2F%2Fverisigninc.com%2F>>
<http://secure-web.cisco.com/1HBfWxc3rSLo8-JlnTCv8UuQJ7L33Ftu57xslVdB9Dl9hGo6XcCGaOcAIRKpaTtwnGNTDjmlvH5qvxtvnCphtQWCoygFXoTczFrh7uwiE1uE1vsZpXMnKUP0ejMM-fNayWZt038WfcGMPuytMu-3WI5BsWFoQkUOPDQz5mBV9MYB_Z2VliIwLnrNwjdeG0l3cftzkKIFO036cnjxMj7yRyTYHkEpSoX6HsHuocCWFVS9T3ENS8o2o-uTSRtVcWd6Zxt41OOO2F4hw9URThTqjn1pYp_dvdtC1NbbPbIKXpP4/http%3A%2F%2Fverisigninc.com%2F>>
<http://secure-web.cisco.com/1HBfWxc3rSLo8-JlnTCv8UuQJ7L33Ftu57xslVdB9Dl9hGo6XcCGaOcAIRKpaTtwnGNTDjmlvH5qvxtvnCphtQWCoygFXoTczFrh7uwiE1uE1vsZpXMnKUP0ejMM-fNayWZt038WfcGMPuytMu-3WI5BsWFoQkUOPDQz5mBV9MYB_Z2VliIwLnrNwjdeG0l3cftzkKIFO036cnjxMj7yRyTYHkEpSoX6HsHuocCWFVS9T3ENS8o2o-uTSRtVcWd6Zxt41OOO2F4hw9URThTqjn1pYp_dvdtC1NbbPbIKXpP4/http%3A%2F%2Fverisigninc.com%2F>>
<http://secure-web.cisco.com/1HBfWxc3rSLo8-JlnTCv8UuQJ7L33Ftu57xslVdB9Dl9hGo6XcCGaOcAIRKpaTtwnGNTDjmlvH5qvxtvnCphtQWCoygFXoTczFrh7uwiE1uE1vsZpXMnKUP0ejMM-fNayWZt038WfcGMPuytMu-3WI5BsWFoQkUOPDQz5mBV9MYB_Z2VliIwLnrNwjdeG0l3cftzkKIFO036cnjxMj7yRyTYHkEpSoX6HsHuocCWFVS9T3ENS8o2o-uTSRtVcWd6Zxt41OOO2F4hw9URThTqjn1pYp_dvdtC1NbbPbIKXpP4/http%3A%2F%2Fverisigninc.com%2F&gt;>>
<http://secure-web.cisco.com/1HBfWxc3rSLo8-JlnTCv8UuQJ7L33Ftu57xslVdB9Dl9hGo6XcCGaOcAIRKpaTtwnGNTDjmlvH5qvxtvnCphtQWCoygFXoTczFrh7uwiE1uE1vsZpXMnKUP0ejMM-fNayWZt038WfcGMPuytMu-3WI5BsWFoQkUOPDQz5mBV9MYB_Z2VliIwLnrNwjdeG0l3cftzkKIFO036cnjxMj7yRyTYHkEpSoX6HsHuocCWFVS9T3ENS8o2o-uTSRtVcWd6Zxt41OOO2F4hw9URThTqjn1pYp_dvdtC1NbbPbIKXpP4/http%3A%2F%2Fverisigninc.com%2F&gt;>>
On 11/30/25, 5:41 PM, "Mark Nottingham via Datatracker"
<[email protected] <mailto:[email protected]>
<mailto:[email protected]> <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected]> <mailto:[email protected]>>
<mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected]> <mailto:[email protected]>
<mailto:[email protected] <mailto:[email protected]>
<mailto:[email protected]> <mailto:[email protected]>>>> wrote:
Caution: This email originated from outside the organization.
Do not click links or open attachments unless you recognize
the sender and know the content is safe. Document:
draft-ietf-regext-epp-https Title: Extensible Provisioning
Protocol (EPP) Transport over HTTPS Reviewer: Mark Nottingham
Review result: Not Ready This draft violates many aspects of
BCP56, and needs substantial revision to address that. That's
because it's tunnelling a protocol over HTTP semantics
(primarily POST). Doing so prevents many benefits of using
HTTP from being realised and may cause deployment issues. I
would recommend mapping the semantics of EPP more faithfully
to HTTP -- e.g., <create> to PUT, <delete> to DELETE. This
would be a substantially new version of EPP but would be much
more integrated into the HTTP ecosystem. We can look for
volunteers from the HTTP community to help with this direction
if there's interest. Failing that, if the authors wish to
tunnel, they should do so using CONNECT rather than over HTTP
semantics (such as POST). The draft has other issues
(including interoperability concerns) that I won't list here
as the decision above needs to be made first.
-- Mark Nottingham
https://secure-web.cisco.com/1GIoLtqb3sFhOpgHUmBetlXn0_dCNquVEOjlzHhsHkwUuK_Mm1PHu3Qh-a4NP3z8LBKs92L6k7py3mE-yQoQnsqzfSyIRhcWCo4BwJCRWXKMErt6rSFq_vhjrljB1gWShCVbAGZHh2a7dmF58WckNp37FcRas-vQzGAgHkSeAvipWtl1DzLm_euZp79N5t6LdZ5rW2nyAwihaHsN3chtzDh1vBVodkpRMVaP2D0hkDHvXx6cT1rvpvHQ1QUo1woSOrMjJ-e6_tTB0JGUn0yhB5dJ_VgWpgptk8bifpxEYYEA/https%3A%2F%2Fwww.mnot.net%2F
<https://secure-web.cisco.com/1GIoLtqb3sFhOpgHUmBetlXn0_dCNquVEOjlzHhsHkwUuK_Mm1PHu3Qh-a4NP3z8LBKs92L6k7py3mE-yQoQnsqzfSyIRhcWCo4BwJCRWXKMErt6rSFq_vhjrljB1gWShCVbAGZHh2a7dmF58WckNp37FcRas-vQzGAgHkSeAvipWtl1DzLm_euZp79N5t6LdZ5rW2nyAwihaHsN3chtzDh1vBVodkpRMVaP2D0hkDHvXx6cT1rvpvHQ1QUo1woSOrMjJ-e6_tTB0JGUn0yhB5dJ_VgWpgptk8bifpxEYYEA/https%3A%2F%2Fwww.mnot.net%2F>
<https://secure-web.cisco.com/1GIoLtqb3sFhOpgHUmBetlXn0_dCNquVEOjlzHhsHkwUuK_Mm1PHu3Qh-a4NP3z8LBKs92L6k7py3mE-yQoQnsqzfSyIRhcWCo4BwJCRWXKMErt6rSFq_vhjrljB1gWShCVbAGZHh2a7dmF58WckNp37FcRas-vQzGAgHkSeAvipWtl1DzLm_euZp79N5t6LdZ5rW2nyAwihaHsN3chtzDh1vBVodkpRMVaP2D0hkDHvXx6cT1rvpvHQ1QUo1woSOrMjJ-e6_tTB0JGUn0yhB5dJ_VgWpgptk8bifpxEYYEA/https%3A%2F%2Fwww.mnot.net%2F>
<https://secure-web.cisco.com/1GIoLtqb3sFhOpgHUmBetlXn0_dCNquVEOjlzHhsHkwUuK_Mm1PHu3Qh-a4NP3z8LBKs92L6k7py3mE-yQoQnsqzfSyIRhcWCo4BwJCRWXKMErt6rSFq_vhjrljB1gWShCVbAGZHh2a7dmF58WckNp37FcRas-vQzGAgHkSeAvipWtl1DzLm_euZp79N5t6LdZ5rW2nyAwihaHsN3chtzDh1vBVodkpRMVaP2D0hkDHvXx6cT1rvpvHQ1QUo1woSOrMjJ-e6_tTB0JGUn0yhB5dJ_VgWpgptk8bifpxEYYEA/https%3A%2F%2Fwww.mnot.net%2F>
<https://secure-web.cisco.com/1GIoLtqb3sFhOpgHUmBetlXn0_dCNquVEOjlzHhsHkwUuK_Mm1PHu3Qh-a4NP3z8LBKs92L6k7py3mE-yQoQnsqzfSyIRhcWCo4BwJCRWXKMErt6rSFq_vhjrljB1gWShCVbAGZHh2a7dmF58WckNp37FcRas-vQzGAgHkSeAvipWtl1DzLm_euZp79N5t6LdZ5rW2nyAwihaHsN3chtzDh1vBVodkpRMVaP2D0hkDHvXx6cT1rvpvHQ1QUo1woSOrMjJ-e6_tTB0JGUn0yhB5dJ_VgWpgptk8bifpxEYYEA/https%3A%2F%2Fwww.mnot.net%2F>
<https://secure-web.cisco.com/1GIoLtqb3sFhOpgHUmBetlXn0_dCNquVEOjlzHhsHkwUuK_Mm1PHu3Qh-a4NP3z8LBKs92L6k7py3mE-yQoQnsqzfSyIRhcWCo4BwJCRWXKMErt6rSFq_vhjrljB1gWShCVbAGZHh2a7dmF58WckNp37FcRas-vQzGAgHkSeAvipWtl1DzLm_euZp79N5t6LdZ5rW2nyAwihaHsN3chtzDh1vBVodkpRMVaP2D0hkDHvXx6cT1rvpvHQ1QUo1woSOrMjJ-e6_tTB0JGUn0yhB5dJ_VgWpgptk8bifpxEYYEA/https%3A%2F%2Fwww.mnot.net%2F>
<https://secure-web.cisco.com/1GIoLtqb3sFhOpgHUmBetlXn0_dCNquVEOjlzHhsHkwUuK_Mm1PHu3Qh-a4NP3z8LBKs92L6k7py3mE-yQoQnsqzfSyIRhcWCo4BwJCRWXKMErt6rSFq_vhjrljB1gWShCVbAGZHh2a7dmF58WckNp37FcRas-vQzGAgHkSeAvipWtl1DzLm_euZp79N5t6LdZ5rW2nyAwihaHsN3chtzDh1vBVodkpRMVaP2D0hkDHvXx6cT1rvpvHQ1QUo1woSOrMjJ-e6_tTB0JGUn0yhB5dJ_VgWpgptk8bifpxEYYEA/https%3A%2F%2Fwww.mnot.net%2F>>
<https://secure-web.cisco.com/1GIoLtqb3sFhOpgHUmBetlXn0_dCNquVEOjlzHhsHkwUuK_Mm1PHu3Qh-a4NP3z8LBKs92L6k7py3mE-yQoQnsqzfSyIRhcWCo4BwJCRWXKMErt6rSFq_vhjrljB1gWShCVbAGZHh2a7dmF58WckNp37FcRas-vQzGAgHkSeAvipWtl1DzLm_euZp79N5t6LdZ5rW2nyAwihaHsN3chtzDh1vBVodkpRMVaP2D0hkDHvXx6cT1rvpvHQ1QUo1woSOrMjJ-e6_tTB0JGUn0yhB5dJ_VgWpgptk8bifpxEYYEA/https%3A%2F%2Fwww.mnot.net%2F>>
_______________________________________________ regext mailing
list -- [email protected] <mailto:[email protected]> To unsubscribe
send an email to [email protected] <mailto:[email protected]>
--
Dott. Mario Loffredo
Senior Technologist
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
Address: Via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
