Independent Submission S. Li Internet-Draft RTTP.COM Organization Intended status: Informational 20 September 2026 Expires: 24 March 2027 Intent Addressing in the rttp URI Scheme draft-li-rttp-intent-addressing-00 Abstract 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. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 24 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Li Expires 24 March 2027 [Page 1] Internet-Draft rttp URI Scheme September 2026 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 3 3. The rttp URI Scheme . . . . . . . . . . . . . . . . . . . . . 4 3.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Reserved Characters and Exclusions . . . . . . . . . . . 5 3.3. Default Operation . . . . . . . . . . . . . . . . . . . . 5 3.4. The Address: ROUTE_SHARD Derivation . . . . . . . . . . . 5 4. Client Requirements . . . . . . . . . . . . . . . . . . . . . 6 4.1. No Navigation to the URI . . . . . . . . . . . . . . . . 6 4.2. Scheme Prefix Check . . . . . . . . . . . . . . . . . . . 7 4.3. Consent, Never Silence . . . . . . . . . . . . . . . . . 7 4.4. Rationale . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 8 7. Internationalization Considerations . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 10. Normative References . . . . . . . . . . . . . . . . . . . . 10 11. Informative References . . . . . . . . . . . . . . . . . . . 10 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Valid forms . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Invalid forms and the reason . . . . . . . . . . . . . . . . . 11 Conformance . . . . . . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. 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 (Section 3.4), so the same authority always yields the same address; * there is *no lookup*: no DNS, no registry query, no well-known resource fetch (Section 3.4, Section 4); * the URI is a *claim, not a proof*. It establishes nothing about the subject by itself (Section 5). Li Expires 24 March 2027 [Page 2] Internet-Draft rttp URI Scheme September 2026 The scheme is subject to registration with IANA under [RFC7595]. Its registration status is recorded in Section 8; 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. 2. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses the ABNF notation of [RFC5234] and the URI syntax of [RFC3986]. Terminology: authority The three-segment component .. defined in Section 3.1. 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 Section 3.4. 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 Section 3.2 and Section 5 require. Nothing in this specification depends on an AID registry or authority. organ In the readable form of intent, a human-readable token Li Expires 24 March 2027 [Page 3] Internet-Draft rttp URI Scheme September 2026 identifying a subject. In the hash form, a fixed-width derived value. 3. The rttp URI Scheme 3.1. Syntax The general form of an rttp URI is: rttp://..[/] 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: rttp-URI = "rttp://" authority [ "/" action ] authority = intent "." pillar "." root intent = hash-intent / name-intent hash-intent = 8 lowhex name-intent = 1*( %x61-7A / DIGIT / "-" ) pillar = 1*( %x61-7A / DIGIT / "-" ) root = 1*( %x61-7A / DIGIT / "-" ) action = 1*( %x61-7A / DIGIT / "-" ) lowhex = %x30-39 / %x61-66 Examples (the example labels are reserved names per [RFC2606]; operators use labels they control): rttp://f3b2a1c4.pillar.example/vessel rttp://organ.pillar.example/verify rttp://f3b2a1c4.pillar.example Li Expires 24 March 2027 [Page 4] Internet-Draft rttp URI Scheme September 2026 The fragment component is not part of this scheme and MUST NOT be used to address an action. 3.2. 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 Section 2.1 of [RFC3986]. 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 (Section 4). 3.3. 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 Section 3.1 of [RFC3986]: 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 (Section 5). 3.4. The Address: ROUTE_SHARD Derivation The routing address of an rttp URI is derived from the authority alone: canonical_authority = intent "." pillar "." root (lowercase, US-ASCII) ROUTE_SHARD = SHA-256(ASCII(canonical_authority))[0:16] Li Expires 24 March 2027 [Page 5] Internet-Draft rttp URI Scheme September 2026 The *authority only*: the scheme name is excluded, // is excluded, and any action is excluded. +====================+===================================+ | 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. | +--------------------+-----------------------------------+ Table 1: Properties of the derived 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 (Section 4). 4. 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 Section 5: 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. 4.1. 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. Li Expires 24 March 2027 [Page 6] Internet-Draft rttp URI Scheme September 2026 A client MAY navigate only to a destination that is fixed in advance by the client itself. 4.2. 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. 4.3. 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. 4.4. Rationale rttp://../ 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. 5. 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. Li Expires 24 March 2027 [Page 7] Internet-Draft rttp URI Scheme September 2026 * 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 Section 3.3 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. 6. 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 (Section 3.4). * 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. Li Expires 24 March 2027 [Page 8] Internet-Draft rttp URI Scheme September 2026 7. 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. 8. IANA Considerations IANA is requested to register the URI scheme rttp in the "Uniform Resource Identifier (URI) Schemes" registry, following the template of Section 7.4 of [RFC7595] and the guidance of [RFC8126]. 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 https://rttp.com/RFC-002/. Security considerations: See Section 5 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. Li Expires 24 March 2027 [Page 9] Internet-Draft rttp URI Scheme September 2026 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. 9. 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. 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 11. Informative References [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Li Expires 24 March 2027 [Page 10] Internet-Draft rttp URI Scheme September 2026 Examples Valid forms rttp://f3b2a1c4.pillar.example/vessel (hash form) rttp://organ.pillar.example/verify (readable form) rttp://f3b2a1c4.pillar.example (default operation) Invalid forms and the reason +========================================+==========================+ | 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/ | Action is a | | extra | single path | | | segment. | +----------------------------------------+--------------------------+ Table 2: Invalid input and why it is rejected Li Expires 24 March 2027 [Page 11] Internet-Draft rttp URI Scheme September 2026 Conformance The reference specification at https://rttp.com/RFC-002/ 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. Author's Address ShaoBao Li RTTP.COM Organization Email: lee@rttp.com Li Expires 24 March 2027 [Page 12]