Résumé

  • Le changelog actuel d’AFRINIC associe WHOIS 2.10.7, daté du 29 novembre 2022, à l’ajout d’une fonctionnalité RDAP appelée JSContact.
  • Le guide RDAP actuel décrit les recherches et le client, mais ne documente ni version JSContact, ni représentation de réponse, ni signal de conformité, ni méthode de demande.
  • Cette absence relève du texte du guide ; elle ne décrit pas le comportement de l’endpoint et ne démontre aucune non-conformité.

Ce que le mot « ajouté » permet réellement de dire

Le journal d’AFRINIC est une source affirmative. La version WHOIS 2.10.7 y est encore indiquée comme courante. Ses notes mentionnent des corrections et améliorations liées à la conformité du profil RDAP de la NRO, puis l’ajout de JSContact comme fonctionnalité RDAP. Ce sont des faits publics utiles. Ils attestent qu’AFRINIC a voulu rendre visible un changement dans son service de registre.

Le guide RDAP est une source affirmative d’un autre ordre. Il fournit l’adresse du service, les requêtes pour réseaux IP, numéros d’AS, DNS inverse et entités, une référence au client NicInfo et un exemple de redirection HTTP 301 hors région. Il répond donc à la question pratique : où interroger et quelles familles de ressources demander ?

Ce que les deux sources ne joignent pas est tout aussi délimité. Dans la partie RDAP du guide, une vérification textuelle actuelle ne trouve pas JSContact, jCard, rdapConformance ni version. Un lecteur ne peut pas y déterminer quelle représentation de contact est annoncée, si une version est pertinente, quel en-tête ou quel paramètre serait éventuellement reconnu, ni quel élément de réponse confirmerait le choix.

Il serait pourtant excessif de transformer cette limite documentaire en diagnostic technique. Rien ici ne démontre qu’une réponse AFRINIC ne contient pas JSContact, qu’un client est empêché de l’obtenir, qu’un profil NRO n’est pas respecté ou qu’une donnée a été mal traitée. Aucun endpoint n’a été observé pour cette commission. Un guide peut rester plus étroit que le service qu’il décrit. La bonne question n’est pas « que cache AFRINIC ? », mais « quelle information publique un lecteur peut-il raisonnablement attacher à ce nom de fonctionnalité ? »

Un même nom a traversé plusieurs textes

La chronologie invite à ne pas inventer cette réponse. En avril 2022, le brouillon IETF Using JSContact in RDAP JSON Responses existait déjà. Il présentait une extension RDAP pour les informations de contact d’entités et se décrivait lui-même comme travail en cours. Il utilisait alors notamment le terme jscard. Cela précède l’entrée AFRINIC de novembre, mais ne prouve ni que l’organisation a mis en œuvre ce brouillon, ni quelle partie elle aurait retenue.

Le brouillon courant d’août 2026 emploie une terminologie plus récente : jscontact_card, sélection de représentation sollicitée par le client, signalisation via rdapConformance, étapes de transition entre jCard et JSContact. Cette évolution ne permet pas de relire 2022 comme si AFRINIC avait promis une étape précise. Elle montre seulement qu’un mot générique peut couvrir des questions distinctes pour un client : format par défaut, demande explicite, marqueur de réponse et compatibilité.

Le registre IANA de JSContact distingue aujourd’hui les versions majeures 1.0 et 2.0. Ce registre n’identifie pas un déploiement AFRINIC. Il rend en revanche intelligible la prudence documentaire : le nom d’une famille de données n’est pas toujours une information suffisante sur la forme publiée par un service.

AFRINIC a le meilleur argument pour conserver une documentation concise. Le registre n’a pas à publier des notes internes de conception, des configurations de sécurité, des données de contact ou le détail d’un déploiement. L’annonce de changement et le guide des requêtes ont déjà chacun une fonction légitime.

Un enregistrement public très court pourrait néanmoins les relier. Il indiquerait la révision du service et de la documentation ; la représentation et la version annoncées, si elles existent ; une méthode de demande seulement lorsqu’elle est offerte ; un marqueur de conformité ; l’état de compatibilité ; la référence de profil pertinente ; le comportement de repli documenté ; le responsable, la date de correction et l’historique des remplacements. Ce serait un reçu de disponibilité d’extension, non une injonction à adopter un protocole particulier.

Préserver l’autorité, rendre la phrase vérifiable

Le registre doit garder l’autorité de décider de sa représentation et de son calendrier. Les lecteurs ne doivent pas convertir une brève annonce en garantie technique non écrite. Un reçu rend ces deux positions compatibles : il permet de vérifier le périmètre public de la phrase sans exiger une divulgation opérationnelle.

Ainsi, la clarification demandée n’est pas une nouvelle règle de politique. Elle ne décide pas de l’attribution de ressources. Elle donne à une annonce la capacité minimale de rejoindre le guide qu’utilisent les clients.

Sources

  1. Journal des modifications des services en ligne AFRINIC
  2. Guide du service RDAP d’AFRINIC
  3. IETF draft-ietf-regext-rdap-jscontact-11
  4. IETF draft-ietf-regext-rdap-jscontact
  5. Registre IANA JSContact