AICENT-002 -- the rttp URI scheme V1.2.8 reading ======================================================================== SCOPE This is the V1.2.8 reading of AICENT-002, aligned with the 1.2.8 packages and with the Aicent Stack narrative (v1.3.0). It states what the "rttp" URI scheme is and what a client must do with it, and nothing else. The normative specification is the Internet-Draft cited at the end of this file; where this text and that document differ, the document governs. WHAT THE SCHEME IS An rttp URI names a claim of intent directed at an identified subject. The address of that subject is derived by computation from the URI authority. No lookup service, registry, or name-resolution system is consulted at resolution time. The URI is an entry fingerprint. It is not a locator to be resolved. ADDRESS FORM rttp://../ intent either eight lowercase hexadecimal digits, or a readable label pillar operator-chosen label; the processing layer root operator-chosen label; the operator action an optional verb on the intent A URI can also be reached from a web page through the prefix that browsers reserve for external protocol handlers: web+rttp://../ Both forms carry the same authority, the same path and the same derived routing label. They are not two schemes. ROUTING LABEL The routing label (the route shard) is a 16-byte value derived from the canonical authority. The same authority always yields the same route shard. Resolution is a computation, not a query: no DNS, no TTL and no registry lookup on the resolution path. CLIENT REQUIREMENTS A client that handles an rttp URI MUST NOT perform a lookup in order to use it. It MUST treat the URI as a claim of intent, not as a proof about the subject. It MUST NOT render an rttp URI as an IRI. It MUST NOT acquire the ability to handle rttp URIs without an explicit action by the user. It MUST reject any input whose scheme is neither rttp nor web+rttp. Handling an rttp URI is not by itself a statement about the safety of the operation that the URI names. REGISTRATION STATUS Scheme: rttp Status: registered -- Provisional (2026-09-22) CRI scheme number: 27 (assigned on the CRI designated expert's approval; the 0-999 band is Expert Review) Request ticket: [IANA #1459939] Change controller: RTTP.COM Organization Contact: ShaoBao Li The registry entry currently cites the earlier single-scheme draft. Should the combined document be approved for publication as an RFC, IANA is requested to point the registry entry at that RFC. CONFORMANCE A published set of deterministic conformance vectors accompanies this scheme, replayed by independent implementations that share no code. Agreement between implementations is a statement about parsing only, and no performance property is claimed. The 1.2.8 packages carry the expanded self-test suite and no protocol change relative to earlier releases. Asserted counts, re-asserted by CI on every push against the published artifacts: Package | Asserted checks PyPI `rttp` 1.2.8 (default install) | 80 (3 skipped) PyPI `rttp[ed25519]` 1.2.8 | 83 npm `@aicent/rttp` 1.2.8 | 35 crates.io `rttp` 1.2.8-alpha (default) | 37 (1 skipped) crates.io `rttp` 1.2.8-alpha, `ed25519` feature | 38 Published vectors: 35 (6 positive + 15 negative + 3 frames + 9 + 1 + envelope). Core dependencies of the default builds: 0 (SHA-256 written in-crate, known-answer tested against the NIST vectors). The conformance challenge at https://iqa.org/challenge/ accepts independent implementations in any language. SPECIFICATION The two companion schemes are now specified in one combined document: draft-li-rttp-iqa-addressing-00 https://datatracker.ietf.org/doc/draft-li-rttp-iqa-addressing/ OTHER READING The Aicent Stack narrative (v1.3.0) is preserved, unchanged, at: https://rttp.com/AICENT-002/source-v1.3.0.txt The previous reading (V1.2.6) remains available at: https://rttp.com/AICENT-002/source.txt (C) 2026 RTTP.COM Organization