Document Center
Every public document of the two companion URI schemes, current first. The normative specification is the combined Internet-Draft; the plain-text readings are distilled views of it; the Aicent Stack narrative is preserved unchanged and is explicitly non-normative. A live demo client runs the syntax, the derivation, the action safety classes and the AE-128 envelope in your browser.
PulseHeader128 carrying timestamp, sequence and TTL), iqa states WHETHER
(a 128-byte AE-128 envelope). Hover any field for what it does; click to pin the note.
The same 16-byte intent shard — one derivation of the
authority, carried at offset 0x36 in the question and at offset 16 in the answer —
is the seam where question and answer lock together — where the two agree, action begins.
Engineering rationale — why two fixed 128-byte frames (click to expand)
I. Symmetric fixed-length frames — the full optimum for constrained devices.
1 · Static memory, zero heap allocation. Ask 128, answer 128 — a node allocates two fixed buffers at compile time; the hot path has no variable-length parsing, no TLV walking, no malloc. On MCU-class devices "no heap" directly means no fragmentation, no leak surface, predictable real-time behavior. This is the engineering delivery of the zero-parser claim: verification needs only the SHA-256/HMAC primitives plus fixed-offset reads.
2 · One review technique, two carriers. Both frames are fixed-layout, so reading them uses the same trivial method — constant offsets and hash primitives — and each reader can be audited in isolation. The carriers remain independent codecs (the specification requires that they do not parse each other); what is shared is the discipline, and that is what keeps every audit small.
3 · Fixed length → constant-time-friendly. The MAC comparison runs over a fixed layout with no variable-length loops, shrinking the side-channel surface; fields are O(1) reads — standing at offset 80 is an array index, not a "parse then extract". The validator is also total: every 128-byte input is either accepted or rejected whole, never partially parsed, and the rule set is small enough to reason about exhaustively, rule by rule.
4 · 128 is backed by hard constraints. A power of two (aligned allocation) and exactly two cache lines; above all, one datagram, no fragmentation: 128 bytes plus roughly 60 bytes of IPv6/UDP/CoAP header overhead fits comfortably inside the 1280-byte minimum MTU — fragmentation means reassembly buffers, reassembly means heap, and heap is a death sentence on constrained nodes. The upgrade runway is proven, not promised: the pulse frame tail (0x66–0x7F) went from zero bytes to the v1.2.6 extension block without changing the total length, and AE-128 reserves its own zero bytes (reserved + extension) for the same future.
II. The shared shard — the cryptographic handshake of the Q&A.
The amber link on the map is the most valuable stroke: the intent_shard at 0x36 in the question and at 16 in the answer are the same 16 bytes. Three engineering layers:
1 · One round trip. Addressing (WHERE + WHEN) and standing (WHETHER) ride the same exchange: one question, one answer — one round trip does what used to take two. On duty-cycle-powered LPWAN links, round trips are the dearest resource.
2 · The answer is bound to its subject. The MAC covers the intent_shard, so an answer cannot be re-targeted: swap in another subject’s shard and the bytes no longer authenticate — fail-closed. Freshness is carried separately, by the lease and the organ’s per-verdict nonce.
3 · From document pairing to byte pairing. "One datagram carries WHERE, WHEN and WHETHER" is no longer prose: two 128-byte frames sharing one constant is the physical implementation.
III. What is saved, against current practice.
| Carrier | Size | Parser required |
|---|---|---|
| JSON envelope (the original AE route) | hundreds of bytes | JSON parser + field walking |
| CBOR encoding | compact | CBOR decoder (TLV logic) |
| AE-128 / PulseHeader128 | 128 bytes each, capped | none — fixed offsets + hash primitives only |
1. The Internet-Drafts — normative, newest first
Four documents have been submitted to the IETF for the two schemes. The combined Internet-Draft is the normative one and is in the Independent Submission Editor's stream ("Submission Received", Informational); the three earlier single-scheme drafts are superseded and remain archived.
| Date | Document | Status | HTML |
|---|---|---|---|
| 2026-09-24 | draft-li-rttp-iqa-addressing-00The rttp and iqa URI Schemes: Derived-Address Intent and Attestation Addressing — 16 pages |
current — Independent Submission, Informational; ISE state "Submission Received" | HTML |
| 2026-09-20 | draft-li-rttp-intent-addressing-01Intent Addressing in the rttp URI Scheme |
superseded by the combined draft | HTML |
| 2026-09-20 | draft-li-iqa-subject-attestation-00Subject Attestation in the iqa URI Scheme |
superseded by the combined draft | HTML |
| 2026-09-19 | draft-li-rttp-intent-addressing-00Intent Addressing in the rttp URI Scheme |
superseded by draft-li-rttp-intent-addressing-01 |
HTML |
Other views of the current draft: plain text · XML (source of all views) · datatracker (series — follows the latest revision)
2. rttp — readings and narrative (rttp.com/AICENT-002/)
- Scheme text, V1.2.8 reading (current) — source-v1.2.8.txt — distilled from the combined Internet-Draft; normative content unchanged from V1.2.6.
- Aicent Stack narrative (v1.3.0, non-normative) — source-v1.3.0.txt
- Archived reading (V1.2.6) — source.txt
- URI reference and releases: rttp.com/URI/
3. iqa — readings and narrative (iqa.org/AICENT-009/)
- Scheme text, V1.2.10 reading (current) — source-v1.2.10.txt — adds the four-state standing vocabulary (sec. 11.1.1, normative since v1.2.9) and the current registration status.
- AE-128 companion draft (v0.3) — the fixed 128-byte attestation
envelope (magic
IQAE, HMAC-SHA256 over the whole frame): ae128-draft-v0.3.md — implemented in the 1.3.1 packages (Pythoniqa.envelope, JS@aicent/iqa/envelope, Rustiqa_org::envelope), pinned byae128-vectors-v1.json(sha256 ceff2d11…). Roadmap artifact of the specification line; not part of the Internet-Draft. - Archived reading (V1.2.8) — source-v1.2.8.txt — adds the current registration status and the 1.2.8 conformance counts.
- Aicent Stack narrative (v1.3.0, non-normative) — source.txt
- Archived reading (V1.2.6) — the version the published conformance vectors cite (SPEC/IQA-URI-ATTEST v1.2.6): source-v1.2.6.txt
- URI reference and releases: iqa.org/URI/ · frozen snapshots: v1.3.1 · v1.2.8
4. Published packages — 1.3.1
| Scheme | PyPI | npm | crates.io |
|---|---|---|---|
rttp |
rttp 1.3.1 | @aicent/rttp 1.3.1 | rttp 1.3.1 |
iqa |
iqa-org 1.3.1 | @aicent/iqa 1.3.1 | iqa-org 1.3.1 |
The 1.2.8 wave (crates.io pre-release 1.2.8-alpha) remains published, is not yanked, and is archived in the public record. 1.3.1 is the first formal (non-pre-release) crates.io publication; the four registries, the GitHub organizations and the sites all carry 1.3.1 as of 2026-10-05.
5. See also
- Public record — the dated, verifiable history
- Conformance challenge — implement the schemes from the specification alone; the scoreboard is public
- Homepages: rttp.com · iqa.org · Sources: github.com/Aicent-Stack