I agree that a redesign would only make sense if it can do more afterward than before. Otherwise, it would only produce costs and effort without delivering any real added value.
I may not doubt whether the attractiveness can be an added value, but I would at least question whether that is a sufficient added value. In my years as a registrar, missing or unequal test systems and detailed documentation (e.g., error codes, behavior, poll messages, limits, etc.) were a much bigger problem than how the transport works—especially when transferring TLDs from one backend to another. I don't know how your experiences are/were in those cases, but if I had a choice, I would instead work on simplification/documentation. If I remember correctly, there was also once an approach to this from Jim https://datatracker.ietf.org/doc/draft-gould-carney-regext-registry/ <https://datatracker.ietf.org/doc/draft-gould-carney-regext-registry/> Regarding Mario's draft, EPP over HTTP is already in use, and the document, at least as I understand it, is only intended to standardize the existing procedure, so there is no proliferation. I support that. Tobias > On 21. Jun 2022, at 22:51, Patrick Mevzek <p...@dotandco.com> wrote: > > On Tue, Jun 21, 2022, at 15:09, Eduardo Duarte wrote: >> EPP is about 20 years old and I >> think it needs some reshaping to the actual Internet state. > > Is the EPP *transport* really where people struggle most? Ok, XML over TLS > might not be the current trendy couple in Internet circles, but among all the > problems I see in EPP (having worked both on registrar and registry side), I > really do not have the transport in my top 10. > The plethora of extensions to do the same thing, and the various "quality" of > extensions is more of a concern to me, as well as the non-existent > discoverability of features (there is one extension solving part of the > problem, not used by everyone). Or the lack of standardization in error > codes/messages/details extended from core case. Or the now not good enough > design of a contact. Or operations being mixed where they shouldn't (like > restore in update). > > We barely arrived only a few months ago to have "fees" finally being a > standard... and it > will take years before all registries switch to it. This is certainly where > registrars struggle more than just having to use a TLS "socket" (I count > around 28 versions of the fees document, for 18 different XML namespaces with > more than a couple of them really used in the wild). > > Said differently, the transport part seems to me really the easy part of the > problem of EPP viewed globally. Of course, if that blocks some actors, then > the working group is certainly the relevant place to find out a standardized > solution, but will really a lot of registries suddenly switch to it just for > the sake of switching to it? > > Or: what EPP over TCP and/or a REST redesign really add as new features, > solving current problems? Besides "it looks similar to the rest of the > Internet, so it will attract more/better programmers" (a statement I would > certainly have an hard time to believe) or "the crappy hosting I am using > only allows HTTPS servers/clients and nothing else, so now I have to adapt my > whole word just because I chose a bad system from the beginning". > > Just my personal views of course. > > -- > Patrick Mevzek > p...@dotandco.com > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
