RTTP.COM Organization

lee@rttp.com

Applications and Real-Time Independent Submission This document specifies the "rttp" URI scheme. 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, and no lookup service, registry, or name-resolution system is consulted at resolution time. The document also states the requirements a client MUST satisfy when it handles such a URI, in order to avoid two failure modes that short, user-embeddable strings otherwise invite: using the authority as a navigation target (open redirect), and using a registered protocol handler as a general-purpose launcher.

Introduction Most URI schemes name a location: the authority identifies a host to be contacted. This document specifies a scheme that names something else: a claim of intent directed at an identified subject. What a client does with that claim is defined by the scheme; where the subject might be reached is not part of the URI and is not resolved through any lookup service. Three properties follow from that choice and are normative in this document:

• the address is derived by computation from the authority (), so the same authority always yields the same address;
• there is no lookup: no DNS, no registry query, no well-known resource fetch (, );
• the URI is a claim, not a proof. It establishes nothing about the subject by itself ().

The scheme is subject to registration with IANA under . Its registration status is recorded in ; as of this writing the request is submitted and pending, and the name is not registered. Readers familiar with other "agent" or identity addressing schemes should note what is not claimed here. This document does not define a discovery mechanism, a transport, a key directory, or an authorization decision. It defines a URI scheme and the minimum client behaviour that makes the scheme safe to embed.

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses the ABNF notation of and the URI syntax of . Terminology:

authority

The three-segment component <intent>.<pillar>.<root> defined in . It is a name, not a host name, and is never resolved.

claim of intent

A statement that a subject intends an action. It is a claim: it is not evidence, and it does not by itself establish the identity of the subject.

subject

The entity the claim is directed at, identified by the authority.

action

The optional final path segment naming what is claimed to be intended.

ROUTE_SHARD

The 16-byte value derived from the authority as specified in .

AID

A self-certifying subject identifier defined outside this document. This document does not define AID, and makes no assumption about its length or encoding beyond what and require. Nothing in this specification depends on an AID registry or authority.

organ

In the readable form of intent, a human-readable token identifying a subject. In the hash form, a fixed-width derived value.

The rttp URI Scheme

Syntax The general form of an rttp URI is: ..[/] ]]> The authority comprises exactly three dot-separated segments, in this order:

• intent: either 8 lowercase hexadecimal digits, or a readable token matching 1*( %x61-7A / DIGIT / "-" ). The hash form is a derived value; the readable form is an operator-chosen label. Both are opaque to a client.
• pillar: an operator-chosen label matching 1*( %x61-7A / DIGIT / "-" ). This document defines no enumeration of pillar labels and no registry for them; the label is meaningful to the operator that assigned it.
• root: an operator-chosen label matching 1*( %x61-7A / DIGIT / "-" ).

The action, when present, is a single path segment: "/" 1*( %x61-7A / DIGIT / "-" ). ABNF: Examples (the example labels are reserved names per ; operators use labels they control): The fragment component is not part of this scheme and MUST NOT be used to address an action.

Reserved Characters and Exclusions

• The canonical form is lowercase US-ASCII. Uppercase is invalid input, not a formatting difference: a parser MUST NOT normalise an uppercase string into a valid URI, because two distinct strings would then map onto one address.
• ., / and :// are the delimiters defined by this scheme.
• This scheme defines no userinfo, no port, no query, and no fragment. A URI containing any of them is not a valid rttp URI. In particular, credentials cannot appear in an rttp URI, and there is no field in which to exfiltrate data.
• Percent-encoding follows . Because no component requires characters outside the unreserved set, a canonical URI contains no percent-encoded octets; a parser MAY reject such input rather than normalising it.
• There is no "rttps" scheme and no protocol fallback. A client that does not implement this scheme fails closed ().

Default Operation Dereferencing an rttp URI without an action requests the default operation: one stateful, single round-trip semantic request against the subject named by the authority. The default operation is safe in the sense of : it creates no obligations and mutates no state of the subject. When an action is present, the default operation is not implied for it. An action names what is claimed to be intended; the safety of a given action is not defined by this document, and a client MUST NOT infer safety from this section ().

The Address: ROUTE_SHARD Derivation The routing address of an rttp URI is derived from the authority alone: The authority only: the scheme name is excluded, // is excluded, and any action is excluded. Properties of the derived address

Property	Meaning
Deterministic	The same authority always yields the same address.
Pure computation	No DNS, no registry, no network access, no lookup service.
One-way	The authority cannot be recovered from the address.
Action-independent	Different actions on one authority yield the same address.

The last property is the reason an action is not part of the addressing component: an address is where, not what. Were the action to participate in derivation, two different actions on one subject would become two different addresses, splitting one subject into several. Because the derivation is a computation on a string, the URI is usable without network access, and no third party is consulted when it is used. A client MUST NOT perform a lookup in order to use an rttp URI ().

Client Requirements A client that handles an rttp URI (including a resolver page, a protocol handler, and a library that renders one) MUST satisfy the requirements below. They follow from : an rttp URI may be supplied by an untrusted party, its authority is a claim rather than a proof, and the strings are short enough to be embedded anywhere.

No Navigation to the URI The authority and action components MUST NOT be used as a navigation target. A client that renders a link, redirect, or fetch derived from any part of an rttp URI is an open redirect and is non-conformant. A client MAY navigate only to a destination that is fixed in advance by the client itself.

Scheme Prefix Check A protocol handler MUST reject any input whose scheme is neither rttp nor the exact scheme name under which that handler was itself registered. Without this check, the handler becomes a general-purpose launcher that any page can use to open an arbitrary URI of any scheme.

Consent, Never Silence The ability to handle rttp URIs MUST NOT be acquired without an explicit action by the user, and a client MUST NOT simulate, pre-select, or otherwise bypass that consent. Where the platform exposes the list of registered handlers, that list MUST NOT be exposed to the network.

Rationale rttp://<intent>.<pillar>.<root>/<action> is a short, human-readable string that any page can embed in a link. Without the rules above, the scheme would hand third parties two primitive attacks: using an operator's own domain as a redirector, and using a registered handler as a launcher for URIs the user never intended to open. Both are properties of the embedding context, not of the URI syntax, which is why they are stated as client requirements rather than as grammar rules.

Security Considerations

• An rttp URI is a claim of intent against a subject. The derived address is an entry fingerprint, not a proof of identity. Identity is carried by the subject's AID, and any attestation of it is carried separately.
• There is no rttps and no fallback: clients that do not implement the scheme fail closed, and an unrecognised form is rejected rather than approximated.
• The scheme does not resolve via DNS, and no lookup is performed when a URI is used. Consequently there is no resolver to poison, no registration to hijack, and no query metadata to observe on the resolution path.
• Because userinfo is not defined, credentials cannot be carried in an rttp URI. Operators MUST NOT place secrets in any component: the URI is expected to be logged, quoted, and rendered.
• The authority is pseudonymous, not anonymous. It is a stable name and will appear in logs, in caches, and in anything that quotes the URI. Whether that name is linkable to a subject is a property of the operator's naming choices, not of the scheme.
• Unknown actions carry unknown safety. The safe default operation of applies to the omitted-action form. An implementation MUST NOT infer safety for an unrecognised action verb from that statement; it MUST treat the verb as having unknown safety and either require explicit authorisation under the local security policy or reject it. Treating unknown verbs as safe reads would grant safe semantics to every future verb for free.
• The scheme itself provides no confidentiality and no authentication. Signing is not encryption, and a URI is not a signature.
• Parsing an rttp URI establishes nothing about the subject. A client MUST NOT present a parsed or rendered URI as if it were evidence of anything.

Privacy Considerations

• No component is defined for a query string, so the scheme provides no convenient channel for a page to smuggle data into a lookup: there is no lookup ().
• Using an rttp URI does not, by itself, cause any network traffic to a third party. Any traffic that follows is caused by the client's own, separately defined handling of the claim.
• The authority is a stable pseudonym and is expected to be logged. Operators that assign readable intent labels rather than derived hashes should be aware that they are choosing names that are meaningful to humans, which is a privacy trade-off made at assignment time.
• A client that renders an rttp URI SHOULD avoid prefetching, handing the string to third-party services, or otherwise distributing it beyond what the user's action requires.

Internationalization Considerations The canonical form of an rttp URI is lowercase US-ASCII, and no international form is defined. Characters outside the permitted set are invalid input rather than input to be converted: a client MUST NOT map a Unicode label to its ASCII form (for example, by case folding or by applying an IDNA-style transformation) in order to accept it, and MUST NOT render an rttp URI as an IRI. This is deliberate. The scheme has no host to resolve, so there is no need for a label-to-ASCII transformation; permitting one would introduce a second way to write one address.

IANA Considerations IANA is requested to register the URI scheme rttp in the "Uniform Resource Identifier (URI) Schemes" registry, following the template of and the guidance of .

Scheme name:

rttp

Status:

Provisional

Applications/protocols that use this scheme name:

URIs of this scheme name a claim of intent directed at an identified subject. Applications include intent-addressed requests between autonomous software agents and the client-side handling of such URIs by protocol handlers in browsers and operating systems. The scheme defines addressing only; it does not define a transport or a discovery mechanism.

Contact:

ShaoBao Li <>

Change controller:

RTTP.COM Organization

References:

This document, and the reference specification published at .

Security considerations:

See of this document.

Registration status at the time of writing: a registration request was submitted to IANA (ticket #1459939); the request is pending, and the scheme is not registered. It is inaccurate to describe the scheme as "registered", "assigned", or "standardised" until IANA publishes the registration. If this document is approved for publication as an RFC, IANA is requested to update the reference in the registry entry to point at that RFC.

Acknowledgements The author thanks the reviewers of the URI review process for their attention to the client-behaviour requirements, which are the part of this specification most likely to be misimplemented.

Normative References Informative References

Examples

Valid forms

Invalid forms and the reason Invalid input and why it is rejected

Input	Reason
RTTP://f3b2a1c4.pillar.example/vessel	Uppercase scheme or components are invalid input, not normalisable.
rttp://f3b2a1c4.pillar.example/	Trailing slash with an empty action is not a valid action.
rttp://f3b2a1c4.pillar.example?v=1	No query component is defined.
rttp://f3b2a1c4.pillar.example#top	No fragment component is defined.
rttp://user@f3b2a1c4.pillar.example/v	No userinfo component is defined.
rttp://f3b2a1c4.pillar.example:80/v	No port component is defined.
rttp://f3b2a1c4.pillar/v	Authority does not have exactly three segments.
rttp://f3b2a1c4.pillar.example/vessel/extra	Action is a single path segment.

Conformance The reference specification at is accompanied by a published set of deterministic conformance vectors, replayed by independent implementations that share no code. Implementations of this scheme are encouraged to replay the URI-parsing portion of that set; agreement is a statement about parsing only, and no performance property is claimed.