Bulletin d'information : clarifications sur les exigences requises aux opérateurs de registre et aux bureaux d'enregistrement pour le WHOIS (port 43) et les services d'annuaire basés sur le Web

Date de publication : 12 septembre 2014 ; mis à jour le 27 avril 2015 ; puis, mis à jour le 25 mai 2018

Changements surlignés

Le présent bulletin d'information a pour objet de fournir les clarifications requises aux opérateurs de registre et aux bureaux d'enregistrement concernant le WHOIS (port 43) et les services d'annuaire basés sur le Web (ci-après dénommés conjointement le Whois) pour se conformer, respectivement, au contrat de registre et au contrat d'accréditation de bureau d'enregistrement.

Les clarifications incluses dans la section I sont applicables tant aux opérateurs de registre qu'aux bureaux d'enregistrement ; la section II s'applique uniquement aux opérateurs de registre ; et la section III s'applique uniquement aux bureaux d'enregistrement.

Un des objectifs de ces clarifications est celui de faciliter l'analyse des résultats obtenus à partir du système. Les utilisateurs intéressés sont encouragés à tenir compte des clarifications ci-dessous lors du développement de systèmes d'analyse des résultats du WHOIS.

Les termes « PEUT », « DOIT », « NE DOIT PAS », « REQUIS », « DEVRAIT » et « NE DEVRAIT PAS » sont utilisés pour indiquer le niveau d'exigence conformément au RFC 2119, disponible à http://www.ietf.org/rfc/rfc2119.txt [TXT, 5 KB].

1. Les clarifications suivantes s'appliquent aux spécifications du service d'annuaire de données d'enregistrement tant des opérateurs de registre que des bureaux d'enregistrement :

   1. Pour chaque type de requête d'objet (nom de domaine, bureau d'enregistrement, serveur de nom), ce bulletin d'information identifie certains champs comme facultatifs. Pour les champs facultatifs où il n'existe pas de données dans le système de registre partagé (SRS), la partie contractante DOIT mettre en œuvre soit : 1) la clé (c.-à-d., la chaîne à gauche de la virgule), qui DOIT être indiquée sans aucune information dans la section valeur (c.-à-d., côté droit de la virgule) du champ ; soit 2) rien ; aucun champ NE DOIT ÊTRE indiqué. S'il existe des données pour un champ facultatif donné, la clé et la valeur avec les données DOIVENT être affichées.

   2. Dans les réponses aux requêtes d'objets portant sur un nom de domaine, les champs suivants sont considérés comme facultatifs et doivent être traités comme décrits dans la clarification 1 :

      • Date de mise à jour (si le nom de domaine n'a pas été mis à jour depuis sa création)
      • Organisation du Titulaire/Admin/Tech
      • État/province du Titulaire/Admin/Tech
      • Code postal du Titulaire/Admin/Tech
      • Poste téléphonique du Titulaire/Admin/Tech
      • Fax du Titulaire/Admin/Tech
      • Poste de fax du Titulaire/Admin/Tech
      • Serveur de nom

      Par exemple, une requête pour un nom de domaine sans serveurs de noms (et pas d'enregistrements DS ou DNSKEY) peut générer l'un des deux résultats suivants :

      …
      E-mail du contact technique : EMAIL@EXEMPLE.TLD
      Serveur de nom :
      DNSSEC : unsigned
      …

      Ou

      …
      E-mail du technicien : EMAIL@EXEMPLE.TLD
      DNSSEC : unsigned
      …

   3. Comme décrit dans le RFC 3912, le protocole WHOIS (port-43) n'a pas été internationalisé. Les opérateurs de registre et les bureaux d'enregistrement sont encouragés à utiliser uniquement le codage et le répertoire de caractères US-ASCII pour les résultats du WHOIS (port 43). Si l'opérateur de registre/bureau d'enregistrement utilise des caractères en dehors du répertoire US-ASCII, le résultat DEVRAIT doit être encodé en UTF-8 afin de maximiser les chances d'interopérabilité.

   4. Le résultat du Whois PEUT montrer une traduction du nom de la clé dans d'autres langues. Toutefois, la première entrée de la clé DOIT être indiquée tel que prévu dans le contrat et la/les traduction(s) DOI(VEN)T être affichée(s) entre parenthèses (U+0028 et U+0029) avec un espace (U+0020) entre la clé du champ (comme spécifié par le RAA 2013 ou le contrat de registre, selon le cas) et les parenthèses d'ouverture (U +0028). Les différentes traductions DOIVENT être séparées par une barre oblique (U+002F). La parenthèse de fermeture (U+0029) DOIT apparaître immédiatement avant la virgule. La traduction du nom de la clé et la parenthèse NE DOIVENT PAS être séparées un ou plusieurs espaces (U+0028 et U+0029). Les barres obliques NE DOIVENT PAS être séparées par un ou plusieurs espaces (U+002F).

      Par exemple, « Nom de domaine : » pourrait apparaître en espagnol et portugais comme :

      Nom de domaine (Nombre de Dominio/Nome de domínio) : foo.example

   5. Toutes les étiquettes de nom de domaine dans les valeurs de n'importe lequel des champs (p. ex., nom de domaine, serveur de noms, e-mail) DOIVENT être indiquées sous la forme compatible avec ASCII (Étiquette A).

      Par exemple, un serveur de noms avec une étiquette IDN devrait être affiché comme :

      Serveur de nom : ns1.xn--caf-dma.example

   6. Si le nom de domaine est un IDN, l'opérateur de registre/bureau d'enregistrement PEUT montrer l'IDN dans le format étiquette-U en utilisant la clé « nom de domaine internationalisé : ». S'il est affiché, le champ DOIT apparaître comme un champ supplémentaire tel que défini dans la clarification 1, ou immédiatement après le champ « Nom de Domaine ». Par exemple :

      Nom de domaine : xn--caf-dma.example
      Nom de domaine internationalisé : café.example
      …

      Ou

      …
      DNSSEC : signedDelegation
      Nom de domaine internationalisé : café.example

   7. Les statuts des domaines DOIVENT se conformer aux cartographies spécifiées dans les appels à commentaires relatifs au EPP : 5730-5734, et 3915. Conformément à l'AWIP (https://www.icann.org/resources/pages/policy-awip-2014-07-02-en), le statut EPP DOIT être immédiatement suivi par au moins un et pas plus de neuf espaces (U+0020), puis suivi d'une URL correspondant à la description du statut dans le site Web de l'ICANN. Pour un exemple, veuillez voir la clarification 1.
   8. La date et l'heure indiquées dans le pied de page « > > > Dernière mise à jour de la base de données Whois : <date et heure > < < < » fait référence à la date et l'heure (au format RFC 3339) auxquelles la base de données des services d'annuaire de données d'enregistrement (RDDS) a été mise à jour à partir de la base de données SRS. Selon l'exigence de niveau de service décrite à l'article 1.4.2 du RAA 2013, et dans la spécification 10 du contrat de registre de base, les services RDDS doivent être mis à jour dans les 60 minutes de tout changement. Dans le cas où la partie contractante interroge directement sa base de données SRS, et utilisant en conséquence des données en temps réel, cette date et heure indiquent l'heure de la réponse à la requête.
   9. La/les adresse(s) IP pour les serveurs de nom NE DEVRAIENT PAS être indiquée(s) dans les requêtes Whois pour les noms de domaine. Si elles sont affichées, la/les adresse(s) IP DOIVENT apparaître immédiatement après le serveur de nom correspondant comme on le fait dans les réponses pour un objet de serveur de noms.
   10. « DNSSEC : signedDelegation » doit être indiqué lorsqu'il y a un ou plusieurs enregistrements DS ou DNSKEY dans le SRS pour le nom de domaine faisant l'objet de la requête. « DNSSEC : unsigned » DOIT être affiché dans tous les autres cas.
   11. Si des champs de données supplémentaires sont inclus dans le résultat du Whois au-delà de ceux requis en vertu du contrat ou de la politique, les champs de données supplémentaires DOIVENT être placés à la fin de la réponse, sauf dans les cas décrits dans ce bulletin d'information ou ceux requis par la politique ou le contrat.
   12. JavaScript ou un autre code de script côté client NE DOIT PAS être ajouté au résultat du WHOIS (port 43), et les données des objets qui pourraient être interprétées à tort comme langage de balisage DOIVENT être complètement évitées dans le Whois basé sur le Web.
   13. Le résultat du Whois basé sur le Web DOIT suivre les mêmes conventions du WHOIS (port 43).
   14. Chaque champ (paire clé/valeur) DOIT être terminé avec ASCII CR et puis ASCII LF <U+000D, U+000A>. (Voir l'article 2 du RFC 3912, spécification du protocole WHOIS). Cela s'applique aux paragraphes utilisés pour les clauses de non-responsabilité légale ou toute autre ligne affichée dans le résultat du Whois.

   15. La clé et les valeurs doivent être séparées par une virgule suivie d'un espace, « : « »» <U+003A,U+0020 >.

       Par exemple, un nom doit être affiché comme :

       Serveur de nom : ns1.xn--caf-dma.example

   16. Les espaces à gauche, avant le texte, NE DEVRAIENT PAS apparaître dans le résultat du Whois. S'ils étaient inclus, le nombre NE DOIT PAS dépasser les 9 espaces. Les espaces de fin NE DOIVENT PAS être inclus.
   17. Il NE DEVRAIT PAS Y AVOIR des lignes vides entre le dernier champ de données dans la réponse et le pied de page « > > > Dernière mise à jour de la base de données Whois : « »<date et heure> <<< ». Il NE DOIT PAS apparaître plus de trois lignes vides entre le dernier champ de données dans la réponse et le pied de page de la « dernière mise à jour ».
   18. Les requêtes WHOIS (port 43) pour les objets portant sur le nom de domaine ne DEVRAIENT retourner qu'un enregistrement par requête (c.-à-d., aucune correspondance partielle ou d'autres capacités de recherche, la recherche sera exclusivement par correspondance exacte).
   19. Tous les champs sont sensibles à la casse. La clé (c.-à-d., la chaîne à gauche de la virgule) est sensible à la casse et elle DOIT être spécifiée par contrat ou par politique.
   20. L'ASCII CR et/ou ASCII LF <U+000D, U+000A > NE DOIVENT apparaître QU'à la fin d'un champ.
   21. L'opérateur de registre et le bureau d'enregistrement DOIVENT utiliser les noms de domaine complètement qualifiés. L'opérateur de registre NE DEVRAIT PAS inclure de point à la fin des noms de domaine lors de l'affichage.
   22. L'opérateur de registre et le bureau d'enregistrement PEUVENT afficher l'information du contact de facturation pour le nom de domaine, sous réserve d'autres exigences contractuelles ou de politique. S'ils apparaissent, les champs de contact DOIVENT être affichés soit comme des champs supplémentaires tels que définis dans la clarification 1 de ce document ou immédiatement après les champs de données du contact technique.

   23. En vertu de la politique relative aux informations WHOIS supplémentaires (AWIP) (https://www.icann.org/resources/pages/policy-awip-2014-07-02-en), le résultat du Whois DOIT inclure un pied de page comme suit « Pour plus d'informations sur les codes du statut du Whois, veuillez visiter le site https://icann.org/epp ». Le pied de page de l'AWIP DOIT apparaître après le dernier pied de page décrit dans la clarification 17. Au moins une ligne vide (et pas plus de trois) DOIT précéder le pied de page de l'AWIP. La clause de non-responsabilité légale DOIT suivre le pied de page de l'AWIP, précédée par au moins une ligne vide et pas plus de trois. Par exemple :

       Nom de domaine : foobar.example
       Identifiant du domaine du registre : D1234567-Exemple
       …
       DNSSEC : signedDelegation
       URL du formulaire de plainte pour inexactitude des données du Whois de l' ICANN : https://www.icann.org/wicf/
       >>> Dernière mise à jour de la base de données WHOIS : 2009-05-29T20:15:00Z <<<

       Pour plus d'informations sur les codes de statut du Whois, merci de vous rendre sur https://icann.org/epp

       Conditions d'utilisation : Les utilisateurs de ce service Whois …

   24. Les champs du résultat du Whois NE DOIVENT PAS apparaître plusieurs fois, sauf avis contraire explicitement spécifié.
   25. Dans les réponses aux requêtes d'objets portant sur le nom de domaine, les champs suivants peuvent avoir plusieurs valeurs et, par conséquent, PEUVENT apparaître plusieurs fois :
       • Statut du domaine
       • Serveur de nom
       • Rue de facturation du Titulaire/Admin/Tech (c.-à-d., suivant l'usage du RFC 5733 sur le EPP)
   26. Lors de la réception d'une requête pour un objet qui n'existe pas dans le SRS, la partie contractante DEVRAIT retourner la clé « l'objet demandé n'existe pas : », suivie de manière facultative par un message de texte défini par le registre (la valeur) qui fournit de plus amples renseignements au sujet de la non-existence de l'objet. Aucun autre champ NE DOIT être affiché. Le pied de page de la « dernière mise à jour », la ligne vide, et la clause de non-responsabilité légale DOIVENT suivre comme pour d'autres requêtes Whois.

2. Les clarifications suivantes s'appliquent uniquement aux opérateurs de registre.

   27. Dans les réponses aux requêtes de serveur de nom, les champs suivants sont considérés comme facultatifs et doivent être traités comme décrit dans la clarification 1 :
       • Bureau d'enregistrement
       • Serveur WHOIS du bureau d'enregistrement
       • URL du bureau d'enregistrement
   28. Les requêtes WHOIS (port 43) pour des objets portant sur le serveur de noms NE DEVRAIENT PAS offrir la correspondance partielle ou d'autres capacités de recherche.

   29. Une requête pour un objet serveur de nom, utilisant soit le nom du serveur de nom soit l'adresse IP comme la chaîne de requête pourrait correspondre à plus d'un objet. Dans ce cas, l'opérateur de registre DEVRAIT donner comme réponse « la requête a une correspondance exacte avec plus d'un serveur de nom : » suivie par les ROID correspondant avec le nom du serveur de nom entre parenthèses, un par ligne. Par exemple, la réponse à une requête pour les serveurs de noms avec l'IP « 203.0.113.7 » ayant trois objets avec une correspondance exacte sera :

       La requête a une correspondance exacte avec plus d'un serveur de nom :
       roid1abc-examplerep (ns1.foo.example)
       roid5jkl-examplerep (ns2.example.com)
       roid9mno-examplerep (ns1.example.net)
       >>> Dernière mise à jour de la base de données WHOIS : 2009-05-29T20:15:00Z <<<

   30. Un opérateur de registre qui met en œuvre des clarifications 29 DOIT supporter les requêtes pour les objets portant sur un serveur de nom à l'aide du ROID d'un objet serveur de nom, par exemple, les requêtes de la forme : whois roid <roid>, où <roid> est le ROID d'un serveur de nom.
   31. Un opérateur de registre PEUT offrir des capacités de correspondance partielle pour les requêtes d'un objet bureau d'enregistrement. Lors de la réception d'une requête pour un objet bureau d'enregistrement qui correspond à plus d'un objet, l'opérateur de registre DOIT afficher plusieurs enregistrements en réponse. Chaque objet de bureau d'enregistrement DOIT être séparé par une ligne vide, suivie par la clé « nom du bureau d'enregistrement : » qui indique le début d'un nouvel enregistrement. Par exemple, la réponse à une requête pour le bureau d'enregistrement « Exemple » qui a deux objets ayant une correspondance exacte sera (si elle fournit des capacités de recherche) :

       Bureau d'enregistrement : Bureau d'enregistrement exemple, Inc.
       …
       URL du bureau d'enregistrement : http://www.example-registrar.example
       Contact administratif : Bureau d'enregistrement Joe
       Numéro de téléphone : +1. 5553101213
       Numéro de fax : +1. 5553101213
       E-mail : joeregistrar@example-registrar.example
       Contact administratif : Bureau d'enregistrement Jane
       Numéro de téléphone : +1. 5553101214
       Numéro de fax : +1. 5553101213
       E-mail : janeregistrar@example-registrar.example
       Contact technique : John Geek
       …

       Bureau d'enregistrement : Bureau d'enregistrement exemple deux, Inc.
       …
       URL du bureau d'enregistrement : http://www.example-registrar-two.example
       Contact administratif : Bureau d'enregistrement Joe deux
       Numéro de téléphone : +1. 5553101213
       Numéro de fax : +1. 5553101213
       E-mail : joeregistrar@example-registrar-two.example
       Contact administratif : Bureau d'enregistrement Jane
       Numéro de téléphone : +1. 5553101214
       Numéro de fax : +1. 5553101213
       E-mail : janeregistrar@example-registrar-two.example
       Contact technique : John Geek
       …
       >>> Dernière mise à jour de la base de données WHOIS : 2009-05-29T20:15:00Z <<<

   32. Lors de la réception d'une requête pour un objet portant sur un serveur de nom qui correspond à plus d'un objet, l'opérateur de registre DOIT afficher en réponse plusieurs enregistrements si la clarification 29 de ce document n'a pas été mise en œuvre. Chaque objet serveur de nom DOIT être séparé par une ligne vide, suivie par la clé « Serveur de nom : » qui indique le début d'un nouvel enregistrement. Par exemple, la réponse à une requête pour le serveur de nom « 203.0.113.7 » qui a deux objets ayant une correspondance exacte sera :

       Serveur de nom : ns1.foo.example
       Adresse IP : 203.0.113.7
       Bureau d'enregistrement : Bureau d'enregistrement exemple, Inc.
       Serveur WHOIS du bureau d'enregistrement : whois.example-registrar.tld
       URL du bureau d'enregistrement : http://www.example-registrar.example
       Serveur de nom : ns3.bar.example
       Adresse IP : 203.0.113.7
       Bureau d'enregistrement : Bureau d'enregistrement exemple 2, Inc.
       Serveur WHOIS du bureau d'enregistrement : whois.example-registrar2.example
       URL du bureau d'enregistrement : http://www.example-registrar2.example
       >>> Dernière mise à jour de la base de données WHOIS : 2009-05-29T20:15:00Z <<<

   33. L'opérateur de registre PEUT afficher les éléments extension téléphonique et/ou extension de fax pour les contacts dans les données du bureau d'enregistrement. S'il est indiqué, chaque champ DOIT être affiché, soit en tant que champ de données supplémentaires au sens de la clarification 1 de ce document, soit immédiatement après le champ respectif de contact téléphonique ou de fax.
   34. Les opérateurs de registre DEVRAIENT supporter les requêtes pour des objets portant sur un bureau d'enregistrement en utilisant l'ID IANA du bureau d'enregistrement, par exemple, les requêtes de la forme : whois registrar-id <IANA ID>.
   35. Dans les réponses aux requêtes d'objets portant sur un serveur de noms, le champ « Adresse IP » peut avoir plusieurs valeurs et donc, PEUT apparaître plusieurs fois.

   36. Dans le cas de requêtes pour des serveurs de noms pour lesquels il y a au moins un nom de domaine actif qui exige des données de type glue dans le DNS (veuillez voir le RFC 1034) et lorsque les opérateurs de registre ont lesdites données, les opérateurs de registre DOIVENT inclure dans les données de réponse de leur SRS (p. ex., serveur de nom, adresses IP) la/les adresse(s) IP connexe(s) d'au moins le nom de domaine qui nécessite des données de type glue dans le DNS. Dans d'autres cas, les opérateurs de registre PEUVENT fournir une réponse avec les données du SRS.

       Par exemple, si le nom de domaine « foo.example » est actif dans le DNS et a le serveur de nom « ns.foo.example », la/les adresse(s) IP et les données connexes du SRS pour le serveur de nom seront affichées dans les résultats du Whois d'une requête pour le serveur de nom « ns.foo.example ».

   37. Dans les réponses aux requêtes d'un objet portant sur un bureau d'enregistrement, les champs suivants peuvent avoir plusieurs valeurs et, par conséquent, PEUVENT apparaître plusieurs fois :
       • Contact administratif
       • Contact technique
       • E-mail
       • Numéro de fax
       • Numéro de téléphone
       • Ext. téléphonique
       • Ext. fax
       • Rue

       Lorsqu'une requête d'objet portant sur un bureau d'enregistrement renvoie à plusieurs contacts administratifs ou techniques, les domaines connexes (e-mail, numéro de fax et numéro de téléphone) DOIVENT suivre le champ du nom du contact (c.-à-d., contact administratif ou contact technique). Par exemple, la réponse à une requête pour un bureau d'enregistrement qui a deux contacts administratifs sera :

       Bureau d'enregistrement : Bureau d'enregistrement exemple, Inc.
       …
       URL du bureau d'enregistrement : http://www.example-registrar.example
       Contact administratif : Bureau d'enregistrement Joe
       Numéro de téléphone : +1. 5553101213
       Numéro de fax : +1. 5553101213
       E-mail : joeregistrar@example-registrar.example
       Contact administratif : Bureau d'enregistrement Jane
       Numéro de téléphone : +1. 5553101214
       Numéro de fax : +1. 5553101213
       E-mail : janeregistrar@example-registrar.example
       Contact technique : John Geek
       …
       >>> Dernière mise à jour de la base de données WHOIS : 2009-05-29T20:15:00Z <<<

   38. Lors de la réception d'une « requête non qualifiée » (par exemple, une chaîne de requête qui n'inclut pas les paramètres « serveur de nom » ou « bureau d'enregistrement ») qui correspond à un objet portant sur un nom de domaine et un objet relatif au serveur de nom, l'opérateur de registre DEVRAIT afficher en réponse l'information sur l'objet portant sur un nom de domaine.
   39. Dans les réponses aux requêtes d'un objet portant sur un bureau d'enregistrement, les champs suivants sont considérés comme facultatifs et devraient être traités comme décrit dans la clarification 1:
       • État/Province
       • Code postal
       • Numéro de fax
   40. Les réponses aux requêtes d'un objet portant sur un bureau d'enregistrement DEVRAIENT inclure au moins un contact administratif et un contact technique.

   41. Sauf si cela était autrement requis par la politique ou le contrat, la section valeur (c.-à-d., à droite de la virgule) des champs DOIT se conformer au format défini dans les appels à commentaires relatifs au EPP : 5730-5734, et 3915. Les champs suivants ne sont pas spécifiés dans le RFC relatif au EPP : 5730-5734, ou 3915, et DOIVENT suivre les spécifications ci-dessous relatives au format :

       1. La valeur « serveur WHOIS du bureau d'enregistrement » est définie comme un nom d'hôte (voir RFC952 et RFC1123) et DOIT indiquer le serveur de nom du serveur WHOIS (port-43) du bureau d'enregistrement parrain/mentionné, si le bureau d'enregistrement mentionné offre un service WHOIS (port-43) pour l'objet demandé, il serait autrement considéré comme facultatif tel que décrit dans la clarification 1 ;
       2. La valeur « URL du bureau d'enregistrement » est définie comme une URL (voir RFC3986). La valeur DOIT afficher un site Web du bureau d'enregistrement parrain. L'URL DOIT être soit : l'URL du Web-Whois de l'objet demandé, le service Web-Whois du bureau d'enregistrement, ou la page Web principale du bureau d'enregistrement parrain ;
       3. La valeur « ID IANA du bureau d'enregistrement » est définie comme un entier décimal positif ;
       4. La valeur « Bureau d'enregistrement » est définie comme jeton (voir Langage de balisage étendu 1.1) ;
       5. Les éléments de l'objet contact pour l'objet bureau d'enregistrement sont définis comme des éléments EPP des objets contact.

   42. Dans les réponses aux requêtes d'un objet nom de domaine, bureau d'enregistrement ou serveur de nom, les champs suivants sont considérés comme facultatifs et doivent être traités comme décrit dans les clarifications 1 :

       • Serveur WHOIS du bureau d'enregistrement (si le bureau d'enregistrement parrain/mentionné n'offre pas le service WHOIS (port-43) pour l'objet demandé)

3. Les précisions suivantes s'appliquent uniquement aux bureaux d'enregistrement.

   43. Un bureau d'enregistrement EST seulement TENU d'afficher les informations du Whois des noms de domaine pour lesquels le bureau d'enregistrement est le bureau d'enregistrement parrain.
   44. Le champ « ID du domaine du registre : » fait référence à l'identificateur de l'objet référencé (ROID) pour l'objet nom de domaine comme spécifié dans le RFC 5730 (appelé ID du domaine dans la spécification 4 du contrat de registre). Par exemple, un bureau d'enregistrement pourrait obtenir le ROID du registre via l'EPP et mettre en cache localement les informations après avoir créé ou obtenu un nom de domaine via un transfert.
   45. Les champs « Registre Admin/Tech/Facturation/ID du titulaire : » font référence à l'identificateur de l'objet référencé (ROID) pour l'objet Contact comme spécifié dans le RFC 5733. Par exemple, un bureau d'enregistrement pourrait obtenir le ROID du registre via l'EPP et mettre en cache les informations localement. Le RAA 2013 définit que cette information DOIT être indiquée si elle est disponible à partir du registre. Si cette information n'est pas disponible à partir du registre (par exemple, un registre « résumé »), la chaîne « Non disponible du registre » DEVRAIT être affichée à sa place.
   46. Le champ « Date de mise à jour : » DOIT refléter la date et l'heure de la dernière mise à jour réussie connue du bureau d'enregistrement. Les bureaux d'enregistrement ne sont pas tenus d'actualiser constamment cette « date de mise à jour : » de l'opérateur de registre.
   47. L'exigence de niveau de service « Temps de mise à jour du RDDS » décrite à l'article 2.2 de la spécification du Service d'annuaire de données d'enregistrement (WHOIS) fait uniquement référence aux changements initiés par le bureau d'enregistrement.
   48. Les statuts EPP dans les résultats Whois DOIVENT refléter le dernier ensemble connu de statuts EPP du registre. Les bureaux d'enregistrement ne sont pas tenus de mettre à jour en permanence les statuts EPP du registre.

   49. Sauf si cela était autrement requis par la politique ou le contrat, la section valeur (c.-à-d., à droite de la virgule) des champs DOIT se conformer au format défini dans les appels à commentaires relatifs au EPP : 5730-5734, et 3915. Les champs suivants ne sont pas spécifiés dans le RFC relatif au EPP : 5730-5734, ou 3915, et DOIVENT suivre les spécifications ci-dessous relatives au format :

       1. « E-mail du point de contact du bureau d'enregistrement prévu pour signaler des cas d'abus » (au sens du RFC relatif au EPP pour les champs e-mail)
       2. « Téléphone du point de contact du bureau d'enregistrement prévu pour signaler des cas d'abus » (au sens du RFC relatif au EPP pour les champs téléphone)
       3. « Revendeur » est défini comme jeton (voir Langage de balisage étendu 1.1)
       4. La valeur « Serveur Whois du bureau d'enregistrement » est définie comme un nom d'hôte (voir RFC952 et RFC1123) et elle est le serveur de nom du serveur WHOIS (port 43) du bureau d'enregistrement parrain
       5. La valeur « URL du bureau d'enregistrement » est définie comme une URL (voir RFC3986) et DOIT indiquer le site Web du bureau d'enregistrement parrain, plus précisément, l'URL du Web-Whois de l'objet demandé, ou au moins l'URL du service Web-Whois du bureau d'enregistrement
       6. La valeur « ID IANA du bureau d'enregistrement » est définie comme un entier décimal positif.
       7. La valeur « Bureau d'enregistrement » est définie comme jeton (voir Langage de balisage étendu 1.1).
   50. La valeur du champ « Revendeur » DEVRAIT être affichée mais PEUT être laissée en blanc ou ne pas être affichée du tout. Si elle était indiquée, la valeur du champ DOIT être le nom de l'organisation, si le revendeur du nom était une personne morale ou une personne physique avec un autre nom.
   51. Les champs ci-dessous PEUVENT apparaître immédiatement avant le dernier champ (« URL du formulaire de plainte pour inexactitude des données Whois de l'ICANN ») au lieu de suivre le champ « ID IANA du bureau d'enregistrement » :
       • E-mail du point de contact du bureau d'enregistrement prévu pour signaler des cas d'abus
       • Téléphone du point de contact du bureau d'enregistrement prévu pour signaler des cas d'abus