Pawel,
Thanks for your thoughts on this and I’m in agreement.
We have reviewed BCP 56 (RFC 9205) and have not found any areas of
non-compliance. The scope of BCP 56 (RFC 9205) is “This document
specifies best practices for writing specifications that use HTTP to
define new application protocols.” from the abstract and “It is
written primarily to guide IETF efforts to define application
protocols using HTTP for deployment on the Internet but might be
applicable in other situations.” from the Introduction. Section 2
defines where HTTP is being used, which is not in question when it
comes to draft-ietf-regext-epp-https, but I believe the difference
here is that a new application protocol is not being defined, but an
HTTP transport is being defined for the existing EPP application
protocol like what has been done for DNS over HTTP (DoH) in RFC 8484.
I don’t see applicability of BCP 56 for the case of
draft-ietf-regext-epp-https, but I do see applicability of BCP 56 for
the new Restful Provisioning Protocol (RPP) being worked on by the RPP
WG.
Other thoughts on this from REGEXT?
Thanks,
--
JG
James Gould
Fellow Engineer
[email protected] [8]
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com [9]
From: Pawel Kowalik <[email protected]>
Date: Tuesday, February 3, 2026 at 11:39 AM
To: James Gould <[email protected]>, "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>,
"[email protected]"
<[email protected]>, "[email protected]"
<[email protected]>
Subject: [EXTERNAL] 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]
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/> [4]
On 1/5/26, 1:10 PM, "Gould, James" <[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]>
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]
<mailto:[email protected]>>
703-948-3271
12061 Bluemont Way
Reston, VA 20190
Verisign.com <http://verisigninc.com/> [4]
<http://verisigninc.com/>> [5]
On 12/29/25, 7:57 PM, "Mark Nottingham" <[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]>>> 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]>>
<applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[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>
[1]
<http://secure-web.cisco.com/1HBfWxc3rSLo8-JlnTCv8UuQJ7L33Ftu57xslVdB9Dl9hGo6XcCGaOcAIRKpaTtwnGNTDjmlvH5qvxtvnCphtQWCoygFXoTczFrh7uwiE1uE1vsZpXMnKUP0ejMM-fNayWZt038WfcGMPuytMu-3WI5BsWFoQkUOPDQz5mBV9MYB_Z2VliIwLnrNwjdeG0l3cftzkKIFO036cnjxMj7yRyTYHkEpSoX6HsHuocCWFVS9T3ENS8o2o-uTSRtVcWd6Zxt41OOO2F4hw9URThTqjn1pYp_dvdtC1NbbPbIKXpP4/http%3A%2F%2Fverisigninc.com%2F>>
[2]
<http://secure-web.cisco.com/1HBfWxc3rSLo8-JlnTCv8UuQJ7L33Ftu57xslVdB9Dl9hGo6XcCGaOcAIRKpaTtwnGNTDjmlvH5qvxtvnCphtQWCoygFXoTczFrh7uwiE1uE1vsZpXMnKUP0ejMM-fNayWZt038WfcGMPuytMu-3WI5BsWFoQkUOPDQz5mBV9MYB_Z2VliIwLnrNwjdeG0l3cftzkKIFO036cnjxMj7yRyTYHkEpSoX6HsHuocCWFVS9T3ENS8o2o-uTSRtVcWd6Zxt41OOO2F4hw9URThTqjn1pYp_dvdtC1NbbPbIKXpP4/http%3A%2F%2Fverisigninc.com%2F>>
[2]
<http://secure-web.cisco.com/1HBfWxc3rSLo8-JlnTCv8UuQJ7L33Ftu57xslVdB9Dl9hGo6XcCGaOcAIRKpaTtwnGNTDjmlvH5qvxtvnCphtQWCoygFXoTczFrh7uwiE1uE1vsZpXMnKUP0ejMM-fNayWZt038WfcGMPuytMu-3WI5BsWFoQkUOPDQz5mBV9MYB_Z2VliIwLnrNwjdeG0l3cftzkKIFO036cnjxMj7yRyTYHkEpSoX6HsHuocCWFVS9T3ENS8o2o-uTSRtVcWd6Zxt41OOO2F4hw9URThTqjn1pYp_dvdtC1NbbPbIKXpP4/http%3A%2F%2Fverisigninc.com%2F&gt;>>
[3]
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]>>>> 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>
[6]
<https://secure-web.cisco.com/1GIoLtqb3sFhOpgHUmBetlXn0_dCNquVEOjlzHhsHkwUuK_Mm1PHu3Qh-a4NP3z8LBKs92L6k7py3mE-yQoQnsqzfSyIRhcWCo4BwJCRWXKMErt6rSFq_vhjrljB1gWShCVbAGZHh2a7dmF58WckNp37FcRas-vQzGAgHkSeAvipWtl1DzLm_euZp79N5t6LdZ5rW2nyAwihaHsN3chtzDh1vBVodkpRMVaP2D0hkDHvXx6cT1rvpvHQ1QUo1woSOrMjJ-e6_tTB0JGUn0yhB5dJ_VgWpgptk8bifpxEYYEA/https%3A%2F%2Fwww.mnot.net%2F>
[6]
<https://secure-web.cisco.com/1GIoLtqb3sFhOpgHUmBetlXn0_dCNquVEOjlzHhsHkwUuK_Mm1PHu3Qh-a4NP3z8LBKs92L6k7py3mE-yQoQnsqzfSyIRhcWCo4BwJCRWXKMErt6rSFq_vhjrljB1gWShCVbAGZHh2a7dmF58WckNp37FcRas-vQzGAgHkSeAvipWtl1DzLm_euZp79N5t6LdZ5rW2nyAwihaHsN3chtzDh1vBVodkpRMVaP2D0hkDHvXx6cT1rvpvHQ1QUo1woSOrMjJ-e6_tTB0JGUn0yhB5dJ_VgWpgptk8bifpxEYYEA/https%3A%2F%2Fwww.mnot.net%2F>>
[7]
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Links:
------
[1]
http://secure-web.cisco.com/1HBfWxc3rSLo8-JlnTCv8UuQJ7L33Ftu57xslVdB9Dl9hGo6XcCGaOcAIRKpaTtwnGNTDjmlvH5qvxtvnCphtQWCoygFXoTczFrh7uwiE1uE1vsZpXMnKUP0ejMM-fNayWZt038WfcGMPuytMu-3WI5BsWFoQkUOPDQz5mBV9MYB_Z2VliIwLnrNwjdeG0l3cftzkKIFO036cnjxMj7yRyTYHkEpSoX6HsHuocCWFVS9T3ENS8o2o-uTSRtVcWd6Zxt41OOO2F4hw9URThTqjn1pYp_dvdtC1NbbPbIKXpP4/http%3A%2F%2Fverisigninc.com%2F
[2]
http://secure-web.cisco.com/1HBfWxc3rSLo8-JlnTCv8UuQJ7L33Ftu57xslVdB9Dl9hGo6XcCGaOcAIRKpaTtwnGNTDjmlvH5qvxtvnCphtQWCoygFXoTczFrh7uwiE1uE1vsZpXMnKUP0ejMM-fNayWZt038WfcGMPuytMu-3WI5BsWFoQkUOPDQz5mBV9MYB_Z2VliIwLnrNwjdeG0l3cftzkKIFO036cnjxMj7yRyTYHkEpSoX6HsHuocCWFVS9T3ENS8o2o-uTSRtVcWd6Zxt41OOO2F4hw9URThTqjn1pYp_dvdtC1NbbPbIKXpP4/http%3A%2F%2Fverisigninc.com%2F&gt;
[3]
http://secure-web.cisco.com/1HBfWxc3rSLo8-JlnTCv8UuQJ7L33Ftu57xslVdB9Dl9hGo6XcCGaOcAIRKpaTtwnGNTDjmlvH5qvxtvnCphtQWCoygFXoTczFrh7uwiE1uE1vsZpXMnKUP0ejMM-fNayWZt038WfcGMPuytMu-3WI5BsWFoQkUOPDQz5mBV9MYB_Z2VliIwLnrNwjdeG0l3cftzkKIFO036cnjxMj7yRyTYHkEpSoX6HsHuocCWFVS9T3ENS8o2o-uTSRtVcWd6Zxt41OOO2F4hw9URThTqjn1pYp_dvdtC1NbbPbIKXpP4/http%3A%2F%2Fverisigninc.com%2F&amp;gt;&gt;
[4]
http://secure-web.cisco.com/1yo_iqDTup8YogJSnCPEgl43ufGwH3NhbTqc8930KB2bIAPWRnMgma1QQw2hdb9vjuTA2lEYqXQLNW49XSUDtTFYpBTHYxZO4hb0Kkw372eVi___k8TI00M1ZlA51wgN4gnMCmGAaHnUM7-7o_nyODyJT3RiXr1c9vk7_VryaVwosKMMQzyjWiB17ULwia5S6uysHRSRrZ60sq74-zq0XYjFWPaZDVC2mFkHp4iUa3_G7v_qP6BkjVaJ9Gxpd17rddqlRKDn1k-AKm1_2IsK_F59JljANBMZAy-h6I_7FVPghY-PHO7MOncgzX5LhMoE7/http%3A%2F%2Fverisigninc.com%2F
[5]
http://secure-web.cisco.com/1-7uh148QHCrmsglyqyrbqVw5OZmdcpQ1ZVBKzrCB4XH-H9T1ohfZnUj5cUl3hhAyl6i3nekVSkvbNtX93wk76bQpi51qdttJ7WoZl9pZ1G98FDj9uhZtiy5o2_EmcNfO8mJKBsy5-iP5D48IDoDq7Q4suOHAHbJHM0NcUCUZhPnPXbZavux7ua2jsK-LHQi-MIZahuNn5in7mXV4-yGg1tui0ieLLks2mK1Alz9TKmyaZy3nDvVpyHBNHcJw0sDRSAY-gse65Mp2-tQTv2_HNmeb3itCNwbfM0RjjmbFikcyN3ciJgDWuM0vC2eiHy39/http%3A%2F%2Fverisigninc.com%2F%26gt%3B
[6]
https://secure-web.cisco.com/1GIoLtqb3sFhOpgHUmBetlXn0_dCNquVEOjlzHhsHkwUuK_Mm1PHu3Qh-a4NP3z8LBKs92L6k7py3mE-yQoQnsqzfSyIRhcWCo4BwJCRWXKMErt6rSFq_vhjrljB1gWShCVbAGZHh2a7dmF58WckNp37FcRas-vQzGAgHkSeAvipWtl1DzLm_euZp79N5t6LdZ5rW2nyAwihaHsN3chtzDh1vBVodkpRMVaP2D0hkDHvXx6cT1rvpvHQ1QUo1woSOrMjJ-e6_tTB0JGUn0yhB5dJ_VgWpgptk8bifpxEYYEA/https%3A%2F%2Fwww.mnot.net%2F
[7]
https://secure-web.cisco.com/1GIoLtqb3sFhOpgHUmBetlXn0_dCNquVEOjlzHhsHkwUuK_Mm1PHu3Qh-a4NP3z8LBKs92L6k7py3mE-yQoQnsqzfSyIRhcWCo4BwJCRWXKMErt6rSFq_vhjrljB1gWShCVbAGZHh2a7dmF58WckNp37FcRas-vQzGAgHkSeAvipWtl1DzLm_euZp79N5t6LdZ5rW2nyAwihaHsN3chtzDh1vBVodkpRMVaP2D0hkDHvXx6cT1rvpvHQ1QUo1woSOrMjJ-e6_tTB0JGUn0yhB5dJ_VgWpgptk8bifpxEYYEA/https%3A%2F%2Fwww.mnot.net%2F&gt;
[8]
applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]
[9] http://verisigninc.com/
_______________________________________________
regext mailing list -- [email protected]
To unsubscribe send an email to [email protected]
