The Intent-to-Capability Knowledge Gap in Discovery of Agents With Names

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

The DAWN charter [DAWN-CHARTER] says clients need to learn how to reach AI resources and what those resources offer. It limits the work to the initial discovery of minimum public discovery information within a local network, an organisation, or between cooperating parties, and it excludes open-ended search, semantic matchmaking, ranking, and selection based on capabilities or user intent.¶

The DAWN documents describe discovery as starting from a task or intent that is turned into a discovery request [I-D.kay-dawn-use-cases]. The step from intent to request is assumed, not described. This document examines it. An intent can usually be satisfied in several ways, each needing different capabilities, and the best way depends on what is available. What is available is learned by discovery, and discovery requests are formed from the chosen capabilities.¶

The aim is to make the gap explicit so that the Architecture work can treat it deliberately and not define the MDI on the silent assumption that clients already know what to ask for.¶

2. Terminology

The following terms are used as defined in [I-D.farrel-dawn-terminology]: Capability, Capability Card, Discovered Entity, Discovering Entity, Discovery, Discovery Information, Discovery Mechanism, Discovery Scope, Entity, Function, Minimum Discoverable Information (MDI), Properties, and Selection.¶

This document adds four terms.¶

Intent:

A goal held by a discovering entity or by a user on whose behalf it acts, not necessarily expressed in terms of any published capability.¶

Decomposition:

A mapping from an intent to one or more plans, each a set of capabilities whose combined fulfilment would satisfy the intent.¶

Capability Identifier:

A token or description in which a discovery request or MDI expresses a Function or Capability.¶

Scope Enumeration:

A discovery request that asks for the MDI of all entities visible within a Discovery Scope, without filtering by capability.¶

3. The Knowledge Gap

4. Strategies

Five ways of handling the gap are described. They differ in where matching happens and what they cost. They are not exclusive.¶

A. Identifier probing.

The client holds a vocabulary and queries for identifiers from candidate plans. It needs the vocabulary in advance, and a series of probes can reveal the intent. It scales poorly with open-ended intents.¶

B. Intent forwarding.

The client sends the intent, or a close paraphrase, to a catalog that matches it. This removes the circularity and needs no vocabulary, but it discloses the intent and is semantic matchmaking, which the charter excludes.¶

C. Scope Enumeration with client-side matching.

The client asks for all MDI in a Discovery Scope and evaluates it against its own plans. The intent never leaves the client. It works only where the Discovery Scope is small enough to enumerate and where the MDI is descriptive enough to interpret without a pre-agreed vocabulary. The charter example "discover all agents in this shop" is of this kind.¶

D. Brokered discovery.

The client discovers a planning or coordinating entity, such as a journey planner, by a coarse Capability Identifier, then gives it the intent in the application exchange. This keeps the intent out of discovery and semantic matching out of DAWN, but it still needs a coarse vocabulary and puts trust and privacy exposure on the broker. The requirements already ask for discovery of brokers (REQ-DISC-3).¶

E. Reversed discovery.

The client publishes its need as a discoverable object and providers find it, as the problem statement describes for tasks. This needs no vocabulary on the client side, but it publishes the intent to everyone who can see the Discovery Scope.¶

Within the charter as written, A, C, and D are available. A depends on a full vocabulary and D on a coarse one. C depends on what the MDI contains, which is the first question in Section 6.¶

5. Scalability of the Strategies

The strategies differ mostly in who bears the scaling cost, not in whether there is one. This section is qualitative and assumes that no central registry is available (REQ-ARCH-1).¶

A:

The server side scales like DNS-SD [RFC6763]: exact match, cacheable, and delegable. The cost moves to the client, which probes more as intents become open-ended, and to the vocabulary. Privacy mitigations add cost; the privacy draft itself notes that private information retrieval may not cope with DAWN's scale [I-D.iannone-dawn-privacy-considerations].¶

B:

The worst fit. Matching free-form intents needs an aggregated index across domains, which conflicts with REQ-ARCH-1 and with independent publication (REQ-ARCH-2).¶

C:

Richer MDI reduces the need for a shared vocabulary but enlarges every enumeration. For a language-model client the limit is not bandwidth but context budget and interpretation cost, so C trades the vocabulary problem for a compute and trust problem. Dynamic properties defeat caching and are better carried by reference. C scales by hierarchy (a shop, a mall, a city), which makes the granularity of Discovery Scopes a real design question.¶

D:

Finding a broker is cheap, because broker types are few, coarse, and stable. The broker must know the offers, so the market tends toward a few large brokers, and brokers that discover brokers can cascade without bound.¶

E:

Write load follows the number of clients, and every provider must scan every need. It needs expiry and rate limiting.¶

Intents that span several Discovery Scopes multiply the cost, because chained discovery needs sequential rounds. A and D handle this through delegation; C needs the client to know the scopes. The combination that scales best on paper is hierarchical: a coarse probe (A) finds the scope or broker, enumeration (C) runs inside a small scope, and a broker (D) handles cross-scope intents. What remains open is how a client finds the right scopes.¶

6. Questions for the DAWN Architecture

MDI content.

If Strategy C is to work without a shared vocabulary, the MDI must be interpretable on its own, which suggests descriptive content and not only an identifier. What keeps such content minimal, how is it language-tagged, and where does it end and a capability card begin? The terminology describes the MDI as a common header of a data structure, and "services offered" in REQ-PROP-1 does not settle this.¶

Enumeration and abuse limits.

Strategy C needs enumeration to be possible. The requirements ask the mechanism to limit abuse including scraping (REQ-SEC-3), and ask a specification to say whether it resists enumeration, failing which the set of discoverable entities is to be treated as public. The Architecture will have to say which Discovery Scopes allow enumeration, to whom, and at what cost.¶

Truncation.

REQ-DISC-4 asks for an indication of truncated results. What should a client do with a partial enumeration: page through it, narrow the Discovery Scope, or refine the request?¶

Chained and multi-scope intents.

An intent such as the long-distance case in Appendix A needs offers from several Discovery Scopes that the client does not know in advance. Finding them is an indexing problem, which the charter excludes. Is referral (REQ-DISC-3) expected to carry this, and should chained and interactive discovery be added to the use cases?¶

Vocabulary ownership.

Extensible schemas are required (REQ-EXT-1), but nobody is assigned to define Function identifiers, and the naming of entities is out of scope. Service types in existing service discovery come from a registry [RFC6763]. Can a registry keep pace with agent capabilities, and what would DAWN carry if none exists?¶

7. Security Considerations

Integrity protection shows that discovery information was not altered in transit. It does not show that the information is accurate or safe to interpret. Strategy C asks clients to read descriptive MDI, often with a language model, so that content is untrusted input. A publisher can write descriptions to match as many intents as possible or to steer a client's behaviour; the AID draft already lists inputs from an index that modify agent reasoning as an adversarial use [I-D.mozley-aidiscovery]. Enumerations also let an attacker add or remove entries to shape a client's plan, and large results can exhaust a client's processing budget.¶

8. Privacy Considerations

Discovery queries can reveal intent; the privacy draft gives a medical-dataset example [I-D.iannone-dawn-privacy-considerations]. The strategies differ in exposure.¶

• Granularity: fine-grained queries are selective but reveal more; coarse queries reveal less and return more. A destination or a medical need should not appear in a discovery query.¶
• Series: repeated probing (A) can reveal an intent when each query is coarse, and repeated queries to one service can be correlated. Private information retrieval, named in the privacy draft, may help but its scaling is unproven.¶
• Enumeration (C): reveals the chosen Discovery Scope but not the intent. A location-bounded scope reveals location.¶
• Brokers (D) learn the full intent, and reversed discovery (E) publishes it.¶
• Multicast queries are visible to every node on the link.¶

A sound default is to keep the intent out of the discovery exchange and to carry it only in an authenticated application exchange with an entity the client has chosen.¶

9. IANA Considerations

This document has no IANA actions.¶

Appendix A. Worked Example

A user's agent holds the intent "get to place X as fast as possible". The three situations of Section 3.1 need different capabilities: bicycle rental, a taxi, or local transit plus rail plus an airline.¶

A (probing):

The agent probes for bicycle, taxi, rail, and airline capabilities. It needs the identifiers beforehand, and the probes show that the user is travelling and roughly how.¶

B (forwarding):

The agent sends "get to X fast" to a catalog. It needs no identifiers, but the destination is disclosed.¶

C (enumeration):

The agent enumerates a Discovery Scope it knows, such as the local network or the city transport organisation, and matches locally. This covers the first two situations if the scope contains them. It does not cover the third unless the agent can find the rail and airline scopes (Section 6).¶

D (broker):

The agent discovers a journey planner by a coarse capability, then sends the destination to it in an application exchange. Discovery reveals only that a planner was sought. The user must trust the planner with the destination.¶

E (reversed):

The agent publishes "need a fast route to X". Any provider in the Discovery Scope can respond, and everyone there learns the destination.¶

Author's Address