juwan.hwang@proton.me

Applications Independent Submission URI scheme ARS-1 identifier permalink 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.

This specification 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.

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 and . This specification uses ABNF (Augmented Backus-Naur Form) as defined by and the terminal rules from .

An implementation of the "ars" URI scheme conforms to this specification if:

• It parses "ars" URIs in accordance with the ABNF grammar in .
• It performs canonicalization and comparison in accordance with and .
• It does not impose additional syntactic constraints beyond those defined herein.
• It delegates ARS-1 Reference generation and verification to a conforming ARS-1 implementation.

Conforming ARS-1 implementations are NOT required to support the "ars" URI form. The canonical ARS-1 Reference representation is always the Local Reference form defined in ARS-1 Section 21.

This ABNF is adapted from and is consistent with the ARS-1 canonical forms.

The "ars" URI has the following structure:

/ ]]>

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.

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.

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.

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

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

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.

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.

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.

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

This is a deliberate restriction for the provisional registration. The character set is a subset of the "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 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.

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:

Only "ars://AEV/..." is the canonical URI for the "AEV" namespace. The URI scheme does not perform case normalization on the authority component. 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.

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.

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):

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.

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

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

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

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.

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

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.

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

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

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

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.

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 () or percent-encoding of UTF-8 octets.

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

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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

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:

, This document.

Provisional registration is requested. The "ars" scheme is intended for use by the ARS-1 protocol community. If the scheme gains broader adoption, a transition to permanent registration may be requested in a future revision.

juwan.hwang@proton.me

The ARS-1 protocol and its 23 independent implementations provided the foundation for this URI scheme specification.