Mon blog

Historiquement, le protocole EPP d'avitaillement des ressources Internet (notamment les noms de domaine) n'indiquait pas le prix de création ou de renouvellement d'un nom. Typiquement, tous les noms coûtaient le même prix. Mais certains registres préfèrent vendre plus cher sex.example que suitedelettressanstropdesignification.example. D'où cette extension EPP qui permet d'indiquer le coût d'un nom de domaine particulier, extension qui est aujourd'hui très répandue.

Il y a donc deux logiques possibles, une purement technique (les noms de domaine ont tous le même coût pour le registre et devraient donc coûter pareil au client) et une logique business, où on essaie de faire payer le client plus cher pour les noms les plus demandés. Aux débuts d'EPP (ou de son prédécesseur RGP, dans le RFC 3915), il allait de soi qu'il n'y avait qu'un prix puisque les coûts réels sont les mêmes pour tous les domaines, mais ce n'est plus le cas aujourd'hui. Il faut donc pouvoir informer sur les prix, EPP n'étant pas juste un canal technique mais aussi un canal de vente. Comme cela avait été dit lors d'une discussion à l'IETF, « Arguably, in a situation where many TLDs are now offering domains at various pricing tiers (with no further policy requirements), general availability is no longer just a matter of "domain taken/reserved/valid?", but also of "how much is the registrant willing to pay?". »

L'ancien modèle était donc :

• Certaines opérations sur les objets avitaillés (cf. RFC 5730) sont payantes, typiquement <create>, <renew> et <transfer>, d'autres gratuites (par exemple <update>),
• Le prix est le même pour tous les domaines,
• Ce prix n'est pas indiqué via le canal EPP, on le découvre dans la documentation fournie par le registre.

Le nouveau modèle, où le tarif est indiqué via le canal EPP, permet d'avoir des prix différents par domaine, mais permet également de découvrir automatiquement le tarif, sans se plonger dans la documentation.

La section 3 du RFC décrit ce qui se passe dans chaque commande EPP facturable. L'extension utilise un espace de noms XML qui vaut urn:ietf:params:xml:ns:epp:fee-1.0 (abrégé à fee: dans les exemples du RFC mais bien sûr, comme toujours avec les espaces de noms XML, chacun choisit son abréviation.) Voici un exemple où le client vérifie la disponibilité d'un domaine et son prix, avec <check> :

<?xml version="1.0" encoding="utf-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <check>
       <domain:check
          xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
           <domain:name>example.net</domain:name>
       </domain:check>
   </check>
  <extension>
    <fee:check xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0">
      <fee:currency>USD</fee:currency>
      <fee:command name="create">
        <fee:period unit="y">2</fee:period>
      </fee:command>
    </fee:check>
  </extension>
  </command>
</epp>
	    
  

Le client a demandé quel était le prix en dollars étatsuniens pour une réservation de deux ans. Ici, le serveur lui répond que le domaine est libre (avail="1") :

...
  <resData>
    <domain:chkData
      xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
      <domain:cd>
        <domain:name avail="1">example.net</domain:name>
      </domain:cd>
    </domain:chkData>
  </resData>
  <extension>
       <fee:cd avail="1">
        <fee:objID>example.net</fee:objID>
        <fee:class>standard</fee:class>
        <fee:command name="create" standard="1">
          <fee:period unit="y">2</fee:period>
          <fee:fee
            description="Registration Fee"
            refundable="1"
            grace-period="P5D">10.00</fee:fee>
        </fee:command>
...  

  

Et qu'il en coûtera dix dollars. Notez que le prix dépend de la commande (d'où le <fee:command name="create"> chez le client, et dans la réponse) ; un renouvellement peut coûter moins cher qu'une création, par exemple. Notez aussi que le RFC ne spécifie pas comment le prix est déterminé ; cela peut être configuré manuellement par le registre, ou bien suivre un algorithme (prix plus élevé si le nom est dans un dictionnaire, ou s'il fait moins de N caractères…)

Le serveur EPP aurait pu refuser, si les paramètres étaient inconciliables avec sa politique :

<fee:cd avail="0">
    <fee:objID>example.net</fee:objID>
    <fee:reason>Only 1 year registration periods are
    valid.</fee:reason>
</fee:cd>

  

En quelle monnaie sont indiqués les coûts ? Un élément XML <fee:currency> va permettre de l'indiquer. Sa valeur est un code à trois lettres tiré de la norme ISO 4217, par exemple EUR pour l'euro et CNY pour le yuan. Si le registre se fait payer, non pas dans une monnaie reconnue mais dans une unité de compte privée (des « crédits » internes, par exemple), il peut utiliser le code XXX. Le serveur ne doit pas faire de conversion monétaire. S'il a indiqué des coûts en dollars étatsuniens et que le client indique ce qu'il paie en pesos mexicains, le serveur doit rejeter la commande (ce qui est logique, vu la volatilité des taux de conversion.)

Cette extension à EPP permet également d'indiquer des périodes pendant lesquelles les objets, par exemple les noms de domaine, sont enregistrés. L'unité de temps (mois ou année) est indiquée également.

L'extension permet également d'indiquer des actions commerciales comme une remise, un remboursement (par exemple en cas d'utilisation de la période de grâce du RFC 3915), etc.

Un mécanisme courant chez les registres est d'avoir un compte par client, où le client dépose une certaine somme, d'où les créations ultérieures de noms de domaine sont déduites. Cela donne au registre de la trésorerie, et cela simplifie la comptabilité. L'extension de ce RFC permet de consulter le montant restant (balance) et d'indiquer si l'épuisement de ce compte signifie un arrêt des opérations payantes, ou bien si le serveur fait crédit au client.

Les prix peuvent dépendre du nom de domaine (hotels.example étant plus cher que fzoigqskjjazw34.example) mais aussi de la phase actuelle des enregistrements. Par exemple, une phase initiale, dite de « lever de soleil » (RFC 8334) pour un nouveau domaine d'enregistrement peut avoir des prix plus élevés.

Le serveur peut exiger que le client marque son approbation en indiquant, dans ses requêtes, le prix à payer (section 4). Voilà ce que cela donnerait pour la commande de création :

...
  <command>
     <create>
       <domain:create
         xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
         <domain:name>example.net</domain:name>
         <domain:period unit="y">2</domain:period>
         <domain:registrant>jd1234</domain:registrant>
         ...
       </domain:create>
     </create>
     <extension>
       <fee:create xmlns:fee="urn:ietf:params:xml:ns:epp:fee-1.0">
         <fee:currency>USD</fee:currency>
         <fee:fee>10.00</fee:fee>
       </fee:create>
     </extension>
   </command>

Pour une demande de vérification de disponibilité (<check>), le serveur peut répondre que le domaine n'est pas libre si le client n'utilise pas l'extension de coût. Le principe est que, si un <check> indique qu'un domaine est libre, un <create> avec les mêmes extensions ou la même absence d'extension doit réussir. « Libre » veut donc dire « libre, aux conditions que tu as indiquées ».

Les détails de l'extension dans toutes les commandes EPP figurent en section 5, et le schéma en section 6.

L'extension décrite dans le RFC a été ajoutée au registre des extensions EPP, spécifié par le RFC 7451.

Cette extension EPP est déjà mise en œuvre par CentralNic et par d'autres registres mais attention, pas forcément avec la version du RFC, cela peut être des brouillons antérieurs.