Hi Maarten, I have some comments about your points, which I will insert below.
> On 25 Apr 2024, at 08:15, Maarten Wullink > <maarten.wullink=40sidn...@dmarc.ietf.org> wrote: > > Jim, Scott, > > There exists a lot of confusion about REPP, here is my attempt to try to > answer some of these question. > > Q) What is the goal of REPP? > > A) The goal is to create a "RESTful API for EPP" to increase scalability of > an EPP service, make it easier to integrate into registry/registrar systems > through the use of modern HTTP/REST based APIs and also include support for > other data formats such as JSON. > Maybe, a good analogy would be that REPP would be to EPP, what RDAP is to > WHOIS? 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. > 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). 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. > This is similar to the draft proposal for EPP over HTTP and Quic. After the > login request, the client would receive a session identifier/token to couple > the server state to the client. > > 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. > 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. Regards, -- Gavin Brown Principal Engineer, Global Domains & Strategy Internet Corporation for Assigned Names and Numbers (ICANN) https://www.icann.org _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
