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]> 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] > <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email protected]> > > 703-948-3271 > 12061 Bluemont Way > Reston, VA 20190 > > Verisign.com <http://verisigninc.com/> > > > > > On 11/30/25, 5:41 PM, "Mark Nottingham via Datatracker" <[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://www.mnot.net/ _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
