Independent Submission J. Hwang Internet-Draft 22 August 2026 Intended status: Informational Expires: 23 February 2027 ARS URI Scheme: A URI Scheme for ARS-1 References draft-juwan-ars-uri-00 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. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Hwang Expires 23 February 2027 [Page 1] Internet-Draft ars URI Scheme August 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Notational Conventions . . . . . . . . . . . . . . . . . 3 2. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. URI Scheme Syntax . . . . . . . . . . . . . . . . . . . . . . 4 3.1. ABNF Grammar . . . . . . . . . . . . . . . . . . . . . . 4 3.2. URI Structure . . . . . . . . . . . . . . . . . . . . . . 5 3.3. Authority Component . . . . . . . . . . . . . . . . . . . 6 3.4. Path Component . . . . . . . . . . . . . . . . . . . . . 6 3.5. Absent Components . . . . . . . . . . . . . . . . . . . . 6 3.6. Examples . . . . . . . . . . . . . . . . . . . . . . . . 7 4. URI Semantics . . . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Identification . . . . . . . . . . . . . . . . . . . . . 7 4.2. Non-Retrieval Semantics . . . . . . . . . . . . . . . . . 7 4.3. Relationship to the Canonical Reference . . . . . . . . . 7 5. Namespace Semantics . . . . . . . . . . . . . . . . . . . . . 8 5.1. Namespace as Authority . . . . . . . . . . . . . . . . . 8 5.2. ASCII-Only Restriction . . . . . . . . . . . . . . . . . 8 5.3. Case Sensitivity . . . . . . . . . . . . . . . . . . . . 8 6. Local Reference Semantics . . . . . . . . . . . . . . . . . . 9 6.1. Prefix . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. Payload . . . . . . . . . . . . . . . . . . . . . . . . . 9 6.3. Separator . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Canonicalization . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Scheme Name . . . . . . . . . . . . . . . . . . . . . . . 9 7.2. Namespace . . . . . . . . . . . . . . . . . . . . . . . . 10 7.3. Local Reference . . . . . . . . . . . . . . . . . . . . . 10 7.4. Percent-Encoding . . . . . . . . . . . . . . . . . . . . 10 7.5. Summary of Canonicalization Rules . . . . . . . . . . . . 10 8. Encoding and Percent-Encoding . . . . . . . . . . . . . . . . 11 8.1. Character Set . . . . . . . . . . . . . . . . . . . . . . 11 8.2. Percent-Encoding Rules . . . . . . . . . . . . . . . . . 11 8.3. Percent-Encoding is Invalid . . . . . . . . . . . . . . . 11 8.4. Internationalized Namespace Support . . . . . . . . . . . 11 9. Resolution Semantics . . . . . . . . . . . . . . . . . . . . 11 9.1. No Implied Resolution Protocol . . . . . . . . . . . . . 12 9.2. Resolution Methods . . . . . . . . . . . . . . . . . . . 12 9.3. Resolution and Verification . . . . . . . . . . . . . . . 12 9.4. Authorization . . . . . . . . . . . . . . . . . . . . . . 12 10. Interoperability Considerations . . . . . . . . . . . . . . . 12 10.1. Relationship to HTTP(S) URLs . . . . . . . . . . . . . . 13 Hwang Expires 23 February 2027 [Page 2] Internet-Draft ars URI Scheme August 2026 10.2. Compatibility with ARS-1 Core . . . . . . . . . . . . . 13 10.3. Parser Considerations . . . . . . . . . . . . . . . . . 13 10.4. QR Codes and Print Media . . . . . . . . . . . . . . . . 13 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11.1. No Implied Trust . . . . . . . . . . . . . . . . . . . . 13 11.2. Checksum Integrity . . . . . . . . . . . . . . . . . . . 14 11.3. Namespace Collision . . . . . . . . . . . . . . . . . . 14 11.4. Case Sensitivity Risks . . . . . . . . . . . . . . . . . 14 11.5. Resolution Security . . . . . . . . . . . . . . . . . . 14 11.6. Phishing and Spoofing . . . . . . . . . . . . . . . . . 14 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 12.1. Registration Template . . . . . . . . . . . . . . . . . 15 12.2. Registration Status . . . . . . . . . . . . . . . . . . 15 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 13.1. Normative References . . . . . . . . . . . . . . . . . . 15 13.2. Informative References . . . . . . . . . . . . . . . . . 16 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 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]. Hwang Expires 23 February 2027 [Page 3] Internet-Draft ars URI Scheme August 2026 2. Conformance An implementation of the "ars" URI scheme conforms to this specification if: * It parses "ars" URIs in accordance with the ABNF grammar in Section 3. * It performs canonicalization and comparison in accordance with Section 7 and Section 9. * It does not impose additional syntactic constraints beyond those defined herein. * It delegates ARS-1 Reference generation and verification to a conforming ARS-1 [ARS1] 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. 3. URI Scheme Syntax 3.1. ABNF Grammar Hwang Expires 23 February 2027 [Page 4] Internet-Draft ars URI Scheme August 2026 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:/// Where: * "ars" is the scheme name. * "//" indicates the presence of an authority component. Hwang Expires 23 February 2027 [Page 5] Internet-Draft ars URI Scheme August 2026 * is the authority component and carries the ARS-1 Namespace. * "/" is the path delimiter separating the authority from the 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. Hwang Expires 23 February 2027 [Page 6] Internet-Draft ars URI Scheme August 2026 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. Hwang Expires 23 February 2027 [Page 7] Internet-Draft ars URI Scheme August 2026 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. Hwang Expires 23 February 2027 [Page 8] Internet-Draft ars URI Scheme August 2026 [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". Hwang Expires 23 February 2027 [Page 9] Internet-Draft ars URI Scheme August 2026 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 +=======================+==================+==================+ | Component | Case Sensitivity | Canonical Form | +=======================+==================+==================+ | Scheme name | Case-insensitive | Lowercase "ars" | +-----------------------+------------------+------------------+ | Authority / Namespace | Case-sensitive, | As defined by | | | byte-for-byte | Profile | +-----------------------+------------------+------------------+ | Path / Local Ref | Uppercase only | Canonical | | | | uppercase | +-----------------------+------------------+------------------+ | Percent-encoding | Rejected | No percent- | | | | encoding | +-----------------------+------------------+------------------+ Hwang Expires 23 February 2027 [Page 10] Internet-Draft ars URI Scheme August 2026 Table 1: Canonicalization Rules 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 Hwang Expires 23 February 2027 [Page 11] Internet-Draft ars URI Scheme August 2026 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 Hwang Expires 23 February 2027 [Page 12] Internet-Draft ars URI Scheme August 2026 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. Hwang Expires 23 February 2027 [Page 13] Internet-Draft ars URI Scheme August 2026 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]. Hwang Expires 23 February 2027 [Page 14] Internet-Draft ars URI Scheme August 2026 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 Change controller: Juwan Hwang References: [ARS1], This document. 12.2. Registration Status 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. 13. References 13.1. Normative References [ARS1] Hwang, J., "ARS-1 -- Generic Archival Reference System, v1.0-rc2 (Frozen)", August 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, January 2005, . [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, . Hwang Expires 23 February 2027 [Page 15] Internet-Draft ars URI Scheme August 2026 [RFC7595] Thaler, D., Ed., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", RFC 7595, December 2015, . 13.2. Informative References [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005, . Acknowledgments The ARS-1 protocol and its 23 independent implementations provided the foundation for this URI scheme specification. Author's Address Juwan Hwang Email: juwan.hwang@proton.me Hwang Expires 23 February 2027 [Page 16]