Re: [enum-wg] Second call for RIPE 51 agenda topics and commentson RIPE 50 minutes

[Richard Shockey <]

Title: Re: [enum-wg] Second call for RIPE 51 agenda topics and comments on RIPE 50 minutes

Conroy, Lawrence (SMTP) wrote:

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?

The issue is not the client server model. That is in fact the correct way domain  registration is and should be donedone ..the issue is that major Teleco customer care systems dont know how to integrate EPP into their applications.

The entire planet uses SOAP/XML processes to facilitate data exchanges between various database elements. The IETF does not because as you correctly point out 3205 is stupid.

The problem with EPP is the binding of the objects to the underlying transport is very tight and that requires implementing the full EPP suite in the Teleco CRM application. Though every TLD operator gives its Registrars toolkits to implement EPP the businesses are very very different. Telecos have existing customer management systems and they DO NOT want to implement "alien" transport protocols like EPP.

The integration issue is just too expensive.

Time and Time again in talking to carriers that are looking at the ENUM provisioning issues they say . "We're integrating SOAP/XML across our entire adminstrative and accounting infrastructure." Cant you just abstract out all of the underlying XML objects from EPP ..and give me a WSDL ?

Practical answer to a practical problem.

You know I've been screaming about this for ages ..but now that people are really serious about implementing this the real problem comes up.

     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.

Well we did the work in the IETF to make sure there was SOMETHING that Registries could use and since most ENUM activity in Europe is being driven by CC TLD operators it made sense to let them have some tools that they were immediately familiar with.

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

-- 


>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141(at)fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile +1 703.593.2683
Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or 
<mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<