The AEO1 Discovery Mechanism: A DNS-Anchored, Signed Pointer to Owner-Attested Fact Catalogs for AI Answer Engines
draft-miller-aeo-00

Network Working Group                                          G. Miller
Internet-Draft                                    Meadow Mountain AI LLC
Intended status: Informational                              18 July 2026
Expires: 19 January 2027

 The AEO1 Discovery Mechanism: A DNS-Anchored, Signed Pointer to Owner-
              Attested Fact Catalogs for AI Answer Engines
                          draft-miller-aeo-00

Abstract

   This document specifies AEO1 (Answer Engine Optimization, version 1),
   a discovery mechanism that allows a domain owner to publish a
   verifiable, machine-readable pointer to a structured, owner-attested
   fact catalog for that domain.  AEO1 consists of three coordinated
   surfaces: a DNS TXT record at the "_aeo" subdomain, a JSON document
   at the well-known URI "/.well-known/aeo.json", and an optional HTML
   link hint.  Records may carry an Ed25519 signature issued by an
   issuing authority, enabling consuming agents such as AI answer
   engines to distinguish verified, current, domain-authorized data from
   unverified crawled content.  The design follows the DNS-authenticated
   trust-anchor pattern established by SPF, DKIM, and DMARC.  This
   document also requests provisional registration of the "aeo.json"
   well-known URI suffix.

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 19 January 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

Miller                   Expires 19 January 2027                [Page 1]
Internet-Draft                    AEO1                         July 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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
   3.  The AEO1 Discovery Mechanism  . . . . . . . . . . . . . . . .   4
     3.1.  The DNS TXT Record  . . . . . . . . . . . . . . . . . . .   4
       3.1.1.  Required Tags . . . . . . . . . . . . . . . . . . . .   5
       3.1.2.  Optional Tags . . . . . . . . . . . . . . . . . . . .   5
     3.2.  The Well-Known URI: /.well-known/aeo.json . . . . . . . .   6
     3.3.  The HTML Link Hint  . . . . . . . . . . . . . . . . . . .   6
     3.4.  Verification Tiers  . . . . . . . . . . . . . . . . . . .   6
   4.  The aeo.json Document . . . . . . . . . . . . . . . . . . . .   7
   5.  Signing and Verification  . . . . . . . . . . . . . . . . . .   8
     5.1.  Fact-Catalog Canonicalization . . . . . . . . . . . . . .   8
     5.2.  Public-Key Publication  . . . . . . . . . . . . . . . . .   9
     5.3.  Key Revocation and Status . . . . . . . . . . . . . . . .   9
     5.4.  Verification Procedure  . . . . . . . . . . . . . . . . .   9
   6.  Relationship to Other Mechanisms  . . . . . . . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
     7.1.  Spoofing and Self-Declared Records  . . . . . . . . . . .  11
     7.2.  Key Compromise and Revocation . . . . . . . . . . . . . .  11
     7.3.  DNS Trust . . . . . . . . . . . . . . . . . . . . . . . .  11
     7.4.  Server-Side Request Forgery on Catalog Fetch  . . . . . .  11
     7.5.  Stale Data  . . . . . . . . . . . . . . . . . . . . . . .  12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  12
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  14
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   AI answer engines (large language model based systems that answer
   natural-language questions with a synthesized response rather than a
   list of links) increasingly serve as a primary interface through
   which users discover information about organizations, businesses,
   products, and services.  These systems typically ground their answers
   in web crawls, search index snapshots, or general training data.
   None of those sources provide a reliable, machine-checkable signal
   of:

Miller                   Expires 19 January 2027                [Page 2]
Internet-Draft                    AEO1                         July 2026

   (a)  whether any party has verified facts about the organization
        associated with a domain;

   (b)  where a canonical, structured, currently maintained record of
        those facts can be retrieved;

   (c)  whether time-sensitive facts (hours, pricing, service area) are
        current; and

   (d)  whether publication of the data was authorized by the domain
        owner.

   This document defines AEO1, a discovery convention that gives a
   domain owner a predictable, verifiable place to publish a pointer to
   a structured fact catalog, together with a verification tier, tenure
   information, and an optional cryptographic signature.  The design
   intentionally mirrors SPF [RFC7208], DKIM [RFC6376], and DMARC
   [RFC7489]: a low-friction DNS TXT record at a conventionally named
   subdomain, checked by automated systems before trusting domain-
   associated content.  The well-known URI surface follows the precedent
   of security.txt [RFC9116].

   The AEO1 format is an open specification.  The living specification,
   JSON Schema, and worked examples are published at
   https://aeorecord.org [AEO-SPEC].  This document describes version
   0.2 of that specification.  An open-source verifier is available as
   the "aeo-record" package in the npm registry.

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.

   Answer engine:  A system that synthesizes a natural-language response
      to a user query, typically citing one or more sources.

   Consuming agent:  Any crawler, AI agent, answer engine, or automated
      tool that reads an AEO record to decide how to retrieve domain-
      associated data.

   Issuing authority:  An entity that verifies facts about a domain and
      issues an "id=" token and Ed25519 signature after confirming the
      requester controls that domain.  This document does not mandate a
      single issuing authority; it defines the record format any
      authority MAY use.

Miller                   Expires 19 January 2027                [Page 3]
Internet-Draft                    AEO1                         July 2026

   Fact catalog:  A structured, machine-readable document of facts about
      the organization associated with a domain, retrievable over HTTPS.

3.  The AEO1 Discovery Mechanism

   AEO1 defines three coordinated discovery surfaces.  A consuming agent
   SHOULD attempt them in the following order, stopping at the first
   successful retrieval:

   1.  the well-known URI (Section 3.2);

   2.  the DNS TXT record (Section 3.1);

   3.  the HTML link hint (Section 3.3);

   4.  lower-precedence fallbacks: a pointer within the domain's
       llms.txt file if present, a listing in a public Model Context
       Protocol (MCP) directory if the agent supports MCP, and finally
       conventional HTML retrieval of the domain (an unverified
       fallback).

3.1.  The DNS TXT Record

   The authoritative anchor of an AEO1 deployment is a TXT resource
   record published at the "_aeo" subdomain of the domain being
   described, following the convention established by DMARC's "_dmarc"
   prefix:

   _aeo.example.com.  IN  TXT  "v=AEO1; id=grd_a1b2c3;
       catalog=https://issuer.example/c/example.com;
       tier=verified; ts=20260629; sig=<base64-ed25519-signature>"

   Placing the record under "_aeo" rather than at the domain apex avoids
   collision with other TXT records (SPF, domain verification tokens,
   etc.) commonly present at the apex.  The record value is a semicolon-
   separated list of tag=value pairs.  Whitespace around separators is
   ignored.

   All AEO1 tag names and the "v=AEO1" version token are US-ASCII
   protocol constants; they are never localized or translated, following
   the practice of SPF, DKIM, and DMARC.  Where the domain being
   described is an internationalized domain name, the "_aeo" label is
   prepended to the domain's A-label (Punycode) form as defined by
   IDNA2008 [RFC5890], and a consuming agent resolves the record using
   that A-label form.

Miller                   Expires 19 January 2027                [Page 4]
Internet-Draft                    AEO1                         July 2026

3.1.1.  Required Tags

   v=  REQUIRED.  Version tag.  MUST be the literal string "AEO1" for
      records conforming to this specification.  If present, this tag
      MUST appear first in the record.

   catalog=  REQUIRED.  An HTTPS URL of the structured, machine-readable
      fact catalog for the domain.  The URL MUST use the "https" scheme.

   tier=  REQUIRED.  Verification depth.  MUST be one of
      "self_declared", "listed", "verified", or "grounded" (see
      Section 3.4).  Consuming agents MUST treat unrecognized tier
      values as equivalent to "self_declared".

   ts=  REQUIRED.  The date the record was first verified or issued, in
      YYYYMMDD format.  In this version of the specification, ts=
      expresses TENURE (how long the domain has held a verified record),
      not freshness.  Consuming agents MUST NOT reject or down-rank a
      record solely because its ts= value is old.  Freshness is carried
      by the "verified_at" and "last_confirmed_at" fields of the
      aeo.json document (Section 4).

3.1.2.  Optional Tags

   id=  OPTIONAL.  A token issued by an issuing authority as proof that
      the domain owner authorized the catalog entry.  Absent for self-
      issued, self-declared records.

   sig=  OPTIONAL.  An Ed25519 signature [RFC8032] issued by an issuing
      authority, covering the canonical string defined in Section 5.  A
      record carrying a valid sig= from a known issuing authority
      provides cryptographic evidence that the authority issued the
      stated tier for the stated domain and catalog content.

   area=  OPTIONAL.  For domains representing entities with a
      geographically bounded service area, a short structured
      description of that area.

   Note: an earlier revision of the AEO1 specification defined a
   "method=" DNS tag expressing retrieval-method preference.  That tag
   was removed in specification version 0.2; retrieval preference is
   expressed only by the "method_preference" field of the aeo.json
   document (Section 4).  Consuming agents MUST ignore unrecognized
   tags, including "method=", if encountered.

Miller                   Expires 19 January 2027                [Page 5]
Internet-Draft                    AEO1                         July 2026

3.2.  The Well-Known URI: /.well-known/aeo.json

   Because DNS-record checking requires explicit implementation by a
   consuming agent, this document also defines an equivalent discovery
   surface at a well-known URI [RFC8615]:

   https://example.com/.well-known/aeo.json

   This resource, when present, MUST contain a JSON [RFC8259] object
   with fields semantically equivalent to the tags defined in
   Section 3.1, as described in Section 4.  Retrieval of the resource is
   safe and idempotent: it is read-only JSON with no side effects.

   A consuming agent MAY check this URI in place of, or prior to, a DNS
   TXT lookup.  When both surfaces are present and disagree, the DNS
   record is authoritative.  The well-known resource exists to enable
   adoption by systems that already fetch /.well-known/ resources (per
   the precedent of security.txt [RFC9116] and WebFinger [RFC7033]) but
   do not yet perform AEO-specific DNS lookups.

3.3.  The HTML Link Hint

   A domain MAY additionally advertise its AEO record from within its
   HTML pages using a link element with the link relation type "aeo":

   <link rel="aeo" href="/.well-known/aeo.json">

   This hint lets agents that parse page markup, but that would not
   otherwise probe well-known URIs or DNS, discover the record in-page.
   The hint is advisory only: a consuming agent that follows it MUST
   apply the same validation it would apply to a directly fetched
   /.well-known/aeo.json resource.  Registration of the "aeo" link
   relation type in the IANA "Link Relation Types" registry [RFC8288]
   may be requested separately; the hint functions without such
   registration.

3.4.  Verification Tiers

   The tier value expresses verification depth on an ordinal scale so
   that consuming agents can weight trust appropriately:

   self_declared:  Data supplied by the domain owner with no independent
      corroboration and no issuing authority involved.

   listed:  The domain is enrolled with an issuing authority and its
      catalog is published, without independent fact review.

   verified:  Data reviewed by a human operator at the issuing

Miller                   Expires 19 January 2027                [Page 6]
Internet-Draft                    AEO1                         July 2026

      authority, or independently spot-checked against at least one
      additional source.

   grounded:  Data cross-corroborated against multiple independent
      sources with agreement, and cryptographically signed.

   Consuming agents MAY apply different trust thresholds depending on
   the sensitivity of the query (for example, requiring "grounded" tier
   before citing time-sensitive or safety-relevant facts such as
   business hours for urgent or emergency services).

4.  The aeo.json Document

   The /.well-known/aeo.json resource contains a single JSON object.  A
   JSON Schema for the document is published at https://aeorecord.org/
   aeo.schema.json; the living specification [AEO-SPEC] is normative for
   field-level detail.  Example:

   {
     "v": "AEO1",
     "catalog": "https://issuer.example/c/example.com",
     "mcp": "mcp://api.issuer.example",
     "api": "https://api.issuer.example/v1/companies/example.com",
     "tier": "verified",
     "verified_at": "2026-06-29",
     "last_confirmed_at": "2026-07-04",
     "method_preference": ["mcp", "api", "crawl"]
   }

   v:  REQUIRED.  The literal string "AEO1".

   catalog:  REQUIRED.  As in the DNS record (Section 3.1.1).

   tier:  REQUIRED.  As in the DNS record.

   verified_at:  Date (RFC 3339 full-date) of the most recent system-
      performed verification or re-signing event.  This is the primary
      machine freshness signal.

   last_confirmed_at:  Date of the most recent owner-attested
      confirmation that the catalog facts remain accurate.  This field
      is purely additive: its presence and recency MAY raise an agent's
      confidence, but its absence or age MUST NOT be treated as
      invalidating the record.

   mcp, api:  OPTIONAL.  Endpoints for structured retrieval of the
      catalog via a Model Context Protocol server or a conventional
      HTTPS API, respectively.

Miller                   Expires 19 January 2027                [Page 7]
Internet-Draft                    AEO1                         July 2026

   method_preference:  OPTIONAL.  An ordered array of preferred
      retrieval methods.  Defined values: "mcp", "api", "crawl".
      Consuming agents SHOULD attempt methods in the listed order and
      fall back to the next on failure.

   All AEO1 JSON resources — the aeo.json document and the fact catalog
   it references — are encoded in UTF-8 [RFC8259], so fact values in any
   language or writing system are carried without transformation.  A
   human-readable fact value MAY carry an associated language tag per
   BCP 47 [RFC5646], and an issuing authority MAY publish the same fact
   in more than one language so that a consuming agent can cite the
   value whose language matches the query.  Language tagging does not
   alter canonicalization (Section 5.1): every published value, whatever
   its language, is normalized and hashed by the single procedure
   defined there.

5.  Signing and Verification

   An issuing authority signs records with Ed25519 [RFC8032].  The
   signature carried in the sig= DNS tag is computed over the canonical
   string:

   AEO1|domain|tier|ts|facts_hash

   where "domain" is the domain being described, "tier" and "ts" are the
   values published in the DNS record, and "facts_hash" is the SHA-256
   digest of the canonical fact-catalog content defined in Section 5.1.
   Binding the hash of the catalog content into the signed string allows
   a consuming agent to detect tampering with catalog content after
   issuance.  The issuing authority re-signs the record whenever the
   catalog facts or tier change.

5.1.  Fact-Catalog Canonicalization

   The "facts_hash" is computed over a deterministic canonical form of
   the domain's published facts, so that every conforming implementation
   reproduces an identical hash regardless of platform, locale, or text
   encoding.  Each published fact is reduced to a JSON object with
   exactly the three string members "fact_type", "key", and "value".
   Canonicalization proceeds as follows:

   1.  Every string field MUST be normalized to Unicode Normalization
       Form C (NFC) [UAX15].  This ensures that text which is identical
       to a reader but differs only in composed versus decomposed
       encoding — for example U+00E9 versus the sequence U+0065 U+0301,
       both rendering "é" — produces the same bytes, and therefore the
       same signature.

Miller                   Expires 19 January 2027                [Page 8]
Internet-Draft                    AEO1                         July 2026

   2.  The fact objects MUST be sorted in ascending order, comparing
       "fact_type", then "key", then "value", by Unicode code point —
       not by UTF-16 code unit, which would misorder characters outside
       the Basic Multilingual Plane.

   3.  The sorted array MUST be serialized as JSON [RFC8259], each
       object emitting its members in the order "fact_type", "key",
       "value", with no insignificant whitespace.

   4.  "facts_hash" is the lowercase hexadecimal SHA-256 digest of the
       UTF-8 encoding of that serialization.

   Because the canonical form is UTF-8 and ordered by code point, it is
   script-independent: facts in any language or writing system
   canonicalize deterministically under this single procedure, with no
   locale-dependent behavior.  Verifiers MUST apply the identical
   canonicalization before checking a signature.

5.2.  Public-Key Publication

   An issuing authority MUST publish its verification keys as a JSON
   document at the well-known path "/.well-known/aeo-public-key.json" on
   the authority's own domain.  Each key entry carries at minimum a key
   identifier ("key_id"), the Ed25519 public key, and a status of
   "active", "retired", or "revoked".

5.3.  Key Revocation and Status

   Verifiers MUST refuse signatures made with keys whose published
   status is "revoked".  Verifiers MUST accept signatures made with
   "active" keys and SHOULD accept signatures made with "retired" keys
   (keys rotated out of service but not compromised), so that previously
   issued records remain verifiable across routine rotation.

5.4.  Verification Procedure

   1.  Resolve the _aeo TXT record (or fetch /.well-known/aeo.json) for
       the target domain and parse the tags.

   2.  If sig= is absent, treat the record as carrying no cryptographic
       assurance; apply tier semantics with correspondingly lower
       weight.

   3.  If sig= is present, fetch the issuing authority's public-key
       document, select the applicable key, and check its status per
       Section 5.3.

Miller                   Expires 19 January 2027                [Page 9]
Internet-Draft                    AEO1                         July 2026

   4.  Reconstruct the canonical string and verify the Ed25519
       signature.  On failure, the record MUST be treated as no better
       than "self_declared".

   A reference verifier is available as the open-source "aeo-record"
   package in the npm registry.

6.  Relationship to Other Mechanisms

   robots.txt:  Governs crawler access permissions.  Orthogonal: an AEO
      record does not override robots.txt directives.

   llms.txt:  A file-based content index for AI crawlers.
      Complementary: an AEO-aware llms.txt SHOULD include a pointer to
      the domain's AEO record.  llms.txt provides no DNS-layer
      authentication, freshness signal, or verification depth.

   AIPREF (IETF AI Preferences):  The IETF AI Preferences (AIPREF)
      working group standardizes a vocabulary for expressing AI usage
      preferences — whether and how an AI system may collect, train on,
      or display content — along with related work on cryptographic
      grants that lift those preferences.  Complementary and orthogonal:
      AIPREF governs usage permissions, whereas AEO1 governs verified
      publication of factual claims and the publisher authority behind
      them.  The AIPREF grant-binding work explicitly places
      establishing that an issuer is authoritative for an asset out of
      scope; AEO1's DNS-control and issuer-signature model supplies
      exactly that domain-authority anchor, which usage- and grant-
      signaling mechanisms assume but do not themselves define.  Related
      independent efforts add a verifiable authority-and-timestamp
      binding to those preference signals (for example the ADP-1
      declaration format, which anchors a signed reservation's
      authorship and time to a public transparency substrate).  Such
      work binds who reserved a usage right and when; AEO1 is orthogonal
      in object, binding publisher authority and signature to positive
      factual claims for citation rather than to usage reservations, and
      could compose with a shared authority substrate rather than
      duplicate it.

   schema.org markup:  Page-level structured data.  Orthogonal: AEO
      operates at the domain/DNS layer, not the page layer, and is
      authenticated by DNS control and issuer signature.

   SPF/DKIM/DMARC:  Direct structural precedent for this specification's
      DNS-TXT, subdomain-prefixed, tag=value record design [RFC7208]
      [RFC6376] [RFC7489].

   security.txt:  Precedent for publishing machine-readable, domain-

Miller                   Expires 19 January 2027               [Page 10]
Internet-Draft                    AEO1                         July 2026

      scoped metadata at a well-known location [RFC9116].

7.  Security Considerations

7.1.  Spoofing and Self-Declared Records

   Because DNS TXT records can only be modified by parties with access
   to the domain's authoritative DNS zone, publication of a "v=AEO1"
   record is itself evidence of domain-owner intent, consistent with the
   trust model used by SPF and DMARC.  However, a self-declared record
   (no id=, no sig=) carries no assurance beyond DNS publication.
   Consuming agents MUST NOT treat self-declared records as equivalent
   to "verified" or "grounded" records, and MUST NOT trust a claimed
   tier value that is not backed by a valid issuer signature.  A
   malicious domain owner can claim any tier in an unsigned record; the
   tier is only meaningful when the signature verifies against a known
   issuing authority.

7.2.  Key Compromise and Revocation

   Compromise of an issuing authority's private key would allow forgery
   of signed records at any tier.  Authorities MUST be able to mark keys
   "revoked" in their public-key document, and verifiers MUST honor that
   status (Section 5.3).  Authorities SHOULD rotate keys periodically
   (publishing superseded keys as "retired") and SHOULD protect private
   keys in managed secret storage.  Verifiers SHOULD NOT cache public-
   key documents beyond a modest lifetime, so that revocation takes
   effect promptly.

7.3.  DNS Trust

   Unsigned DNS responses can be spoofed by on-path attackers or through
   cache poisoning.  Deployments SHOULD sign the zones carrying _aeo
   records with DNSSEC, and consuming agents SHOULD validate DNSSEC
   where available.  Absent DNSSEC, the Ed25519 issuer signature
   (Section 5) remains the strongest integrity signal, since a spoofed
   record cannot carry a valid signature over attacker-chosen values.

7.4.  Server-Side Request Forgery on Catalog Fetch

   The catalog=, mcp=, and api= values are attacker-controllable URLs
   from the consuming agent's perspective.  An agent that dereferences
   them from server-side infrastructure is exposed to server-side
   request forgery (SSRF).  Consuming agents MUST require the "https"
   scheme, SHOULD refuse to fetch URLs that resolve to loopback, link-
   local, or private address ranges, SHOULD re-apply these checks on
   every hop of an HTTP redirect chain, and SHOULD bound redirect depth,
   response size, and fetch time.

Miller                   Expires 19 January 2027               [Page 11]
Internet-Draft                    AEO1                         July 2026

7.5.  Stale Data

   Because ts= expresses tenure rather than freshness (Section 3.1.1),
   agents seeking a freshness signal SHOULD consult "verified_at" and
   "last_confirmed_at" in the aeo.json document and weight confidence
   accordingly, rather than rejecting records by age.  Fact catalogs
   remain assertions by their publisher and issuing authority; AEO1
   conveys who attested what and when, not ground truth.

8.  IANA Considerations

   IANA is requested to register the following entry in the "Well-Known
   URIs" registry, following the procedure of [RFC8615]:

   URI Suffix:  aeo.json

   Change Controller:  Meadow Mountain AI LLC

   Specification Document(s):  This document (Sections 3.2 and 4) and
      https://aeorecord.org

   Status:  provisional

   Related Information:  The companion DNS TXT record convention and
      signature scheme are defined in Sections 3.1 and 5 of this
      document.

   A provisional registration for this suffix, with the same change
   controller and referencing https://aeorecord.org, was requested
   through the IANA protocol-assignment process in July 2026 and may
   already appear in the registry; in that case this document serves as
   an additional specification document for the existing entry rather
   than a new registration.

   This document makes no other requests of IANA.  It creates no new
   registries.

9.  References

9.1.  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,
              <https://www.rfc-editor.org/info/rfc2119>.

Miller                   Expires 19 January 2027               [Page 12]
Internet-Draft                    AEO1                         July 2026

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8032]  Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
              Signature Algorithm (EdDSA)", RFC 8032,
              DOI 10.17487/RFC8032, January 2017,
              <https://www.rfc-editor.org/info/rfc8032>.

   [RFC8259]  Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
              Interchange Format", STD 90, RFC 8259,
              DOI 10.17487/RFC8259, December 2017,
              <https://www.rfc-editor.org/info/rfc8259>.

   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
              (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
              <https://www.rfc-editor.org/info/rfc8615>.

   [RFC5646]  Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
              Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
              September 2009, <https://www.rfc-editor.org/info/rfc5646>.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,
              <https://www.rfc-editor.org/info/rfc5890>.

   [UAX15]    The Unicode Consortium, "Unicode Standard Annex #15:
              Unicode Normalization Forms", 2024,
              <https://www.unicode.org/reports/tr15/>.

9.2.  Informative References

   [RFC6376]  Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
              "DomainKeys Identified Mail (DKIM) Signatures", STD 76,
              RFC 6376, DOI 10.17487/RFC6376, September 2011,
              <https://www.rfc-editor.org/info/rfc6376>.

   [RFC7033]  Jones, P., Salgueiro, G., Jones, M., and J. Smarr,
              "WebFinger", RFC 7033, DOI 10.17487/RFC7033, September
              2013, <https://www.rfc-editor.org/info/rfc7033>.

   [RFC7208]  Kitterman, S., "Sender Policy Framework (SPF) for
              Authorizing Use of Domains in Email, Version 1", RFC 7208,
              DOI 10.17487/RFC7208, April 2014,
              <https://www.rfc-editor.org/info/rfc7208>.

Miller                   Expires 19 January 2027               [Page 13]
Internet-Draft                    AEO1                         July 2026

   [RFC7489]  Kucherawy, M., Ed. and E. Zwicky, Ed., "Domain-based
              Message Authentication, Reporting, and Conformance
              (DMARC)", RFC 7489, DOI 10.17487/RFC7489, March 2015,
              <https://www.rfc-editor.org/info/rfc7489>.

   [RFC8288]  Nottingham, M., "Web Linking", RFC 8288,
              DOI 10.17487/RFC8288, October 2017,
              <https://www.rfc-editor.org/info/rfc8288>.

   [RFC9116]  Foudil, E. and Y. Shafranovich, "A File Format to Aid in
              Security Vulnerability Disclosure", RFC 9116,
              DOI 10.17487/RFC9116, April 2022,
              <https://www.rfc-editor.org/info/rfc9116>.

   [AEO-SPEC] Meadow Mountain AI LLC, "The AEO Record Standard (v=AEO1),
              Specification v0.2", 2026, <https://aeorecord.org>.

Acknowledgements

   The record design draws directly on the deployment experience of SPF,
   DKIM, DMARC, and security.txt.

Author's Address

   Garrett Miller
   Meadow Mountain AI LLC
   Email: support@aeorecord.org
   URI:   https://aeorecord.org

Miller                   Expires 19 January 2027               [Page 14]