Independent Submission S. Li Internet-Draft RTTP & IQA Organization Intended status: Informational 24 September 2026 Expires: 28 March 2027 The rttp and iqa URI Schemes: Derived-Address Intent and Attestation Addressing draft-li-rttp-iqa-addressing-00 Abstract This document specifies two companion URI schemes built on one shared addressing model, in which the address of a subject is derived by computation from the authority and no lookup service, registry, or name-resolution system is consulted when the URI is used. The "rttp" scheme names a claim of intent directed at an identified subject; the "iqa" scheme names the attestation standing of an identified subject, as reported by one of three named organs, and carries no proof and no credential. The two are deliberately paired: intent addressing carries what is claimed, attestation carries whether the claimant is verified. Both schemes parse fail-closed, and the document states the requirements a client MUST satisfy when it handles such URIs, to avoid the failure modes that short, user-embeddable strings invite: using the authority as a navigation target (open redirect), using a registered handler as a general-purpose launcher, and, for "iqa", a parse that looks like a certification. This document is not an Internet Standard. It is an Informational specification of two experimental addressing schemes, published for the public record. Disclaimer This document is not on the Internet Standards Track. It is not a standard, does not propose a standard, and acquires no standardisation status from publication. The two URI schemes it defines are experimental addressing schemes. As IANA URI schemes, "rttp" holds CRI scheme number 27 and "iqa" is in expert review. The registration status of both schemes is recorded in Section 9. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Li Expires 28 March 2027 [Page 1] Internet-Draft rttp and iqa URI Schemes September 2026 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 28 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 4 3. The Shared Addressing Model . . . . . . . . . . . . . . . . . 5 4. The rttp URI Scheme . . . . . . . . . . . . . . . . . . . . . 5 4.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Reserved Characters and Exclusions . . . . . . . . . . . 6 4.3. Default Operation . . . . . . . . . . . . . . . . . . . . 6 4.4. The Address: ROUTE_SHARD Derivation . . . . . . . . . . . 7 4.5. Client Requirements . . . . . . . . . . . . . . . . . . . 7 4.5.1. No Navigation to the URI . . . . . . . . . . . . . . 7 4.5.2. Scheme Prefix Check . . . . . . . . . . . . . . . . . 8 4.5.3. Consent, Never Silence . . . . . . . . . . . . . . . 8 5. The iqa URI Scheme . . . . . . . . . . . . . . . . . . . . . 8 5.1. Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 8 5.2. Reserved Characters and Exclusions . . . . . . . . . . . 9 5.3. Default Operation . . . . . . . . . . . . . . . . . . . . 9 5.4. Action Safety Classes . . . . . . . . . . . . . . . . . . 10 5.5. Client Requirements . . . . . . . . . . . . . . . . . . . 10 5.5.1. Parsing Is Not Attestation . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6.1. The rttp scheme . . . . . . . . . . . . . . . . . . . . . 11 6.2. The iqa scheme . . . . . . . . . . . . . . . . . . . . . 11 7. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13 Li Expires 28 March 2027 [Page 2] Internet-Draft rttp and iqa URI Schemes September 2026 8. Internationalization Considerations . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9.1. The "rttp" URI Scheme . . . . . . . . . . . . . . . . . . 13 9.2. The "iqa" URI Scheme . . . . . . . . . . . . . . . . . . 14 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 11. Normative References . . . . . . . . . . . . . . . . . . . . 15 12. Informative References . . . . . . . . . . . . . . . . . . . 15 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 1. Introduction Most URI schemes name a location: the authority identifies a host to be contacted. This document specifies two schemes that name something else. The "rttp" scheme names a claim of intent directed at an identified subject. The "iqa" scheme names the attestation standing of an identified subject, as reported by a named organ. In both cases, what a client does with what the URI names is defined by the scheme; where the subject might be reached is not part of the URI and is not resolved through any lookup service. The two schemes share one addressing model and are deliberately paired: intent addressing carries what is claimed, attestation carries whether the claimant is verified. Implementations and deployments should treat them as one model rather than as two unrelated namespaces. Four properties follow from the shared model and are normative in this document: * the address is *derived by computation* from the authority (Sections 4.4 and 5.1, and [IQA-SPEC]); * there is *no lookup*: no DNS, no registry query, no fetch (Sections 4.5 and 5.5); * the URI is a *claim, not a proof* (Sections 5.2 and 6); * both schemes fail closed: non-conforming input is rejected, never repaired (Sections 4 and 5). *Naming note.* IQA denotes *Identity* Quality Assurance. It is not affiliated with the *Institute* of Quality Assurance (which became the Chartered Quality Institute in 2007), nor is it the computer- vision field of *Image* Quality Assessment. RTTP denotes *Resonant Time Transfer Protocol*. It is not RTP: what it names is a claim, not a session or a data stream. Li Expires 28 March 2027 [Page 3] Internet-Draft rttp and iqa URI Schemes September 2026 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. This document uses the ABNF notation of [RFC5234] and the URI syntax of [RFC3986]. Terminology: authority The three-segment component of either scheme: .. for "rttp" (Section 4.1) and .. for "iqa" (Section 5.1). It is a name, not a host name, and is never resolved. subject The entity a URI names or is directed at. It is a claim about which identity is of interest, not a proof of that identity. organ The segment that identifies the subject or answers for it: in "rttp", a readable token (readable form of intent) or a fixed- width derived value (hash form); in "iqa", one of three defined names (Section 5.1). root The root label of the "iqa" authority. It is a name and is not resolved. claim of intent A statement that a subject intends an action. It is a claim, not evidence, and establishes no identity by itself. standing The attestation answer an organ returns for a subject. The values it may take are defined by the reference specification [IQA-SPEC], not here. It carries the attestation algorithm, the standing vocabulary and the conformance material. action The optional final path segment naming what is claimed to be intended ("rttp") or an operation requested of the organ ("iqa"). ROUTE_SHARD The 16-byte value derived from the "rttp" authority as specified in Section 4.4. AID A self-certifying subject identifier defined outside this document. Nothing here depends on an AID registry or authority, and no assumption is made about its length or encoding beyond what Sections 4.2, 5.2 and 6 require. Li Expires 28 March 2027 [Page 4] Internet-Draft rttp and iqa URI Schemes September 2026 3. The Shared Addressing Model Both schemes defined in this document instantiate one addressing model, whose four properties are stated in Section 1 and made normative per scheme in Sections 4 and 5: the address is derived by computation rather than assigned; every segment of an authority is a name, never a host; a URI is a claim, never a proof; and both schemes fail closed. The model is deliberately minimal: no discovery mechanism, no transport, no key directory, no authorisation decision, and no registry of any kind is defined. What is defined is the grammar, the derivation, and the minimum client behaviour that make the two schemes safe to embed. 4. The rttp URI Scheme 4.1. Syntax The general form of an rttp URI is: rttp://..[/] The authority is exactly three dot-separated segments: * intent: 8 lowercase hexadecimal digits (a derived value), or a readable operator-chosen label; both forms are opaque to a client. * pillar: an operator-chosen label. No enumeration of pillar labels and no registry for them is defined. * root: an operator-chosen label matching 1*( %x61-7A / DIGIT / "-" ). The action, when present, is a single path segment: "/" 1*( %x61-7A / DIGIT / "-" ). ABNF: rttp-URI = "rttp://" authority [ "/" action ] authority = intent "." pillar "." root intent = hash-intent / name-intent hash-intent = 8 lowhex name-intent = 1*( %x61-7A / DIGIT / "-" ) pillar = 1*( %x61-7A / DIGIT / "-" ) root = 1*( %x61-7A / DIGIT / "-" ) action = 1*( %x61-7A / DIGIT / "-" ) lowhex = %x30-39 / %x61-66 Li Expires 28 March 2027 [Page 5] Internet-Draft rttp and iqa URI Schemes September 2026 The examples below use reserved names per [RFC2606]; operators use labels they control: rttp://f3b2a1c4.pillar.example/vessel rttp://organ.pillar.example/verify rttp://f3b2a1c4.pillar.example 4.2. Reserved Characters and Exclusions These exclusions apply to both schemes. Section 5.2 adds the ones specific to "iqa". * The canonical form is *lowercase US-ASCII*. Uppercase is *invalid input*, not a formatting difference: a parser MUST NOT normalise it, because two distinct strings would then map onto one address. * ., / and :// are the delimiters defined by these schemes. * Neither scheme defines *userinfo, port, query or fragment*. A URI carrying any of them is not valid, and a fragment MUST NOT be used to address an action. Credentials cannot appear in such a URI, and there is no field in which to exfiltrate data. * Percent-encoding follows Section 2.1 of [RFC3986]. No component requires characters outside the unreserved set, so a canonical URI contains no percent-encoded octets; a parser MAY reject such input rather than normalising it. * There is *no "rttps"* scheme and no fallback. A client that does not implement this scheme fails closed (Section 4.5). 4.3. Default Operation Dereferencing an rttp URI without an action requests the *default operation*: one single round-trip semantic request against the subject named by the authority. The default operation is *safe* in the sense of Section 9.2.1 of [RFC9110]: it creates no obligations and mutates no state of the subject. When an action is present, the default operation is not implied for it. An action names _what_ is claimed to be intended; the safety of a given action is not defined by this document, and a client MUST NOT infer safety from this section (Section 6). Li Expires 28 March 2027 [Page 6] Internet-Draft rttp and iqa URI Schemes September 2026 4.4. The Address: ROUTE_SHARD Derivation The routing address of an rttp URI is derived from the authority alone: canonical_authority = intent "." pillar "." root (lowercase, US-ASCII) ROUTE_SHARD = SHA-256(ASCII(canonical_authority))[0:16] The *authority only*: the scheme name, "//" and any action are excluded. The derived address has four properties: it is *deterministic* (the same authority always yields the same address); it is *pure computation* (no DNS, no registry, no network access, no lookup service); it is *one-way* (the authority cannot be recovered from the address); and it is *action-independent* (different actions on one authority yield the same address). The last property is why an action is not part of the addressing component: *an address is _where_, not _what_*. Were the action to participate in derivation, two actions on one subject would become two addresses, splitting one subject into several. A client MUST NOT perform a lookup in order to use an rttp URI (Section 4.5). 4.5. Client Requirements A client that handles an rttp or iqa URI (including a resolver page, a protocol handler, and a library that renders one) MUST satisfy the requirements below. They follow from Section 6: either URI may be supplied by an untrusted party, and what it names is a claim rather than a proof. Section 5.5 adds the one requirement specific to "iqa". 4.5.1. No Navigation to the URI A client MUST NOT use any component of an rttp or iqa URI as a navigation target. A client that renders a link, redirect, or fetch derived from any such URI is an *open redirect* and is non- conformant; a client MAY navigate only to a destination that is fixed in advance by the client itself. Li Expires 28 March 2027 [Page 7] Internet-Draft rttp and iqa URI Schemes September 2026 4.5.2. Scheme Prefix Check A protocol handler MUST reject any input whose scheme is neither rttp nor iqa nor the exact scheme name under which that handler was itself registered; without this check it becomes a general-purpose launcher that any page can use to open an arbitrary URI of any scheme. 4.5.3. Consent, Never Silence The ability to handle rttp or iqa URIs MUST NOT be acquired without an explicit action by the user, and a client MUST NOT simulate, pre- select, or otherwise bypass that consent. Where the platform exposes the list of registered handlers, that list MUST NOT be exposed to the network. 5. The iqa URI Scheme 5.1. Syntax The general form of an iqa URI is: iqa://..[/] The authority comprises exactly three dot-separated segments, in this order: * subject: 8, 32 or 64 lowercase hexadecimal digits (a derived routing hash), or a readable label; both forms are opaque to a client. * organ: one of the three organ names, forge, tss or gateway. This is a *closed set*; no other value is valid. * root: the root label of this scheme. Like every other segment it is a name and is never resolved. The action, when present, is a single path segment and is one of the four operation names verify, audit, attest or revoke. This is also a *closed set*. ABNF: Li Expires 28 March 2027 [Page 8] Internet-Draft rttp and iqa URI Schemes September 2026 iqa-URI = "iqa://" iqa-authority [ "/" iqa-action ] iqa-authority = subject "." organ "." iqa-root subject = hash-subject / name-subject hash-subject = 8( iqa-lowhex ) / 32( iqa-lowhex ) / 64( iqa-lowhex ) name-subject = 1*( %x61-7A / DIGIT / "-" ) organ = "forge" / "tss" / "gateway" iqa-root = 1*( %x61-7A / DIGIT / "-" ) iqa-action = "verify" / "audit" / "attest" / "revoke" iqa-lowhex = DIGIT / %x61-66 Examples (the examples use the root label of this specification and placeholder subjects): iqa://3f9a1b2c.gateway.iqa (routing hash, standing read) iqa://0000004149434e531c5b21d80403358b.forge.iqa iqa://3f9a1b2c.tss.iqa/audit (explicit fidelity audit) iqa://master-authority.gateway.iqa/verify (readable label form) 5.2. Reserved Characters and Exclusions The exclusions of Section 4.2 apply to iqa URIs as they do to rttp URIs. Two are specific to this scheme: * There is *no "iqas"* scheme and no protocol fallback. A client that does not implement this scheme fails closed (Section 5.5). * The hexadecimal subject form is a *routing hint, not evidence*. It carries no verification weight; identity is bound outside the URI and is never established by parsing one (Section 6). 5.3. Default Operation Dereferencing an iqa URI without an action requests the *default operation*: a standing read, returning the subject's current attestation answer as reported by the named organ. The default operation is *safe* in the sense of Section 9.2.1 of [RFC9110]: it creates no obligation, transfers no value, and mutates no state. The following rule is normative: *Dereferencing an iqa URI, by itself, MUST NOT transition any subject's standing state.* When an action is present, the default operation is not implied for it. Which actions are safe is stated in Section 5.4; a client MUST NOT infer safety for an unrecognised verb (Section 6). Li Expires 28 March 2027 [Page 9] Internet-Draft rttp and iqa URI Schemes September 2026 5.4. Action Safety Classes The four defined actions, and the omitted-action form, have the following classes: audit is not classified safe because the measurement it requests can itself change the outcome it measures. audit, attest and revoke MUST be requested explicitly and MUST NOT be reachable by dereferencing a URI that omits the action. +===========+==========================+=====================+ | Action | Semantics | Class | +===========+==========================+=====================+ | (omitted) | Read the current | *SAFE*, read-only | | | standing. | | +-----------+--------------------------+---------------------+ | verify | Compare a presented seal | *SAFE*, read-only | | | against the subject. No | comparison | | | state is written. | | +-----------+--------------------------+---------------------+ | audit | Request a fidelity | *NOT SAFE*, a | | | measurement of the | failed measurement | | | subject's execution. | may change standing | +-----------+--------------------------+---------------------+ | attest | Request that a seal be | *NOT SAFE*, state | | | issued for the subject. | transition | +-----------+--------------------------+---------------------+ | revoke | Withdraw the subject's | *NOT SAFE*, state | | | standing. | transition | +-----------+--------------------------+---------------------+ Table 1 5.5. Client Requirements The client requirements of Section 4.5 apply to iqa URIs as they do to rttp URIs: no navigation to the URI, a scheme prefix check, and consent that is never silent. One requirement is specific to this scheme. 5.5.1. Parsing Is Not Attestation A client that displays a parsed or rendered iqa URI MUST NOT present the result as evidence of standing. Reading the syntax establishes nothing about any subject; standing is established only by the answer of the named organ, under the rules of the reference specification [IQA-SPEC]. Li Expires 28 March 2027 [Page 10] Internet-Draft rttp and iqa URI Schemes September 2026 6. Security Considerations The security properties of the two schemes share one foundation, and the following statements apply to both of them. * *No lookup.* Neither scheme resolves through DNS, and neither performs a lookup when a URI is used: there is no resolver to poison, no registration to hijack, and no query metadata to observe on a resolution path. * *No secrets in the URI.* Neither scheme defines userinfo, so credentials cannot be carried in one. Operators and deployments MUST NOT place secrets in any component: a URI is expected to be logged, quoted, and rendered. * *Unknown actions carry unknown safety.* The safe default operations of Sections 4.3 and 5.3 apply to the omitted-action forms only. An implementation MUST NOT infer safety for an unrecognised action verb; it MUST treat the verb as having unknown safety and either require explicit authorisation under the local security policy or reject it. * *No confidentiality, authentication, or transport security.* Neither scheme protects a URI in transit, and neither turns a URI into a proof: signing is not encryption, and a URI is not a signature. * *Parsing establishes nothing.* Neither the syntax nor any component of a URI of either scheme is evidence about its subject, and a client MUST NOT present a parsed or rendered URI as if it were evidence (Sections 4.5 and 5.5). The scheme-specific considerations follow. 6.1. The rttp scheme * An rttp URI is a *claim of intent directed at a subject*. The derived address is an *entry fingerprint, not a proof of identity*. Identity is carried by the subject's AID, and any attestation of it is carried separately. * The authority is *pseudonymous, not anonymous*. It is a stable name and will appear in logs, in caches, and in anything that quotes the URI. Whether that name is linkable to a subject is a property of the operator's naming choices, not of the scheme. 6.2. The iqa scheme Li Expires 28 March 2027 [Page 11] Internet-Draft rttp and iqa URI Schemes September 2026 * An iqa URI is a *claim about the attestation standing of a named subject*. Neither the syntax nor any component of the URI is evidence of standing. * *Seal forgery.* Standing is carried by a keyed message authentication code over the subject's identity material and its deployment parameters, not by the URI; no key material is ever present in an iqa URI. * *Subject spoofing.* A seal presented for one subject fails binding when replayed for another, because the binding covers hardware and deployment parameters of the subject; a client MUST NOT treat a syntactically valid subject as a verified one. * *Linkability and disclosure of interest.* An iqa URI names the subject being attested, so citing one discloses which identity is of interest, and querying several organs for the same subject is trivially correlatable. *This scheme cannot be used for anonymous reference.* Deployments SHOULD prefer the routing-hash form over readable labels, SHOULD NOT encode personal identifiers in the action, and SHOULD treat iqa URIs in logs as an identity assertion. * *Silence is not assent.* An endpoint that is unreachable, times out, or returns an error MUST NOT be read as affirmative standing: absence of evidence is not evidence of compliance. * *Downgrade and scheme confusion.* No "iqas" variant exists and no fallback is defined. A client that does not implement this scheme MUST fail closed and MUST NOT silently rewrite an iqa URI as some other scheme. * *Detection of observers.* A measurement requested by the audit action compares observed execution timing against an expected path: execution slower than predicted is treated as evidence of an attached observer, and measurable deviation is itself the detector. This is a property of the answering organ, not of the URI syntax. * *Replay across epochs.* Standing material is rotated on a defined cycle, so a previously valid answer can become invalid without any change to the URI; a client MUST NOT treat a cached answer as current indefinitely. * *Cryptographic suite.* The current construction uses a keyed symmetric hash rather than a public-key signature, and is therefore not directly affected by quantum algorithms that break factoring or discrete logarithms. Li Expires 28 March 2027 [Page 12] Internet-Draft rttp and iqa URI Schemes September 2026 7. Privacy Considerations The privacy properties of the two schemes share one foundation: no component is defined for a query string, so neither scheme offers a channel for a page to smuggle unrelated data into a request, and using a URI of either scheme does not by itself cause network traffic to a third party; the authority is a stable pseudonym, expected to be logged, quoted and rendered, and readable labels are a naming choice rather than a scheme property. A client that renders such a URI SHOULD avoid prefetching, handing the string to third-party services, or otherwise distributing it beyond what the user's action requires. For "iqa", citing a URI also discloses which subject is of interest; the disclosure considerations of Section 6.2 apply. 8. Internationalization Considerations The canonical form of a URI in either scheme is lowercase US-ASCII, and no international form is defined: a client MUST NOT map a Unicode label to its ASCII form (for example, by case folding or by applying an IDNA-style transformation) in order to accept it, and MUST NOT render such a URI as an IRI. This is deliberate: with no host to resolve there is no need for a label-to-ASCII transformation, and permitting one would introduce a second way to write one address. 9. IANA Considerations IANA is requested to register the two URI schemes below, "rttp" and "iqa", in the "Uniform Resource Identifier (URI) Schemes" registry, following the template of Section 7.4 of [RFC7595] and the guidance of [RFC8126]. The templates below are complete. If this document is approved for publication as an RFC, IANA is requested to point both registry entries at that RFC. 9.1. The "rttp" URI Scheme Scheme name: rttp Status: Provisional Li Expires 28 March 2027 [Page 13] Internet-Draft rttp and iqa URI Schemes September 2026 Applications/protocols that use this scheme name: URIs of this scheme name a claim of intent directed at an identified subject. Applications include intent-addressed requests between autonomous software agents and the client-side handling of such URIs by protocol handlers in browsers and operating systems. The scheme defines addressing only; it does not define a transport or a discovery mechanism. Contact: ShaoBao Li Change controller: RTTP.COM Organization References: This document, and AICENT-002, "the rttp URI scheme", . Registered with CRI scheme number 27. 9.2. The "iqa" URI Scheme Scheme name: iqa Status: Provisional Applications/protocols that use this scheme name: Subject-attestation references: an iqa URI names the attestation standing of a subject as reported by one of three named authority organs, without carrying the underlying cryptographic proof. It is used by the reference implementations and by tools that cite an attestation in a document, a configuration file or a log. The scheme defines addressing and client behaviour only; it does not define a transport, a discovery mechanism, or the attestation algorithm. Contact: ShaoBao Li Change controller: IQA.ORG Organization References: This document, and AICENT-009, "Identity Quality Assurance, the iqa URI scheme specification", . Submitted for registration; the scheme name is approved and the CRI number is in expert review. Li Expires 28 March 2027 [Page 14] Internet-Draft rttp and iqa URI Schemes September 2026 10. Acknowledgements The author thanks those who commented on earlier revisions of this document for their attention to the client-behaviour requirements, which are the part of this specification most likely to be misimplemented. 11. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, . [RFC7595] Thaler, D., Hansen, T., and T. Hardie, "Guidelines and Registration Procedures for URI Schemes", BCP 35, RFC 7595, DOI 10.17487/RFC7595, June 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9110] Fielding, R., Nottingham, M., and J. Reschke, "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022, . 12. Informative References [IQA-SPEC] Li, S., "Identity Quality Assurance, the iqa URI scheme specification", September 2026, . [RFC2606] Eastlake 3rd, D. and A. Panitz, "Reserved Top Level DNS Names", BCP 32, RFC 2606, DOI 10.17487/RFC2606, June 1999, . Li Expires 28 March 2027 [Page 15] Internet-Draft rttp and iqa URI Schemes September 2026 [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . Author's Address ShaoBao Li RTTP & IQA Organization Email: lee@iqa.org Li Expires 28 March 2027 [Page 16]