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.
>