> -----Original Message----- > From: Maarten Wullink <[email protected]> > Sent: Tuesday, April 2, 2024 10:15 AM > To: Gould, James <[email protected]> > Cc: [email protected]; [email protected]; [email protected]; Hollenbeck, > Scott <[email protected]>; [email protected] > Subject: [EXTERNAL] Re: [regext] EPP evolution and the REGEXT charter > > 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.
[SAH] Yes, it *was* thought of. Section 2 of RFC 5730 explicitly describes the outcome of that thought process: "EPP is a stateful XML protocol that can be layered over multiple transport protocols." A very specific decision was made to make EPP a stateful protocol. > 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? [SAH] That would be a fundamental change to EPP. > > 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? [SAH] I'm not a WG chair, or our AD, so this is just my opinion as someone who's very familiar with both the process and the subject matter: correct, updates to RFC 5730 are not something we can currently work on. We can work on EPP extensions, and requirements/guidelines for those extensions as described in RFC 3735. Scott _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
