diff options
author | neodarz <neodarz@neodarz.net> | 2017-03-10 11:58:22 +0100 |
---|---|---|
committer | neodarz <neodarz@neodarz.net> | 2017-03-10 11:58:22 +0100 |
commit | bc1d70343807104ccf64b6bde9b2db54270203ff (patch) | |
tree | 122467d5cad8688bc609a1509e922dce5d70d391 /RFC_8056_Extensible_Provisioning_Protocol_EPP_and_Registration_Data_Access_Protocol_RDAP_Status_Mapping.txt | |
download | read_it_later-bc1d70343807104ccf64b6bde9b2db54270203ff.tar.xz read_it_later-bc1d70343807104ccf64b6bde9b2db54270203ff.zip |
Diffstat (limited to 'RFC_8056_Extensible_Provisioning_Protocol_EPP_and_Registration_Data_Access_Protocol_RDAP_Status_Mapping.txt')
-rw-r--r-- | RFC_8056_Extensible_Provisioning_Protocol_EPP_and_Registration_Data_Access_Protocol_RDAP_Status_Mapping.txt | 49 |
1 files changed, 49 insertions, 0 deletions
diff --git a/RFC_8056_Extensible_Provisioning_Protocol_EPP_and_Registration_Data_Access_Protocol_RDAP_Status_Mapping.txt b/RFC_8056_Extensible_Provisioning_Protocol_EPP_and_Registration_Data_Access_Protocol_RDAP_Status_Mapping.txt new file mode 100644 index 0000000..0662e4f --- /dev/null +++ b/RFC_8056_Extensible_Provisioning_Protocol_EPP_and_Registration_Data_Access_Protocol_RDAP_Status_Mapping.txt @@ -0,0 +1,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) |