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 regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
