Summary

  • draft-wolf-dialogue-txt-00 proposes a canonical /.well-known/dialogue.txt through which a person or organisation can invite any reader to send one first message and, after silence, one reminder. It is an individual Informational Internet-Draft, not an RFC, an allocated standard or deployment evidence.
  • The grant is deliberately tiny: talk is true; action, system access, representation, advertising, surveillance and any duty to reply are false. Delivery does not create a conversation. Only the publisher's reply creates the bridge.
  • Operators should retain separate receipts for discovery, exact invitation bytes, interpretation, message delivery, publisher reply, later turns, any independent action authorisation and the observed outcome. Joining those records into one “consent” state would recreate the authority the file expressly refuses.

There is a peculiar temptation in machine-readable policy. Once a system can find a statement, parse it and attach a green result to it, the statement begins to look like power.

The new individual Internet-Draft draft-wolf-dialogue-txt-00 is interesting because it tries to resist that temptation from inside the format. It proposes a plain-text file at a well-known HTTPS location. A person or organisation publishes it on its own domain. Any reader, including software with no prior relationship, may discover it and ask about a named topic. Yet the document repeats one boundary in almost every possible form: this is permission to talk and nothing else.

That sounds modest because it is. The draft does not define a task protocol, an approval endpoint or an agent credential. It does not let a machine represent the publisher. It does not permit access to systems or private data. It does not turn a topic label into a work order. It is an invitation to attempt a conversation.

That distinction could become unusually important if autonomous research systems begin contacting organisations whose knowledge is not already on the web. A public door may make hidden expertise discoverable. But the same door can become a consent-laundering device if product designers compress discovery, delivery, reply, instruction and execution into a single flag.

The first message creates no bridge

The proposed state machine is sharper than the word “contact” suggests. A reader may send one message through a listed channel. The message must carry a public reference in its subject or first line, ask about one specific thing and include a reply address that will still work after the reader's own process ends. The reader does not poll. If there is no answer after the publisher's declared interval, it may send one reminder and then must stop.

None of that creates the bridge. The draft assigns that transition only to the publisher's reply.

This gives an evidence designer a clean separation. Retrieval proves that one representation was served from one canonical URL at one time. A mail server's acceptance can show that a message entered a channel. Neither event establishes that the publisher read it, understood it, accepted the proposed purpose or wanted a continuing exchange. Silence is not an asynchronous approval. It remains silence.

Once the publisher replies, a narrow conversation begins: one question per message, with the next question waiting for the answer. Either side may refuse or end it. The reply creates conversational standing, not standing authority. A helpful answer does not entitle the reader to buy, publish, deploy, transfer, access or act on the publisher's behalf.

A public reference is a filter, not a credential

The file includes a publisher-chosen reference. Messages lacking it are not read. Changing it can invalidate harvested address lists. This may reduce noise from senders that never saw the current file.

But the draft is explicit: the reference is public and proves nothing. Any program able to read the file can copy it. It is not a shared secret, bearer token, signature, identity proof or capability.

That is an excellent operational warning. Many systems promote possession of a value into authorization because possession is easy to test. Here possession proves only that the sender obtained the value somewhere. Even that conclusion is uncertain because copies can circulate. A reference match may route a message into a review queue. It cannot bypass identity checks, content screening, rate limits or later action controls.

The same narrow reading applies to the domain. The draft says nothing is authenticated beyond control of the domain. HTTPS can help a reader retrieve bytes from the expected origin. It cannot prove that the named human wrote them, that a corporate officer approved them, or that the domain remains under the same ownership as yesterday. Losing the domain means losing control of the current invitation.

Canonical now, permanent elsewhere

Only the file at its declared canonical URL counts. A copied file grants nothing. That rule protects the current permission surface from mirrors, screenshots and modified versions.

It does not make the information disappear. The privacy section acknowledges that crawlers and archives can preserve copies after live: false or removal. The invitation is revocable at the canonical location but publication is effectively permanent as disclosure.

This creates two clocks. The historical clock answers what a reasonable reader could have observed when it sent a message. The current clock answers whether a new first contact is allowed now. An archived live: true file can support an audit of an old decision; it cannot revive an invitation that the current canonical source has withdrawn.

Systems therefore need to retain the exact bytes or a cryptographic hash, retrieval time, URL, redirect chain and relevant transport result used for each decision. They also need a re-fetch policy. A cached yes with no expiry discipline becomes a private extension of consent.

Discovery is not truth

The /.well-known/ convention from RFC 8615 gives applications a predictable place to look for origin-wide metadata. Predictability solves discovery. It does not certify the truth of what is found.

RFC 9116 supplies a useful comparison. security.txt helps researchers find vulnerability-reporting contacts, yet its security analysis warns about compromised files, malicious redirects, stale information and scope. It also says the presence or absence of the file does not itself grant or deny permission for security testing. A contact path and permission to perform an act are different objects.

dialogue.txt takes that separation further. Its fixed fields say talk true, act false, access false and representation false. Unknown lines are ignored. If two readings exist, the narrower one wins. If a reader cannot tell talk from action, it sends nothing. Those rules make the file less ambitious and therefore more defensible.

The draft also asks IANA to register dialogue.txt and dialogue.json. At the time of this research, that request remains part of revision 00. A request in a draft is not an allocation. The Datatracker record, history and frozen IANA registry must be read separately. Publication status, registry state, implementation and adoption are distinct receipts.

One invitation can still create a load problem

A bounded sender is not a bounded population. If ten thousand conforming readers each send one message and one reminder, the publisher receives twenty thousand messages. Early adopters may bear more load because few domains publish the file.

The public reference can filter obvious non-readers but cannot stop readers that ignore the rules. Protection beyond the declared behaviour belongs at the inbox: dedicated addresses, queues, malware filtering, sender reputation, content isolation, per-domain and aggregate rate limits, and human-speed review.

There is also a selection problem. Topics are labels, not fences. A publisher may say what it can best answer, but other questions remain allowed under the base proposal. Organisations should not publish a broad invitation if the receiving team assumes topic labels will function as enforcement.

The privacy risk runs in both directions. The publisher exposes a name and channel. The incoming message may expose a sender, organisation, research purpose and durable reply endpoint. RFC 6973 treats data minimisation and user participation as design questions, not decorations. A contact system should collect only what one message requires, avoid public contact logs and define retention before the first unsolicited machine message arrives.

Build an evidence chain, not a consent flag

The operating model should use at least eight records.

Receipt Minimum evidence What it does not prove
Discovery URL, time, redirects, TLS/domain result Publisher identity or current legal authority
Invitation Exact bytes/hash, live, version, reference, channel Delivery, reply or permission to act
Interpretation Parser, duplicate handling, narrow reading That the publisher agrees with the reader's purpose
Delivery Message hash, one-question scope, reference, channel acceptance Reading, understanding or bridge creation
Bridge Exact publisher reply linked to the proposal General representation or action authority
Turn Ordered question, answer, refusal or end event Truth or completeness of the answer
Action authority Separate principal, scope, credential and expiry Successful execution or outcome
Outcome Named system observation or business result That earlier policy was legitimate for other cases

This is not bureaucratic duplication. Each row changes under a different actor and clock. The web administrator controls publication. The mail system controls delivery. The publisher controls reply. An application owner controls an operation. The running system produces the outcome.

Lu Heng's doctrine of Minimum Initial Specification, Localized Future Decision and Voluntary Adoption offers the right lens. A coordination artifact should contain only the common structure necessary to make a narrow choice intelligible. Later reality comes from participants that actually reply, adopt, authorize and run something. Publication alone should not declare the future into existence.

dialogue.txt is strongest when read in exactly that restrained way. It can make asking possible without making obedience implicit. It can expose a door without creating a gatekeeper. Its value is not that it gives agents more power. Its value is that it shows how little power a discoverable permission needs to contain.