Extensible Provisioning Protocol

Cet article est une ébauche concernant Internet et l’informatique.

Vous pouvez partager vos connaissances en l’améliorant (comment ?) selon les recommandations des projets correspondants.

Extensible Provisioning Protocol (EPP) ou protocole d'avitaillement extensible est un protocole informatique basé sur XML pour des échanges entre registres et registrars. Cette méthode, unifiée et commune entre les acteurs, permet de faire toutes les opérations liées aux domaines de façon sécurisée.

Les avantages sont multiples :

Les actions sont généralement instantanées. Plus besoin d’attendre un mail ou un courrier avec un formulaire en triple exemplaire pour faire une petite modification, les fonctionnalités de l’EPP permettent des demandes instantanées et une réponse tout aussi immédiate.
EPP est commun à tous, ainsi, il est très facile de travailler avec plusieurs registres sans devoir recoder le logiciel client.
Pour toutes les actions différées, vous avez le contrôle total de l’information. Vous choisissez quoi répondre et surtout quand. Les messages restent en attente jusqu'à ce que vous ayez pris bonne note et confirmé la réception.

Historique

Ce protocole fait suite à une démarche d'uniformisation des méthodes de travail entre registre et registrars pour déposer, modifier et supprimer des noms de domaines. Cela s'inscrit aussi dans la lutte contre le cybersquattage.

L'IETF Provisioning Registry (provreg) l'a finalisé en 2004.

Il a été adopté par de nombreux registres, comme .info, .org, .aero, .mobi, .ag, .au, .br, .bz, .cz, .eu, .fr, .re, .gi, .gr, .hn, .in, .me, .mn, .pl, .ro, .sc, .uk, .vc, etc.

Exemple

Exemple de commande pour créer un domaine :

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <create>
      <domain:create
       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>example.com</domain:name>
        <domain:period unit="y">1</domain:period>
        <domain:ns>
          <domain:hostObj>ns1.exemple.net</domain:hostObj>
          <domain:hostObj>ns2.exemple.net</domain:hostObj>
        </domain:ns>
        <domain:registrant>REG-1738</domain:registrant>
        <domain:contact type="admin">ADM-9374</domain:contact>
        <domain:contact type="tech">OTH-2567</domain:contact>
        <domain:contact type="billing">OTH-2567</domain:contact>
        <domain:authInfo>
          <domain:pw>y85NS%FJ4zeKuHXo</domain:pw>
        </domain:authInfo>
      </domain:create>
    </create>
    <clTRID>uu28qbb2wo6o5bpk</clTRID>
  </command>
</epp>

Les deux objets hostObj et les trois objets contact différents ont dû être créés au préalable pour pouvoir être utilisés, et que le client devait déjà être connecté. Le authInfo pw est un secret requis pour le transfert entre les serveurs d'enregistrement. Le clTRID est un identifiant de transaction unique pour chaque commande générée par le client. La réponse du serveur à la commande ci-dessus pourrait ressembler à ceci :

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Commande executée avec succès</msg>
    </result>
    <resData>
      <domain:creData
       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>exemple.com</domain:name>
        <domain:crDate>2023-03-12T12:00:00.0Z</domain:crDate>
        <domain:exDate>2024-03-12T12:00:00.0Z</domain:exDate>
      </domain:creData>
    </resData>
    <trID>
      <clTRID>uu28qbb2wo6o5bpk</clTRID>
      <svTRID>ma3fuaeuh7bzpgv9</svTRID>
    </trID>
  </response>
</epp>

Le clTRID est identique à celui envoyé par le client, tandis que le svTRID est un identifiant de transaction unique généré par le serveur. Le serveur renvoie un code de résultat, un message et des données de résultat supplémentaires, telles que la date d'expiration du domaine nouvellement créé.

Codes de réponse

Toutes les réponses du serveur doivent respecter un format spécifié. Chaque code de réponse correspond à un message lisible par un humain. Les codes au format 1xxx indiquent des opérations réussies, tandis que les codes au format 2xxx signalent des erreurs. Ces erreurs sont classées en erreurs de syntaxe du protocole (format 20xx), règles spécifiques à l'implémentation (format 21xx), sécurité (format 22xx), gestion des données (format 23xx), système serveur (format 24xx) et gestion de la connexion (format 25xx). La plupart des résultats peuvent inclure des données supplémentaires dans l'objet resData, par exemple, le paramètre obligatoire manquant^[1].

Le code de réponse 1001 active le traitement hors ligne. Par exemple, un registre de noms de domaine peut souhaiter valider un titulaire avant l'enregistrement du domaine. Dans ce cas, le domaine est bloqué pour les autres clients jusqu'à la fin du processus, et le client est notifié par un message de requête qu'il peut récupérer via la commande 'poll'. Les codes 1300 et 1301 sont spécifiques à la commande 'poll' et indiquent la présence d'un message^[1].

La liste complète des codes de résultats et des messages de résultats normalisés est ^[1]:

Code	Message
1000	Commande exécutée avec succès
1001	Commande exécutée avec succès ; action en attente
1300	Commande exécutée avec succès ; aucun message
1301	Commande exécutée avec succès ; accusé de réception pour retrait de la file d'attente
1500	Commande exécutée avec succès ; fin de la session
2000	Commande inconnue
2001	Erreur de syntaxe de la commande
2002	Erreur d'utilisation de la commande
2003	Paramètre obligatoire manquant
2004	Erreur de plage de valeurs de paramètre
2005	Erreur de syntaxe de la valeur du paramètre
2101	Commande non implémentée
2102	Option non implémentée
2103	Extension non implémentée
2104	Échec de facturation
2105	L'objet n'est pas éligible au renouvellement
2106	L'objet n'est pas éligible au transfert
2200	Erreur d'authentification
2201	Erreur d'autorisation
2202	Informations d'autorisation invalides
2300	Objet en attente de transfert
2301	Objet non en attente de transfert
2302	L'objet existe
2303	L'objet n'existe pas.
2304	L'état de l'objet interdit l'opération
2305	L'association d'objets interdit le fonctionnement
2306	Erreur de stratégie de valeur de paramètre
2307	Service d'objet non implémenté
2308	violation de la politique de gestion des données
2400	La commande a échoué
2500	La commande a échoué ; le serveur ferme la connexion.
2501	Erreur d'authentification ; le serveur ferme la connexion
2502	Limite de session dépassée ; le serveur ferme la connexion.

Code de résultat

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <create>
      <domain:create
       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>exemple.com</domain:name>
        <domain:period unit="y">1</domain:period>
        <domain:ns>
          <domain:hostObj>ns1.exemple.net</domain:hostObj>
          <domain:hostObj>ns2.exemple.net</domain:hostObj>
        </domain:ns>
        <domain:registrant>REG-1738</domain:registrant>
        <domain:contact type="admin">ADM-9374</domain:contact>
        <domain:contact type="tech">OTH-2567</domain:contact>
        <domain:contact type="billing">OTH-2567</domain:contact>
        <domain:authInfo>
          <domain:pw>y85NS%FJ4zeKuHXo</domain:pw>
        </domain:authInfo>
      </domain:create>
    </create>
    <clTRID>uu28qbb2wo6o5bpk</clTRID>
  </command>
</epp>

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Commande exécutée avec succès</msg>
    </result>
    <resData>
      <domain:creData
       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>exemple.com</domain:name>
        <domain:crDate>2023-03-12T12:00:00.0Z</domain:crDate>
        <domain:exDate>2024-03-12T12:00:00.0Z</domain:exDate>
      </domain:creData>
    </resData>
    <trID>
      <clTRID>uu28qbb2wo6o5bpk</clTRID>
      <svTRID>ma3fuaeuh7bzpgv9</svTRID>
    </trID>
  </response>
</epp>

Voici un exemple de commande pour créer un domaine :

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <command>
    <create>
      <domain:create
       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>example.com</domain:name>
        <domain:period unit="y">1</domain:period>
        <domain:ns>
          <domain:hostObj>ns1.exemple.net</domain:hostObj>
          <domain:hostObj>ns2.exemple.net</domain:hostObj>
        </domain:ns>
        <domain:registrant>REG-1738</domain:registrant>
        <domain:contact type="admin">ADM-9374</domain:contact>
        <domain:contact type="tech">OTH-2567</domain:contact>
        <domain:contact type="billing">OTH-2567</domain:contact>
        <domain:authInfo>
          <domain:pw>y85NS%FJ4zeKuHXo</domain:pw>
        </domain:authInfo>
      </domain:create>
    </create>
    <clTRID>uu28qbb2wo6o5bpk</clTRID>
  </command>
</epp>

Notez que les deux objets hostObj et les trois objets contact différents ont dû être créés au préalable pour pouvoir être utilisés, et que le client devait déjà être connecté. Le authInfo pw est un secret requis pour le transfert entre les serveurs d'enregistrement. Le clTRID est un identifiant de transaction unique pour chaque commande générée par le client. La réponse du serveur à la commande ci-dessus pourrait ressembler à ceci :

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Commande executée avec succès</msg>
    </result>
    <resData>
      <domain:creData
       xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
        <domain:name>exemple.com</domain:name>
        <domain:crDate>2023-03-12T12:00:00.0Z</domain:crDate>
        <domain:exDate>2024-03-12T12:00:00.0Z</domain:exDate>
      </domain:creData>
    </resData>
    <trID>
      <clTRID>uu28qbb2wo6o5bpk</clTRID>
      <svTRID>ma3fuaeuh7bzpgv9</svTRID>
    </trID>
  </response>
</epp>

Le clTRID est identique à celui envoyé par le client, tandis que le svTRID est un identifiant de transaction unique généré par le serveur. Le serveur renvoie un code de résultat, un message et des données de résultat supplémentaires, telles que la date d'expiration du domaine nouvellement créé.

Toutes les réponses du serveur doivent respecter un format spécifié. Chaque code de réponse correspond à un message lisible par un humain. Les codes au format 1xxx indiquent des opérations réussies, tandis que les codes au format 2xxx signalent des erreurs. Ces erreurs sont classées en erreurs de syntaxe du protocole (format 20xx), règles spécifiques à l'implémentation (format 21xx), sécurité (format 22xx), gestion des données (format 23xx), système serveur (format 24xx) et gestion de la connexion (format 25xx). La plupart des résultats peuvent inclure des données supplémentaires dans l'objet resData, par exemple, le paramètre obligatoire manquant^[1].

Le code de réponse 1001 active le traitement hors ligne. Par exemple, un registre de noms de domaine peut souhaiter valider un titulaire avant l'enregistrement du domaine. Dans ce cas, le domaine est bloqué pour les autres clients jusqu'à la fin du processus, et le client est notifié par un message de requête qu'il peut récupérer via la commande 'poll'. Les codes 1300 et 1301 sont spécifiques à la commande 'poll' et indiquent la présence d'un message^[1].

La liste complète des codes de résultats et des messages de résultats normalisés est ^[1]:

Code	Message
1000	Commande exécutée avec succès
1001	Commande exécutée avec succès ; action en attente
1300	Commande exécutée avec succès ; aucun message
1301	Commande exécutée avec succès ; accusé de réception pour retrait de la file d'attente
1500	Commande exécutée avec succès ; fin de la session
2000	Commande inconnue
2001	Erreur de syntaxe de la commande
2002	Erreur d'utilisation de la commande
2003	Paramètre obligatoire manquant
2004	Erreur de plage de valeurs de paramètre
2005	Erreur de syntaxe de la valeur du paramètre
2101	Commande non implémentée
2102	Option non implémentée
2103	Extension non implémentée
2104	Échec de facturation
2105	L'objet n'est pas éligible au renouvellement
2106	L'objet n'est pas éligible au transfert
2200	Erreur d'authentification
2201	Erreur d'autorisation
2202	Informations d'autorisation invalides
2300	Objet en attente de transfert
2301	Objet non en attente de transfert
2302	L'objet existe
2303	L'objet n'existe pas.
2304	L'état de l'objet interdit l'opération
2305	L'association d'objets interdit le fonctionnement
2306	Erreur de stratégie de valeur de paramètre
2307	Service d'objet non implémenté
2308	violation de la politique de gestion des données
2400	La commande a échoué
2500	La commande a échoué ; le serveur ferme la connexion.
2501	Erreur d'authentification ; le serveur ferme la connexion
2502	Limite de session dépassée ; le serveur ferme la connexion.

Notes et références

1 2 3 4 5 6 (en) Hollenbeck, « Extensible Provisioning Protocol (EPP) », août 2009 (ISSN 2070-1721, DOI 10.17487/RFC5730)

Liens

(en) RFC 5730^[1] - Extensible Provisioning Protocol (EPP) (remplace la RFC 4930^[2])
(en) RFC 5731^[3] - Extensible Provisioning Protocol (EPP) l'objet Domain (remplace la RFC 4931^[4])
(en) RFC 5732^[5] - Extensible Provisioning Protocol (EPP) l'objet Host (remplace la RFC 4932^[6])
(en) RFC 5733^[7] - Extensible Provisioning Protocol (EPP) l'objet Contact (remplace la RFC 4933^[8])
(en) RFC 5734^[9] - Extensible Provisioning Protocol (EPP) Transport par TCP (remplace la RFC 4934^[10])

Portail de l’informatique

Portail d’Internet

[:0-1] 1 2 3 4 5 6 (en) Hollenbeck, « Extensible Provisioning Protocol (EPP) », août 2009 (ISSN 2070-1721, DOI 10.17487/RFC5730)

[RFC-5730-2] (en) Request for comments n^o 5730

[RFC-4930-3] (en) Request for comments n^o 4930

[RFC-5731-4] (en) Request for comments n^o 5731

[RFC-4931-5] (en) Request for comments n^o 4931

[RFC-5732-6] (en) Request for comments n^o 5732

[RFC-4932-7] (en) Request for comments n^o 4932

[RFC-5733-8] (en) Request for comments n^o 5733

[RFC-4933-9] (en) Request for comments n^o 4933

[RFC-5734-10] (en) Request for comments n^o 5734

[RFC-4934-11] (en) Request for comments n^o 4934

[1]

[1]

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]