Mon blog

EPP, normalisé dans le RFC 4930 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 RFC 4930) de la description des objets qu'on peut avitailler (par exemple les domaines sont dans le RFC 4931). 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 RFC 4933 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 RFC 4114 décrit un nouveau type d'objets avitaillés, pour les besoins d'ENUM.

Le RFC 3915 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 RFC 4310 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.