]> Alter Meridian Pty Ltd

blake@truealter.com

This document defines the alter URI scheme as a dispatchable reference syntax for ~handle identity references published in the DNS records defined in the companion specification for discovering Model Context Protocol servers through DNS TXT records. An alter: URI binds a textual ~handle reference to a resolution and verification procedure that retrieves the handle's envelope from a 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 that companion specification, reused without modification. The scheme is provider-neutral and introduces no new cryptographic primitive. A handler given an alter: URI verifies the handle's envelope before acting on it, and where the URI addresses an action, verification precedes any side effect. IANA provisionally registered the alter scheme under Section 4 of RFC 7595 on 5 October 2026.

Introduction The ~handle identity primitive defined in binds a textual identifier of the Sovereign or Bot tier ( Section 3) to a cryptographic principal published under an _alter. DNS TXT record. An Instrument-tier handle, such as ~cc-example-model, is not an independent handle: it names an instrument whose acts are attributed to the Sovereign that operates it, and it has no envelope of its own ( Section 2). A handle reference written in running text, such as ~alice or ~example.com, 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 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. A handler that receives alter:~alice retrieves and verifies the envelope, then decides what to do with it (open an inbox, show a profile card, initiate an Accord ceremony per , dispatch to a per-surface MCP tool). A reference can also name an organisation, a facet of the identity, and an action surface under that facet. For example, alter:~carol@acme.example:security/verify names the verify action under the security facet of ~carol at acme.example, in one 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. This document also carries the registration template submitted to IANA under Section 7.2; the DNS record format is specified in .

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Terminology

~handle

A textual identity reference defined in and tiered in . Handles begin with the tilde character U+007E.

Envelope

The signed identity record retrieved from the _alter.<domain> DNS TXT record of the publishing zone, as specified in Section 7.

Organisational scope

An optional DNS-named organisation qualifying a handle, written after an @ separator, e.g. ~carol@acme.example. The scope identifies the publishing zone under which the handle's envelope is resolved. Because a handle carries no zone of its own, a reference with no scope names no zone (Section 3.4). 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.

Facet

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 is one example of the kind of specification that could own such a facet.

Action-path

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, billing/invoices. An action-path names an operation or resource surface; its semantics are owned by the specification that defines it.

Artefact type

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. context in alter:context/9f2a-freelance-b. 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.

Artefact reference

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. 9f2a-freelance-b in alter:context/9f2a-freelance-b. 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.

Handler

An operating-system component registered to receive alter: URIs and dispatch to a resolver. Examples include xdg-mime associations on Linux, LaunchServices URL handlers on macOS and iOS, registry entries under HKCR on Windows, and intent filters on Android.

Scheme Definition

Scheme Name alter

Status Provisional. IANA provisionally registered the alter scheme under Section 4 on 5 October 2026. Permanent registration, against the requirements of Section 3, is the intended upgrade path once the scheme specification stabilises.

URI Scheme Syntax The alter URI scheme's generic syntax conforms to . The scheme carries two disjoint reference forms under one scheme name. The grammar uses the ABNF of . ALPHA, DIGIT and HEXDIG are its core rules, and unreserved, pct-encoded, sub-delims, pchar, query and fragment repeat the productions of . 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 artefact-type is restricted to 1*LOWER because the tilde character is reserved as the handle prefix under this scheme and MUST NOT begin an artefact-type. A parser that inspects only this first octet can determine which grammar governs the remainder of the URI without backtracking. The handle-name ABNF carries the three tiers of Section 3 using the lexical markers of Section 2, a trailing .bot for the Bot tier and a leading cc- for the Instrument tier, 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 /. Likewise an @ appearing after the first / is a literal action-segment character and never introduces an org-scope, since an org-scope can only follow handle-ref directly. 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 authority. This document admits one member to the artefact-type genus, context (Section 3.8). Any other member is admitted by the specification that defines what it addresses (Section 3.9). The genus is a set of reference shapes and governs no storage or transport format.

Scheme Semantics 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 Section 12.3 before any content, directive, or action derived from the resulting envelope is acted upon. Specifically, the handler MUST:

1. Parse the URI per the ABNF above, isolating the handle, and any organisational scope, facet, and action-path.
2. Take the publishing zone from org-scope. Where org-scope is absent, the reference names no zone, and the handler proceeds only if it holds an association between the handle and a zone established out of band; otherwise the reference is unresolvable. A zone is never derived from the spelling of the handle (Section 6.9).
3. Retrieve and DNSSEC-validate the _alter.<zone> TXT record, as Section 12.3 specifies.
4. Select the record whose handle matches, and verify the envelope signature against the published Ed25519 key, per Section 12.3. An envelope that procedure does not treat as verified is unverified.
5. If a facet or action-path is present, forward it verbatim, with the verified handle, as the specification that defines that facet or action surface directs. The envelope names no resolver. The fields of Section 7 carry no endpoint, and the procedure of Section 12.3 recognises the handle without reading a facet or action-path.

Envelope retrieval in Step 3 is a DNS query. defines no other surface from which an envelope is retrieved, and neither does this document; where the _alter.<zone> TXT record is absent, the reference is unresolvable. An Instrument-tier handle names an instrument whose acts are attributed to the Sovereign that operates it. It is not an independent handle and has no envelope of its own ( Section 2; Section 7.3.2). A handler MUST NOT treat a handle-ref-form reference whose handle is Instrument-tier as naming an independent principal: it MUST NOT accept a record published for that handle as the instrument's envelope, and MUST NOT dispatch a facet or action-path under it on the instrument's authority. Authority for anything done with an instrument is the operating Sovereign's, verified under the Sovereign's own handle. The facet and action-path are addressing information only. This document does not define what any facet denotes, how a resolver answers an action, or what value a dereference yields; the surface specification that defines the facet or action owns those semantics. 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 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. The specification that defines the artefact genus named by artefact-type owns those semantics, as a surface specification owns facet and action-path semantics. 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.

Encoding Considerations alter URIs are ASCII per ; characters outside the unreserved set MUST be percent-encoded. The IRI form per is supported for action-paths that contain non-ASCII characters; the handle-ref, org-scope, and facet productions MUST be ASCII, as the DNS labels of are. The tilde character U+007E is reserved as the handle prefix and is treated as a literal, not as an unreserved-character escape.

Applications and Protocols That Use This Scheme A command-line client by the present author accepts alter: URIs supplied to it as input. It does not register as an operating-system handler for the scheme and does not run the resolution procedure of Section 3.4. Any agent runtime, client, or operating-system component that resolves ~handle references can register a handler for the scheme.

Interoperability Considerations Each target platform has its own URI handler registry:

• Linux desktops: xdg-mime associations .
• macOS: CFBundleURLSchemes entries in an application's Info.plist .
• Windows: HKEY_CLASSES_ROOT\alter with URL Protocol and shell\open\command subkeys.
• Android: <intent-filter> with <data android:scheme="alter">.
• iOS: CFBundleURLSchemes entries in an application's Info.plist .

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 Section 12.3 retrieves the envelope by a DNS query and defines no HTTP retrieval of it. The alter scheme does not displace any existing scheme and does not contradict the path-handling rules of . It coexists with https:, mailto:, and other schemes that an operating system may dispatch on the same surface.

Context Artefact Type context is a member of the artefact-type genus (Section 3.3), naming the reference shape for a context artefact. A context artefact is an 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 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 an address authored by its holder, naming which context artefact is meant. Determining which context is presently acting for a given session or request is out of scope, as the resolution meaning of a facet or an action-path is; see Context Reference Confusion in Section 6.

Artefact Type Genus Membership Beyond context (Section 3.8), this document admits no member to the artefact-type genus and establishes no registry of artefact-type names. A specification that defines a kind of artefact MAY admit a member by naming its artefact-type, stating what an artefact-ref under it denotes and how one is dereferenced, and stating any sub-grammar it imposes on artefact-ref, following the pattern of Section 3.8. A member that needs no sub-grammar conforms to artefact-ref-form as specified, with artefact-ref opaque within the member. artefact-ref is a sequence of ref-segments so that a member can place a scoping name ahead of the reference it scopes, for example alter:example/scope-a/item-7, without folding the two into one segment that only the emitter could read.

Security Considerations See Section 6 below.

Author / Change Controller Blake Morrison, Alter Meridian Pty Ltd, blake@truealter.com. Change control transfers to the IETF if this scheme is later specified by an IETF Stream document.

References , , , .

Operating-System Handler Registration 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.

Linux desktops A .desktop file with MimeType=x-scheme-handler/alter; and a Exec= line invoking the platform resolver.

macOS A CFBundleURLTypes entry with CFBundleURLSchemes=("alter") and a CFBundleURLName of Identity Handle Reference in the application's Info.plist.

Windows Registry entries under HKEY_CLASSES_ROOT\alter:

• A default value of URL:Identity Handle Reference.
• A URL Protocol value of empty string.
• A shell\open\command subkey with the handler invocation.

Android An <intent-filter> declaring <data android:scheme="alter"/> on an Activity capable of performing the resolution procedure of Section 12.3.

iOS A CFBundleURLTypes entry with CFBundleURLSchemes=("alter") in the application's Info.plist . Associated domains and universal links serve https: URLs and do not register a custom scheme. An application that only opens alter: URIs, and handles none, lists alter under LSApplicationQueriesSchemes if it needs to test whether a handler is installed.

Addressing Examples 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. 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 first three, and the seventh, carry no org-scope. A handler resolves them only through a zone association held out of band (Section 3.4). No example addresses an Instrument-tier handle, for the reason given in Section 3.4.

Security Considerations

Verification Mandate The verification mandate of Section 12.3 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).

Action-Address Confusion 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.

Context Reference Confusion 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. This document specifies no resolution path for a context artefact reference other than resolution by its holder, using the holder's own bound credential. It neither describes nor forbids resolution by any other party.

Handler Substitution 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. This document defines no manifest against which a handler binary could be checked.

Path-Component Privacy 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.

Ref-Segment Traversal 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. An artefact-ref of ../secret, one of /etc/passwd (whose first segment is empty), and an artefact-ref-form URI ending in / are therefore 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.

Cross-Scheme Confusion A URI in which the scheme separator alter: is followed by //, the introducer of an authority component, is malformed and MUST be rejected. Implementations MUST NOT silently coerce such a URI to the same URI without the double slash; 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 userinfo delimiter; there is no authority component in an alter: URI.

Form Confusion 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-Domain Confusion handle-name admits U+002E FULL STOP, because the tier productions it mirrors from 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 ; no other label within a handle-name carries any.

IRI Considerations When an alter: URI is presented in IRI form per with non-ASCII characters in the action-path, implementations MUST apply the conversion procedure of 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.

IANA Considerations Provisional registration of the alter URI scheme in the Uniform Resource Identifier (URI) Schemes registry was requested of IANA on 30 September 2026, under Section 4 and the procedure of Section 7.2, and IANA registered the scheme as Provisional on 5 October 2026, citing revision 03 of this document. Section 11 and Section 16.2 cross-reference the registration. The template submitted is:

• 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.
• References: This document; ; .

Permanent registration, against the requirements of Section 3, is the intended upgrade path once the scheme specification stabilises.

Acknowledgements The scheme builds on the ~handle identity primitive defined in and the tier taxonomy of . The lexical choice of tilde for the handle prefix is informed by and by the long-standing shell convention that the tilde denotes a named principal.

Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. A Uniform Resource Identifier (URI) is a compact sequence of characters that identifies an abstract or physical resource. This specification defines the generic URI syntax and a process for resolving URI references that might be in relative form, along with guidelines and security considerations for the use of URIs on the Internet. The URI syntax defines a grammar that is a superset of all valid URIs, allowing an implementation to parse the common components of a URI reference without knowing the scheme-specific requirements of every possible identifier. This specification does not define a generative grammar for URIs; that task is performed by the individual specifications of each URI scheme. [STANDARDS-TRACK] Internet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK] This document updates the guidelines and recommendations, as well as the IANA registration processes, for the definition of Uniform Resource Identifier (URI) schemes. It obsoletes RFC 4395. This document defines a new protocol element, the Internationalized Resource Identifier (IRI), as a complement of the Uniform Resource Identifier (URI). An IRI is a sequence of characters from the Universal Character Set (Unicode/ISO 10646). A mapping from IRIs to URIs is defined, which means that IRIs can be used instead of URIs, where appropriate, to identify resources. The approach of defining a new protocol element was chosen instead of extending or changing the definition of URIs. This was done in order to allow a clear distinction and to avoid incompatibilities with existing software. Guidelines are provided for the use and deployment of IRIs in various protocols, formats, and software components that currently deal with URIs. The Domain Name System Security Extensions (DNSSEC) add data origin authentication and data integrity to the Domain Name System. This document introduces these extensions and describes their capabilities and limitations. This document also discusses the services that the DNS security extensions do and do not provide. Last, this document describes the interrelationships between the documents that collectively describe DNSSEC. [STANDARDS-TRACK] Alter Meridian Pty Ltd Alter Meridian Pty Ltd Informative References Alter Meridian Pty Ltd Alter Meridian Pty Ltd

Change Log

draft-morrison-alter-uri-scheme-05

• Rewrite the prose against the drafting rules and pin each citation of another Internet-Draft to its latest posted revision. The grammar, the examples and every requirement are unchanged.

draft-morrison-alter-uri-scheme-04

• Correct the section references into : the envelope record is Section 7, and the resolution and verification procedure is Section 12.3. Revision 03 cited Sections 5 and 8 of that document for them.
• State that a handle carries no zone of its own. Step 2 of Section 3.4 takes the zone from org-scope, or from an association held out of band, and otherwise treats the reference as unresolvable; it no longer points at a handle-to-zone procedure in , because that document defines none. Note this in the org-scope definition and under the Addressing Examples.
• Remove the statement that falls back to an HTTPS well-known surface for envelope retrieval. defines no such fallback, and the statement contradicted Section 3.7. Drop the [RFC8615] reference, since nothing else cited it.
• State that an Instrument-tier handle is not an independent handle and has no envelope of its own, matching Section 2, and that a handler MUST NOT treat one as naming an independent principal. Correct the Introduction to match, remove the Instrument-tier addressing example, and attribute the cc- prefix in the ABNF comments to rather than . The grammar is unchanged.
• Correct the section references: provisional registration is Section 4, the registration procedure is Section 7.2, and the requirements for permanent registration are Section 3.
• Record in the Abstract, Status and IANA Considerations that provisional registration was requested on 30 September 2026 and that IANA registered the scheme as Provisional on 5 October 2026.
• Correct the iOS registration text: a custom scheme is registered with CFBundleURLTypes in Info.plist, as on macOS; associated domains and universal links serve https: URLs.
• Describe the one command-line client that accepts alter: URIs as it is: it does not register as an operating-system handler and does not run the resolution procedure. Remove the statement that it registers itself as the default handler.
• Reduce the Artefact Type Genus Membership subsection to the rule for admitting a member, and remove the list of members that named one implementation's own artefact kinds and file titles. Replace the examples that used them in Terminology and under Ref-Segment Traversal with generic ones.
• Replace the closing paragraph of Context Reference Confusion: this document specifies no resolution path for a context artefact reference other than its holder's, and neither describes nor forbids resolution by another party.
• Remove a SHOULD that depended on a handler manifest no specification defines.
• Replace the hand-typed BCP 14 paragraph with the standard boilerplate, use a neutral handle in the examples, remove a statement of the document's own contribution from the Abstract, and name in words the documents the Abstract relies on, where it had cited them by tag.
• Describe the malformed forms under Ref-Segment Traversal and Cross-Scheme Confusion without spelling each as a complete URI. The requirements are unchanged.
• Shorten the Abstract, Introduction, Status and Scheme Semantics prose. No requirement changes.
• Correct step 5 of Scheme Semantics, where a facet or action-path was dispatched to a resolver named by the envelope. The envelope names none; the step now defers to the specification that defines the facet or action surface.

draft-morrison-alter-uri-scheme-03

• Add a Handle-Domain Confusion security consideration. Because handle-name admits "." in order to carry the .bot tier suffix of , 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.
• Partition the scheme into two disjoint reference forms carried under one scheme name: handle-ref-form, unchanged from revision 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 MUST NOT begin an artefact type.
• Add Artefact type and Artefact reference to Terminology, defining the shape of the reference only, and state that this document assigns artefact resolution no meaning.
• Make artefact-ref a sequence of ref-segments separated by "/", so that a scoping name can precede the reference it scopes, and widen each segment to 1*( unreserved / pct-encoded ) so that a ~handle or its percent-encoded form can be carried. Make the artefact-ref component OPTIONAL so that a bare artefact type is expressible.
• Add Form Confusion and Ref-Segment Traversal security considerations. A ref-segment MUST NOT be "." or "..", and is rejected on its textual form, after pct-encoded decoding, before any resolution.
• Add context as a member of the artefact-type genus, with a Context Artefact Type subsection specifying context-ref-form and the RESERVED personal literal, and a Context Reference Confusion security consideration. Define org-scope as a DNS zone qualifier that carries no acting context.
• Add an Artefact Type Genus Membership subsection listing further members of the genus.
• Repoint the informative Apple reference to the current CFBundleURLTypes page. The mechanism cited is unchanged.

draft-morrison-alter-uri-scheme-02

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

draft-morrison-alter-uri-scheme-01

• Editorial and reference alignment.

draft-morrison-alter-uri-scheme-00

• Initial submission. Upgrades the provisional registration recorded in Section 11.