Résumé

  • Le membre redacted de la RFC 9537 permet au serveur de nommer un champ soustrait, sa méthode de masquage et un chemin dans la forme antérieure ou livrée de la réponse. Il documente une décision de sortie, pas le contenu secret du registre.
  • Le motif reste facultatif, la politique demeure hors du périmètre de la RFC et le signal lui-même peut être omis si reconnaître l’existence du champ porte atteinte à la vie privée. Une preuve exploitable doit donc conserver requête, serveur, niveau d’accès, heure, réponse brute et version de politique.

La comparaison qui inventait une cause

Imaginons une veille qui interroge chaque nuit le même nom de domaine. Lundi, une entité de contact contient une adresse électronique de relais. Mardi, l’entité n’apparaît plus. Le moteur de comparaison annonce « donnée censurée ». Il a observé un changement réel, mais lui a donné une cause sans reçu : le champ a pu être absent à la source, déplacé, retiré par politique, limité à un autre niveau d’accès ou perdu à la suite d’une erreur.

La RFC 9537 réduit cette ambiguïté pour les réponses RDAP. Publiée en mars 2024 sur la voie normative de l’IETF, elle définit une extension qui permet au serveur d’indiquer explicitement les champs masqués. James Gould la signe avec David Smith, Jody Kolker et Roger Carney. Le profil IETF de Gould, consulté le 7 septembre 2026, lui attribue treize RFC ; la biographie du comité Registration Operations Workshop le présente comme fellow chez Verisign, chargé de l’orientation technique de services de registre. Ce contexte explique une familiarité avec les frontières entre protocoles et exploitation.

Il ne confère ni paternité exclusive ni autorité sur les mises en œuvre d’autrui.

L’intérêt du texte est précisément de ne pas résoudre tout le dossier. Il donne une syntaxe commune à l’affirmation d’un serveur. Il ne transforme pas cette affirmation en copie certifiée de la donnée qu’il retient.

Ce que relie réellement le membre redacted

Une réponse qui emploie l’extension annonce la valeur redacted dans rdapConformance. L’objet concerné contient normalement un tableau dont chaque élément possède un name obligatoire. Ce nom peut être un type enregistré ou une description libre.

Le chemin apporte la précision structurelle. prePath désigne l’emplacement du champ avant son retrait ; il est donc normal qu’il ne trouve aucun nœud dans le document livré. postPath désigne une valeur vide, partielle ou remplacée qui demeure dans ce document. Les deux ne peuvent coexister dans la même entrée. replacementPath peut pointer vers le champ substitut. JSONPath, normalisé par la RFC 9535, est le langage par défaut.

Cette mécanique autorise une conclusion utile : pour cette réponse, le serveur a qualifié tel champ de masqué selon telle méthode. Elle ne livre pas la valeur antérieure. Elle ne prouve pas que la base détenait une information exacte, que la personne supposée était bien le titulaire ou que le client avait tort d’en demander l’accès. Un chemin est un pointeur dans une structure, pas une attestation sur les faits cachés.

Les registres IANA complètent l’interopérabilité. L’identifiant d’extension, les familles de noms, de motifs et de langages d’expression peuvent être partagés. L’enregistrement évite que chaque client réinvente ses libellés ; il ne certifie pourtant ni une réponse particulière ni la décision qui l’a produite.

Quatre méthodes, quatre traces

Le retrait supprime le champ ou l’objet. C’est la méthode implicite quand method manque, sauf si la position dans un tableau porte une signification. Dans un tableau jCard, une valeur vide permet de conserver la position attendue. Le masquage partiel maintient un fragment d’une valeur formatée. Le remplacement fournit une autre valeur ou un autre champ, par exemple une adresse anonymisée ou un formulaire de contact.

Une interface peut afficher le même badge pour les quatre cas, mais une enquête ne doit pas les confondre. La disparition d’un objet ne se teste pas comme une chaîne vide. Une valeur partielle continue de divulguer une information. Un formulaire de contact maintient une fonction sans devenir l’adresse électronique originelle. La RFC interdit aussi l’emploi d’un remplissage fait de lettres répétées, susceptible de violer le format du champ et de créer un faux signal.

L’unité de conservation est donc la réponse JSON telle qu’elle a été reçue. Une capture d’écran disant « masqué » élimine justement la différence que l’extension a été conçue pour préserver.

Le motif ne rend pas la politique vraie

Une entrée peut comporter un reason, sous forme de type enregistré ou de description destinée au lecteur. La description ne doit pas devenir une dépendance de traitement. Un automate ne peut donc pas transformer une phrase comme « politique du serveur » en décision d’accès stable.

La frontière est tout aussi nette pour la politique publiée. La RFC autorise le serveur à renvoyer vers une politique de masquage, mais laisse son contenu hors spécification. Elle ne tranche pas la validité d’un consentement, la portée d’une juridiction ou le droit d’un demandeur. La RFC 7481 prévoit authentification et accès différencié suivant une politique locale : deux clients peuvent recevoir deux vues valides du même objet.

Le profil RDAP 2024 de l’ICANN illustre le niveau suivant. Pour les gTLD relevant de son champ, il associe des éléments précis à des noms et méthodes de la RFC 9537. Ce profil constitue une preuve importante de l’obligation opérationnelle correspondante ; ce n’est pas une règle universelle de RDAP ni une décision sur une demande individuelle.

Enfin, reconnaître qu’un champ existe peut déjà révéler quelque chose. La RFC permet de taire l’entrée de masquage lorsque ce signal d’existence pose lui-même un problème de confidentialité. L’absence de redacted n’est donc pas une garantie de complétude. Elle doit rester un état indéterminé tant que la capacité du serveur, son profil et le niveau d’accès ne sont pas connus.

Composer le reçu minimal

Le reçu commence par l’URI exacte et la nature de la requête : recherche ou consultation directe. Il conserve le serveur faisant autorité, les redirections, l’heure, l’identité de transport, l’authentification du client et sa classe d’autorisation. Comparer une requête publique à une requête privilégiée sans garder cette différence fabrique une anomalie.

Il faut ensuite garder les octets de la réponse ou leur empreinte, les valeurs de rdapConformance, l’identité de l’objet et chaque nom, méthode, langage, chemin et motif de masquage. Le rapport précise si postPath a trouvé un nœud, comment prePath a été interprété et quelle version du décodeur JSONPath a servi. Si une politique est liée, son URL et sa version observée sont datées : une page modifiée demain n’explique pas rétroactivement la réponse d’hier.

La RFC 9082 distingue consultation et recherche ; dans une recherche, l’extension s’applique à chaque objet. Une limitation globale de résultats n’est pas le retrait d’un champ dans un résultat. Les notices et remarques de la RFC 9083 apportent des explications générales ou liées à l’objet, mais ne remplacent pas le signal structuré par champ.

Avec ce faisceau, la conclusion reste proportionnée : ce serveur, pour cette requête et ce niveau d’accès, a décrit ce champ comme masqué de cette manière. Pour affirmer davantage, il faut joindre le reçu suivant — intégrité de la donnée source, autorité de la politique, habilitation du client ou examen de la divulgation.

Sources