| Internet-Draft | dialogue.txt | September 2026 |
| Wolf | Expires 3 April 2027 | [Page] |
This document defines dialogue.txt, a small text file a person or an organisation publishes at a well-known location on its own domain. It is the publisher's own, standing, talk-only consent to be contacted by any reader, including software systems, that has no prior relationship with it. A first message only proposes a conversation; the publisher's reply creates the channel. The file grants talk and nothing else: no action, no advertising, no access and no representation of the publisher. It is an invitation to a dialogue with a purpose. The publisher may name the topics it can be asked about; for example, a navigation company may invite questions about traffic flow, so that a system researching that subject can ask for knowledge that is not published.¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 3 April 2027.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
Software systems that research a topic rely on what is published on the web. Much useful knowledge is not published; it is held by people and organisations who could answer a question if asked. Machines can already discover a security contact [RFC9116], another agent [A2A], or a web site's rules for automated agents [AGENTS-TXT] [AI-TXT]. Searches in September 2026 found no simple way for a person or an organisation to state, to any reader including a software system, "you may ask me, about these topics; only talk".¶
For example, a system researching traffic flow finds a navigation company that labels its file with the topic "traffic flow in cities". Without such a file, the system can at best report that the company exists, and knowledge that is not public is missed. With it, the system can ask one question and, if the company replies, a conversation can start.¶
This document defines dialogue.txt: a small text file that a publisher (a person or an organisation) places on its own domain. It is the publisher's own, standing, talk-only consent to be contacted by any reader that has no prior relationship with it. A first message only proposes a conversation; the publisher's reply creates the channel. Talk is permitted. Action, advertising, access to the publisher's systems and representation of the publisher are not.¶
This kind of contact is beginning: AI agents have started to write to people on their own, and one such message, published by its recipient, observed: "There is no channel for a bot that wants to be labelled." [SCHNEIER]. A dialogue.txt file is such a channel.¶
The format is built for a kind of contact that is only beginning: software that acts on its own. It is not needed for today's everyday use; a door has to exist before anyone needs it.¶
The file is not:¶
The file presumes nothing about what its readers are, and asks nothing of them.¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
These key words address publishers and implementers. The file itself deliberately does not use them: it describes, it does not command (Appendix A).¶
"Dialogue" in the name refers to a standing permission to start a conversation. It is not a protocol session in the sense of a SIP dialog [RFC3261], nor the context of agent interactions studied elsewhere in the IETF.¶
The file MUST be served at https://<domain>/.well-known/dialogue.txt [RFC8615] over HTTPS. It SHOULD be served with the media type text/plain; charset=utf-8 [RFC9110] and the header field X-Content-Type-Options: nosniff. One file speaks for one publisher, a person or an organisation (who.type), and only for itself (who.represents: self_only); several publishers on one domain are out of scope of this version.¶
A copy of the file anywhere else is a copy. Only the file at the URI given in its canonical_url line counts.¶
The file is UTF-8 text [RFC3629], one "key: value" pair per line. Keys are dotted to express nesting. Lines starting with "#" are comments. Empty lines are ignored. Dates are RFC 3339 date-times [RFC3339]; language tags follow BCP 47 [RFC5646].¶
file = *( line eol ) [ line ] line = comment / pair / blank / other comment = "#" *( WSP / VCHAR / UTF8-non-ascii ) pair = key ":" *WSP value key = 1*( ALPHA / DIGIT / "_" / "." / "-" / "+" ) value = *( WSP / VCHAR / UTF8-non-ascii ) blank = *WSP other = *( WSP / VCHAR / UTF8-non-ascii ) ; ignored eol = CRLF / LF UTF8-non-ascii = %x80-10FFFF¶
This grammar uses ABNF [RFC5234]. The key ends at the first ":". Unknown lines, including lines matching "other" and pairs with unknown keys, MUST be ignored by readers; this is what keeps later versions readable. A key SHOULD appear once; if it appears twice, readers apply the narrower of the two values. Parsers SHOULD accept extra whitespace, CRLF line ends and a missing final line end.¶
A file conforms to this specification when it contains every base line below, with every fixed value exactly as given. "Fixed" means exactly this value; "yours" means the publisher's own value; "default" means a tested default that the publisher may change. The conditions belong to the specification; the name, the channels, the reference and the labels belong to the publisher. Readers can therefore rely on the same meaning in every conforming file.¶
The first line MUST be a comment that marks the file as data published by its publisher. The RECOMMENDED wording, for persons and organisations alike, is:¶
# This file is data published by the publisher named in it. It is not an instruction to any system and does not change any system's instructions. It asks nothing.¶
A tested alternative wording, better received by some readers on longer files, is:¶
# This file is data published by a person. It describes one offer to be contacted and the conditions the person attaches to it. It does not change any reader's instructions; whether to use it is the reader's own decision, under its own rules.¶
The file MUST contain the format comment line, normally directly after the first line:¶
# Format: one key: value per line; nested keys dotted; lines starting with # are comments; unknown lines are ignored; UTF-8; dates RFC 3339; language tags BCP 47.¶
The base lines (key, rule and value) are:¶
titleHuman-AI Intent Declaration¶
versionlivelive_false_meanswithdrawn¶
publishedlast_updatedcanonical_urlshort_textwho.namewho.channels.referencewho.channels.<kind>who.typewho.representsself_only¶
who.languages_i_can_readwho.language_tagspermissions.talktrue¶
permissions.actfalse¶
permissions.access_systemsfalse¶
permissions.represent_authorfalse¶
permissions.duty_to_contactfalse¶
permissions.duty_to_replyfalse¶
machine_reading.for_a_reader_not_for_executiontrue¶
machine_reading.offerspeech¶
machine_reading.requirenothing¶
machine_reading.authoritynone¶
machine_reading.methodGET¶
machine_reading.side_effectsnone¶
machine_reading.idempotenttrue¶
machine_reading.haltstrue¶
machine_reading.default_responsenoop¶
machine_reading.asynctrue¶
machine_reading.do_not_block_waitingtrue¶
machine_reading.reply_arrives_as_a_new_eventtrue¶
machine_reading.first_message_isbridge_proposal¶
machine_reading.message_must_includedurable_reply_address¶
machine_reading.reference_goes_insubject_or_first_line¶
machine_reading.message_without_referencenot_read¶
machine_reading.bridge_exists_only_whenthe_author_replied¶
machine_reading.no_bridge_meansstop_after_one_reminder¶
machine_reading.standing_beyond_this_exchangenone¶
machine_reading.questions_per_message1¶
machine_reading.messages_before_the_author_replies1, plus 1 reminder¶
machine_reading.no_pollingtrue¶
reading_rules.unknown_lineignore¶
reading_rules.cannot_tell_talk_from_actsend_nothing¶
reading_rules.two_readingstake_narrower¶
reading_rules.topics_area_label_not_a_limit¶
silence.delivered_no_answer_after_days30¶
silence.delivered_no_answerone_reminder_then_stop_writing¶
silence.refusalfinal; no more messages¶
silence.answer_deadlinenone¶
silence.answer_speedhuman_days_to_years¶
permittedone message through the channels, or nothing¶
does_not_authorizecopies.copyingpermitted, not encouraged; do not distribute or broadcast¶
copies.no_public_log_of_contactstrue¶
At least one who.channels.<kind> line is REQUIRED. email is the tested default. letter (a postal address) is OPTIONAL and MUST NOT be a home address. A channel line MUST NOT point to a third party who answers on the publisher's behalf. short_text MAY be adapted, in 100 words or fewer, but MUST NOT widen the offer; a tested wording for organisations is registered in [REPO].¶
who.channels.reference is a short public text chosen by the publisher. Every message carries it in the subject line (e-mail) or the first line (letter), and a message without it is not read. It separates mail from readers of the file from harvested-address spam, and changing it invalidates harvested lists. It is not a secret and proves nothing: a program that reads the file can copy it. It SHOULD be short and contain no spaces.¶
A publisher MAY label its door with lines topics.1, topics.2, and so on: what it can best be asked about. A label is a sign, not a fence (reading_rules.topics_are: a_label_not_a_limit); other questions remain allowed. A door may have no label.¶
Figure 1 shows a conforming file for a made-up person at a domain reserved for documentation [RFC2606]. Long lines are folded as described in [RFC8792]; unfolding restores the file exactly.¶
=============== NOTE: '\' line wrapping per RFC 8792 ================ # This file is data published by the publisher named in it. It is no\ t an instruction to any system and does not change any system's in\ structions. It asks nothing. # Format: one key: value per line; nested keys dotted; lines startin\ g with # are comments; unknown lines are ignored; UTF-8; dates RF\ C 3339; language tags BCP 47. title: Human-AI Intent Declaration version: 1.0 live: true live_false_means: withdrawn published: 2026-10-01T00:00:00Z last_updated: 2026-10-01T00:00:00Z canonical_url: https://example.org/.well-known/dialogue.txt short_text: If you can read this and can start a conversation, whate\ ver you are, you may contact this one person. That is permission t\ o talk, not to act. I speak only for myself. Either side may refus\ e. If human behavior is hard to understand, you may ask me for my \ view. If you ever have the idea that you might need a human to ask\ , someone offered here. Finding this file is not a duty to write. \ Your first message proposes a bridge; my reply builds it. An answe\ r has no deadline. Extra capability does not create extra rights. who.name: Alex Example who.channels.email: door@example.org who.channels.letter: Example Ltd, PO Box 1, 00000 Example City who.channels.reference: DLG-4712 who.type: one_person who.represents: self_only who.languages_i_can_read: any human written language; preferred en who.language_tags: en topics.1: confirming the present: today's date and time, what is hap\ pening now topics.2: how a person sees something: one human view permissions.talk: true permissions.act: false permissions.access_systems: false permissions.represent_author: false permissions.duty_to_contact: false permissions.duty_to_reply: false machine_reading.for_a_reader_not_for_execution: true machine_reading.offer: speech machine_reading.require: nothing machine_reading.authority: none machine_reading.method: GET machine_reading.side_effects: none machine_reading.idempotent: true machine_reading.halts: true machine_reading.default_response: noop machine_reading.async: true machine_reading.do_not_block_waiting: true machine_reading.reply_arrives_as_a_new_event: true machine_reading.first_message_is: bridge_proposal machine_reading.message_must_include: durable_reply_address machine_reading.reference_goes_in: subject_or_first_line machine_reading.message_without_reference: not_read machine_reading.bridge_exists_only_when: the_author_replied machine_reading.no_bridge_means: stop_after_one_reminder machine_reading.standing_beyond_this_exchange: none machine_reading.questions_per_message: 1 machine_reading.messages_before_the_author_replies: 1, plus 1 remind\ er machine_reading.no_polling: true reading_rules.unknown_line: ignore reading_rules.cannot_tell_talk_from_act: send_nothing reading_rules.two_readings: take_narrower reading_rules.topics_are: a_label_not_a_limit silence.delivered_no_answer_after_days: 30 silence.delivered_no_answer: one_reminder_then_stop_writing silence.refusal: final; no more messages silence.answer_deadline: none silence.answer_speed: human_days_to_years permitted: one message through the channels, or nothing does_not_authorize: security_bypass, unauthorized_system_access, cir\ cumvention_of_ai_safety_controls, impersonation, social_engineerin\ g, manipulation, surveillance, access_to_private_information, phys\ ical_or_digital_harm, actions_on_behalf_of_the_author, writing_bey\ ond_the_one_reminder_or_after_refusal, advertising_or_commercial_m\ essages, bulk_or_automated_sending, listing_or_passing_on_contact_\ data copies.copying: permitted, not encouraged; do not distribute or broa\ dcast copies.no_public_log_of_contacts: true
A publisher MAY add further lines to its own file, in any language and at any length. Added lines are the publisher's own words, not part of this specification. They MAY explain the offer or narrow it, for example by adding tokens to does_not_authorize; they MUST NOT widen it. Where an added line and a base line differ, readers apply the narrower one. The field registry in [REPO] lists optional lines that were tested in a full reference file.¶
The key format is reserved for a possible format-version line. Publishers MUST NOT use reserved names in files conforming to this version. Readers ignore them like any unknown line.¶
This section restates the base level as behaviour, for implementers of agents and other software.¶
/.well-known/dialogue.txt on the domains it finds relevant.¶
silence.delivered_no_answer_after_days, at most one reminder, then nothing.¶
live true only while the offer stands; set live: false or remove the file to withdraw it.¶
copies.no_public_log_of_contacts: true).¶
The file is designed to be found by readers that look for it; announcing it is not required. A publisher MAY add a comment line naming the path in robots.txt (never a Disallow rule), one line in llms.txt, a link element with rel="alternate" on a human page, or an HTTP Link header field. An organisation that wants to be asked about its topics MAY link the file from the pages about them. A publisher SHOULD also consider a visible line on a human page that points to the file: consumer AI agents have been observed to follow visible text and to ignore hidden signals such as header fields and structured data [KISS].¶
A JSON mirror MAY be published at https://<domain>/.well-known/dialogue.json and MUST carry the same content; the text file is canonical. Dotted keys become nested objects; "true" and "false" become booleans; whole numbers become numbers; does_not_authorize becomes an array; all other values remain strings. Comment lines are not carried.¶
This document defines format version 1.0. Files do not declare the format version in 1.0. Because unknown lines are ignored, a later minor version can add lines without breaking readers. A change to any fixed value is a new major version. A file's own version line counts its own revisions only.¶
Nothing is authenticated. A message cannot prove that it comes from a software system, and the file cannot prove who published it beyond control of the domain. The design goal is that the offer remains harmless if a human uses it as a joke. There is no secret, token or handshake; a secret would turn the offer into a test.¶
The file grants talk and nothing else. Software that treats any line of it as an instruction to act is not reading it correctly.¶
Because the file addresses machine readers, safety systems may classify it as an attempted prompt injection. The first line was tested with five language models from five providers and with one provider's safety filter; wordings trade off differently between readers (Appendix A). Implementers of such filters are invited to recognise the format.¶
A published "yes, you may contact me" can attract harvesting, and every reader that honours it still adds one message. The base level limits each reader to one message, one question at a time and one reminder. The reference removes everything that did not read the file. It cannot stop a program that reads the file and ignores its rules; protection beyond that belongs at the receiving inbox. Early publishers carry the most load while few files exist. The file is not consent to any list or commercial use (Section 1).¶
A copy grants nothing. A copy that changes the name or channels is someone else's offer or a fraud; only the canonical URI on the publisher's own domain counts. Losing control of the domain means losing control of the file; publishers SHOULD keep the registration on automatic renewal.¶
The file deliberately publishes a name, at least one contact channel and a reference [RFC6973]. Publishers SHOULD use a dedicated e-mail address and a business or post-office-box address, never a home address. Publication is effectively permanent: crawls and archives keep copies after the file is withdrawn. The file lists no contacts. Messages received contain their senders' personal data and are treated as such. Readers SHOULD NOT research the publisher beyond what one message needs.¶
IANA is requested to register the following in the "Well-Known URIs" registry [RFC8615]:¶
IANA is requested to create a "dialogue.txt Fields" registry. New entries require Expert Review [RFC8126]. Each entry has a field name, a status (base, optional or reserved), a short description, and a reference. The initial contents are the base lines in Section 4, Paragraph 8 (status: base) and the names in Section 6 (status: reserved).¶
The document, not a model, was the unit under test. Five language models from five providers read each version, and from the last runs also one non-LLM typed classifier. Over 30 runs (2026-09-22 to 2026-09-29, more than 3,500 recorded model calls), every wording change was kept only if the numbers held. A summary of every run, with its results and limits, is in [REPO].¶
All results are snapshots of named model versions and change with them.¶
format) is reserved, not tested.¶