Politique d’information supplémentaire sur les services d’annuaire de données d’enregistrement (RDDS)
Veuillez noter que seule la version anglaise des contenus et des documents traduits a un caractère officiel. Les traductions dans d’autres langues sont fournies uniquement à titre informatif.
Document mis à jour le 21 février 2024 pour refléter les changements nécessaires à la mise en œuvre de la politique sur les données d’enregistrement. Auparavant, cette politique était connue sous le nom de politique relative aux informations WHOIS supplémentaires. Les parties contractantes peuvent mettre en œuvre la présente politique mise à jour à compter du 21 août 2024 et doivent la mettre en œuvre au plus tard le 21 août 2025.
Les mots clés « DOIT/DOIVENT », « NE DOIT PAS/NE DOIVENT PAS », « REQUIS », « DEVRA/DEVRONT», « NE DEVRA PAS/NE DEVRONT PAS », « DEVRAIT/DEVRAIENT », « NE DEVRAIT PAS/NE DEVRAIENT PAS », « RECOMMANDÉ », « NON RECOMMANDÉ », « PEUT/PEUVENT », et « FACULTATIF » dans ce document doivent être interprétés comme décrit dans la BCP 14 [RFC2119] [RFC8174] si, et seulement si, ils apparaissent en majuscules, comme indiqué ici.
La section 1 de la présente politique détaille les exigences indépendantes de la technologie qui s’appliquent à tous les services d’annuaire de données d’enregistrement.
La section 2 de cette politique détaille les exigences de mise en œuvre relatives au WHOIS (disponible via le port 43) et aux services d’annuaire WHOIS basés sur le Web uniquement.
Les bureaux d’enregistrement et les opérateurs de registre de domaines génériques de premier niveau (gTLD) accrédités par l’ICANN sont obligés, conformément à leurs contrats respectifs avec l’ICANN, de fournir un accès basé sur les requêtes à certaines données d’enregistrement. Cette politique relative aux informations supplémentaires du RDDS exige par ailleurs que les bureaux d’enregistrement et les opérateurs de registre incluent dans leurs résultats du RDDS des informations qui aident les utilisateurs du RDDS à mieux identifier un enregistrement auprès d’un bureau d’enregistrement sponsor et comprendre les codes d’état utilisés par les opérateurs de registre et les bureaux d’enregistrement, comme suit :
- Les opérateurs de registre et les bureaux d’enregistrement DOIVENT mettre en œuvre les exigences suivantes :
1.1 inclure dans leur résultat du RDDS le message suivant : « Pour de plus amples informations sur les codes d’état du domaine, veuillez vous rendre sur https://icann.org/epp »*
*Veuillez noter que la forme plus longue du lien ci-dessus précédemment incluse dans l’article 1 (c), c’est à dire, https://www.icann.org/resources/pages/epp-status-codes-2014-06-16-en, est également conforme à cette politique.
1.2 Les opérateurs de registre DOIVENT utiliser l’identificateur unique global de bureau d’enregistrement émis par l’ICANN (GURID, connu comme l’ID IANA) dans leurs résultats du RDDS.
- Les opérateurs de registre et les bureaux d’enregistrement DEVRONT mettre en œuvre les exigences suivantes pour le WHOIS (disponible via le port 43) et les services d’annuaire WHOIS basés sur le Web :
2.1 Le ou les états DOIVENT être affichés à l’aide de leurs codes EPP respectifs ;
2.2 Un lien ou une adresse URL DOIVENT apparaître près de chaque code EPP qui dirige vers une page Internet de l’ICANN décrivant et définissant le code EPP respectif. Une liste des adresses URL est disponible sur https://www.icann.org/resources/pages/epp-status-codes-list-2014-06-18-en ;
2.3 Les bureaux d’enregistrement NE DEVRONT PAS retirer les liens et les messages décrits ci-dessus lorsqu’ils fournissent des données du service WHOIS de leur propre opérateur de registre ou bureau d’enregistrement (ou d’un autre).
Remarques : la politique relative aux informations WHOIS supplémentaires (AWIP), renommée comme Services d’annuaire de données d’enregistrement supplémentaires (ARIP), a été adoptée par l’ICANN comme politique de consensus le 6 mai 2012. La date de mise en application de cette politique est le 31 janvier 2016. L’ensemble des bureaux d’enregistrement accrédités par l’ICANN et les opérateurs de registre gTLD sont tenus de se conformer à l’ARIP pour les enregistrements qu’ils gèrent dans tous les gTLD, pour lesquels ils sont accrédités ou qu’ils administrent en commençant à la date de mise en application.
L’objectif de cette politique est de clarifier la signification des codes EPP dans les données du RDDS et demander une identification correcte des bureaux d’enregistrement au moyen de leur GURID dans le RDDS.
Contexte : le 24 juin 2009, le conseil de la GNSO a lancé un processus d’élaboration de politiques (PDP) en lien avec la politique de transfert de noms de domaine entre bureaux d’enregistrement (IRTP) (http://gnso.icann.org/en/council/resolutions#200906 – r- résolution 20090624-2) et le groupe de travail du PDP (groupe de travail IRTP B) a soumis son rapport final le 30 mai 2011 avec un ensemble de recommandations (http://gnso.icann.org/issues/transfers/irtp-b-final-report-30may11-en.pdf [PDF, 971 KB]), dont la Recommandation 8 pour normaliser et clarifier les messages RDDS concernant l’état « verrouillé par le bureau d’enregistrement » . Le 22 juin 2011, le conseil de la GNSO a pris cette résolution avant de considérer l’approbation de la recommandation concernant la normalisation et la clarification des messages d’état du RDDS, à savoir l’état « verrouillé par le bureau d’enregistrement ». Le conseil de la GNSO pourrait demander au personnel de l’ICANN de présenter une proposition conçue pour s’assurer qu’une approche techniquement faisable soit développée dans le but de mettre en place cette recommandation. En réponse à cette demande, le personnel de l’ICANN a élaboré une proposition en consultation avec le groupe de travail qui a été publiée pour consultation publique et a ensuite été adoptée par le conseil de la GNSO le 16 février 2012 (http://gnso.icann.org/en/council/resolutions#20120216-1). Suite à un autre forum de commentaires publics sur la recommandation et la proposition (http://www.icann.org/en/news/public-comment/irtp-b-rec8-21feb12-en.htm) le Conseil d’administration de l’ICANN les a adoptées le 6 mai 2012. (https://www.icann.org/en/groups/board/documents/resolutions-06may12-en.htm#1.5)
Le 22 septembre 2011, un groupe de travail supplémentaire de la GNSO (groupe de travail IRTP C) a été chargé d’analyser trois questions liées à l’IRTP, y compris le fait de savoir si le processus pourrait être rationalisé en obligeant les registres à utiliser les ID IANA pour les bureaux d’enregistrement plutôt que les ID des propriétaires (https://community.icann.org/display/gnsoirtppdpwg/3.+WG+Charter). Le groupe de travail a émis un rapport initial qui a fait l’objet de commentaires publics et a ensuite émis un rapport final qui a été adopté par le conseil de la GNSO le 17 octobre 2012. Suite à un autre forum de commentaires publics, le Conseil d’administration de l’ICANN a adopté les recommandations du rapport final le 20 décembre 2012 (http://www.icann.org/en/groups/board/documents/minutes-20dec12-en.htm#2.a).