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 jgould@Verisign.com 
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com> 
> 703-948-3271 12061 Bluemont Way Reston, VA 20190 Verisign.com 
> <http://verisigninc.com/> On 1/5/26, 1:10 PM, "Gould, James" 
> <jgould@verisign.com <mailto:jgould@verisign.com>> 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 jgould@Verisign.com 
> <mailto:jgould@Verisign.com> 
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com 
> <mailto:jgould@Verisign.com>> 703-948-3271 12061 Bluemont Way Reston, 
> VA 20190 Verisign.com <http://verisigninc.com/> 
> <http://verisigninc.com/&gt;> On 12/29/25, 7:57 PM, "Mark Nottingham" 
> <mnot@mnot.net <mailto:mnot@mnot.net> <mailto:mnot@mnot.net 
> <mailto:mnot@mnot.net>>> 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 <jgould@verisign.com <mailto:jgould@verisign.com> <mailto:jgould@verisign.com <mailto:jgould@verisign.com>>> 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
>> jgould@Verisign.com <mailto:jgould@Verisign.com> <mailto:jgould@Verisign.com <mailto:jgould@Verisign.com>> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com <mailto:jgould@Verisign.com> <mailto:jgould@Verisign.com <mailto:jgould@Verisign.com>>>
>>
>> 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&gt;> <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&amp;gt;&gt;> 
>>
>>
>>
>>
>> On 11/30/25, 5:41 PM, "Mark Nottingham via Datatracker" <noreply@ietf.org <mailto:noreply@ietf.org> <mailto:noreply@ietf.org <mailto:noreply@ietf.org>> <mailto:noreply@ietf.org <mailto:noreply@ietf.org> <mailto:noreply@ietf.org <mailto:noreply@ietf.org>>>> 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 Nottinghamhttps://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&gt;>
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> regext mailing list --regext@ietf.org
> To unsubscribe send an email toregext-leave@ietf.org