Skip to main content
Resources

Processus RSEP accéléré et langage d’autorisation normalisé

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.

Certains services de registre fréquemment demandés par les opérateurs de registre à travers le processus RSEP ont abouti au langage d'autorisation normalisé (généralement sous la forme d'un amendement au contrat de registre (RA)), dénommés services connus. Pour plusieurs de ces services connus, l'organisation ICANN a également établi des formulaires de demande RSEP simplifiés pour un processus RSEP accéléré. Cette page Web présente les services disponibles à travers le processus RSEP accéléré et d'autres services connus avec langage d'autorisation normalisé.

Cette page Web sera mise à jour de temps à autre avec des services supplémentaires qui correspondent à cette description.

Processus RSEP accéléré

Le processus RSEP accéléré est une version simplifiée du processus RSEP qui demande à l'opérateur de registre d'utiliser le langage d'autorisation spécifié (généralement sous la forme d'un amendement au contrat de registre) sans modification. Les demandes de processus RSEP accéléré visent à un processus plus court, de la présentation à l'autorisation, que celui qui caractérise une demande RSEP standard.

Si un opérateur de registre souhaite modifier le langage d'autorisation d'une demande RSEP accélérée, elle doit être présentée comme une demande RSEP standard. Un opérateur de registre peut retirer sa demande RSEP à tout moment en présentant un commentaire dans le portail des services de nommage.

Le processus RSEP accéléré est divisé en quatre (4) étapes :

  1. Présenter une demande RSEP accélérée - répertoriée sous la rubrique « RSEP accéléré-[nom du service] » dans le portail des services de nommage. Suivez les étapes pour (a) confirmer le service proposé, (b) confirmer le langage d'autorisation normalisé, (c) répondre aux questions standard de concurrence (d) et fournir l'information du signataire (contact avec l'autorité d'exécuter une modification au contrat de registre).
  2. Vérification d'exhaustivité de l'organisation ICANN (durée prévue : 5 jours calendaires) - une demande est considérée comme complète si l'opérateur de registre a répondu à tous les champs requis dans le formulaire. Au cours de cette étape, la demande RSEP n'est pas publiée.
  3. Révision de l'ICANN (durée prévue : 12 jours calendaires) - dès que la demande fait l'objet de la révision de l'ICANN, elle est publiée sur la page Web du processus RSEP. L'organisation ICANN fait la révision du service proposé afin de déterminer s'il soulève des problèmes importants en matière de sécurité, de stabilité, ou de concurrence. À la fin de la révision de l'ICANN, l'organisation ICANN informera l'opérateur de registre de sa détermination préliminaire sur le service de registre proposé.

    1. Si le service proposé exige aussi de changer le fournisseur d'une fonction critique (tel que défini dans l'article 6 de la spécification 10 du contrat de registre), l'organisation ICANN rappellera à l'opérateur de registre qu'il est tenu de soumettre une demande de modification au Contrat de sous-traitance partiel de fonctions critiques (MSA) une fois que la demande RSEP sera approuvée (exemple : validation d'un enregistrement selon la loi en vigueur avec enregistrement fiduciaire)
  4. Détermination et traitement final (durée prévue pour initier cette étape : 5 jours calendaires) - si cela est approuvé à la suite de la révision de l'ICANN, l'organisation ICANN lancera le processus d'autorisation (pour exécuter une modification au contrat de registre ou pour envoyer une lettre libre d'être utilisé) dans les 5 jours calendaires. La détermination et l'autorisation sont publiées sur le site Web du processus RSEP.

Le processus RSEP accéléré est disponible pour les services suivants :

Nom du service Description Langage de modification du RA pré-approuvé

Transfert groupé après l'acquisition partielle de portefeuille (BTAPPA)

Ce service permet aux opérateurs de registre d'offrir aux bureaux d'enregistrement la possibilité d'effectuer un transfert groupé, en vertu des spécifications de la modification du contrat de registre, circonstance où (a) un bureau d'enregistrement achète une partie importante du portefeuille de noms de domaine du bureau d'enregistrement dans le TLD, ou (b) un bureau d'enregistrement récemment accrédité demande le transfert de tous les noms de domaine du bureau d'enregistrement sortant pour lequel le bureau d'enregistrement entrant a servi comme revendeur.

Transfert groupé après l'acquisition partielle de portefeuille (BTAPPA)

Validation d'un enregistrement selon la loi en vigueur avec ou sans enregistrement fiduciaire

Ce service permet aux opérateurs de registre de valider un enregistrement pour se conformer à la loi en vigueur dans une juridiction donnée. Les opérateurs de registre peuvent offrir ce service avec ou sans un enregistrement fiduciaire supplémentaire tel qu'identifié dans les options de langage de modification du contrat de registre pré-approuvées.

Verrouillage du registre

Ce service aide à se protéger contre des transferts involontaires, des modifications ou des suppressions de données d'enregistrement de noms de domaine en permettant à un représentant autorisé d'un bureau d'enregistrement parrain de demander l'activation ou la désactivation de certains statuts du protocole d'avitaillement extensible (EPP).

Verrouillage du registre

Autres services connus avec langage d'autorisation normalisé

Les services suivants ne sont pas disponibles dans le processus RSEP accéléré, mais ils utilisent encore le langage de modification au contrat de registre pré-approuvé qui aidera à simplifier le processus RSEP standard. Pour ces services, présenter une demande RSEP standard (voir le Guide RSEP) et inclure un lien au langage d'amendement au contrat de registre approprié (ci-dessous) dans la section applicable du formulaire de demande RSEP.

Nom du service Description Langage de modification du RA pré-approuvé

Noms de domaine internationalisés (IDN) -Ce service permet aux opérateurs de registre d'offrir des noms de domaine non-ASCII au second niveau ou à des niveaux plus bas.

Les opérateurs de registre sont encouragés à utiliser des tables de référence des règles de génération d'étiquettes (LGR) pré-approuvées et normalisées.

(a) Ajouter un service IDN et activer des variantes

Ce modèle s'adresse aux opérateurs de registre qui n'ont pas été approuvés pour offrir des IDN. L'opérateur de registre activera des variantes.

Ajouter un service IDN et activer des variantes

(b) Ajouter un service IDN et verrouiller les variantes

Ce modèle s'adresse aux opérateurs de registre qui n'ont pas été préalablement approuvés pour offrir des IDN. L'opérateur de registre verrouillera les variantes.

Ajouter un service IDN et verrouiller les variantes

(c) Ajouter un service IDN et ne pas offrir des variantes

Ce modèle s'adresse aux opérateurs de registre qui n'ont pas été approuvés pour offrir des IDN. L'opérateur de registre n'offrira pas de variantes.

Ajouter un service IDN et ne pas offrir des variantes

(d) Ajouter des langages/scripts IDN

Ce modèle s'adresse aux opérateurs de registre qui ont été approuvés pour offrir des IDN et qui prévoient d'offrir des IDN avec des langages/scripts supplémentaires.

Ajouter des langages/scripts IDN

(e) Supprimer des langages/scripts IDN

Ce modèle s'adresse aux opérateurs de registre qui prévoient de ne plus offrir des IDN dans des langages/scripts spécifiques.

Supprimer des langages/scripts IDN

Archives

Cette page Web a été mise à jour en juin 2019 dans le cadre des améliorations opérationnelles du processus RSEP (voir le blog post de l'organisation ICANN). La version archivée de cette page Web est disponible ici.

Domain Name System
Internationalized Domain Name ,IDN,"IDNs are domain names that include characters used in the local representation of languages that are not written with the twenty-six letters of the basic Latin alphabet ""a-z"". An IDN can contain Latin letters with diacritical marks, as required by many European languages, or may consist of characters from non-Latin scripts such as Arabic or Chinese. Many languages also use other types of digits than the European ""0-9"". The basic Latin alphabet together with the European-Arabic digits are, for the purpose of domain names, termed ""ASCII characters"" (ASCII = American Standard Code for Information Interchange). These are also included in the broader range of ""Unicode characters"" that provides the basis for IDNs. The ""hostname rule"" requires that all domain names of the type under consideration here are stored in the DNS using only the ASCII characters listed above, with the one further addition of the hyphen ""-"". The Unicode form of an IDN therefore requires special encoding before it is entered into the DNS. The following terminology is used when distinguishing between these forms: A domain name consists of a series of ""labels"" (separated by ""dots""). The ASCII form of an IDN label is termed an ""A-label"". All operations defined in the DNS protocol use A-labels exclusively. The Unicode form, which a user expects to be displayed, is termed a ""U-label"". The difference may be illustrated with the Hindi word for ""test"" — परीका — appearing here as a U-label would (in the Devanagari script). A special form of ""ASCII compatible encoding"" (abbreviated ACE) is applied to this to produce the corresponding A-label: xn--11b5bs1di. A domain name that only includes ASCII letters, digits, and hyphens is termed an ""LDH label"". Although the definitions of A-labels and LDH-labels overlap, a name consisting exclusively of LDH labels, such as""icann.org"" is not an IDN."