Summary

  • A new individual Internet-Draft says an intent-only client cannot choose a capability query without some knowledge of available services; learning the services is what discovery was meant to do.
  • Inside DAWN's current charter, the paper leaves three practical routes: probe named capabilities, enumerate a small scope, or find a coarse broker. Each spends privacy, bandwidth or trust in a different place.

“Find me someone who can do this” sounds like a discovery request. It is a goal, not necessarily a service name. The 28 October DAWN paper puts that difference at the front door. To ask for a capability, the client must already have a candidate capability in mind. To know which capability would help, it needs to see what is available. The lookup cannot manufacture its own question.

The DAWN charter draws a narrow line around initial discovery: minimum public information in a local network, an organization or between cooperating parties. Open-ended search, semantic matchmaking, ranking and selection by intent sit outside the assignment. The requirements draft asks for discovery by function and starts from a name or scope known to the client. It asks results to say when a scope search was truncated. It never supplies the step that turns a plain-language goal into a function identifier.

The new paper lays out five ways to pay for that missing step. First, probe a known vocabulary: try candidate capability names until something answers. The server gets exact, cacheable matches, while the client carries the dictionary and exposes its interest through the sequence of probes. Second, send the whole intent to a catalog and let it match the request to an offer. That breaks the circle, but the catalog sees the goal and performs semantic matching the charter excludes.

Third, enumerate a small discovery scope and interpret the offers locally. The client's goal stays on its own machine. The catalog and client now pay for a full list, and the minimum discoverable information must explain enough to be understood without a shared vocabulary. Fourth, find a coarse broker first, then give it the goal in an application exchange. The broker can assemble the plan; it also becomes a trust and privacy choke point. Fifth, publish the need so providers can find the client. That puts the goal in front of everyone allowed in the discovery scope.

The paper says probing, small-scope enumeration and brokerage fit the charter as written. Whether publishing the need for providers to find the client fits that initial-discovery mandate remains unclear.

Imagine a client starting with an ordinary goal and no service label. It can send three guesses to the directory, download a small shelf of offers, or tell a broker what it wants. Each route produces a different witness to that goal. This makes “minimum” a live governance decision. Too little description in each discoverable record and the local shelf is useless. Enough description to support local interpretation makes enumeration heavier and raises the scraping question. The requirements already ask specifications to say whether they resist enumeration; the new paper asks which scopes permit it and how a client handles a truncated list.

If a broker is the answer, the system must say who can offer that role and what it learns.

The Datatracker entry lists an individual Informational draft at I-D Exists. It proposes no protocol and gives qualitative costs, not a measured deployment. A bounded-scope test with interpretable records, explicit truncation and query-privacy behavior would show whether clients can discover without handing their goal to a planner. The draft has identified the bill; DAWN's architecture still has to decide who pays it.