T. SattlerR. CarneyJ. Kolker (GoDaddy)December20212021-12-26
Un registre, par exemple un registre de noms de
domaine, utilise parfois le protocole
EPP pour la communication avec ses
clients. Ce RFC décrit comment utiliser ce
protocole pour informer les clients des périodes d'indisponibilité
du registre, par exemple lors d'une opération de maintenance.
Aujourd'hui, un registre prévient de ses periodes
d'indisponibilité prévues par divers moyens : courriers aux BE, messages sur des
réseaux sociaux, page Web dédiée comme :
Chaque registre le
fait de façon différente, il n'existe pas de règles communes, et le
côté non-structuré de ces annonces fait qu'il faut une interventon
humaine pour les analyser et les mettre dans un agenda. Et un
BE peut devoir
interagir avec de nombreux registres ! Notre RFC propose d'utiliser
EPP
() pour ces annonces.
Donc, premier principe, puisqu'on va souvent manipuler des dates,
les dates et heures seront toutes représentées en UTC et dans le format
du . Ensuite, les annonces seront dans
un élément XML<item>, de
l'espace de nomsurn:ietf:params:xml:ns:epp:maintenance-1.0
(enregistré
à l'IANA). Parmi les sous-éléments de cet élément :
id, un identificateur de
l'évènement,systems, qui permettra de désigner les
systèmes affectés,environment, pour dire si l'évènement
concerne la production ou bien un banc de test,start et end, qui
indiquent le début et la fin (prévue…) de l'évènement,et plusieurs autres éléments.
Un exemple d'évènement, une intervention sur le serveur EPP
epp.registry.example de production, peut être :
2e6df9b0-4092-4491-bcc8-9fb2166dcee6EPPepp.registry.examplefull2021-12-30T06:00:00Z2021-12-30T07:00:00Zplanned
https://www.registry.example/notice?123
exampletest
]]>
On voit que le serveur EPP sera arrêté pendant une heure
(<impact>full</impact> indiquant
une indisponibilité totale) et que cela affectera les TLD.example et .test. Une
telle information, étant sous une forme structurée, peut être
analysée par un programme et automatiquement insérée dans un agenda,
ou un système de supervision.
Les commandes EPP exactes, maintenant (section 4 du RFC). La
commande <info> peut renvoyer maintenant
un élément <maint:info> qui contient
l'information de maintenance. Voici l'exemple du RFC. D'abord, la
question du client, qui veut de l'information sur l'évènement
2e6df9b0-4092-4491-bcc8-9fb2166dcee6 :
2e6df9b0-4092-4491-bcc8-9fb2166dcee6
]]>
Puis la réponse du serveur :
Command completed successfully2e6df9b0-4092-4491-bcc8-9fb2166dcee6
Routine MaintenanceEPPepp.registry.example
full2021-12-30T06:00:00Z2021-12-30T07:00:00Zplanned
https://www.registry.example/notice?123
free-text
Freitext
exampletestfalsefalse2021-11-08T22:10:00Z
...
]]>
Ici, le client connaissait l'identificateur d'une opération de
maintenance particulière. S'il ne le connait pas et veut récupérer
une liste d'événements :
]]>
Il récupérera alors une <maint:list>, une
liste d'opérations de maintenance.
Le client EPP peut
également être prévenu des maintenances par la commande
<poll>, qui dote EPP d'un système de
messagerie (, section 2.9.2.3). Ainsi,
un message dans la boite aux lettres du client pourra être :
Command completed successfully; ack to dequeue2021-11-08T22:10:00ZRegistry Maintenance Notification2e6df9b0-4092-4491-bcc8-9fb2166dcee6createEPPepp.registry.example
full
...
]]>
La section 5 du RFC décrit la syntaxe formelle de cette extension
(en XML Schema). Elle est dans le
registre IANA des extensions à EPP.
Et question mises en œuvre ? Apparemment, les registres gérés par
GoDaddy et Tango envoient déjà ces
informations de maintenance.