Why two schemes live in one document

Reading the Draft · No. 6 · Source: draft-li-rttp-iqa-addressing-00 §1 / §3 / §4.1 / §5.1 · Sister pillars: rttp:// (CRI 27) · iqa:// (CRI 28)

After the merged document was submitted, we expected the first batch of review questions to include this one: "Why are two URI schemes written as one document? Wouldn't separate documents be more standard?" The answer is in Section 1, and it is more than engineering convenience: "The two schemes share one addressing model and are deliberately paired: intent addressing carries what is claimed, attestation carries whether the claimant is verified. Implementations and deployments should treat them as one model rather than as two unrelated namespaces."

We did consider separate documents — early versions of intent-addressing and subject-attestation each had independent drafts, and the merge followed from the indivisibility of one addressing model: Section 3 states four shared properties (derived by computation, no lookup, URI as claim not proof, fail-closed), and Sections 4 and 5 then state them separately for each scheme. Split documents would have to state those four twice, and any revision on one side could silently obsolete the other's restatement — a single definition point for the shared model is the first reason for the merge.

The second reason is the opposite: merge the document, but refuse to merge the semantics. The two pillars' grammatical closed sets are deliberately different, and the specification spends equal care on the difference. The rttp action is an open token — Section 4.1 constrains only the character set (lowercase letters, digits, hyphens) with no enumeration; the action space is fully open. The iqa organ, by contrast, is "one of the three organ names, forge, tss or gateway. This is a closed set; no other value is valid," and the action is likewise a closed set of four operation names (verify / audit / attest / revoke), of which only verify and the omitted form are SAFE-class (Section 5.4).

The asymmetry is intentional: rttp answers "what is claimed" (WHERE+WHEN), and the action space must stay open — anyone may claim any intent; iqa answers "whether it is true" (WHETHER), and the vouching actions must be closed — who may issue proofs, and what proofs they may issue, must be enumerated as a closed set. Putting both into one document lets the reader see this boundary by contrast; splitting them lets the boundary blur inside each document's separate revision history. The merged document is not laziness — it is a welding guard: we neither allow readers to mistake rttp's open actions for vouching power, nor iqa's closed actions for an open interface.

One line: one document, two schemes, four shared properties, and two grammars that will not yield to each other — the closed and the open live together so the boundary lives on the same page, where no revision history can carry it away.