The Intent-to-Capability Knowledge Gap in Discovery of Agents With Names
draft-hecker-dawn-intent-capability-gap-00

Network Working Group                                          A. Hecker
Internet-Draft                      Huawei Technologies Duesseldorf GmbH
Intended status: Informational                          28 October 2026
Expires: 1 May 2027

        The Intent-to-Capability Knowledge Gap in Discovery
                        of Agents With Names
           draft-hecker-dawn-intent-capability-gap-00

Abstract

   DAWN defines discovery as an initial step that returns minimum
   discoverable information (MDI) about entities.  Clients, however,
   usually start from an intent, not from a name or a capability, and
   the capabilities needed to satisfy an intent depend on what is
   available.  A client therefore has to know what is on offer to
   decide what to look for, and has to decide what to look for to learn
   what is on offer.

   This document describes that circular dependency, locates it in the
   current DAWN documents, compares five strategies for handling it,
   and lists questions for the Architecture work.  The main question is
   what the MDI must contain for a client to act without a pre-agreed
   capability vocabulary.  This document proposes no protocol.

Editorial Note (to be removed before publication)

   Reviewed for this version: the DAWN charter (charter-ietf-dawn-01),
   [I-D.king-dawn-requirements] -02, [I-D.farrel-dawn-terminology] -05,
   [I-D.kay-dawn-use-cases] -01, [I-D.akhavain-moussa-dawn-problem-
   statement] -05, [I-D.mozley-aidiscovery] -01 (expired), and
   [I-D.iannone-dawn-privacy-considerations] -00 (mostly placeholders).
   The agentic AI use-case drafts were seen only in excerpts and are
   not analysed.  REQ identifiers refer to requirements -02, which
   renumbered those of -01 that the use cases draft cites.

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.

Table of Contents

   1.  Introduction
   2.  Terminology
   3.  The Knowledge Gap
     3.1.  The Circular Dependency
     3.2.  What This Is Not
     3.3.  Where the Gap Sits in the DAWN Documents
   4.  Strategies
   5.  Scalability of the Strategies
   6.  Questions for the DAWN Architecture
   7.  Security Considerations
   8.  Privacy Considerations
   9.  IANA Considerations
   10. Informative References
   Appendix A.  Worked Example
   Author's Address

1.  Introduction

   The 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

3.1.  The Circular Dependency

   1.  To form a discovery request, a client needs a decomposition of
       its intent, or at least candidate capabilities to ask about.

   2.  The best decomposition depends on which capabilities are
       available, and valid decompositions are usually numerous.

   3.  Which capabilities are available can be learned only by
       discovery.

   Take the intent "get to place X as fast as possible".  If X is
   within walking distance in a dense city, a bicycle service may be
   best.  If X is 30 km away, a taxi may be best.  If X is 1000 km
   away, a train to an airport and a flight may be best.  The client
   does not initially know its distance to X or what is around it, and
   learning those things is itself a matter of finding and querying
   resources.

   A client that cannot form a request cannot discover.  A client that
   forms requests blindly either asks about many capabilities, which is
   costly and revealing, or about too few, and may miss a better plan.
   Sending the whole intent as the request is unlikely to match any
   published capability exactly, and it discloses the intent.

3.2.  What This Is Not

   Bootstrapping:  How a client learns which domain, network, or entry
      point to query is a known problem with known solutions, such as
      provisioning, configuration, or a first multicast query.  This
      document assumes the client has an entry point for the Discovery
      Scope it cares about.

   Vocabulary definition:  Agreeing that a printer is called a printer
      is a vocabulary problem.  The gap persists even with a perfect
      dictionary.  The client would know which names might exist, but
      not which are offered in this Discovery Scope, nor which
      combinations satisfy its intent.  It could probe the dictionary
      entry by entry, but probing makes the gap a scalability and
      privacy problem: the number of probes grows with the dictionary,
      and the pattern of probes reveals the intent.

   The classic model, a query for a printer that handles a given page
   description language, assumes the client already holds the
   Capability Identifier.  The gap concerns a client that holds only
   an intent.

3.3.  Where the Gap Sits in the DAWN Documents

   Charter and terminology.  The terminology draft defines Discovery
   as locating entities able to perform a desired function.  It also
   breaks the discovery ecosystem into functions, one of which is
   search based on a "formalised encoding of search criteria", and
   places only the discovery lookup in scope.  The gap sits between
   the two: lookup needs criteria, and producing criteria from an
   intent is not part of the work.

   Requirements.  [I-D.king-dawn-requirements] requires discovery of
   both specific entities and classes of entities that can perform a
   function (REQ-DISC-1).  It also says discovery starts from "a name
   or scope known to the discovering entity" (REQ-DISC-4).  Together
   these describe discovery by function within a Discovery Scope.
   Nothing says how the function is chosen.  The MDI is to include the
   type and "services it offers" (REQ-PROP-1), but the documents do not
   say whether that is an identifier or a description.  A reference to
   a capability card is allowed, with its content out of scope
   (REQ-PROP-4).  The requirements do help Scope Enumeration: results
   should say whether a Discovery Scope was fully searched or
   truncated (REQ-DISC-4), and absence may be reported only from a
   complete result (REQ-PROP-3).

   Use cases.  The pattern in [I-D.kay-dawn-use-cases] runs from intent
   to request to candidates, and its examples begin at the request,
   with the organisation and capability already known.  The problem
   statement lists chained, interactive, and reversed discovery among
   topics for the use cases document, and names blind or exploratory
   search among things current approaches do not handle
   [I-D.akhavain-moussa-dawn-problem-statement].  The current use cases
   draft has none of these as a category.  Chained discovery, in which
   later queries depend on earlier results, is the circular dependency
   of Section 3.1 in iterative form.  The problem statement also
   names semantic matching as a possible discovery mechanism, which
   sits uneasily with the charter exclusion.

   Discovery Scope.  The terminology allows a Discovery Scope to be
   defined by administrative identifiers, trust domains, distance,
   geographic or jurisdictional boundaries, and time.  A location-
   bounded scope can answer "what is near me", but a client has to
   reveal its location to use it.

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.

   +----------+------------+--------------+-------------+-------------+
   | Strategy | Vocabulary | Intent seen  | Fits        | Main limit  |
   |          | in advance | by others    | charter     |             |
   +==========+============+==============+=============+=============+
   | A Probe  | Full       | Inferable    | Yes         | Probe count |
   +----------+------------+--------------+-------------+-------------+
   | B Forward| None       | Yes          | No          | Privacy     |
   +----------+------------+--------------+-------------+-------------+
   | C Enumer-| Depends on | No           | Yes, if MDI | Scope size  |
   | ate      | MDI content|              | stays small |             |
   +----------+------------+--------------+-------------+-------------+
   | D Broker | Coarse     | Broker only  | Yes         | Broker trust|
   +----------+------------+--------------+-------------+-------------+
   | E Reverse| None       | Yes, public  | Unclear     | Privacy     |
   +----------+------------+--------------+-------------+-------------+

                                Table 1

   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 below.

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).

   +----------+------------------+-----------------+-----------------+
   | Strategy | Main bottleneck  | Who pays        | Cacheable       |
   +==========+==================+=================+=================+
   | A Probe  | Plans times      | Client; the     | Yes, exact      |
   |          | vocabulary size  | vocabulary      | match           |
   +----------+------------------+-----------------+-----------------+
   | B Forward| Matching over    | The matching    | No, intents     |
   |          | all offers       | service         | are unique      |
   +----------+------------------+-----------------+-----------------+
   | C Enumer-| Size of the      | Client; and     | Yes, same       |
   | ate      | scope and of MDI | publishers      | for all clients |
   +----------+------------------+-----------------+-----------------+
   | D Broker | Knowledge held   | Brokers         | Yes, for        |
   |          | by the broker    |                 | finding one     |
   +----------+------------------+-----------------+-----------------+
   | E Reverse| Needs times      | Providers and   | No, needs are   |
   |          | watching parties | notification    | short-lived     |
   +----------+------------------+-----------------+-----------------+

                                Table 2

   A:  The server side scales like DNS-SD: 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.

   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.

10.  Informative References

   [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.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-dawn-terminology-05, 19 October 2026.

   [I-D.iannone-dawn-privacy-considerations]
              Iannone, L. and A. Fressancourt, "Privacy Considerations
              for the Discovery of Agents, Workloads, and Named
              Entities (DAWN)", Work in Progress, Internet-Draft,
              draft-iannone-dawn-privacy-considerations-00,
              22 May 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.mozley-aidiscovery]
              Mozley, J., Williams, N., Sarikaya, B., and R. Schott,
              "AI Agent Discovery (AID) Problem Statement", Work in
              Progress, Internet-Draft, draft-mozley-aidiscovery-01,
              16 April 2026.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763,
              February 2013.

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

   Artur Hecker
   Huawei Technologies Duesseldorf GmbH
   Germany
   Email: [EMAIL TBD]