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.

The question and the answer as 128-byte frames rttp PulseHeader128 and the iqa AE-128 envelope are both fixed 128-byte frames sharing the same 16-byte intent shard. rttp · PulseHeader128 — the question (WHERE + WHEN) · VERSION_ID 130 128 B fixed header · timestamp · seq · TTL AID origin (32 B) SPEC_REV + ACTION 0 0x36=54 0x66=102 128 Same 16 bytes · rttp ROUTE_SHARD = iqa intent_shard offset 0x36 ↔ 16 iqa · AE-128 envelope — the answer (WHETHER) · HMAC-SHA256 full-frame 128 B fixed IQAE remaining fields (whole frame MAC-authenticated) 0 16 80 128 offset 80 · standing closed 4-state set · O(1) read question frame answer frame shared shard (16 B) zero / padding
The two pillars on the wire: rttp resolves WHERE and WHEN (a 128-byte 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.

CarrierSizeParser required
JSON envelope (the original AE route)hundreds of bytesJSON parser + field walking
CBOR encodingcompactCBOR decoder (TLV logic)
AE-128 / PulseHeader128128 bytes each, cappednone — 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.

DateDocumentStatusHTML
2026-09-24 draft-li-rttp-iqa-addressing-00
The 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-01
Intent Addressing in the rttp URI Scheme
superseded by the combined draft HTML
2026-09-20 draft-li-iqa-subject-attestation-00
Subject Attestation in the iqa URI Scheme
superseded by the combined draft HTML
2026-09-19 draft-li-rttp-intent-addressing-00
Intent 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/)

3. iqa — readings and narrative (iqa.org/AICENT-009/)

4. Published packages — 1.3.1

SchemePyPInpmcrates.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