<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <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> </HEAD> <BODY>  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. > </BODY> </HTML>