Groupe de travail Réseau	S. Hollenbeck	
Request for Comments : 2832	M. Srivastava	
Catégorie : Information	Network Solutions, Inc. Registry	
Traduction Claude Brière de L’Isle	mai 2000	

Protocole NSI Registry de registraire (RRP) version 1.1.0

Statut de ce mémoire
Le présent mémoire apporte des informations à la communauté de l’Internet. Il ne spécifie aucune norme de l’Internet. La distribution du présent mémoire n’est soumise à aucune restriction.

Notice de copyright
Copyright (C) The Internet Society (2000). Tous droits réservés.

Résumé
Le présent document décrit un protocole pour l’enregistrement et la gestion des noms de domaine de second niveau et des serveurs de noms associés dans les domaines génériques de niveau supérieur (gTLD, generic Top Level Domain) et les domaines de niveau supérieur de code de pays (ccTLD, country code Top Level Domain). Ce protocole a été développé par Network Solutions, Inc. Registry pour être utilisé au sein du système d’enregistrement partagé et est publié "tel quel" pour documenter les mises en œuvre du protocole qui ont été développées par Network Solutions, Inc. Registry.

L’enregistrement des noms de domaine Internet implique normalement trois entités : un postulant qui souhaite enregistrer un nom de domaine, un registraire qui fournit les services au postulant, et un registre qui fournit les services au registraire tout en servant de dépositaire d’autorité de toutes les informations fonctionnelles requises pour résoudre les noms enregistrés dans les TLD du registre. Le présent document décrit un protocole pour les seules communications entre registre et registraire. Le protocole ne fournit aucun service au postulant.

Le présent document est discuté sur la liste de diffusion "rrp". Pour se joindre à la liste, envoyer un message à <majordomo@NSIRegistry.com> avec les mots "subscribe rrp" dans le corps du message. Il y a aussi un site de la Toile pour les archives de la liste de diffusion à http://www.NSIRegistry.net/maillist/rrp .

Conventions utilisées dans ce document
Dans le présent document, les mots clés "DOIT", "NE DOIT PAS", "EXIGE", "DEVRA", "NE DEVRA PAS", "DEVRAIT", "NE DEVRAIT PAS", "RECOMMETE", "PEUT", et "FACULTATIF" sont à interpréter comme décrit dans le BCP 14, [RFC2119].

De plus, le terme "attribut implicite" se réfère à un attribut d’entité dont la valeur est déduite d’un autre attribut ou est dépendante d’une session RRP établie.

Dans les exemples, "C:" représente les lignes envoyées par le client du registraire et "S:" représente les lignes envoyées par le serveur du registre.

Le terme "système" est utilisé dans le présent document pour se référer collectivement au présent protocole et aux logiciels et matériels qui mettent en œuvre le protocole.
Table des Matières
1. Introduction	2
2. Services de sécurité	3
2.1 Sécurité de connexion	3
2.2 Sécurité des données du système	3
3. Modèle de connexion	3
4. Description du protocole	4
4.1 Format de demande	4
4.2 Format de réponse	5
4.3 Commandes du protocole	5
5. Codes de réponse	13
5.1 Liste des codes de réponse	13
5.2 Correspondance commande-réponse	17
6. Codes d’état de domaine	17
6.1 Description du code d’état de domaine	18
7. Syntaxe formelle	18
8. Internationalisation	21
9. Problèmes connus	22
10. Considérations pour la sécurité	23
11. Considérations relatives à l’IANA	23
12. Références	23
13. Remerciements	23
14. Adresse des auteurs	23
15. Déclaration complète de droits de reproduction	23

1.	Introduction

Le présent document décrit les spécifications pour le protocole de registre à registraire (RRP, Registry Registrar Protocol) version 1.1.0 de NSI, un protocole de texte en US ASCII à 7 bits fondé sur TCP qui permet à plusieurs registraires de fournir des services d’enregistrement de nom de domaine Internet de second niveau dans les domaines de niveau supérieur (TLD, top level domain) administrés par un registre de TLD. RRP est spécifié en utilisant le format Backus-Naur augmenté (ABNF) comme décrit dans la [RFC2234]. Noter que toutes les chaînes ABNF littérales sont insensibles à la casse et que les exemples fournis dans ce document peuvent utiliser une casse mixte pour améliorer la lisibilité.

RRP a été développé par Network Solutions, Inc. Registry sous les auspices du programme Système d’enregistrement partagé. Le protocole a été initialement déployé en avril 1999 au titre d’une mise en œuvre expérimentale du système d’enregistrement partagé avec cinq registraires. Des registraires supplémentaires ont commencé à utiliser le protocole en juillet 1999. Les expériences de fonctionnement du registre et des registraires ont permis d’identifier plusieurs problèmes qui ont été mentionnés ici sous la rubrique "problèmes connus".

Le présent document donne une description d’un protocole et mentionne les leçons tirées des expériences de fonctionnement qui peuvent être utiles comme premières étapes du développement d’un protocole de services d’enregistrement de domaine en cours de normalisation. Le présent document et le protocole qu’il décrit pourront être modifiés à l’avenir sur la base de la poursuite de l’expérience de son fonctionnement et des réactions de la communauté.

Le registre mémorise les informations sur les noms de domaines enregistrés et les serveurs de noms associés. Les données d’un nom de domaine incluent son nom, les serveurs de noms, le registraire, la date d’expiration de l’enregistrement, et l’état. Les données d’un serveur de noms incluent son nom de serveur, les adresses IP, et le registraire. Un registraire PEUT en utilisant RRP effectuer les procédures de service d’enregistrement suivantes :
-	Déterminer si un nom de domaine a été enregistré.
-	Enregistrer un nom de domaine.
-	Renouveler l’enregistrement d’un nom de domaine.
-	Annuler l’enregistrement d’un nom de domaine.
-	Mettre à jour les serveurs de noms d’un nom de domaine.
-	Transférer un nom de domaine provenant d’un autre registraire.
-	Examiner l’état des noms de domaine que le registraire a enregistré.
-	Modifier l’état des noms de domaine que le registraire a enregistré.
-	Déterminer si un serveur de noms a été enregistré.
-	Enregistrer un serveur de noms.
-	Mettre à jour les adresses IP d’un serveur de noms.
-	Supprimer un serveur de noms.
-	Examiner l’état des serveurs de noms que le registraire a enregistré.

Toutes les commandes RRP comportent des dispositifs pour assurer l’idempotence. C’est-à-dire que l’effet de chaque commande est le même si la commande est exécutée une fois ou si la commande est exécutée plusieurs fois. Cette propriété est extrêmement utile dans des situations où une commande est réessayée à cause d’une condition d’erreur qui résulte en une réponse manquée à une commande et qu’est tenté un nouvel essai de la commande. Les ré essais de commande seront capturés par le système et rejetés avec un code de réponse d’erreur approprié. Les paramètres de commande qui ne fournissent pas l’idempotence seront expliqués pleinement au titre de la description de commande appropriée.

2.	Services de sécurité

RRP fournit seulement les services de base d’authentification du registraire sur la base d’un mot de passe. Des services de sécurité supplémentaires, incluant la confidentialité et l’authentification du registraire au moyen d’un chiffrement à clé publique seront fournis par d’autres caractéristiques du système.

2.1	Sécurité de connexion
Chaque session RRP DOIT être chiffrée en utilisant le protocole couche de connexion sécurisée (SSL, Secure Socket Layer) v3.0 tel que spécifié dans la [RFC6101]. SSL fournit des services de confidentialité qui réduisent le risque de divulgation par inadvertance d’informations sensibles du registraire, telles que l’identifiant d’utilisateur et le mot de passe du registraire.

SSL prend en charge l’authentification mutuelle du client et du serveur en utilisant des certificats numériques signés. Le système d’enregistrement partagé mis en œuvre par NSI Registry exige des certificats numériques produits par une autorité de certification commerciale à la fois pour les clients de registraire et pour les serveurs RRP de registre public. Le client registraire et le serveur RRP de registre public sont tous deux authentifiés lorsque ils établissent une connexion SSL. De plus, un registraire DOIT être authentifié lorsque il établit une connexion RRP via la commande RRP SESSION en fournissant un identifiant d’utilisateur registraire et un mot de passe connu seulement du registraire et du système. Les registraires peuvent changer leur mot de passe de session à tout moment en utilisant la commande RRP SESSION.

Le protocole SSL n’est pas un protocole de l’IETF en cours de normalisation. Le protocole de sécurité de la couche transport (TLS, Transport Layer Security) spécifié dans la [RFC2246], est un protocole en cours de normalisation qui fournit les dispositifs de compatibilité avec SSL v3.0.

2.2	Sécurité des données du système
Le système mémorise les informations sur les noms de domaines enregistrés et leurs serveurs de noms. Seul le registraire actuel d’un nom de domaine enregistré est autorisé à l’interroger, à mettre à jour ses serveurs de noms, et à l’annuler ou le renouveler. Tout registraire peut demander le transfert d’un nom de domaine et de ses serveurs de noms associés d’un autre registraire au registraire demandeur. Seul le registraire parrain actuel peut recevoir et approuver ou rejeter explicitement une demande de transfert de domaine.

Seul le registraire d’un serveur de noms peut l’interroger, le mettre à jour, et le supprimer. En général, les serveurs de noms doivent être enregistrés chez le registraire actuel du nom de domaine parent du serveur de noms, bien qu’une mise en œuvre PUISSE permettre l’utilisation de serveurs de noms enregistrés dans d’autres TLD sans spécifier les adresses IP ou sans demander l’enregistrement du domaine parent. L’utilisation des serveurs de noms de ccTLD pour un nom de domaine gTLD en est un exemple.

Les noms de serveurs sont implicitement transférés par le système lorsque leur nom de domaine parent est transféré. De plus, un serveur de noms ne peut pas être supprimé si il héberge des noms de domaines.

3.	Modèle de connexion

L’IANA a alloué l’accès TCP 648 pour l’utilisation de RRP. Toutes les mises en œuvre de RRP DOIVENT fournir les services RRP sur SSL sur l’accès TCP 648. Un serveur RRP DOIT retourner une bannière du format suivant pour confirmer qu’une connexion a été établie :

<nom du registre> version de serveur RRP <version><crlf>
<date et heure de construction du serveur><crlf>

Chaque ligne se termine par les caractères retour chariot (CR) et saut à la ligne (LF). La chaîne date et heure de construction du serveur comporte les jour, mois, heure (spécifiée en heures, minutes, et secondes) la zone horaire locale, et les quatre chiffres de l’année. Un point (".") en début d’une ligne par ailleurs vide marque la fin du texte de la bannière

Exemple
Un registraire réussit à établir une connexion avec NSI Registry sur l’accès TCP 648 :
S:NSI RRP Server version 1.1.0
S:Mon Oct 25 20:20:34 EDT 1999
S:.

4.	Description du protocole

Une session RRP normale va passer par un certain nombre d’états pendant sa durée de vie. La Figure 1 illustre les états possibles d’un serveur RRP.

Au départ, le serveur attend la connexion et l’authentification d’un client (PRE). Toutes les connexions de client DOIVENT être authentifiées.

                                      |
                                      |
                                      v
                             +-----------------+   Temporisation
                             |  Attente de l’  |-------------------+
   Authentification réussie  |authentification |                   |
                   +---------|     du client   | Échec d’          |
                   |         |      (PRE)      |--+authentification|
                   |         +-----------------+  |                |
                   |                              |                |
                   V                              V                |
             +-----------+     Réussite     +--------------------+ |
             |Attente de |<-----------------|  Attente de réessai| |
             |  commande |----------+       |d’authentification  | |
             |   (WFC)   |Temporisa-|       |       (WFR)        | |
             +-----------+  tion    |       +--------------------+ |
                 |   ^              |           |         |        |
                 |   |              | Temporisa-|         | Échec  |
         Demande V   | Réponse      |   tion    |         |        |
             +-----------+          |           V         V        V
             | Exécutiion|          |          +--------------------+
             |de commande|          +--------->|    Déconnexion     |
             |   (EXE)   |-------------------->|       (DIS)        |
             +-----------+          QUIT       +--------------------+

Figure 1 : Automate à états finis de serveur RRP

Si l’authentification échoue, le serveur donne au client une autre chance de s’identifier (WFR). Si l’authentification échoue encore, le serveur se déconnecte (DIS). Autrement, le serveur attend une demande du client (WFC). À réception d’une demande, le serveur l’exécute et répond au client par le résultat (EXE). Le serveur attend encore une autre demande de client (WFC). Si le client envoie une commande QUIT, le serveur termine la session et se déconnecte (DIS). Pour garder son état synchrone  avec celui du serveur, le client DEVRAIT attendre une réponse du serveur avant d’envoyer une autre demande sur la même connexion. Le tableau suivant résume ces états :
PRE	attente de la connexion et de l’authentification du client
WFR	attente d’un réessai d’authentification
WFC	attente d’une commande d’un client authentifié
EXE	exécution d’une commande
DIS	déconnecté

Les états WFR et WFC PEUVENT être soumis à une temporisation. Une mise en œuvre DEVRAIT définir des périodes de temporisation d’inactivité pour ces états sur la base de facteurs spécifiques du système, incluant (mais sans s’y limiter) la disponibilité des ressources et les risques pour la sécurité. En l’absence d’autres facteurs, une période de temporisation par défaut de 10 minutes DEVRAIT être utilisée. Le serveur PEUT se déconnecter si le serveur est dans un de ces états et si aucun message n’est reçu du client durant la période de temporisation.

4.1	Format de demande
Une demande RRP consiste nominalement en un nom de commande, un bloc d’entité, des options de commande, et un délimiteur de fin de commande. Les options de commande et les blocs d’entité définissent collectivement les paramètres de commande et leur spécification est indépendante de l’ordre ; les exemples fournis dans ce document spécifient les blocs d’entité avant les options de commande.

NomDeCommande [BlocD’Entité] [OptionsDeCommande] FinDeCommande

Un nom de commande spécifie le type d’une demande RRP. Une commande est un mot ou une abréviation terminée par une séquence retour chariot saut à la ligne (CRLF).

NomDeCommande<CRLF>

Un bloc d’entité spécifie les données dans une demande RRP. Il consiste en une paire d’attributs nom-valeur qui spécifient l’entité et tous les attributs de l’entité. Chaque paire d’attributs nom-valeur commence par le nom de l’attribut, suivi par deux-points, la valeur de l’attribut, et se termine par une séquence retour chariot saut à la ligne. Les blocs d’entité sont facultatifs pour certaines demandes.

nomd’Entité:valeurD’entité<CRLF>
nomD’Attribut:valeurD’Attribut<CRLF>

Les options de commande spécifient les paramètres de commande pour une demande RRP. Une option de commande commence par un trait d’union, suivi par le nom de l’option, deux points, la valeur de l’option, et se termine par une séquence retour chariot saut à la ligne.

-commandeOptionNom:commandeOptionValeur<CRLF>

Un délimiteur FinDeCommande spécifie la fin d’une demande RRP. Il consiste en un point (".") en début de ligne suivi par une séquence retour chariot saut à la ligne.

.<CRLF>

4.2	Format de réponse
Une réponse RRP commence par un code de réponse de trois chiffres, suivi par une espace, un texte de description de la réponse en ASCII, une séquence retour chariot saut à la ligne, et zéro, une ou plusieurs lignes de paires d’attribut nom-valeur. Une réponse RRP se terminé par un point en début de ligne suivi par une séquence retour chariot saut à la ligne.

CodeDeRéponse<espace>descriptionDeRéponse<CRLF>
[nomD’Attribut:valeurD’Attribut<CRLF>]
.<CRLF>

4.3	Commandes du protocole
Les mises en œuvre des commandes RRP DOIVENT réagir à la réussite ou à l’échec d’une opération par "tout ou rien". L’échec de l’exécution d’une commande DOIT laisser le système dans le même état qu’il était avant que la commande soit tentée et ait échoué.

Toutes les commandes RRP comportent des caractéristiques pour assurer l’idempotence. Les caractéristiques de commandes qui ne sont pas idempotentes sont pleinement expliquées en tant que de besoin au titre de la description de commande appropriée.

4.3.1	ADD
Cette commande permet à un registraire d’enregistrer un nom de domaine ou un serveur de noms dans le système.

4.3.1.1	Enregistrement d’un nom de domaine
La demande d’enregistrer un nom de domaine DOIT contenir les données suivantes :
-	le paramètre "NomD’Entité" réglé à la valeur "Domaine"  ;
-	le nom de domaine pleinement qualifié de second niveau dans le paramètre "NomDeDomaine".

La demande d’enregistrement d’un nom de domaine PEUT contenir un ou plusieurs, avec un maximum de 13, noms de serveurs pleinement qualifiés hébergeant le nom de domaine dans plusieurs instances du paramètre "ServeurDeNoms". Les serveurs de noms DOIVENT avoir déjà été enregistrés dans le registre. Les mises en œuvre PEUVENT permettre la spécification de serveurs de noms associés à des domaines enregistrés dans d’autres TLD. Par exemple, une mise en œuvre PEUT permettre l’utilisation de serveurs de noms de ccTLD pour l’enregistrement d’un nom de domaine gTLD.

La demande d’enregistrement d’un nom de domaine PEUT contenir la période initiale d’enregistrement en années pour le domaine qui est enregistré dans une seule instance du paramètre "Période". Le système DOIT fournir une période initiale d’enregistrement par défaut en années si le paramètre "Période" n’est pas fourni. Les valeurs d’années acceptables pour le paramètre "Période" sont spécifiques de la mise en œuvre.

Le système va enregistrer le nom de domaine chez le registraire pour la période spécifiée par le registraire. Si le registraire ne spécifie pas une période d’enregistrement, une valeur par défaut spécifique du système DOIT être utilisée pour la période initiale d’enregistrement. Si le nom de domaine est enregistré avec succès, le système DOIT retourner la date d’expiration de l’enregistrement dans l’attribut "date d’expiration d’enregistrement" dans la réponse.

Utilisateur autorisé : tous les registraires PEUVENT utiliser la commande ADD pour enregistrer les noms de domaine.

Exemples
Un registraire enregistre un nom de domaine sans spécifier de serveur de noms :
C:add<CRLF>
C:NomD’Entité:Domaine<CRLF>
C:NomDeDomaine:exemple.com<CRLF>
C:-Period:10<CRLF>
C:.<CRLF>
S:200 Commande bien exécutée<CRLF>
S:Date d’expiration de l’enregistrement:2009-09-22 10:27:00.0<CRLF>
S:status:ACTIVE<CRLF>
S:.<CRLF>

Un registraire enregistre un nom de domaine en utilisant des serveurs de noms enregistrés précédemment :
C:add<CRLF>
C:NomD’Entité:Domaine<CRLF>
C:NomDeDomaine:exemple2.com<CRLF>
C:-Period:10<CRLF>
C:NomDeServeur:ns1.exemple.com<CRLF>
C:NomDeServeur:ns2.exemple.com<CRLF>
C:.<CRLF>
S:200 Commande bien exécutée<CRLF>
S:Date d’expiration de l’enregistrement:2000-09-22 10:27:00.0<CRLF>
S:status:ACTIVE<CRLF>
S:.<CRLF>

4.3.1.2	Enregistrement d’un serveur de noms
La demande d’enregistrer un serveur de noms DOIT contenir les données suivantes  :
-	le paramètre "NomD’Entité" réglé à la valeur de "NomDeServeur"  ;
-	le nom de serveur pleinement qualifié du serveur de noms dans le paramètre "NomDeServeur".

Si le serveur de noms enregistré est l’enfant d’un nom de domaine enregistré, la demande d’enregistrement de serveur de noms DOIT comporter une ou plusieurs, avec un maximum de 13, adresses IP de serveur de noms dans plusieurs instances du paramètre "AdresseIP". Les serveurs de noms associés à des domaines enregistrés dans d’autres TLD NE DEVRAIENT PAS être spécifiés avec des adresses IP pour réduire la possibilité de duplication des enregistrements NS du DNS pour les serveurs de noms dans plusieurs fichiers de zone.

Le registraire DOIT enregistrer le serveur de noms dans le système avant de l’utiliser pour héberger des noms de domaines. De plus, le serveur de noms DOIT être enregistré par le même registraire que celui qui est le registraire actuel de son nom de domaine parent. Le système PEUT permettre à tout registraire d’utiliser le serveur de noms pour héberger des noms de domaines.

Utilisateur autorisé : tous les registraires PEUVENT utiliser la commande ADD pour enregistrer les serveurs de noms.

Exemples
Un registraire enregistre un nouveau serveur de noms dans un nom de domaine existant :
C:add<CRLF>
C:NomD’Entité:NomDeServeur<CRLF>
C:NomDeServeur:ns1.exemple.com<CRLF>
C:IPAddress:198.41.1.11<CRLF>
C:.<CRLF>
S:200 Commande bien exécutée<CRLF>
S:.<CRLF>

4.3.2	CHECK
Cette commande permet à un registraire de déterminer si un nom de domaine ou un serveur de noms a été enregistré dans le système.

4.3.2.1	Vérification de nom de domaine
La demande pour déterminer si un nom de domaine est enregistré DOIT contenir les données suivantes :
-	le paramètre "NomD’Entité" réglé à la valeur "Domaine"  ;
-	le nom de domaine pleinement qualifié de second niveau dans le paramètre "NomDeDomaine".

Le système DOIT fournir une réponse positive ou négative pour documenter la disponibilité du nom de domaine au moment où la commande est exécutée.

Utilisateur autorisé :	tous les registraires PEUVENT utiliser la commande CHECK pour déterminer si un nom de domaine a été enregistré ou non.

Exemples
Un registraire vérifie la disponibilité d’un nom de domaine dans le système :
C:check<CRLF>
C:NomD’Entité:Domaine<CRLF>
C:NomDeDomaine:exemple.com<CRLF>
C:.<CRLF>
S:211 Nom de domaine non disponible<CRLF>
S:.<CRLF>

4.3.2.2	Vérification de nom de serveur
La demande pour déterminer si un serveur de noms est enregistré DOIT contenir les données suivantes :
-	le paramètre "NomD’Entité" réglé à la valeur "NomDeServeur"  ;
-	le nom de serveur pleinement qualifié dans le paramètre "NomDeServeur".

Le système DOIT fournir une réponse positive ou négative pour documenter la disponibilité du serveur de noms au moment où la commande est exécutée. Si le serveur de noms a été enregistré, le système DOIT retourner la ou les adresses IP du serveur de noms.

Utilisateur autorisé :	tous les registraires PEUVENT utiliser la commande CHECK pour déterminer si un serveur de noms a été enregistré ou non.

Exemples
Un registraire vérifie la disponibilité d’un nom de serveur dans le système :
C:check<CRLF>
C:NomD’Entité:ServeurDeNom<CRLF>
C:ServeurDeNom:ns1.exemple.com<CRLF>
C:.<CRLF>
S:213 Serveur de noms non disponible<CRLF>
S:ipAddress:192.10.10.10<CRLF>
S:.<CRLF>

4.3.3	DEL
Cette commande permet à un registraire de supprimer (annuler l’enregistrement) d’un nom de domaine ou de supprimer un serveur de noms.

4.3.3.1	Suppression d’un nom de domaine
La demande d’annulation de l’enregistrement d’un nom de domaine DOIT contenir les données suivantes :
-	le paramètre "NomD’Entité" réglé à la valeur "Domaine"  ;
-	Le nom de domaine pleinement qualifié de second niveau dans le paramètre "NomDeDomaine".

Une demande de suppression d’un nom de domaine DEVRAIT causer la suppression de tous les serveurs de noms qui sont les enfants du nom de domaine supprimé. Les serveurs de noms DEVRAIENT être supprimés si ils ne sont pas des hébergeurs actifs d’autres domaines. Un domaine NE DOIT PAS être supprimé si il a des enfants serveurs de noms qui hébergent d’autres domaines.

Utilisateur autorisé :	le registraire actuel d’un nom de domaine PEUT utiliser la commande DEL pour supprimer un nom de domaine du système.

Exemples
Un registraire supprime un nom de domaine, supprimant implicitement tous les serveurs de noms enregistrés dans le domaine :
C:del<CRLF>
C:NomD’Entité:Domaine<CRLF>
C:NomDeDomaine:exemple.com<CRLF>
C:.<CRLF>
S:200 Commande bien exécutée<CRLF>
S:.<CRLF>

4.3.3.2	Suppression d’un serveur de noms
La demande de supprimer un serveur de noms DOIT contenir les données suivantes :
-	le paramètre "NomD’Entité" réglé à la valeur "NomDeServeur"  ;
-	nom pleinement qualifié du serveur de noms dans le paramètre "NomDeServeur".

Un serveur de noms NE DOIT PAS être supprimé si il héberge des domaines. Supprimer de tels domaines ou serveurs de noms est interdit parce que leur suppression résulterait à transformer les domaines hébergés en orphelins.

Utilisateur autorisé :	le registraire actuel d’un serveur de noms PEUT utiliser la commande DEL pour supprimer un serveur de noms du système.

Exemples
Un registraire supprime un serveur de noms qui n’héberge pas de domaines :
C:del<CRLF>
C:NomD’Entité:NomDeServeur<CRLF>
C:NomDeServeur:ns1.registraireA.com<CRLF>
C:.<CRLF>
S:200 Commande bien exécutée<CRLF>
S:.<CRLF>

Un registraire essaye de supprimer un serveur de noms qui héberge des domaines :
C:del<CRLF>
C:NomD’Entité:NomDeServeur<CRLF>
C:NomDeServeur:ns1.registraireA.com<CRLF>
C:.<CRLF>
S:532 Nom de domaines liés au serveur de noms<CRLF>
S:.<CRLF>

4.3.4	DESCRIBE
Cette commande permet à un registraire d’obtenir des informations générales sur une mise en œuvre de RRP. La commande PEUT contenir les paramètres suivants :
-	le paramètre "Target" réglé à la valeur "Protocole".
La mise en œuvre DOIT retourner le numéro de version du protocole, que la demande contienne ou non le paramètre "Target".

Utilisateur autorisé : tous les registraires PEUVENT utiliser la commande DESCRIBE.

Exemples
Un registraire obtient une information générale sur une mise en œuvre RRP :
C:describe<CRLF>
C:-Target:Protocol<CRLF>
C:.<CRLF>
S:200 Commande bien exécutée<CRLF>
S:Protocol:RRP 1.1.0<CRLF>
S:.<CRLF>

4.3.5 MOD
Cette commande permet à un registraire de mettre à jour un nom de domaine ou serveur de noms enregistré. La commande permet les opérations suivantes sur une valeur d’attribut pour un attribut aussi bien à valeur unique qu’à valeurs multiples :
-	Ajouter une valeur d’attribut. La valeur à ajouter DOIT être unique parmi les valeurs de l’attribut. Pour un attribut à une seule valeur, il remplace la valeur courante.
-	Retirer une valeur d’attribut. La valeur à retirer DOIT exister. De plus, une valeur d’attribut ne peut pas être retirée si elle est la seule valeur d’un attribut exigé.

Les valeurs d’attribut à retirer sont identifiées en les étiquetant avec un suffixe "=".

4.3.5.1	Modification de domaine
La demande de modifier un nom de domaine enregistré DOIT contenir les données suivantes :
-	Le paramètre "NomD’Entité" réglé à la valeur "Domaine".
-	Le nom de domaine pleinement qualifié de second niveau dans le paramètre "NomDeDomaine".

Le registraire peut effectuer les opérations de mise à jour suivantes sur le nom de domaine :
-	Mettre à jour les serveurs de noms du nom de domaine en réglant une ou plusieurs instances du paramètre "NomDeServeur".
-	Mettre à jour l’état du nom de domaine en réglant une ou plusieurs instances du paramètre "Status". Les valeurs valides pour le paramètre "Status" sont définies à la Section 6.

Utilisateur autorisé :	le registraire actuel d’un nom de domaine PEUT utiliser la commande MOD pour modifier les attributs d’un nom de domaine.

Exemples
Un registraire retire un serveur de noms (ns1) d’un domaine et ajoute un nouveau serveur de noms (ns3) au même domaine :
C:mod<CRLF>
C:NomD’Entité:Domaine<CRLF>
C:NomDeDomaine:exemple.com<CRLF>
C:NomDeServeur:ns3.registraireA.com<CRLF>
C:NomDeServeur:ns1.registraireA.com=<CRLF>
C:.<CRLF>
S:200 Commande bien exécutée<CRLF>
S:.<CRLF>

4.3.5.2	Modification d’un serveur de noms
La demande de mise à jour d’un serveur de noms DOIT contenir les données suivantes :
-	Le paramètre "NomD’Entité" réglé à la valeur "NomDeServeur".
-	Le nom de serveur pleinement qualifié du serveur de noms dans le paramètre "NomDeServeur".

Le registraire peut effectuer les opérations de mise à jour suivantes sur le serveur de noms :
-	Mettre à jour l’attribut "NomDeServeur" du serveur de noms. Cela permet au registraire de changer le nom d’un serveur de noms tout en préservant toutes les associations existantes.
-	Mettre à jour les adresses IP du serveur de noms en réglant une ou plusieurs instances du paramètre "AdresseIP".

Utilisateur autorisé :	le registraire actuel d’un serveur de noms PEUT utiliser la commande MOD pour modifier les attributs d’un nom de domaine.

Exemples
Un registraire change le nom et l’adresse IP d’un serveur de noms :
C:mod<CRLF>
C:NomD’Entité:NomDeServeur<CRLF>
C:NomDeServeur:ns1.registraireA.com<CRLF>
C:NouveauNomServeur:ns2.registraireA.com<CRLF>
C:IPAddress:198.42.1.11<CRLF>
C:IPAddress:198.41.1.11=<CRLF>
C:.<CRLF>
S:200 Commande bien exécutée<CRLF>
S:.<CRLF>

4.3.6 QUIT
Cette commande permet à un registraire de clore une connexion RRP. Une réponse DOIT être envoyée avant de clore la connexion.

Utilisateur autorisé : tous les registraires PEUVENT utiliser la commande QUIT command.

Exemples
Un registraire termine une session RRP et clôt une connexion existante :
C:quit<CRLF>
C:.<CRLF>
S:220 Commande bien exécutée. Le serveur clôt la connexion<CRLF>
S:.<CRLF>

4.3.7	RENEW
Cette commande permet à un registraire de renouveler un nom de domaine dans  le système. La demande de renouvellement d’un nom de domaine DOIT contenir les données suivantes :
-	le paramètre "NomD’Entité" réglé à la valeur "Domaine"  ;
-	le nom de domaine pleinement qualifié de second niveau dans le paramètre "NomDeDomaine".

La demande de renouvellement d’un nom de domaine PEUT contenir la période de renouvellement en années pour le domaine renouvelé dans une seule instance d’un paramètre "Période" et une seule instance d’un paramètre "AnnéeD’ExpirationActuelle". Ces paramètres DOIVENT apparaître ensemble si l’un ou l’autre est spécifié, bien que l’ordre dans lequel ils apparaissent ne soit pas signifiant. Le paramètre "Période" identifie le nombre d’années à ajouter à l’enregistrement. Le paramètre "AnnéeD’ExpirationActuelle" identifie l’année d’expiration actuelle, et il est exigé qu’on s’assure que des tentatives répétées de réessai de cette commande ne résultent pas en plusieurs renouvellements réussis. Le système DOIT fournir un nombre d’années de renouvellement par défaut si les paramètres "Période" et "AnnéeD’ExpirationActuelle" ne sont pas fournis. L’utilisation répétée de cette commande sans les paramètres "Période" et "AnnéeD’ExpirationActuelle" peut résulter en des renouvellements réussis répétés car l’idempotence n’est pas fournie lorsque ces paramètres ne sont pas utilisés. Les valeurs d’années acceptables pour le paramètre "Période" sont spécifiques de la mise en œuvre sous réserve des restrictions de la syntaxe.

Le système renouvelle le nom de domaine pour une période spécifiée par le registraire. Si le renouvellement du nom de domaine se termine avec succès, le système DOIT retourner la nouvelle date d’expiration de l’enregistrement dans l’attribut "DateExpirationEnregistrement" dans la réponse.

Utilisateur autorisé : le registraire actuel d’un nom de domaine PEUT utiliser la commande RENEW.

Exemples
Un registraire renouvelle un nom de domaine en utilisant une période de renouvellement spécifiée :
C:renew<CRLF>
C:NomD’Entité:Domaine<CRLF>
C:NomDeDomaine:exemple.com<CRLF>
C:-Période:9<CRLF>
C:-AnnéeD’ExpirationActuelle:2001<CRLF>
C:.<CRLF>
S:200 Commande bien exécutée<CRLF>
S:Date d’expiration de l’enregistrement:2010-09-22 10:27:00.0<CRLF>
S:.<CRLF>

4.3.8	SESSION
Cette commande permet à un registraire d’établir une session RRP. Un registraire peut aussi utiliser cette commande pour changer son mot de passe. La demande d’établir une connexion RRP DOIT contenir les paramètres de commande suivants :
-	le paramètre "Id" réglé à l’identifiant d’utilisateur de système du registraire  ;
-	le paramètre "MotDePasse" réglé au mot de passe système actuel du registraire.

La demande d’établissement d’une session RRP PEUT contenir un nouveau mot de passe pour le registraire dans une seule instance du paramètre "NouveauMotDePasse".

Le registraire DOIT envoyer cette commande au système avant toute autre commande. Si la commande échoue à cause d’informations invalides (comme un ID ou mot de passe de registraire invalide) le registraire peut envoyer à nouveau cette demande avec les informations corrigées. Si la commande échoue une seconde fois, le système DEVRAIT clore la connexion.

Utilisateur autorisé : tous les registraires PEUVENT utiliser la commande SESSION.

Exemples
Un registraire établit une session RRP :
C:session<CRLF>
C:-Id:registraireA<CRLF>
C:-Password:i-am-registraireA<CRLF>
C:.<CRLF>
S:200 Commande bien exécutée<CRLF>
S:.<CRLF>

4.3.9	STATUS
Cette commande permet au registraire de déterminer l’état actuel d’un nom de domaine ou serveur de noms.

4.3.9.1	État de domaine
La demande pour une interrogation de nom de domaine DOIT contenir les données suivantes :
-	le paramètre "NomD’Entité" réglé à la valeur "Domaine"  ;
-	le nom de domaine pleinement qualifié de second niveau dans le paramètre "NomDeDomaine".

La réponse du système PEUT contenir les données suivantes  :
-	noms de serveur pleinement qualifiés de serveurs de noms hébergeant le nom de domaine dans plusieurs instances de l’attribut "serveurdenom",
-	date d’expiration d’enregistrement dans l’attribut "Date d’expiration de l’enregistrement",
-	ID du registraire actuel du nom de domaine dans l’attribut "registraire",
-	date à laquelle le nom de domaine a été transféré par le registraire actuel dans l’attribut "date de transfert de registraire",
-	état actuel du nom de domaine dans plusieurs instances de l’attribut "status",
-	date à laquelle le nom de domaine a été enregistré à l’origine dans l’attribut "date de création",
-	ID du registraire qui a enregistré à l’origine le nom de domaine dans l’attribut "créé par",
-	date à laquelle le nom de domaine a été mis à jour pour la dernière fois dans l’attribut "date de mise à jour",
-	ID de l’entité (registraire ou registre) qui a mis à jour pour la dernière fois le nom de domaine dans l’attribut "mis à jour par",

Utilisateur autorisé : le registraire courant d’un nom de domaine PEUT utiliser la commande STATUS pour voir les attributs actuels du nom de domaine.

Exemples
Le registraire courant d’un nom de domaine interroge le nom de domaine :
C:status<CRLF>
C:NomD’Entité:Domaine<CRLF>
C:NomDeDomaine:exemple.com<CRLF>
C:.<CRLF>
S:200 Commande bien exécutée<CRLF>
S:nameserver:ns2.registraireA.com<CRLF>
S:nameserver:ns3.registraireA.com<CRLF>
S:Date d’expiration de l’enregistrement:2010-09-22 10:27:00.0<CRLF>
S:registraire:registraireA<CRLF>
S:date de transfert de registraire  :1999-09-22 10:27:00.0<CRLF>
S:status:ACTIVE<CRLF>
S:date de création:1998-09-22 10:27:00.0<CRLF>
S:créé par:registraireA<CRLF>
S:date de mise à jour:2002-09-22 10:27:00.0<CRLF>
S:mis à jour par:registraireA<CRLF>
S:.<CRLF>

Un registraire interroge un nom de domaine actuellement enregistré par un autre registraire :
C:status<CRLF>
C:NomD’Entité:Domaine<CRLF>
C:NomDeDomaine:exemple.com<CRLF>
C:.<CRLF>
S:531 Échec d’autorisation<CRLF>
S:.<CRLF>

4.3.9.2	État du serveur de noms
La demande d’interrogation d’un serveur de noms DOIT contenir les données suivantes :
-	le paramètre "NomD’Entité" réglé à la valeur "NomDeServeur",
-	le nom pleinement qualifié du serveur de noms dans le paramètre "NomDeServeur".

La réponse du système PEUT contenir les données suivantes :
-	le nom pleinement qualifié du serveur de noms dans l’attribut "serveurdenom",
-	les adresses IP du serveur de noms dans plusieurs instances de l’attribut "ipaddress",
-	ID du registraire actuel du serveur de noms dans l’attribut "registraire",
-	date à laquelle le serveur de noms a été transféré par le registraire actuel dans l’attribut "date de transfert du registraire",
-	date à laquelle le serveur de noms a été enregistré dans l’attribut "date de création",
-	ID de l’entité qui a enregistré le serveur de noms dans l’attribut "créé par",
-	date à laquelle le serveur de noms a été mis à jour pour la dernière fois dans l’attribut "date de mise à jour",
-	ID de l’entité qui a mis à jour le serveur de noms pour la dernière fois dans l’attribut "mis à jour par".

Utilisateur autorisé :	le registraire courant d’un serveur de noms PEUT utiliser la commande STATUS pour voir les attributs courants du nom de domaine.

Exemples
Le registraire actuel d’un serveur de noms interroge le serveur de noms :
C:status<CRLF>
C:NomD’Entité:NomDeServeur<CRLF>
C:NomDeServeur:ns1.registraireA.com<CRLF>
C:.<CRLF>
S:200 Commande bien exécutée<CRLF>
S:ipaddress:198.42.1.11<CRLF>
S:registraire:registraireA<CRLF>
S:date de transfert du registraire:1999-09-22 10:27:00.0<CRLF>
S:DateDeCréation:1998-09-22 10:27:00.0<CRLF>
S:Créé Par:registraireA<CRLF>
S:DateDeMiseAJour:2002-09-22 10:27:00.0<CRLF>
S:MisAJourPar:registraireA<CRLF>
S:.<CRLF>

Un registraire interroge un serveur de noms qui a été enregistré par un autre registraire :
C:status<CRLF>
C:NomD’Entité:NomDeServeur<CRLF>
C:NomDeServeur:ns1.registraireA.com<CRLF>
C:.<CRLF>
S:531 Échec d’autorisation<CRLF>
S:.<CRLF>

4.3.10	TRANSFER
Cette commande permet à un registraire de demander le transfert du parrainage d’un nom de domaine provenant d’un second registraire et d’approuver ou rejeter les demandes de transfert initiées par d’autres registraires. La demande de transfert d’un nom de domaine DOIT contenir les données suivantes :
-	le paramètre "NomD’Entité" réglé à la valeur "Domaine",
-	le nom de domaine pleinement qualifié de second niveau dans le paramètre "NomDeDomaine".

L’identité du registraire demandeur est déduite de la session actuellement active. L’identité du registraire parrain actuel (le registraire qui doit approuver ou rejeter la demande de transfert) est connue par le registre et n’a pas besoin d’être connue par le registraire demandeur avant qu’il produise la demande de transfert.

Le système DOIT notifier au registraire qui va le perdre quand une demande de transfert de domaine a été reçue en utilisant un mécanisme de transport hors bande tel qu’un message électronique et/ou un rapport de transaction. Le registraire perdant DEVRAIT alors approuver ou rejeter explicitement le transfert. Une demande d’approuver ou rejeter une demande de transfert DOIT contenir une seule instance du paramètre "Approuve" avec une valeur de "Oui" pour approuver le transfert ou une valeur de "Non" pour rejeter le transfert. Une mise en œuvre de serveur PEUT fournir une approbation par défaut ou une action de rejet sera prise si le registraire perdant n’approuve pas ou ne rejette pas explicitement la demande de transfert dans un délai fixé. Les critères utilisés par les registraires pour approuver ou rejeter les transferts demandés sont normalement fondés sur les politiques commerciales qui sortent du domaine d’application du présent document.

L’approbation d’un transfert par le registraire parrain actuel résulte en un changement du parrainage au profit du registraire demandeur d’origine. Les tentatives d’approbation par tout autre registraire DOIVENT résulter en un échec explicite de la tentative d’approbation. Le rejet du transfert par le registraire parrain actuel résulte en la fin de la demande de transfert sans changement du parrainage. Les tentatives de rejet par tout autre registraire DOIVENT résulter en un échec explicite de la tentative de rejet.

Les serveurs de noms DOIVENT être implicitement transférés lorsque leur nom de domaine parent est transféré.

Utilisateur autorisé : 	tous les registraires PEUVENT utiliser la commande TRANSFER pour demander le transfert de l’autorité du service d’enregistrement au registraire demandeur. Seul le registraire parrain actuel d’un nom de domaine peut explicitement approuver ou rejeter un transfert demandé. Le registre PEUT implicitement approuver ou rejeter les transferts demandés après un délai fixé.

Exemples
Un registraire demande le transfert d’un nom de domaine d’un autre registraire :
C:transfer<CRLF>
C:NomD’Entité:Domaine<CRLF>
C:NomDeDomaine:exemple.com<CRLF>
C:.<CRLF>
S:200 Commande bien exécutée<CRLF>
S:.<CRLF>

Le registraire d’origine approuve la demande de transfert  :
C:transfer<CRLF>
C:-Approuve:Oui<CRLF>
C:NomD’Entité:Domaine<CRLF>
C:NomDeDomaine:exemple.com<CRLF>
C:.<CRLF>
S:200 Commande bien exécutée<CRLF>
S:.<CRLF>

5.	Codes de réponse

Les commandes RRP peuvent retourner divers codes de réponse pour signifier l’achèvement normal ou des conditions d’erreur. La présente section décrit tous les codes de réponse définis par RRP.

5.1	Liste des codes de réponse
200 Commande bien exécutée
C’est la réponse normale pour l’achèvement réussi de la plupart des commandes RRP.

210 Nom de domaine disponible
C’est la réponse normale pour l’achèvement réussi d’une commande RRP CHECK pour un nom de domaine qui n’est pas enregistré actuellement.

211 Nom de domaine non disponible
C’est la réponse normale pour l’achèvement réussi d’une commande RRP CHECK pour un nom de domaine qui est actuellement enregistré.

212 Serveur de noms disponible
C’est la réponse normale pour l’achèvement réussi d’une commande RRP CHECK pour un serveur de noms qui n’est pas enregistré actuellement.

213 Serveur de noms non disponible
C’est la réponse normale pour l’achèvement réussi d’une commande RRP CHECK pour un serveur de noms qui est actuellement enregistré.

220 Commande bien exécutée. Le serveur clôt la connexion
C’est la réponse normale pour l’achèvement réussi d’une commande RRP QUIT. Elle peut  aussi être retournée par d’autres commandes RRP si une situation provisoire est notée qui exige de clore la connexion après l’achèvement réussi de la commande RRP.

420 Échec de la commande due à une erreur du serveur. Le serveur clôt la connexion
Une erreur provisoire du serveur a causé l’échec de la commande RRP et la fin de la session. Une nouvelle session doit être établie avant que la poursuite du traitement puisse être tentée.

421 Échec de la commande due à une erreur du serveur. Le client devrait réessayer
Une erreur provisoire du serveur a causé l’échec de la commande RRP. Un nouvel essai peut produire un bon résultat.

500 Nom de commande invalide
Un nom de commande RRP spécifié par le client n’a pas été reconnu comme un nom de commande valide RRP.

501 Option de commande invalide
Un paramètre de commande RRP spécifié par le client n’a pas été reconnu comme un paramètre valide de commande RRP.

502 Valeur d’entité invalide
La "valeur" d’une paire nom-valeur d’une entité est invalide. Les blocs de commande qui exigent un paramètre "NomD’Entité" exigent aussi une valeur qui spécifie le nom de l’entité, et la valeur fournie est invalide.

503 Nom d’attribut invalide
Un paramètre de commande RRP spécifié par le client n’a pas été reconnu comme un paramètre valide de commande RRP.

504 Attribut exigé manquant
Un paramètre exigé pour exécuter la commande RRP n’a pas été fourni par le client. La commande devrait être réessayée avec tous les paramètres requis spécifiés.

505 Syntaxe invalide de la valeur d’attribut
Une valeur d’un paramètre est syntaxiquement incorrecte. Par exemple, une valeur de chiffre d’année tel que "5" peut être requise mais le client a fourni une chaîne de caractères de "cinq".

506 Valeur d’option invalide
Une valeur spécifiée par le client pour un paramètre de commande RRP est hors limites ou par ailleurs en dehors des limites acceptables du système.

507 Format de commande invalide
La commande spécifiée ne ressemble pas à une commande RRP bien formée. La commande devrait être réessayée en utilisant les structure et syntaxe de commande appropriées.

508 Entité exigée manquante
Une entité exigée pour l’achèvement de la commande n’a pas été fournie par le client. Par exemple, la commande CHECK exige la spécification d’une entité "Domaine" ou "ServeurDeNom".

509 Option de commande manquante
Un paramètre de commande qui n’est pas réellement facultatif (comme l’identifiant de registraire dans une commande SESSION) n’a pas été fourni par le client. La commande devrait être réessayée avec tous les paramètres nécessaires.

520 Le serveur clôt la connexion. Le client devrait essayer d’ouvrir une nouvelle connexion ; <pourquoi>
Un événement de fin de temporisation a été détecté, et la session du client a été close. Le système DEVRAIT définir des périodes de temporisation pour le début d’une commande de client, pour l’achèvement d’une commande de client, et pour la durée d’ouverture d’une session. La raison de la temporisation DOIT être fournie à la fin de la chaîne de code de réponse.

521 Trop de sessions ouvertes. Le serveur clôt la connexion
Une limite, définie par le système, sur le nombre de connexions ouvertes, a été dépassée, et il est impossible d’établir une nouvelle session pour le moment. Il sera possible d’établir une session en attendant quelques instants ou en closant des sessions inutilisées existantes.

530 Échec d’authentification
L’identifiant ou le mot de passe de registraire fourni par le client n’a pas été reconnu par le système. Un nouvel essai avec des valeurs valides peut produire un résultat fructueux. Des échecs répétés d’autorisation PEUVENT résulter en la terminaison de la connexion TCP.

531 Échec d’autorisation
Les registraires ne peuvent pas voir ou altérer les données associées au registre ou à un autre registraire. Ce code de réponse est normalement retourné lorsque un registraire tente de voir ou modifier des données qui appartiennent au registre ou à un autre registraire. Une situation typique comporte de faire une commande STATUS pour un domaine enregistré chez un autre registraire.

532 Noms de domaines liés à un serveur de noms
Le serveur de noms héberge des domaines actifs. Cette erreur survient lorsque un registraire essaye de supprimer un serveur qui est le serveur de noms de domaines actifs. Le registre NE DOIT PAS permettre au registraire de supprimer ce serveur. Tous les noms de domaines qui utilisent ce serveur DOIVENT être modifiés pour utiliser un serveur de noms différent avant que le serveur de noms puisse être supprimé.

533 Le nom de domaine a des serveurs de noms actifs
Le nom de domaine a des serveurs de noms actifs. Le registraire essaye de supprimer un nom de domaine qui est un domaine parent d’un serveur de noms actif, c’est-à-dire, un serveur qui héberge des domaines actifs. Tous les serveurs de noms au sein du domaine DOIVENT être retirés du service avant que le domaine puisse être supprimé.

534 Le nom de domaine n’a pas été étiqueté pour le transfert
Le registraire essaye d’approuver ou rejeter un transfert de nom de domaine pour un nom de domaine qui n’est pas en cours de transfert.

535 Adresse IP interdite
L’IANA identifie certaines gammes d’adresses IP qui ne sont pas valides pour une utilisation normale. Le registraire essaye d’utiliser une adresse IP qui est dans une gamme d’adresses IP interdites identifiée par l’IANA.

536 Domaine déjà étiqueté pour le transfert
Le registraire a essayé d’effectuer une commande de transfert pour un nom de domaine qui attend l’approbation d’une demande de transfert antérieure.

540 La valeur d’attribut n’est pas unique
Une valeur d’attribut fournie n’est pas unique. Cela arrive lorsque le registraire ajoute un nom de domaine qui existe déjà dans le registre, un serveur qui existé déjà dans le registre, ou une adresse IP qui est déjà utilisée par un autre serveur dans le registre. Une autre possibilité arrive lorsque on effectue des modifications de domaines et que le registraire ajoute un serveur qui est déjà dans la liste des serveurs pour le nom de domaine ou règle un nom de domaine à un état auquel il est déjà réglé. La commande RRP STATUS PEUT être utilisée pour déterminer l’état actuel d’un nom de domaine avant de tenter de changer l’état. Lorsque on modifie ou qu’on ajoute un serveur de noms, l’adresse IP de ce serveur de noms peut ne pas être unique. Le registre NE DOIT PAS permettre que des adresses IP soient utilisées par plus d’un serveur.

541 Valeur d’attribut invalide
Une valeur de paramètre fournie est invalide. Des exemples de valeurs d’attribut invalides incluent une adresse IP invalide, un nom de domaine invalide, un nom de serveur invalide, ou une période de renouvellement invalide.

542 Vieille valeur invalide pour un attribut
Une valeur actuelle d’un attribut à modifier est invalide. Le registraire essaye de modifier un attribut d’un serveur ou d’un nom de domaine qui n’existe pas dans le registre.

543 L’attribut final ou implicite ne peut pas être mis à jour
Le registraire tente de modifier un attribut qui n’est modifiable que par le registre. Les registraires ne peuvent pas modifier des valeurs d’attribut finales ou implicites.

544 Entité en garde
L’opération tentée a été rejetée parce que l’entité est dans l’état HOLD. Si l’état HOLD a été établi par le registraire, l’état ne peut pas être changé en utilisant la commande MOD et la commande demandée peut être réessayée. Si l’état HOLD a été établi par le registre, le registraire doit contacter le registre pour changer l’état avant que la commande puisse réussir.

545 Référence d’entité non trouvée
Une référence d’entité exigée n’a pas été trouvée. Cela arrive lorsque le registraire essaye d’ajouter un nouveau serveur de noms et que le domaine parent du serveur de noms n’existe pas dans le registre. Cela arrive aussi lorsque l’utilisateur essaye d’ajouter un nouveau serveur de noms à un nom de domaine lorsque le serveur de noms n’existe pas dans le registre.

546 Limite de crédit excédée
La limite de crédit du registraire a été dépassée. C’est une erreur spécifique de la mise en œuvre qui arrive lorsque une opération potentiellement facturable, telle que l’ajout d’un nom de domaine, le renouvellement d’un nom de domaine, ou le transfert d’un nom de domaine, est tenté et que le registraire n’a pas une situation financière suffisante auprès du registre pour achever l’opération.

547 Séquence de commandes invalide
Les commandes RRP sont produites en utilisant une syntaxe bien formée qui exige une entrée des structures de commandes dans une séquence particulière. Ce code de réponse indique qu’une commande mal formée a été reçue et rejetée.

548 Domaine pas prêt pour renouvellement
Une commande RENEW a été tentée durant une période dans laquelle le domaine ne peut pas être renouvelé. Les mises en œuvre PEUVENT limiter les périodes de renouvellement à des tranches de temps particulières, comme dans les 90 jours de l’expiration du domaine. Cette réponse indique que la commande RENEW a été reçue en dehors de la période de renouvellement du domaine définie par le système.

549 Échec de commande
Une erreur du système a empêché l’achèvement réussi de la commande RRP demandée. Un nouvel essai de la commande pourrait réussir, mais un échec répété indique une condition d’erreur du système.

550 Domaine parent non enregistré
Le domaine parent d’un serveur de noms à enregistrer n’est pas enregistré. Cela arrive lorsque le registraire essaye d’ajouter un nouveau serveur de noms et que le domaine parent pour le serveur n’existe pas dans le registre.

551 L’état du domaine parent ne permet pas l’opération
L’état du domaine parent ne permet pas l’opération demandée. Cela arrive lorsque un registraire essaye de modifier un serveur dont le domaine parent est étiqueté comme LOCK ou HOLD dans le registre.

552 L’état du domaine ne permet pas l’opération
L’état du domaine ne permet pas l’opération demandée. Cela arrive lorsque un registraire essaye de modifier ou supprimer un domaine qui est étiqueté comme LOCK ou HOLD dans le registre.

553 Opération interdite. Domaine encours de transfert
L’état du domaine ne permet pas l’opération demandée. Le registraire tente de supprimer un domaine dont la demande de transfert est en cours d’approbation ou de refus.

554 Domaine déjà enregistré
Un registraire a essayé d’enregistrer un nom de domaine qui est déjà enregistré par le même registraire.

555 Domaine déjà renouvelé
Un registraire a essayé de renouveler un domaine en utilisant les mêmes paramètres que spécifiés pour un renouvellement antérieur réussi. Cela va couramment arriver en exécutant la même commande RENEW plus d’une fois.

556 Période maximum d’enregistrement dépassée
Un registraire a essayé de renouveler un enregistrement de domaine, et la nouvelle période d’enregistrement résultante dépasse la période d’enregistrement maximum définie par le système. Si il y a du temps de renouvellement disponible avec la période d’enregistrement maximum définie par le système, il est possible de réessayer la commande RENEW avec les paramètres de période de renouvellement spécifiés.

5.2	Correspondance commande-réponse
La session entre le client et le serveur est destinée à être un dialogue alternatif. Chaque commande produite par un client DOIT faire l’objet d’une réaction de la part du serveur, qui DOIT retourner un code de réponse pour documenter le succès ou l’échec de l’exécution de la commande. "Succès" signifie que la commande a achevé son exécution normale sans erreur. "Échec" signifie que le système n’a pas terminé la commande comme demandé. L’échec peut être dû à une erreur de syntaxe, de sémantique, de données, ou du système.

Une liste complète des codes de réponse pour chaque commande RRP est donnée ci-dessous.

Commande : ADD
Succès : 200, 220
Échec : 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 535, 540, 541, 545, 546, 547, 549, 550, 554

Commande : CHECK
Succès : 210, 211, 212, 213
Échec : 220, 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 541, 547, 549

Commande : DEL
Succès : 200, 220
Échec : 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 532, 533, 541, 544, 545, 547, 549, 551, 552, 553

Commande : DESCRIBE
Succès : 200, 220
Échec : 420, 421, 500, 501, 506, 507, 509, 520, 547, 549

Commande : MOD
Succès : 200, 220
Échec : 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 535, 540, 541, 542, 543, 544, 545, 547, 549, 550, 551, 552, 553

Commande : QUIT
Succès : 220
Échec : 420, 421, 500, 507, 520, 547, 549

Commande : RENEW
Succès : 200, 220
Échec : 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 541, 545, 546, 547, 548, 549, 552, 553, 555, 556

Commande : SESSION
Succès : 200, 220
Échec : 420, 421, 500, 501, 506, 507, 508, 509, 520, 521, 530, 531, 547, 549

Commande : STATUS
Succès : 200, 220
Échec : 420, 421, 500, 501, 502, 503, 504, 505, 506, 507, 508, 520, 531, 541, 545, 547, 549

Commande : TRANSFER
Succès : 200, 220
Échec : 420, 421, 500, 501, 502, 503, 504, 505, 506, 507, 508, 520, 531, 534, 536, 541, 544, 545, 546, 547, 549, 552, 553

6.	Codes d’état de domaine

L’état d’un domaine peut être vu comme l’utilisation de la commande RRP STATUS et la modification comme l’utilisation de la commande RRP MOD. Le registre et le registraire parrain PEUVENT voir et changer l’état d’un domaine. Les critères du changement d’état sont largement dépendants des modèles commerciaux du registre et du registraire et sortent donc du domaine d’application de la présente spécification.

L’état du domaine DEVRAIT avoir un rapport direct avec le fait que le domaine apparaît ou non dans le fichier de zone du TLD approprié et le fait que le domaine peut ou non être modifié. Un domaine peut avoir plus d’un état alloué, par exemple, REGISTRY-HOLD et REGISTRY-LOCK. Si un domaine est dans l’état ACTIF, le nom de domaine peut seulement être dans cet état. Lorsque un registraire règle un nom de domaine à REGISTRY-LOCK, le registre DOIT automatiquement retirer l’état ACTIF. Lorsque le registraire retire l’état REGISTRY-LOCK et d’autres états de domaines, le registre DOIT automatiquement régler l’état du nom de domaine à ACTIF.

6.1	Description du code d’état de domaine
ACTIF : c’est l’état par défaut d’un domaine au moment de l’enregistrement. Le registre règle le domaine à cet état. Le domaine est modifiable par le registraire. Le domaine peut être renouvelé. Le domaine DEVRA être inclus dans le fichier de zone lorsque il est dans cet état si le domaine a au moins un serveur de noms associé.

REGISTRY-LOCK : le registre règle le domaine à cet état. Le domaine ne peut pas être modifié ou supprimé par le registraire. Le registre DOIT retirer l’état REGISTRY-LOCK pour que le registraire modifie le domaine. Le domaine peut être renouvelé. Le domaine DEVRA être inclus dans le fichier de zone lorsque il est dans cet état si le domaine a au moins un serveur de noms associé.

REGISTRY-HOLD : le registre règle le domaine à cet état. Le domaine ne peut pas être modifié ou supprimé par le registraire. Le registre DOIT retirer l’état REGISTRY-HOLD pour que le registraire modifie le domaine. Le domaine peut être renouvelé. Le domaine NE DEVRA PAS  être inclus dans le fichier de zone lorsque il est dans cet état.

REGISTRAR-HOLD : le registraire du domaine règle le domaine à cet état. Le domaine ne peut pas être modifié ou supprimé lorsque il est dans cet état. Le registraire DOIT retirer l’état REGISTRAR-HOLD pour modifier le domaine. Le domaine peut être renouvelé. Le domaine NE DEVRA PAS être inclus dans le fichier de zone lorsque il est dans cet état.

REGISTRAR-LOCK : le registraire du domaine règle le domaine à cet état. Le domaine ne peut pas être modifié ou supprimé lorsque il est dans cet état. Le registraire DOIT retirer l’état REGISTRAR-LOCK pour modifier le domaine. Le domaine peut être renouvelé. Le domaine DEVRA être inclus dans le fichier de zone lorsque il est dans cet état.

REGISTRY-DELETE-NOTIFY : un domaine est réglé à cet état si il est arrivé à expiration et a des serveurs de noms enfants qui hébergent d’autres domaines. Seul le registre peut établir cet état. Le domaine DEVRA être inclus dans le fichier de zone lorsque il est dans cet état si le domaine a au moins un serveur de noms associé.

7.	Syntaxe formelle

La spécification de syntaxe suivante utilise la forme Backus-Naur augmentée (ABNF) décrite dans la [RFC2234].

; Spécification ABNF pour le protocole de registre à registraire (RRP) v1.1.0
; Noter que les littéraux de chaîne de caractères sont insensibles à la casse.

; Jetons lexicaux
espace = %x20 ; " "
point = %x2E ; "."
tiret = %x2D ; "-"
souligné = %x5F ; "_"
deux-points = %x3A ; ":"
cr = %x0D ; retour chariot ASCII
lf = %x0A ; saut à la ligne ASCII
CRLF = cr lf
alpha = %x41-5A / %x61-7A ; A-Z / a-z
chiffre = %x30-39 ; 0-9
dns-caract = alpha / chiffre / tiret
id-caract = alpha / chiffre / souligné / tiret
id-prefix = alpha / chiffre
id-mot = id-prefix *id-caract
caract-imprimable = %x20-7E ; ASCII " " - "~"

; Début de la grammaire de base.
année = 4chiffres
mois = 2chiffres
jour = 2chiffres
amj = année tiret mois tiret jour
heure = 2chiffres
minute = 2chiffres
seconde = 2chiffres
split-second = 1chiffre
hms = heure deux-points minute deux-points seconde point split-second
horodatage = amj espace hms
ip-adresse = 1*3chiffre point 1*3chiffre point 1*3chiffre point 1*3chiffre
mot-de-passe = 4*16caract-imprimable
option-nom = 1*128id-mot
option-tag = tiret option-nom
option-valeur = 1*128id-mot
attribut-nom = 1*128id-mot
attribut-valeur = 1*128caract-imprimable
attribut-ligne = attribut-nom deux-points attribut-valeur CRLF
réponse = 3chiffre espace 1*caract-imprimable CRLF
version-numéro = "RRP" espace 1*chiffre point 1*chiffre point 1*chiffre
label = id-prefix [*61dns-caract id-prefix]
sldn = label point label
nomdeserveur = *(label point) sldn
period = %x31-39 / (%x31-39 %x30-39) ; "1" - "9" ou "10" - "99"
period-option = tiret "Period" deux-points period CRLF
ouinon = "Oui" / "Non"
domainstatus = "Actif" / "Registry-Lock" / "Registry-Hold" / "Registry-Lock" / "Registry-Hold" / "Registry-Delete-Notify"

; commandes et réponses RRP.
rrp = add / check / delete / describe / mod / quit / renew / session / status / transfer

add = add-request add-réponse
check = check-request check-réponse
delete = del-request del-réponse
describe = describe-request describe-réponse
mod = mod-request mod-réponse
quit = quit-request quit-réponse
renew = renew-request renew-réponse
session = session-request session-réponse
status = status-request status-réponse
transfer = transfer-request transfer-réponse

; commande ADD.
add-request = add-domain-request / add-serveurdenom-request
add-response = add-domain-response / add-serveurdenom-réponse
add-domain-request = "add" CRLF
 "NomD’Entité" deux-points "Domaine" CRLF
 "NomDeDomaine" deux-points sldn CRLF
 [period-option]
 0*13("NomDeServeur" deux-points nomdeserveur CRLF)
 point CRLF
add-serveurdenom-request = "add" CRLF
 "NomD’Entité" deux-points "NomDeServeur" CRLF
 "NomDeServeur" deux-points nomdeserveur CRLF
 1*("IPAddress" deux-points ip-adresse CRLF)
 point CRLF
add-domain-réponse = réponse
 "RegistrationExpirationDate" deux-points horodatage CRLF
 "status" deux-points domainstatus CRLF
 point CRLF
add-serveurdenom-réponse = réponse
 point CRLF

; commande CHECK.
check-request = check-domain-request / check-serveurdenom-request
check-réponse = check-domain-réponse / check-serveurdenom-réponse
check-domain-request = "check" CRLF
"NomD’Entité" deux-points "Domaine" CRLF
"NomDeDomaine" deux-points sldn CRLF
 point CRLF
check-serveurdenom-request = "check" CRLF
"NomD’Entité" deux-points "NomDeServeur" CRLF
"NomDeServeur" deux-points servername CRLF
point CRLF
check-domain-réponse = réponse
point CRLF
check-serveurdenom-response = disponible-check-serveurdenom-réponse / nondisponible-check-serveurdenom-réponse
disponible-check-serveurdenom-réponse = réponse
point CRLF
nondisponible-check-serveurdenom-réponse = réponse
1*("IPAddress" deux-points ip-adresse CRLF)
point CRLF

; commande DEL.
del-request = del-domain-request / del-serveurdenom-request
del-réponse = réponse
 point CRLF
del-domain-request = "del" CRLF
 "NomD’Entité" deux-points "Domaine" CRLF
 "NomDeDomaine" deux-points sldn CRLF
 point CRLF
del-serveurdenom-request = "del" CRLF
 "NomD’Entité" deux-points "NomDeServeur" CRLF
 "NomDeServeur" deux-points nomdeserveur CRLF
 point CRLF

; commande DESCRIBE.
describe-request = "describe" CRLF
 [target-option]
 *(option-tag deux-points option-valeur CRLF)
 point CRLF
describe-réponse = réponse
 "Protocole" deux-points version-numéro CRLF
 *attribut-ligne
 point CRLF
target-option = tiret "Target" deux-points "Protocole" CRLF

; commande MOD.
mod-request = mod-domain-request / mod-serveurdenom-request
mod-réponse = réponse
 *attribut-ligne
 point CRLF
mod-domain-request = "mod" CRLF
 "NomD’Entité" deux-points "Domaine" CRLF
 "NomDeDomaine" deux-points sldn CRLF
 *(add-attribut-valeur-ligne /
 remove-attribut-valeur-ligne /
 replace-attribut-valeur-ligne)
 point CRLF
mod-serveurdenom-request = "mod" CRLF
 "NomD’Entité" deux-points "NomDeServeur" CRLF
 "NomDeServeur" deux-points nomdeserveur CRLF
 ["NewNameServer" deux-points attribut-valeur CRLF]
 *(add-attribut-valeur-ligne /
 remove-attribut-valeur-ligne /
 replace-attribut-valeur-ligne)
 point CRLF
add-attribut-valeur-ligne = attribut-nom deux-points nouvelle-valeur-attribut
remove-attribut-valeur-ligne = attribut-nom deux-points vieille-valeur-attribut "="
replace-attribut-valeur-ligne = attribut-nom deux-points vieille-valeur-attribut "=" nouvelle-valeur-attribut
vieille-valeur-attribut = attribut-valeur
nouvelle-valeur-attribut = attribut-valeur

; commande QUIT.
quit-request = "quit" CRLF
 point CRLF
quit-réponse = réponse
 point CRLF

; commande RENEW.renew-request = "renew" CRLF
 "NomD’Entité" deux-points "Domaine" CRLF
 "NomDeDomaine" deux-points sldn CRLF
 [renew-period-option]
 point CRLF
année-expiration--option = tiret "AnnéeActuelleExpiration" deux-points année CRLF
renew-period-option = period-option année-expiration-option / année-expiration-option period-option
renew-réponse = réponse
 "RegistrationExpirationDate" deux-points horodatage CRLF
 point CRLF

; commande SESSION.
session-request = "session" CRLF
 registraire-id-option
 registraire-mot-de-passe-option
 [registraire-nouveau-mot-de-passe-option]
 point CRLF
session-réponse = réponse
 point CRLF
registraire-id-option = tiret "Id" deux-points option-valeur CRLF
registraire-mot-de-passe-option =
 tiret "MotDePasse" deux-points mot-de-passe CRLF
registraire-nouveau-mot-de-passe-option =
 tiret "NouveauMotDePasse" deux-points mot-de-passe CRLF

; commande STATUS.
status-request = status-domain-request / status-serveurdenom-request
status-response = réponse
 *attribut-ligne
 point CRLF
status-domain-request = "status" CRLF
 "NomD’Entité" deux-points "Domaine" CRLF
 "NomDeDomaine" deux-points sldn CRLF
 point CRLF
status-serveurdenom-request = "status" CRLF
 "NomD’Entité" deux-points "NomDeServeur" CRLF
 "NomDeServeur" deux-points nomdeserveur CRLF
 point CRLF

; commande TRANSFER.
transfer-request = "transfer" CRLF
 [approve-option]
 "NomD’Entité" deux-points "Domaine" CRLF
 "NomDeDomaine" deux-points sldn CRLF
 point CRLF
transfer-réponse = réponse
 "RegistrationExpirationDate" deux-points horodatage CRLF
 point CRLF
approuve-option = tiret "Approuve" deux-points ouinon CRLF

; Fin de la grammaire.

8.	Internationalisation

RRP est défini avec les caractères à 7 bits de l’US-ASCII. Les autres jeux de caractères et code de caractères ne sont actuellement pas pris en charge.

9.	Problèmes connus

RRP n’a pas été conçu pour fournir des caractéristiques d’interrogation de données en vrac. Le but principal des concepteurs du protocole d’origine était de fournir un protocole léger et rapide de transactions qui pourrait être mis en œuvre en minimisant les besoins d’interrogation de base de données qui prendraient un temps "long" pour s’achever ou qui retourneraient de "grandes" quantités de données. Les mises en œuvre DEVRAIENT envisager de développer des dispositifs de rapport hors ligne pour fournir des données brutes pour les rapports de registraire d’une façon convenable pour un certain environnement de fonctionnement de registre à registraire.

La présente version de RRP contient quelques limitations notées dans le cours de plusieurs mois d’expérience de fonctionnement avec de vrais registraires de nom de domaine. Les dernières versions de ce protocole ou ses successeurs devraient s’efforcer de résoudre ou traiter chacune des questions suivantes :

La commande DESCRIBE devrait retourner des informations décrivant les valeurs de mise en œuvre par défaut définies par le système.

L’utilisation de la commande RENEW sans les paramètres "AnnéeCouranteD’Expiration" et "Period" n’assure pas l’idempotence. L’exécution répétée d’une commande RENEW sans ces paramètres peut résulter en plusieurs commandes RENEW réussies, ce qui peut n’être pas l’action désirée si un registraire réessaye une commande RENEW  à cause de problèmes de connexité réseau.

Les horodatages retournés par RRP n’incluent pas d’identifiant de zone horaire et DEVRAIENT être interprétés comme des heures locales de registre.

Le protocole ne donne pas de dispositif qui permette à un registraire de connaître les demandes et réponses de transfert de domaine. Les systèmes doivent s’appuyer sur des moyens extérieurs au protocole, tels que des messages électroniques et les rapports fournis par le registre, pour informer les registraires des demandes et réponses de transfert.

Le protocole ne fournit pas de dispositif pour qu’un registraire détermine tous les domaines desservis par un serveur de noms. Les systèmes doivent fournir ces informations en utilisant une méthode extérieure au protocole, comme des extraits périodiques de la base de données du système.

Le protocole ne fournit pas de dispositif pour gérer les délégations boiteuses de serveurs de noms. Tout registraire peut "utiliser" les serveurs de noms enregistrés par un autre registraire. Lorsque un registraire essaye de supprimer un domaine ou serveur de noms, il est tout à fait possible que les serveurs de noms dans le domaine ou le serveur de noms à supprimer soient associés à d’autres domaines actifs, empêchant la suppression immédiate. Les systèmes doivent s’appuyer sur des moyens extérieurs au protocole pour gérer les délégation boiteuses de serveurs de noms.

L’utilisation de "=" au sein de la commande MOD pour indiquer une valeur à retirer est un peu perturbante. Un moyen plus explicite d’identifier dans la syntaxe du protocole les anciennes et les nouvelles valeurs d’attribut pourrait rendre ce dispositif plus évident.

La commande CHECK retourne aussi les adresses IP de serveur de noms lorsque on retourne une confirmation positive de l’enregistrement d’un serveur de noms. Ces informations peuvent être utiles, mais c’est en contradiction avec la fonction limitée de la commande. La commande devrait retourner une réponse positive ou négative et rien de plus.

La syntaxe formelle de protocole décrite dans ce document exige un ordre spécifique pour les éléments d’un bloc d’entité de commande et les options de commande. La mise en œuvre côté serveur du protocole par NSI Registry donne la souplesse supplémentaire de permettre une spécification indépendante de l’ordre des options et des éléments du bloc d’entité. Les mises en œuvre côté client sont fortement invitées à observer l’ordre des éléments de commande tel que spécifié ici pour assurer la conformité si une forme plus restreinte était mise en application à l’avenir.

RRP ne retourne pas d’horodatages ou d’identifiants de transaction pour suivre les transactions. NSI Registry fournit aux registraires des rapports quotidiens et hebdomadaires qui comportent des horodatages en heure locale du registre pour documenter et synchroniser les données registraire par registraire.

10.	Considérations pour la sécurité

Une mauvaise utilisation du protocole de registraire de registre peut avoir des conséquences catastrophiques sur le fonctionnement des enregistrants, des registraires, et des registres. À ce titre, tous les registraires doivent être authentifiés avant toute interaction avec le registre. De plus, toutes les données échangées entre le registraire et le registre doivent être protégées pour éviter une divulgation involontaire des informations.

11.	Considérations relatives à l’IANA

L’IANA a alloué l’accès TCP 648 à RRP en novembre 1998. Aucune autre action n’est requise de l’IANA pour la prise en charge du fonctionnement de ce protocole.

L’IANA a réservé certaines gammes d’adresses IPv4 comme décrit dans la [RFC2050]. Les mises en œuvres DOIVENT s’assurer que les adresses IP de serveur de noms ne tombent pas dans une des gammes d’adresses réservées pour éviter des erreurs de fonctionnement du DNS.

12.	Références

[RFC2050]	K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, J. Postel, "Lignes directrices pour l'allocation des adresses IP par les registraires Internet", novembre  1996. (Remplacée par la RFC7020) 

[RFC2119]	S. Bradner, "Mots clés à utiliser dans les RFC pour indiquer les niveaux d'exigence", BCP 14, mars 1997.

[RFC2234]	D. Crocker et P. Overell, "BNF augmenté pour les spécifications de syntaxe : ABNF", novembre 1997. (Obsolète, voir RFC5234)

[RFC2246]	T. Dierks et C. Allen, "Protocole TLS version 1.0", janvier 1999.

[RFC6101]	A. Freier, P. Karlton, P. Kocher "Protocole de couche de connexion sécurisée (SSL) version 3.0", août 2011. (Historique)

13.	Remerciements

De nombreuses personnes ont contribué de façon significative au présent document et au protocole qu’il décrit. Brad McMillen et Neeran Saraf méritent une mention particulière comme co-auteurs d’une spécification interne antérieure du protocole. D’autres contributeurs au contenu de la spécification interne antérieure sont Aristotle Balogh, Chris Bason, Mark Kosters, Jasdip Singh, et Yibing Wu. Finalement, les contributeurs les plus significatifs à la révision de ce document sont Steve Mahlstedt et Chris Smith.

14.	Adresse des auteurs

Scott Hollenbeck	Manoj Srivastava	
Network Solutions, Inc. Registry	Network Solutions, Inc. Registry	
505 Huntmar Park Dr.	505 Huntmar Park Dr.	
Herndon, VA 20170	Herndon, VA 20170	
USA	USA	
mél : shollenb@netsol.com 	mél : manojs@netsol.com 	

15.	Déclaration complète de droits de reproduction

Copyright (C) The Internet Society (1999). Tous droits réservés.

Ce document et les traductions de celui-ci peuvent être copiés et diffusés, et les travaux dérivés qui commentent ou expliquent autrement ou aident à sa mise en œuvre peuvent être préparés, copiés, publiés et distribués, partiellement ou en totalité, sans restriction d'aucune sorte, à condition que l'avis de copyright ci-dessus et ce paragraphe soit inclus sur toutes ces copies et œuvres dérivées. Toutefois, ce document lui-même ne peut être modifié en aucune façon, par exemple en supprimant le droit d'auteur ou les références à l'Internet Society ou d'autres organisations Internet, sauf si c'est nécessaire à l'élaboration des normes Internet, auquel cas les procédures pour les droits de reproduction définis dans les processus des normes pour l'Internet doivent être suivies, ou si nécessaire pour le traduire dans des langues autres que l'anglais.

Les permissions limitées accordées ci-dessus sont perpétuelles et ne seront pas révoquées par la Société Internet, ses successeurs ou ayants droit.

Ce document et les renseignements qu'il contient sont fournis "TELS QUELS" et l'INTERNET SOCIETY et l'INTERNET ENGINEERING TASK FORCE déclinent toute garantie, expresse ou implicite, y compris mais sans s'y limiter, toute garantie que l'utilisation de l'information ici présente n'enfreindra aucun droit ou aucune garantie implicite de commercialisation ou d'adaptation a un objet particulier.

Remerciement
Le financement de la fonction d’éditeur des RFC est actuellement fourni par la Internet Society.