DAWN Y. Cui Internet-Draft Tsinghua University Intended status: Informational 1 November 2026 Expires: 5 May 2027 Minimum Public Discovery Information: Requirements and Common Semantics draft-cui-dawn-mdi-model-01 Abstract The charter of the Discovery of Agents With Names (DAWN) working group asks it to specify the minimum public discovery information that a client obtains when it discovers an AI resource. An individual draft on DAWN terminology defines Minimum Discoverable Information (MDI) as the minimum amount of information an entity needs to provide to become discoverable, distinguishes it from the Minimum Viable Dataset (MVD) that a discovery mechanism needs as input, and gives only examples of the content of either. Individual drafts on the DAWN problem statement and requirements call for a standardized minimum structure and list what it must at least contain; in its absence, emerging discovery formats risk each defining its own minimal metadata, with descriptors that do not interoperate across organizational or protocol boundaries. This document addresses the minimum public discovery information as a client obtains it and as a publisher provides it, and its relation to the input of discovery; registration mechanisms are outside its scope. Using the distinction RFC 3444 draws between information models and data models, it describes the information involved in publication, lookup, and response; proposes a procedure that derives what is minimal for each deployment context from the scope of the charter; applies the procedure to the charter's three deployment contexts: a local network, an organization, and the domain of a cooperating party; and proposes a set of elements with the minimal constraints that hold among them. Information can be supplied by the discovery response, by context the client already has, or by binding rules. This document is input to the DAWN architecture and protocol work; normative definitions that affect interoperability belong to the corresponding Standards Track documents. It is a mapping target for richer descriptors. Discussion Venues This note is to be removed before publishing as an RFC. Cui Expires 5 May 2027 [Page 1] Internet-Draft Minimum Public Discovery Information November 2026 Discussion of this document takes place on the Discovery of Agents, Workloads, and Named entities Working Group mailing list (dawn@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/dawn. Source for this draft and an issue tracker can be found at https://github.com/nxbrowning/MDI. 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 5 May 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . . 5 4. Design Principles . . . . . . . . . . . . . . . . . . . . . . 6 5. Information in the Discovery Flow . . . . . . . . . . . . . . 7 6. Determining What Is Minimal . . . . . . . . . . . . . . . . . 9 Cui Expires 5 May 2027 [Page 2] Internet-Draft Minimum Public Discovery Information November 2026 7. Applying the Procedure . . . . . . . . . . . . . . . . . . . 10 8. MDI Information Model . . . . . . . . . . . . . . . . . . . . 14 8.1. Structure . . . . . . . . . . . . . . . . . . . . . . . . 15 8.2. Elements . . . . . . . . . . . . . . . . . . . . . . . . 16 8.3. Information Beyond the Minimum . . . . . . . . . . . . . 18 8.4. Services . . . . . . . . . . . . . . . . . . . . . . . . 19 8.5. Minimal Constraints . . . . . . . . . . . . . . . . . . . 19 9. Binding Expectations . . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 22 11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 13. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 23 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 14.1. Normative References . . . . . . . . . . . . . . . . . . 24 14.2. Informative References . . . . . . . . . . . . . . . . . 25 Appendix A. Illustrative JSON Example . . . . . . . . . . . . . 27 Appendix B. Mapping Notes . . . . . . . . . . . . . . . . . . . 28 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 30 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 30 1. Introduction Clients often need to discover information about AI resources, such as AI agents, before interacting with them [DAWN-CHARTER], and often have no pre-configured relationship with them. Before any interaction can begin, a client needs a small amount of information about the AI resource: what it is, what it does, how to reach it, and what assurances, if any, accompany those claims. [I-D.farrel-dawn-terminology] defines Minimum Discoverable Information (MDI) as the minimum amount of information an entity needs to provide to become discoverable, and does not define its content; [I-D.king-dawn-requirements] requires each discovery mechanism to define the MDI, including at least the entity's type, the services it offers, its reachability information, and the communication protocols and any security parameters needed to interact with it, and to indicate whether discovery information is static or dynamic; [I-D.akhavain-moussa-dawn-problem-statement] calls directly for a standardized structure carrying the minimum information a discovery response returns; and [I-D.moussa-dawn-gap-analysis] sketches a provisional baseline without normalizing it. Mechanism-specific drafts define such fields for their carriers ([I-D.jakab-dawn-agent-discovery-mdns], [I-D.blwm-dawn-common-discovery-parameters]); none defines MDI content independently of a carrier. The DAWN charter [DAWN-CHARTER] places this information at the center of the working group's scope: discovery is limited to a client requesting and obtaining the minimum public discovery information for Cui Expires 5 May 2027 [Page 3] Internet-Draft Minimum Public Discovery Information November 2026 an AI resource (for example, its type, reachability information, communication protocol, and services) within a local network, within an organization, or between cooperating parties with trust relationships over the public Internet. The charter assigns this information to two deliverables: the Discovery Architecture captures the requirements behind it, and the Protocol specifications, possibly one per deployment context, define it. This document uses "MDI" as shorthand for the information the charter calls minimum public discovery information; where the two might differ, the charter's wording governs. Meanwhile, the gap is being filled independently and incompatibly by adjacent ecosystems: DNS-based bootstrap ([I-D.mozleywilliams-dnsop-dnsaid]), well-known JSON manifests, agent cards, and signed capability documents each carry a slightly different minimal field set with slightly different semantics, each bound to its own substrate. A descriptor that is minimal and sufficient in one system is unreadable in another. [I-D.farrel-dawn-terminology] distinguishes the input of discovery, the Minimum Viable Dataset (MVD), from MDI, which it defines by what an entity provides to become discoverable and describes as what a lookup returns. This document considers MDI at both points, publication and response, and relates it to the input. Following the distinction [RFC3444] draws between information models and data models, it describes the information involved in discovery (Section 5), proposes how to decide what is minimal (Section 6), applies that procedure to the charter's three deployment contexts (Section 7), and describes the elements of the common discovery header and the minimal constraints that hold among them (Section 8), leaving encodings to bindings. Section 13 lists the points on which input is sought. 1.1. Requirements Language 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. Cui Expires 5 May 2027 [Page 4] Internet-Draft Minimum Public Discovery Information November 2026 2. Terminology This document uses the terms defined in [I-D.farrel-dawn-terminology], including AI Resource, Entity, Discovered Entity, Discovering Entity, Discovery, Discovery Information, Discovery Scope, Discoverable Object, Capability Card, Trust Indicator, and, centrally, Minimum Discoverable Information (MDI); readers are assumed to be familiar with that document. The elements defined here are the normalized slots through which a minimal subset of an entity's Properties is conveyed as Discovery Information. The entity that MDI describes is a Discovered Entity, which in DAWN is an AI system or AI resource [I-D.farrel-dawn-terminology]; the charter's AI resource "may be an individual named agent or a service such as a catalog that will further the discovery process" [DAWN-CHARTER]. In this document, "resource" is short for AI resource. The client, as the charter calls it, is the Discovering Entity; this document also calls it the discovering party. In addition: Discovery response: What a discovery mechanism returns to a client; it may carry element values for one or more entities. Known context: Information the client already has when it interprets a discovery response, such as the Discovery Scope it searched, the name it started from, or the network it is attached to. Some of it is part of the MVD (Section 5). Minimum Viable Dataset (MVD): As defined in [I-D.farrel-dawn-terminology], "the data that must be provided to the discovery mechanism to enable it to return indications of Discovered Entities" (Section 5). MDI instance: The collection of element values for one entity, as a publisher provides it or as a consumer obtains it (Section 5). A consumer's instance takes each value from the discovery response, known context, or a binding rule. Consumer: The party that interprets an MDI instance, typically the client that performed discovery. 3. Scope and Non-Goals This document defines the abstract content of the MDI common header, and proposes how it is derived (Section 6), within the initial discovery that the DAWN charter scopes [DAWN-CHARTER]. It does NOT define: Cui Expires 5 May 2027 [Page 5] Internet-Draft Minimum Public Discovery Information November 2026 * a discovery, query, resolution, or transport protocol, and it does not bind MDI to DNS or to any other carrier; * a wire format, serialization, or schema; representations are illustrative (Appendix A); * a new capability card, or a replacement for any existing descriptor; * identity verification, authentication, authorization, policy evaluation, or attestation procedures; * capability exchange, negotiation, selection, registration, or invocation semantics; * open-ended search, semantic matchmaking, ranking, indexing or searching across the wider Internet, or trust management and trust evaluation beyond the secure exchange of discovery information, all of which the charter places out of scope. 4. Design Principles Encoding-neutral model: Per [RFC3444], one information model can be carried by many concrete data models -- a JSON object, a CBOR map, a set of DNS records. Those are carriers; MDI is the shared meaning they carry. Information, not fields: Information that initial discovery needs can be carried in a discovery response, supplied by known context (such as the scope searched or the name the client started from), or fixed by a binding. Necessary information therefore need not be repeated in every record. Thin core, rich references: MDI is a header. Rich or sensitive structures -- capability cards, proofs, certificates, policy documents -- are referenced, not embedded, and fetched only when needed. Discovery-time only: MDI carries what lets a discovering party identify an entity, decide whether follow-up is worthwhile, and dereference the next object safely. Freshness and rate of change matter -- elements are marked static, mainly-static, or dynamic, and validity information is first-class -- but detailed cache behavior belongs to bindings (Section 9). Cui Expires 5 May 2027 [Page 6] Internet-Draft Minimum Public Discovery Information November 2026 5. Information in the Discovery Flow Discovery moves information through four stages, and each stage holds different information: Publication: A publisher makes information about an entity available to a discovery system. The publisher can be the entity or a system that maintains information on its behalf, such as an orchestration system [I-D.dunbar-dawn-infra-assisted-discovery]. Published information contains the published MDI instance and can include more, such as administrative or policy data that is never returned to clients. Serving: A system that answers lookups, such as an authoritative DNS server, a registry, a catalog, or a responder on the local link, holds the published information. It can generate or transform parts of the output, for example when an mDNS responder renames an instance after a name conflict or a Discovery Proxy answers unicast queries with the results of mDNS queries [I-D.jakab-dawn-agent-discovery-mdns], and it can add information of its own or hold different views for different audiences. A serving system outside the publisher's administrative domain, such as a gateway or a third-party catalog, is an intermediary. Lookup input: The MVD: the data the discovery mechanism needs to return results. The client supplies some of it in its query, such as a name, a protocol, or a scope; other mechanisms can supply the rest, such as context derived from the client's network attachment. Response: The MDI instances returned for the entities found, interpreted together with known context and binding rules. +-----------+ published MDI and more +-----------------+ | publisher |-------------------------->| | +-----------+ | serving system | | | +-----------+ lookup input (MVD) | can generate, | | client |-------------------------->| transform, or | | |<--------------------------| add | +-----------+ response (MDI) | information | | +-----------------+ | follow-up at an Endpoint: description retrieval, v interaction, or further discovery Figure 1: Information in the discovery flow Cui Expires 5 May 2027 [Page 7] Internet-Draft Minimum Public Discovery Information November 2026 This document proposes that MDI be considered at publication as well as in the response. The individual terminology draft [I-D.farrel-dawn-terminology] defines MDI by what an entity needs to provide to become discoverable and describes a lookup that returns it, and the individual requirements draft [I-D.king-dawn-requirements] asks each mechanism to define the MDI "that every discoverable entity provides"; the charter defines discovery by what a client obtains. The model of Section 8 describes MDI instances at both points: published MDI instances, which publishers provide, and the instances consumers obtain. The correspondence need not be one to one. One published MDI instance can yield several obtained instances, as when a Discovery Proxy relays an advertisement (Section 7), and an entity can have several published MDI instances, per protocol or per publisher; a binding states how they correspond. A published and an obtained instance have the same elements and can differ in which values they carry and in the values themselves: a serving system can generate or transform values, as in the examples above; a binding can fix a value, such as an Endpoint purpose; and known context can supply one, such as a protocol named in the query. Every other value comes from a publisher. Considered at publication, the analysis of Section 6 also indicates what a publisher has to provide, which each binding states (Section 9). Origin and attribution are assessed per value. A value can be verified to the name that a validated key is authorized for, the zone for DNSSEC or the origin for TLS, whoever operates the server. Protection applied at publication, such as a signature by a key that the binding ties to the publisher's name through an authenticated property of the carrier, covers only values that serving systems pass on unchanged. A value that a serving system generates or transforms, as a catalog or a Discovery Proxy does, can be verified at most to that serving system, and only where that system is authenticated; Section 7 applies this to the deployment contexts. A consumer generally obtains only its own instance, so a binding states which values a serving system can generate or transform, and those values are attributable to the serving system unless protection applied at publication covers them. How published information reaches a serving system, for example by zone provisioning, DNS Update, SRP registration, or a registry interface, is a registration mechanism. [I-D.farrel-dawn-terminology] lists registration as a function separate from the discovery lookup and places it out of scope for DAWN, while noting that "the information that can be discovered and the trust with which that information is treated are key to any complete system". This document defines no registration mechanism (Section 3). Cui Expires 5 May 2027 [Page 8] Internet-Draft Minimum Public Discovery Information November 2026 The MVD and MDI can share attributes, such as a protocol that a client asks for and a response reports, and each has items the other lacks, such as a search scope in the input and endpoints in MDI. The sources of the input, how it is conveyed, and how it corresponds to published information are stated for each deployment context and binding. The individual use-cases draft [I-D.kay-dawn-use-cases] leaves to the DAWN architecture which query properties belong in the minimum (Section 13). 6. Determining What Is Minimal The charter gives examples of the minimum public discovery information (type, reachability information, communication protocol, and services) but no list [DAWN-CHARTER]. This document uses one question to decide what belongs: what does a client need to know to use a discovery result? Using a result means the subsequent interactions that the charter names, "such as selection, invocation, or communication": choosing one result, then fetching its description, talking to it, or asking a catalog for more results. An example shows how the question works. A client on a shop's network looks for agents and receives three results. To choose one and talk to it, the client has to tell the three apart, so each result needs a name. It has to know where to connect, such as a host and port or a URL, and which agent protocol to speak there, such as A2A or MCP. It has to know what it will find there: the agent itself, or a description of the agent, such as an agent card. And it has to know whether the result is still current. Other information helps only in some situations: a short description when a person, not software, makes the choice; an authentication scheme when the client talks to the agent directly without reading a description first; and a stable identifier when the client wants to recognize the same agent later or in another result. The rest, such as the full list of what the agent can do, can be read from its description after the choice is made, and is not part of the minimum. Not everything a client needs has to be in every result. A client that asked for A2A agents already knows the protocol, and a discovery mechanism can fix defaults, such as where an agent card is found. For each piece of information, this document therefore records two things: whether a client needs it, and where the client gets it, which is from the result, from its own query, from the rules of the discovery mechanism, or later from a description. The analysis has four steps: 1. List the candidates: the charter's examples and the information that existing discovery mechanisms carry (Appendix B). Cui Expires 5 May 2027 [Page 9] Internet-Draft Minimum Public Discovery Information November 2026 2. For each candidate and each deployment context of the charter, ask: if this were missing, could the client still use the result? If not, the client needs it in that context. 3. For each candidate the client needs, ask whether the client can know it without the result telling it. If not, results have to carry it, and the publisher provides it unless a serving system generates it (Section 5). 4. Where a candidate is needed only in some situations, state the situation. What existing mechanisms carry is evidence for step 1: information that all of them carry can be required at little cost, and information that only some of them carry still has to pass step 2. The charter also requires integrity of all discovery information exchanged; protecting it, and the origin of the information where Table 1 marks this, is an obligation on the binding in every context (Section 9). 7. Applying the Procedure This section applies Section 6 to the three deployment contexts of the charter. Local network: The charter's example is "discover all agents in this shop". The client knows only its network attachment and possibly the agent protocol it wants; it has no name, registry, or prior relationship. DNS-SD over multicast DNS, as the individual draft [I-D.jakab-dawn-agent-discovery-mdns] profiles it for agents, is a representative mechanism. The next step is to tell the candidates apart, choose one, and retrieve its description or interact with it. Within an organization: The charter's example is "discover all Cui Expires 5 May 2027 [Page 10] Internet-Draft Minimum Public Discovery Information November 2026 agents available to employees within their employer's infrastructure". In the case tested here, the client is attached to the organization's network, possibly through a VPN, and can learn from that attachment where to look: DNS-SD domain enumeration queries names derived from a domain name received through DHCP and from the client's address prefixes ([RFC8766], Section 5.2). Representative mechanisms extend those of the other two contexts: DNS-SD beyond the link, through Discovery Proxies [RFC8766] or registration with the Service Registration Protocol (SRP) [RFC9665], as [I-D.jakab-dawn-agent-discovery-mdns] describes for enterprise campus and branch networks, and DNS records in internal zones, which the individual draft [I-D.mozleywilliams-dnsop-dnsaid] provides for. The next step is to choose an agent and retrieve its description or interact with it, or to continue discovery at a catalog. Known domain of a cooperating party: The charter's example is "discover all agents of example.org, for all its customers/ members", between cooperating parties with trust relationships over the public Internet. The client knows the party's domain name and possibly the protocol, and has an organizational trust relationship; knowing the name does not show that information came from that party, and "for all its customers/members" names an audience for the results. DNS records under the party's domain, as proposed in the individual drafts [I-D.mozleywilliams-dnsop-dnsaid] and [I-D.blwm-dawn-common-discovery-parameters], are representative. To find all of a domain's agents, these drafts locate an organizational index at a well-known name such as _index._agents., so the next step is further discovery at that index; a client that already knows an agent's name queries its records directly, then reaches the agent or retrieves its description. +================+================+=================+==============+ | Information | If missing | Other source | Result | +================+================+=================+==============+ | Name of each | Results cannot | The query, when | Needed in | | result | be told apart | it names one | every | | | | entity | context | +----------------+----------------+-----------------+--------------+ | Endpoint | Client cannot | Partly: owner | Needed in | | location | connect | name, default | every | | | | path | context | +----------------+----------------+-----------------+--------------+ | Agent protocol | Client cannot | The query, when | Needed in | | | talk to the | the binding | every | | | endpoint | ties the | context | Cui Expires 5 May 2027 [Page 11] Internet-Draft Minimum Public Discovery Information November 2026 | | | protocol to it | | +----------------+----------------+-----------------+--------------+ | Endpoint | Next step | Protocol or | Needed in | | purpose | unknown | well-known | every | | | | name, via the | context | | | | binding | | +----------------+----------------+-----------------+--------------+ | Freshness | Stale data not | Record lifetime | Needed in | | | recognized | | every | | | | | context | +----------------+----------------+-----------------+--------------+ | Entity type | Mostly covered | Partly | Left to the | | | by the purpose | | WG | +----------------+----------------+-----------------+--------------+ | Display name | Only a person | DNS-SD instance | When a | | | choosing is | name | person | | | affected | | chooses | +----------------+----------------+-----------------+--------------+ | Authentication | Next step can | Description or | When neither | | hint | fail | protocol | supplies the | | | | handshake | scheme first | +----------------+----------------+-----------------+--------------+ | Stable | Results cannot | None | When results | | identifier | be correlated | | are | | | | | correlated | +----------------+----------------+-----------------+--------------+ | Services | Covered by | Description | Left to the | | | Endpoint | | WG | | | protocols and | | | | | Entity Type | | | +----------------+----------------+-----------------+--------------+ | Origin | Publisher | DNSSEC or TLS, | Protection | | | unknown | to the zone or | goal | | | | origin; none | | | | | for mDNS or SRP | | | | | advertisers | | +----------------+----------------+-----------------+--------------+ | Coarse | Nothing; the | Description | Beyond the | | capability | client chooses | | minimum | | labels | by protocol | | | | | and type | | | +----------------+----------------+-----------------+--------------+ | Trust | Nothing beyond | Binding and | Beyond the | | material, | what origin | carrier | minimum | | publisher name | provides | | | +----------------+----------------+-----------------+--------------+ | Scope or | Nothing; the | Query and | Beyond the | | audience hint | audience | deployment | minimum | Cui Expires 5 May 2027 [Page 12] Internet-Draft Minimum Public Discovery Information November 2026 | | applies to the | | | | | lookup | | | +----------------+----------------+-----------------+--------------+ | Availability | The connection | Follow-up | Beyond the | | | fails and the | connection | minimum | | | client tries | | | | | another result | | | +----------------+----------------+-----------------+--------------+ Table 1: Derivation for the three deployment contexts In the Result column, "Protection goal" marks an obligation on the binding (Section 9), "Left to the WG" marks a question in Section 13, and "Beyond the minimum" marks information a client does not need for its next step, which is therefore not part of MDI (Section 8.3). The results are the same in all three contexts; what differs is where the client gets each item. On a local network, each result carries the name, the endpoint location, and the protocol. A query for a known name, as under a cooperating party's domain, supplies the name, and a query for one protocol supplies the protocol. The binding supplies defaults, such as the protocol's default path, and usually the endpoint purpose, which follows from the protocol or from a well- known name such as an index label. Freshness comes from the lifetime of the records a result is built from. The conditional items depend on the next step. A display name matters when a person chooses among results. An authentication hint matters when the client interacts directly and neither a description nor the agent protocol's own handshake supplies the scheme first. A Stable Identifier matters when results are correlated, as when a client within an organization sees the same agent both through multicast DNS on its link and through a Discovery Proxy (Section 8.5). Entity type is largely covered by the endpoint purpose, and services by Endpoint protocols and Entity Type; both are asked in Section 13. Information beyond the minimum can help but is not needed: the client chooses by protocol and type, learns the details from the description, and learns availability at the follow- up connection. Where the results are meant for an audience, as "available to employees" and "for all its customers/members" suggest, the restriction applies to the lookup, for example through split-view DNS or a VPN, and the result carries nothing that enforces it; where this requester context belongs is asked in Section 13. Cui Expires 5 May 2027 [Page 13] Internet-Draft Minimum Public Discovery Information November 2026 Origin is where the contexts differ most. Under a party's domain, DNSSEC-validated records and TLS-authenticated origins tie the information to the party. A catalog or a Discovery Proxy that relays information can be authenticated only as itself, and on a local link multicast DNS does not authenticate advertisements, so the agent is authenticated only at the follow-up connection [I-D.jakab-dawn-agent-discovery-mdns]. How the charter's integrity requirement is met for such advertisements is asked in Section 13. Compared with REQ-PROP-1 of the individual requirements draft [I-D.king-dawn-requirements], reachability and protocol are needed in every context, security parameters (an authentication hint) under a condition, and type and services are questions for the working group. 8. MDI Information Model An MDI instance is the common header published or obtained for one entity. Its elements follow the results of Section 7 (Table 1): * Information needed in every context becomes the mandatory Name and Endpoint (location, agent protocol, and purpose) and the Freshness element. Freshness is SHOULD because its meaning is obtainable from the carrier lifetime; a binding whose carrier provides no lifetime MUST carry it. * Entity type, left to the working group, is the mandatory Entity Type until the question in Section 13 is decided. Services are covered by Endpoint protocols and Entity Type (Section 8.4). * Information needed only under a condition becomes an element with Status MAY: Display Name, Authentication Hint, and Stable Identifier. A publisher cannot always know whether the condition holds for a given consumer; a binding or profile for deployments where it holds can make the element MUST. * Origin is a protection goal, met by the binding (Section 9), and is not an element. * Information beyond the minimum is not an element of MDI. A binding can still carry it as an Extension, and Section 8.3 names the kinds that existing formats and individual drafts carry, so that bindings agree on their meaning. Mandatory elements keep the record very small; in constrained carriers, a binding can derive their values from the carrier or from known context (Section 9). All Status values are provisional. Cui Expires 5 May 2027 [Page 14] Internet-Draft Minimum Public Discovery Information November 2026 Status key words in this document place obligations on the publishers and bindings that claim to carry MDI, and key words addressed to consumers apply to implementations of a binding. Status says how strongly the meaning of an element has to be obtainable by the consumer, from the response, from known context, or from binding rules; whether each response carries a value explicitly is a binding decision. Status applies to the instance a consumer obtains; a publisher provides every value that the binding neither derives nor fixes and that no serving system generates (Section 5). Cardinality governs how many values of an element may be carried. Obligations specific to binding documents are collected in Section 9. 8.1. Structure Figure 2 shows the elements and their shapes. Composite members marked "?" are optional, and freshness, whose members are all optional, is present only when at least one member is present; all other structure is given by the cardinalities. +--------------+ describes exactly one | MDI Instance |---------------------------> Entity +--------------+ |- name (1) |- endpoint { locator-type, locator, | protocols (1..n), purpose?, | digest? } (1..n) |- freshness { version?, valid-from?, | valid-until?, refresh-hint? } (0..1) |- entity-type (1) |- display-name (0..n) |- authentication-hint { scheme, metadata? } (0..n) |- stable-identifier (0..1) |- extension { name, value } (0..n) Reference = { ref-type, locator, digest? } Figure 2: Elements of the MDI model A Reference is a typed pointer, used by the Authentication Hint and by information beyond the minimum: the ref-type says how to interpret the locator, and the optional digest is an integrity digest over the object the locator identifies (Section 8.5). Cui Expires 5 May 2027 [Page 15] Internet-Draft Minimum Public Discovery Information November 2026 8.2. Elements +================+========+===============+=======================+ | Element | Status | Class | Result in Table 1 | +================+========+===============+=======================+ | Name | MUST | varies | Needed in every | | | | | context | +----------------+--------+---------------+-----------------------+ | Endpoint | MUST | mainly-static | Needed in every | | | | | context (location, | | | | | protocol, purpose) | +----------------+--------+---------------+-----------------------+ | Freshness | SHOULD | dynamic | Needed in every | | | | | context; carrier | | | | | lifetime | +----------------+--------+---------------+-----------------------+ | Entity Type | MUST | static | Left to the WG | +----------------+--------+---------------+-----------------------+ | Display Name | MAY | static | When a person chooses | +----------------+--------+---------------+-----------------------+ | Authentication | MAY | mainly-static | When neither | | Hint | | | description nor | | | | | handshake supplies it | +----------------+--------+---------------+-----------------------+ | Stable | MAY | static | When results are | | Identifier | | | correlated | +----------------+--------+---------------+-----------------------+ | Extension | MAY | varies | Mechanism for | | | | | information beyond | | | | | the minimum | +----------------+--------+---------------+-----------------------+ Table 2 A static value is not expected to change while the resource keeps its identity. A mainly-static value changes only through deliberate administrative or deployment action. A dynamic value can change in normal operation and is evaluated together with Freshness. The stability of a Name varies with the carrier and is stated by the binding. The following elements are needed in every context. Name: The name under which a result is found, such as a DNS-SD service instance name or a DNS owner name, which lets a client tell results apart and refer back to them. It is often implicit in the carrier and is interpreted within its naming scope (Section 8.5). One resource can be found under several Names, for Cui Expires 5 May 2027 [Page 16] Internet-Draft Minimum Public Discovery Information November 2026 example one per protocol, and a Name can change, as when multicast DNS renames an instance after a conflict. A Name that the binding states to be stable also serves as the Stable Identifier; such a name is the stable name by which [I-D.farrel-dawn-terminology] identifies a Named Entity. Endpoint: Where follow-up can proceed, for what purpose, and in which agent protocol; the locator is the charter's "reachability information", and the protocols member its "communication protocol". In this document, "agent protocol" means the application protocol that an AI resource speaks at the endpoint, such as A2A or MCP, whether or not the resource is an agent. The locator-type and locator members say where to go; a binding can carry the locator as one value, such as a URI, or assemble it from several fields, such as a target host and port plus a path. The protocols member names the agent protocols reached there, such as A2A or MCP; the protocol negotiated on the underlying TLS or QUIC connection, such as an HTTP version identified by ALPN [RFC7301], is different information unless the agent protocol runs directly over TLS or QUIC. The purpose member says what the follow-up is: retrieving a description of the resource (for example, an agent card), interacting with the resource, or continuing discovery at another discovery service, such as a catalog. When the purpose is not carried, the binding states how it follows from the protocol. An Endpoint for description retrieval is how MDI points to a fuller capability description, such as a Capability Card; its protocols member names the agent protocol of the described resource, the description is fetched as the locator implies (for an https URI, with an HTTP GET), and the Endpoint can carry a digest of the description. An entity can have Endpoints with different protocols and purposes. Freshness: Version, validity window, and refresh hint for the instance. The following element is left to the working group. Entity Type: The kind of AI resource: for example an individual named agent or a service such as a catalog that furthers discovery, the two kinds the charter names [DAWN-CHARTER], or another AI resource such as an AI inference service [I-D.farrel-dawn-terminology]. It lets a client triage before fetching anything. The value space is left to DAWN, bindings, or profiles to define. The following elements are needed under the conditions that Section 7 states. Cui Expires 5 May 2027 [Page 17] Internet-Draft Minimum Public Discovery Information November 2026 Display Name: A short human-readable name or description for a person choosing among results, with no machine semantics. In DNS- SD the Name often serves; under unicast owner names, a binding carries one, as the title parameter of [I-D.blwm-dawn-common-discovery-parameters] does, or takes it from the description. Language handling, if any, is a binding matter. Authentication Hint: The authentication scheme(s) a discovering party would need for follow-up, optionally with a Reference to authentication metadata. Never credentials, never authorization logic. Stable Identifier: A name for the resource itself that stays the same across results, protocols, and time within its naming scope, so that a client can correlate results and recognize the resource later. Like a Name, it is a name, not a verified identity, key, or proof. Extension: An extension named by a binding, profile, or future registry, carrying type-specific or ecosystem-specific information, including the information beyond the minimum of Section 8.3. An Extension does not alter core element semantics and does not reintroduce a non-goal of Section 3. 8.3. Information Beyond the Minimum Table 1 finds that a client does not need the following information for its next step, so it is not part of MDI; REQ-PROP-1 of the individual requirements draft [I-D.king-dawn-requirements] likewise states that "Properties beyond the MDI are optional". Existing formats and individual drafts carry it (Appendix B). A binding that carries it does so as an Extension, with the following meanings: Capability Summary: Coarse, machine-readable capability tags for discovery-time filtering and triage; they are not sufficient for selection, negotiation, authorization, or invocation. The value space is not yet defined (Section 8.4). Trust Reference: A Reference to a trust indicator, such as a signature, certificate, attestation, trust manifest, or key set. Provenance: Who published this discovery information and, optionally, the party responsible for the entity -- information- layer provenance, not verified identity. Scope Hint: An opaque hint about discovery scope, audience, jurisdiction, or visibility. It is not access control (Section 11). Cui Expires 5 May 2027 [Page 18] Internet-Draft Minimum Public Discovery Information November 2026 Operational Hint: A coarse availability or health class, or a Reference to richer operational state, or both. 8.4. Services The charter lists "services" among its examples [DAWN-CHARTER], and REQ-PROP-1 of [I-D.king-dawn-requirements] requires the MDI to include "the services it offers"; neither says what a service is. This document covers services with existing elements, so there is no separate Services element: * The agent protocols a resource offers, such as A2A or MCP, are the protocols of its Endpoints. The per-protocol DNS-SD subtypes proposed for agents, such as "_a2a._sub._agents._tcp", name these protocols [I-D.jakab-dawn-agent-discovery-mdns]. * A resource that is itself a service, such as a catalog that furthers discovery, as the charter's scope notes, is identified by its Entity Type and by an Endpoint whose purpose is continuing discovery. Coarse labels for what a resource does are the Capability Summary, which is beyond the minimum (Section 8.3). The individual draft [I-D.zhang-dawn-bgp-style-federated-discovery] makes such labels mandatory, while [I-D.blwm-dawn-common-discovery-parameters] leaves capabilities out of DNS records and notes that coarse categories, if ever needed, could use DNS-SD subtypes. A shared vocabulary for the labels does not yet exist, and labels used for more than triage would be capability information beyond the minimum, which the charter places out of scope. Whether this reading of "services" is right is asked in Section 13. 8.5. Minimal Constraints The following rules are part of the model. A binding MAY tighten them but MUST NOT relax them. 1. An MDI instance describes exactly one entity. A discovery response may carry information for several entities; aggregation is a carrier matter. 2. Each Name and Stable Identifier is interpreted within a naming scope, which by default is the publisher scope. A binding states the naming scope and stability period of each Name and Stable Identifier it carries and how values are compared, with exact match as carried as the default. A Name distinguishes results only within its naming scope and stability period, and one resource may be found under several Names. The host name at Cui Expires 5 May 2027 [Page 19] Internet-Draft Minimum Public Discovery Information November 2026 which an endpoint is reached (such as an SVCB TargetName) belongs to the Endpoint locator and names a host, even where the same string is also a Name. Correlating results to one resource without a Stable Identifier is heuristic. Within one naming scope, equal Stable Identifiers denote the same resource; unequal ones do not by themselves denote distinct resources, and across naming scopes this model makes no sameness claim. Where a consumer holds several instances with the same Stable Identifier, it reconciles them by Freshness only among instances whose integrity and origin in that naming scope have been verified as the binding defines, using only Freshness values that the same verification covers; an instance that has not passed those checks does not displace one that has, and other cases are left to the binding. 3. Protocols attach to endpoints, not to the instance as a whole. A protocols value names an agent protocol, not the protocol negotiated on the underlying connection, such as an HTTP version, except where the two coincide (Section 8.2). An instance-level protocol list, where a binding offers one, is derived information (the union over all endpoints) and cannot diverge from them. The model attaches no meaning to the order of Endpoints; preference and selection are binding or carrier matters. 4. A digest, when present, is a member of the Reference or of the description-retrieval Endpoint it protects and covers exactly the object located there. Integrity is not trust: a matching digest shows that the bytes are intact, provided the digest itself was obtained with integrity, and it does not show that the publisher or the entity should be believed. A consumer MUST NOT use an object whose digest does not match. How a digest value identifies its algorithm is defined by the binding. 5. A consumer MUST ignore unrecognized Extensions; their presence is not an error. As an exception, a binding MAY mark an Extension as mandatory, as SVCB does with its "mandatory" key ([RFC9460]); unless the binding says otherwise, a consumer that does not understand a mandatory Extension does not use the Endpoint or result that carries it, as an SVCB client skips a record that lists a mandatory key it does not support. 9. Binding Expectations MDI reaches the wire through bindings: documents that map this model onto a concrete encoding or discovery mechanism. Existing discovery formats already approximate bindings (Appendix B); normative bindings are expected in separate documents. A binding that carries MDI MUST specify: Cui Expires 5 May 2027 [Page 20] Internet-Draft Minimum Public Discovery Information November 2026 Encoding: How each element is encoded and which value space it uses, defined by the binding, a profile, or a future registry. Which values are implicit and how they are derived from the carrier or from known context, for example a Name taken from a DNS-SD service instance name; an implicit value counts exactly as an explicit one. How unrecognized Extensions are carried and skipped at the encoding level, and which Extensions, if any, are mandatory. Names and Endpoints: The naming scope and stability period of each Name and Stable Identifier it carries, and whether it carries a Stable Identifier at all. For each Endpoint, how the locator is assembled, how the purpose is determined when it is not carried, and, where connection-level protocols are also carried, how they are kept apart from the protocols member. For an Endpoint for description retrieval, which object a digest covers. For Endpoints whose purpose is continuing discovery, the maximum referral depth, how loops are detected, and the naming scope of the results obtained there. Integrity and origin: How the integrity and origin of the MDI it conveys are protected, including how carried values are bound to the carrier fields and known context they are interpreted with, for example that a response answers the name or scope the client asked about, and where verification material comes from. How the publisher scope is determined from an authenticated property of the carrier, such as a DNSSEC-validated owner name or a TLS- authenticated web origin, never from values the instance asserts about itself, such as Provenance, and what publisher scope, if any, applies where a serving system generates the content from unauthenticated sources, as a Discovery Proxy does. Whether information relayed by a catalog or other intermediary is verified to the original publisher or only to the intermediary. How a consumer treats failed verification, removed elements, and expired information, and what successful verification establishes and what it does not. Sources and lifetimes of values: Which values the publisher provides and which a serving system generates or transforms, how a consumer tells them apart, how what an intermediary adds or changes is attributed to it, and which publisher an obtained instance derives from when several provide information for one entity. How carrier lifetimes, such as a DNS TTL or an HTTP cache lifetime, combine with Freshness, including which record lifetimes apply when a result is assembled from several records, with the earliest applicable expiry prevailing, and how stale or replayed information is detected. Cui Expires 5 May 2027 [Page 21] Internet-Draft Minimum Public Discovery Information November 2026 A binding MUST protect the integrity of all MDI it conveys, as the charter requires [DAWN-CHARTER]; what meets this requirement where the carrier does not authenticate advertisements is asked in Section 13. A binding MAY tighten Status, cardinality, or constraints, including per entity type, but MUST NOT relax a MUST element or a rule of Section 8.5. 10. Security Considerations MDI is advertised information; a consumer MUST treat it as unverified until corroborated by mechanisms outside this document. * Values prove nothing by themselves. Any value can be forged by whoever publishes or serves it: a Name or Stable Identifier is not proof of identity, and an Endpoint does not prove that the reachable party is the intended entity. A matching digest shows only that a referenced object is the one the digest was computed over, and only if the digest was obtained with integrity; it does not show that the publisher or the entity can be trusted. A Display Name or other text chosen by the publisher can imitate another entity, including through visually confusable characters, or carry text aimed at automated consumers; a client presents such text as unverified, does not use it to identify or authorize, and does not treat it as instructions. An Authentication Hint, and any metadata at its locator, is unverified; it does not lead a client to weaken its authentication requirements or to send credentials to a party named only by unverified MDI. A Trust Reference locates assurance material but confers none until that material is verified by procedures defined elsewhere. * Protection comes from the binding and the carrier, value by value. Integrity and origin, including protection against the removal of optional elements, are properties of the binding and carrier (for example DNSSEC, TLS); each binding states how it provides them and to whom origin is verified (Section 9). A serving system can generate, transform, withhold, or replay values, and protection applied at publication covers only the values it protects. A value derived from the carrier is as trustworthy as that carrier, and a value taken from known context is no more trustworthy than that context. A consumer SHOULD NOT draw conclusions from the absence of an element. A referral to another discovery service does not extend the referring publisher's naming scope or protection to the results obtained there. * Every locator in MDI, whether of an Endpoint, a Reference, or authentication metadata, is supplied by an unverified party, and following it carries the usual risks of contacting an untrusted party. The usual dereferencing protections apply, such as limits Cui Expires 5 May 2027 [Page 22] Internet-Draft Minimum Public Discovery Information November 2026 on redirects and response sizes. Which addresses a client connects to is a matter of deployment policy, applied to the addresses a locator resolves to at connection time, including after redirects. Link-local and internal addresses are expected results of local and organizational discovery; unless deployment policy permits otherwise, a client does not connect to them when they appear in information obtained from outside that context. 11. Privacy Considerations Publishing MDI can reveal entity names, endpoints, organizational structure, capability hints, and scope information. Publishers SHOULD minimize public MDI to what discovery requires and SHOULD place sensitive information -- detailed capabilities, policy, internal topology, operational state -- behind access-controlled references. A Stable Identifier lets any observer correlate an entity across results, protocols, and time. Where an entity acts for an individual, its names, identifiers, and Provenance can be personal data; publishers that do not need correlation can omit a Stable Identifier. A Scope Hint is not access control. Published information, including data never returned to clients, is disclosed to every serving system that holds it, and views for different audiences stay separate only as far as that system keeps them apart. A key used to sign published MDI instances can be tracked like an identifier ([RFC9665], Section 7): a key unique to an entity correlates that entity as a Stable Identifier does, and a key shared by a publisher links the entities it publishes. Results obtained under an audience restriction carry no marker of it; a cache, intermediary, or consumer that passes them outside that audience discloses internal names, endpoints, and topology. A Discovery Proxy makes advertisements visible to whoever can query it, and the domain a result appears under can reveal where a device, and a person it acts for, is ([RFC8766], Section 9.2). 12. IANA Considerations Future revisions or binding documents may request registries for selected MDI value spaces, such as entity types or protocol identifiers; existing registries are to be reused where applicable. 13. Open Issues Input from the working group is sought on the following questions: Cui Expires 5 May 2027 [Page 23] Internet-Draft Minimum Public Discovery Information November 2026 * Is the procedure of Section 6 an acceptable basis for deciding what belongs in the minimum public discovery information? Are the results of Section 7 right, including the conditions under which a display name, an authentication hint, or a Stable Identifier is needed, and is the information that Table 1 places beyond the minimum correctly left out of MDI? If so, should this document keep naming that information for bindings (Section 8.3), or leave it to bindings and profiles? * Should MDI be defined only by what a client obtains, or also at publication? This document proposes both points, with Status defined for the instance a consumer obtains and a publisher's obligations derived from it per binding (Section 5); an alternative is to set Status separately for published MDI instances. * Which items of the MVD should DAWN specify for each deployment context? Is requester context, such as the audience that "available to employees" or "for all its customers/members" implies, part of the MVD, and if so who supplies it, or is it access control outside discovery? Is information restricted to such an audience public in the charter's sense? * How should the charter's examples "type" and "services" be read? Entity Type can remain MUST or follow from the endpoint purpose. This document covers services by the protocols of Endpoints and by Entity Type, and places coarse labels (Capability Summary) beyond the minimum (Section 8.4); is that right? * Where an agent's advertisement or registration is not authenticated to its operator, as with multicast DNS, a Discovery Proxy relaying it, or SRP, how is the charter's requirement for integrity of the information exchanged met: by authenticating the agent at the follow-up connection, by that together with protection of the hop that delivers the information, such as a Discovery Proxy's DNSSEC signature, or only by protecting the advertisement to its origin, for example with authenticated DNS Update ([RFC8766], Section 9.1), which places a requirement on registration (Section 5)? See Section 7. 14. References 14.1. Normative References [I-D.farrel-dawn-terminology] Farrel, A., Yao, K., Schott, R., and N. Williams, "Terminology for the Discovery of Agents With Names (DAWN)", Work in Progress, Internet-Draft, draft-farrel- Cui Expires 5 May 2027 [Page 24] Internet-Draft Minimum Public Discovery Information November 2026 dawn-terminology-06, 28 October 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . 14.2. Informative References [DAWN-CHARTER] IETF, "Discovery of Agents With Names (dawn) Working Group Charter", October 2026, . [I-D.akhavain-moussa-dawn-problem-statement] Akhavain, A., Moussa, H., and D. King, "Problem Statement for the Discovery of Agents, Workloads, and Named Entities (DAWN)", Work in Progress, Internet-Draft, draft-akhavain- moussa-dawn-problem-statement-05, 19 July 2026, . [I-D.blwm-dawn-common-discovery-parameters] Brockners, F., Jakab, L., Williams, N., and J. Mozley, "Common Agent DNS Discovery Parameters", Work in Progress, Internet-Draft, draft-blwm-dawn-common-discovery- parameters-00, 27 October 2026, . [I-D.dunbar-dawn-infra-assisted-discovery] Dunbar, L. and B. Zhang, "Infrastructure-Assisted Discovery for AI Agents", Work in Progress, Internet- Draft, draft-dunbar-dawn-infra-assisted-discovery-02, 16 October 2026, . Cui Expires 5 May 2027 [Page 25] Internet-Draft Minimum Public Discovery Information November 2026 [I-D.jakab-dawn-agent-discovery-mdns] Jakab, L. and F. Brockners, "Zero-Configuration Agent Discovery", Work in Progress, Internet-Draft, draft-jakab- dawn-agent-discovery-mdns-01, 28 October 2026, . [I-D.kay-dawn-use-cases] King, D., Yao, K., Adler, K., and R. Ramdhany, "Use Cases and Applicability for Discovery of Agents With Names", Work in Progress, Internet-Draft, draft-kay-dawn-use- cases-01, 10 September 2026, . [I-D.king-dawn-requirements] King, D. and A. Farrel, "Requirements for the Discovery of Agents With Names (DAWN)", Work in Progress, Internet- Draft, draft-king-dawn-requirements-02, 19 October 2026, . [I-D.moussa-dawn-gap-analysis] Moussa, H. and A. Akhavain, "Gap Analysis and Applicability Statement for Discovery Protocols of Agents, Workloads, and Named Entities (DAWN)", Work in Progress, Internet-Draft, draft-moussa-dawn-gap-analysis-01, 12 June 2026, . [I-D.mozleywilliams-dnsop-dnsaid] Mozley, J., Williams, N., Sarikaya, B., Schott, R., and J. Damick, "DNS for AI Discovery", Work in Progress, Internet-Draft, draft-mozleywilliams-dnsop-dnsaid-02, 27 May 2026, . [I-D.zhang-dawn-agent-discovery-framework] Zhang, B., Dunbar, L., and Y. Yang, "A Framework for Agent Discovery in DAWN", Work in Progress, Internet-Draft, draft-zhang-dawn-agent-discovery-framework-09, 20 October 2026, . Cui Expires 5 May 2027 [Page 26] Internet-Draft Minimum Public Discovery Information November 2026 [I-D.zhang-dawn-bgp-style-federated-discovery] Zhang, B., "Federated Agent Metadata Synchronization Protocol (FAMS-P)", Work in Progress, Internet-Draft, draft-zhang-dawn-bgp-style-federated-discovery-00, 14 October 2026, . [RFC3444] Pras, A. and J. Schoenwaelder, "On the Difference between Information Models and Data Models", RFC 3444, DOI 10.17487/RFC3444, January 2003, . [RFC7301] Friedl, S., Popov, A., Langley, A., and E. Stephan, "Transport Layer Security (TLS) Application-Layer Protocol Negotiation Extension", RFC 7301, DOI 10.17487/RFC7301, July 2014, . [RFC8766] Cheshire, S., "Discovery Proxy for Multicast DNS-Based Service Discovery", RFC 8766, DOI 10.17487/RFC8766, June 2020, . [RFC9460] Schwartz, B., Bishop, M., and E. Nygren, "Service Binding and Parameter Specification via the DNS (SVCB and HTTPS Resource Records)", RFC 9460, DOI 10.17487/RFC9460, November 2023, . [RFC9665] Lemon, T. and S. Cheshire, "Service Registration Protocol for DNS-Based Service Discovery", RFC 9665, DOI 10.17487/RFC9665, June 2025, . Appendix A. Illustrative JSON Example Cui Expires 5 May 2027 [Page 27] Internet-Draft Minimum Public Discovery Information November 2026 { "name": "invoice-bot", "entity_type": "agent", "endpoint": [ { "locator_type": "uri", "locator": "https://example.com/.well-known/agent-card.json", "protocols": [ "a2a" ], "purpose": "description" }, { "locator_type": "uri", "locator": "https://example.com/agent", "protocols": [ "a2a" ], "purpose": "interaction" } ], "freshness": { "valid_until": "2026-09-01T00:00:00Z" }, "display_name": "Invoice assistant", "stable_identifier": "urn:example:agent:invoice-bot", "extension": [ { "name": "capability-summary", "value": [ "invoicing" ] } ] } Appendix B. Mapping Notes The table sketches where the mandatory elements of MDI, the Stable Identifier, the description Endpoint, and Freshness surface in the DNS and DNS-SD parameters proposed in [I-D.blwm-dawn-common-discovery-parameters] for SVCB records ([RFC9460]) and DNS-SD TXT records, as used by [I-D.jakab-dawn-agent-discovery-mdns], and in the generic well-known- JSON and agent-card patterns (no single specification is implied). Field names are indicative; full mappings belong to binding documents. Cui Expires 5 May 2027 [Page 28] Internet-Draft Minimum Public Discovery Information November 2026 +===========+===================+===============+===================+ |MDI element| DNS and DNS-SD | Well-known | Agent Card | | | | JSON | | +===========+===================+===============+===================+ |Name | instance or | (document | (card URL) | | | owner name | URL) | | +-----------+-------------------+---------------+-------------------+ |Stable | none; shared | identity | agent_id | |Identifier | desc-ref | | | | | suggests one | | | | | agent | | | +-----------+-------------------+---------------+-------------------+ |Entity Type| (service type | (metadata) | (metadata) | | | or name) | | | +-----------+-------------------+---------------+-------------------+ |Endpoint | SRV/SVCB target | endpoints | endpoint.url | |locator | and port, plus | | | | | path or well- | | | | | known | | | +-----------+-------------------+---------------+-------------------+ |Endpoint | proto | (in | endpoint.protocol | |protocols | | endpoints) | | +-----------+-------------------+---------------+-------------------+ |Endpoint | implied by | (interaction) | (interaction) | |purpose | proto, or by | | | | | the _index | | | | | label | | | +-----------+-------------------+---------------+-------------------+ |Description| desc-ref | descriptor | (the card itself) | |Endpoint | | URI | | +-----------+-------------------+---------------+-------------------+ |Freshness | DNS TTL; desc- | version | version | | | ref-digest as | | | | | change signal | | | +-----------+-------------------+---------------+-------------------+ Table 3 In the DNS and DNS-SD column, proto carries the agent protocol; the alpn parameter carries the protocol negotiated on the TLS or QUIC connection and corresponds to no MDI element. [I-D.mozleywilliams-dnsop-dnsaid] carries the agent protocol in alpn or in a separate bap parameter. Each record carries one proto value, so a resource that offers several protocols appears in several records: in DNS-SD each has its own instance name, while unicast SVCB records share one owner name. Each record supplies the Endpoint for its protocol, and a desc-ref Cui Expires 5 May 2027 [Page 29] Internet-Draft Minimum Public Discovery Information November 2026 supplies an Endpoint for description retrieval, whose description can be hosted elsewhere. [I-D.blwm-dawn-common-discovery-parameters] and [I-D.jakab-dawn-agent-discovery-mdns] infer from a shared desc-ref that records belong to one agent; [I-D.blwm-dawn-common-discovery-parameters] states that desc-ref is neither a universal identifier nor authenticated. The desc-ref- digest parameter is defined as a freshness signal, not a security signal, and maps to Freshness; it is not the digest of the description Endpoint (rule 4 of Section 8.5). The locator is assembled from the SRV or SVCB target and port plus the path or well-known parameter or, absent both, the protocol's default location (for A2A, /.well-known/agent-card.json). Whether the advertised location serves description retrieval or interaction follows from the protocol: for A2A it serves the agent card, from which interaction URLs are taken, while for MCP it is the interaction endpoint [I-D.jakab-dawn-agent-discovery-mdns]. The individual drafts [I-D.zhang-dawn-bgp-style-federated-discovery] and [I-D.zhang-dawn-agent-discovery-framework] define a TLV binding of MDI elements for exchange between gateways, including an Entity- Identifier and a Capability-Summary. In [I-D.zhang-dawn-bgp-style-federated-discovery], the Entity- Identifier, which together with the Origin-GW-ID keys a record, can serve as the Name and corresponds to the Stable Identifier; the Capability-Card-URI is an Endpoint for description retrieval; and the Capability-Summary, Trust-Reference, and Provenance TLVs correspond to the information of the same names beyond the minimum (Section 8.3). That draft makes the Capability-Summary mandatory, while Table 1 places coarse capability labels beyond the minimum. Acknowledgements The author thanks Chenguang Du for his valuable contributions to the design and text of this draft. This work builds on the DAWN terminology, requirements, problem statement, and gap-analysis documents. Author's Address Yong Cui Tsinghua University Beijing 100084 China Email: cuiyong@tsinghua.edu.cn URI: http://www.cuiyong.net/ Cui Expires 5 May 2027 [Page 30]