Mon blog

Le protocole d'avitaillement EPP ne spécifie pas comment représenter les objets qu'on crée, détruit, modifie, etc. Cette tâche est déléguée à des RFC auxiliaires comme le nôtre, consacré aux contacts, c'est-à-dire aux personnes physiques ou morales responsables d'un objet de la base et qui peuvent être contactées à son sujet. (L'objet étant typiquement un nom de domaine ou bien un préfixe IP.)

EPP permet à un client de créer, détruire et modifier des objets de types différents. En pratique, EPP n'est utilisé que dans l'industrie des noms de domaine mais, en théorie, il pourrait être utilisé pour n'importe quel type d'objets.

Le type n'est donc pas spécifié dans le protocole EPP de base, normalisé dans le RFC 4930, mais dans des RFC supplémentaires. Par exemple, celui qui fait l'objet de cet article spécifie le type (EPP dit le mapping) pour les contacts. Il n'est plus d'actualité, ayant été remplacé par le RFC 5733.

Ce type est spécifié (section 4 du RFC) dans le langage W3C XML Schema.

Un contact est donc composé d'un identificateur (type clIDType du RFC 4930). Cet identificateur (on l'appelait traditionnellement le handle) est, par exemple, SB68-GANDI.

Les contacts ont aussi évidemment des moyens d'être contactés, via numéro de téléphone, adresse postale, etc.

Les contacts pouvant être des personnes physiques, pour protéger leur vie privée, la section 2.9 du RFC décrit aussi un format pour spécifier si ces informations doivent être publiées ou pas. Insuffisant pour tous les cas, ce format est en général remplacé, chez les registres européens, par un mapping spécifique (par exemple, EPP parameters for .pl ccTLD pour les polonais qui utilisent un élément <individual> pour indiquer si le contact est une personne physique, et a donc droit à la protection des lois européennes sur les données personnelles).

À titre d'exemple, voici la réponse d'un serveur EPP à une requête <epp:info> pour le contact SB68-GANDI :

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
    </result>
    <resData>
      <contact:infData
       xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
        <contact:id>SB68-GANDI</contact:id>
        <contact:roid>SH8013-REP</contact:roid>
        <contact:status s="clientDeleteProhibited"/>
        <contact:postalInfo type="int">
          <contact:name>John Doe</contact:name>
          <contact:org>Exemple SA</contact:org>
          <contact:addr>
            <contact:street>123 rue de l'Exemple</contact:street>
            <contact:city>Trifouillis-les-Oies</contact:city>
            <contact:cc>FR</contact:cc>
          </contact:addr>
        </contact:postalInfo>
        <contact:voice x="1234">+33.7035555555</contact:voice>
        <contact:fax>+33.7035555556</contact:fax>
        <contact:email>jdoe@example.com</contact:email>
        <contact:crDate>1997-04-03T22:00:00.0Z</contact:crDate>
        <contact:upDate>1999-12-03T09:00:00.0Z</contact:upDate>
        <contact:trDate>2000-04-08T09:00:00.0Z</contact:trDate>
        <contact:authInfo>
          <contact:pw>2fooBAR</contact:pw>
        </contact:authInfo>
        <contact:disclose flag="0">
          <contact:voice/>
          <contact:email/>
        </contact:disclose>
      </contact:infData>
    </resData>
  </response>
</epp>

Ce RFC remplace son prédécesseur, le RFC 3733 mais ce ne sont que des modifications de détail. Lui-même a ensuite été remplacé par le RFC 5733, avec, là encore, peu de modifications.