| Internet-Draft | alter URI Scheme | August 2026 |
| Morrison | Expires 4 March 2027 | [Page] |
This document defines the alter URI scheme as a dispatchable
reference syntax for ~handle identity references published under
the DNS substrate defined in [MCPDNS]. An alter: URI binds a
textual ~handle reference to a resolution and verification
procedure that retrieves the handle's envelope from the publishing
zone, validates the envelope's signature chain, and dispatches the
result to an operating-system URI handler. The reference may be
scoped to an organisation, narrowed to a named facet of the
identity, and addressed to a typed action surface. The scheme is
the addressing form of
the ~handle@org:facet/action reference; its resolution semantics
are those of [MCPDNS], reused without modification.¶
The scheme is provider-neutral, introduces no new cryptographic
primitive, and reuses the resolution and verification procedures
of [MCPDNS] without modification. The principal contribution is a
single, self-verifying dispatch surface for handle-typed references:
clicking, typing, or scanning an alter: URI yields a verified
handle resolution rather than a free-text string or an
unauthenticated fetch, and where an action is addressed it yields a
verify-before-side-effect dispatch. This document requests
provisional
registration of the alter scheme with IANA per [RFC7595]
Section 3.¶
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 4 March 2027.¶
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.¶
The ~handle identity primitive defined in [MCPDNS] binds a textual
identifier (Sovereign, Bot, or Instrument tier per [IDCOMMITS]) to
a cryptographic principal published under an _alter. DNS TXT
record. A handle reference written in running text, such as
~alice, ~example.com or ~cc-example-model, is interpretable to
a human reader but is not, by itself, a dispatchable reference for a
machine.¶
This document defines the alter URI scheme as the dispatchable
form of a handle reference. An alter: URI binds a ~handle to
the resolution procedure of [MCPDNS] and to a URI handler registered
with the host operating system. It carries three optional
addressing components, an organisational scope, a facet, and an
action-path. Once a handler is installed, clicking alter:~alice
in a
browser, chat window, or terminal yields a verified envelope; the
handler decides what to do with the resulting envelope (open an
inbox, show a profile card, initiate an Accord ceremony per
[IDACCORD], dispatch to a per-surface MCP tool).¶
The scheme's addressing model is deliberately fuller than a bare
handle. A reference frequently needs to name not just who but
which organisational context, which facet of that identity, and
which action surface under it. One example is "the security facet
of ~blake at acme, verify action". The alter: scheme carries all
four in a single dispatchable token, alter:~blake@acme:security/verify,
so that the whole reference travels as one clickable, scannable,
copy-pasteable string. Every component beyond the handle is
OPTIONAL; a bare alter:~alice remains valid.¶
This document specifies the addressing syntax, the dispatch and verification obligations of a handler, and the operating-system registration entries a handler installs. It does NOT specify the resolution semantics of any facet or action surface: what a given facet or action means, and how a resolver computes its answer, are owned by the specification that defines that surface and are out of scope here. This document is the standalone registration request submitted to IANA per [RFC7595] Section 3, separating the administrative ceremony of scheme registration from the substantive specification of the DNS substrate.¶
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.¶
~handleA textual identity reference defined in [MCPDNS] and tiered in [IDCOMMITS]. Handles begin with the tilde character U+007E.¶
The signed identity record retrieved from the _alter.<domain>
DNS TXT record of the publishing zone, as specified in [MCPDNS]
Section 5.¶
An optional DNS-named organisation qualifying a handle, written
after an @ separator, e.g. ~blake@acme.example. The scope
identifies the publishing zone under which the handle's envelope
is resolved; a handle with no scope resolves under its own zone.
org-scope selects the publishing zone consulted in the
resolution procedure of Section 3.4; it carries no claim about
which context, tenancy, or organisational capacity the presenting
principal is presently acting under. A resolver, facet, or
action-path definition MUST NOT infer the principal's acting
context from the presence, absence, or value of org-scope.
Where a reference needs to carry acting context, it does so via a
context artefact reference (see Context Artefact Type below) or
via a facet or action-path defined for that purpose by the
surface that owns it, never via org-scope.¶
An optional named aspect of an identity, written after a :
separator, e.g. :security. A facet narrows a reference to one
addressable face of the identity. What a facet denotes, and how a
resolver answers it, are defined by the surface specification that
owns the facet, not by this document. An identity-pronoun
reference axis [IDPRONOUNS] is one example of the kind of
specification that could own such a facet.¶
An optional typed surface addressed under a handle (and facet, if
present), expressed as the path component of the URI, e.g.
verify, decisions/123, seat/architect. An action-path names
an operation or resource surface; its semantics are owned by the
specification that defines it.¶
A lowercase-alphabetic label identifying a member of a typed
artefact genus, carried as the first path segment of an
artefact-ref-form URI, e.g. nest in alter:nest/summary-42. An
artefact type names a member of a genus whose extent is owned by
the specification defining that genus, not by this document; this
document defines the shape of the reference, not the genus it
addresses.¶
An opaque reference to one member of the genus named by an
artefact type, carried as the second path segment of an
artefact-ref-form URI, e.g. summary-42 in
alter:nest/summary-42. What an artefact reference denotes, and
how a resolver dereferences it, are defined by the surface
specification that owns the artefact type, not by this document.¶
An operating-system component registered to receive alter:
URIs and dispatch to a resolver. Examples include xdg-mime
associations [XDG-MIME] on Linux, LaunchServices URL handlers
[LSHANDLERS] on macOS, registry entries under HKCR on Windows,
intent filters on Android, and universal links on iOS.¶
alter¶
Provisional. This document requests provisional registration of the
alter scheme per [RFC7595] Section 3. A permanent registration
per [RFC7595] Section 7 is the intended upgrade path once the scheme
specification stabilises; this document records that intent without
asserting a permanent registration that IANA has not yet made.¶
The alter URI scheme's generic syntax conforms to [RFC3986]. The
scheme carries two disjoint reference forms under one scheme name:¶
alter-URI = "alter:" ( handle-ref-form
/ artefact-ref-form )
handle-ref-form = handle-ref [ "@" org-scope ]
[ ":" facet ] [ "/" action-path ]
[ "?" query ] [ "#" fragment ]
artefact-ref-form = artefact-type [ "/" artefact-ref ]
[ "?" query ] [ "#" fragment ]
handle-ref = "~" handle-name
handle-name = sovereign-name / bot-name / instrument-name
sovereign-name
= ALPHA *( ALPHA / DIGIT / "-" / "." )
; Per [IDCOMMITS] Section 4.
bot-name = ALPHA *( ALPHA / DIGIT / "-" / "." ) ".bot"
instrument-name
= "cc-" 1*( ALPHA / DIGIT / "-" / "." )
; Per [IDCOMMITS] Section 4.
artefact-type
= 1*LOWER
; the artefact genus member name; lowercase only
artefact-ref = ref-segment *( "/" ref-segment )
; opaque within the genus named by artefact-type
ref-segment = 1*( unreserved / pct-encoded )
; "~" is unreserved per [RFC3986] Section 2.3, and
; any other octet is available via pct-encoded.
; A ref-segment MUST NOT be "." or "..", and cannot
; be empty, so "//" and a trailing "/" are both
; malformed. See Ref-Segment Traversal under
; Security Considerations
org-scope = domain-label *( "." domain-label )
; the organisational zone qualifying the handle
domain-label = ALPHA / ( ALPHA *( ALPHA / DIGIT / "-" )
( ALPHA / DIGIT ) )
facet = facet-label *( "." facet-label )
; a named aspect of the identity surface
facet-label = ALPHA *( ALPHA / DIGIT / "-" )
action-path = action-segment *( "/" action-segment )
action-segment
= 1*( unreserved / pct-encoded / sub-delims
/ ":" / "@" )
query = *( pchar / "/" / "?" )
fragment = *( pchar / "/" / "?" )
pchar = unreserved / pct-encoded / sub-delims / ":" / "@"
unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~"
pct-encoded = "%" HEXDIG HEXDIG
sub-delims = "!" / "$" / "&" / "'" / "(" / ")"
/ "*" / "+" / "," / ";" / "="
LOWER = %x61-7A
; a-z
¶
The two alternatives of alter-URI are unambiguous because they are
discriminated by the single octet immediately following the scheme
separator alter:. U+007E TILDE (~) introduces a
handle-ref-form reference; a lowercase ALPHA introduces an
artefact-ref-form reference; no other leading octet is valid, and
a URI beginning with any other octet MUST be rejected. The tilde
character is reserved as the handle prefix under this scheme and
MUST NOT begin an artefact-type; artefact-type is restricted to
1*LOWER for exactly this reason. A parser that inspects only this
first octet can determine which grammar governs the remainder of the
URI without backtracking.¶
The handle-name ABNF mirrors the tier productions of [IDCOMMITS]
without restating tier-level invariants; an alter: URI carries a
single handle and the parser determines the tier from the lexical
form.¶
The four identity-bearing components of handle-ref-form are parsed
left to right and each is bounded by its introducing delimiter: the
handle follows the scheme separator, an @ introduces the
organisational scope, the first : after the handle (or scope)
introduces the facet, and the first / introduces the action-path.
A : appearing after the first / is a literal action-segment
character, not a facet delimiter, because the facet, if present, is
fully consumed before any /. Every component after handle-ref
is OPTIONAL and any combination MAY be omitted.¶
The host-component slot of a generic URI is not used. All
identity-bearing material is carried in the path-like productions
immediately after the scheme separator; the @ in org-scope is a
component delimiter within that material and MUST NOT be read as the
userinfo @ of an [RFC3986] authority.¶
For the reference substrate of Section 3.6, this document is itself
the specification that Terminology's Artefact type definition
refers to: Section 3.9 enumerates the members currently admitted to
the artefact-type genus under this document. That genus is a list
of reference shapes maintained here; it is not, and does not govern,
any closed set of storage or transport formats a consuming platform
separately maintains for its own artefact-persistence purposes. A
name MAY be a member of both without either list constraining the
other's admission or carrying any resolution meaning across the two.¶
Operations on an alter: URI in handle-ref-form are
retrieval-and-verify by default. Submitting an alter: URI in
handle-ref-form to a handler MUST perform the resolution and
verification procedure specified in [MCPDNS] Section 8 before any
content, directive, or action derived from the resulting envelope is
acted upon. Specifically, the handler MUST:¶
Parse the URI per the ABNF above, isolating the handle, and any organisational scope, facet, and action-path.¶
Resolve ~handle (under org-scope if present) to a publishing
zone via the procedures of [MCPDNS] Section 6.¶
Retrieve and DNSSEC-validate [RFC4033] the _alter.<zone> TXT
record.¶
Verify the envelope signature against the published Ed25519 key per [MCPDNS] Section 8.¶
If a facet or action-path is present, dispatch the request to the resolver indicated by the envelope, carrying the facet and action-path verbatim.¶
Envelope retrieval in Step 3 is DNS-primary; where the
_alter.<zone> TXT record is absent, [MCPDNS] falls back to the
HTTPS Well-Known URI surface [RFC8615] for envelope retrieval. This
document imposes no requirement on that fallback beyond the
verification procedure above, which applies uniformly regardless of
which surface produced the envelope.¶
The facet and action-path are ADDRESSING information only. This document assigns them no resolution meaning: it does not define what any facet denotes, how a resolver answers an action, or what value a dereference yields. Those semantics are owned entirely by the surface specification that defines the facet or action, and are out of scope here. A conforming handler treats the facet and action-path as opaque, verified-then-forwarded tokens.¶
Where an action-path names an operation with a side effect, the
verification of Step 4 is a precondition to that side effect:
handlers MUST NOT perform, initiate, or authorise any action
addressed by an alter: URI until the envelope has been retrieved
and verified. Handlers SHOULD treat any verification failure as a
hard error and SHOULD NOT fall back to unverified retrieval or to
executing the addressed action.¶
An alter: URI in artefact-ref-form addresses a typed artefact,
not a ~handle. The resolution procedure of Steps 1-5 above is
defined entirely in terms of DNS zone resolution for a handle and
does not apply to it. This document assigns artefact resolution no
meaning: it does not define how an artefact-type is resolved to a
genus, how an artefact-ref is dereferenced to content, or what a
handler does upon receiving one. Those semantics are owned entirely
by the specification that defines the artefact genus named by
artefact-type, exactly as facet and action-path semantics are
owned by the surface specification that defines them. A conforming
handler that receives an artefact-ref-form URI and has no such
specification registered MUST treat it as unresolvable and MUST NOT
attempt handle resolution against it.¶
alter URIs are ASCII per [RFC3986]; characters outside the
unreserved set MUST be percent-encoded. The IRI form per [RFC3987]
is supported for action-paths that contain non-ASCII characters;
the handle-ref, org-scope, and facet productions MUST be ASCII
to align with the DNS label production of [MCPDNS]. The tilde
character U+007E is reserved as the handle prefix and is treated as
a literal, not as an unreserved-character escape.¶
A reference substrate operated by the present author uses alter:
URIs to dispatch handle references between operating-system
handlers, an alter command-line interface, chat clients, and
agent runtimes that consume the DNS substrate of [MCPDNS]. Any
agent runtime, client, or operating-system component that resolves
~handle references can register a handler for the scheme.¶
Operating-system URI handler registries are well-defined for each target platform:¶
macOS: CFBundleURLSchemes entries in an application's
Info.plist [LSHANDLERS].¶
Windows: HKEY_CLASSES_ROOT\alter with URL Protocol and
shell\open\command subkeys.¶
Android: <intent-filter> with <data android:scheme="alter">.¶
iOS: associated-domains and universal-link entitlement entries.¶
Where multiple applications register a handler for alter:, the
operating system's default-application policy applies. No special
arbitration mechanism is defined by this document.¶
Browsers MAY treat alter: URIs as opaque external schemes and
delegate dispatch to the operating-system handler. Clients SHOULD
NOT attempt direct retrieval of alter: URIs over HTTP; the
resolution procedure of [MCPDNS] does not run over HTTP.¶
The alter scheme does not displace any existing scheme and does
not contradict the path-handling rules of [RFC3986]. It coexists
with https:, mailto:, and other schemes that an operating
system may dispatch on the same surface.¶
context is a member of the artefact-type genus (Section 3.3),
naming the reference shape for a context artefact. A context
artefact is a first-class object the presenting principal holds,
distinct from an organisational scope or a facet. This document
specifies the reference shape only; it assigns no meaning to what a
context artefact carries, in the same way it assigns no meaning to
an artefact reference generally.¶
context-ref-form = "context" "/" context-ref
[ "?" query ] [ "#" fragment ]
context-ref = personal-context / opaque-context-ref
personal-context = "personal"
; RESERVED. Denotes the presenting
; principal's own organisation-free
; default context, as a positive,
; present value rather than the
; absence of one.
opaque-context-ref = 1*( ALPHA / DIGIT / "." / "_" / "-" )
; opaque within the context genus,
; using a character class that itself
; excludes "~". MUST NOT lexically
; embed a handle-name or a domain-
; label; a reference that embeds
; either is non-conforming.
¶
context-ref-form is artefact-ref-form with artefact-type =
"context"; it introduces no third alternative to alter-URI and
no change to the discriminator rule of Section 3.3. Worked forms:
alter:context/personal, alter:context/9f2a-freelance-b. The
RESERVED personal literal is the one exception to full opacity
within this genus: because it is identical across every principal
rather than an opaque per-context identifier, resolving it never
distinguishes one principal's personal context from another's, and
it reveals only that a personal-context resolution was attempted.¶
A context artefact reference is a member-authored address naming
which context artefact is meant. Determining which context is
presently acting for a given session or request is outside the
scope of this addressing specification, in the same way this
document already declines to assign resolution meaning to a facet
or an action-path; see Context Reference Confusion in Section 6.¶
Beyond context (Section 3.8), the reference substrate of
Section 3.6 currently admits the following members to the
artefact-type genus. Each names a reference shape only, in the
same way Section 3.3 assigns artefact-ref no meaning beyond
opacity within the named genus; none needs sub-grammar of its own,
and each conforms to artefact-ref-form as specified.¶
A static documentation artefact, e.g. alter:docs/protocol.md.¶
A plain-language explainer section, e.g.
alter:explainer/07-where-your-name-earns.md.¶
A reciprocal-guidance document section, e.g.
alter:guidance/00-what-you-owe.md.¶
A design-nest document reference, e.g. alter:nest/summary-42.
An artefact-ref in this genus member MAY carry a --<section>
suffix naming a section within the referenced document, e.g.
alter:nest/summary-42--3.1; the suffix is opaque within the
artefact reference and needs no sub-grammar of its own.¶
An inter-agent message frame, e.g. alter:agentframe/<frame-id>.¶
An inter-agent advisory frame, e.g.
alter:agentadvisory/<frame-id>.¶
A member consent request, e.g. alter:consent/<approval-id>,
optionally carrying an action query parameter naming a grant or
decline disposition.¶
A content-addressed grant envelope, e.g.
alter:grant/sha256-<digest>.¶
A signed authorisation stamp, e.g.
alter:stamp/<concern-domain>/<ref>. This member is the reason
artefact-ref is a sequence of ref-segments rather than a
single segment: the concern domain and the reference it scopes are
separate names, and collapsing them into one segment would make
the domain unreadable to anything but the emitter. A member of
this genus MAY share its name with a format a consuming platform
separately maintains for its own artefact storage, as grant,
nest and stamp all do here; per Section 3.3, the coincidence
carries no cross-governance between the two.¶
This list is not exhaustive of every reference the substrate of Section 3.6 may in future admit; a new member is admitted by describing its reference shape here, following this pattern or, where a member needs its own sub-grammar, the pattern of Section 3.8.¶
See Section 6 below.¶
The following non-normative subsections sketch the platform- specific registration entries that a conforming handler installs. Implementations are responsible for the platform-specific syntax; this document does not prescribe handler binaries or invocation shapes.¶
A .desktop file with MimeType=x-scheme-handler/alter; and a
Exec= line invoking the platform resolver. The alter-cli
reference implementation registers itself as the default handler
on first run.¶
A CFBundleURLTypes entry with CFBundleURLSchemes=("alter") and
a CFBundleURLName of Identity Handle Reference in the
application's Info.plist.¶
The following non-normative examples illustrate the addressing syntax. Facet and action semantics are out of scope; each surface is defined by the specification that owns it.¶
alter:~alice alter:~example.com/decisions/123 alter:~bob/inbox alter:~blake@acme.example alter:~blake@acme.example:security alter:~blake@acme.example:security/verify alter:~example.com:seat/architect alter:~cc-example-model/sessions/last¶
The first form addresses an envelope; the second and third address action surfaces under an envelope; the fourth scopes a handle to an organisation; the fifth adds a facet; the sixth adds a typed action under that facet; the seventh addresses a facet-scoped surface; the eighth illustrates Instrument-tier addressing.¶
The verification mandate of [MCPDNS] Section 8 is the security
floor of this scheme. Handlers that accept an alter: URI without
verifying the envelope's signature against the DNSSEC-validated
publishing record violate the scheme's invariants. An attacker
who induces a handler to perform unverified retrieval can
substitute an envelope. Implementations MUST treat envelope
verification as a precondition to any side effect (writing files,
sending requests, dispatching a sub-handler, or performing an
addressed action).¶
Because an alter: URI MAY address a typed action, a handler that
acts on the action-path before verifying the envelope exposes a
confused-deputy surface: an attacker-supplied URI could name a
privileged action under a handle the attacker does not control.
The Step-4 verification MUST complete, binding the resolved envelope
to the addressed handle, before any action-path is dispatched. A
handler MUST NOT infer authority from the URI's textual form alone.¶
A context artefact reference (Section 3.8) is a claim to verify,
never authority to assume. A handler that treats the mere presence
of a context artefact reference in an inbound request as
sufficient to act under that context, without a separate admission
step re-deriving the verdict against the principal's actual
holdings, reproduces the confused-deputy surface described in
Action-Address Confusion above, for the context axis rather than
the action axis.¶
A context artefact is a private holding, blind to every other
context the same principal holds. The resolution procedure for a
context artefact reference MUST NOT expose, to any party other
than the presenting principal's own bound credential, the
existence, name, or count of any other context the same principal
holds. An unresolvable context-ref and a context-ref the
resolver declines to answer MUST be indistinguishable; a resolver
that distinguishes them creates an existence oracle over the
principal's context set.¶
No public resolution path is specified for context artefact
references, and none should be built. Unlike a ~handle envelope,
which is a published declaration under a zone its holder wants
third parties to verify, a context artefact is resolvable only by
its holder's own bound credential. A resolver receiving a
context artefact reference from any other party MUST decline, in
a way indistinguishable from the non-enumeration behaviour above.¶
The operating-system's default-application policy is the
trust-anchor for which binary handles alter: URIs. Users
configuring the default handler MUST treat handler selection with
the same caution they apply to default browsers or default mail
clients. A malicious handler could parse an alter: URI, present
a forged envelope to the user, and act on attacker-supplied data
without performing verification. Implementations SHOULD
cross-check the handler binary's signature against the publishing
substrate's expected handler manifest where such a manifest is
defined by a future specification.¶
An organisational scope, facet, or action-path included in an
alter: URI is part of the URI's textual form and may be logged by
the operating-system handler registry, browser history, terminal
scrollback, and chat-client indexers. Surface owners that consider
a facet or action identifier (e.g. a decision identifier, a thread
identifier) sensitive SHOULD provide indirected forms (opaque
tokens, ephemeral identifiers) and SHOULD NOT recommend embedding
sensitive identifiers in the URI.¶
An artefact-ref is a sequence of named segments, not a filesystem
path. A ref-segment MUST NOT be . or .., and MUST NOT be
empty, so alter:explainer/../secret.md,
alter:explainer//etc/passwd and alter:docs/ are all malformed
and MUST be rejected. Implementations MUST reject them on the
textual form, before any resolution is attempted, and MUST NOT
normalise a navigation segment away and resolve what remains: a
resolver that receives an already-normalised reference cannot tell
that a traversal was ever requested. The percent-encoded spellings
of these segments are covered by the same rule, because
pct-encoded decoding happens before a segment is compared.¶
A URI of the form alter://~alice (with the authority-component
double-slash) is malformed and MUST be rejected. Implementations
MUST NOT silently coerce alter://~handle to alter:~handle;
divergent parsers risk confusing a third-party authority component
with a handle reference. Similarly, the @ of an org-scope MUST
NOT be parsed as an [RFC3986] userinfo delimiter; there is no
authority component in an alter: URI.¶
The two forms defined in Section 3.3 share one scheme prefix and
are discriminated solely by the octet following the scheme
separator. A parser that accepts a leading tilde character inside
an artefact-type production, or that treats an artefact-ref-form
URI as containing a handle-ref when no tilde is present, breaks
the partition between the two forms and creates a parser-divergence
surface: two conforming implementations could disagree about which
form a given URI carries, and an attacker could craft a URI that one
implementation resolves as a handle reference and another resolves
as an artefact reference. Implementations MUST reject any URI in
which the octet following alter: is neither U+007E TILDE nor a
lowercase ALPHA. Implementations MUST NOT attempt
handle-ref-form parsing on a URI beginning with a lowercase ALPHA,
and MUST NOT attempt artefact-ref-form parsing on a URI beginning
with U+007E. A handler that dispatches based on a partial or
best-effort match of either form, rather than a full match against
the discriminator rule of Section 3.3, is non-conforming.¶
handle-name admits U+002E FULL STOP, because the tier productions
it mirrors from [IDCOMMITS] use a trailing .bot label to carry the
bot tier lexically. A handle-name may therefore be spelled so
that it resembles a DNS domain name. alter:~example.com is a
well-formed handle reference naming a principal whose handle is
example.com; it is not a reference to the example.com zone, and
nothing in this scheme gives it one.¶
Implementations MUST NOT derive DNS meaning from the lexical form of
a handle-name, MUST NOT resolve a handle through DNS on the basis
of its spelling, and MUST NOT treat a handle ending in a public
suffix as evidence of any relationship to the corresponding domain.
An association between a domain and a handle is established out of
band and is never inferred from the handle's characters. A surface
that renders a handle to a person MUST retain the leading tilde,
because a handle stripped of its tilde and placed where a reader
expects a domain cannot be distinguished from one. Only a trailing
.bot label carries meaning under [IDCOMMITS]; no other label
within a handle-name carries any.¶
When an alter: URI is presented in IRI form per [RFC3987] with
non-ASCII characters in the action-path, implementations MUST
apply the conversion procedure of [RFC3987] Section 3.1 before
performing the resolution procedure. Non-ASCII characters in the
handle-ref, org-scope, or facet MUST be rejected; those
productions are restricted to the ASCII forms above.¶
This document requests that IANA register the alter URI scheme
in the Uniform Resource Identifier (URI) Schemes registry per
[RFC7595] Section 3 (provisional registration), recording the
provisional registration cross-referenced under [MCPDNS] Section 11
with the following body:¶
URI scheme name: alter¶
Status: Provisional¶
URI scheme syntax: As specified in Section 3.3 above.¶
URI scheme semantics: As specified in Section 3.4 above.¶
Encoding considerations: As specified in Section 3.5 above.¶
Applications/protocols that use this URI scheme name: As specified in Section 3.6 above.¶
Interoperability considerations: As specified in Section 3.7 above.¶
Security considerations: As specified in Section 6 above.¶
Contact: Blake Morrison blake@truealter.com, Alter Meridian Pty Ltd.¶
Author/Change controller: Blake Morrison, Alter Meridian Pty Ltd. Change control transfers to the IETF if this scheme is later specified by an IETF Stream document.¶
A permanent registration per [RFC7595] Section 7 is the intended upgrade path once the scheme specification stabilises.¶
The scheme builds on the ~handle identity primitive defined in
[MCPDNS] and the tier taxonomy of [IDCOMMITS]. The lexical choice
of tilde for the handle prefix is informed by [POSIX-TILDE] and by
the long-standing shell convention that the tilde denotes a named
principal.¶
Add a Handle-Domain Confusion security consideration. handle-name
admits "." in order to carry [IDCOMMITS]'s .bot tier suffix, so a
handle may be spelled to resemble a DNS domain; state that no DNS
meaning follows from a handle's lexical form, that a domain's
association with a handle is established out of band, and that a
rendering surface MUST retain the leading tilde.¶
Make artefact-ref a sequence of ref-segments separated by "/"
rather than a single segment, so a member whose reference carries a
scoping name ahead of the reference itself is expressible; stamp,
alter:stamp/<concern-domain>/<ref>, is the case that forced it.
The slash is a separator between named segments and never a
character within one, which is what keeps "//" and a trailing "/"
malformed.¶
Add a Ref-Segment Traversal security consideration. A ref-segment
MUST NOT be "." or "..", MUST be rejected on the textual form
before any resolution, and MUST NOT be normalised away and the
remainder resolved; the rule is applied after pct-encoded
decoding, so %2e%2e is refused on the same ground as ...¶
Admit stamp to the artefact-type genus, and name nest and
stamp alongside grant as the members whose names coincide with
a consuming platform's own storage formats.¶
Partition the scheme into two disjoint reference forms carried
under one scheme name: handle-ref-form (unchanged from rev 02)
and a new artefact-ref-form, alter:<artefact-type>/<artefact-ref>,
addressing a typed artefact rather than a ~handle.¶
Add a discriminator rule: the octet immediately following the scheme separator selects the form, U+007E TILDE for a handle reference and a lowercase ALPHA for an artefact reference; no other leading octet is valid, and the tilde is reserved as the handle prefix and MUST NOT begin an artefact type.¶
Add Artefact type and Artefact reference to Terminology, defining the shape of the reference only; the extent of any artefact genus is owned by the specification defining that genus, not by this document.¶
State that artefact resolution is assigned no meaning by this document, matching the existing disclaimer for facet and action-path semantics.¶
Add a Form Confusion security consideration addressing the parser-divergence surface the two-form scheme introduces.¶
Repoint the informative Apple reference from the archived Core Foundation keys page to the current CFBundleURLTypes page, and retitle it to match, because the archived URL cannot be rendered inside the 72-column limit at any reference indent. The mechanism cited is unchanged.¶
Add context as a member of the artefact-type genus, with a
Context Artefact Type subsection specifying context-ref-form,
the RESERVED personal literal for the presenting principal's
own organisation-free default context, and the opaque-reference
production carrying a MUST-NOT-embed-a-handle-or-domain-label
constraint. No top-level grammar change and no third alternative
to alter-URI. Add a matching Context Reference Confusion
security consideration covering the confused-deputy risk,
non-enumeration of a principal's other contexts, and the absence
of any public resolution path. Demote org-scope in Terminology
from an implicit context carrier to a bare DNS zone qualifier,
stating that a resolver, facet, or action-path definition
MUST NOT infer acting context from it.¶
Fix two grammar coverage gaps found by bringing an existing
implementation into conformance against this scheme, rather than
inventing new requirements. Widen artefact-ref from
1*( ALPHA / DIGIT / "." / "_" / "-" ) to
1*( unreserved / pct-encoded ), since ~ is unreserved per
[RFC3986] Section 2.3 and the character class as previously
written could not carry a ~handle reference or its
percent-encoded form; and make the artefact-ref component of
artefact-ref-form OPTIONAL, since a bare artefact type with no
ref had no production at all and several real "open this surface"
addresses need exactly that shape.¶
State, in URI Scheme Syntax, that this document is itself the
specification owning the artefact-type genus for the reference
substrate of Section 3.6, and that the genus is distinct from any
closed set of storage or transport formats a consuming platform
separately maintains; a name MAY be a member of both without
either governing the other. Add an Artefact Type Genus Membership
subsection listing the genus's current members beyond context
(docs, explainer, guidance, nest, agentframe,
agentadvisory, consent, grant), each a bare reference shape needing no
sub-grammar of its own, and stating that membership is additive.¶
Broaden the addressing syntax to the full ~handle@org:facet/action
reference: add the org-scope, facet, and action-path
productions and their left-to-right parsing rules. Every added
component is OPTIONAL; a bare alter:~handle is unchanged.¶
State explicitly that facet and action-path are addressing information only, with resolution semantics owned by the surface specification and out of scope here.¶
Add an Action-Address Confusion security consideration and extend the verification mandate to cover addressed actions.¶
Correct the registration Status to Provisional, matching the registration this document actually requests; record permanent registration as the intended upgrade path rather than asserting it.¶
Editorial and reference alignment.¶