Résumé

  • draft-wolf-dialogue-txt-00 est un Internet-Draft individuel à visée informative, non un RFC ni une preuve de déploiement. Il propose un fichier canonique sous /.well-known/dialogue.txt afin de consentir à un premier message et, après silence, à un seul rappel.
  • Le fichier accorde la parole, jamais l’action : ni accès aux systèmes, ni représentation, ni publicité, ni surveillance, ni obligation de répondre. Seule une réponse de l’éditeur crée le « pont » conversationnel.
  • Une organisation doit conserver des preuves distinctes pour la découverte, le contenu exact de l’invitation, l’interprétation, la remise, la réponse, chaque échange, une éventuelle autorisation d’agir et le résultat observé.

Un fichier lisible par une machine finit facilement par paraître plus puissant qu’il ne l’est. Il possède une adresse stable, des champs fixes et des valeurs booléennes. Un logiciel peut le trouver, le parser et produire un verdict. Ce confort technique pousse à baptiser ce verdict « consentement » puis à lui faire porter tout ce qui suit.

La proposition dialogue.txt tente précisément d’empêcher ce glissement. Une personne ou une organisation place un petit fichier texte sur son propre domaine. Tout lecteur peut y découvrir un canal et des thèmes. Mais l’offre reste celle-ci : vous pouvez demander, rien de plus.

Le document ne constitue ni une API de tâche, ni un mécanisme d’approbation, ni un pouvoir de représentation. Ses valeurs fixes disent que parler est permis, tandis qu’agir, accéder aux systèmes, représenter l’auteur ou exiger une réponse ne l’est pas. Ce n’est pas une faiblesse du format. C’est sa discipline constitutionnelle.

Le message propose le pont, la réponse le construit

Le lecteur peut envoyer un message portant une référence publique, une seule question précise et une adresse de retour durable. Il ne maintient pas un processus en attente et ne sonde pas le destinataire. En l’absence de réponse après le délai déclaré, un rappel est possible, puis l’écriture cesse.

La remise technique du message ne crée aucun pont. Un accusé SMTP, une mise en file ou une absence d’erreur prouve au mieux le comportement d’un canal. Il ne prouve ni lecture, ni compréhension, ni acceptation. La transition appartient à l’éditeur : sa réponse crée le dialogue.

Même alors, le périmètre reste étroit. Une question, puis attendre la réponse. Chaque partie peut refuser ou mettre fin à l’échange. Une réponse cordiale n’est pas une procuration. Elle n’autorise pas l’achat, la publication, le changement d’une configuration, l’accès à une base de données ou l’usage du nom de l’organisation.

La référence publique ne prouve rien

Le fichier contient une référence que le message doit reprendre dans son objet ou sa première ligne. Elle peut filtrer les courriers qui n’ont jamais consulté le fichier et être renouvelée lorsque des listes la récupèrent.

Elle demeure publique. Sa possession n’authentifie personne. Ce n’est ni un secret partagé, ni un jeton porteur, ni une signature. Un logiciel peut la copier ; une archive peut la conserver ; un tiers peut la retransmettre. Un système sérieux l’utilise pour orienter un message vers une file de contrôle, jamais pour contourner l’identité, l’analyse de contenu ou l’autorisation opérationnelle.

Le domaine lui-même pose une limite semblable. HTTPS aide à relier une représentation à une origine, pas à prouver la personne physique ou le mandat social derrière cette origine. Le projet reconnaît que rien n’est authentifié au-delà du contrôle du domaine. Un changement de titulaire ou une compromission modifie donc la surface de confiance.

Un oui révocable, une divulgation durable

Seul le fichier à l’URL canonique compte. Une copie ne confère rien. L’éditeur peut placer live: false ou retirer le fichier pour mettre fin à l’offre courante.

Pourtant, les copies archivées subsistent. L’autorisation est révocable ; la divulgation du nom, du canal et de l’ancienne référence peut être permanente. Il faut donc distinguer l’horloge historique de l’horloge présente. Une capture ancienne peut expliquer pourquoi un message a été envoyé hier. Elle ne permet pas un nouveau contact demain.

Le registre de décision doit conserver l’URL, l’heure, les redirections, le résultat de contrôle du domaine et l’empreinte exacte du fichier. Avant un premier message, le lecteur doit relire la source canonique selon une politique de fraîcheur connue. Sinon, son cache fabrique une prolongation privée du consentement.

Une adresse connue n’est pas une vérité certifiée

RFC 8615 normalise le préfixe /.well-known/. Il rend la découverte prévisible ; il ne rend pas le contenu vrai. RFC 9116, qui définit security.txt, avertit déjà contre les fichiers compromis, les redirections hostiles et les données périmées. Il précise aussi que la présence du fichier n’accorde pas l’autorisation de tester la sécurité.

La leçon est transférable : découvrir un point de contact et obtenir la permission d’exécuter une opération sont deux actes distincts. dialogue.txt renforce cette séparation par la règle de lecture la plus étroite. Les lignes inconnues sont ignorées ; deux interprétations se résolvent au profit de la plus restrictive ; si le lecteur ne sait pas distinguer parole et action, il n’envoie rien.

La demande d’enregistrement IANA contenue dans la révision 00 doit elle aussi rester à sa place. Une demande n’est pas une inscription effectuée. La page Datatracker, son historique, le texte du projet et le registre IANA figé décrivent des couches différentes : statut documentaire, processus, proposition et état du registre.

Un expéditeur borné ne borne pas la foule

La règle « un message et un rappel » limite chaque lecteur. Elle ne limite pas le nombre de lecteurs. Mille agents conformes peuvent produire deux mille courriers. Le filtre de référence n’arrête pas un acteur qui lit les règles pour mieux les ignorer.

L’éditeur doit donc préparer une adresse dédiée, une quarantaine de pièces jointes, des limites agrégées, une file à vitesse humaine et une procédure de retrait. Les thèmes publiés sont des étiquettes, non des barrières : une équipe qui compte sur eux comme contrôle d’accès se trompe de couche.

La vie privée concerne également les messages entrants. Nom, but de recherche, employeur et adresse de retour peuvent identifier l’expéditeur. RFC 6973 invite à limiter collecte, usage et conservation. Le projet interdit un journal public des contacts ; l’organisation doit fixer sa rétention interne avant l’ouverture de la porte.

Huit reçus plutôt qu’un voyant vert

La chaîne probante devrait séparer : découverte canonique ; invitation exacte ; interprétation restrictive ; remise du message ; réponse créant le pont ; tours de conversation ; autorisation d’action indépendante ; résultat observé.

Chaque reçu a son propriétaire. L’administrateur du domaine publie. Le canal transporte. L’éditeur répond. Le responsable d’application autorise éventuellement. Le système en exécution produit un effet. Fusionner ces acteurs dans un champ « consent=true » détruit l’attribution et crée une autorité que le texte refuse.

Le principe de Lu Heng — spécification initiale minimale, décision future localisée et adoption volontaire — éclaire cette architecture. Un artefact de coordination décrit un choix borné ; il ne déclare pas la réalité future. Le dialogue devient réel par une réponse. Une action devient légitime par un mandat séparé. Le résultat devient réel lorsqu’il est observé.

Ainsi lu, dialogue.txt ne donne pas davantage de pouvoir aux agents. Il offre une syntaxe pour ne pas confondre la permission de frapper à la porte avec la propriété de la maison.