| Internet-Draft | CADDP | October 2026 |
| Brockners, et al. | Expires 30 April 2027 | [Page] |
This document defines parameters for AI agents that would be used in DNS and mDNS discovery processes. It provides a set of common parameters for different DNS records to facilitate agents communicating over application layer protocols such as A2A or MCP.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://example.com/LATEST. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-blwm-dawn-common-discovery-parameters/.¶
Discussion of this document takes place on the DAWN Working Group mailing list (mailto:dawn@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/dawn/. Subscribe at https://www.ietf.org/mailman/listinfo/dawn/.¶
Source for this draft and an issue tracker can be found at https://github.com/USER/REPO.¶
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 30 April 2027.¶
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.¶
Several approaches to agent discovery use DNS, and this document is scoped to those approaches. Local discovery uses mDNS/DNS-SD to find agents advertised within a local network or discovery domain, while global discovery uses DNS names resolvable beyond that domain. Applications can combine these scopes, for example, by discovering a local available network service and globally accessible service to complete a task. These scenarios require consistent discovery parameters so that agents can interpret endpoint and descriptor information across both scopes. This document specifies a common set of parameters for DNS-based global discovery and mDNS/DNS-SD local discovery, supporting either scope and their combination while keeping discovery records concise.¶
A discovering agent needs to answer three questions from the DNS record alone, before subsequent discovery processes:¶
How do I connect? Protocol and transport.¶
What am I connecting to? A stable location I can cache and recognize later.¶
Is what I know still current? Has the descriptor changed?¶
This document defines a set of parameters that answers these. Everything else (capability taxonomy, business metadata, authorization details, etc.) comes from interaction beyond the initial discovery.¶
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.¶
Parameter keys are divided into two groups, those that carry baseline information for discovery Table 1, and those that are important in some cases as necessary to support discovery Table 2. The intent is to support discovery via DNS with the minimum information needed and not to overload DNS records with information that is provided by other communication layers and protocols.¶
Baseline discovery information:¶
| Key | TXT | SVCB | Description |
|---|---|---|---|
alpn
|
MAY | MUST | HTTP versions |
txtvers
|
MUST | N/A | Text record format version |
proto
|
SHOULD | SHOULD | Agent protocol |
Optional discovery information that is use case specific depending on the agent protocol and discovery process:¶
| Key | TXT | SVCB | Description |
|---|---|---|---|
desc-ref
|
SHOULD | SHOULD | Stable descriptor locator |
desc-ref-digest
|
SHOULD | SHOULD | Descriptor locator digest (see note 1) |
proto-ver
|
MAY | MAY | App protocol version |
path
|
MAY | MAY | Endpoint path |
well-known
|
MAY | MAY | .well-known suffix |
title
|
MAY | MAY | Display name |
Notes:¶
When the endpoint has a descriptor reference, at the protocol's default location or named by well-known.¶
Key definitions presented in the same order as Table 1 and Table 2.¶
The application-layer protocols the endpoint supports for connection setup, identified by ALPN protocol identifiers ([RFC7301]), for example h2 and h3 for HTTP, with [RFC9460] semantics. It never carries the agent protocol, which is carried by proto.¶
For SVCB records, the alpn SvcParamKey is defined in [RFC9460], Section 7.1.¶
For TXT records, the value is a comma-separated list of ALPN protocol identifiers in order of preference, for example alpn=h2,h3.¶
Version number for the DNS text record format.¶
Not applicable. txtvers has no SvcParamKey registration and MUST NOT appear in an SVCB record.¶
Not applicable, for the same reason as above.¶
The value is a decimal integer in US-ASCII digits, with no sign and no leading zeros other than the single digit "0" itself, following the version-tag convention of [RFC6763], Section 6.7:¶
txtvers-value = "0" / (%x31-39 *DIGIT)¶
txtvers MUST be the first key/value pair in the TXT record ([RFC6763], Section 6.7), so that a client can determine how to interpret the rest of the record before parsing it. This document starts numbering at txtvers=1; a change to the meaning of an existing key would increment the value, while adding a new key that older clients can safely ignore does not require a new one.¶
Examples¶
This key has no SVCB representation; only the TXT record string is shown.¶
The TXT record string is txtvers=1.¶
The single agent protocol offered by this DNS-SD instance or SVCB record, e.g. a2a or mcp. An endpoint that offers several protocols is advertised once per protocol (i.e. one protocol per record in a DNS RRset), and a DNS-SD subtype (_a2a._sub), when used, names the same protocol.¶
The proto SvcParamKey is single-valued, not a list. Agent protocols run over a transport identified nu the alpn so they are not themselves entries in the IANA Service Name and Transport Protocol Port Number Registry [RFC6335] and a proto value is not required to be registered in, or validated against, that registry. Each decoded value MUST match this ABNF [RFC5234]:¶
proto-value = ALPHA *( ALPHA / DIGIT / "-" )¶
The wire-format SvcParamValue is the US-ASCII octets of the protocol identifier. Because the value holds a single item, it contains no internal length field, and its extent is given by the SvcParamValue length field of the enclosing SvcParam ([RFC9460], Section 2.2). A zero-length value is malformed.¶
proto=proto-value¶
The value is the protocol identifier in US-ASCII.¶
In a TXT record the string is "proto=" followed by the value, with no further escaping.¶
A descriptor reference for the agent being discovered. Different standards and specifications my use descriptors of different formats, such as an [ARDSpecification] URN or an [I-D.draft-narajala-courtney-ansv2] ANSName. This is not any form of universal agent identifier, rather it is used to facilitate discovery by specific implementations. It is not authenticated, so it provides information on locating or using the agent without proving who runs it.¶
For a discovering entity to properly interact with an agent it needs to discover where the agent instance is and a descriptor of the agent to be used in subsequent stages of discovery. In some standards, the descriptor might be hosted at the same location as the agent instance in a fixed location specified as part of that standard, in which case no extra info may be needed. In other standards the descriptor may be hosted somewhere else, or the location of the descriptor might vary, then two references are needed - one to the location of the agent instance (that is the domain name) and one to the location of the descriptor.¶
The format is not constrained. Examples could include:
- ARD URN: urn:air:agent-name.example.com:travel:bookings
- ANS ANSName: "ans://v1.5.0.support.example.com"¶
This document places no constraint on its contents beyond excluding the NUL octet; a descriptor reference's own format (e.g. a URN, or URI) is defined by the standard that specifies it, not by this document.¶
The wire-format SvcParamValue is the UTF-8 octets of the reference to the descriptor. Because the value holds a single item, it contains no internal length field, and its extent is given by the SvcParamValue length field of the enclosing SvcParam ([RFC9460], Section 2.2). A zero-length value is malformed.¶
desc-ref="locator-value"¶
The value is a single character-string, using the escaping rules of [RFC9460], Section 2.1 and [RFC9460], Appendix A.1. It is not a list, so "," is an ordinary character within the locator value.¶
In a TXT record the string is "desc-ref=" followed by the value, with no further escaping.¶
An algorithm-prefixed digest of the descriptor reference, used as a freshness signal. This consists of a value from the Named Information Hash Algorithm Registry [HashFunctionRegistry], colon, and hash value (e.g. sha-256:<base64url>). A client whose cached descriptor matches MAY assume the descriptor has not changed; a mismatch means the descriptor changed, not that the endpoint is hostile.¶
A change in the digest is not a security signal. It means the descriptor reference changed and indicates this to a discovering entity, which MAY use this as a signal to take decisions regarding connecting to the end point.¶
If the digest doesn't match what's cached, the discovering agent SHOULD perform actions such as:¶
Re-fetch information from the descriptor and/or other parameters such well-known, or¶
Query an organizational index such as _index._agents.<domain> from [I-D.draft-mozleywilliams-dnsop-dnsaid] or _agent._tcp.local. from [I-D.draft-jakab-dawn-agent-discovery-mdns] to see if the agent record has changed, or¶
Escalate to the application layer if it needs to decide whether the prior desc-ref descriptor is still valid, such as the descriptor altering because of a version change¶
The desc-ref-digest SvcParamKey is single-valued: its SvcParamValue is one digest, not a list. Each decoded value MUST match this ABNF [RFC5234]:¶
digest-value = hash-alg ":" base64url-value hash-alg = 1*(ALPHA / DIGIT / "-") base64url-value = 1*(ALPHA / DIGIT / "-" / "_" / "=")¶
hash-alg is a name from the Named Information Hash Algorithm Registry [HashFunctionRegistry] (e.g. sha-256); base64url-value is the digest encoded per [RFC4648], Section 5, with padding included if the registry entry's output length requires it. A value whose hash-alg is not a registered name, or whose base64url-value does not decode to the length that algorithm produces, does not have the expected format, so the RR is malformed ([RFC9460], Section 2.2). In a TXT record, a client ignores a desc-ref-digest that fails this check.¶
The wire-format SvcParamValue is the UTF-8 octets of the digest value (hash algorithm name, ":", Base64url digest). Because the value holds a single item, it contains no internal length field, and its extent is given by the SvcParamValue length field of the enclosing SvcParam ([RFC9460], Section 2.2). A zero-length value is malformed.¶
desc-ref-digest="hash-alg:base64url-value"¶
The value is a single character-string, using the escaping rules of [RFC9460], Section 2.1 and [RFC9460], Appendix A.1. The ":" separating hash-alg from base64url-value is an ordinary character and needs no escaping.¶
In a TXT record the string is "desc-ref-digest=" followed by the value, with no further escaping.¶
The version of proto the endpoint supports, in that protocol's own syntax (A2A 1.0, MCP 2025-11-25). It is a selection hint only; the protocol's own negotiation settles compatibility.¶
The proto-ver SvcParamKey is single-valued: its SvcParamValue is one version identifier, not a list. The value is an opaque character-string in the syntax that protocol's own specification defines for its version identifiers; this document does not otherwise constrain its contents beyond excluding the NUL octet.¶
The wire-format SvcParamValue is the UTF-8 octets of the version identifier. Because the value holds a single item, it contains no internal length field, and its extent is given by the SvcParamValue length field of the enclosing SvcParam ([RFC9460], Section 2.2). A zero-length value is malformed.¶
proto-ver="version-identifier"¶
The value is a single character-string, using the escaping rules of [RFC9460], Section 2.1 and [RFC9460], Appendix A.1. It is not a list, so "," is an ordinary character within the version identifier.¶
In a TXT record the string is "proto-ver=" followed by the value, with no further escaping¶
The HTTP path of the protocol endpoint (e.g. /mcp), as _http._tcp carries it ([RFC6763], Section 13.3). Needed when the endpoint does not supply a description, such as with MCP version 2026-07-28. A client builds the URL from the SRV or SVCB target and port plus this path; host and port never appear in the TXT record ([RFC6763], Section 6.3).¶
The path SvcParamKey is single-valued: its SvcParamValue is one path, not a list. The value is the path component only. The scheme and authority come from the SVCB or SRV target and port, and a query or fragment is not permitted. Each decoded value MUST match this ABNF [RFC5234]:¶
path-value = "/" [ segment-nz *( "/" segment ) ]¶
The segment-nz and segment rules are from [RFC3986], Section 3.3. Non-ASCII characters MUST be percent-encoded. Invalid percent escapes and segments equal to "." or "..", including their percent-encoded forms, MUST be rejected. Other percent-encoded octets and any trailing "/" MUST be preserved without decoding or normalisation. A value that fails these checks does not have the expected format, so the RR is malformed ([RFC9460], Section 2.2). In a TXT record, a client ignores a path that fails these checks.¶
The wire-format SvcParamValue is the octets of the path. Because the value holds a single item, it contains no internal length field, and its extent is given by the SvcParamValue length field of the enclosing SvcParam ([RFC9460], Section 2.2). A zero-length value is malformed.¶
path="absolute-path"¶
The value is a single character-string, using the escaping rules of [RFC9460], Section 2.1 and [RFC9460], Appendix A.1. It is not a list, so "," is an ordinary character within the path.¶
In a TXT record the string is "path=" followed by the same value, with no further escaping. Each string in a TXT record holds at most 255 octets ([RFC6763], Section 6.1), so the path is limited to 250 octets. All of an instance's key/value strings share one TXT record, which DNS-SD recommends keeping to 200 octets or less, and under 400 octets to fit in a single 512-byte DNS message ([RFC6763], Section 6.2); in practice a path is therefore much shorter than 250 octets.¶
The descriptor's suffix under /.well-known/ (e.g. agent-card.json), as [I-D.draft-mk-dnsop-svcb-well-known] defines it for SVCB records. Omitted when the descriptor is at the protocol's default location.¶
A human-readable name for the endpoint, for display only, such as the name a client shows in a list of discovered agents. The value typically comes from the descriptor, for example the A2A Agent Card name or the MCP title. In DNS-SD the service instance name normally serves this purpose, so title is useful mainly when the two differ: after an mDNS name conflict renamed the instance, or when the descriptor's name cannot be an instance name ([RFC6763], Section 4.1.1). In unicast DNS, owner names are host names, so title is the only display name available before the descriptor is fetched.¶
The value is not authenticated. A client displays it as an unverified name and does not use it to identify or correlate agents. (see Section 5).¶
The title SvcParamKey is single-valued. The value is UTF-8 text in Unicode Normalization Form C, with no control characters. Each decoded value MUST match this ABNF [RFC5234]:¶
title-value = 1*( %x20-7E / UTF8-2 / UTF8-3 / UTF8-4 )¶
The UTF8-2, UTF8-3, and UTF8-4 rules are from [RFC3629], Section 4; the C1 control characters U+0080 to U+009F are not allowed. A value that fails these checks makes the RR malformed ([RFC9460], Section 2.2). In a TXT record, a client ignores a title that fails these checks.¶
The wire-format SvcParamValue is the UTF-8 octets of the value, and its extent is given by the SvcParamValue length field of the enclosing SvcParam ([RFC9460], Section 2.2). A zero-length value is malformed.¶
title="display name"¶
The value is a single character-string, using the escaping rules of [RFC9460], Section 2.1 and the character-string grammar of [RFC9460], Appendix A, which allows only visible ASCII unescaped: non-ASCII octets are written as \DDD escapes. It is not a list, so "," is an ordinary character within the title.¶
In a TXT record the string is "title=" followed by the UTF-8 octets of the value, with no further escaping. Each string in a TXT record holds at most 255 octets ([RFC6763], Section 6.1), so the title is limited to 249 octets. All of an instance's key/value strings share one TXT record, which DNS-SD recommends keeping to 200 octets or less ([RFC6763], Section 6.2), so a title is best kept short.¶
Figure 1 shows title="Travel Bookings" in an SVCB record, and the corresponding TXT record string title=Travel Bookings. A title with non-ASCII characters, such as "Café Orders", is title="Caf\195\169 Orders" in SVCB presentation format, while the TXT string carries the UTF-8 octets directly.¶
An index of AI resources may be published using a well known DNS label within an organizational domain to indicate the presence of a catalog or agent registry.¶
_index._agents.<domain> (unicast) or the browse-domain PTR target (DNS-SD) SHOULD carry:¶
Same key names in both. SVCB uses numeric codes (private-use until IANA assigns); TXT uses the string names directly. Sharing names means a client doesn't need two vocabularies.¶
Until IANA assigns codes, mandatory=proto won't work reliably across implementations because the numeric value may differ. TXT at the same owner name is the interoperability fallback.¶
Examples of records can be seen in Figure 1 and Figure 2:¶
Individual agent - unicast:¶
Individual agent - DNS-SD/mDNS, one instance per protocol (PTR to browse, SRV for host/port, TXT primary):¶
One instance per protocol rather than proto=a2a,mcp in one TXT. Browse _agents._tcp for every agent, or the _a2a._sub / _mcp._sub subtype for one protocol. IF both instances carry the same desc-ref, a client that sees both can infer they are one agent. The MCP instance has no well-known or location-digest yet, because MCP has no settled location descriptor (Server Cards, SEP-2127, still open). It carries path=/mcp instead: MCP requires a single endpoint path but defines no default, so without path a client could not reach the server. The A2A instance needs no path, because its endpoint URL comes from the Agent Card.¶
This section lists questions on which the authors seek input. It will be removed before publication.¶
The title key carries a display name chosen by whoever publishes the record. It is not authenticated, so an advertiser can use a title that imitates another agent or a trusted organization, such as "Official Stadium Taxi". Clients present it as an unverified name, do not use it to identify or authorize an agent, and rely on subsequent processes for those purposes. A client that shows titles to users also needs to consider visually confusable characters.¶
This section will be revised based on consensus of the parameter keys and value.¶
This appendix illustrates how a user's personal agent can use local-network and global discovery, separately and together, during a stadium visit. The examples show how the discovery parameters described in this document apply to these scenarios.¶
When the user enters the stadium, the user's personal agent can browse the venue's local DNS-SD domain to discover agent services advertised on the stadium network. The available services may vary with the user's location and the services enabled for the event.¶
These services provide information and capabilities relevant to the stadium visit. For example, a live-statistics service could provide statistics and updates through MCP or A2A. A replay service could provide access to venue media through MCP, with the media delivered using MOQ. If the replay service is accessible only through the stadium's Wi-Fi network, the user's device must connect to that network to use it.¶
During the game, the user might ask, "Have two burgers and two soft drinks delivered to seat 34B." The personal agent could use a local food-ordering service offered by the stadium or consider a global food-ordering service.¶
A local service could support ordering from stadium vendors and delivery to the user's seat. Global providers could complement these vendors by arranging a meal for pickup outside the venue or delivery to the user's home after the event. The personal agent must account for venue access and delivery restrictions: discovering a global food-delivery service does not imply that the service can deliver to a stadium seat.¶
The selected food-ordering agent would maintain order state and coordinate payment and delivery. The personal agent could also combine information from local and global services, such as using venue-specific pickup instructions when arranging an order through a global provider.¶
After the game, the user might ask, "Get me home as quickly as possible." The personal agent could consider both local and global transportation services.¶
The stadium could offer a local transportation service that provides access to a preferred set of ride-share and taxi companies selected by the venue. Booking through this service could provide negotiated rates or discounts unavailable through direct bookings. The service could obtain offers from participating companies and help arrange pickup at a designated meeting point.¶
Global transportation services could provide additional options, including ride-share services, taxis, buses, and metro connections. The personal agent could combine these options with local information from the stadium, such as guidance to the most appropriate exit or pickup location. Local services would therefore complement global services even when the transportation itself is arranged through a global provider.¶
The stadium's transportation service could expose both A2A and MCP endpoints. Following the one-instance-per-protocol approach in Figure 2, it would advertise a separate DNS-SD instance for each protocol. Both instances would carry the same desc-ref value, allowing the personal agent to correlate them as protocol endpoints of the same logical service. The A2A endpoint could support goal-oriented interaction, while the MCP endpoint could provide access to tools or resources. The personal agent could select the protocol appropriate to the task and its own capabilities.¶
These scenarios illustrate two complementary discovery scopes. Local DNS-SD discovery identifies services advertised within the venue's local discovery domain, while global DNS discovery identifies services through globally resolvable names. The personal agent can use services discovered through either scope or combine them to fulfill the user's request.¶
Each endpoint's application protocol is conveyed using proto. When the same logical service supports both A2A and MCP, it is advertised through separate protocol instances that can be correlated using desc-ref.¶
This appendix records alternatives that were considered while designing the parameters in this document but were not adopted, with the reasons for each. All of them are plausible, and several appear in earlier versions of related drafts. The entries show which trade-offs have already been weighed, and what new information would justify revisiting a decision. They run from the most general question, what DNS should carry at all, to the most specific, key syntax.¶
A2A and MCP both run over HTTP, so DNS could limit itself to locating an HTTP server, as HTTPS records [RFC9460] already do, and leave the agent layer to bootstrap itself from .well-known resources. Each layer would then carry only what is needed to bootstrap the next one. That is sufficient when a client already knows which endpoint it wants.¶
It is not sufficient for discovery. Browsing _agents._tcp on a busy local network can return many instances, and without a hint in the advertisement a client has to complete a TLS handshake and an application-layer exchange with every candidate just to discard most of them. The parameters in Section 3 are therefore limited to what a client needs to choose an endpoint before connecting: the agent protocol and HTTP versions, where to find the endpoint or its descriptor, which logical agent the endpoint belongs to, and whether a cached descriptor is still current. Everything else is left to the descriptor and the agent protocol.¶
The saving is largest for local discovery. In global discovery a client often starts from a single known name, and the parameters mainly provide the freshness check of desc-ref-digest and a vocabulary shared with local discovery.¶
Relying on HTTP alone would also tie agent discovery to HTTP. A2A and MCP run over HTTP today, but future agent protocols might not, and this document is not meant to exclude them. Because proto identifies the agent protocol independently of HTTP, a client can select such a protocol in the same way, and keys that apply only to HTTP, such as path and well-known, are omitted for it.¶
A new RR type for agent discovery could carry structured data without the constraints of TXT key/value strings. Before any deployment could use it, however, authoritative servers, provisioning systems, DNS hosting interfaces, and mDNS implementations would all need to support it. The record types that DNS-SD already uses (PTR, SRV, and TXT [RFC6763]) and SVCB [RFC9460] are deployed today and can hold the small set of parameters in Section 3. This document therefore defines conventions for existing record types and introduces no new ones.¶
Advertising what an agent can do, for example caps=bookings,refunds, would let a client filter candidates by function. There is no shared vocabulary for such values, and examples tend to mix protocol features, such as MCP tools, resources, and prompts, with business categories, which serve different purposes. Capabilities also change more often than DNS records should: the tools an MCP server offers are listed at run time through the protocol itself and can change during a session. Long capability lists also strain the size limits of TXT records ([RFC6763], Section 6.2). Capabilities are therefore left to the descriptor and to the agent protocol. If coarse categories are needed in the future, DNS-SD subtypes ([RFC6763], Section 7.1) can filter at query time, which a TXT key cannot: a client has to receive and parse every TXT record before it can apply a key-based filter.¶
The agent protocol could be carried in the alpn SvcParam, as in alpn=h2,mcp. ALPN identifiers [RFC7301] name the protocol that runs directly over TLS, and the alpn SvcParam lists alternatives a client can choose from, not the layers of a protocol stack ([RFC9460], Section 7.1). A value of alpn=h2,mcp therefore advertises either HTTP/2 or a protocol named mcp running directly over TLS, whereas A2A and MCP both run over HTTP. In this document, alpn carries only the HTTP versions an endpoint supports, and the agent protocol is carried in proto (Section 3.2).¶
A DNS-SD service type identifies "what the service does and what application protocol it uses to do it" ([RFC6763], Section 7), which suggests one service type per agent protocol, such as _a2a._tcp and _mcp._tcp. This raises several problems:¶
Every service type needs its own entry in the Service Name registry [RFC6335]. The name mcp is already registered for an unrelated protocol, so MCP would need a different name, such as mcp-ai, which would then differ from the protocol's own name.¶
No single service type would cover all agents. An agent using a new protocol could not be discovered until its service type was registered and clients were updated to browse for it.¶
mDNS gateways and proxies that forward selected service types would need to be reconfigured for every new protocol, whereas a single service type needs to be permitted only once.¶
Instance names are unique only within a service type, so two unrelated agents could advertise the same name under _a2a._tcp and _mcp-ai._tcp, and a client merging the two lists would take them for one agent. DNS-SD resolves this with a "flagship" service type that reserves the name across all related types ([RFC6763], Section 8), which amounts to a generic service type after all.¶
This document uses one generic service type, _agents._tcp, which needs a single registration, and DNS-SD subtypes such as _a2a._sub._agents._tcp for protocol-specific browsing ([RFC6763], Section 7.1). The subtype namespace is separate for each service type, so _mcp is available as a subtype of _agents._tcp even though mcp is a registered Service Name. Encoding the protocol as an extra label in front of the instance name, as in _mcp.agent-name._agents._tcp, does not work either: the instance portion of a Service Instance Name is a single DNS label ([RFC6763], Section 4.1.1), and subtypes provide the selection such a label was meant to provide.¶
A service instance that offers two protocols could carry a separate TXT record for each, one containing proto=a2a and its keys, and the other proto=mcp and its keys. DNS-SD allows multiple TXT records only when each describes "a different variant of the same logical service, offered using the same underlying protocol on the same port", and advises future protocol designs not to follow the example of the only service type that uses them ([RFC6763], Section 6.8). Multiple records also cannot reduce traffic, since a responder that sends any member of the TXT RRset "MUST send the entire RRSet" ([RFC6762], Section 10.2).¶
Implementations also disagree. Apple's mDNSResponder publishes multiple TXT records and returns all of them; Avahi refuses to publish a second record and keeps only the first when resolving; python-zeroconf keeps only the last. The same advertisement can therefore present a different protocol to each client, and none of these implementations reports the discrepancy. This document uses exactly one TXT record per service instance.¶
A single instance could list all the protocols it offers, as in proto=a2a,mcp, with protocol-specific keys distinguished by a prefix, such as a2a-card and mcp-path. This is compact, but the protocols then share one host and port, every protocol-specific key needs a prefix, and a client interested in one protocol still receives and parses the keys of the others. A change to one protocol, such as a new version or its withdrawal, also changes the record that clients of the other protocols have cached. This document advertises one instance per protocol instead (Figure 2), and instances of the same logical agent carry the same desc-ref, so a client that sees several of them can tell they belong together. The unit of multiplicity is the instance, not the record or the key.¶
Keys with parallel lists, such as proto=mcp,a2a ver=1,2, associate values by position. The association is fragile, because a missing or extra item silently shifts every value after it, and it cannot express two versions of the same protocol. Repeating a key does not provide a hierarchy either, since a DNS-SD client ignores all but the first occurrence of a key in a TXT record ([RFC6763], Section 6.4). With one protocol per instance (Appendix B.7), each key has a single meaning and no values need to be associated across keys.¶
A single ver key would conflate three different versions: of the TXT record format, which txtvers carries ([RFC6763], Section 6.7); of the agent protocol, which proto-ver carries; and of the agent's implementation. The implementation version is left to the descriptor, so that a software upgrade does not require a change to DNS.¶
Leaving protocol versions out of DNS would keep records smaller, but a client that supports only some versions of a protocol would have to contact every candidate to find out which ones it can use. The proto-ver key is therefore an optional selection hint (Table 2), and the agent protocol's own negotiation still determines compatibility.¶
A TXT key could carry the complete URL of an endpoint or descriptor, as in cardUrl=https://agent.example.com/.well-known/agent-card.json. This duplicates the host and port that the SRV record already carries, which DNS-SD prohibits ([RFC6763], Section 6.3), and URLs are among the longest values a TXT record would hold. This document carries only the path (path) or the .well-known suffix (well-known), and a client builds the URL from the target and port of the SRV or SVCB record, the way the _http._tcp service carries path ([RFC6763], Section 13.3). Carrying only a path also leaves a single source for the host a client connects to: any policy the client applies to the SRV or SVCB target, such as permitted hosts or address ranges, also covers the URL it builds, and a value that is not a path, such as a complete URL, is ignored (Section 3.2).¶
TXT keys could follow their own conventions, such as camelCase names like cardUrl and a2aProtoVer, with different names for the same parameters in SVCB. SvcParamKey names are limited to lowercase letters, digits, and hyphens, with at most 63 characters ([RFC9460], Section 2.1), while TXT keys are case-insensitive and are recommended to be no more than nine characters long ([RFC6763], Section 6.4). Names that satisfy both rules can be used unchanged in both encodings, so a client needs only one vocabulary, and a parameter means the same thing in local and global discovery. The one key longer than nine characters, well-known, keeps the name used for the corresponding SVCB parameter.¶
desc-ref was chosen after discussion on several possible names including cap (for capability) and locator (to locate agent description or capability). Naming it as a description reference was chosen as it is generic and allows the parameter to support different protocols and specifications without the name referring to a single property of a description.¶
Agent protocols may use .well-known URI suffixes and hence in some cases this does not need to be specified. However, more than one well-known suffix might be used and offered as alternatives during discovery (with a preference order) to discovering entities, or this may be used in conjunction with an agent descriptor that is not a well-known suffix and contained in the Section 3.2.4 parameter. Having both desc-ref and well-known allows for these use cases and flexibility in supporting multiple agent protocols.¶
The authors would like to thank Ben Schwartz and Scott Courtney for their feedback and discussion.¶