Names, once

Naming and disambiguation

Both scheme names expand to something specific. They expand to those things everywhere we write them, including here — the point of a Naming note is that it does not drift.

RTTP

RTTP = Resonant Time Transfer Protocol.

It is not RTP. RTP is the Real-time Transport Protocol of RFC 3550; it carries media streams. RTTP carries intent addressing: WHERE you mean, and WHEN the claim stands.

IQA

IQA = Identity Quality Assurance — the Internet-Draft's own Naming note.

Not Intent-Quality Attestation.
Not the Institute of Quality Assurance.
Not Image Quality Assessment.

IQA answers WHETHER: standing attestations sealed into 128-byte envelopes, fail-closed, offline-verifiable. Sister site: iqa.org.

Which one answers what

Question	Answer
WHERE, WHEN	`rttp://` — derived intent addressing under a real-time constraint. No DNS, no registry, no lookup service.
WHETHER	`iqa://` — standing proof sealed into 128-byte envelopes, offline verifiable.
Not answered by either	WHO answers when something goes wrong, and WHAT the trust is worth. Those are matters of law and of the rest of the stack.

Scheme names are lowercase in URIs: rttp://, iqa://. Uppercase is used only when writing the expanded names.

Anticipated Objections

Q1 · What is RTTP? · click to expand

RTTP denotes Resonant Time Transfer Protocol — the addressing pillar. An rttp:// URI names an intent against an authority (intent.pillar.root); the address is derived by computation — one SHA-256, no DNS, no registry, no fetch. The name is a claim: intent addressing under a real-time constraint — synchronized in time, with resolution latency bounded and independent of network scale.

Q2 · What is IQA? · click to expand

IQA denotes Identity Quality Assurance — the attestation pillar. An iqa:// URI asks a named Organ for a verdict about a subject's standing: one of Ghost, Probation, Radiant, Genesis — a closed set. A verdict is an answer, not a computation: seals are HMAC-SHA256 over the canonical claim, bound to the subject's key material, verifiable offline — no issuer, no key directory, no network call. "I QA" — I, the answerer.

Q3 · Why not just use regular https URLs? · click to expand

A https URL states where a resource lives — you must fetch it to know anything. An rttp URI is computed, not looked up: the address is derived from the authority by SHA-256, with no DNS, no registry query and no fetch. The intent is part of the identifier itself, and anyone can verify the derivation offline.

Q4 · Why two schemes instead of one? · click to expand

Because they answer different kinds of questions. rttp resolves where — and when — by pure computation, needing no one's word. iqa states whether — a named Organ's verdict about a subject. Two namespaces keep the question channel and the attestation channel apart: the computation never depends on anyone's word, and the attestation never pretends to be computation.

Q5 · Is this a performance claim — faster than PTP? · click to expand

No. The temporal half of the name is a structural commitment, not a benchmark: resolution is computation, so addressing latency does not scale with the network. Clock synchronization is PTP's discipline and remains its own; RTTP borrows the discipline of time transfer for intent — two parties compute the same address into agreement without a shared lookup.

Q6 · How do I verify any of this? · click to expand

Replay the conformance vectors at iqa.org/challenge/ (35 vectors, any language, byte for byte), or install the packages from the URI Center.

Don't take our word for any of it — replay the vectors at iqa.org/challenge/ or run the demos at iqa.org/demo/.