<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Conroy, Lawrence (SMTP) wrote:
<blockquote cite="midD4C15E83-7FC2-4EE1-8604-7CC613BD10E0@roke.co.uk"
 type="cite">
  <meta http-equiv="Content-Type" content="text/html; ">
  <meta name="Generator"
 content="MS Exchange Server version 6.5.7232.11">
  <title>Re: [enum-wg] Second call for RIPE 51 agenda topics and
comments on RIPE 50 minutes</title>
<!-- Converted from text/plain format -->
  <p><font size="2">Hi Richard, Carsten, folks,</font>
  <br>
  <font size="2">  In reference to EPP vs. SOAP/HTTP, I note the
authorship of RFC3205</font>
  <br>
  <font size="2">- given that, calling it stupid is redundant/stating
the obvious.</font>
  </p>
  <p><font size="2">Seriously, care to expand on what you see as the
differences that</font>
  <br>
  <font size="2">make the EPP (client/server) model inappropriate for
provisioning?</font></p>
</blockquote>
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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
The integration issue is just too expensive.<br>
<br>
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 ?<br>
<br>
Practical answer to a practical problem.<br>
<br>
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.<br>
<blockquote cite="midD4C15E83-7FC2-4EE1-8604-7CC613BD10E0@roke.co.uk"
 type="cite">
  <p></p>
  <p><font size="2">     I had thought that the goal was for the Telco
customer care system</font>
  <br>
  <font size="2">     to act as an EPP client, whilst the core ENUM
provisioning/ </font>
  <br>
  <font size="2">population</font>
  <br>
  <font size="2">     system acted as the EPP server. That seemed to be
the model  </font>
  <br>
  <font size="2">behind the</font>
  <br>
  <font size="2">     (delphic) answer when I (and others) asked on the
IETF-ENUM list  </font>
  <br>
  <font size="2">for</font>
  <br>
  <font size="2">     clarification on why one would ever want
EPP-E164, where would  </font>
  <br>
  <font size="2">it be</font>
  <br>
  <font size="2">     used, and between whom.</font></p>
</blockquote>
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.<br>
<blockquote cite="midD4C15E83-7FC2-4EE1-8604-7CC613BD10E0@roke.co.uk"
 type="cite">
  <p></p>
  <br>
  <br>
  <p><font size="2">On 12 Sep 2005, at 15:36, Richard Shockey wrote:</font>
  <br>
  <font size="2">> I can certainly testify to the intense interest
in provisioning  </font>
  <br>
  <font size="2">> issues on this side of the pond.</font>
  <br>
  <font size="2">></font>
  <br>
  <font size="2">> In particular we're looking at SOAP/XML
interfaces to the  </font>
  <br>
  <font size="2">> registry.  The reason for this is that EPP (
which is a fine  </font>
  <br>
  <font size="2">> protocol ) was designed for the highly unique
business model of  </font>
  <br>
  <font size="2">> domain name registries and simply will not
integrate into the kinds  </font>
  <br>
  <font size="2">> of customer management systems teleco typically
deploy.</font>
  <br>
  <font size="2">></font>
  <br>
  <font size="2">> EPP was designed in the manner it is because the
IETF has a really  </font>
  <br>
  <font size="2">> really stupid policy ( RFC 3205 ) on the use of
HTTP as a  </font>
  <br>
  <font size="2">> application substrate.</font>
  <br>
  <font size="2">></font>
  </p>
</blockquote>
<br>
<br>
<pre class="moz-signature" cols="72">-- 


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