Intent Addressing in the rttp URI Scheme

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.¶

Table of Contents

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).¶

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 identifying a subject. In the hash form, a fixed-width derived value.¶

3. The rttp URI Scheme

rttp://<intent>.<pillar>.<root>[/<action>]

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

rttp://f3b2a1c4.pillar.example/vessel
rttp://organ.pillar.example/verify
rttp://f3b2a1c4.pillar.example

canonical_authority = intent "." pillar "." root
                      (lowercase, US-ASCII)
ROUTE_SHARD         = SHA-256(ASCII(canonical_authority))[0:16]

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.¶

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.¶
• 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.¶

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.¶

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.¶

Examples

rttp://f3b2a1c4.pillar.example/vessel      (hash form)
rttp://organ.pillar.example/verify         (readable form)
rttp://f3b2a1c4.pillar.example             (default operation)

Author's Address