Initiale releaseHEADmaster

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)