ARS URI Scheme: A URI Scheme for ARS-1 References

Internet-Draft	ars URI Scheme	August 2026
Hwang	Expires 23 February 2027	[Page]

Abstract

This document defines the "ars" URI scheme for representing ARS-1 References in a syntactically valid URI form. ARS-1 defines a deterministic, cryptographically derived reference protocol for assigning stable public identifiers to durable digital entities. The "ars" URI scheme provides a standard URI notation for these references, enabling their use in hyperlinks, QR codes, metadata fields, and other URI-consuming contexts.¶

This specification does not redefine the ARS-1 Reference generation pipeline, canonicalization rules, or verification logic. Those are normatively defined by ARS-1. This document defines only the URI syntax, encoding, comparison, and resolution semantics for the "ars" 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 23 February 2027.¶

1. Introduction

This specification defines the "ars" URI scheme for representing ARS-1 References [ARS1] in a syntactically valid URI form. ARS-1 defines a deterministic, cryptographically derived reference protocol for assigning stable public identifiers to durable digital entities. The "ars" URI scheme provides a standard URI notation for these references, enabling their use in hyperlinks, QR codes, metadata fields, and other URI-consuming contexts.¶

This specification does not redefine the ARS-1 Reference generation pipeline, canonicalization rules, or verification logic. Those are normatively defined by ARS-1 [ARS1]. This document defines only the URI syntax, encoding, comparison, and resolution semantics for the "ars" scheme.¶

1.1. Notational Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119] and [RFC8174].¶

This specification uses ABNF (Augmented Backus-Naur Form) as defined by [RFC5234] and the terminal rules from [RFC3986].¶

3. URI Scheme Syntax

3.1. ABNF Grammar

ars-uri       = "ars://" authority "/" local-reference

authority     = namespace

namespace     = 1*( ALPHA / DIGIT / "-" / "." )
                ; ASCII-only, restricted to RFC 3986 reg-name
                ; compatible characters (unreserved / sub-delims
                ; subset). Underscore is excluded to maintain
                ; compatibility with RFC 3986 authority syntax.
                ; Case-sensitive: byte-for-byte canonical
                ; representation. MUST exactly match the
                ; canonical Namespace string as serialized in
                ; the CanonicalReferenceRecord (ARS-1 Section 30).

local-reference = prefix "-" payload

prefix        = 1*4ALNUM-UPPER
                ; MUST match one uppercase letter followed by
                ; 1-3 uppercase alphanumeric (ARS-1 Section 19)
                ; canonical uppercase only (ARS-1 Section 31)

payload       = 1*ALNUM-UPPER
                ; MUST consist of symbols from the ARS-1 alphabet
                ; (ARS-1 Section 23):
                ; 0123456789ABCDEFGHJKMNPQRSTVWXYZ
                ; variable length; final symbol is the checksum

ALNUM-UPPER   = DIGIT / %x41-48 / %x4A / %x4B / %x4D-50 /
                %x51-54 / %x56-57 / %x58-5A
                ; 0-9, A-H, J, K, M-P, Q-T, V, W, X-Z
                ; (excludes I, L, O, U per ARS-1 Section 23)

This ABNF is adapted from [RFC3986] and is consistent with the ARS-1 canonical forms.¶

3.2. URI Structure

The "ars" URI has the following structure:¶

ars://<namespace>/<local-reference>

Where:¶

"ars" is the scheme name.¶
"//" indicates the presence of an authority component.¶
<namespace> is the authority component and carries the ARS-1 Namespace.¶
"/" is the path delimiter separating the authority from the local reference.¶
<local-reference> is the path component and carries the ARS-1 Local Reference.¶

3.3. Authority Component

The authority component carries the ARS-1 Namespace identifier as defined in ARS-1 Section 30. The authority is NOT a network hostname; it does not imply a DNS resolution or network connection. The authority component in the "ars" scheme is a logical namespace identifier, not a transport address.¶

The authority component MUST be interpreted as an opaque ARS Namespace identifier and MUST NOT be processed using DNS host normalization.¶

In particular, implementations MUST NOT:¶

lowercase the authority;¶
perform DNS resolution;¶
apply IDNA processing;¶
interpret the authority as an IP address;¶
infer a port or userinfo component.¶

3.4. Path Component

The path component carries the ARS-1 Local Reference as defined in ARS-1 Section 21. The path consists of a Prefix and a Payload separated by a single ASCII hyphen ("-", U+002D). The path component does NOT include a leading slash; the slash preceding the local reference in the URI form is a structural delimiter between the authority and the path.¶

3.5. Absent Components

The "ars" scheme does not use a query component. A conforming "ars" URI MUST NOT contain a query component ("?..."). An "ars" URI containing a query component is invalid and MUST be rejected by a conforming parser.¶

This version of the "ars" scheme does not define fragment semantics. A canonical "ars" URI MUST NOT contain a fragment component ("#..."). While [RFC3986] treats the fragment as a generic URI mechanism whose syntax and usage are orthogonal to scheme definition, the "ars" scheme does not assign meaning to fragments, and a conforming canonical "ars" URI does not include one.¶

The "ars" URI does not use a port number or userinfo ("user@"). An "ars" URI containing a port or userinfo component is invalid and MUST be rejected by a conforming parser.¶

3.6. Examples

ars://AEV/NX-103MACV9M
ars://AEV/CJ3-106Q
ars://EXAMPLE/MR-X4928V

4. URI Semantics

4.1. Identification

An "ars" URI identifies the ARS-1 Reference composed of the Namespace in the authority component and the Local Reference in the path component. Two "ars" URIs identify the same ARS-1 Reference if and only if they are character-for-character identical after canonicalization (Section 7).¶

4.2. Non-Retrieval Semantics

The "ars" scheme does NOT imply a specific retrieval protocol. Unlike "http" or "ftp", resolving an "ars" URI does not intrinsically retrieve a representation over a network. Resolution semantics are defined by the deployment context (ARS-1 Section 64) and MAY involve:¶

Direct lookup in a local or remote database.¶
Dereferencing to an HTTP(S) URL via a namespace-specific resolution service.¶
In-process interpretation by an application that recognizes the scheme.¶

4.3. Relationship to the Canonical Reference

The canonical ARS-1 Reference is always the Local Reference form defined in ARS-1 Section 21. The "ars" URI is a URI representation of a (Namespace, Local Reference) pair. The URI structural delimiters ("ars://", "/") are NOT part of the Reference itself.¶

5. Namespace Semantics

5.1. Namespace as Authority

The Namespace occupies the authority position in the "ars" URI. This design decision is deliberate: it places the Namespace in a structurally significant URI component, enabling namespace-aware processing without parsing the path.¶

5.2. ASCII-Only Restriction

This version of the "ars" URI scheme supports only ASCII namespaces. The "namespace" ABNF rule (Section 3.1) restricts the character set to:¶

ALPHA / DIGIT / "-" / "."

This is a deliberate restriction for the provisional registration. The character set is a subset of the [RFC3986] "reg-name" production ("unreserved / sub-delims"), ensuring that the authority value is syntactically valid as a URI authority component under the generic URI syntax. Underscore ("_") is excluded because it is not permitted in "unreserved" or "sub-delims" per [RFC3986] Section 2.2.¶

ARS-1 Section 31 permits Application Profiles to choose ASCII-only or Unicode NFC for Namespace encoding. This URI scheme specification supports only the ASCII-only subset. Application Profiles that use Unicode NFC Namespaces MUST define their own URI encoding rules or use a different URI representation.¶

5.3. Case Sensitivity

The Namespace in the "ars" URI is case-sensitive and uses byte-for-byte canonical representation. The Namespace string in the URI MUST exactly match the canonical Namespace string as serialized in the CanonicalReferenceRecord (ARS-1 Section 30).¶

This means:¶

ars://AEV/NX-103MACV9M   (canonical)
ars://aev/NX-103MACV9M   (different URI - different Namespace)
ars://Aev/NX-103MACV9M   (different URI - different Namespace)

Only "ars://AEV/..." is the canonical URI for the "AEV" namespace. The URI scheme does not perform case normalization on the authority component.¶

[RFC3986] defines the authority component using generic URI syntax and specifies case-insensitive comparison for the host subcomponent. The "ars" scheme does not assign DNS host semantics to its authority value. Instead, the entire authority value is an ARS Namespace identifier and is compared byte-for-byte according to this specification.¶

6. Local Reference Semantics

6.1. Prefix

The Prefix occupies the first portion of the path component, before the hyphen. The Prefix MUST conform to ARS-1 Section 19:¶

The Prefix pattern is: one uppercase letter (A through Z) followed by one to three uppercase alphanumeric characters (A through Z, or 0 through 9), yielding a total length of 2 to 4 characters.¶

The Prefix MUST be canonical uppercase (ARS-1 Section 31). Lowercase prefix characters are syntactically invalid in an "ars" URI.¶

6.2. Payload

The Payload occupies the portion of the path component after the hyphen. The Payload MUST consist entirely of symbols from the ARS-1 alphabet (ARS-1 Section 23):¶

0123456789ABCDEFGHJKMNPQRSTVWXYZ

The final symbol of the Payload is the checksum (ARS-1 Sections 42-44). The Payload is variable length and MUST NOT exceed the maximum payload length defined by the applicable Application Profile.¶

6.3. Separator

The Prefix and Payload MUST be separated by exactly one ASCII hyphen ("-", U+002D). Multiple hyphens or other separator characters are syntactically invalid.¶

7. Canonicalization

7.1. Scheme Name

The scheme name "ars" is case-insensitive per URI syntax ([RFC3986] Section 3.1). The canonical representation uses lowercase "ars".¶

ars://AEV/NX-103MACV9M   (canonical)
ARS://AEV/NX-103MACV9M   (equivalent - non-canonical scheme casing)
Ars://AEV/NX-103MACV9M   (equivalent - non-canonical scheme casing)

Implementations MUST accept any casing of the scheme name but SHOULD produce the lowercase canonical form.¶

7.2. Namespace

The Namespace is case-sensitive and byte-for-byte canonical. No case normalization is performed. The URI representation MUST preserve the canonical Namespace representation exactly as defined by the Application Profile.¶

7.3. Local Reference

The Local Reference (Prefix and Payload) MUST be canonical uppercase. No case folding is permitted.¶

7.4. Percent-Encoding

The Namespace and Local Reference components of the canonical "ars" URI do not contain characters that require percent-encoding. The Namespace is restricted to ASCII alphanumeric characters, hyphens, and periods. The Local Reference is restricted to the ARS-1 alphabet and a single hyphen separator.¶

Therefore, canonical "ars" URIs MUST NOT contain percent-encoded octets. A percent-encoded octet in an "ars" URI indicates a non-canonical or invalid form.¶

7.5. Summary of Canonicalization Rules

Table 1: Canonicalization Rules
Component	Case Sensitivity	Canonical Form
Scheme name	Case-insensitive	Lowercase "ars"
Authority / Namespace	Case-sensitive, byte-for-byte	As defined by Profile
Path / Local Ref	Uppercase only	Canonical uppercase
Percent-encoding	Rejected	No percent-encoding

8. Encoding and Percent-Encoding

8.1. Character Set

The "ars" URI is representable entirely in ASCII. No non-ASCII characters appear in a canonical "ars" URI.¶

8.2. Percent-Encoding Rules

Per [RFC3986] Section 2.1, percent-encoding is a mechanism to represent data octets that are not otherwise representable. In the "ars" scheme:¶

The Namespace is restricted to ALPHA / DIGIT / "-" / ".". None of these characters are reserved or require percent-encoding in the authority component.¶
The Local Reference is restricted to ALNUM-UPPER and a single hyphen. None of these characters are reserved or require percent-encoding in the path component.¶

Therefore, canonical "ars" URIs contain no percent-encoded octets.¶

8.3. Percent-Encoding is Invalid

A percent sign ("%", U+0025) is not permitted by the canonical "ars" syntax. An "ars" URI containing a percent-encoded octet is non-canonical and MUST be rejected as invalid by a conforming "ars" URI parser.¶

Implementations MUST NOT treat percent-encoded octets as equivalent to unencoded characters in an "ars" URI. There is exactly one canonical representation for each "ars" URI; percent-encoding does not produce an equivalent form.¶

8.4. Internationalized Namespace Support

This version of the "ars" URI scheme does NOT support non-ASCII namespaces. Application Profiles that use Unicode NFC Namespaces (per ARS-1 Section 31) MUST NOT use the "ars" URI scheme directly. Future versions of this specification MAY define internationalized namespace support using IRIs ([RFC3987]) or percent-encoding of UTF-8 octets.¶

9. Resolution Semantics

9.1. No Implied Resolution Protocol

The "ars" scheme does not define or mandate a specific resolution protocol. Resolution of an "ars" URI to an entity, resource, or representation is deployment-defined (ARS-1 Section 64).¶

9.2. Resolution Methods

A deployment MAY resolve "ars" URIs via:¶

Local lookup: The application maintains or queries a local registry mapping (Namespace, Local Reference) to entity records.¶
HTTP(S) dereferencing: The Application Profile defines a canonical HTTP(S) URL template (ARS-1 Section 70) that embeds the ARS Reference. Resolution involves HTTP retrieval of the canonical URL.¶
Scheme handler: An operating system or application framework may register a handler for the "ars" scheme that redirects to an appropriate resolution service.¶
No resolution: The "ars" URI may be used purely as an identifier with no associated resolution mechanism.¶

9.3. Resolution and Verification

ARS-1 Reference verification (ARS-1 Section 66) is a separate operation from URI resolution. Verifying that an "ars" URI contains a syntactically valid and checksum-valid Reference does NOT require resolution. Resolution may return any of the outcomes defined in ARS-1 Section 64 (existing entity, retired entity, tombstone, missing entity).¶

9.4. Authorization

Resolution of an "ars" URI MAY require authorization. The "ars" scheme itself does not define an authorization mechanism. Authorization is the responsibility of the resolution service or Application Profile.¶

10. Interoperability Considerations

10.1. Relationship to HTTP(S) URLs

An Application Profile MAY define canonical HTTP(S) URLs that embed ARS References (ARS-1 Section 70). The "ars" URI form and canonical HTTP URL form are independent representations. An Application Profile MUST define which form, if any, is canonical for its deployment.¶

When both forms are used, the HTTP(S) URL is a resolution mechanism, while the "ars" URI is the identifier. The "ars" URI is the more stable form: HTTP URLs may change due to domain migration, CDN reconfiguration, or HTTP-to-HTTPS upgrades, while the "ars" URI is invariant.¶

10.2. Compatibility with ARS-1 Core

The "ars" URI scheme is compatible with all ARS-1 Application Profiles that use ASCII-only Namespaces. Application Profiles with Unicode NFC Namespaces are not directly representable in this version of the "ars" scheme.¶

10.3. Parser Considerations

Implementations parsing "ars" URIs SHOULD use a general-purpose URI parser (e.g., one conforming to [RFC3986]) and then validate the authority and path components against the ABNF in Section 3.1. Implementations MUST NOT assume that "ars" URIs follow HTTP URL conventions (e.g., no default port, no query string, no fragment).¶

10.4. QR Codes and Print Media

The "ars" URI is designed to be compact enough for QR code encoding. The all-uppercase, ASCII-only character set maximizes QR code alphanumeric mode efficiency.¶

11. Security Considerations

11.1. No Implied Trust

The existence of a syntactically valid "ars" URI does NOT imply that the referenced entity exists, is trustworthy, or is accessible. An "ars" URI is a cryptographically derived identifier, not a capability or access token.¶

11.2. Checksum Integrity

The "ars" URI includes a checksum symbol (ARS-1 Sections 42-44) as the final character of the Payload. The checksum provides probabilistic detection of transcription errors. For a non-identical input, an incorrect checksum is expected to be detected with probability 31/32 under the cryptographic assumptions described by ARS-1 (Hard Invariants 81 and 82).¶

The checksum provides no deterministic detection guarantee for any specific error class and MUST NOT be interpreted as authentication, cryptographic integrity, or proof of identity.¶

11.3. Namespace Collision

The "ars" scheme does not maintain a global namespace registry. Different deployments may use the same Namespace string with different semantics. Consumers of "ars" URIs MUST verify the Namespace identity through the applicable Application Profile before relying on the reference.¶

11.4. Case Sensitivity Risks

The Namespace is case-sensitive. Consumers MUST NOT perform case normalization on the authority component. Doing so may cause the URI to reference a different namespace. For example, "ars://AEV/..." and "ars://aev/..." are different URIs that reference different namespaces.¶

11.5. Resolution Security

When an "ars" URI is resolved to an HTTP(S) URL, the security of the resolution process (TLS, authentication, access control) is the responsibility of the resolution service. The "ars" scheme does not provide transport-layer security.¶

11.6. Phishing and Spoofing

Malicious actors may construct syntactically valid "ars" URIs with arbitrary Namespace and Local Reference values. Applications displaying "ars" URIs SHOULD verify the checksum before display and SHOULD indicate when a Reference cannot be verified.¶

12. IANA Considerations

This document requests provisional registration of the "ars" URI scheme in the IANA Uniform Resource Identifier (URI) Schemes registry, in accordance with [RFC7595].¶

12.1. Registration Template

Scheme name:: ars¶
Status:: Provisional¶
Applications/protocols that use this scheme:: ARS-1 Generic Archival Reference System. Used to represent ARS-1 References as URIs for use in hyperlinks, QR codes, metadata, and other URI-consuming contexts.¶
Contact:: Juwan Hwang <juwan.hwang@proton.me>¶
Change controller:: Juwan Hwang <juwan.hwang@proton.me>¶
References:: [ARS1], This document.¶

[ARS1]: Hwang, J., "ARS-1 -- Generic Archival Reference System, v1.0-rc2 (Frozen)", August 2026, <https://github.com/Juwan-Hwang/ARS-1/blob/main/spec/ARS-1.md>.
[RFC2119]: Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC8174]: Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC3986]: Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, January 2005, <https://www.rfc-editor.org/info/rfc3986>.
[RFC5234]: Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, 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", RFC 7595, December 2015, <https://www.rfc-editor.org/info/rfc7595>.

13.2. Informative References

[RFC3987]: Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005, <https://www.rfc-editor.org/info/rfc3987>.