RE: Standard mappings hardwired in EPP servers? (Was: lastVerified: optional vs. extension

["Gould, James" <JGould@verisign.com>]

Stephane,

As an implementer I have to say that hard coding the "standard" mappings
with the server is extremely poor design and supporting new EPP
mappings/extensions can be easily made pluggable.  All that is needed is one
factory class per namespace along with a pluggable handler.  I've personally
implemented multiple EPP registries with the "standard" mappings and with
custom mappings/extensions, and none of them required modifying the core
server code.  

Jim    

-----Original Message-----
From: Stephane Bortzmeyer [mailto:bortzmeyer@nic.fr]
Sent: Monday, December 09, 2002 4:58 AM
To: Joe Abley
Cc: ietf-provreg@cafax.se
Subject: Standard mappings hardwired in EPP servers? (Was: lastVerified:
optional vs. extension


On Fri, Dec 06, 2002 at 10:59:11AM -0500,
 Joe Abley <jabley@isc.org> wrote 
 a message of 25 lines which said:

> It is also important to remember that the domain and nameserver mapping 
> documents are extensions to the base protocol, and not integral to it. 
> There is nothing to stop a registry for whom the current documents are 
> not a good match from writing their own mapping documents that better 
> suit their purposes.

Yes, but this could be a nightmare for the implementor of the EPP
server: if you distribute a shrink-wrapped server (wether free
software or closed), you need some sort of plug-in mechanism in the
server in order to support "alternative" mappings. It is not obvious
to realize. (/etc/epp.conf contains a relationship of
extension->module/class to load? And the registry develops the local
modules/classes?)

Let's try: how many EPP servers (whatever their legal status) have the
"standard" mappings hardwired in the code? I assume "all".

It is also a problem for the registrars: if you interact with several
registries and they use different EPP mappings, you lose a part of the
reason to have a standard protocol...