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. _______________________________________________ regext mailing list -- [email protected] To unsubscribe send an email to [email protected]
