摘要

  • 10 月 28 日的个人 Internet-Draft 指出，只拿着任务目标的客户端，无法凭空选出能力查询词；可用能力又要靠发现流程才能知道。
  • 在 DAWN 现行章程内，草案认为可行的三条路是逐项探测、枚举小范围目录、先找粗粒度中介；每条路分别付出隐私、传输或信任成本。

“帮我完成这件事”是一句请求，不一定是目录认识的能力名。新发布的 DAWN 草案抓住了一个先后倒置：查询前要把目标拆成能力，可怎样拆又取决于附近有什么服务。发现系统若要求用户先写对菜单项，实际上把最难的一步留在门外。

DAWN 工作组章程把任务限定在局域网、机构或合作方之间的初始发现和最低限度公开信息；开放式搜索、语义匹配、排序和按意图选服务都不在范围内。需求草案第 02 版要求按功能发现特定实体或一类实体，从客户端已知的名称或范围开始，并在结果被截断时标明。它没有规定普通目标怎样变成可查询的功能标识。

新文档列出五种办法。逐项探测最像传统目录：客户端带着词表，挨个试可能的能力名。服务端可以做精确、可缓存的匹配；客户端承担词表和探测次数，连续查询还可能暴露它真正想做什么。把完整意图交给目录做语义匹配则省掉猜词，但目录直接看见目标，还跨过章程边界。

第三条路是枚举一个足够小的发现范围，客户端在本地读完所有最低可发现信息后自己匹配。目标不出本机，目录却要提供一份可理解的清单；信息写得太瘦，客户端仍得靠预先约定的词表，写得足够丰富，下载和解释的成本又上升。第四条路先找一类粗粒度中介，再在应用交互中把目标交给它。中介能帮忙规划，也掌握客户意图和服务入口。第五条路反过来公开需求，让服务商来找客户，范围内的人都能看见这张需求单。草案认为探测、小范围枚举和中介符合现有章程，反向发现的边界仍不清楚。

因此，“最低信息”要写多少不是排版问题。DAWN 需要决定哪些范围允许完整枚举、怎样限制抓取、截断结果如何表示。需求草案已要求说明枚举防护；新文档指出，若不允许枚举，只拿着目标的客户端又会被推回词表或中介。若默认走中介，谁维护它、谁决定它能看见哪些服务，便成了新的入口权力。

Datatracker 记录显示这仍是目标为 Informational、状态为 I-D Exists 的个人草案，没有提出协议，也没有提供查询量或部署测量。下一步可用一个只知道目标的客户端，在可枚举的小范围里测试自描述记录、截断和隐私行为。草案已把账单摊开，架构还得写明付款人。