Hi Gavin, Thank’s for your comments!
If "scalability" (based on a cloud paradigm which is designed around HTTP) is the sole objective, then I think that draft-loffredo-regext-epp-over-http would be the "smallest shippable delta" to achieve that objective. However, your use of the term "REST", and the effective forking of EPP's XML syntax for commands and responses (in order to make substantial changes to them), do not seem to relate to this objective. I would encourage you to be explicit in the objectives you're seeking to achieve with this proposal, since "scalability" is insufficient to justify most of what's proposed in your draft. Improved scalability is one the stated goals and It’s true that just by adding HTTP support, EPP would be able to leverage all of the scalability features provided by HTTP. However, by using named resources in the URL (as is a feature of REST) it would also be possible to include more advanced forms of load balancing, such as routing requests based on the request URL pattern. An example would be a configuration where informational requests such the CHECK and INFO are separated from the creational requests such as CREATE and UPDATE. And there’s also the other benefits linked to using RESTful APIs as described. Q) Is REPP a stateless version of EPP? A) No, REPP can be designed to be stateful to conform to the requirement (RFC5730 section 2.1) that a transport MUST preserve the stateful nature of the EPP protocol. When using REPP, EPP is layered over HTTTP and REST, which are both stateless, but the EPP protocol itself can be kept stateful. REST is not something that can be "layered" over, it is an architectural approach based on hypermedia concepts. I would argue that REPP is only partially "RESTful" (as it was defined by Roy Fielding), in that it lacks the hypermedia controls (HATEOAS, Hypermedia As The Engine of Application State) of a true REST design. At most, it meets the criteria for Level 2 of the Richardson Maturity Model (to be clear, draft-loffredo-regext-epp-over-http isn't REST either, but RESTfulness is not one of its design goals). Yes, you are correct that REST is an architectural style and nothing more, i should not have used “layered” for REST, only for HTTP Adding HATEOS was something we considered, the idea behind HATEOS is to allow a server to be able to change the resource names without breaking a client implementation, which may be useful in non-standardized API’s. We decided that it would not be useful in the context of EPP because when URL resources are defined in an IETF standard, they are not very likely to change very often (if ever), And adding HATEOS would make the implementation more complex and bloat server responses, also the vast majority of "RESTful” APIs do not implement HATEOS. for those interested here is an interesting blog about this topic: https://www.ben-morris.com/pragmatic-rest-apis-without-hypermedia-and-hateoas/ If REPP is not REST, and also not EPP, then it is poorly named, and I think you would cause less confusion and win more support with a different name. It's a small thing but could have a big impact. We feel that something like REPP can still be regarded as a "RESTful API” Changing the name, if there is consensus that this would this would be better, is not a problem. Q) Do we need to change the existing EPP RFCs? A) No, for REPP we would not need to change any of the existing EPP RFCs. Only because you plan to fork the formal specifications, resulting in two incompatible grammars for the same fundamental concepts. This means that it may not be possible for an extension designed for EPP to be used with REPP (and vice versa) moving forward, which would harm both protocols. I assume you are referring to the “Formal Syntax” section [1] from the draft? We added a new XML schema in our last version to better align the EPP XML to the RESTful style, if this is a blocking issue, then we can remove the new XML schema in the next version and go back to using the XML schema from RFC 5730. [1] https://www.ietf.org/archive/id/draft-wullink-restful-epp-01.html#name-formal-syntax Q) Are the existing EPP extensions compatible with REPP? A) Yes, all existing EPP extensions should work fine, we have have not worked out all the details but we do feel that this is not an issue. I think this is a matter that you should address urgently since EPP's extensibility is fundamental to its success as a protocol, and implementers (of both clients and servers) will be extremely reluctant to jettison two decades' of work and start again from the ground up. Agree, and it is our goal to be 100% compatible with “standard EPP” on this point. Best, Maarten
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
