EPP, normalisé dans le et suivants, a une particularité importante : il est
conçu pour être extensible. Ce RFC explique les précautions à prendre
lorsqu'on étend EPP.
EPP est un protocole
d'avitaillement, c'est-à-dire de création,
modification et destruction d'objets stockés dans un registre
distant. L'utilisation la plus connue d'EPP concerne les
registres de noms de domaine mais EPP peut
servir à bien d'autres choses. Même dans le cas de registres de noms
de domaine, les différences de politique d'enregistrement font qu'il
est bien difficile de proposer un protocole qui convienne à tout le
monde. EPP sépare donc le protocole (décrit dans
le ) de la description des objets qu'on peut avitailler (par
exemple les domaines sont dans le ). Aussi bien le protocole que les types d'objets sont
extensibles (et, naturellement, on peut aussi créer ses propres types
d'objets), cf. les sections 2.4 à 2.7, ainsi que la section 3 qui
explique quoi étendre. (Par exemple, le RFC recommande d'étendre un
type d'objet existant plutôt que d'en créer un nouveau.)
Étendre EPP signifie écrire des schémas XML
dans le langage W3C Schema. Il est prudent de
valider ensuite les schémas et les exemples d'éléments XML qu'ils
décrivent, ici par exemple avec xmllint :
% xmllint --noout --schema nask-extcon.xsd nask-create-contact.xml
nask-create-contact.xml validates
on teste un élément décrivant un contact, suivant l'extension au créée par
le NASK, registre de
.pl.
Notre RFC explique que les schémas sont identifiés par un
URI (par exemple
http://www.nic.coop/contactCoopExt-1.0
pour l'extension du registre de .coop), doivent être documentés (section
2.1), doivent eux-même être extensibles, etc. Le protocole EPP impose
que les extensions soient annoncées par le serveur
et demandées par le client.
Naturellement, une fois qu'on étend EPP, les anciens programmes ne
marchent plus. Chaque extension nécessite un travail de programmation
spécifique. On notera que le client EPP libre Net::DRI
gère pratiquement toutes les extensions EPP existantes.
Voyons quelques exemples (la liste n'est pas limitative) d'extensions à EPP (je donne la priorité
aux registres où l'information est publiquement accessible).
Le décrit un nouveau type d'objets avitaillés,
pour les besoins d'ENUM.
Le décrit une extension au type Domaine pour
gérer les périodes de rédemption (le fait qu'un domaine détruit ne
soit pas réenregistrable immédiatement, pour laisser une chance à son
ancien titulaire).
Le décrit une extension pour gérer l'information
DNSSEC pour les domaines.
Le registre de .coop a
plusieurs
extensions (langue de l'utilisateur, connexion à leur système
de tickets, pour la validation des domaines).
Le registre polonais a des
extensions aux objets de type Contact pour gérer la protection des
données personnelles (le fait d'être une personne physique et
l'autorisation de publication).
Certains registres comme le belge, ont le concept de « groupe de serveurs
de noms », qui permet d'attacher un groupe à un domaine, facilitant
ainsi l'ajout ou le retrait d'un serveur de noms. Cette extension
(documentée dans leur Registration
guidelines) a nécessité la création d'un nouveau type
d'objets, le NSgroup
Verisign fournit également de nombreuses
extensions, par exemple une extension « IDN
language » pour indiquer la langue associée à un
nom de domaine internationalisé (une stupide
idée, imposée par l'ICANN).
Enfin, d'autres registres ont des extensions EPP comme
.br ou
.us. Merci à Patrick Mevzek pour les détails.