Les registres, par exemple les registres de noms de domaine fonctionnent
parfois sur un modèle registry/registrar
c'est-à-dire, où le client final doit passer par un intermédiaire, le
registrar pour enregistrer
son nom de domaine. Le registrar souhaite en
général avoir un protocole de communication avec le
registre afin
d'automatiser ses opérations, dans son langage de programmation
favori. EPP, décrit dans ce RFC, est un de ces protocoles
d'avitaillement (provisioning,
et merci à Olivier Perret pour la traduction). (EPP n'emploie pas le
terme de registrar mais celui de
sponsoring client, plus neutre. EPP peut donc en
théorie être utilisé en cas de vente directe.)
Notre RFC remplace le premier RFC sur EPP, le ,
mais les changements sont mineurs, essentiellement des bogues qui se
produisent assez rarement dans la pratique, même si le registre du
.eu a réussi à violer la
norme XML en câblant en dur le préfixe d'espace
de noms epp dans leur code, ce qui a nécessité
une modification dans la section 2 de notre RFC pour rappeler que
c'était interdit.
À son tour, notre a été remplacé, par le , là encore avec peu de modifications.
EPP a été réalisé sur la base du cahier des charges dans le . Au lieu de s'appuyer sur les protocoles classiques de
communication comme XML-RPC ou
SOAP, ou même sur l'architecture
REST, EPP crée un protocole tout nouveau,
consistant en l'établissement d'une connexion (authentifiée) puis sur
l'échange d'éléments XML, spécifiés dans le
langage W3C Schemas.
Par exemple, l'ouverture de la connexion se fait en envoyant
l'élément XML <login> :
ClientXfoo-BAR2bar-FOO21.0fr-CAurn:ietf:params:xml:ns:obj1urn:ietf:params:xml:ns:obj2urn:ietf:params:xml:ns:obj3ABC-12345
]]>
Un des points délicats de la conception d'un tel protocole est que
chaque registre a sa propre politique d'enregistrement et ses propres
règles. Quoi que dise ou fasse l'ICANN, cette
variété va persister. Par exemple, l'expiration automatique d'un domaine existe dans
.com mais pas dans
.eu ou
.fr. Le protocole EPP ne
prévoit donc pas d'éléments pour gérer telle ou telle catégorie
d'objets (les domaines mais aussi les serveurs de noms ou les contacts). Il doit être complété par des mappings,
des schémas dont certains sont spécifiés pas
l'IETF comme le domain
mapping (gestion des domaines) dans le . Plusieurs registres utilisent des
mappings non-standard, pour s'adapter à leurs
propres règles d'enregistrement, ce qui limite la portabilité des
programmes EPP. C'est ce qu'ont fait les brésiliens ou les polonais.
Complexe, EPP n'a guère eu de succès chez les registres existants,
sauf ceux qui refaisaient complètement leur logiciel comme
.be. On notera que certains gros TLD comme .de n'utilisent pas
EPP (Denic utilise son
protocole MRI/RRI). Il existe d'autres protocoles d'avitaillement
comme :
Le registre Adams' Names a son protocole au dessus de XML-RPC,Le registrarGandi
utilise son protocole, au dessus de XML-RPC
pour ses revendeurs,Le registrarBookMyName utilise son protocole, au dessus de SOAP
pour ses revendeurs,
et beaucoup d'autres qui ne semblent pas forcément documentés publiquement.
Il existe plusieurs mises en œuvres d'EPP en
logiciel libre par exemple le serveur EPP OpenReg de
l'ISC, le logiciel Fred du registre de .cz ou
bien le client EPP Net::DRI de
Patrick Mevzek.