epp à l’afnic- 2 - epp à l’afnic spécifications rc 1.0 - 30/06/08 table des matières 1....

- 1 -

EPP à l’AFNIC Spécifications RC 1.0 - 30/06/08

EPP à l’AFNIC

Draft V1.5 (Release Candidate 1)

Version du 30 juin 2008

- 2 -


T a b l e d e s m a t i è r e s

1. Généralités à propos d’EPP à l’AFNIC ......................................4

1.1. Tous les contacts auront un Nic-Handle.................................. 4

1.2. Le processus d’identification se fera sur les titulaires, plus sur les domaines .................................................................................. 4

1.3. Les objets "contact" de type "role" et les objets "mntner" (maintainer) seront en état "deprecated"........................................... 4

1.4. Les tests ZoneCheck ne seront liés qu’à un seul type d’opération............................................................................................ 5

1.5. Nous n’implémenterons pas les objets "host" (RFC 4932).... 5

1.6. Cas des opérations avec code retour 1000 et comportement du serveur en cas de problème .......................................................... 5

1.7. Cohabitation des communautés "formulaires-only" et "EPP-only" pour la gestion des mots de passe des noms de domaine ... 6

1.8. Choix d’implémentation de la liste des messages de notification ............................................................................................ 6

2. Gestion des noms de domaine................................................7

2.1. Créer un nom de domaine ......................................................... 7 2.1.1. Dépôt "direct" d’un nom de domaine ............................................................. 7 2.1.2. Dépôt "en 2 temps" d’un nom de domaine .................................................. 10 2.1.3. Après la création… ......................................................................................... 11

2.2. Modifier les attributs d’un nom de domaine.......................... 11 2.2.1. Modification de la liste des contacts ............................................................ 12 2.2.2. Modification de la configuration des serveurs de noms ............................ 13 2.2.3. Modification de l’état du domaine et/ou de son mot de passe................... 16 2.2.4. Suivre le déroulement d’une modification technique ................................. 18

2.3. Supprimer (et restaurer) un nom de domaine ....................... 21 2.3.1. La suppression................................................................................................ 21 2.3.2. La restauration ................................................................................................ 22

- 3 -


2.4. Changement de délégation d’un nom de domaine (<transfer>).......................................................................................... 23

2.4.1. Demander un changement de délégation..................................................... 24 2.4.2. Suite des opérations pour le bureau gestionnaire ...................................... 26 2.4.3. Suite des opérations pour le bureau repreneur........................................... 29 2.4.4. Utilisation de la commande <domain:transfer> en consultation............... 32

2.5. Transmission volontaire d’un nom de domaine (<trade>) ... 32 2.5.1. Demander une transmission volontaire ....................................................... 32 2.5.2. Suivre une transmission volontaire .............................................................. 35 2.5.3. Utilisation de la commande <trade> en consultation.................................. 39

2.6. Transmission forcée d’un nom de domaine (<recover>) ..... 39 2.6.1. Demander une transmission forcée.............................................................. 39 2.6.2. Utilisation de la commande <recover> en consultation ............................. 42

2.7. Vérification de la disponibilité d’un nom de domaine .......... 42

2.8. Récupération des données associées à un nom de domaine 46

2.8.1. Détail de la partie "classique" de la réponse ............................................... 47 2.8.2. Détails des extensions possibles de la réponse ......................................... 50

3. Gestion des contacts..............................................................51

3.1. Créer un contact ....................................................................... 52

3.2. Modifier un contact .................................................................. 57

3.3. Supprimer un contact .............................................................. 59

3.4. Identification d’un contact titulaire......................................... 59

3.5. Récupération des données associées à un contact ............. 60

- 4 -


1. Généralités à propos d’EPP à l’AFNIC

Avant de décrire plus précisément chaque type d’opération pour les différents types d’objets, voici quelques modifications majeures que nous proposons de mettre en œuvre parallèlement à la mise en place de cette nouvelle interface et qui sont communes aux différents cas présentés.

1.1. Tous les contacts auront un Nic-Handle

De manière à proposer une gestion homogène de tous les contacts, nous avons décidé de tous leur associer un Nic-Handle. Si cela ne change rien pour les différents contacts techniques, administratifs et titulaire de domaine Personne Physique (PP), cela n’existe pas pour les titulaires de type Personne Morale (PM). Un plan de migration sera donc à prévoir pour quelques centaines de milliers de contacts. Une conséquence de ce choix est que les objets "contact" doivent exister avant toute utilisation (ce qui n’est pas obligatoire avec le traitement actuel par formulaires où ils peuvent être créés "à la volée"), par contre cela ne changera rien aux règles actuellement en vigueur pour ces objets lors du dépôt des noms de domaine.

1.2. Le processus d’identification se fera sur les titulaires, plus sur les domaines

Tout comme pour les titulaires de type PP auxquels on associe ce que nous appelons un bloc invariant, un mécanisme similaire sera appliqué pour les titulaires de type PM. Ceci permettant, dans un premier temps d’offrir une gestion homogène des titulaires de noms de domaine, quelque soit leur "univers", et dans un second temps, d’imaginer une identification du titulaire d’un nom de domaine plutôt que dudit nom de domaine. Ceci devrait permettre, entre autres, la mise en place d’identification par lot (les règles éventuellement spécifiques à ces traitements par lot seront précisées ultérieurement).

1.3. Les objets "contact" de type "role" et les objets "mntner" (maintainer) seront en état "deprecated"

Ces objets pourront toujours être utilisés, en particulier, les contacts de type "role" qui pourront toujours être référencés comme contacts technique pour les noms de domaine mais leur usage ne sera plus rendu obligatoire et aucune extension EPP ne sera prévue pour en assurer le traitement (création, modification, …). À terme, on peut même prévoir de les rendre obsolètes, c'est-à-dire qu’ils seront toujours dans nos bases mais ne pourraient plus être utilisés dans de nouvelles opérations. Leur suppression pouvant intervenir dès lors qu’ils ne seraient plus référencés nulle part.

- 5 -


1.4. Les tests ZoneCheck ne seront liés qu’à un seul type d’opération

Afin d’assurer un traitement plus fluide des opérations et pour répondre aux demandes des bureaux d’enregistrement de ne faire ces tests techniques qu’en cas d’absolue nécessité, nous avons décidé d’exclure de toute opération (à l’exception d’une commande de mise à jour décrite plus loin) la présence de configuration DNS. Les trois impacts les plus visibles étant que la réservation d’un nom de domaine devient possible (il est créé et facturé même si il n’y a pas de publication DNS), que la création/publication DNS se fera dorénavant en 2 phases et que les transferts et autres transmissions ne seront plus bloqués pour des problèmes de configuration technique.

1.5. Nous n’implémenterons pas les objets "host" (RFC 4932)

Ce concept étant assez éloigné de la gestion de l’AFNIC des serveurs de noms (de nombreux ccTLDs ont choisi la même voie), nous adopterons la méthode où les serveurs de noms sont des attributs du nom de domaine.

1.6. Cas des opérations avec code retour 1000 et comportement du serveur en cas de problème

Une précaution est nécessaire lors du développement de clients qui se connecteront à notre serveur EPP. En effet, nous indiquons à plusieurs reprises dans la description détaillée des opérations disponibles que telle ou telle opération sur un nom de domaine ne renverra qu’un code retour 1000. Il faut comprendre cela comme étant le comportement attendu dans des conditions normales de fonctionnement de la chaîne d’enregistrement des noms de domaine. Cette chaîne est actuellement composée de modules indépendants et toute opération qui est validée par le premier module de celle-ci doit être menée à son terme et ne peut être annulée. L’architecture de cette chaîne pourrait être revue, mais ce serait un projet indépendant de l’interface EPP et nous devons donc tenir compte du comportement actuel lors de l’écriture de notre serveur EPP. Ce qu’il est donc prévu de faire, c’est que tout problème détecté sur la chaîne d’enregistrement rendra celle-ci indisponible le temps que celui-ci soit résolu. Toute opération en cours censée renvoyer un code retour 1000 et affectée par le problème renverra un code retour 1001. Aucune nouvelle opération de type "transform" sur les domaines ne pourra être prise en compte et un message d’erreur "command failed" (code 2400) sera retourné. Si le problème ne touche "que" la chaîne d’enregistrement, les opérations sur les objets "contact", les consultations des files de notifications et les opérations EPP de type "query" ne devraient pas être affectées.

- 6 -


1.7. Cohabitation des communautés "formulaires-only" et "EPP-only" pour la gestion des mots de passe des noms de domaine

Le protocole EPP prévoit l’utilisation d’un mot de passe pour les noms de domaine qui sera utilisé dans le cadre des opérations de changement de délégation. Ce concept n’existe pas à l’AFNIC et il sera donc nécessaire de modifier nos structures de données et d’initialiser nos bases de données pour associer à tous les domaines qui existent déjà un mot de passe unique. Les opérations que nous décrivons par la suite vont permettre aux bureaux d’enregistrement qui utiliseront notre serveur EPP de récupérer les mots de passe de tout leur portefeuille de domaines et de modifier ceux-ci si nécessaire. En revanche, il est nécessaire d’offrir un minimum d’outils aux bureaux qui n’auront pas la possibilité de migrer vers EPP pour récupérer facilement cette information. Au minimum, nous prévoyons de rendre cette information accessible via l’espace web sécurisé de chaque bureau d’enregistrement. De plus, compte tenu de l’utilisation obligatoire de ce mot de passe pour tout changement de délégation, une nouvelle règle (les contours exacts seront définis ultérieurement) imposera la mise à disposition de ce code par le bureau gestionnaire du nom de domaine dans un délai de 5 jours à compter de la date de la demande par son client. Ce mode de fonctionnement implique de plus la disparition de la procédure d’enquête actuelle utilisée pour vérifier l’identité d’un titulaire lors d’un changement de délégation.

1.8. Choix d’implémentation de la liste des messages de notification

Nous avons choisi d’indiquer lors de n’importe quelle réponse du serveur le nombre de messages dans la file d’attente (à moins qu’il n’y ait aucun message, auquel cas, cette information ne doit pas être fournie). Le RFC 4930 n’oblige à fournir cette information que dans le cas des réponses aux commandes <poll> alors qu’elle est optionnelle pour les autres types de commandes. Concrètement, cela implique que dès qu’un message doit être notifié à un bureau d’enregistrement, celui-ci en sera averti par la présence de l’élément <msgQ> présent dans les réponses à toutes les commandes envoyées au serveur. Il est vivement conseillé de prendre connaissance de ces messages au fur et à mesure que ceux-ci arrivent puisqu’au milieu des messages de suivi d’opérations de modifications techniques par exemple peuvent très bien se trouver des demandes de changement de délégation auxquelles il pourrait être intéressant de répondre (de manière positive ou négative, peu importe).

- 7 -


2. Gestion des noms de domaine

2.1. Créer un nom de domaine

Le protocole EPP (RFC 4930) permet la création de noms de domaine (RFC 4931). Voici ce que cela suppose en termes d’adaptation par rapport aux formulaires que nous utilisons et en spécificités par rapport au mapping standard. Même si nous essaierons, dans la mesure du possible de ne pas complexifier nos procédures, il convient de distinguer 2 types de dépôts, chacun ayant sa spécificité. Le premier type de dépôt, nous pourrons le qualifier de "direct", il ne pourra s’appliquer que sur des noms de domaine en .fr, .re, .com.fr, .com.re, .asso.fr, .asso.re, .nom.fr, .nom.re, .tm.fr, .prd.fr et presse.fr pour lesquels aucune convention de nommage ne s’applique (domaines dits descriptifs). Le second type de dépôt, qui sera forcément un peu plus "complexe" pourra être qualifié de "dépôt en 2 temps", il concernera les noms de domaine pour lesquels des conventions de nommage existent, les noms dans des domaines sectoriels tels que .notaires.fr ou encore les noms de domaine réservés tels que les noms de commune. Nous proposons d’ailleurs d’étendre le mécanisme utilisé pour les noms de communes à ces différents types de domaines. Malgré des spécificités que nous indiquerons ci-après, ce qui ne change pas et qui a été brièvement évoqué précédemment, c’est le fait que dorénavant la création d’un nom de domaine devra se faire en 2 étapes si l’on souhaite aboutir à un résultat similaire à ce que l’on peut faire aujourd’hui grâce à un formulaire de création. En effet, la création via EPP devra être vue comme une opération de réservation. Ce sera un état fini, donnant lieu à une publication dans le Whois et à la facturation du domaine traité. La publication DNS ne pourra être réalisée qu’au terme d’une seconde étape.

2.1.1. Dépôt "direct" d’un nom de domaine

Ce cas représentera 99,99% des opérations de création et nous allons voir que compte tenu des choix que nous avons fait (contacts avec Nic-Handles, gestion différente des configurations DNS), il n’y a pas beaucoup d’informations à fournir pour ce type d’opération. En ce qui concerne les Nic-Handles, d’un point de vue EPP, XX12345-FRNIC est un ROID (Repository Object Identifier) et ce n’est pas ce qui est censé être utilisé comme référence pour les objets "contact". En toute logique, un objet "contact" est référencé uniquement avec la "partie gauche" du Nic-Handle, à savoir ce dernier sans le " -FRNIC". Il se trouve qu’il existe encore dans notre base des contacts construits à l’aide d’un autre suffixe que "FRNIC", mais ce problème a été anticipé et ils ont depuis longtemps été rendus obsolètes et plus aucun d’entre eux n’est aujourd’hui référencé. Leur éradication prévue au cours des prochains mois nous

- 8 -


permettra de n’avoir qu’un seul suffixe nous permettant ainsi d’appliquer sereinement la règle décrite dans le RFC sur le traitement des ROID à savoir d’utiliser dans les commandes, telle que celle décrite ici, des Nic-Handles sans le "-FRNIC". Un autre point à noter sur les Nic-Handle… Puisqu’il est prévu de "déprécier" les contacts de type "role", les règles type "le premier contact technique doit être un objet "role" n’ont bien entendu plus beaucoup de sens. Il n’est toutefois pas prévu, dans un premier temps en tout cas, d’interdire d’utiliser des Nic-Handles d’objets "contact" de type "role" pour référencer un contact (sauf a priori pour un titulaire, tout de même…). Voici les éléments qui devront être présents lors de la commande et leur description succincte. Bien entendu, l’absence d’éléments obligatoire et/ou la présence d’autres éléments renverraient une erreur.

• <domain:name> contiendra le nom de domaine complet (exemple-

ndd-epp.fr). • <domain:period> n’a pas vraiment de sens compte tenu de la gestion

actuelle des noms de domaine renouvelés par tacite reconduction. Mais compte tenu du fait qu’il est envisageable que les choses évoluent à ce niveau et que cet élément est pris en compte par de nombreux registres, il a été convenu de ne pas renvoyer d’erreur lorsqu’il est présent mais de n’accepter que 2 valeurs bien précises pour celui-ci.

• Soit <domain:period unit="y">1</domain:period> • Soit <domain:period unit="m">12</domain:period>

• <domain:registrant> contiendra l’identifiant du titulaire déduit du Nic-Handle de celui-ci auquel on aura retiré le suffixe (FRNIC) et le caractère séparateur "-".

• <domain:contact type="admin"> contiendra l’identifiant du contact administratif.

• <domain:contact type="tech"> contiendra l’identifiant d’un contact technique.

• <domain:authInfo> contiendra le mot de passe que le bureau d’enregistrement choisira d’associer à ce nom de domaine. Nous verrons que dans le cas de la création "en 2 temps", ce mot de passe sera imposé. Il n’est pas prévu dans l’immédiat de proposer un autre mécanisme que le mot de passe (<domain:pw>). Ce dernier étant libre, rien n’empêche un bureau d’enregistrement de mettre le même

Nom de l’élément Nombre d’occurrences <domain:name> 1 <domain:period> 0-1 <domain:registrant> 1 <domain:contact type="admin"> 1 <domain:contact type="tech"> 1-3 <domain:authInfo> 1 <domain:pw> 1 <clTRID> 0-1

- 9 -


mot de passe pour tous ses noms de domaine ou bien de faire en sorte que chaque nom de domaine en ait un différent. Il n’est pas non plus possible d’utiliser l’attribut "roid". De manière à ne pas être ambigu à ce niveau, son utilisation aura pour résultat de renvoyer une erreur.

• <clTRID> est optionnel mais pourrait tout à fait remplir la même fonction que le champ 1e du formulaire (lorsque celui-ci est utilisé pour indiquer une référence client, par pour le code d’autorisation, fonctionnalité prise en charge par un autre mécanisme).

Exemple de requête envoyée par le client :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <create> C: <domain:create C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-de-test-0001.fr</domain:name> C: <domain:period unit="y">1</domain:period> C: <domain:registrant>MM4567</domain:registrant> C: <domain:contact type="admin">NFC1</domain:contact> C: <domain:contact type="tech">NFC1</domain:contact> C: <domain:contact type="tech">VL</domain:contact> C: <domain:authInfo> C: <domain:pw>WarlordZ666</domain:pw> C: </domain:authInfo> C: </domain:create> C: </create> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Dans ce contexte de création "simple", si toutes les règles syntaxiques sont respectées, si le nom de domaine est libre, si celui-ci ne rentre pas en conflit avec une quelconque convention de nommage, n’est pas un nom de domaine réservé et que les identifiants de contacts existent et respectent les règles administratives adéquates… la création devrait correctement se passer et le serveur pourra envoyer une réponse avec comme code retour 1000. Pour être plus précis, en cas de succès pour le dépôt du nom de domaine, le seul code retour possible est 1000. Il ne pourra pas y avoir de code retour 1001 pour ce type de dépôt. À noter, dans la réponse du serveur les dates de création et d’expiration (<domain:crDate> et <domain:exDate>), cette dernière étant donnée à titre indicatif et pour être cohérent avec l’élément <domain:period> lorsque celui-ci est fourni par le client. Exemple de réponse envoyée par le serveur :

- 10 -


S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <domain:creData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:crDate>2008-12-25T00:00:00.0Z</domain:crDate> S: <domain:exDate>2009-12-25T00:00:00.0Z</domain:exDate> S: </domain:creData> S: </resData> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000001</svTRID> S: </trID> S: </response> S:</epp>

2.1.2. Dépôt "en 2 temps" d’un nom de domaine

Ce cas va se rencontrer lors du dépôt d’un de domaine lié à une commune, par exemple. Aujourd’hui, une telle opération nécessite d’obtenir un code d’autorisation qui doit ensuite être utilisé dans le formulaire en remplissant le champ 1g. Si le processus d’obtention de ce code n’est pas l’objet du présent document, il est important de noter que celui-ci va subir quelques aménagements. En effet, compte tenu de la nouvelle gestion des contacts par référence et comme nous avons décidé de ne plus restreindre son utilisation aux seuls noms de commune, le bureau d’enregistrement qui voudra obtenir un code d’autorisation devra préalablement créer un objet "contact" qui sera le titulaire du nom de domaine puis faire la demande de ce code qui sera associé au nom de domaine et au contact précédemment créé. Nous passons donc d’un modèle où le code d’autorisation était associé au couple (bureau d’enregistrement, nom de domaine) à celui où ce code est associé au triplet (bureau d’enregistrement, nom de domaine, Nic-Handle du titulaire). Une fois que le code sera créé, le dépôt du nom de domaine se fera pratiquement comme ce que nous avons décrit lors du dépôt "direct" à 2 nuances près. La première c’est que l’identifiant du titulaire n’est pas libre mais doit correspondre à celui associé au code d’autorisation, la seconde c’est que le code d’autorisation devra être utilisé en lieu et place du mot de passe dans l’élément <domain:authInfo>, ce dernier n’étant donc plus libre. Par contre, rien n’empêchera de le modifier par la suite. Il est à noter que cela ne change rien au reste de la requête et que le traitement de celle-ci est soumis aux mêmes règles que le cas précédemment décrit. Ceci impliquant, entre autres, que nous nous trouvons dans le cas où un dépôt réussi générera une réponse avec un code retour 1000 (c’est pour cette raison que la réponse du serveur n’est pas reproduite).

- 11 -


Exemple de requête envoyée par le client :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <create> C: <domain:create C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-reserve-0001.fr</domain:name> C: <domain:period unit="m">12</domain:period> C: <domain:registrant>MM4567</domain:registrant> C: <domain:contact type="admin">NFC1</domain:contact> C: <domain:contact type="tech">NFC1</domain:contact> C: <domain:contact type="tech">VL</domain:contact> C: <domain:authInfo> C: <domain:pw>NDCR20080229T173000.123456789</domain:pw> C: </domain:authInfo> C: </domain:create> C: </create> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

2.1.3. Après la création…

Une fois le domaine créé, il est consultable en utilisant la commande <domain:info> et est visible dans le Whois (un délai de propagation supplémentaire est possible compte tenu de l’architecture de réplication des bases de données mise en place, mais dans des conditions optimales, la synchronisation des données se fait au fil de l’eau). La publication DNS passe par une procédure totalement indépendante, il est nécessaire d’envoyer une commande de modification sur ce nom de domaine. La procédure complète est expliquée après. Bien que le processus d’identification soit désormais déplacé sur le titulaire, celui-ci impacte sur l’état du nom de domaine une fois ce dernier créé. En effet, si le titulaire est déjà "identifié", le domaine sera dans l’état "ok", dans le cas contraire, celui-ci sera dans l’état "serverTransferProhibited".

2.2. Modifier les attributs d’un nom de domaine

Nous allons traiter ici de l’équivalent de ce que nous appelons aujourd’hui "modification administrative" (code opération A dans les formulaires 1.7.4 et 2.0.0) et "modification technique" (code opération T dans les formulaires 1.7.4 et 2.0.0). Pour des raisons que nous avons déjà abordées (tests techniques via ZoneCheck) ou que nous allons expliquer par la suite, nous avons choisi de définir 3 types de modifications bien distinctes via la même commande EPP, à savoir la commande <domain:update>. Dans un cas la modification portera sur les contacts associés à un nom de domaine (technique et/ou administratifs), dans un autre, uniquement sur la configuration DNS et dans le dernier cas, uniquement sur l’état du nom de domaine et le mot de passe qui lui est associé.

- 12 -


2.2.1. Modification de la liste des contacts

La modification de la liste des contacts associés à un nom de domaine, qu’ils soient techniques et/ou administratifs va passer par une commande <domain:update>. Bien qu’EPP et le mapping domain prévoient la modification du titulaire du nom de domaine par le biais de cette commande, nous n’autoriserons pas cette action. Un changement de titulaire passera par la commande <trade> que nous traiterons un peu plus loin dans ce document. Il est important de garder à l’esprit que les modifications sur les listes de contacts ne doivent pas transgresser les règles d’occurrences indiquées dans la section sur la création d’un nom de domaine. En effet, la commande <domain:update> permettant l’utilisation de 2 sous-commandes <domain:add> et <domain:rem>, toute suppression d’un contact amenant la disparition de ce type de contact pour le domaine doit s’accompagner de l’ajout d’un autre contact de ce même type. Par exemple, la règle actuelle qui veut qu’il n’y ait qu’un contact administratif pour un nom de domaine se traduit lors de la modification de celui-ci par la suppression du contact actuel et l’ajout d’un nouveau, dans la même commande EPP (l’exemple que nous donnerons plus loin reprendra ce cas). Chaque élément <domain:add> et <domain:rem> pourra contenir des éléments de type <domain:contact> (déjà présentés dans la section "créer un nom de domaine"). Si un même contact est présent en même temps dans <domain:add> et <domain:rem>, la commande est acceptée, les 2 opérations s’annulent et les autres modifications indiquées dans la commande sont prises en compte normalement. Concrètement, une commande indiquant l’ajout des contacts techniques VL et MS ainsi que la suppression du contact technique VL sera équivalente à une commande indiquant uniquement l’ajout du contact technique MS. Si nous reprenons l’exemple du nom de domaine précédemment créé auquel nous souhaiterions ajouter un troisième contact technique et modifier le contact administratif, voici la requête XML qui sera envoyée.

- 13 -


C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <update> C: <domain:update C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-de-test-0001.fr</domain:name> C: <domain:add> C: <domain:contact type="admin">VL</domain:contact> C: <domain:contact type="tech">JP</domain:contact> C: </domain:add> C: <domain:rem> C: <domain:contact type="admin">NFC1</domain:contact> C: </domain:rem> C: </domain:update> C: </update> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Exemple de réponse envoyée par le serveur (pour ce type de commande, le code retour sera toujours 1000) :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000002</svTRID> S: </trID> S: </response> S:</epp>

2.2.2. Modification de la configuration des serveurs de noms

Nous avons déjà eu l’occasion de l’indiquer, la gestion de la configuration DNS pour un nom de domaine fait partie des points qui seront les plus impactés par la nouvelle procédure d’enregistrement que nous présentons dans le présent document. La sémantique même de la commande est légèrement modifiée puisque celle-ci ne permettra pas uniquement de modifier une configuration existante puisque les domaines nouvellement créés n’en auront tout simplement pas. Elle sera donc utilisée pour indiquer une configuration DNS initiale pour un nom de domaine qui n’en aurait pas encore ou pour modifier une configuration DNS existante. Contrairement à l’ancienne modification technique qui permettait de modifier dans un unique formulaire contacts techniques et configuration

- 14 -


DNS, nous avons décidé que toute opération sur les serveurs de noms se ferait de manière autonome et selon un scénario expliqué ci-après. La commande est envoyée par le client (pour simplifier, nous considèrerons que celle-ci est syntaxiquement correcte et que les glues nécessaires sont bien présentes), le format retenu pour les serveurs de noms étant celui où ces derniers sont des attributs de l’objet "domain" et non pas des références sur des objets "host" (RFC 4932). Lorsque la commande est traitée, le serveur renvoie un code retour 1001 indiquant que celle-ci est prise en compte. Dans le même temps, l’état "pendingUpdate" est appliqué au nom de domaine. Une fois que l’outil ZoneCheck a réalisé les tests nécessaires à la validation de la configuration technique, l’état "pendingUpdate" est supprimé et deux cas peuvent se présenter :

• La configuration est OK et dans ce cas elle est directement visible dans le Whois et peut être publiée au prochain rechargement du fichier de zone (à moins que l’état "clientHold" ou "serverHold" ne soit positionné, empêchant ainsi la publication DNS).

• La configuration est KO et elle est tout simplement ignorée. Rien n’est modifié dans le Whois ou dans les DNS.

La commande <poll> sera utilisée pour connaître le résultat de l’opération de mise à jour. Une notification sera émise quelque soit le résultat final du ZoneCheck. ATTENTION : La gestion des serveurs de noms via l’interface EPP en utilisant le mapping domain standard nous pose un problème si l’on considère les règles de vérifications de ZoneCheck. En effet, actuellement, on distingue le serveur de noms primaire des serveurs de noms secondaires. Cette différenciation primaire/secondaire n’a pas été conservée (Ce n’est pas EPP qui nous oblige à modifier cette règle, mais une réflexion interne menée en parallèle pourrait remettre en cause quelques principes de cet outil. Si cette règle doit être modifiée, il serait dommage de ne pas en tenir compte dès maintenant, compte tenu que son maintient nous obligerait à mettre en place une technique de contournement qui pourrait être abandonnée peu de temps après), nous n’en tiendrons donc pas compte. Une mise à jour de ce document serait par contre nécessaire dans l’hypothèse où cette règle devait être finalement conservée. La commande <domain:update> qui sera utilisée ne pourra contenir que les éléments <domain:add> et/ou <domain:rem>. Le premier contenant les informations nécessaires pour ajouter un ou plusieurs serveurs de noms à la configuration existante, le second permettant de supprimer un ou plusieurs serveurs de noms. La modification d’un serveur de noms pour mettre à jour les glues qui lui seraient affectées passe par sa présence dans <domain:rem> (juste le nom du serveur) et dans <domain:add> (avec les nouvelles glues à appliquer). Nous l’avons déjà indiqué, nous n’implémenterons pas le RFC 4932, à savoir les objets de type "host" permettant de référencer les serveurs de

- 15 -


noms. Nous utiliserons la possibilité de décrire les serveurs de noms comme attributs des objets "domain". Chacun des éléments <domain:add> et <domain:rem> ne pourra contenir que l’unique élément <domain:ns> (plusieurs occurrences de celui-ci sont bien entendu possibles), toute présence d’un autre élément amenant ainsi la confusion sur le type de modification demandée entraînera une erreur. De même, chaque élément <domain:ns> ne sera composé que d’une collection d’éléments <domain:hostAttr>. Voici les sous éléments qui seront présents dans l’élément <domain:hostAttr> et leur description succincte. Bien entendu, l’absence d’éléments obligatoire et/ou la présence d’autres éléments renverrait une erreur.

Nom de l’élément Nombre d’occurences

<domain:hostName> 1 <domain:hostAddr ip="v4"> 0-n <domain:hostAddr ip="v6"> 0-n

• <domain:hostName> contiendra le nom de domaine complet du

serveur de noms. • <domain:hostAddr ip="v4"> contiendra une adresse IPv4 à

associer au serveur de noms lorsqu’une glue est nécessaire (uniquement pour <domain:add>, interdit pour <domain:rem>).

• <domain:hostAddr ip="v6"> contiendra une adresse IPv6 à associer au serveur de noms lorsqu’une glue est nécessaire (uniquement pour <domain:add>, interdit pour <domain:rem>).

Il est bien entendu, que si la présence d’une glue s’avère nécessaire, il n’est pas obligatoire de fournir des adresses ipv4 et des adresses ipv6. Une seule adresse, quelque soit son type, est suffisante (mais rien n’empêche d’en mettre plusieurs). Exemple de requête envoyée par le client après une création pour fournir la configuration initiale d’un nom de domaine :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <update> C: <domain:update C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-de-test-0001.fr</domain:name> C: <domain:add> C: <domain:ns> C: <domain:hostAttr> C: <domain:hostName>ns1.nic.fr</domain:hostName> C: </domain:hostAttr> C: <domain:hostAttr> C: <domain:hostName>ns2.nic.fr</domain:hostName> C: </domain:hostAttr> C: <domain:hostAttr>

- 16 -


C: <domain:hostName>ns.ndd-de-test-0001.fr</domain:hostname> C: <domain:hostAddr ip="v4">192.93.0.1</domain:hostAddr> C: <domain:hostAddr ip="v6">2001:660:3005:1::1:1</domain:hostAddr> C: </domain:hostAttr> C: </domain:ns> C: </domain:add> C: </domain:update> C: </update> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Sur les commandes de type <domain:update>, les réponses envoyées par le serveur sont assez succinctes, c'est-à-dire qu’il n’y a pas d’élément <resData>. Par contre, on notera le code retour qui sera toujours égal à 1001 pour ce type de modification. Exemple de réponse envoyée par le serveur :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1001"> S: <msg>Command completed successfully; action pending</msg> S: </result> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000003</svTRID> S: </trID> S: </response> S:</epp>

2.2.3. Modification de l’état du domaine et/ou de son mot de passe

Le type de modification que nous proposons ici n’est pas une variante de ce qui existait avant EPP, comme c’est le cas de ce que nous venons de décrire, mais bien d’une nouvelle fonctionnalité. Ceci expliquant le fait que nous ayons souhaité la traiter de manière autonome. En effet EPP permet l’ajout ou la suppression de flags sur les noms de domaine. Tous ces flags ne sont pas pertinents dans notre contexte mais l’un d’entre eux permet d’offrir un service réclamé depuis longtemps et qui s’intègre parfaitement dans la logique des évolutions de notre système d’enregistrement. Il s’agit de la possibilité pour le bureau d’enregistrement de contrôler la publication DNS d’un nom de domaine. Ceci est complètement indépendant de la configuration DNS du nom de domaine concerné. Ce flag que le bureau d’enregistrement pourra positionner ou retirer est "clientHold". S’il est positionné, un nom de domaine, même s’il est associé à une configuration DNS validée par notre outil ZoneCheck, ne sera pas annoncé dans le DNS. À ce propos, quelques soient les modifications faites sur ce flag, cela ne déclenche aucune relance

- 17 -


des tests de vérification ZoneCheck. Les 2 processus sont réellement indépendants. Ce sont à nouveau les éléments <domain:add> et <domain:rem> qui sont utilisés pour ajouter/supprimer un flag. Ces éléments ne pourront contenir qu’un seul élément.


<domain:status s="clientHold"> 1

• <domain:status s="clientHold"> sera envoyé tel quel. Le RFC 4931 permet l’envoi d’un message clair associé à l’élément <domain:status> ainsi que l’utilisation d’un attribut (lang) indiquant la langue de ce message. Ce message n’étant pas traité chez nous, l’élément doit être vide. Concernant la modification du mot de passe associé au nom de domaine, l’utilisation de l’élément <domain:chg> est nécessaire et bien que celui-ci puisse avoir comme éléments fils <domain:registrant> et <domain:authInfo>, seul ce dernier est accepté. La présence de l’élément <domain:registrant> entraînera un retour d’erreur de la part du serveur EPP. L’utilisation de <domain:authInfo> est tout à fait similaire à celle indiquée pour une opération de création. Exemple de requête pour interdire la publication DNS du nom de domaine précédemment créé et pour modifier son mot de passe (d’autant que dans le cas présent, puisqu’il s’agissait d’une création "en 2 temps", le mot de passe initial a été imposé par l’AFNIC) :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <update> C: <domain:update C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-reserve-0001.fr</domain:name> C: <domain:add> C: <domain:status s="clientHold"/> C: </domain:add> C: <domain:chg> C: <domain:authInfo> C: <domain:pw>PlusFortKeWarlordZ666</domain:pw> C: </domain:authInfo> C: </domain:chg> C: </domain:update> C: </update> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Exemple de réponse envoyée par le serveur (pour ce type de commande, le code retour sera toujours 1000, on notera aussi qu’un message est en attente

- 18 -


sur le serveur, certainement le résultat de la commande de modification des serveurs de noms pour le nom de domaine ndd-de-test-0001.fr) :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <msgQ count="1" id="50001"/> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000004</svTRID> S: </trID> S: </response> S:</epp>

2.2.4. Suivre le déroulement d’une modification technique

Grâce au mécanisme de notification prévu dans EPP, nous allons avoir la possibilité de connaître le résultat d’une demande de modification technique en utilisant la commande <poll>. Il y a bien d’autres méthodes pour savoir si une modification technique a été prise en compte, une des plus évidentes étant de faire une requête sur le serveur Whois ou bien d’envoyer une commande <domain:info> au serveur EPP, mais la notification sera de toute façon placée dans la file d’attente prévue à cet effet et il sera nécessaire de la dépiler pour accéder aux autres messages de cette file. Bien entendu, une notification sera placée dans la file d’attente, que le résultat soit positif ou négatif. Ne pas en tenir compte immédiatement n’aura aucun effet sur le processus de publication DNS, elle n’est là qu’à titre d’information. Exemple de requête pour récupérer le message en attente : C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <poll op="req"/> C: <clTRID>une-autre-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Dans la réponse envoyée, indépendamment du résultat de la commande qui est connu grâce à l’attribut "paResult", nous fournissons le résultat du ZoneCheck dans l’élément <msg>. Une balise XML a été ajoutée à cet effet, <resZC> avec un attribut "type" qui pour le moment ne peut prendre qu’une unique valeur, à savoir "plain-text". Des évolutions futures nous permettraient peut-être de structurer de manière un peu plus fine ce résultat, nous y reviendrions en temps voulu.

- 19 -


Exemple de réponse envoyée par le serveur pour une mise à jour technique acceptée :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50001"> S: <qDate>2008-12-25T00:01:00.0Z</qDate> S: <msg> S: <resZC type="plain-text"> S: ZONE : ndd-de-test-0001.fr. S: NS : ns1.nic.fr. S: NS : ns2.nic.fr. S: NS : ns.ndd-de-test-0001.fr. [192.93.0.1, 2001:660:3005:1::1:1] S: S: ==> SUCCESS S: </resZC> S: </msg> S: </msgQ> S: <resData> S: <domain:panData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="1">ndd-de-test-0001.fr</domain:name> S: <domain:paTRID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000003</svTRID> S: </domain:paTRID> S: <domain:paDate>2008-12-25T00:01:00.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <clTRID>une-autre-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000005</svTRID> S: </trID> S: </response> S:</epp>

Exemple de la même réponse envoyée par le serveur mais dans le cas où la mise à jour technique n’a pas pu être acceptée suite à une erreur de ZoneCheck :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50001"> S: <qDate>2008-12-25T00:01:00.0Z</qDate> S: <msg> S: <resZC type="plain-text"> S: ZONE : ndd-de-test-0001.fr. S: NS : ns1.nic.fr. S: NS : ns2.nic.fr. S: NS : ns.ndd-de-test-0001.fr. [192.93.0.1, 2001:660:3005:1::1:1] S:

- 20 -


S: f> Server doesn't listen/answer on port 53 for UDP protocol S: => ns.ndd-de-test-0001.fr./192.93.0.1 S: S: ==> FAILURE S: </resZC> S: </msg> S: </msgQ> S: <resData> S: <domain:panData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="0">ndd-de-test-0001.fr</domain:name> S: <domain:paTRID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000003</svTRID> S: </domain:paTRID> S: <domain:paDate>2008-12-25T00:01:00.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <clTRID>une-autre-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000005</svTRID> S: </trID> S: </response> S:</epp>

Bien entendu, il est nécessaire de supprimer le message de la file d’attente, la consultation de celui-ci ne suffit pas à le dépiler… Bien que cela fasse partie intégrante du protocole EPP et que nous n’apportons aucune spécificité à ce niveau, nous allons indiquer la marche à suivre pour réaliser cette opération. La requête pour accuser réception de la prise en compte par le client du message qui se trouve dans la file d’attente sera la suivante :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <poll op="ack" msgID="50001"/> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Exemple de la réponse envoyée par le serveur (nous considérerons que c’était le seul message en attente):

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <msgQ count="0" id="50001"/> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000006</svTRID> S: </trID> S: </response> S:</epp>

- 21 -


La notification, positive ou négative, pour un changement de configuration technique clos cette opération. Si pour une raison ou une autre la configuration n’a put être validée par notre outil de vérification ZoneCheck (cas où paResult="0") et que le bureau d’enregistrement, après avoir appliqué les corrections nécessaires, souhaite que celle-ci soit prise en compte ; une nouvelle demande, avec la configuration complète souhaitée doit à nouveau être envoyée. Le système ne garde pas en mémoire les demandes qui n’ont pas réussies et ne va pas tenter de lancer des ZoneCheck jusqu’à ce que cela fonctionne…

2.3. Supprimer (et restaurer) un nom de domaine

La suppression d’un nom de domaine va s’accompagner d’un mécanisme de restauration qui fait son apparition à l’occasion de la mise en place de l’interface EPP. Ce mécanisme, bien que basé sur le RFC 3915, en limite le champ d’application en restreignant celui-ci au seul cas de l’opération de suppression. Les règles qui accompagnent cette procédure, en particulier les délais qui lui sont associés, ne font pas l’objet du présent document.

2.3.1. La suppression

La commande de suppression n’est pas modifiée par rapport à ce qui est décrit dans le RFC 4931, par contre, en cas de succès (il est certains cas où la suppression d’un nom de domaine ne sera pas possible, comme par exemple, le cas ou des serveurs de nom appartenant à ce domaine sont utilisés pour d’autres noms de domaine), le code retour ne sera plus 1000, mais 1001. L’état "pendingDelete" étant positionné pendant toute la durée de la "période de grâce" accordée et tant que le domaine n’est pas restauré ou définitivement supprimé. Exemple de la requête de suppression de notre domaine de test :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <delete> C: <domain:delete C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-de-test-0001.fr</domain:name> C: </domain:delete> C: </delete> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>


S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response>

- 22 -


S: <result code="1001"> S: <msg>Command completed successfully; action pending</msg> S: </result> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000005</svTRID> S: </trID> S: </response> S:</epp>

2.3.2. La restauration

La commande de restauration passe par une extension de la commande <domain:update>. Il ne faut surtout pas confondre ce type d’opération avec les autres possibilités décrites un peu plus haut dans ce document sur l’utilisation de cette commande pour modifier les contacts, la configuration DNS ou bien encore l’état d’un domaine. En effet une opération de restauration ne pourra pas s’accompagner d’une quelconque autre modification sur le nom de domaine concerné. Ce problème est contourné dans le RFC en obligeant qu’un des éléments de la commande <domain:update> soit présent mais vide… Mais, ce n’est pas conforme avec le fichier XSD associé, qui lui est norminatif. Nous avons donc fait le choix de suivre ce dernier et donc, contrairement à ce qu’indique le RFC 3915, une commande <domain:update> ne contenant que l’élément <domain:name>, associée à l’extension de la commande <domain:update> est la commande correcte à utiliser. L’extension de la commande <domain:update> décrite par le RFC 3915 ne passe que par l’ajout d’un élément <rgp:restore>. Par contre celui-ci possède un attribut "op" qui peut prendre 2 valeurs. Nous n’en accepterons qu’une seule, telle qu’indiqué dans le tableau ci-après.

Nom de l’élément Nombre d’occurences <rgp:restore op="request"> 1

Exemple de la requête de restauration de notre domaine de test :

- 23 -


C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <update> C: <domain:update C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-de-test-0001.fr</domain:name> C: </domain:update> C: </update> C: <extension> C: <rgp:update C: xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"> C: <rgp:restore op="request"/> C: </rgp:update> C: </extension> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Exemple de réponse envoyée par le serveur (pour ce type de commande, le code retour sera toujours 1000 et comme précisé dans le RFC, en cas de succès, l’attribut "s" de l’élément <rgp:rgpStatus> de l’extension doit avoir pour valeur "pendingRestore") :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <extension> S: <rgp:update S: xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0"> S: <rgp:rgpStatus s="pendingRestore"/> S: </rgp:update> S: </extension> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000006</svTRID> S: </trID> S: </response> S:</epp>

2.4. Changement de délégation d’un nom de domaine (<transfer>)

La commande <transfer> proposée par EPP permet un changement de bureau d’enregistrement uniquement. Si ce modèle est adapté à un registre comme VeriSign, nous ne pouvons pas l’utiliser tel quel. Quelques adaptations ont été nécessaires mais elles ne changent rien à l’esprit général de la commande. En ce qui concerne les restrictions d’accès pour l’utilisation de cette commande, le RFC 4930 fait des recommandations, mais celles-ci ne sont pas des

- 24 -


obligations. Pour éviter toute ambiguïté, le choix de l’AFNIC est de n‘autoriser le changement de délégation d’un nom de domaine qu’aux bureaux d’enregistrements qui ne gèrent pas celui-ci. L’acceptation et le rejet d’un changement de délégation ne peut être fait que par le bureau gestionnaire.

2.4.1. Demander un changement de délégation

Première petite modification par rapport au standard mais cohérent avec ce que nous avons déjà indiqué pour l’opération de création, l’élément <domain:pw> (lui-même élément de <domain:authInfo>) ne pourra pas être utilisé avec l’attribut "roid" pour indiquer que le mot de passe fourni est lié au titulaire ou à un contact associé au nom de domaine plutôt qu’au nom de domaine lui-même. Dans notre cas, le mot de passe ne peut être lié qu’au nom de domaine. Celui-ci devant être fourni au titulaire du nom de domaine par le bureau d’enregistrement gestionnaire sur simple demande pour permettre le changement de délégation vers un autre bureau d’enregistrement. La commande <domain:info> permettant au bureau gestionnaire de récupérer le mot de passe si jamais celui-ci l’avait égaré. Autre modification, lors du changement de délégation, le titulaire sera cloné chez le bureau d’enregistrement demandeur (à moins qu’un objet "contact" avec exactement les mêmes informations existe déjà chez ce bureau d’enregistrement). Attention, ce clonage interviendra après que le changement de délégation a été approuvé par le bureau d’enregistrement qui assurait la gestion du nom de domaine. Autre changement ; bien que cela soit prévu dans le RFC, la modification de la période de validité d’un nom de domaine ne pourra pas être faite et tout comme pour la création les même restrictions s’imposent sur l’élément <domain:period> toujours considéré comme un élément optionnel (dans un souci d’homogénéité, nous gardons exactement la même logique que pour l’opération de création). Par contre dans la réponse, comme le changement n’est validé qu’au terme de la procédure et donc que c’est à ce moment que la nouvelle date anniversaire est positionnée, nous ne pouvons pas l’anticiper, ce qui implique que l’élément <domain:exDate> sera absent de la réponse du serveur. Dernière modification, une extension est nécessaire pour permettre d’associer au nom de domaine transféré des contacts technique et administratif liés au bureau d’enregistrement qui demande le changement de délégation. Voici les éléments spécifiques que nous retrouverons dans la requête XML envoyée par le client.

Nom de l’élément Nombre d’occurrences

<domain:pw> 1 <frnic:contact type="admin"> 1 <frnic:contact type="tech"> 1-3

- 25 -


Exemple de la requête de changement de délégation envoyée par un bureau d’enregistrement sur notre nom de domaine ndd-de-test-0001.fr :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <transfer op="request"> C: <domain:transfer C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-de-test-0001.fr</domain:name> C: <domain:period unit="y">1</domain:period> C: <domain:authInfo> C: <domain:pw>WarlordZ666</domain:pw> C: </domain:authInfo> C: </domain:transfer> C: </transfer> C: <extension> C: <frnic:ext C: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.0"> C: <frnic:transfer> C: <frnic:domain> C: <frnic:contact type="admin">PR1249</frnic:contact> C: <frnic:contact type="tech">AI1</frnic:contact> C: <frnic:contact type="tech">PR1249</frnic:contact> C: </frnic:domain> C: </frnic:transfer> C: </frnic:ext> C: </extension> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

La réponse à cette demande de changement de délégation (si elle est syntaxiquement et sémantiquement acceptable) contiendra un certain nombre d’informations décrites dans le RFC 4931. Nous n’utiliserons pas d’extension pour la réponse. Voici la liste des éléments qui seront présents dans la réponse.

Nom de l’élément Nombre d’occurences <domain:name> 1 <domain:trStatus> 1 <domain:reID> 1 <domain:reDate> 1 <domain:acID> 1 <domain:acDate > 1

• <domain:name> contiendra le nom de domaine complet (exemple-

ndd-epp.fr). • <domain:trStatus> indique l’état de la requête. Ne peut contenir que

la valeur "pending". • <domain:reID> contient l’ID du bureau d’enregistrement qui fait la

demande.

- 26 -


• <domain:reDate> indique la date et l’heure de prise en compte de la demande.

• <domain:acID> contient l’ID du bureau d’enregistrement gestionnaire actuel.

• <domain:acDate> indique la date et l’heure limite de réponse attendue pour le gestionnaire actuel ("approve" ou "reject") avant que la procédure n’entre dans un processus automatique de traitement de la demande.


S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1001"> S: <msg>Command completed successfully; action pending</msg> S: </result> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:trStatus>pending</domain:trStatus> S: <domain:reID>BEdemandeurID</domain:reID> S: <domain:reDate>2008-12-25T00:00:00.0Z</domain:reDate> S: <domain:acID>BEactuelID</domain:acID> S: <domain:acDate>2009-01-02T00:00:00.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000007</svTRID> S: </trID> S: </response> S:</epp>

Bien entendu, si le nom de domaine s’était trouvé dans l’état "serverTransferProhibited" (ce sera le cas lors de la phase dite d’identification pour le titulaire du nom de domaine), il n’aurait pas été possible de demander un changement de délégation. Un code erreur 2106 aurait alors été retourné. La suite des opérations, à savoir l’acceptation ou le refus de la demande de changement de délégation par le bureau d’enregistrement gestionnaire, se fera en utilisant l’attribut "op" de la commande <transfer>. Tant que le changement de délégation ne sera pas terminé (quelque soit l’issue de cette opération), le domaine apparaîtra dans l’état "pendingTransfer".

2.4.2. Suite des opérations pour le bureau gestionnaire

Une difficulté dont il faut tenir compte est le fait que le bureau d’enregistrement qui assure la gestion du nom de domaine, au moment où la demande de changement de délégation est faite, ne supporte peut-être pas

- 27 -


EPP. Ce sera même un cas très fréquent lorsque l’interface EPP sera nouvellement mise en place, et cette situation devrait durer un certain temps. Lors du lancement de l’interface EPP, il est même prévu, pendant une durée qui reste à déterminer mais qui sera volontairement assez courte, que les bureaux d’enregistrement identifiés comme utilisateurs de cette interface reçoivent aussi le mail en plus des notifications de manière à migrer sans soucis d’une gestion par mails vers une gestion EPP. Dans ce cas de double canal, la première réponse valide, seule, compte. Accepter le changement de délégation via EPP et répondre au ticket "Attente Opposition" avec "ACTION=ACCORD" sont 2 opérations équivalentes. De même, refuser le changement de délégation via EPP et répondre au ticket "Attente Opposition" avec "ACTION=OPPOSITION" sont aussi 2 opérations équivalentes. Nous allons nous placer dans le cas qui nous intéresse, à savoir, le bureau gestionnaire utilise EPP pour gérer son portefeuille de noms de domaine. Un message est alors mis en attente et le bureau pourra avoir connaissance de cet ajout lors d’une prochaine commande puisque le compteur de messages incrémenté sera présent dans toute réponse du serveur à n’importe qu’elle requête du client. Le message va ressembler trait pour trait à la réponse qu’a reçu le bureau qui a fait la demande de changement de délégation. Exemple de requête pour récupérer le message en attente :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <poll op="req"/> C: <clTRID>une-reference-client-du-BEactuel-par-exemple</clTRID> C: </command> C:</epp>

Exemple de réponse envoyée par le serveur indiquant qu’un changement de délégation a été demandé pour le nom de domaine ndd-de-test-0001.fr :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50002"> S: <qDate>2008-12-25T00:02:00.0Z</qDate> S: <msg>Transfer requested.</msg> S: </msgQ> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:trStatus>pending</domain:trStatus> S: <domain:reID>BEdemandeurID</domain:reID> S: <domain:reDate>2008-12-25T00:00:00.0Z</domain:reDate> S: <domain:acID>BEactuelID</domain:acID> S: <domain:acDate>2009-01-02T00:00:00.0Z</domain:acDate> S: </domain:trnData>

- 28 -


S: </resData> S: <trID> S: <clTRID>une-reference-client-du-BEactuel-par-exemple</clTRID> S: <svTRID>frnic-00000008</svTRID> S: </trID> S: </response> S:</epp>

Nous ne reviendrons pas sur la procédure d’acquittement des messages de notifications, nous partons du principe que le bureau d’enregistrement gestionnaire a fait le nécessaire pour le dépiler. Le bureau a alors 3 options, soit approuver l’opération, soit la rejeter, soit ne rien faire… S’il ne fait rien, dans un délai égal à <domain:acDate> moins <domain:reDate>, soit 8 jours dans le cas présent, la demande est considérée comme acceptée. Pour accepter la demande de changement de délégation de manière explicite, le bureau gestionnaire doit envoyer la requête suivante au serveur (cette fois-ci l‘élément <domain:period> ne doit pas être présent sous peine de recevoir un message d’erreur et il n’y a pas d’extension à utiliser) :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <transfer op="approve"> C: <domain:transfer C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>ndd-de-test-0001.fr</domain:name> C: <domain:authInfo> C: <domain:pw>WarlordZ666</domain:pw> C: </domain:authInfo> C: </domain:transfer> C: </transfer> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Comme la possibilité d’accepter ou rejeter la demande de changement de délégation est réservée au bureau gestionnaire, on pourrait se passer de demander le mot de passe associé au domaine, mais dans un souci de cohérence celui-ci est obligatoire, quelque soit la valeur de l’attribut "op". Exemple de réponse envoyée par le serveur indiquant que l’acceptation du changement de délégation a bien été prise en compte (on notera le code retour 1000 dans ce cas, que l’état du "transfert" est maintenant "clientApproved" et que la date indiquée dans <domain:acDate> permet de connaître à quel moment le bureau gestionnaire a accepté le changement de délégation) :

- 29 -


S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:trStatus>clientApproved</domain:trStatus> S: <domain:reID>BEdemandeurID</domain:reID> S: <domain:reDate>2008-12-25T00:00:00.0Z</domain:reDate> S: <domain:acID>BEactuelID</domain:acID> S: <domain:acDate>2008-12-26T00:00:00.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000009</svTRID> S: </trID> S: </response> S:</epp>

Dans le cas où le bureau gestionnaire souhaite refuser l’opération de changement de délégation, il devra envoyer une requête similaire à la précédente en modifiant uniquement la valeur de l’attribut "op", celui-ci passant de "approve" à "reject". La réponse du serveur elle aussi sera très semblable à ce qui a été présenté dans le cas de l’acceptation. La différence se situant au niveau de l’état du transfert qui ne sera plus à "clientApprove", mais à "clientRejected". Lorsque la demande est rejetée, le délai initial de 8 jours est porté à 3 semaines et il est toujours possible au bureau gestionnaire d’accepter le changement de délégation suivant les modalités précédemment décrites. Au cours de ces 2 phases, dans le système actuel basé sur des échanges de mails, il est prévu d’envoyer des messages de relances. Ce mécanisme ne sera pas reconduit via notre interface EPP, les messages de notification ne seront pas dupliqués.

2.4.3. Suite des opérations pour le bureau repreneur

Deux cas peuvent se présenter pour le bureau d’enregistrement, soit le changement de délégation est accepté, soit il est refusé (sic). Dans tous les cas le bureau repreneur sera notifié dans sa file de messages du choix du bureau gestionnaire. En fait, un changement de délégation accepté va générer 2 entrées dans cette file d’attente (voir 3, mais nous reviendrons sur ce dernier message un peu plus loin), la première informant le bureau repreneur que l’opération a été acceptée par le bureau gestionnaire, la seconde indiquant le bon déroulement de la commande qu’il a passé. Concrètement, voici la séquence de messages qu’il faudra récupérer avec la commande <poll> (les commandes de requêtes et d’acquittements ne sont pas reproduites ici, seules les réponses du serveur sont indiquées).

- 30 -


Le premier message va reprendre le contenu de l’élément <domain:trnData> envoyé en réponse à la commande <transfer op="approve"> et que le bureau gestionnaire a reçu. On notera la valeur de <domain:acDate> par rapport à <qDate>, la seconde ne pouvant pas être postérieure à la première.

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="2" id="60001"> S: <qDate>2008-12-26T00:00:01.0Z</qDate> S: <msg>Transfer approved.</msg> S: </msgQ> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:trStatus>clientApproved</domain:trStatus> S: <domain:reID>BEdemandeurID</domain:reID> S: <domain:reDate>2008-12-25T00:00:00.0Z</domain:reDate> S: <domain:acID>BEactuelID</domain:acID> S: <domain:acDate>2008-12-26T00:00:00.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <svTRID>frnic-00000010</svTRID> S: </trID> S: </response> S:</epp>

Le second message dans la file de d’attente est le résultat de la commande initiale à laquelle le serveur avait répondu par un code retour 1001.

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="60002"> S: <qDate>2008-12-26T00:01:00.0Z</qDate> S: <msg>Transfer completed.</msg> S: </msgQ> S: <resData> S: <domain:panData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="1">ndd-de-test-0001.fr</domain:name> S: <domain:paTRID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000007</svTRID> S: </domain:paTRID> S: <domain:paDate>2008-12-26T00:01:00.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID>

- 31 -


S: <svTRID>frnic-00000012</svTRID> S: </trID> S: </response> S:</epp>

En cas de refus du bureau gestionnaire, ce second message ne sera pas présent puisque la commande n’est pas terminée. Voici le message qui sera dans la file d’attente à la place de celui indiquant que le changement de délégation a été accepté. On notera la valeur de <domain:acDate> qui reflète l’extension du délai accordé au bureau gestionnaire, celui-ci passant de 8 jours à 3 semaines… Au cours de cette période, ce dernier peut à tout moment approuver le changement de délégation (générant la séquence de message précédemment indiquée), le domaine étant dans l’état "pendingTransfer".

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="60001"> S: <qDate>2008-12-26T00:00:01.0Z</qDate> S: <msg>Transfer rejected.</msg> S: </msgQ> S: <resData> S: <domain:trnData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:trStatus>clientRejected</domain:trStatus> S: <domain:reID>BEdemandeurID</domain:reID> S: <domain:reDate>2008-12-25T00:00:00.0Z</domain:reDate> S: <domain:acID>BEactuelID</domain:acID> S: <domain:acDate>2009-01-16T00:00:00.0Z</domain:acDate> S: </domain:trnData> S: </resData> S: <trID> S: <svTRID>frnic-00000010</svTRID> S: </trID> S: </response> S:</epp>

Nous avons évoqué précédemment la possible présence d’un autre message dans la file d’attente. En effet, nous avons indiqué que lors d’un changement de délégation, le contact titulaire du nom de domaine serait cloné si nécessaire. Dans ce cas, il est important que le bureau d’enregistrement repreneur soit averti de cette création, d’autant qu’elle n’est pas demandée de manière explicite. Un message de notification sera donc ajouté à sa file d’attente (semblable à celui résultant d’une création d’objet contact), celui-ci sera envoyé juste après que l’opération de changement de délégation se soit terminée avec succès. Ainsi, il sera possible de différencier les cas où le titulaire est cloné (un message est envoyé) de ceux ou le titulaire est réutilisé (aucun message n’est envoyé). L’envoi de ce message devrait inciter le

- 32 -


bureau repreneur à interroger le serveur pour obtenir toutes les informations sur ce nouveau contact.

2.4.4. Utilisation de la commande <domain:transfer> en consultation

Contrairement à ce qui est indiqué dans les RFC 4930 et 4931, la commande en question ne sera utile que pour connaître l’état d’avancement d’un changement de délégation en cours. En effet, il est normalement prévu que cette commande puisse aussi fournir des informations sur le dernier changement de délégation effectué sur un nom de domaine. Nous ne proposerons pas cette utilisation. La bonne gestion des messages de notification devrait permettre aux deux bureaux d’enregistrements impliqués dans l’opération de faire un suivi complet du bon déroulement de cette opération. Il n’est toutefois pas exclu que nous offrions ce service dans une version future de notre interface EPP, mais cette fonctionnalité ne fera pas partie de la présente version. Une évolution possible étant aussi que cette information soit disponible (en partie) pour d’autres bureaux que ceux impliqués dans l’opération. Mais encore une fois, ce n’est qu’une piste de réflexion, en aucun cas, un engagement de notre part.

2.5. Transmission volontaire d’un nom de domaine (<trade>)

La commande <trade> n’existe pas en standard en EPP. À l’AFNIC, nous avons 2 procédures de transmission spécifiques s’appliquant dans des cas différents, l’opération décrite ici ne correspondant qu’à ce que nous appelons "transmission volontaire".

2.5.1. Demander une transmission volontaire

Contrairement à l’opération <transfer> que nous avons précédemment décrite, la transmission n’implique pas forcément un changement de bureau d’enregistrement. Par contre, le titulaire doit changer. En ce qui concerne les autres types de contacts, si le domaine reste chez le même bureau d’enregistrement, il n’y a, a priori, aucune raison à ce que ceux-ci soient modifiés ; par contre si la transmission s’accompagne d’un changement de bureau d’enregistrement, les contacts administratifs et techniques ont toutes les chances d’être modifiés. Dans un souci de cohérence avec, entre autres, l’opération <transfer>, nous avons décidé de rendre obligatoire la présence de tous les types de contacts, que ceux-ci soient modifiés ou non … Tout comme la commande <transfer>, la commande <trade> aura un attribut "op" permettant de différentier son utilisation en mode "transform" de son utilisation en mode "query". Par contre, contrairement à la commande <transfer>, seules 2 valeurs seront possibles pour cet attribut, "request" pour demander une transmission sur un nom de domaine et "query" pour consulter l’état d’avancement de cette transmission.

- 33 -


La transmission volontaire ne peut se faire que lorsque le titulaire cédant a été correctement identifié. Si ce n’est pas le cas, un code d’erreur sera retourné lors de la demande. L’état "serverTradeProhibited" sera positionné pour ce nom de domaine, cette information étant consultable en utilisant la commande <domain:info>. Comme cet état n’existe pas en standard en EPP, il se trouvera dans une extension. Les éléments qui devront être présents dans l’extension (dans l’élément <frnic:domain> de l’élément <frnic:trade>) sont indiqués dans le tableau ci-après.

Nom de l’élément Nombre d’occurences <frnic:name> 1 <frnic:registrant> 1 <frnic:contact type="admin"> 1 <frnic:contact type="tech"> 1-3

On notera que la mise en place d’une nouvelle commande via les mécanismes d’extension d’EPP empêche l’utilisation de l’élément <clTRID> (c’est un fils de l’élément <command>). Celui-ci étant important pour assurer un suivi des commandes et une synchronisation de celles-ci (il est particulièrement utile pour les commandes qui renvoient un code retour 1001), nous l’avons intégré à l’extension proposée. Bien qu’il ne soit pas au même endroit, son utilisation dans la réponse du serveur et dans les messages de notification reste la même. Par exemple, lors de la réponse du serveur à la demande de transmission que nous allons envoyer ci-après, l’élément <clTRID> sera dupliqué dans l’élément <trID> et non pas dans la partie extension de la réponse. Exemple de la requête de transmission volontaire pour notre nom de domaine ndd-de-test-0001.fr (dans notre exemple, la transmission est faite à bureau d’enregistrementconstant en conservant les mêmes contacts administratifs et techniques) :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <extension> C: <frnic:ext C: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.0"> C: <frnic:command> C: <frnic:trade op="request"> C: <frnic:domain> C: <frnic:name>ndd-de-test-0001.fr</frnic:name> C: <frnic:registrant>PR1249</frnic:registrant> C: <frnic:contact type="admin">VL</frnic:contact> C: <frnic:contact type="tech">AI1</frnic:contact> C: <frnic:contact type="tech">PR1249</frnic:contact> C: </frnic:domain> C: </frnic:trade> C: <frnic:clTRID>une-reference-client-par-exemple</frnic:clTRID> C: </frnic:command>

- 34 -


C: </frnic:ext> C: </extension> C:</epp>

En ce qui concerne la réponse, nous nous proposons de fournir une réponse assez proche de ce qui est retourné lors d’un changement de délégation à laquelle nous ajoutons dans une extension l’information concernant le titulaire cédant et le titulaire repreneur. Même si nous avons conservé un format proche de la réponse faite dans le cas d’un changement de délégation (mais c’est dans la partie <extension> de la réponse, plus dans <resData>), certains éléments changent un peu de sens. En effet, pour un changement de délégation, ce sont les bureaux d’enregistrement qui vont réaliser les opérations nécessaires aux changements d’état du nom de domaine traité, alors que dans le cas d’une transmission volontaire, ce sont les 2 titulaires concernés qui, par le biais d’un processus "off-line", vont valider ou refuser l’opération. Les éléments utilisés pour horodater des opérations ou indiquer des dates d’expiration (<domain:reDate>, <domain:acDate> et <domain:exDate>) vont être complétés. En effet, nous avons besoin d’indiquer la date et l’heure de réception de la requête, le délai accordé aux 2 titulaires pour accepter ou refuser cette opération et l’heure et la date à laquelle ils ont répondu à la demande. Le tableau suivant reprend les éléments qui seront présents dans l’extension (<frnic:trdData>) de la réponse du serveur :

Nom de l’élément Nombre d’occurences <frnic:name> 1 <frnic:trStatus> 1 <frnic:reID> 1 <frnic:reDate> 1 <frnic:reHldID> 1 <frnic:rhDate> 1 <frnic:acID> 1 <frnic:acHldID> 0-1 <frnic:ahDate> 1

• <frnic:name> nom du domaine qui est l’objet de la demande de

transmission. • <frnic:trStatus> indique l’état de la transmission. Bien qu’à la

demande, la seule valeur possible soit "pending", 6 valeurs sont possibles qui seront détaillées par la suite ("pending", "newHolderApproved", "oldHolderApproved", "holdersApproved", "newHolderRejected", "oldHolderRejected").

• <frnic:reID> contient l’ID du bureau d’enregistrement qui fait la demande.

• <frnic:reDate> indique la date et l’heure auxquelles la commande a été prise en compte.

- 35 -


• <frnic:reHldID> contient l’identifiant du titulaire qui demande la transmission volontaire.

• <frnic:rhDate> indique la date et l’heure limites pour que le titulaire repreneur accepte la transmission.

• <frnic:acID> contient l’ID du bureau d’enregistrement gestionnaire actuel (dans la plupart des cas, ce sera égal à <frnic:reID>).

• <frnic:acHldID> contient l’identifiant du titulaire actuel du nom de domaine. Cette information ne sera fournie que si la transmission se fait à bureau d‘enregistrement constant (ce sera le cas dans notre exemple).

• <frnic:ahDate> indique la date et l’heure limites pour que le titulaire cédant accepte la transmission.

Exemple de réponse envoyée par le serveur (pour ce type de commande, le code retour sera toujours 1001). Dans le cas présent, les valeurs de "BEdemandeurID" et "BEactuelID" sont considérées comme identiques, ce qui explique la présence conjointe des éléments <frnic:reHldID> et <frnic:acHldID> :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1001"> S: <msg>Command completed successfully; action pending</msg> S: </result> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.0"> S: <frnic:resData> S: <frnic:trdData> S: <frnic:domain> S: <frnic:name>ndd-de-test-0001.fr</frnic:name> S: <frnic:trStatus>pending</frnic:trStatus> S: <frnic:reID>BEdemandeurID</frnic:reID> S: <frnic:reDate>2009-01-01T00:00:00.0Z</frnic:reDate> S: <frnic:reHldID>PR1249</frnic:reHldID> S: <frnic:rhDate>2009-01-09T00:00:00.0Z</frnic:rhDate> S: <frnic:acID>BEactuelID</frnic:acID> S: <frnic:acHldID>MM4567</frnic:acHldID> S: <frnic:ahDate>2009-01-09T00:00:00.0Z</frnic:ahDate> S: </frnic:domain> S: </frnic:trdData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000011</svTRID> S: </trID> S: </response> S:</epp>

2.5.2. Suivre une transmission volontaire

Si la transmission donne lieu à un changement de délégation, le bureau gestionnaire et le bureau repreneur recevront (pratiquement) les mêmes

- 36 -


messages de service permettant de suivre l’évolution de l’opération en cours. Par contre seul le bureau par qui est passée la demande recevra le message de conclusion indiquant le résultat de la commande <trade> et seul le bureau gestionnaire recevra le premier message de service plus ou moins équivalent au retour de la commande (mis à part le fait que <frnic:reHldID> sera absent contrairement à <frnic:acHldID>). Le titulaire cédant et le titulaire repreneur ont 15 jours pour valider la transmission du nom de domaine. Pour illustrer nos propos nous allons imaginer un scénario classique où le titulaire cédant valide la transmission, suivi du titulaire repreneur, et ceci dans le délai imparti de 15 jours. Dans un premier temps, le bureau d’enregistrement gestionnaire recevra ce premier message de notification (on est dans le cas ou la transmission s’accompagne d’un changement de délégation, ce qui explique l’absence de l’élément <frnic:reHldID>) :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50010"> S: <qDate>2009-12-25T00:02:00.0Z</qDate> S: <msg>Trade requested.</msg> S: </msgQ> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.0"> S: <frnic:resData> S: <frnic:trdData> S: <frnic:domain> S: <frnic:name>ndd-de-test-0001.fr</frnic:name> S: <frnic:trStatus>pending</frnic:trStatus> S: <frnic:reID>BEdemandeurID</frnic:reID> S: <frnic:reDate>2009-01-01T00:00:00.0Z</frnic:reDate> S: <frnic:rhDate>2009-01-09T00:00:00.0Z</frnic:rhDate> S: <frnic:acID>BEactuelID</frnic:acID> S: <frnic:acHldID>MM4567</frnic:acHldID> S: <frnic:ahDate>2009-01-09T00:00:00.0Z</frnic:ahDate> S: </frnic:domain> S: </frnic:trdData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-du-BEactuel-par-exemple</clTRID> S: <svTRID>frnic-00000012</svTRID> S: </trID> S: </response> S:</epp>

Le titulaire cédant accepte la transmission, ce qui aura pour effet de générer 2 messages de notification, un à chaque bureau d’enregistrement. Ceux-ci seront presque identique, la seule différence se situant au niveau de

- 37 -


l’élément <frnic:reHldID> qui ne sera présent que dans le message envoyé au bureau par qui le titulaire repreneur est passé pour faire la demande de transmission et de l’élément <frnic:acHldID> qui ne sera présent que dans le message envoyé au bureau d’enregistrement gestionnaire. On notera la valeur de l’élément <frnic:trStatus> qui passe de "pending" à "oldHolderApproved" (dans un cas ou le titulaire repreneur aurait été le premier à valider la transmission, <frnicStatus> auarit eu pour valeur "newHolderApproved"). On notera aussi les valeurs de <qDate> et <frnic:rhDate>. Voici le message que recevra le bureau gestionnaire :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50011"> S: <qDate>2009-01-02T00:00:01.0Z</qDate> S: <msg>Trade in progress.</msg> S: </msgQ> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.0"> S: <frnic:resData> S: <frnic:trdData> S: <frnic:domain> S: <frnic:name>ndd-de-test-0001.fr</frnic:name> S: <frnic:trStatus>oldHolderApproved</frnic:trStatus> S: <frnic:reID>BEdemandeurID</frnic:reID> S: <frnic:reDate>2009-01-01T00:00:00.0Z</frnic:reDate> S: <frnic:rhDate>2009-01-02T00:00:00.0Z</frnic:rhDate> S: <frnic:acID>BEactuelID</frnic:acID> S: <frnic:acHldID>MM4567</frnic:acHldID> S: <frnic:ahDate>2009-01-09T00:00:00.0Z</frnic:ahDate> S: </frnic:domain> S: </frnic:trdData> S: </frnic:trdData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-du-BEactuel-par-exemple</clTRID> S: <svTRID>frnic-00000013</svTRID> S: </trID> S: </response> S:</epp>

Le titulaire repreneur fera de même et 2 messages seront à nouveau générés avec les mêmes limitations que celles indiquées précédemment sur les éléments <frnic:reHldID> et <frnic:acHldID>. Cette fois-ci <frnic:trStatus> aura pour valeur "holdersApproved".

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="50012">

- 38 -


S: <qDate>2009-01-03T00:00:00.0Z</qDate> S: <msg>Trade in progress.</msg> S: </msgQ> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.0"> S: <frnic:resData> S: <frnic:trdData> S: <frnic:domain> S: <frnic:name>ndd-de-test-0001.fr</frnic:name> S: <frnic:trStatus>holdersApproved</frnic:trStatus> S: <frnic:reID>BEdemandeurID</frnic:reID> S: <frnic:reDate>2009-01-01T00:00:00.0Z</frnic:reDate> S: <frnic:rhDate>2009-01-02T00:00:00.0Z</frnic:rhDate> S: <frnic:acID>BEactuelID</frnic:acID> S: <frnic:acHldID>MM4567</frnic:acHldID> S: <frnic:ahDate>2009-01-03T00:00:00.0Z</frnic:ahDate> S: </frnic:domain> S: </frnic:trdData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-du-BEactuel-par-exemple</clTRID> S: <svTRID>frnic-00000014</svTRID> S: </trID> S: </response> S:</epp>

Pour terminer cette opération, un message sera envoyé au bureau d’enregistrement par qui la demande de transmission a été passée, et uniquement à lui. Dans notre cas, la valeur de "paResult" vaudra 1 car tout c’est passé normalement.

- 39 -


S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1301"> S: <msg>Command completed successfully; ack to dequeue</msg> S: </result> S: <msgQ count="1" id="60002"> S: <qDate>2009-01-03T00:00:00.0Z</qDate> S: <msg>Transfer completed.</msg> S: </msgQ> S: <resData> S: <domain:panData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name paResult="1">ndd-de-test-0001.fr</domain:name> S: <domain:paTRID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000011</svTRID> S: </domain:paTRID> S: <domain:paDate>2009-01-03T00:00:00.0Z</domain:paDate> S: </domain:panData> S: </resData> S: <trID> S: <svTRID>frnic-00000015</svTRID> S: </trID> S: </response> S:</epp>

2.5.3. Utilisation de la commande <trade> en consultation

Tout comme pour la commande <transfer>, la commande <trade> en consultation ne donnera aucune information sur la dernière transmission réalisée sur un nom de domaine. Seules des informations sur les transmissions en cours, seront disponibles pour les bureaux impliqués dans cette opération.

2.6. Transmission forcée d’un nom de domaine (<recover>)

L’autre méthode de transmission qui existe à l’AFNIC, dite "forcée", est un peu particulière puisque nous sommes dans un cas où le titulaire cédant n’existe plus ou que la transmission est faite suite à une décision judiciaire. Nous nous retrouvons donc dans une situation qui est un panaché de la création "en 2 temps" et de la transmission volontaire qui vient d’être présentée.

2.6.1. Demander une transmission forcée

Tout comme pour le cas de la création "en 2 temps", nous ne détaillerons pas dans le présent document le processus de récupération du code d’autorisation nécessaire à la demande d’une transmission forcée. Mais son obtention est un préalable à toute tentative d’utilisation de cette commande sur un nom de domaine.

- 40 -


Mis à part ce "détail", l’utilisation de la commande <recover> va se révéler particulièrement simple. La logique de celle-ci est proche des commandes <transfer> et <trade> qui ont déjà été détaillée. Et même si le processus lié à cette opération est sensiblement différent de celui des 2 commandes pré-citées, dans un souci d’homogénéité et de cohérence, nous avons fait le choix de conserver un format similaire. Par exemple, bien que cela ne soit pas utile dans cette version d’interface, nous avons choisi de conserver l’attribut "type" de la commande. Celui-ci ne pourra prendre qu’une unique valeur, "request", puisque contrairement aux autres commandes dont elle s’inspire, la commande <recover> renverra un code 1000 au lieu d’un code 1001. Mis à part le nom de la commande, ce qui va différencier la requête envoyée pour <recover> de celle envoyée pour <trade>, c’est la présence de l’élément <frnic:authInfo> qui servira à indiquer le code d’autorisation qui comme pour la création "en 2 temps" sera associé au triplet (bureau d’enregistrement, nom de domaine, Nic-Handle du titulaire). La transmission forcée ne peut se faire que lorsque le titulaire cédant a été correctement identifié. Si ce n’est pas le cas, un code d’erreur sera retourné lors de la demande. L’état "serverTradeProhibited" sera positionné pour ce nom de domaine, cette information étant consultable en utilisant la commande <domain:info>. Comme cet état n’existe pas en standard en EPP, il se trouvera dans une extension. Voici un exemple de requête envoyée par un bureau d’enregistrement qui a obtenu le code d’autorisation nécessaire à la transmission forcée de notre nom de domaine d’exemple :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <extension> C: <frnic:ext C: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.0"> C: <frnic:command> C: <frnic:recover op="request"> C: <frnic:domain> C: <frnic:name>ndd-de-test-0001.fr</frnic:name> C: <frnic:authInfo> C: <frnic:pw>NDCR20080229T173000.123456789</frnic:pw> C: </frnic:authInfo> C: <frnic:registrant>PR1249</frnic:registrant> C: <frnic:contact type="admin">VL</frnic:contact> C: <frnic:contact type="tech">AI1</frnic:contact> C: <frnic:contact type="tech">PR1249</frnic:contact> C: </frnic:domain> C: </frnic:recover> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </frnic:command> C: </frnic:ext> C: </extension> C:</epp>

- 41 -


La réponse du serveur sera elle aussi très proche de ce qui est proposé pour la commande <trade>, à quelques nuances près. En effet, dans ce cas, ni les titulaires, ni les bureaux d’enregistrements n’ont à intervenir pour assurer le bon déroulement de la commande. Nous l’avons déjà indiqué, le code retour de la commande sera 1000, il ne semble donc pas nécessaire de fournir d’information sur l’état du transfert ou d’indiquer des dates limites d’action pour que les titulaires ou les bureaux d’enregistrements agissent sur le déroulement de la commande. Les limitations sur la présence ou non des identifiants des titulaires cédant et repreneur sont les même que pour la commande <trade>. À titre d’information uniquement et si le bureau par qui la demande de transmission est faite est différent du bureau d’enregistrement gestionnaire du nom de domaine, un message de notification sera ajouté à la file de messages de ce dernier. Le tableau suivant reprend les éléments qui seront présents dans l’extension (<frnic:recData>) de la réponse du serveur (et dans le message de notification envoyé si nécessaire) :

Nom de l’élément Nombre d’occurrences

<frnic:name> 1 <frnic:reID> 1 <frnic:reDate> 1 <frnic:reHldID> 0-1 <frnic:acID> 1 <frnic:acHldID> 0-1

• <frnic:name> nom du domaine qui est l’objet de la demande de

transmission. • <frnic:reID> contient l’ID du bureau d’enregistrement qui fait la

demande. • <frnic:reDate> indique la date et l’heure auxquelles la commande a été

prise en compte. • <frnic:reHldID> contient l’identifiant du titulaire qui demande la

transmission volontaire. Ne sera pas présent dans le message de notification dans le cas d’une transmission impliquant un changement de bureau d’enregistrement.

• <frnic:acID> contient l’ID du bureau d’enregistrement gestionnaire actuel (dans la plupart des cas, ce sera égal à <frnic:reID>).

• <frnic:acHldID> contient l’identifiant du titulaire actuel du nom de domaine. Cette information ne sera fournie que si la transmission se fait à bureau d‘enregistrement constant.

Exemple de réponse envoyée par le serveur (pour ce type de commande, le code retour sera toujours 1000). Dans le cas présent, les valeurs de "BEdemandeurID" et "BEactuelID" sont considérées comme identiques, ce qui explique la présence conjointe des éléments <frnic:reHldID> et <frnic:acHldID> :

- 42 -


S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.0"> S: <frnic:resData> S: <frnic:recData> S: <frnic:domain> S: <frnic:name>ndd-de-test-0001.fr</frnic:name> S: <frnic:reID>BEdemandeurID</frnic:reID> S: <frnic:reDate>2009-01-01T00:00:00.0Z</frnic:reDate> S: <frnic:reHldID>PR1249</frnic:reHldID> S: <frnic:acID>BEactuelID</frnic:acID> S: <frnic:acHldID>MM4567</frnic:acHldID> S: </frnic:domain> S: </frnic:recData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000016</svTRID> S: </trID> S: </response> S:</epp>

2.6.2. Utilisation de la commande <recover> en consultation

Bien que nous venions d’indiquer que seule la valeur "request" sera acceptée pour l’attribut "type" et que le code retour 1000 systématique "limite" l’intérêt d’avoir des renseignements sur une transmission en cours, nous n’avons pas voulu fermer la possibilité à une évolution de cette commande. On peut imaginer, à l’instar de ce qui sera peut-être possible de faire avec les commandes <transfer> et <trade> plus tard, avoir la possibilité d’avoir des informations sur la dernière commande <recover> ayant eu lieu sur un nom de domaine donné.

2.7. Vérification de la disponibilité d’un nom de domaine

La commande <domain:check> va permettre de vérifier la disponibilité d’un ou plusieurs noms de domaines. Même si il aurait été possible de coller au plus près des codes retours proposés par notre propre outil de disponibilité, à savoir "check_domain", nous avons décidé d’offrir un éventail plus large de messages pour les cas où le nom de domaine n’est pas disponible. Ces derniers étant plus proches de ce qu’il est possible de recevoir comme message d’erreur lors de l’utilisation du formulaire en ligne. Pour rappel, la commande <domain:check> permet d’indiquer une liste de noms de domaine à tester. Nous avons décidé d’en limiter le nombre à 7 (cette

- 43 -


règle pouvant être durcie ou assouplie à l’usage). Toute requête comportant plus de domaines que cette limite renverra un message d’erreur. La réponse du serveur consiste pour chaque domaine à indiquer, à l’aide d’un attribut de type booléen si le nom de domaine peut-être créé et si ce n’est pas le cas, d’indiquer la raison qui empêche la création du nom de domaine. Voici une liste des messages qui seront envoyés en cas d’impossibilité de créer un nom de domaine :

Message Détails

In use Le nom de domaine existe déjà (Quelque soit son état. Un nom de domaine en cours de suppression, par exemple, n’est pas libre).

Zone not opened Le nom de domaine est libre, mais appartient à une zone géréé par l’AFNIC qui n’est pas ouverte à l’enregistrement.

Zone unknown Le nom de domaine n’est pas dans une zone gérée par l’AFNIC.

Bad syntax L’argument passé en paramètre n’est pas un nom de domaine.

Registry bad syntax L’argument passé en paramètre est bien un nom de domaine mais ne respecte pas une des règles syntaxiques imposées par l’AFNIC (par exemple : un seul caractère dans le label genre x.fr, …).

Equivalent name in use Un nom de domaine "équivalent" existe déjà et empêche le dépôt de ce nom de domaine.

Forbidden name Le nom de domaine fait partie d’une liste de noms interdits.

On notera que le message "Reserved name" retourné lors du dépôt via le formulaire ou bien en réponse à "check_domain" a disparu des codes retours possibles. En effet un nom de domaine dit "réservé" est tout de même déposable via une procédure identifiée et standard (l’utilisation de la procédure de création "en 2 temps" après obtention d’un code d’autorisation est nécessaire). C’est ce qui va aussi différencier cet état de l’état "interdit" qui qualifie un nom de domaine non déposable en l’état et pour lequel une procédure exceptionnelle telle qu’un vote du Conseil d’Administration serait un préalable à son dépôt par exemple. Nous avons donc décidé d’indiquer ces informations dans une extension où seront repris tous les noms de domaine de la réponse, même ceux non concernés par ces notions de nom réservé ou de nom interdit. L’élément <frnic:name> contiendra le nom de domaine et l’attribut "reserved" de cet élément, de type binaire, permettra d’indiquer si le nom de domaine en question fait bien partie de la catégorie de noms réservés, l’attribut "forbidden" faisant de même pour les noms de domaine interdits. Si c’est un nom de domaine "réservé", un élément <frnic:rsvReason> devra être présent pour indiquer pourquoi il se trouve

- 44 -


catégorisé ainsi (la raison la plus évidente qui vient à l’esprit étant le cas des noms de communes). Il en sera de même avec la présence éventuelle d’un élément <frnic:fbdReason>. On peut imaginer qu’un nom réservé le soit pour de multiples raisons, même si ce n’est pas le cas aujourd’hui, c’est pour cela que l’élément <frnic:rsvReason> pourra être présent plusieurs fois pour un nom de domaine (la même règle s’appliquant bien sûr à l’élément <frnic:fbdReason>). Exemple de la requête pour vérifier la disponibilité d’une liste de noms de domaine : C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <check> C: <domain:check C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name>afnic.fr</domain:name> C: <domain:name>af-1234-nic.fr</domain:name> C: <domain:name>bois-guillaume.fr</domain:name> C: <domain:name>paris.fr</domain:name> C: <domain:name>trafiquants.fr</domain:name> C: <domain:name>toto.wf</domain:name> C: </domain:check> C: </check> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> Le tableau suivant reprend les éléments qui seront présents dans les éléments <frnic:cd> de l’extension (<frnic:chkData>) de la réponse du serveur :


<frnic:name reserved="" forbidden=""> 1 <frnic:rsvReason> 0-n <frnic:fbdReason> 0-n

• <frnic:name reserved="" forbidden=""> nom du domaine qui est

vérifié, "reserved" peut prendre les valeurs 0 ou 1, de même que "forbidden".

• <frnic:rsvReason> pourra prendre les valeurs suivantes (cette liste n’est pas définitive et pourra être étendue voir modifiée à l’avenir ; il serait imprudent de coder ces valeurs de retour avant la version définitive de ces spécifications) :

• City name • Registry process

• <frnic:fbdReason> pourra prendre prendre la valeur suivante (cette liste n’est pas définitive et pourra être étendue voir modifiée à l’avenir; il serait imprudent de coder ces valeurs de retour avant la version définitive de ces spécifications) :

• Legal issue Exemple de la réponse envoyée par le serveur (pour ce type de commande, le code retour sera toujours 1000, jamais 1001). Il est à noter que dans la réponse

- 45 -


du serveur l’attribut "avail" prend les valeurs "1" ou "0", mais le protocole autorisant aussi l’utilisation de "true" et "false", il faut s’attendre à recevoir l’un ou l’autre. S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <domain:chkData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:cd> S: <domain:name avail="0">afnic.fr</domain:name> S: <domain:reason>In use</domain:reason> S: </domain:cd> S: <domain:cd> S: <domain:name avail="1">af-1234-nic.fr</domain:name> S: </domain:cd> S: <domain:cd> S: <domain:name avail="1">bois-guillaume.fr</domain:name> S: </domain:cd> S: <domain:cd> S: <domain:name avail="0">paris.fr</domain:name> S: <domain:reason>In use</domain:reason> S: </domain:cd> S: <domain:cd> S: <domain:name avail="0">trafiquants.fr</domain:name> S: <domain:reason>Forbidden name</domain:reason> S: </domain:cd> S: <domain:cd> S: <domain:name avail="0">toto.wf</domain:name> S: <domain:reason>Zone not opened</domain:reason> S: </domain:cd> S: </domain:chkData> S: </resData> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.0"> S: <frnic:resData> S: <frnic:chkData> S: <frnic:domain> S: <frnic:cd> S: <frnic:name reserved="0" forbidden="0"> S: afnic.fr S: </frnic:name> S: </frnic:cd> S: <frnic:cd> S: <frnic:name reserved="0" forbidden="0"> S: af-1234-nic.fr S: </frnic:name> S: </frnic:cd> S: <frnic:cd> S: <frnic:name reserved="1" forbidden="0"> S: bois-guillaume.fr S: </frnic:name> S: <frnic:rsvReason>City name</frnic:rsvReason> S: </frnic:cd> S: <frnic:cd>

- 46 -


S: <frnic:name reserved="1" forbidden="0"> S: paris.fr S: </frnic:name> S: <frnic:rsvReason>City name</frnic:rsvReason> S: </frnic:cd> S: <frnic:cd> S: <frnic:name reserved="0" forbidden="1"> S: trafiquants.fr S: </frnic:name> S: <frnic:fbdReason>Legal issue</frnic:fbdReason> S: </frnic:cd> S: <frnic:cd> S: <frnic:name reserved="0" forbidden="0"> S: toto.wf S: </frnic:name> S: </frnic:cd> S: </frnic:domain> S: </frnic:chkData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000017</svTRID> S: </trID> S: </response> S:</epp>

2.8. Récupération des données associées à un nom de domaine

La commande <domain:info> va permettre de récupérer des informations sur un nom de domaine. Bien qu’il ne s’agisse pas de remplacer la commande Whois, cette commande renvoie le même type d’information et elle est particulièrement utile pour suivre les traitements en cours pour un nom de domaine. Une requête sur un nom de domaine retournera toute l’information disponible sur celui-ci dès lors que l’interrogation est faite par le bureau d’enregistrement qui assure la gestion du nom de domaine. Le mot de passe n’est pas nécessaire, par contre, contrairement à ce que le RFC 4931 préconise, même en ayant connaissance du mot de passe associé à un nom de domaine, il n’est pas possible, pour un bureau autre que le bureau gestionnaire d’obtenir des informations sur le nom de domaine faisant l’objet de la requête. Par rapport à ce qui est décrit dans le RFC 4931, nous aurons besoin de définir des extensions pour indiquer des états spécifiques aux nouvelles commandes que nous avons décrites, la suppression avec rédemption (RFC 3915) prévoit aussi l’utilisation d’une extension. Nous acceptons les différentes valeurs pour l’attribut "hosts", à savoir "none" pour n’avoir aucune information sur les serveurs de noms, "del" pour avoir uniquement les informations concernant la liste des serveurs de noms sur lesquels sont installés le nom de domaine interrogé, "sub" pour connaître la liste des serveurs de noms liés à ce nom de domaine et "all" pour avoir les 2 (c’est la

- 47 -


valeur par défaut). Pour rappel, un nom de domaine peut être déposé sans avoir de configuration technique, ce qui n’empêche pas que des serveurs de noms puissent être liés à celui-ci… La requête envoyée par le client est très simple :

C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <info> C: <domain:info C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> C: <domain:name hosts="all">ndd-de-test-0001.fr</domain:name> C: </domain:info> C: </info> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

2.8.1. Détail de la partie "classique" de la réponse

La réponse que le serveur renverra ne contiendra pas tous les éléments décrits dans le RFC 4931 (en tout cas pas dans la présente version de l’interface EPP). Nous allons indiquer la liste des éléments possibles, mais avant cela, revenons sur quelques éléments qui ne seront pas présents ou qui auront une signification un peu différente de ce que le RFC indique. Premier différence notable, l’élément <domain:roid>… Bien que nous ayons des identifiants uniques pour les noms de domaine dans notre base de données, ceux-ci ne répondent pas tout à fait au "cahier des charges" défini dans le RFC. En effet, un "roid" devrait être créé à chaque création d’objet dans la base ; un nom de domaine créé une première fois, supprimé et re-créé devrait, en toute logique, se voir attribuer des "roid" différents pour chaque opération de création. À l’AFNIC, un ID unique est associé à un nom de domaine lors de sa toute première insertion dans la base de données, celui-ci le suivra même si il est supprimé entre temps (il ne sera jamais ré-attribué). À cet ID unique nous concaténerons le suffixe "–FRNIC", tout comme pour les objets contact. L’état d’un nom de domaine pourra être indiqué soit dans la partie <resData> de la réponse, soit dans les extensions. Toutefois, contrairement au RFC, cette information n’est pas optionnelle. Un nom de domaine qui n’est pas dans un état particulier aura forcément l’élément <domain:status s="ok"/> présent dans la partie <resData> de la réponse. De la même manière, l’absence de cet élément implique forcément qu’une information sur l’état du nom de domaine se trouve dans la partie <extension> de la réponse. Les éléments <domain:crID> (ID du bureau qui a créé pour la première fois le nom de domaine), <domain:upID> (ID du bureau qui a le dernier mis à jour le nom de domaine) et <domain:trDate> (date du dernier changement de délégation terminé) ne seront pas présents.

- 48 -


Le tableau suivant reprend les éléments qui seront présents dans l’élément <domain:infData> de la réponse du serveur :


<domain:name> 1 <domain:roid> 1 <domain:status =""> 0-n <domain:registrant> 1 <domain:contact type="tech"> 1 <domain:contact type="admin"> 1-3 <domain :ns> 0-1 <domain :host> 0-n <domain:clID> 1 <domain:crDate> 1 <domain:exDate> 1 <domain:upDate> 1 <domain:authInfo> 1

• <domain:name> nom du domaine qui est l’objet de la demande

d’informations. • <domain:roid> ID unique de l’objet dans notre base de données. • <domain:status s=""> permet d’indiquer l’état d’un nom de

domaine (celui-ci pouvant être dans différents états au même moment). Tout état qui ne correspond pas à la liste disponible et décrite dans le RFC 4931 devra être indiqué dans une extension adéquate.

• <domain:registrant> contiendra l’identifiant du titulaire déduit du Nic-Handle de celui-ci auquel on aura retiré le suffixe (FRNIC) et le caractère séparateur "-".

• <domain:contact type="admin"> contiendra l’identifiant du contact administratif.

• <domain:contact type="tech"> contiendra l’identifiant d’un contact technique.

• <domain:ns> contiendra la configuration technique du nom de domaine si celui-ci en a une. Le format sera le même que celui utilisé lors des modifications techniques. Cette information ne sera pas présente si la valeur de l’attribut "hosts" passé lors de la requête vaut "none" ou "sub".

• <domain:host> contiendra la liste des serveurs de noms connus de nos services utilisés comme serveurs de noms pour des domaines gérés par l’AFNIC. Cette information ne sera pas présente si la valeur de l’attribut "hosts" passé lors de la requête vaut "none" ou "del".

• <domain:clID> contient l’ID du bureau qui gère le nom de domaine (dans notre cas, forcément celui qui fait la requête).

• <domain:crDate>… Dans la version actuelle de cette interface, les informations d’horodatage ne sont pas alignées sur leurs rôles décrits dans le RFC 4931 mais reprise du modèle "Whois". La date de

- 49 -


création est donc la dernière date de création du nom de domaine ou de dernière transmission (volontaire ou forcée).

• <domain:exDate> contiendra la date d’expiration supposée du nom de domaine (la date anniversaire). Nous n’avons pas implémenté la commande <domain:renew> et le mécanisme de renouvellement à l’AFNIC n’est pas le même que celui d écrit dans les RFC sur EPP.

• <domain:upDate> contiendra la date de dernière opération d’écriture dans la base concernant ce domaine. Contrairement à ce qui est indiqué dans le RFC 4931, cet élément sera toujours présent, même si il n’y a pas eu de commande de mise à jour. Dans ce cas, sa valeur sera égale à celle de l’élément <domain:crDate> (une fois encore, les règles existantes dans notre modèle "Whois" ont été reconduites).

• <domain:authInfo> contiendra le mot de passe associé au nom de domaine.

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:roid>DOM000000456987-FRNIC</domain:roid> S: <domain:status s="ok"/> S: <domain:registrant>MM4567</domain:registrant> S: <domain:contact type="admin">NFC1</domain:contact> S: <domain:contact type="tech">NFC1</domain:contact> S: <domain:contact type="tech">VL</domain:contact> S: <domain:ns> S: <domain:hostAttr> S: <domain:hostName>ns1.nic.fr</domain:hostName> S: </domain:hostAttr> S: <domain:hostAttr> S: <domain:hostName>ns2.nic.fr</domain:hostName> S: </domain:hostAttr> S: <domain:hostAttr> S: <domain:hostName>ns.ndd-de-test-0001.fr</domain:hostname> S: <domain:hostAddr ip="v4">192.93.0.1</domain:hostAddr> S: <domain:hostAddr ip="v6">2001:660:3005:1::1:1</domain:hostAddr> S: </domain:hostAttr> S: </domain:ns> S: <domain:host>ns.ndd-de-test-0001.fr</domain:host> S: <domain:host>ns1234.ndd-de-test-0001.fr</domain:host> S: <domain:clID>BEactuelID</domain:clID> S: <domain:crDate>2008-12-25T00:00:00.0Z</domain:crDate> S: <domain:exDate>2009-12-25T00:00:00.0Z</domain:exDate> S: <domain:update>2009-01-10T00:00:00.0Z</domain:update> S: <domain:authInfo> S: <domain:pw>WarlordZ666</domain:pw> S: </domain:authInfo> S: </domain:infData> S: </resData> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID>

- 50 -


S: <svTRID>frnic-00000018</svTRID> S: </trID> S: </response> C:</epp>

2.8.2. Détails des extensions possibles de la réponse

La commande <domain:info> pourra contenir des informations supplémentaires dans la partie <extension> de la réponse. Parmi ces informations, il pourra y avoir celles liées au processus de suppression/restauration qui correspondent au RFC 3915. Par exemple, un nom de domaine qui aura été supprimé et qui se retrouve donc en période de rédemption aura l’extension suivante (une partie de l’élément <resData> a aussi été reproduit) :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> […] S: <resData> S: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:status s="pendingDelete"/> […] S: </resData> S: <extension> S: <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0" S: xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0 rgp-1.0.xsd"> S: <rgpStatus s="pendingDelete"/> S: </rgp:infData> S: </extension> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000019</svTRID> S: </trID> S: </response> C:</epp>

Le même domaine, s’il est restauré, aura l’extension suivante :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> […] S: <resData> S: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:status s="pendingDelete"/> […] S: </resData> S: <extension> S: <rgp:infData xmlns:rgp="urn:ietf:params:xml:ns:rgp-1.0" S: xsi:schemaLocation="urn:ietf:params:xml:ns:rgp-1.0 rgp-1.0.xsd"> S: <rgpStatus s="pendingRestore"/> S: </rgp:infData> S: </extension>

- 51 -


S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000020</svTRID> S: </trID> S: </response> C:</epp>

Reprenons notre domaine, mais cette fois-ci, imaginons que le titulaire n’a pas encore passé avec succès le processus d’identification. La partie <extension> de la réponse ressemblera à ceci (l’élément <domain:status> sera aussi présent dans la partie <resData>) :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> […] S: <resData> S: <domain:infData S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0"> S: <domain:name>ndd-de-test-0001.fr</domain:name> S: <domain:status s="serverTransferProhibited"/> […] S: </resData> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.0"> S: <frnic:resData> S: <frnic:infData> S: <frnic:domain> S: <frnic:status s="serverTradeProhibited"/> S: <frnic:status s="serverRecoverProhibited"/> S: </frnic:domain> S: </frnic:infData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000021</svTRID> S: </trID> S: </response> S:</epp>

3. Gestion des contacts

Nous l’avons déjà indiqué, les objets "contact" subissent une évolution significative, aussi bien dans leur format, dans leur utilisation que dans les traitements qu’ils seront amenés à subir. Les 3 aspects principaux de ces évolutions sont :

• L’homogénisation de tous les contacts qui auront désormais tous un Nic-

Handle utilisable pour les référencer dans les différentes opérations sur les noms de domaine.

• Les contacts titulaires devront être créés avant d’être utilisés dans une opération sur un nom de domaine.

- 52 -


• Les données d’identification seront désormais liées au titulaire (ce qui était déjà le cas pour les titulaire de type "Personne Physique"). Le processus d’identification se fera donc sur les contacts…

Il est à noter cette remarque d’ordre général sur la gestion des adresses postales, à savoir :

• Contrairement à ce qu’il est indiqué dans le RFC 4931, un seul élément de

type <contact:postalInfo> peut être fourni. • Contrairement à ce qu’il est est indiqué dans le RFC 4931, seul le type "loc"

pour les adresses postales est accepté.

3.1. Créer un contact

Comme il sera désormais possible de créer des contacts titulaires, ceux-ci étant liés à des données d’identification, il est nécessaire de proposer une extension puisque le mapping EPP standard pour les objets "contact" n’intègre pas ces informations. Mises à part ces données spécifiques, puisque nous avons décidé de rendre "deprecated" les objets "contact" de type "role" et les objets de type "mntner", la structure du mapping standard contient, à une exception près, tout ce dont nous avons besoin. L’exception dont nous venons de parler concerne le fait qu’il n’existe pas de moyen de différencier prénom et nom. Pour un contact pour lequel la différenciation prénom/nom aura un sens, <contact:name> devra contenir le nom de famille alors que l’élément <frnic:surname> de l’extension proposée contiendra le prénom du contact. Concrètement, pour tout contact titulaire "personne physique", cet élément est obligatoire. Autre adaptation nécessaire du mapping contact standard (RFC 4933) car non compatible avec nos procédures, l’élément <contact:id>, bien qu’obligatoire ne sera pas pris en compte par notre serveur. Cela implique, que contrairement au standard EPP, le bureau d’enregistrement n’aura pas le choix de l’identifiant pour le contact dont la création est demandée. De manière à assurer une gestion cohérente et sans rupture par rapport aux procédures actuelles, l’AFNIC continuera, seule, à affecter selon ces propres algorithmes les identifiants de contacts. Bien entendu, en cas de création réalisée avec succès, l’identifiant sera indiqué dans la réponse du serveur. Par contre cet identifiant pourra être celui d’un contact déjà existant si le bureau d’enregistrement envoie exactement les mêmes infos que celles contenues dans ce contact. Pour ce dernier cas, nous avons prévu d’ajouter un élément dans une extension dans la réponse du serveur. Autre élément qui, bien qu’obligatoire, ne sera pas pris en compte car non utilisé, c’est l’élément <contact:authInfo>. Il ne sera effectivement pas possible d’associer un mot de passe par objet contact, mais tout comme pour <contact:id>, nous avons choisi de le conserver dans la requête envoyée pour assurer une compatibilité plus simple avec les codes clients existants. L’élément <contact:disclose>, qui est optionnel dans le mapping contact, ne sera pas non plus traité, il ne devra donc pas être présent sous peine de voir la commande retourner une erreur.

- 53 -


En plus de l’élément <frnic:surname>, l’extension proposée doit permettre d’indiquer des informations nécessaires à l’identification des contacts utilisés comme titulaires de noms de domaine. Un élément <frnic:individualInfos> devra donc être présent pour les titulaires "personne physique", un élément <frnic:legalEntityInfos> pour les titulaires "personne morale". En ce qui concerne la gestion de la liste de diffusion restreinte (la liste rouge du "Whois"), la méthode choisie est la présence d’un élément "générique" <frnic:list> ne pouvant prendre dans l’immédiat que la valeur "restrictedPublication" et ne s’appliquant, toujours pour le moment, qu’au objet contact de type "personne physique".

AVERTISSEMENT : Au moment de la rédaction de ces spécifications, le chantier qui va consister à homogénéiser tous nos contacts, leur associer un Nic-Handle, en dupliquer certains, gérer autrement que par objets "mntner" la relation bureau d’enregistrement <-> objet "contact", … n’est pas encore réalisé, ni même complètement spécifié. De ce chantier pourrait émerger de nouvelles règles de gestion des contacts, certaines pouvant avoir un impact direct sur les règles d’utilisation de l’interface EPP. Les mappings proposés, quand à eux, ne devraient subir aucune modification.

Voici, dans le détail les éléments que nous retrouvons pour les titulaires personnes physiques.

Nom de l’élément Nombre d’occurences <frnic:birthdate> 1 <frnic:birthcity> 0-1 <frnic:pc> 0-1 <frnic:cc> 1

• <frnic:birthdate> contient la date de naissance du contact. • <frnic:birthcity> contient la commune de naissance du contact. • <frnic:pc> contient le code postal de la commune de naissance (au pire

le code département). • <frnic:cc> contient le code pays du lieu de naissance.

Exemple de création d’un contact contenant des informations lui permettant d’être utilisé comme titulaire personne physique pour un nom de domaine :

- 54 -


C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <create> C: <contact:create C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> C: <contact:postalInfo type="loc"> C: <contact:name>Levigneron</contact:name> C: <contact:id>XXXX0000</contact:id> C: <contact:org>AFNIC</contact:org> C: <contact:addr> C: <contact:street>immeuble international</contact:street> C: <contact:street>2, rue Stephenson</contact:street> C: <contact:street>Montigny le Bretonneux</contact:street> C: <contact:city>Saint Quentin en Yvelines Cedex</contact:city> C: <contact:pc>78181</contact:pc> C: <contact:cc>FR</contact:cc> C: </contact:addr> C: </contact:postalInfo> C: <contact:voice>+33.0139308333</contact:voice> C: <contact:fax>+33.0139308301</contact:fax> C: <contact:email>[email protected]</contact:email> C: <contact:authInfo> C: <contact:pw>UnusedPassword</contact:pw> C: </contact:authInfo> C: </contact:create> C: </create> C: <extension> C: <frnic:ext C: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.0"> C: <frnic:create> C: <frnic:contact> C: <frnic:surname>Vincent</frnic:surname> C: <frnic:list>restrictedPublication</frnic:list> C: <frnic:individualInfos> C: <frnic:birthdate>1968-07-20</frnic:birthdate> C: <frnic:birthcity>Rouen</frnic:birthcity> C: <frnic:pc>76000</frnic:pc> C: <frnic:cc>FR</frnic:cc> C: </frnic:individualInfos> C: </frnic:contact> C: </frnic:create> C: </frnic:ext> C: </extension> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

Dans les cas des contacts possédant des informations d’identification, une extension sera nécessaire pour indiquer l’état dans lequel se trouve le contact par rapport à ce processus d’identification. Les éléments qui se trouvent dans cette extension sont indiqués dans le tableau ci-après.

Nom de l’élément Nombre d’occurences <frnic:idStatus> 0-1 <frnic:nhStatus new=""> 1

- 55 -


• <frnic:idStatus> sera utilisé pour indiquer le status par rapport au processus d’identification (il ne sera présent que pour les contacts créés avec un élément <frnic:individualInfos> ou <frnic:legalEntityInfos>) :

• no : Le contact n’est pas encore identifié. • pending : Le contact est en cours d’identification. • ok : Le contact est identifié. • problem : Problème lors du processus d’identification. • ko : Au terme du processus d’identification, le contact n’a pas pu

être identifié. • retired : Les données ont été identifiées il y a trop longtemps,

référencer ce contact comme titulaire d’un nom de domaine aura pour effet de relancer le processus d’identification.

• <frnic:nhStatus new=""> sera utilisé pour indiquer si le Nic-Handle vient d’être créé (valeur de new à 1) ou bien s’il s’agit d’une ré-utilisation d’un contact existant (valeur de new à 0).

Dans la réponse à une commande de création, le RFC 4933 prévoit la présence de l’élément <contact:crDate> pour indiquer l’heure et la date de création du contact. Cette date pouvant par la suite être récupérée par la suite en utilisant la commande <contact:info>. Deux raisons font que cette information devra être interprétée avec toutes les précautions qui s’imposent. La première c’est que dans notre modèle actuel (qui concerne 1,5 millions de contacts), la date de création n’a pas été conservée, la seconde c’est que cela n’est pas cohérent avec notre politique de non duplication de contacts identiques… Donc, bien que cet élément soit fourni dans la réponse du serveur, sa valeur peut être antérieure à la date de soumission de la commande dans le cas d’un objet ré-utilisé (<frnic:nhStatus new="0">). Exemple de réponse envoyée par le serveur (pour les objets "contact", le code retour sera toujours 1000 en cas de commande traitée avec succès) :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <contact:creData S: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> S: <contact:id>VL99999</contact:id> S: <contact:crDate>2008-11-20T00:00:00.0Z</contact:crDate> S: </contact:creData> S: </resData> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.0"> S: <frnic:resData> S: <frnic:creData> S: <frnic:nhStatus new="1"/> S: <frnic:idStatus>no</frnic:idStatus> S: </frnic:creData> S: </frnic:resData> S: </frnic:ext>

- 56 -


S: </extension> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000022</svTRID> S: </trID> S: </response> S:</epp>

Dans le cas où le contact à créer n’est pas de type personne physique mais de type personne morale nécessitant des données d’identification, il faut fournir, soit un numéro de SIREN, un numéro de marque ou des informations spécifiques pour les associations. L’extension du mapping contact standard permet donc d’indiquer ces éléments. Dans l’extension, l’élément <frnic:surname> ne doit pas être présent.

• <frnic:status type=""> cet élément va être utilisé pour indiquer grâce à

l’attribut "type", la raison sociale de l’entité à identifier ("company", "association", "other"). L’élément sera vide sauf dans le cas où l’attribut "type" vaudra "other" (ex : <frnic:status type="other">Ambassade</frnic:status>).

• <frnic:siren> contiendra le numéro de SIREN. • <frnic:trademark> contiendra un numéro de marque. • <frnic:asso> contiendra ces 2 éléments pour les associations.

• <frnic:decl> indique la date de déclaration en préfecture. • <frnic:publ announce="" page=""> contiendra la date de

publication au JO (l’attribut "announce" permet d’indiquer le numéro de l’annonce, l’attribut "page" le numéro de la page de cette annonce).

Voici ce que cela donnerait comme requête. Pour éviter de multiplier les exemples, nous avons pris un cas peu réaliste où tous les éléments d’identification seraient renseignés :

Nom de l’élément Nombre d’occurences <frnic:status type=""> 1 <frnic:siren> 0-1 <frnic:trademark> 0-1 <frnic:asso> 0-1 <frnic:decl> 1 si <frnic:asso> est présent <frnic:publ announce="" page=""> 1 si <frnic:asso> est présent

- 57 -


C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <create> C: <contact:create C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> C: <contact:postalInfo type="loc"> C: <contact:name>Service des Réclamations</contact:name> C: <contact:id>XXXX0000</contact:id> C: <contact:org>AFNIC Corp</contact:org> C: <contact:addr> C: <contact:street>immeuble international</contact:street> C: <contact:street>2, rue Stephenson</contact:street> C: <contact:street>Montigny le Bretonneux</contact:street> C: <contact:city>Saint Quentin en Yvelines Cedex</contact:city> C: <contact:pc>78181</contact:pc> C: <contact:cc>FR</contact:cc> C: </contact:addr> C: </contact:postalInfo> C: <contact:voice>+33.0139308333</contact:voice> C: <contact:fax>+33.0139308301</contact:fax> C: <contact:email>[email protected]</contact:email> C: <contact:authInfo> C: <contact:pw>UnusedPassword</contact:pw> C: </contact:authInfo> C: </contact:create> C: </create> C: <extension> C: <frnic:ext C: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.0"> C: <frnic:create> C: <frnic:contact> C: <frnic:legalEntityInfos> C: <frnic:status type="company"/> C: <frnic:siren>123456789</frnic:siren> C: <frnic:trademark>27YOUPLA2345678</frnic:trademark> C: <frnic:asso> C: <frnic:decl>1999-05-19</frnic:decl> C: <frnic:publ announce="5" page="2">1999-06-01</frnic:publ> C: </frnic:asso> C: </frnic:legalEntityInfos> C: </frnic:contact> C: </frnic:create> C: </frnic:ext> C: </extension> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp>

3.2. Modifier un contact

La mise jour des données pour un contact va permettre la modification de certains éléments de celui-ci mais dans le respect des règles spécifiques liées aux rôles qu’il peut être amené à jouer pour un nom de domaine. Par exemple, si une règle impose que le contact administratif pour un nom de domaine soit domicilié

- 58 -


en France, la modification de l’adresse postale de ce contact pourra être autorisée mais la nouvelle adresse devra respecter cette règle de domiciliation. Il ne sera pas possible non plus de modifier le contenu d’un contact lié à une clé d’autorisation non encore utilisée. Seul le bureau d’enregistrement auquel ce contact est rattaché pourra demander une modification de celui-ci. Le mécanisme d’authentification via <contact:authInfo> n’a pas été mis en place pour la gestion des contacts. Les informations contenues dans les éléments <frnic:individualEntityInfos> et <frnic:legalEntityInfos> ne pourront pas être modifiées. Pas plus que les nom et prénom des contacts titulaire. Une extension est nécessaire pour la gestion de la liste diffusion restreinte, c’est cet exemple que nous avons choisi d’illustrer ici. Nous allons reprendre notre contact précédemment (VL99999) créé et supprimer son appartenance à la liste "restrictedPublication". La gestion des listes (même si au moment de la rédaction de ce document un seul type de liste existe) se fera à l’aide des éléments <contact:add> et <contact:del>. L’élément <frnic:list>, déjà présenté, sera utilisé de la même manière que lors de la création. C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <update> C: <contact:update C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> C: <contact:id>VL99999</contact:id> C: </contact:update> C: </update> C: <extension> C: <frnic:ext C: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.0"> C: <frnic:update> C: <frnic:contact> C: <frnic:rem> C: <frnic:list>restrictedPublication</frnic:list> C: </frnic:rem> C: </frnic:contact> C: </frnic:update> C: </frnic:ext> C: </extension> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> La réponse du serveur n’a rien de spécifique et sera toujours avec un code retour 1000.

- 59 -


3.3. Supprimer un contact

L’opération de suppression d’un objet "contact" ne sera pas disponible dans cette version d’interface EPP. En effet, le chantier sur l’homogénéisation des objets "contact" va être l’occasion de mettre en place un "garbage collector" assurant la suppression des objets trop anciens et non référencés. Tant que les règles encadrant cet outil ne sont pas définies, il nous parait prématuré d’avancer sur les règles de suppression des objets "contact". Toutefois, ce "garbage collector" a vocation à travailler en toute transparence et des messages de notification seront ajoutés dans la file d’attente du bureau d’enregistrement concerné par la suppression d’un objet contact. Ceci afin d’assurer à ce dernier d’avoir une base de données synchronisée avec la notre.

3.4. Identification d’un contact titulaire

Nous l’avons déjà indiqué à plusieurs reprises, le processus d’identification a été déplacé des noms de domaine vers les objets "contact". Aucune commande spécifique n’est disponible pour les bureaux d’enregistrement puisque ce processus de validation est réalisé par l’AFNIC via des procédures "off-line". Toutefois, cela a certains impacts sur la gestion des objets contacts qu’il convient de connaître. Tout titulaire devra être créé avant d’être utilisé dans une commande de création ou de transmission de nom de domaine. Par contre, bien qu’il faille fournir des informations d’identification (éléments <frnic:individualInfos> et <frnic:legalEntityInfos>), les vérifications initiales de celles-ci ne seront déclenchées que lorsque le contact sera référencé pour la première fois dans un nom de domaine. L’état dans lequel se trouve un objet contact dans le processus d’identification peut-être connu grâce à la valeur de l’élément <frnic:idStatus>. Lors de la création initiale du contact (de type titulaire), cet élément aura pour valeur "no". Lorsque ce contact est référencé comme titulaire pour un nom de domaine, cet état passe à "pending" (positionnant du même coup pour le nom de domaine en question, les états "serverTransferProhibited", "serverTradeProhibited" et "serverRecoverProhibited"). Bien que le processus d’identification puisse poser des problèmes (<frnic:idStatus> vaudra alors "problem"), les deux états finaux sont soit "ok", soit "ko". Un contact se trouvant dans un l’état "problem" ou "ko" ne pourra pas être utilisé dans une commande sur un nom de domaine. Par contre, rien n’interdit de référencer un contact titulaire non encore identifié qui se trouverait dans l’état "no" ou "pending".

- 60 -


Un contact dès lors qu’il aura été identifié pourra être utilisé sur autant de noms de domaine que le bureau d’enregistrement le souhaitera sans qu’aucune vérification supplémentaire ne soit effectuée. Par contre, un délai de péremption des données d’identification a été prévu de manière à ce que régulièrement celles-ci soient re-validées.

3.5. Récupération des données associées à un contact

La commande <contact:info> va permettre d’obtenir les informations d’un objet "contact". Compte tenu de la gestion particulière de ces objets, un certain nombre d’éléments ne seront pas présent ou auront une signification différente de ce qui peut être décrit dans le RFC 4933 lors de la réponse envoyée par le serveur. En voici la liste : <contact:crID> (adapté), <contact:crDate> (adapté), <contact:upID> (supprimé), <contact:trDate> (supprimé), <contact:authInfo> (supprimé) et <contact:disclose> (supprimé). De plus une extension est nécessaire pour tenir compte des données d’identification. En ce qui concerne <contact:crID> et <contact:crDate>, leur caractère obligatoire nous "oblige" à les conserver dans la réponse du serveur mais la gestion des objets "contact" antérieure à EPP nous pose quelques problèmes. En effet, il existe de très nombreux objets contacts dans notre base de données qui ne sont pas liés à un bureau d’enregistrement, il est donc difficile (voir impossible dans de nombreux cas) de déterminer quel est le bureau d’enregistrement à l’origine de celui-ci. Avec EPP, cette information pourra être progressivement introduite, mais cela représentera de toute façon une infime partie des objets "contact" par rapport à la base de ceux qui existent déjà. Les valeurs précises de ce champs seront indiquées ultérieurement (projet d’homogénéisation des objets "contact"). Pour <contact:crDate>, le problème est un peu différent puisque l’historique de nombreux objets est émaillé de plusieurs migrations, transformations, clonage, … Et que les dates réelles de création ne sont pas toujours évidentes à retrouver. Par contre, contrairement à <contact:crID>, l’approximation est ici permise, ce qui fait qu’une date sera de toute façon retournée mais qu’il ne faudra pas s’appuyer dessus si l’objet en question est vraiment trop ancien. Autre limitation par rapport au RFC 4933, mais ce point pourra faire l’objet d’une adaptation si nécessaire, seul le bureau d’enregistrement lié à cet objet contact pourra demander des informations sur celui-ci (cette règle est en cohérence avec ce que nous avons proposé pour les noms de domaine). Reprenons notre contact exemple (qui a entre temps été utilisé comme titulaire pour un nom de domaine) et demandons à notre serveur de nous fournir les informations dont nous avons besoin :

- 61 -


C:<?xml version="1.0" encoding="UTF-8" standalone="no"?> C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> C: <command> C: <info> C: <contact:info C: xmlns:contact="urn:ietf:params:xml:ns:domain-1.0"> C: <contact:id>VL99999</contact:id> C: </contact:info> C: </info> C: <clTRID>une-reference-client-par-exemple</clTRID> C: </command> C:</epp> Comme d’habitude, la requête se fait en utilisant l’identifiant du contact qui est différent du Nic-Handle. La réponse du serveur sera la suivante :

S:<?xml version="1.0" encoding="UTF-8" standalone="no"?> S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0"> S: <response> S: <result code="1000"> S: <msg>Command completed successfully</msg> S: </result> S: <resData> S: <contact:infData S: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0"> S: <contact:id>VL99999</contact:id> S: <contact:roid>VL9999-FRNIC</contact:roid> S: <contact: status s="linked"/> S: <contact:postalInfo type="loc"> S: <contact:name>Levigneron</contact:name> S: <contact:org>AFNIC</contact:org> S: <contact:addr> S: <contact:street>immeuble international</contact:street> S: <contact:street>2, rue Stephenson</contact:street> S: <contact:street>Montigny le Bretonneux</contact:street> S: <contact:city>Saint Quentin en Yvelines Cedex</contact:city> S: <contact:pc>78181</contact:pc> S: <contact:cc>FR</contact:cc> S: </contact:addr> S: </contact:postalInfo> S: <contact:voice>+33.0139308333</contact:voice> S: <contact:fax>+33.0139308301</contact:fax> S: <contact:email>[email protected]</contact:email> S: <contact:clID>BEactuelID</contact:clID> S: <contact:crID>BEcreateurID</contact:crID> S: <contact:crDate>2008-11-20T00:00:00.0Z</contact:crDate> S: <contact:update>2008-12-25T00:00:00.0Z</contact:update> S: </contact:infData> S: </resData> S: <extension> S: <frnic:ext S: xmlns:frnic="http://www.afnic.fr/xml/epp/frnic-1.0"> S: <frnic:resData> S: <frnic:infData> S: <frnic:contact> S: <frnic:surname>Vincent</frnic:surname> S: <frnic:list>restrictedPublication</frnic:list> S: <frnic:individualInfos>

- 62 -


S: <frnic:idStatus>ok</frnic:idStatus> S: <frnic:birthdate>1968-07-20</frnic:birthdate> S: <frnic:birthcity>Rouen</frnic:birthcity> S: <frnic:pc>76000</frnic:pc> S: <frnic:cc>FR</frnic:cc> S: </frnic:individualInfos> S: </frnic:contact> S: </frnic:infData> S: </frnic:resData> S: </frnic:ext> S: </extension> S: <trID> S: <clTRID>une-reference-client-par-exemple</clTRID> S: <svTRID>frnic-00000023</svTRID> S: </trID> S: </response> S:</epp>

On remarquera que l’état dans le processus d’identification est indiqué via l’élément <frnic:idStatus> fils de <frnic:individualInfos> et <frnic:legalEntityInfos>.

epp à l’afnic- 2 - epp à l’afnic spécifications rc 1.0 - 30/06/08 table des matières 1....

Documents