Mon blog

Voici le cahier des charges du protocole de communication entre registre et registrar, EPP.

La publication de la norme EPP, le RFC 3730 (auquel a succédé le RFC 4930 et ses frères) a signifié la fin du processus de sélection d'un protocole relativement générique de communication entre un registre et ses registrars. Ce processus avait commencé avec notre RFC, le cahier des charges du projet et s'est conclu avec la dissolution du groupe de travail Provreg en avril 2004.

Écrire un tel protocole n'est pas évident. En effet, les registres ont des politiques d'enregistrement très variées. Chez certains, comme .com, le domaine expire automatiquement au bout d'un certain temps et dans d'autres, comme .fr ou .eu, la notion d'expiration n'existe pas, le domaine doit être détruit explicitement. Chez certains registres, le registrar a tous les pouvoirs, notamment sur les objets de type Contact alors qu'ailleurs les contacts peuvent se gérer eux-même. Si des organismes comme l'ICANN ont du mal à admettre cette diversité et cherchent à imposer des règles uniformes (« Le consensus de Marina del Rey »), d'autres reconnaissent la variété comme une caractéristique essentielle des registres (le titre d'un atelier du CENTR au FGI d'octobre 2007 était One size doesn't fit all).

Le cahier des charges avait commencé comme une simple transcription des politiques de .com avant d'évoluer vers un document plus équilibré, même si le biais .com reste très fort. Par exemple, la terminologie de « registre partagé » (SRS pour shared registry system) reflète une vision du monde où le registre est une simple base de données commune. De même, la terminologie (section 1) utilise un vocabulaire péjoratif, parlant de « séparation peu claire » pour désigner un modèle parfaitement valide, celui de registre à vente directe, sans registrar.

La section 2 du RFC rappelle le fonctionnement général d'un registre. Les clients (le terme est celui utilisé dans les RFC ultérieurs, car plus neutre que registrar, qu'utilise ce RFC) créent des objets, les mettent à jour, les détruisent, etc. Les objets peuvent être de plusieurs types (le RFC cite les noms de domaine, les serveurs de noms et les contacts). Si les objets sont des noms de domaine, le registre produira les fichiers DNS pour les distribuer (les RFC produits par la suite sont plus neutres et moins spécifiques des registres de noms de domaine).

La section 3 décrit ensuite les exigences pour le futur protocole. Par exemple, la section 3.4.1 demande que chaque objet aie un identificateur unique (le ROID d'EPP).

Si, dans le processus de développement de ce RFC, un réel effort avait été fait pour s'abstraire des particularités de .com et des autres TLD ICANN, le résultat n'est pas parfait. Ainsi, la section 3.5, consacrée aux statuts possibles pour un nom de domaine, liste les statuts de .com, sans mentionner que certains peuvent ne pas avoir de sens pour un autre registre.