两个方案为什么住在同一份文档里

规范解读 · 第 6 篇 · 引证源：draft-li-rttp-iqa-addressing-00 §1 / §3 / §4.1 / §5.1 · 姊妹柱：rttp://（CRI 27）· iqa://（CRI 28）

读这份文档的人，几乎都会在同一处停下：「两个 URI scheme 为什么写成一份文档？分开不是更标准吗？」答案写在 §1，且不止是工程便利：「两个方案共享一个寻址模型，且被刻意配对：意图寻址承载『声称了什么』，证明承载『声称者是否已验证』。实现与部署应当把它们当作一个模型，而不是两个互不相关的命名空间。」

拆开的方案我们并非没考虑过——早期版本的 intent-addressing 与 subject-attestation 各有独立文稿，合并是应同一寻址模型的不可分割性而为之：§3 列出四条共同性质（计算派生、无查询、URI 是声称不是证明、fail-closed），这四条在 §4 与 §5 中分别对两个 scheme 叙述一遍。若拆成两份文档，这四条就得写两遍，且任何一边的修订都可能让另一边的复述过时——共享模型的单一定义点，正是合并的第一个理由。

第二个理由恰恰相反：合并成文，但坚决不合并语义。两柱的语法闭集截然不同，规范用同样的篇幅强调其差异：rttp 的 action 是开放 token——§4.1 只约束字符集（小写字母、数字、连字符），不设枚举，动作空间完全开放；而 iqa 的 organ 是「三个具名 organ（forge / tss 或 gateway）。这是一个闭集；任何其他值都无效」，action 亦是四个操作名的闭集（verify / audit / attest / revoke），其中仅 verify 与省略形式是 SAFE 级（§5.4）。

这个不对称是刻意的：rttp 回答「声称了什么」（WHERE+WHEN），动作空间必须开放——任何人可以声称任何意图；iqa 回答「是否为真」（WHETHER），担保动作必须收口——谁有权出证明、做什么样的证明，必须闭集枚举。把两者写进一份文档，读者才能在对照中看清这条边界；拆成两份，边界就会在各自的修订史里模糊。合并文档不是偷懒，是防焊死：我们既不许读者把 rttp 的开放动作错当成担保能力，也不许把 iqa 的闭集动作错当成开放接口。

一句话：一份文档，两个 scheme，四条共享性质，两套互不相让的闭集与开放——合住是为了让边界长在同一个页面上，谁也搬不走它。