Hi Richard, Carsten, folks, In reference to EPP vs. SOAP/HTTP, I note the authorship of RFC3205 - given that, calling it stupid is redundant/stating the obvious. Seriously, care to expand on what you see as the differences that make the EPP (client/server) model inappropriate for provisioning? I had thought that the goal was for the Telco customer care system to act as an EPP client, whilst the core ENUM provisioning/ population system acted as the EPP server. That seemed to be the model behind the (delphic) answer when I (and others) asked on the IETF-ENUM list for clarification on why one would ever want EPP-E164, where would it be used, and between whom. On 12 Sep 2005, at 15:36, Richard Shockey wrote:

I can certainly testify to the intense interest in provisioning issues on this side of the pond.

In particular we're looking at SOAP/XML interfaces to the registry. The reason for this is that EPP ( which is a fine protocol ) was designed for the highly unique business model of domain name registries and simply will not integrate into the kinds of customer management systems teleco typically deploy.

EPP was designed in the manner it is because the IETF has a really really stupid policy ( RFC 3205 ) on the use of HTTP as a application substrate.