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.
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.
La liste complète des codes de résultats et des messages de résultats normalisés est : 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.
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.
La liste complète des codes de résultats et des messages de résultats normalisés est :