Demo Client

An interactive, non-normative client for the two companion URI schemes of draft-li-rttp-iqa-addressing-00. It implements the syntax and the client obligations of the draft: strict ABNF with a lowercase-only canonical form, the ROUTE_SHARD derivation of Section 4.4, the action safety classes of Table 1, the scheme prefix check, and consent that is never silent.

One question, one answer: rttp computes where an intent lives, iqa states whether an organ stands behind it. The three organs on this page are simulated stand-ins — no real organ is contacted, the standing vocabulary shown is a demo placeholder (the normative vocabulary belongs to the reference specification), and nothing here is normative.

1. rttp — the address is derived, not looked up

route_shard = SHA-256(ASCII(canonical_authority))[0:16] — authority only; no scheme, no action.

Obligations applied: uppercase input is rejected, not normalised (4.2); no userinfo, port, query or fragment is accepted (4.2); the derivation uses the authority alone, so different actions on one authority yield the same address — an address is where, not what (4.4).

2. iqa — ask an organ, never mutate

NOT SAFE action (Table 1). Consent, never silence (4.5.3): type the action name to proceed —
The default operation (no action) is a read-only standing read and is safe; dereferencing an iqa URI must not transition any standing state (5.3).

The hexadecimal subject form is a routing hint, not evidence (5.2); the organ set and the action set are closed (5.1).

3. Combined — one question, one answer

The rttp URI is derived; its full SHA-256 digest becomes the iqa subject routing hint (64 lowhex, a valid subject form); the organ answers.

4. Self-test against the draft

The draft’s own seven examples must parse; nine malformed inputs must be rejected; the derivation must be deterministic. Runs entirely in your browser.

Not run yet.