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.

Processus RSEP accéléré

Certains services de registre fréquemment demandés par les opérateurs de registre via le processus RSEP ont abouti au langage d'autorisation normalisé (généralement sous la forme d'un amendement du contrat de registre (RA)). Pour plusieurs de ces services, l'organisation ICANN a établi des formulaires de demande RSEP simplifiés pour un processus RSEP accéléré. La présente page web recense les services disponibles via le processus RSEP accéléré.

La présente page web sera mise à jour de temps à autre avec des services supplémentaires qui correspondent à cette description. Veuillez noter que le service IDN a recours au langage d'autorisation normalisé. Pour en savoir plus, consultez la page consacrée aux demandes de service IDN.

Processus RSEP accéléré

Le processus RSEP accéléré est une version simplifiée du processus RSEP qui impose à l'opérateur de registre d'utiliser le langage d'autorisation spécifié (généralement sous la forme d'un amendement du RA) sans modification. Les demandes RSEP accéléré visent à raccourcir le processus, de la présentation de la demande à l'autorisation, par rapport à une demande RSEP standard.

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

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

  1. Présentation d'une demande RSEP accéléré - répertoriée sous la rubrique « RSEP accéléré-[nom du service] » sur 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 liées à la concurrence (d) et fournir les informations relatives au signataire (contact de l'autorité chargée de procéder à un amendement du RA).
  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. Examen de l'ICANN (durée prévue : 12 jours calendaires) - dès que la demande est soumise à l'examen de l'ICANN, elle est publiée sur la page web du processus RSEP. L'organisation ICANN procède à l'examen du service proposé afin de déterminer s'il soulève d'importants problèmes en matière de sécurité, stabilité ou concurrence. À l'issue de l'examen de l'ICANN, l'organisation ICANN informera l'opérateur de registre de sa détermination préliminaire eu égard au service proposé.
    1. Si le service proposé implique aussi de changer le fournisseur d'une fonction critique (tel que défini dans l'article 6 de la spécification 10 du RA), l'organisation ICANN rappellera à l'opérateur de registre qu'il est tenu de soumettre une demande de modification du 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 le lancement de cette étape : 5 jours calendaires) - en cas d'approbation suite à l'examen de l'ICANN, l'organisation ICANN lancera le processus d'autorisation (pour procéder à un amendement du RA ou pour envoyer une lettre d'accord de déploiement) dans les 5 jours calendaires. La détermination et l'autorisation sont publiées sur la page 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 l'amendement du RA, dans l'hypothèse où (a) un bureau d'enregistrement achèterait une partie, mais pas la totalité, du portefeuille de noms de domaine d'un autre bureau d'enregistrement dans le TLD, ou (b) un bureau d'enregistrement récemment accrédité demanderait le transfert de tous les noms de domaine du bureau d'enregistrement sortant pour lequel le bureau d'enregistrement entrant a fait office de 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 enregistrement fiduciaire supplémentaire tel qu'indiqué dans les options de langage de modification du RA 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

Archives

La présente page web a été mise à jour en juin 2019 dans le cadre des améliorations opérationnelles du processus RSEP (voir le billet de blog 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."