要約

  • draft-wolf-dialogue-txt-00 は個人提出の Informational Internet-Draft であり、RFC、IANA 登録済み標準、実装・普及の証拠ではない。/.well-known/dialogue.txt に、最初の一通と無応答後の一度の再通知を許す正規ファイルを置く案である。
  • 許されるのは会話だけだ。行動、システムアクセス、代理、広告、監視、返答義務は明示的に否定される。配送では橋はできず、公開者の返答だけが対話の橋を作る。
  • 発見、招待の原文、解釈、配送、返答、各ターン、別個の行動承認、実際の結果を独立した証跡として残す必要がある。

機械可読な許可は、実際より強く見える。固定フィールドを解析し、真偽値を得れば、画面には緑の印が出る。やがてその印が、当初の一動作ではなく、その後のすべてを正当化する「同意」に化ける。

dialogue.txt の提案は、この膨張を形式の内側から抑えようとしている。個人または組織が、自らのドメインに小さなテキストを公開する。未知の読者は連絡先と話題を見つけ、質問できる。しかし、そこで与えられるのは話す許可だけである。

タスク API でも承認窓口でもない。公開者は自分自身だけを代表する。読むことに副作用はない。能力が増えても権利は増えない。会話と行動の区別がつかない読者は、何も送らない。狭さこそが安全性である。

最初の一通は橋の提案にすぎない

読者は、公開参照値を件名か冒頭に入れ、一つの具体的な質問と永続する返信先を添えて送る。プロセスを待機させず、ポーリングもしない。指定日数を過ぎても返答がなければ一度だけ再通知し、その後は止まる。

メールサーバーが受理した事実は、経路の一部がデータを受け取ったことしか示さない。本人が読んだ、理解した、目的を受け入れた、とは言えない。沈黙も承認ではない。公開者自身の返答が届いた時にだけ、草案のいう bridge が成立する。

橋ができても権限は広がらない。一通に一問、回答を待って次へ進む。どちらも拒否・終了できる。丁寧な返答は、購入、設定変更、公開、システム操作、代理行為を認める委任状ではない。

公開参照値は認証情報ではない

参照値は、現行ファイルを読まなかった大量メールをフィルタリングする助けになる。採取され始めれば変更できる。しかし値は公開されており、秘密ではない。

値を持つことは、送信者の身元も、現行版を読んだことも証明しない。署名、共有秘密、能力トークンの代わりにはならない。分類の手掛かりには使えても、本人確認、内容検査、レート制限、行動承認を迂回させてはならない。

ドメインも自然人や法人権限の証明ではない。HTTPS は期待したオリジンから表現を取得する助けになるが、文面を書いた人物や社内承認までは示さない。草案自身が、ドメイン支配以上は認証しないと認める。侵害、失効、譲渡は招待の支配者を変える。

正規ファイルは撤回できても、公開履歴は消えない

効力を持つのは、公開者のドメインにある canonical_url のファイルだけである。複製は何も許さない。live: false または削除によって、新しい連絡への招待は撤回できる。

一方、クローラーやアーカイブは氏名、連絡先、古い参照値を残す。許可は撤回可能でも、開示は実質的に永続し得る。古いコピーは過去の送信判断を説明できるが、現在の新規連絡を許可し直すことはできない。

したがって判断時の URL、時刻、リダイレクト、ドメイン検証、正確なバイト列またはハッシュ、パーサー版を保存する。新しい初回連絡の前には、定めた鮮度規則で正規源を再取得する。期限のないキャッシュは、読者が勝手に許可期間を延長する仕組みになる。

well-known は「見つかる」を意味する

RFC 8615 は /.well-known/ の場所を定める。発見を標準化するが、内容の真実性や権限は保証しない。RFC 9116 の security.txt は、侵害されたファイル、悪意あるリダイレクト、古い情報を警告し、ファイルの存在がセキュリティ試験の許可にならないと述べる。

連絡先を知ることと、行為を許されることは別である。dialogue.txt は talk を true、act、access_systems、represent_author を false とする。未知行は無視し、二つの解釈があれば狭い方を採る。追加フィールドは条件を狭められるが広げられない。

revision 00 にある IANA 登録要求も、まだ要求である。Datatracker の状態、履歴、草案本文、IANA レジストリのスナップショット、実装状況は別々に読むべき証拠である。

一人あたりの制限は全体負荷を制限しない

一読者が一通と一度の再通知に従っても、一万人なら二万通になる。参照値は無知な送信者を減らせても、規則を読んで破る相手を止めない。

公開者には専用受信箱、添付隔離、総量制限、人間の速度に合わせたキュー、迅速な撤回手順が要る。話題は看板でありアクセス制御ではない。限られた質問しか処理できない組織は、ラベルだけに執行を期待してはならない。

受信側にも個人データがある。質問者の氏名、所属、調査目的、永続返信先が含まれ得る。RFC 6973 のデータ最小化に従い、一問に必要な情報だけを扱い、公開の連絡記録を作らず、内部保存期限を事前に決めるべきだ。

単一の「同意」ではなく遷移の台帳

必要なのは、正規源の発見、招待原文、狭い解釈、メッセージ配送、橋を作った返答、会話ターン、独立した行動承認、観測結果の八つである。

各記録の支配者は異なる。ウェブ管理者は公開を、通信システムは配送を、公開者は返答を、アプリケーション責任者は操作を、実行中のシステムは結果を支配する。これらを一つの緑ランプにまとめれば、責任主体と時刻が失われる。

Lu Heng の最小初期仕様・将来判断の局所化・自発的採用という考え方は、ここでも有効だ。共有成果物は狭い共通条件を記述する。将来の現実は、当事者が返答し、採用し、承認し、実行した時に生じる。公開しただけでは未来を命令できない。

dialogue.txt の価値は、機械の権限を増やすことではない。見つけられる許可の中に、権限が終わる場所を明記することにある。