Maarten, The scope of an EPP transport is limited and is specifically defined in Section 2.1 of RFC 5730. Defining a stateless protocol that has additional options for the command and response format is not EPP and not an EPP transport. SMTP being referenced in RFC 5730 doesn't make it a true viable EPP transport since it's up to a transport draft to fully define it by complying with Section 2.1 of RFC 5730. Examples of EPP transports include EoT with RFC 5734 and new proposals with EoH in draft-loffredo-regext-epp-over-http and EoQ in draft-yao-regext-epp-quic. Defining a new EPP transport cannot require a change in RFC 5730.
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 4/2/24, 10:14 AM, "Maarten Wullink" <[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, > > An EPP transport mapping must fully comply RFC 5730 and specifically Section > 2.1 of RFC 5730. REPP defines application-level protocol aspects that do not > comply with RFC 5730, such as being stateless, When RFC5730 section 2.1 was written, an EPP deployment as a stateless service was probably not something that was thought of, which makes sense at the time. Modern APIs and web services nowadays make heavy use of stateless architectures. When we feel that statelessness may be something that should be compatible with EPP, then we may choose to update RFC5730 section 2.1 so it also allows for statelessness? > defining a new command format, and defining a new response format. REPP > defines an alternative to EPP using RESTful concepts and reusing some > elements of EPP and is not an EPP transport extension. REPP does not use new data structures for command and response, existing data structures are reused. How can something such as SMTP be regarded as a transport extension and a HTTP based (RESTful) solution cannot? both are mapped to a different endpoint when compared to EPP over TCP, email addresses ( SMTP) and URIs (REPP) > I'm not opposed to rethinking EPP using RESTful concepts, but it's not > supported in the REGEXT charter. You mean, updating RFC5730 section 2.1 is not support? we would need to update the charter? RFC5730 section 2.1 contains the guiding principles and requirements for new EPP extension transport mappings and is a core part of the EPP extension mechanism and therefore should it not be logical that the regext charter not only cover epp extensions but also the requirements for those extensions? Maarten _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
