1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
|
Titre: RFC 8056: Extensible Provisioning Protocol (EPP) and Registration Data Access Protocol (RDAP) Status Mapping
Auteur:
Date: Wed 18 Jan 2017 01:00:00 +0100
Lien: https://www.bortzmeyer.org/8056.html
Deux protocoles utilisés dans l'industrie des noms de domaine, EPP et RDAP, ont
la notion d'état d'un nom de domaine, indiquant, par exemple, que ce nom est
verrouillé et ne doit pas être modifié. Mais les états de EPP et de RDAP sont
différents, et pas toujours évidents à rapprocher. Ce nouveau RFC précise la
correspondance entre les états EPP et les états RDAP, établissant la liste
comparée.
EPP (protocole d'avitaillement d'objets dans un registre, par exemple un
registre de noms de domaine) est normalisé dans divers RFC (STD 69)[1], ceux
qui décrivent les états sont les RFC 5731 (section 2.3), RFC 5732 (section
2.3), RFC 5733 (section 2.2) et RFC 3915 (section 3.1). Les états RDAP
(protocole d'information sur les objets d'un registre, qui vise à remplacer[2]
whois) sont normalisés dans le RFC 7483 (section 10.2) qui crée un registre
IANA des états possibles[3]. Pourquoi des états différents dans ces deux
protocoles ? Disons qu'ils ont été conçus pour des buts différents, et que la
nécessité de faire correspondre les états de l'un avec ceux de l'autre n'est
devenue évidente qu'après. Le but de ce nouveau RFC est justement d'établir une
correspondance univoque entre les états d'EPP et de RDAP.
La section 2 de notre RFC commence par une liste des états EPP, avec leur
équivalent RDAP (quand il existe). Par exemple, il est assez évident que le
pendingDelete d'EPP (RFC 5731) correspond au pending delete de RDAP. De même,
le ok d'EPP est clairement l'équivalent du active de RDAP. Mais les addPeriod
(RFC 3915, durée après l'enregistrement d'un nom de domaine pendant laquelle on
peut annuler l'enregistrement gratuitement) ou clientHold (RFC 5731, le client
a demandé que ce nom de domaine ne soit pas publié dans le DNS) d'EPP n'ont pas
d'équivalent RDAP. L'inverse existe aussi, le delete prohibited de RDAP n'a pas
un équivalent simple en EPP, qui a deux états pour cela, selon que
l'interdiction a été posée par le client EPP ou par le serveur.
La section 2 du RFC se continue donc avec ce qui est désormais la liste
officielle des correspondances, en tenant compte des nouveaux états ajoutés,
par exemple dans le registre RDAP[4]. C'est ainsi qu'un add period et un client
hold ont été ajoutés (section 3 du RFC), ainsi qu'un client delete prohibited
et un server delete prohibited, pour préciser le delete prohibited.
Pour les TLD gérés par l'ICANN, il va sans doute être obligatoire d'utiliser
ces nouveaux états.
Liens:
[1]: https://www.rfc-editor.org/info/std69 (lien)
[2]: http://www.bortzmeyer.org/weirds-rdap.html (lien)
[3]: https://www.iana.org/assignments/rdap-json-values/ (lien)
[4]: https://www.iana.org/assignments/rdap-json-values/rdap-json-values.xml#rdap-json-values-1 (lien)
|
