Intent Addressing in the rttp URI Scheme
draft-li-rttp-intent-addressing-00

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 <intent>.<pillar>.<root>
      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://<intent>.<pillar>.<root>[/<action>]

   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://<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.

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 <mailto:lee@rttp.com>

   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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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,
              <https://www.rfc-editor.org/info/rfc3986>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.

   [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,
              <https://www.rfc-editor.org/info/rfc7595>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

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,
              <https://www.rfc-editor.org/info/rfc2606>.

   [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,
              <https://www.rfc-editor.org/info/rfc8126>.

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]