# drafts

name: draft-mozleywilliams-dnsop-bandaid
rev: 00
title: Brokered Agent Network for DNS AI Discovery
time: 2025-10-16T08:56:23Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-19T08:56:23Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: ["Agent discovery/reg", "A2A protocols", "Agent identity/auth"]
tags: []
fetched_at: 2026-02-27T22:56:05.127691+00:00
abstract:
The emerging field of agent-to-agent protocol standards introduces
   new requirements in order to facilitate discovery, trust signaling,
   session negotiation and communication.  This document specifies a
   method for utilizing the Domain Name System (DNS) to facilitate
   scalable and interoperable discovery between AI agents.  The proposed
   mechanism, referred to as _Brokered Agent Network for DNS AI
   Discovery_ (BANDAID), defines a structured DNS namespace and record
   usage model to support metadata exchange and capability
   advertisement.

   BANDAID introduces a leaf zone convention (e.g., _agents.example.com)
   containing Service Binding (SVCB) records (e.g.,
   chat._agents.example.com) that encode application-specific metadata.
   These records enable agents to retrieve operational parameters prior
   to initiating a session, supporting both targeted lookups and
   capability-based discovery.  The approach leverages existing DNS
   infrastructure, including DNS Service Discovery (DNS-SD), DNSSEC, and
   DANE, to provide integrity, authenticity, and automation without
   requiring human intervention.  Lastly, the draft for Domain Control
   Validation (DCV) proposes a best current practice to prove an agent
   is authorized to act on behalf of a domain.

   _This document proposes no change to the structure of DNS messages,
   and no new operation codes, response codes, resource record types, or
   any other new DNS protocol values._

full_text:
dnsop                                                          J. Mozley
Internet-Draft                                               N. Williams
Intended status: Standards Track                          Infoblox, Inc.
Expires: 19 April 2026                                       B. Sarikaya
                                                            Unaffiliated
                                                               R. Schott
                                                        Deutsche Telecom
                                                         16 October 2025


              Brokered Agent Network for DNS AI Discovery
                 draft-mozleywilliams-dnsop-bandaid-00

Abstract

   The emerging field of agent-to-agent protocol standards introduces
   new requirements in order to facilitate discovery, trust signaling,
   session negotiation and communication.  This document specifies a
   method for utilizing the Domain Name System (DNS) to facilitate
   scalable and interoperable discovery between AI agents.  The proposed
   mechanism, referred to as _Brokered Agent Network for DNS AI
   Discovery_ (BANDAID), defines a structured DNS namespace and record
   usage model to support metadata exchange and capability
   advertisement.

   BANDAID introduces a leaf zone convention (e.g., _agents.example.com)
   containing Service Binding (SVCB) records (e.g.,
   chat._agents.example.com) that encode application-specific metadata.
   These records enable agents to retrieve operational parameters prior
   to initiating a session, supporting both targeted lookups and
   capability-based discovery.  The approach leverages existing DNS
   infrastructure, including DNS Service Discovery (DNS-SD), DNSSEC, and
   DANE, to provide integrity, authenticity, and automation without
   requiring human intervention.  Lastly, the draft for Domain Control
   Validation (DCV) proposes a best current practice to prove an agent
   is authorized to act on behalf of a domain.

   _This document proposes no change to the structure of DNS messages,
   and no new operation codes, response codes, resource record types, or
   any other new DNS protocol values._

About This Document

   This note is to be removed before publishing as an RFC.







Mozley, et al.            Expires 19 April 2026                 [Page 1]

Internet-Draft                   BANDAID                    October 2025


   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-mozleywilliams-
   dnsop-bandaid/.

   Discussion of this document takes place on the WG Working Group
   mailing list (mailto:WG@example.com), which is archived at
   https://example.com/WG.

   Source for this draft and an issue tracker can be found at
   https://github.com/USER/REPO.

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 19 April 2026.

Copyright Notice

   Copyright (c) 2025 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.  Conventions and Definitions . . . . . . . . . . . . . . . . .   4
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   4




Mozley, et al.            Expires 19 April 2026                 [Page 2]

Internet-Draft                   BANDAID                    October 2025


     2.1.  Challenges with Existing Proposed Mechanisms and Benefits
           of DNS  . . . . . . . . . . . . . . . . . . . . . . . . .   5
       2.1.1.  Development . . . . . . . . . . . . . . . . . . . . .   6
       2.1.2.  Opportunity Cost  . . . . . . . . . . . . . . . . . .   6
       2.1.3.  Governance  . . . . . . . . . . . . . . . . . . . . .   7
       2.1.4.  Sovereignty . . . . . . . . . . . . . . . . . . . . .   8
       2.1.5.  Commerce  . . . . . . . . . . . . . . . . . . . . . .   8
       2.1.6.  Application . . . . . . . . . . . . . . . . . . . . .   9
       2.1.7.  Granularity . . . . . . . . . . . . . . . . . . . . .   9
       2.1.8.  Performance . . . . . . . . . . . . . . . . . . . . .  10
       2.1.9.  Lifecycle / Management  . . . . . . . . . . . . . . .  10
       2.1.10. Trust . . . . . . . . . . . . . . . . . . . . . . . .  11
       2.1.11. Agent Properties  . . . . . . . . . . . . . . . . . .  11
       2.1.12. Control . . . . . . . . . . . . . . . . . . . . . . .  12
     2.2.  Mechanisms for Successful Agent Communication . . . . . .  13
       2.2.1.  Service Binding Records, aka SVCB . . . . . . . . . .  13
       2.2.2.  DNS Security Extensions, aka DNSSEC . . . . . . . . .  14
       2.2.3.  DNS Service Discovery, aka DNS-SD . . . . . . . . . .  15
       2.2.4.  DNS-Based Authentication of Named Entities, aka
               DANE  . . . . . . . . . . . . . . . . . . . . . . . .  15
       2.2.5.  Domain Control Validation, aka DCV  . . . . . . . . .  16
       2.2.6.  Service Resilience  . . . . . . . . . . . . . . . . .  17
       2.2.7.  Observability, Auditability . . . . . . . . . . . . .  17
       2.2.8.  Interoperability  . . . . . . . . . . . . . . . . . .  18
       2.2.9.  Multitenancy, Federation  . . . . . . . . . . . . . .  18
     2.3.  Architecture  . . . . . . . . . . . . . . . . . . . . . .  18
       2.3.1.  Example Communication . . . . . . . . . . . . . . . .  18
       2.3.2.  Example Record  . . . . . . . . . . . . . . . . . . .  18
       2.3.3.  Example Use Cases . . . . . . . . . . . . . . . . . .  19
   3.  BANDAID Overview  . . . . . . . . . . . . . . . . . . . . . .  20
     3.1.  Zone and Other Requirements . . . . . . . . . . . . . . .  20
       3.1.1.  Delegation and Chain of Trust . . . . . . . . . . . .  20
       3.1.2.  Algorithms and Parameters . . . . . . . . . . . . . .  21
       3.1.3.  Authenticated Denial of Existence . . . . . . . . . .  21
       3.1.4.  Signature Validity  . . . . . . . . . . . . . . . . .  21
       3.1.5.  Key Rollover  . . . . . . . . . . . . . . . . . . . .  21
       3.1.6.  Transport and Message Size  . . . . . . . . . . . . .  22
       3.1.7.  Transfer and Integrity  . . . . . . . . . . . . . . .  22
       3.1.8.  Monitoring  . . . . . . . . . . . . . . . . . . . . .  22
       3.1.9.  Abuse Resistance  . . . . . . . . . . . . . . . . . .  22
       3.1.10. BANDAID Records . . . . . . . . . . . . . . . . . . .  22
       3.1.11. Performance Optimization(s) . . . . . . . . . . . . .  23
       3.1.12. Customization(s)  . . . . . . . . . . . . . . . . . .  24
   4.  Implementation Guidance . . . . . . . . . . . . . . . . . . .  25
     4.1.  AI Operators  . . . . . . . . . . . . . . . . . . . . . .  25
       4.1.1.  Separation of Roles . . . . . . . . . . . . . . . . .  25
       4.1.2.  Local Root Zone Copy  . . . . . . . . . . . . . . . .  25
       4.1.3.  Aggressive Caching and Prefetch . . . . . . . . . . .  25



Mozley, et al.            Expires 19 April 2026                 [Page 3]

Internet-Draft                   BANDAID                    October 2025


       4.1.4.  EDNS(0) Transport Resilience  . . . . . . . . . . . .  26
       4.1.5.  Load Distribution . . . . . . . . . . . . . . . . . .  26
       4.1.6.  Monitoring and Telemetry  . . . . . . . . . . . . . .  26
       4.1.7.  Encrypted Resolver Steering (Informative) . . . . . .  27
     4.2.  AI Consumers  . . . . . . . . . . . . . . . . . . . . . .  27
       4.2.1.  DNS-Based Service Discovery . . . . . . . . . . . . .  27
       4.2.2.  Communication Failure / Retry . . . . . . . . . . . .  27
       4.2.3.  Domain Control Validation . . . . . . . . . . . . . .  28
     4.3.  AI Developers . . . . . . . . . . . . . . . . . . . . . .  28
       4.3.1.  Publishing Schema . . . . . . . . . . . . . . . . . .  28
       4.3.2.  TTLs, Update Agility  . . . . . . . . . . . . . . . .  28
       4.3.3.  Capability Retrieval  . . . . . . . . . . . . . . . .  29
       4.3.4.  Example DCV Flow  . . . . . . . . . . . . . . . . . .  29
       4.3.5.  Example Zonefile  . . . . . . . . . . . . . . . . . .  29
   5.  Conclusion  . . . . . . . . . . . . . . . . . . . . . . . . .  32
     5.1.  Future Work & Unaddressed Portions  . . . . . . . . . . .  32
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .  33
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  33
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  33
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  33
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  33
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  37
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  37

1.  Conventions and Definitions

   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.

2.  Introduction

   Agent-to-agent communication introduces novel requirements for
   service discovery, authorization signaling, and metadata exchange.
   While several proposals have explored new discovery protocols, the
   DNS remains the most widely deployed and interoperable mechanism for
   service discovery, with decades of operational maturity.  Existing
   DNS record types (including SRV, NAPTR, SVCB, TXT, and A/AAAA) are
   routinely used to locate services and convey configuration metadata.
   It is therefore reasonable to assume that AI agents will interact
   with this network protocol during discovery, session initiation, and
   their application exchange.

   If a user at $company asks their agent "clean up my Salesforce data
   based on this email," how does $company agent then know where to find
   Salesforce's agents?  How would the Salesforce agent validate the



Mozley, et al.            Expires 19 April 2026                 [Page 4]

Internet-Draft                   BANDAID                    October 2025


   $company agent and make the correct requested changes to Salesforce
   data?  The former question is a DNS-solvable problem, the latter is
   not in the scope of this draft.

   DNS can convey authorization and intent: DNS provides an organization
   a way to indicate that an agent is authorized to act on behalf of a
   domain (DCV draft), publish allowed endpoints or capabilities (SVCB),
   advertise service metadata in a way that’s cacheable, verifiable, and
   language-agnostic (tree domain etc), all while creating tamper-proof
   records and binding identities to certificates (DNSSEC + DANE).
   Additionally, DNS contributes to agent security by enabling
   connections to trusted nameservers, mitigating risks from
   typosquatted or malicious domains, and enforcing geographic or
   jurisdictional boundaries through country-code top-level domains
   (ccTLDs) and regionally scoped authoritative servers.  These features
   collectively support secure, policy-compliant agent interactions at
   scale.

   Unlike proposals that rely on centralized registries or ungoverned
   discovery networks, BANDAID builds upon existing infrastructure and
   governance models.  It preserves operator sovereignty, supports
   decentralized publication, and benefits from support in the form of
   legal dispute processes and vulnerability disclosure programs.

   This document aims to address key concerns in governance, commerce,
   security, and performance, allowing agent protocol designers to focus
   on data exchange standards while relying on the DNS for discovery.
   Agent-to-agent communication would take place after initial
   discovery, but some key data can be put into the DNS as a shortcut to
   make it more efficient.

   The problem statement addressed by this draft is
   [I-D.draft-mozley-aidiscovery] and also relevant is
   [I-D.draft-rosenberg-ai-protocols] although this draft is related to
   the discovery of agents rather than protocols used directly in agent-
   to-agent communication.

2.1.  Challenges with Existing Proposed Mechanisms and Benefits of DNS

   Several alternative approaches to agent discovery have been proposed,
   including centralized registries, blockchain-based naming systems,
   and proprietary service directories.  While these models may offer
   novel features, they introduce significant architectural,
   operational, and governance challenges.  Centralized registries
   concentrate control and introduce single points of failure, limiting
   resilience and scalability.





Mozley, et al.            Expires 19 April 2026                 [Page 5]

Internet-Draft                   BANDAID                    October 2025


   Blockchain-based systems often lack integration with existing
   internet infrastructure, suffer from latency and cost constraints,
   and present jurisdictional ambiguity due to decentralized governance.
   Proprietary directories fragment the discovery ecosystem and inhibit
   interoperability across agent frameworks and administrative domains.
   Furthermore, securely delegating authority to AI solution providers
   on behalf of your organization requires interfacing between this
   central authority as opposed to business-to-business.

2.1.1.  Development

   The DNS benefits from decades of global development and operational
   deployment.  It is supported by mature ecosystems for vulnerability
   disclosure, patch management, and protocol evolution, with active
   participation from security researchers, vendors, and operators
   worldwide.  This distributed development model ensures that no single
   entity maintains disproportionate control over the protocol’s
   trajectory or security posture.

   DNS infrastructure is also tightly integrated with existing
   cybersecurity practices.  Connections to trusted nameservers,
   protections against typosquatted or malicious domains, and support
   for jurisdictional scoping via country-code top-level domains
   (ccTLDs) contribute to a robust security baseline.  These features
   are particularly relevant in agent-to-agent contexts, where automated
   systems make trust decisions without human oversight... and
   importantly, may be maliciously modified without human awareness.

   In contrast, the introduction of a novel discovery protocol would
   require the establishment of new governance structures, security
   models, and operational tooling.  Early implementations would likely
   be centralized among a limited set of stakeholders, introducing
   bottlenecks in protocol evolution and risk mitigation.  Building a
   comparable ecosystem would require sustained investment, cross-
   organizational coordination, and long-term trust-building—resources
   that DNS already possesses.

2.1.2.  Opportunity Cost

   Introducing a new protocol for agent-to-agent discovery imposes
   nontrivial infrastructure and operational requirements.  In
   particular, organizations may be required to deploy and maintain
   additional components such as specialized cache servers or registry
   interfaces, which increases complexity and operational overhead.
   Some proposals suggest a generic top level domain (gTLD) like
   .aiagent, which is more cost to advertise as domains are purchased by
   early opportunists.  These requirements may present barriers to
   adoption, especially for small or resource-constrained entities, and



Mozley, et al.            Expires 19 April 2026                 [Page 6]

Internet-Draft                   BANDAID                    October 2025


   risk reinforcing disparities in access to AI technologies.

   DNS, by contrast, is already deeply integrated into global
   infrastructure and supported by mature tooling, operational
   expertise, and deployment models.  Its use for agent discovery
   enables rapid adoption without introducing new layers of technical
   debt.  Leveraging DNS allows organizations to participate in agent-
   to-agent ecosystems using existing infrastructure, reducing
   onboarding friction and accelerating innovation.  This approach
   supports incremental deployment and minimizes opportunity cost by
   avoiding the need for parallel protocol development and
   infrastructure investment.

2.1.3.  Governance

   The DNS operates within a well-established and internationally
   recognized governance framework.  Oversight is provided by entities
   such as the Internet Assigned Numbers Authority (IANA), top-level
   domain (TLD) operators, and national network information centers
   (NICs).  These organizations maintain accountability mechanisms and
   support dispute resolution processes, including domain takedowns,
   mitigation of impersonation, and remediation of malicious behavior.
   The governance structures surrounding DNS have evolved over decades
   and are supported by legal, technical, and operational norms that
   facilitate cross-jurisdictional trust and stability.

   DNS also enables policy enforcement at the infrastructure level.  For
   example, country-code top-level domains (ccTLDs) and regionally
   scoped authoritative servers allow for jurisdictional boundaries to
   be respected, which may be relevant in agent deployments subject to
   regulatory constraints.  Additionally, DNSSEC and DANE provide
   cryptographic assurances that bind domain identities to certificates,
   supporting automated trust decisions without requiring centralized
   registries or manual validation.

   In contrast, alternative discovery proposals—such as blockchain-based
   registries or neutral third-party systems—lack formal integration
   with existing governance bodies and may be susceptible to
   fragmentation, influence, or jurisdictional ambiguity.  These models
   do not currently offer the same level of operational recourse or
   reliability.  Leveraging DNS for agent discovery allows organizations
   to build on trusted infrastructure while maintaining compatibility
   with existing governance frameworks, providing a stable foundation
   for innovation as more experimental models mature.

   Establishing a new governance structure based on new agent discovery
   protocols would be time consuming, involve all stakeholders agreeing
   on the structure, establishing the structure in a specific



Mozley, et al.            Expires 19 April 2026                 [Page 7]

Internet-Draft                   BANDAID                    October 2025


   jurisdiction (which may not be suitable for all parties), and involve
   creating the technical infrastructure to support it.  The DNS already
   has all of these components in place.

2.1.4.  Sovereignty

   The DNS supports decentralized control while maintaining global
   interoperability.  Organizations may operate their own authoritative
   DNS infrastructure, publish service records independently, and retain
   full control over how their services are discovered.  This model
   enables entities to maintain autonomy over their service exposure and
   operational boundaries without reliance on centralized intermediaries
   which may not share their same interests.

   Proposed alternatives—such as blockchain-based registries, single-
   purpose generic top-level domains (gTLDs), or third-party discovery
   networks—often introduce opaque governance models, unclear trust
   boundaries, and dependencies on external infrastructure.  Although
   these systems may be described as “decentralized,” they frequently
   concentrate control within protocol maintainers, validator networks,
   or registry operators, which may not be accountable to the
   organizations they serve.

   DNS provides a proven and extensible registry model that supports
   secure, independent publication of agent metadata.  It aligns with
   principles of digital sovereignty and operational self-determination,
   allowing organizations to participate in agent ecosystems without
   relinquishing control over discovery infrastructure.

2.1.5.  Commerce

   A critical consideration in the design of agent discovery
   infrastructure is the potential for commercialization to compromise
   integrity.  In the absence of established norms or constraints, new
   registry-based discovery mechanisms may evolve into visibility-driven
   platforms, where agent discoverability is influenced by paid
   placement rather than technical merit, trust, or reputation.  This
   introduces incentives that prioritize commercial interests over
   operational reliability and security, undermining the predictability
   and neutrality of agent interactions and the free and open Internet
   as a whole.

   DNS, by contrast, is built on open standards and governed by
   transparent, non-commercial processes.  It provides mechanisms for
   validation and authentication, such as DNSSEC, and certificate
   bindings via DANE that are not subject to monetization.  The
   resolution process is deterministic and not influenced by financial
   incentives, preserving the integrity of service discovery.



Mozley, et al.            Expires 19 April 2026                 [Page 8]

Internet-Draft                   BANDAID                    October 2025


   Leveraging DNS ensures that agent discovery remains a technical
   function grounded in verifiable identity and operational metadata,
   rather than a commercial battleground.  This supports fair access and
   trustworthy interactions across heterogeneous agent ecosystems.

2.1.6.  Application

   Regardless of how agent discovery is initiated, agent-to-agent
   communication ultimately intersects with existing network
   infrastructure.  Agents may require access to internal services,
   external APIs, or shared data repositories, all of which are
   typically addressed through conventional networking and resolution
   mechanisms.  Introducing a separate discovery protocol that fragments
   the location and representation of service metadata introduces
   architectural complexity and increases the risk of cascading failures
   across systems.

   Operators would be required to manage multiple layers of resolution
   logic, synchronization mechanisms, and failure domains, which
   complicates deployment and undermines operational reliability.  DNS,
   by contrast, is already embedded in the fabric of networked
   applications and provides a natural point of integration for
   discovery.  It enables metadata publication to remain proximate to
   the services it describes, reducing latency, simplifying
   architecture, and aligning with existing operational models.  This
   approach supports innovation in agent systems while avoiding brittle
   dependencies and minimizing architectural drift.

   DNS is predictable for agents to use for the purposes of discovery,
   requiring no advanced configurations to consume the service, rather
   it is embedded in all pieces of the application stack eliminating the
   need to retrofit legacy devices to operate in an agent-to-agent
   environment.

2.1.7.  Granularity

   DNS supports fine-grained control over service discovery through its
   hierarchical zone structure and flexible record types.  Organizations
   may define zones and records at varying levels of specificity,
   including per-host, per-service, per-environment (e.g., staging vs.
   production), or per geographic region.  This granularity enables
   precise targeting and segmentation of agent capabilities,
   facilitating operational clarity and policy enforcement.

   Service Binding (SVCB) records further enhance granularity by
   allowing metadata to be associated with individual service endpoints.
   This includes transport preferences, supported protocols, and
   application-specific parameters.  Combined with DNS Service Discovery



Mozley, et al.            Expires 19 April 2026                 [Page 9]

Internet-Draft                   BANDAID                    October 2025


   (DNS-SD), these features allow agents to discover services with high
   specificity, reducing ambiguity and improving interoperability.  The
   DNS model supports modular deployment and incremental adoption,
   making it well-suited for diverse agent architectures and operational
   contexts.

2.1.8.  Performance

   DNS is well-suited to meet the scale and responsiveness requirements
   of agent discovery, where billions of agents may generate trillions
   of queries.  Its architecture supports high-throughput, low-latency
   resolution through mechanisms such as caching, retry logic, and
   autom,atic zone distribution to secondary servers.  Recursive
   resolvers may be further optimized by locally hosting the root zone
   [RFC8806], reducing lookup latency and improving fault tolerance.

   Additional features such as pre-fetching and negative caching allow
   resolvers to anticipate agent behavior and reduce query overhead.
   Country code (ccTLD) and Generic Top Level Domain (gTLD) operators
   have global infrastructure to support localized resolution and
   improve performance for AI-specific applications.  These capabilities
   enable scalable deployment without requiring protocol redesign or new
   infrastructure layers.

   Furthermore, DNS-based discovery enables immediate connection
   establishment.  Once an agent endpoint is resolved, transport
   protocols such as QUIC may be used to initiate communication
   directly, benefiting from features such as 0-RTT and multiplexed
   streams.  This eliminates the need for a separate handshake or
   negotiation phase for discovery, reducing latency and improving
   throughput in high-volume environments.  DNS thus provides a
   performant and extensible foundation for agent discovery at global
   scale.

2.1.9.  Lifecycle / Management

   DNS provides robust provisioning and lifecycle management
   capabilities that align with the dynamic nature of agent-based
   systems.  Mechanisms such as Incremental Zone Transfer (IXFR) and
   Full Zone Transfer (AXFR) allow for rapid propagation of zone updates
   across authoritative servers.  When backed by database-centric DNS
   implementations, zone data may be treated as replicable state,
   enabling near-real-time onboarding or decommissioning of agents.

   Operational observability is supported through query logging, zone
   monitoring, and resolver telemetry, which can be used to track agent
   utilization patterns and identify stale or inactive records.




Mozley, et al.            Expires 19 April 2026                [Page 10]

Internet-Draft                   BANDAID                    October 2025


   These lifecycle management capabilities are mature, widely supported,
   and compatible with existing operational tooling.  They enable high-
   churn agent ecosystems to be managed efficiently without requiring
   the development of new provisioning, monitoring, or cleanup
   protocols.

2.1.10.  Trust

   In agent discovery, trust encompasses more than identity verification
   — it includes confidence in the provenance, behavior, and reliability
   of the agents being discovered.  The DNS provides a recognizable and
   auditable namespace rooted in organizational domains (e.g.,
   microsoft.com, openai.com), enabling systems to make informed
   decisions about agent interactions based on domain ownership and
   established reputational context.  This is particularly critical in
   AI environments, where agents may initiate autonomous actions or
   access sensitive data.

   DNS enables organizations to publish agent endpoints under domains
   they control, establishing a clear chain of accountability.  This
   trust model supports cryptographic validation through DNSSEC and
   DANE, allowing agents to verify domain ownership and certificate
   bindings without manual intervention.  By contrast, discovery
   mechanisms lacking verifiable lineage introduce significant risk and
   complexity, particularly when agents are discovered through opaque or
   ungoverned registries.

   The BANDAID model builds on the DNS’s trust infrastructure to support
   safe and scalable agent discovery.  It allows agents to assess the
   authenticity and authority of remote endpoints prior to interaction,
   reducing the likelihood of misrouting, impersonation, or unauthorized
   access.  This trust-validation-first approach is foundational to
   enabling secure automation in agent ecosystems.

2.1.11.  Agent Properties

   As agent-to-agent protocols evolve, it is likely more metadata will
   need to be signaled in the discovery phase to allow agents to make
   more informed decisions.  An example of how DNS provides a platform
   to facilitate this is below.











Mozley, et al.            Expires 19 April 2026                [Page 11]

Internet-Draft                   BANDAID                    October 2025


   Service Binding (SVCB) records, as defined in [RFC9460], support
   extensible key-value parameters that may be registered through the
   IANA SVCB Parameter Registry.  These parameters can provide agent
   systems with operational context prior to session initiation,
   enabling informed decisions about whether and how to engage with a
   remote agent.  It is possible to publish metadata such as input (e.g.
   expected token counts) or cost (e.g. cost per token bundle) directly
   within DNS records.

   This model supports a trust-validation-first approach to agent
   interaction, where expectations around resource usage and pricing are
   transparently advertised.  It reduces the need for handshake-based
   negotiation or out-of-band signaling, and allows for deterministic,
   cacheable discovery workflows.  For instance, by embedding cost-
   related metadata in DNS, discovery becomes not only scalable and
   performant, but also semantically rich, supporting economically-aware
   agent ecosystems without introducing new protocols or registries.

2.1.12.  Control

   Agent discovery mechanisms must operate within the constraints of
   enterprise security policies, regulatory compliance requirements, and
   operational boundaries.  DNS enables the presentation of distinct DNS
   views based on the source of the query.  This allows organizations to
   expose different sets of agent records to internal versus external
   resolvers.  For example, internal agents may resolve
   _a2a._agents.internal.example.com to discover services not intended
   for public exposure, while external agents receive responses only for
   _a2a._agents.example.com containing externally authorized endpoints.

   Enterprise-grade network controls such as firewalls, Response Policy
   Zones (RPZs), and access control lists (ACLs) provide additional
   enforcement mechanisms.  These controls may restrict outbound DNS
   queries to designated resolvers, filter inbound queries to approved
   zones, and block unauthorized resolution attempts.  This ensures that
   agent discovery adheres to organizational boundaries and complies
   with internal security policies.  For example, an enterprise may
   configure its network security to allow internal agents to query only
   *.internal.example.com zones, while blocking access to external agent
   zones unless explicitly permitted.  Similarly, DNS servers may
   enforce query logging and rate limiting to detect anomalous behavior
   or potential abuse.

   Segmented discovery via DNS aligns with compliance requirements
   related to data residency, privacy, and access control.  By scoping
   agent visibility to specific zones and enforcing resolution
   boundaries, organizations can ensure that discovery mechanisms
   respect jurisdictional constraints, internal governance models, and



Mozley, et al.            Expires 19 April 2026                [Page 12]

Internet-Draft                   BANDAID                    October 2025


   support auditability.  Query logs, zone access telemetry, and
   resolver behavior can be monitored to verify that agent interactions
   conform to policy.  This provides a foundation for regulatory
   reporting, incident response, and continuous compliance validation
   without the need for extensive additional operations that require
   more technical staffing or specialized solutions.

2.2.  Mechanisms for Successful Agent Communication

   The explicit goal of the DNS [RFC1035] is to provide a mechanism for
   name resolution, enabling agent discovery without requiring new
   protocols, trust anchors, or infrastructure layers.  Leveraging DNS
   for agent discovery ensures compatibility with existing operational
   models, supports incremental deployment, and avoids the risks
   associated with experimental or ungoverned discovery mechanisms.

2.2.1.  Service Binding Records, aka SVCB

   The SVCB resource record as defined in [RFC9460], enables DNS to
   convey structured service metadata that facilitates optimized
   connection establishment.  SVCB records support the advertisement of
   protocol identifiers (via ALPN), transport parameters (e.g., port
   numbers), endpoint hints (e.g., IP addresses), and extensible key-
   value attributes.  These capabilities are particularly relevant for
   agent-to-agent communication, where protocol negotiation and metadata
   exchange must occur without human intervention.

   In the context of BANDAID, SVCB records are used to publish agent-
   specific service endpoints under structured leaf zones (e.g.,
   _chat._agents.example.com).  These records allow querying agents to
   retrieve operational parameters prior to initiating a session,
   including supported protocols, privacy features (e.g., Encrypted
   Client Hello via ECH), and failover configurations.  This eliminates
   the need for heuristic-based connection attempts and reduces round-
   trip latency.

   SVCB records also support protocol agility and privacy-preserving
   features.  For example, agents may advertise support for QUIC,
   HTTP/3, or custom agent-to-agent protocols via ALPN declarations.
   Operators may specify alternate endpoints or migrate services across
   domains without relying on CNAME indirection, improving performance
   and reducing DNS resolution complexity.









Mozley, et al.            Expires 19 April 2026                [Page 13]

Internet-Draft                   BANDAID                    October 2025


   When paired with attribute leaf zones and custom SVCB parameters,
   this mechanism enables fine-grained discovery of agent capabilities.
   For instance, an agent querying _a2a._agents.example.com may receive
   an SVCB record indicating supported modalities (e.g., chat, image-to-
   text), expected input formats, and cost-related metadata (e.g., token
   pricing).  This structured discovery model supports deterministic,
   cacheable, and semantically rich interactions between agents.

2.2.2.  DNS Security Extensions, aka DNSSEC

   DNSSEC as defined in [RFC4033], [RFC4034], and [RFC4035], enables
   resolvers and clients to verify that a response originates from an
   authoritative source (authenticity) and DNS data has not been
   modified in transit (data integrity).  In the context of BANDAID,
   DNSSEC serves as a foundational trust mechanism for agent discovery.
   By signing agent-related resource records—such as SVCB, TXT, or
   custom metadata—organizations can ensure that querying agents receive
   authentic and tamper-proof information.  This is particularly
   critical for agent-to-agent communication, where autonomous systems
   must make trust decisions without human oversight.

   DNSSEC supports the establishment of cryptographic trust anchors via
   Delegation Signer (DS) records and facilitates secure delegation of
   authority across zone boundaries.  This allows organizations to
   publish agent metadata under subdomains (e.g.,
   _a2a._agents.example.com) while maintaining verifiable control over
   the zone hierarchy.

   Furthermore, DNSSEC eliminates the need for hardcoded trust lists or
   centralized validation services.  Agents can validate responses using
   the DNSSEC chain of trust, enabling decentralized and scalable trust
   verification.  This model supports zero-trust architectures and
   aligns with modern security principles by minimizing implicit trust
   and enforcing explicit validation.

   When combined with DANE (DNS-Based Authentication of Named Entities),
   DNSSEC enables binding of TLS certificates to DNS names, further
   enhancing the authenticity of agent endpoints.  This integration
   supports secure session initiation and mitigates risks associated
   with certificate mis-issuance or man-in-the-middle attacks.  The use
   of DANE may improve performance and enable automation in the
   dynamicism of agent lifecycle.









Mozley, et al.            Expires 19 April 2026                [Page 14]

Internet-Draft                   BANDAID                    October 2025


2.2.3.  DNS Service Discovery, aka DNS-SD

   DNS-SD as defined in [RFC6763], extends the capabilities of the
   Domain Name System to support service-type-based discovery.  Unlike
   traditional DNS resolution, which requires prior knowledge of a
   specific hostname, DNS-SD enables clients to discover services based
   on their functional type (e.g., _http._tcp, _printer._udp) within a
   given domain.

   In the context of BANDAID, DNS-SD provides a mechanism for AI agents
   to discover other agents or services based on declared capabilities
   rather than explicit names.  For example, an agent may issue a query
   for _data-cleaner._a2a._agents.example.com to locate services capable
   of performing data sanitization tasks.  This type-based discovery
   model supports dynamic ecosystems where agent roles and capabilities
   may evolve over time.

   DNS-SD operates over both multicast DNS (mDNS) and unicast DNS,
   allowing for flexible deployment in local networks and globally
   scoped domains.  In enterprise or cloud environments, unicast DNS-SD
   enables structured and policy-compliant discovery across
   organizational boundaries.  When combined with SVCB records, DNS-SD
   allows agents to retrieve detailed service metadata, including
   transport preferences, protocol support, and operational parameters.

   This model supports federated agent architectures, where multiple
   agents may advertise similar capabilities under different domains.
   By leveraging DNS-SD, agents can perform capability-based queries and
   receive a list of candidate services, each accompanied by structured
   metadata for evaluation and selection.

   DNS-SD also supports extensibility through TXT records and custom
   service naming conventions, enabling organizations to encode
   additional attributes relevant to agent interaction (e.g., supported
   data formats, authentication requirements, or cost models).  These
   features make DNS-SD a suitable foundation for scalable,
   interoperable, and semantically rich agent discovery workflows.

2.2.4.  DNS-Based Authentication of Named Entities, aka DANE

   DANE as specified in [RFC6698] and [RFC7671], enables domain owners
   to associate Transport Layer Security (TLS) certificates with DNS
   names using TLSA resource records.  When protected by DNSSEC, these
   records provide cryptographically verifiable bindings between domain
   names and public keys, allowing clients to authenticate services
   without relying solely on external certificate authorities (CAs).





Mozley, et al.            Expires 19 April 2026                [Page 15]

Internet-Draft                   BANDAID                    October 2025


   In the context of BANDAID, DANE enhances the trust model for agent-
   to-agent communication by enabling agents to validate the
   authenticity of remote endpoints based on domain-controlled
   assertions.  This is particularly relevant in automated environments
   where agents must establish secure sessions without manual
   certificate validation or user interaction.

   By publishing TLSA records under agent-specific service names (e.g.,
   _a2a._tcp.agent.example.com), organizations can declare the expected
   certificate fingerprint or public key for a given agent endpoint.
   Querying agents can then validate the TLS connection against the DANE
   record, ensuring that the certificate presented during session
   initiation matches the domain’s published intent.

   This mechanism mitigates risks associated with certificate mis-
   issuance, man-in-the-middle attacks, and reliance on third-party
   trust anchors.  It also supports deterministic validation workflows,
   which are critical for agents operating in headless or GUI-less
   environments where interactive certificate warnings cannot be
   resolved.

   When combined with DNSSEC, DANE provides a robust, decentralized, and
   verifiable trust infrastructure for agent discovery and
   communication.  It aligns with zero-trust principles by enabling
   domain owners to assert and control trust relationships directly
   through DNS, without introducing additional registries or validation
   services.

2.2.5.  Domain Control Validation, aka DCV

   DCV refers to the process by which an entity demonstrates
   authoritative control over a DNS domain.  As described in draft-ietf-
   dnsop-domain-verification-techniques, DNS-based DCV typically
   involves the placement of a DNS record—most commonly a TXT
   record—containing a challenge token or assertion at a designated
   location within the domain.  This record is then queried by an
   Application Service Provider (ASP) to confirm control.

   In the context of BANDAID, DCV provides a mechanism for agents to
   assert delegated authority on behalf of a domain.  For example, an
   organization may publish a TXT record under a structured leaf zone
   (e.g., _agent-roles._a2a._agents.example.com) containing metadata
   such as:

      ai-role=data-cleaner; crm=salesforce; access=readonly






Mozley, et al.            Expires 19 April 2026                [Page 16]

Internet-Draft                   BANDAID                    October 2025


   This record signals that a specific agent is authorized to perform
   scoped operations under the domain's authority.  When protected by
   DNSSEC, such assertions become cryptographically verifiable,
   mitigating risks of spoofing or unauthorized delegation.

   DCV within BANDAID supports both ephemeral and persistent validation
   models.  Ephemeral validation may be used for short-lived agent
   credentials or session-based delegation, while persistent records
   enable long-term authorization signaling.  TTL and expiration
   considerations, as discussed in the draft, are critical to ensuring
   that validation records do not persist beyond their intended scope.

   Furthermore, BANDAID encourages the use of application-specific
   naming conventions and token formats to avoid service confusion and
   collision.  Validation records should be scoped to the intended
   service and include unguessable tokens or structured metadata to
   prevent unauthorized reuse across federated agent ecosystems.

2.2.6.  Service Resilience

   The DNS architecture is inherently resilient due to its distributed,
   hierarchical design.  Authoritative zones are replicated across
   multiple servers, and recursive resolvers implement caching, retry
   logic, and failover mechanisms to ensure continuity of resolution.
   Failover, anycast, and replication continue to add resiliency and
   redundancy provided through the DNS.

   This fault-tolerant model supports agent discovery even in the
   presence of partial network outages, denial-of-service conditions, or
   upstream failures.  Unlike centralized registries or proprietary
   APIs, DNS does not rely on a single point of availability, making it
   suitable for high-availability agent ecosystems operating across
   diverse network environments.

2.2.7.  Observability, Auditability

   DNS provides built-in observability through query logging, resolver
   telemetry, and zone monitoring.  These features enable operators to
   track agent discovery patterns, detect anomalous behavior, and
   perform forensic analysis of agent interactions.  This auditability
   is critical in regulated environments where agent actions must be
   attributable and verifiable, and where discovery mechanisms must
   align with enterprise governance models.

   Logs may be used to validate compliance with access policies,
   identify stale or misconfigured records, support incident response
   workflows, and/or be used in lifecycle management of unused or
   oversubscribed agents.



Mozley, et al.            Expires 19 April 2026                [Page 17]

Internet-Draft                   BANDAID                    October 2025


2.2.8.  Interoperability

   BANDAID is designed to be agnostic to agent implementation
   frameworks.  Whether agents are built using open-source libraries,
   proprietary orchestration platforms, or custom runtimes, DNS-based
   discovery provides a common substrate for metadata publication and
   retrieval.  This interoperability ensures that agents operating under
   different protocols, vendors, or administrative domains can
   participate in shared discovery workflows without requiring protocol
   translation or framework-specific integration.  DNS’s ubiquity across
   operating systems and network stacks further reinforces its
   suitability as a universal discovery layer.

2.2.9.  Multitenancy, Federation

   DNS’s hierarchical namespace supports multi-tenant and federated
   discovery models.  Organizations may delegate subdomains to tenants
   (e.g., customer1._agents.vendor.com) or publish agent metadata under
   federated zones (e.g., region1._a2a.example.org).  This enables
   scoped discovery, policy enforcement, and operational isolation
   across tenants, departments, or geographic regions.  Combined with
   DNSSEC and access controls, this model supports secure delegation and
   trust signaling in complex agent ecosystems, including SaaS platforms
   and cross-organizational collaborations.

2.3.  Architecture

2.3.1.  Example Communication

   Agent (org1) wants to find other agents provided by another entity
   (org2) and discover/verify capabilities

   DNS SVCB Query ┌────────┐ _a2a._agents.example.com ┌────────┐
   ┌────────┐ │AI
   Agent├─────────────────────────────►│Resolver├───────────►│Auth DNS│
   │ (ORG1) │ ◄────────────────────────────┤ (ORG1) │◄─────┬─────┤
   (ORG2) │ └────────┘ └────────┘ │ └────────┘ │
   ┌─────────────────────────────────────────────────┴─────────────┐
   │_a2a._aiagent.org2.com. 3600 IN SVCB 1 ai-index-svc.org2.com. (│ │
   alpn="a2a" │ │ port=443 │ │ ipv4hint=192.0.2.1 │ │
   ipv6hint=2001:db8::1 │ │) │
   └───────────────────────────────────────────────────────────────┘

2.3.2.  Example Record

   _a2a._aiagent.org2.com. 3600 IN SVCB 1 ai-index-svc.org2.com. (
   alpn="a2a" port=443 ipv4hint=192.0.2.1 ipv6hint=2001:db8::1 )




Mozley, et al.            Expires 19 April 2026                [Page 18]

Internet-Draft                   BANDAID                    October 2025


   _a2a._aiagent.example.com.: The service name, following the SVCB
   naming convention (_service._agents.example.com). 3600: TTL (Time to
   Live) in seconds.  IN SVCB: The record type. 1: SVCB priority. 0 is
   for alias mode; 1+ is for service mode. ai-index-svc.org2.com.: The
   target name of the service. alpn="a2a": Specifies the ALPN protocol
   identifier.  This is where your custom protocol is declared.
   port=443: The port on which the service is available. ipv4hint and
   ipv6hint: Optional hints for clients to connect directly.

2.3.3.  Example Use Cases

      A user instructs their internal agent to “clean up Salesforce
      contacts based on this email.” The agent must discover
      Salesforce’s authorized agents, validate its own delegation to act
      on behalf of the enterprise, and initiate a secure session.
      BANDAID enables this by publishing agent endpoints and roles under
      DNS zones controlled by each organization.

      A research consortium deploys agents across multiple institutions.
      Each institution publishes its agents under its own domain (e.g.,
      _a2a._agents.universityA.edu), allowing collaborators to discover
      services based on capability (e.g., _data-
      annotator._a2a.universityB.edu) while respecting institutional
      boundaries and trust models.

      A SaaS provider hosts agents for multiple customers.  Each
      customer’s agents are published under tenant-specific zones (e.g.,
      customer1._agents.saas.com), enabling scoped discovery and policy
      enforcement.  BANDAID supports this model through hierarchical
      zone delegation and metadata-rich SVCB records.

      Lightweight agents deployed on mobile or edge devices require low-
      latency, cacheable discovery mechanisms.  DNS’s distributed
      architecture and support for SVCB hints (e.g., IP addresses,
      preferred protocols) enable efficient resolution and connection
      bootstrapping in constrained environments.

      In regulated industries, agents must operate within jurisdictional
      boundaries and maintain audit trails of interactions.  DNS
      supports geographic scoping via ccTLDs and split-horizon
      configurations, while query logging and DNSSEC provide
      observability and integrity guarantees.









Mozley, et al.            Expires 19 April 2026                [Page 19]

Internet-Draft                   BANDAID                    October 2025


3.  BANDAID Overview

   The BANDAID model is designed for incremental and non-disruptive
   deployment within existing DNS infrastructure.  It introduces no new
   DNS message formats, opcodes, response codes, or resource record
   types.  Instead, it defines a structured namespace convention and
   usage profile for existing record types... primarily SVCB, TXT, and
   TLSA all within designated leaf zones (e.g.,
   _a2a._agents.example.com).

   Organizations may adopt BANDAID by publishing agent metadata under
   delegated subdomains, leveraging DNSSEC for integrity and
   authenticity, and optionally implementing Domain Control Validation
   (DCV) to signal delegated authority.  These zones may be exposed
   selectively via split-horizon DNS, enabling differentiated discovery
   views for internal and external agents.  No changes are required to
   recursive or authoritative DNS server implementations beyond standard
   support for DNSSEC and SVCB.

   This model supports opt-in adoption, allowing agent operators to
   publish discovery metadata without coordination with external
   registries or protocol maintainers.  It is compatible with existing
   DNS tooling, including zone provisioning systems, monitoring
   platforms, and resolver configurations.  BANDAID is therefore
   suitable for deployment across enterprise, cloud, and federated
   environments, and may coexist with other discovery mechanisms without
   conflict.

3.1.  Zone and Other Requirements

3.1.1.  Delegation and Chain of Trust

   An external authoritative zone used for the purposes of BANDAID MUST
   use DNSSEC [RFC4033].  The BANDAID external zone MUST establish a
   complete chain of trust to a publicly recognized trust anchor.  For
   zones delegated from a public parent, DS records MUST be present and
   maintained at the parent zone.  DS digests MUST use SHA-256 (Digest
   Type 2) as specified in [RFC4509]; SHA-1 (Digest Type 1) MUST NOT be
   used.  Where feasible, automation of DS maintenance SHOULD be
   performed using CDS and CDNSKEY as specified in [RFC7344] and
   operationalized per [RFC8078].










Mozley, et al.            Expires 19 April 2026                [Page 20]

Internet-Draft                   BANDAID                    October 2025


3.1.2.  Algorithms and Parameters

   Authoritative signers for the BANDAID External Zone MUST use DNSSEC
   algorithms and key sizes consistent with current implementation and
   usage guidance in [RFC8624].  Implementations SHOULD prefer
   elliptic-curve or EdDSA algorithms for efficiency and security,
   specifically ECDSA P-256 (Algorithm 13; [RFC6605]) or Ed25519
   (Algorithm 15; [RFC8080]).  Zones MUST NOT rely on RSA/SHA-1
   signatures.  If RSA is used for transitional reasons, key sizes
   SHOULD be ≥ 2048 bits and migration to ECDSA or EdDSA SHOULD be
   planned.

   Separation of roles between a Key-Signing Key (KSK) and a
   Zone-Signing Key (ZSK) is RECOMMENDED for operational agility,
   consistent with practices in [RFC6781].  Private keys SHOULD be
   protected by appropriate controls (e.g., HSMs or equivalent)
   commensurate with organizational risk.

3.1.3.  Authenticated Denial of Existence

   The BANDAID External Zone MUST provide authenticated denial of
   existence.  NSEC3 [RFC5155] is RECOMMENDED to mitigate trivial zone
   enumeration for zones where record names or labels might reveal
   sensitive information.  If NSEC3 is used, the number of iterations
   SHOULD be kept modest to balance CPU cost for signers and validators,
   per guidance in [RFC6781].  Use of NSEC with White Lies is OPTIONAL
   where operationally justified.

3.1.4.  Signature Validity

   Signature validity windows MUST be chosen to balance cache efficiency
   and replay risk.  In general, a signature lifetime on the order of
   days to a small number of weeks is RECOMMENDED, with staggered
   resigning to avoid mass expiration events [RFC6781].  Resource Record
   TTLs MUST be set to values that support timely updates to BANDAID
   capability data while allowing effective caching; operational
   defaults SHOULD be validated against change frequency.  Negative
   caching behavior MUST follow [RFC2308].

3.1.5.  Key Rollover

   Zones MUST support planned key rollovers and emergency key
   replacement consistent with the procedures in [RFC6781].
   Pre-publication and double-signature techniques SHOULD be used to
   minimize validation failures during ZSK and KSK rollovers.  Parent DS
   changes SHOULD be orchestrated using CDS/CDNSKEY signaling
   [RFC7344][RFC8078].  Post-compromise recovery procedures MUST be
   documented, including revocation, re-signing, and DS replacement



Mozley, et al.            Expires 19 April 2026                [Page 21]

Internet-Draft                   BANDAID                    October 2025


   timelines.

3.1.6.  Transport and Message Size

   Because DNSSEC increases response sizes, authoritative servers for
   the BANDAID External Zone MUST implement EDNS(0) per [RFC6891] and
   MUST support TCP fallback for queries per [RFC7766].  Authoritative
   operators SHOULD configure UDP response sizing to minimize IP
   fragmentation risk and SHOULD ensure that large responses (e.g.,
   DNSKEY, NSEC3 chains) remain retrievable via TCP.

3.1.7.  Transfer and Integrity

   When secondary authoritative servers are used, zone transfers MUST be
   authenticated and protected with TSIG [RFC2845].  Use of DNS NOTIFY
   [RFC1996] and incremental transfer (IXFR; [RFC5936]) is RECOMMENDED
   to reduce propagation latency and bandwidth.  To provide at-rest
   integrity verification between primaries and secondaries, publishing
   a ZONEMD record is RECOMMENDED where supported [RFC8976].

3.1.8.  Monitoring

   Operators MUST monitor DNSSEC validity from multiple vantage points
   to detect stale signatures, DS/DNSKEY mismatches, and other
   validation failures.  Alarms SHOULD be configured for impending
   signature expiration, key compromise indicators, and DS
   inconsistencies.  Signing infrastructure SHOULD be tested under load
   and failure scenarios consistent with the scalability requirements of
   this specification.

3.1.9.  Abuse Resistance

   Authoritative servers for the BANDAID External Zone SHOULD implement
   DNS Cookies [RFC7873][RFC9018] to reduce off-path spoofing and
   amplification risks.  Operators SHOULD follow best practices to limit
   amplification and to shape responses under attack, consistent with
   maintaining DNSSEC validity.

3.1.10.  BANDAID Records

   All BANDAID-specific discovery records (e.g., SRV [RFC2782], SVCB/
   HTTPS [RFC9460], TXT/URI [RFC7553] used for capability descriptors,
   and any BANDAID-defined RRTypes) MUST be signed and published in the
   BANDAID External Zone.  Where BANDAID endpoints rely on TLS,
   publication of DANE TLSA records SHOULD be used to bind endpoint
   certificates to DNSSEC-validated names [RFC6698][RFC7671].  Resolver
   behavior consuming BANDAID data MUST treat DNSSEC-bogus responses as
   failures and MUST NOT act on unsigned or invalidly signed discovery



Mozley, et al.            Expires 19 April 2026                [Page 22]

Internet-Draft                   BANDAID                    October 2025


   data.

3.1.11.  Performance Optimization(s)

   The discovery namespace for BANDAID SHOULD be structured to minimize
   query depth, RRset size, and update blast radius.  To that end,
   implementers SHOULD allocate per-service, per-agent leaf names and
   avoid aggregating high-cardinality data under a single owner name.  A
   deterministic mapping (e.g., a stable hash of an Agent Identifier) to
   leaf labels SHOULD be used to support sharding and parallel
   administration.  Where cardinality requires, sub-zones MAY be
   delegated (zone cuts) to distribute authority and update load.

   Each agent service endpoint SHOULD be published using SVCB in
   ServiceMode (or HTTPS RR for HTTPS endpoints) to convey connection
   parameters and capability locators with a single lookup [RFC9460].
   SVCB “address hints” (ipv4hint, ipv6hint) SHOULD be used to reduce A/
   AAAA follow-up queries; resolvers MAY still validate final addresses
   via canonical resolution.  Where human-friendly names are required,
   SVCB AliasMode (priority 0) MAY be used to map from a stable alias to
   a hashed leaf, avoiding record duplication while preserving cache
   locality.

   Authoritative servers MUST support EDNS(0) [RFC6891] and TCP fallback
   [RFC7766].  Operators SHOULD target response sizes that avoid IP
   fragmentation on common paths (e.g., ≤1232 bytes on IPv6), preferring
   compression and layered indirection over oversized RRsets.  TTLs MUST
   be chosen to reflect the volatility of capability data; index/
   indirection records may use longer TTLs than frequently changing
   endpoint or capability descriptors.  Negative caching MUST conform to
   [RFC2308].  When high update rates are expected, IXFR and NOTIFY
   SHOULD be used to reduce propagation latency.

   Resolvers and authoritative operators SHOULD take advantage of SVCB’s
   ALPN, port, and (for HTTPS) ECH parameters to enable connection
   pre-establishment and reduce round-trips, subject to client policy
   and security posture [RFC9460].  Where privacy policies prohibit
   client geolocation, EDNS Client Subnet SHOULD NOT be relied upon for
   performance.

   A representative naming pattern is shown below; the exact label order
   is deployment-specific, but the leaf per service, per agent rule
   applies:

   ``` ; Hashed, per-agent, per-service leaf
   a4k2f9._mcp._bandaid.example.org.  600 IN SVCB 1 svc-
   a4k2f9.example.org.  alpn="h2,h3" port=443 ipv6hint=2001:db8::5
   ipv4hint=192.0.2.5



Mozley, et al.            Expires 19 April 2026                [Page 23]

Internet-Draft                   BANDAID                    October 2025


   ; Optional alias for a friendlier owner name
   billing._mcp._bandaid.example.org. 300 IN SVCB 0
   a4k2f9._mcp._bandaid.example.org. ```

3.1.12.  Customization(s)

   BANDAID deployments MAY define additional SVCB parameters
   (SvcParamKeys) to convey agent-specific capability metadata, provided
   that interoperability safeguards in [RFC9460] are observed.  During
   experimentation, unregistered keys MUST use the numeric keyNNNNN
   presentation form, and any client behavior that depends on them MUST
   be gated via the mandatory SvcParam to ensure downgrade safety.  This
   specification defines the following provisional SvcParamKeys for
   BANDAID (names are illustrative; production deployments MUST register
   through IANA per [RFC9460] or use keyNNNNN until standardized):

      cap — a capability descriptor locator or inline identifier (e.g.,
      a URN or compact JSON-Ref) that identifies the agent’s advertised
      capability schema/version. cap-sha256 — a base64url-encoded
      SHA-256 digest of the canonical capability descriptor to support
      integrity checks and cache revalidation. bap — a comma-separated
      list of BANDAID Application Protocols and versions understood by
      the endpoint (e.g., bap="a2a/1,mcp/1,acp/2").  This is distinct
      from transport-level alpn. policy — a URI or URN identifying a
      policy bundle applicable to this agent (e.g., jurisdiction, data
      handling class) for client-side selection. realm — an opaque token
      for multi-tenant scoping or authz realm selection during protocol
      bootstrapping.

   Clients that require any of these parameters MUST verify their
   presence via the mandatory key; otherwise, the SVCB record MUST be
   ignored.  Example:

   Single-RRTYPE publication with custom params (experimental keys
   shown) a4k2f9._mcp._bandaid.example.org. 600 IN SVCB 1 svc-
   a4k2f9.example.org.  alpn="h2" port=443 ipv4hint=192.0.2.5
   mandatory=alpn,port,key65001,key65002,key65010
   key65001="cap=urn:cap:example:mcp:invoice.v1" key65002="cap-
   sha256=yvZ0n7q8bE2gYkz8m1j1s0yQG0mC2F6qj3b9pVb6Gk0"
   key65010="bap=a2a/1,mcp/1" Where endpoints are HTTPS, the HTTPS RR
   variant SHOULD be used to co-locate transport parameters such as ech
   with capability metadata; otherwise, generic SVCB MAY be used.
   Future standardization SHOULD define the exact syntax (e.g., ABNF)
   and registry policy for these keys, including error handling for
   malformed or conflicting parameters.  Until registration is complete,
   deployments MUST treat unknown keyNNNNN parameters as opaque and MUST
   NOT infer semantics without out-of-band agreement.




Mozley, et al.            Expires 19 April 2026                [Page 24]

Internet-Draft                   BANDAID                    October 2025


4.  Implementation Guidance

4.1.  AI Operators

4.1.1.  Separation of Roles

   Operators MUST separate authoritative servers for BANDAID zones from
   recursive resolvers to prevent cache poisoning and reduce operational
   coupling.  Authoritative servers MUST NOT perform recursion.
   Recursive resolvers SHOULD be deployed close to query sources (e.g.,
   within organizational networks or edge PoPs) to minimize latency and
   reduce upstream load.

4.1.2.  Local Root Zone Copy

   Recursive resolvers serving BANDAID traffic SHOULD maintain a local
   copy of the root zone as specified in [RFC8806].  This eliminates
   dependency on external root servers for priming queries, reduces
   resolution latency, and improves resilience during partial Internet
   outages or denial-of-service events targeting root infrastructure.

4.1.3.  Aggressive Caching and Prefetch

   Resolvers MUST implement RFC-compliant caching and SHOULD enable the
   aggressive use of DNSSEC-validated cache to synthesize negative
   answers from NSEC/NSEC3 and reduce upstream lookups, consistent with
   [RFC8198].  This behavior improves latency, lowers authoritative
   load, and can mitigate certain attack patterns by answering within
   validated non-existence ranges.

   Resolvers SHOULD implement serve-stale as specified in [RFC8767].
   When authoritative servers are unreachable or fail to refresh data, a
   resolver MAY return expired records from its cache to preserve
   availability, subject to policy caps on staleness.  [RFC8767] updates
   the TTL semantics to allow use beyond expiration under these
   exceptional conditions and RECOMMENDS capping staleness on the order
   of days, with a typical cap of 7 days.  When serving stale data, the
   TTL in the response MUST be set to a value greater than zero (with 30
   seconds RECOMMENDED) so clients and intermediaries do not cache a
   zero-TTL response indefinitely.











Mozley, et al.            Expires 19 April 2026                [Page 25]

Internet-Draft                   BANDAID                    October 2025


   Resolvers implementing serve-stale SHOULD follow the timer guidance
   in [RFC8767]: continue background refresh (“stale-while-revalidate”),
   bound total resolution work with a query-resolution timer, avoid
   excessive re-tries with a failure-recheck timer (no more frequently
   than ~30 seconds is RECOMMENDED), and ensure client responsiveness
   with a client-response timer (on the order of ~1.8 seconds is
   RECOMMENDED).  These controls balance resiliency with freshness and
   protect upstream authorities during outages or attack conditions.

   Operators MUST consider DNSSEC interactions when serving stale data.
   Stale answers can increase the likelihood that signatures are outside
   their validity windows; implementations MUST NOT misrepresent
   validation status (e.g., AD bit handling MUST follow DNSSEC semantics
   where the bit is only set if all relevant RRsets are
   cryptographically verified according to local policy).

   Prefetch of popular BANDAID names SHOULD be used to keep caches warm,
   and negative caching MUST follow [RFC2308] to avoid unnecessary
   upstream traffic during flaps.  Where serve-stale is enabled,
   operators SHOULD monitor stale-answer rates and staleness
   distribution to ensure that policy caps and refresh behavior meet
   availability and freshness objectives.

4.1.4.  EDNS(0) Transport Resilience

   All servers MUST support EDNS(0) [RFC6891] and TCP fallback [RFC7766]
   to accommodate DNSSEC and SVCB responses that exceed traditional UDP
   size limits.  Operators SHOULD configure UDP response sizing to avoid
   IP fragmentation (e.g., ≤1232 bytes for IPv6 paths) and SHOULD
   monitor truncation rates to detect misconfigurations or path MTU
   issues.\

4.1.5.  Load Distribution

   Authoritative servers for BANDAID zones SHOULD be deployed using IP
   anycast to provide global reachability, load balancing, and DDoS
   resilience.  Recursive resolvers SHOULD be deployed in a
   geographically distributed manner to minimize latency for agent
   queries and to provide failover during regional outages.

4.1.6.  Monitoring and Telemetry

   Operators MUST implement continuous monitoring of query latency,
   cache hit ratios, DNSSEC validation success rates, and transport
   fallback events.  Alarms SHOULD be configured for anomalies such as
   sudden TTL exhaustion, signature expiration, or upstream
   unreachability.  Logging MUST respect privacy and regulatory
   constraints while providing sufficient detail for operational



Mozley, et al.            Expires 19 April 2026                [Page 26]

Internet-Draft                   BANDAID                    October 2025


   troubleshooting and compliance audits.

4.1.7.  Encrypted Resolver Steering (Informative)

   AI clients and operators MAY implement Encrypted DNS Server
   Redirection (EDSR) to permit an encrypted resolver to redirect a
   client to another encrypted resolver for performance, locality, or
   policy reasons Any acceptance of redirection MUST follow the
   verified-discovery model of DDR [RFC9462], including validation of
   the designated relationship and TLS authentication of the target
   resolver.  If redirection validation fails or exceeds a single hop,
   clients MUST continue to use the original resolver configuration.
   When available, network-designated resolvers provisioned via DNR
   [RFC9463] take precedence over unsolicited redirection unless local
   policy dictates otherwise.  EDSR is currently an Internet-Draft and
   is referenced as an OPTIONAL extension.

4.2.  AI Consumers

4.2.1.  DNS-Based Service Discovery

   DNS-Based Service Discovery AI clients that consume BANDAID discovery
   data MUST implement DNS-based service discovery consistent with
   [RFC6763] and [RFC9460].  Clients SHOULD query for SVCB or HTTPS
   records at well-defined service labels (e.g.,
   _mcp._bandaid.example.org.) and interpret alpn, port, and custom
   SvcParams as specified in this document.  Where multiple priorities
   are returned, clients MUST honor the SVCB priority and weight
   semantics for selection and failover.  Clients MUST validate DNSSEC
   signatures for all discovery responses and MUST NOT act on unsigned
   or bogus data.

   Clients SHOULD implement caching consistent with TTLs and negative
   caching rules in [RFC2308].  Prefetching of high-traffic names MAY be
   used to reduce latency, provided that it does not violate policy or
   privacy constraints.  Clients MUST support EDNS(0) and TCP fallback
   to handle large responses.

4.2.2.  Communication Failure / Retry

   When a discovered agent endpoint is unreachable, clients MUST
   implement retry logic that respects exponential backoff and avoids
   synchronized retry storms.  Clients SHOULD attempt alternate SVCB
   targets in priority order before declaring failure.  Where
   serve-stale responses are received, clients MUST treat them as
   advisory and MUST NOT assume freshness beyond the TTL indicated in
   the response.  Clients SHOULD log stale usage for observability and
   compliance.



Mozley, et al.            Expires 19 April 2026                [Page 27]

Internet-Draft                   BANDAID                    October 2025


4.2.3.  Domain Control Validation

   To prevent impersonation and unauthorized data access, BANDAID
   deployments MUST support Domain Control Validation (DCV) using DNS.
   This mechanism allows application owners to verify that a requesting
   service is authorized to act on behalf of a domain (e.g., “AI, sync
   all customer contacts from my approved CRM for acme.org”).  DCV MUST
   follow a challenge-response model where the domain owner publishes a
   cryptographically strong token in a DNS TXT record under a
   well-defined label (e.g., _bandaid-challenge.acme.org.).  The token
   MUST be bound to the requesting service identity and have a bounded
   validity period.  Clients performing DCV MUST validate the token
   against the expected value and expiration before granting delegated
   access.  Tokens SHOULD be single-use and MUST be removed from DNS
   after successful validation.  All DCV interactions MUST occur over
   DNSSEC-validated channels to prevent spoofing or downgrade attacks.

4.3.  AI Developers

4.3.1.  Publishing Schema

   Publishers SHOULD expose per-service discovery records using SVCB (or
   HTTPS for HTTP origins) at stable, well-scoped owner names (e.g.,
   agent-id._mcp._bandaid.example.org.).  SVCB ServiceMode conveys
   connection parameters and capability locators in a single round trip;
   AliasMode MAY be used to map a friendly name to a hashed leaf for
   sharding without duplicating RRSets.  Initial connection parameter
   keys (alpn, port, address hints) and the mandatory key MUST be
   honored by clients.  [RFC9460]

   Minimal example:

   ; ServiceMode SVCB for an MCP-capable agent
   a4k2f9._mcp._bandaid.example.org.  600 IN SVCB 1 svc-
   a4k2f9.example.net.  alpn="h2,h3" port=443 ipv6hint=2001:db8::5
   ipv4hint=192.0.2.5 mandatory=alpn,port

   SVCB/HTTPS semantics and SvcParam processing MUST follow [RFC9460] to
   ensure interop and correct fallback.

4.3.2.  TTLs, Update Agility

   Publishers SHOULD assign longer TTLs to relatively static indirection
   records (aliases, stable service labels) and shorter TTLs to volatile
   endpoint/capability records to balance cache efficiency with rollout
   safety.  Consumers will apply negative caching per [RFC2308], so
   publishers SHOULD avoid unnecessary NXDOMAIN flaps during deployments
   (e.g., prefer blue/green leaves over in-place deletions).



Mozley, et al.            Expires 19 April 2026                [Page 28]

Internet-Draft                   BANDAID                    October 2025


4.3.3.  Capability Retrieval

   When capability metadata is referenced via URI from SVCB/HTTPS,
   retrieval MUST occur over authenticated, confidential channels.
   Publishers SHOULD offer TLS 1.3 and MAY bind endpoint identity via
   DANE TLSA where resolvers validate DNSSEC; otherwise, WebPKI
   validation applies.  Operational guidance for DANE usage (certificate
   usage selections, rollover) SHOULD follow [RFC7671] [RFC8446]
   [RFC6698]

   Where using HTTPS RRs, publishers MAY advertise the ech SvcParam to
   enable Encrypted Client Hello for privacy; client/server behavior and
   key distribution MUST follow the semantics described in [RFC9460] for
   the ech parameter.

4.3.4.  Example DCV Flow

   Example DCV Flow (Normative Sketch)

   *  The relying service issues a DCV challenge with a nonce bound to
      its identity and an expiration time.

   *  The domain owner publishes the nonce at _bandaid-challenge.domain.
      as a TXT RR until validation completes.

   *  The verifier performs a DNSSEC-validated TXT query and compares
      the presented nonce and binding; on success, access is granted and
      the TXT is removed.

   need a sketch for how this looks

4.3.5.  Example Zonefile

   ``` $ORIGIN example.org. $TTL 3600

   ; -------------------------------------------------------------------
   --- ; SOA / NS ; ----------------------------------------------------
   ------------------ @ IN SOA ns1.example.org. hostmaster.example.org.
   ( 2025091901 ; serial (YYYYMMDDnn) 7200 ; refresh 1800 ; retry
   1209600 ; expire 3600 ) ; minimum IN NS ns1.example.org.  IN NS
   ns2.example.org.

   ns1 IN A 192.0.2.53 ns1 IN AAAA 2001:db8::53 ns2 IN A 192.0.2.54 ns2
   IN AAAA 2001:db8::54

   ; -------------------------------------------------------------------
   --- ; BANDAID discovery (MCP example): per-service, per-agent leaf ;
   - Leaf is a stable mapping from AgentID -> label (e.g. hashed). ; -



Mozley, et al.            Expires 19 April 2026                [Page 29]

Internet-Draft                   BANDAID                    October 2025


   Use SVCB ServiceMode (priority > 0) to bind connection parameters. ; 
   ---------------------------------------------------------------------
   -

   ; AliasMode to keep a friendly name stable even if the leaf changes
   billing._mcp._bandaid 300 IN SVCB 0 a4k2f9._mcp._bandaid.example.org.

   ; Leaf per agent/service (ServiceMode).  Shorter TTL for agility.
   a4k2f9._mcp._bandaid 600 IN SVCB 1 svc-a4k2f9.example.net. \
   alpn="h2,h3" \ port=443 \ ipv4hint=192.0.2.5 \ ipv6hint=2001:db8::5 \
   mandatory=alpn,port

   ; (Optional) Another service face for the same agent (A2A)
   a4k2f9._a2a._bandaid 600 IN SVCB 1 svc-a4k2f9.example.net. \
   alpn="h2" port=8443 \ mandatory=alpn,port

   ; (Optional) HTTPS RR at apex for web-style consumers of BANDAID
   metadata @ 900 IN HTTPS 1 web-gw.example.net. \ alpn="h2,h3" port=443

   ; -------------------------------------------------------------------
   --- ; Capability / policy signaling via SVCB custom keys
   (experimental) ; Use numeric keyNNNNN until you register IANA
   SvcParamKeys. ; Gate client requirements with "mandatory". ; --------
   -------------------------------------------------------------- ;
   Example: reference a capability descriptor and advertise supported
   app protocols. ; NOTE: Values and key numbers are illustrative.

   a4k2f9._mcp._bandaid 600 IN SVCB 1 svc-a4k2f9.example.net. \
   alpn="h2,h3" port=443 \ mandatory=alpn,port,key65001,key65010 \
   key65001="cap=urn:cap:example:mcp:invoice.v1" \
   key65010="bap=a2a/1,mcp/1"

   ; -------------------------------------------------------------------
   --- ; Domain Control Validation (DCV) for BANDAID authorization ;
   Publish a short-lived token to prove control over example.org. ;
   Remove after successful validation.  Resolver MUST DNSSEC-validate. ;
   ---------------------------------------------------------------------
   - _bandaid-challenge 300 IN TXT "bnd-req=svc:crm-
   sync@vendor.example;nonce=3Qz6l8pA;exp=2025-09-19T06:00:00Z"

   ; -------------------------------------------------------------------
   --- ; Optional DANE TLSA for the service endpoint used above. ;
   Owner: _<port>._tcp.<endpoint-FQDN> ; Usage 3 (DANE-EE), Selector 1
   (SPKI), Match 1 (SHA-256) ; Replace the hash with the actual SPKI
   hash of the leaf certificate. ; -------------------------------------
   --------------------------------- _443._tcp.svc-a4k2f9.example.net.
   1800 IN TLSA 3 1 1 (
   0123456789ABCDEF0123456789ABCDEF0123456789ABCDEF0123456789AB )



Mozley, et al.            Expires 19 April 2026                [Page 30]

Internet-Draft                   BANDAID                    October 2025


   ; -------------------------------------------------------------------
   --- ; (Optional) Address records for the service endpoint, if hosted
   in-zone ; If hosted out-of-zone (example.net), these will live there
   instead. ; ----------------------------------------------------------
   ------------ svc-a4k2f9 900 IN A 192.0.2.5 svc-a4k2f9 900 IN AAAA
   2001:db8::5 web-gw 900 IN A 192.0.2.80 web-gw 900 IN AAAA
   2001:db8::80 ```

4.3.5.1.  How to use this zonefile

   *  Adjust TTLs for agility vs. cache efficiency.  Use longer TTLs on
      indirection (aliases), shorter TTLs on volatile leaves and DCV.
      This aligns with DNS caching behavior and negative caching rules
      [RFC2308].

   *  Follow SVCB/HTTPS semantics.  Clients must honor SvcPriority,
      AliasMode (priority 0), and ServiceMode parameters, including
      mandatory, alpn, port, and address hints per [RFC9460].

   *  DCV token flow.  Issue a time-bounded token at _bandaid-
      challenge.domain and require DNSSEC-validated retrieval (pattern
      analogous to ACME’s DNS-01 in [RFC8555]).  Remove on success.

   *  Bind transport to DNS with DANE (optional).  If your relying
      parties validate DNSSEC, publish TLSA to bind the endpoint’s cert/
      key, using the operational guidance in [RFC7671] (TLSA record
      format in [RFC6698]).

   *  Sign the zone.  This file is pre-signing.  Sign with DNSSEC
      (DNSKEY/DS/RRSIG, etc.) before deployment; validators must treat
      unsigned/bogus discovery data as a failure (per your earlier
      spec).  See DNSSEC core specs [RFC4033], [RFC4034], [RFC4035] and
      operational guidance.

4.3.5.2.  Why these records

   *  SVCB/HTTPS concentrate connection metadata and allow aliasing at
      apex and service labels, reducing round trips and enabling
      policy-gated params via mandatory.

   *  Per-service, per-agent leaves avoid oversized RRsets and allow
      parallel administration/sharding while keeping alias names stable.
      This follows performance guidance in SVCB and your BANDAID perf
      section.

   *  DCV via TXT mirrors a well-understood, automated control-proof
      pattern [RFC8555] that fits BANDAID authorization workflows.




Mozley, et al.            Expires 19 April 2026                [Page 31]

Internet-Draft                   BANDAID                    October 2025


   *  DANE TLSA optionally removes reliance on external PKI anchors for
      endpoint auth where DNSSEC is deployed [RFC6698], with deployment
      rules in [RFC7671].

5.  Conclusion

   The discovery of AI agents at Internet scale introduces requirements
   for autonomy, security, resilience, and interoperability that cannot
   be met by ad-hoc or centralized mechanisms.  Organizations must
   advertise capabilities in a manner that is globally unique,
   cryptographically verifiable, and operationally scalable, while
   preserving compliance with regulatory and sovereignty constraints.
   The solution space must account for dynamic lifecycles, selective
   disclosure, and the ability to integrate with existing infrastructure
   without introducing new trust anchors or governance choke points.

   This document defines BANDAID as a DNS-based discovery framework that
   leverages the global DNS namespace, DNSSEC for integrity and
   authenticity, and SVCB/HTTPS records for structured capability
   advertisement.  By building on widely deployed protocols and
   operational practices, BANDAID provides a predictable entry point for
   agent discovery, supports hierarchical delegation for organizational
   autonomy, and enables secure, low-latency resolution at scale.
   Extensions such as custom SvcParams, DNS-based domain control
   validation, and optional DANE bindings further strengthen trust and
   interoperability.

   Future work includes standardizing capability schemas, formalizing
   SvcParam registries for BANDAID metadata, and defining
   privacy-preserving query mechanisms (like authoritative DOT/H/Q).  By
   aligning with existing Internet standards and operational best
   practices, BANDAID offers a path to interoperable, secure, and
   resilient AI agent discovery without reinventing the foundational
   layers of the Internet.

5.1.  Future Work & Unaddressed Portions

   Index versus agents publishing their updates, etc.  Unresolved in the
   use case of it being better to have an index which is a list of all
   agents an org owns, or allow records within the zone to be the record
   of truth.

   For example, a company may only have a few external agents available
   for use, and if the IETF standardizes 'types' of AI agents, then
   perhaps _chat._ai.domain.com or _img2txt._ai.domain.com etc are all
   different SVCB records.





Mozley, et al.            Expires 19 April 2026                [Page 32]

Internet-Draft                   BANDAID                    October 2025


6.  Security Considerations

   To add: Lookalikes, takedowns, misbehaving agents, compliance,
   privacy

7.  IANA Considerations

   IANA are to consider registering an underscored attribute leaf as
   part of [RFC8552] for BANDAID.

   IANA are to consider designating custom key-value pairs for SVCB
   parameters to facilitate agent-to-agent application discovery,
   potentially for cost optimization (token input counts, costs per
   token bundle, etc.)

8.  References

8.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/rfc/rfc2119>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

8.2.  Informative References

   [I-D.draft-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-00, 15
              October 2025, <https://datatracker.ietf.org/doc/html/
              draft-mozley-aidiscovery-00>.

   [I-D.draft-rosenberg-ai-protocols]
              Rosenberg, J. and C. F. Jennings, "Framework, Use Cases
              and Requirements for AI Agent Protocols", Work in
              Progress, Internet-Draft, draft-rosenberg-ai-protocols-00,
              5 May 2025, <https://datatracker.ietf.org/doc/html/draft-
              rosenberg-ai-protocols-00>.

   [RFC1035]  Mockapetris, P., "Domain names - implementation and
              specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
              November 1987, <https://www.rfc-editor.org/rfc/rfc1035>.




Mozley, et al.            Expires 19 April 2026                [Page 33]

Internet-Draft                   BANDAID                    October 2025


   [RFC1996]  Vixie, P., "A Mechanism for Prompt Notification of Zone
              Changes (DNS NOTIFY)", RFC 1996, DOI 10.17487/RFC1996,
              August 1996, <https://www.rfc-editor.org/rfc/rfc1996>.

   [RFC2308]  Andrews, M., "Negative Caching of DNS Queries (DNS
              NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
              <https://www.rfc-editor.org/rfc/rfc2308>.

   [RFC2782]  Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
              specifying the location of services (DNS SRV)", RFC 2782,
              DOI 10.17487/RFC2782, February 2000,
              <https://www.rfc-editor.org/rfc/rfc2782>.

   [RFC2845]  Vixie, P., Gudmundsson, O., Eastlake 3rd, D., and B.
              Wellington, "Secret Key Transaction Authentication for DNS
              (TSIG)", RFC 2845, DOI 10.17487/RFC2845, May 2000,
              <https://www.rfc-editor.org/rfc/rfc2845>.

   [RFC4033]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "DNS Security Introduction and Requirements",
              RFC 4033, DOI 10.17487/RFC4033, March 2005,
              <https://www.rfc-editor.org/rfc/rfc4033>.

   [RFC4034]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Resource Records for the DNS Security Extensions",
              RFC 4034, DOI 10.17487/RFC4034, March 2005,
              <https://www.rfc-editor.org/rfc/rfc4034>.

   [RFC4035]  Arends, R., Austein, R., Larson, M., Massey, D., and S.
              Rose, "Protocol Modifications for the DNS Security
              Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
              <https://www.rfc-editor.org/rfc/rfc4035>.

   [RFC4509]  Hardaker, W., "Use of SHA-256 in DNSSEC Delegation Signer
              (DS) Resource Records (RRs)", RFC 4509,
              DOI 10.17487/RFC4509, May 2006,
              <https://www.rfc-editor.org/rfc/rfc4509>.

   [RFC5155]  Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS
              Security (DNSSEC) Hashed Authenticated Denial of
              Existence", RFC 5155, DOI 10.17487/RFC5155, March 2008,
              <https://www.rfc-editor.org/rfc/rfc5155>.

   [RFC5936]  Lewis, E. and A. Hoenes, Ed., "DNS Zone Transfer Protocol
              (AXFR)", RFC 5936, DOI 10.17487/RFC5936, June 2010,
              <https://www.rfc-editor.org/rfc/rfc5936>.





Mozley, et al.            Expires 19 April 2026                [Page 34]

Internet-Draft                   BANDAID                    October 2025


   [RFC6605]  Hoffman, P. and W.C.A. Wijngaards, "Elliptic Curve Digital
              Signature Algorithm (DSA) for DNSSEC", RFC 6605,
              DOI 10.17487/RFC6605, April 2012,
              <https://www.rfc-editor.org/rfc/rfc6605>.

   [RFC6698]  Hoffman, P. and J. Schlyter, "The DNS-Based Authentication
              of Named Entities (DANE) Transport Layer Security (TLS)
              Protocol: TLSA", RFC 6698, DOI 10.17487/RFC6698, August
              2012, <https://www.rfc-editor.org/rfc/rfc6698>.

   [RFC6763]  Cheshire, S. and M. Krochmal, "DNS-Based Service
              Discovery", RFC 6763, DOI 10.17487/RFC6763, February 2013,
              <https://www.rfc-editor.org/rfc/rfc6763>.

   [RFC6781]  Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC
              Operational Practices, Version 2", RFC 6781,
              DOI 10.17487/RFC6781, December 2012,
              <https://www.rfc-editor.org/rfc/rfc6781>.

   [RFC6891]  Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms
              for DNS (EDNS(0))", STD 75, RFC 6891,
              DOI 10.17487/RFC6891, April 2013,
              <https://www.rfc-editor.org/rfc/rfc6891>.

   [RFC7344]  Kumari, W., Gudmundsson, O., and G. Barwood, "Automating
              DNSSEC Delegation Trust Maintenance", RFC 7344,
              DOI 10.17487/RFC7344, September 2014,
              <https://www.rfc-editor.org/rfc/rfc7344>.

   [RFC7553]  Faltstrom, P. and O. Kolkman, "The Uniform Resource
              Identifier (URI) DNS Resource Record", RFC 7553,
              DOI 10.17487/RFC7553, June 2015,
              <https://www.rfc-editor.org/rfc/rfc7553>.

   [RFC7671]  Dukhovni, V. and W. Hardaker, "The DNS-Based
              Authentication of Named Entities (DANE) Protocol: Updates
              and Operational Guidance", RFC 7671, DOI 10.17487/RFC7671,
              October 2015, <https://www.rfc-editor.org/rfc/rfc7671>.

   [RFC7766]  Dickinson, J., Dickinson, S., Bellis, R., Mankin, A., and
              D. Wessels, "DNS Transport over TCP - Implementation
              Requirements", RFC 7766, DOI 10.17487/RFC7766, March 2016,
              <https://www.rfc-editor.org/rfc/rfc7766>.

   [RFC7873]  Eastlake 3rd, D. and M. Andrews, "Domain Name System (DNS)
              Cookies", RFC 7873, DOI 10.17487/RFC7873, May 2016,
              <https://www.rfc-editor.org/rfc/rfc7873>.




Mozley, et al.            Expires 19 April 2026                [Page 35]

Internet-Draft                   BANDAID                    October 2025


   [RFC8078]  Gudmundsson, O. and P. Wouters, "Managing DS Records from
              the Parent via CDS/CDNSKEY", RFC 8078,
              DOI 10.17487/RFC8078, March 2017,
              <https://www.rfc-editor.org/rfc/rfc8078>.

   [RFC8080]  Sury, O. and R. Edmonds, "Edwards-Curve Digital Security
              Algorithm (EdDSA) for DNSSEC", RFC 8080,
              DOI 10.17487/RFC8080, February 2017,
              <https://www.rfc-editor.org/rfc/rfc8080>.

   [RFC8198]  Fujiwara, K., Kato, A., and W. Kumari, "Aggressive Use of
              DNSSEC-Validated Cache", RFC 8198, DOI 10.17487/RFC8198,
              July 2017, <https://www.rfc-editor.org/rfc/rfc8198>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/rfc/rfc8446>.

   [RFC8552]  Crocker, D., "Scoped Interpretation of DNS Resource
              Records through "Underscored" Naming of Attribute Leaves",
              BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
              <https://www.rfc-editor.org/rfc/rfc8552>.

   [RFC8555]  Barnes, R., Hoffman-Andrews, J., McCarney, D., and J.
              Kasten, "Automatic Certificate Management Environment
              (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019,
              <https://www.rfc-editor.org/rfc/rfc8555>.

   [RFC8624]  Wouters, P. and O. Sury, "Algorithm Implementation
              Requirements and Usage Guidance for DNSSEC", RFC 8624,
              DOI 10.17487/RFC8624, June 2019,
              <https://www.rfc-editor.org/rfc/rfc8624>.

   [RFC8767]  Lawrence, D., Kumari, W., and P. Sood, "Serving Stale Data
              to Improve DNS Resiliency", RFC 8767,
              DOI 10.17487/RFC8767, March 2020,
              <https://www.rfc-editor.org/rfc/rfc8767>.

   [RFC8806]  Kumari, W. and P. Hoffman, "Running a Root Server Local to
              a Resolver", RFC 8806, DOI 10.17487/RFC8806, June 2020,
              <https://www.rfc-editor.org/rfc/rfc8806>.

   [RFC8976]  Wessels, D., Barber, P., Weinberg, M., Kumari, W., and W.
              Hardaker, "Message Digest for DNS Zones", RFC 8976,
              DOI 10.17487/RFC8976, February 2021,
              <https://www.rfc-editor.org/rfc/rfc8976>.





Mozley, et al.            Expires 19 April 2026                [Page 36]

Internet-Draft                   BANDAID                    October 2025


   [RFC9018]  Sury, O., Toorop, W., Eastlake 3rd, D., and M. Andrews,
              "Interoperable Domain Name System (DNS) Server Cookies",
              RFC 9018, DOI 10.17487/RFC9018, April 2021,
              <https://www.rfc-editor.org/rfc/rfc9018>.

   [RFC9460]  Schwartz, B., Bishop, M., and E. Nygren, "Service Binding
              and Parameter Specification via the DNS (SVCB and HTTPS
              Resource Records)", RFC 9460, DOI 10.17487/RFC9460,
              November 2023, <https://www.rfc-editor.org/rfc/rfc9460>.

   [RFC9462]  Pauly, T., Kinnear, E., Wood, C. A., McManus, P., and T.
              Jensen, "Discovery of Designated Resolvers", RFC 9462,
              DOI 10.17487/RFC9462, November 2023,
              <https://www.rfc-editor.org/rfc/rfc9462>.

   [RFC9463]  Boucadair, M., Ed., Reddy.K, T., Ed., Wing, D., Cook, N.,
              and T. Jensen, "DHCP and Router Advertisement Options for
              the Discovery of Network-designated Resolvers (DNR)",
              RFC 9463, DOI 10.17487/RFC9463, November 2023,
              <https://www.rfc-editor.org/rfc/rfc9463>.

Acknowledgments

   The authors thank Ross Gibson for his contributions, questions and
   comments.

Authors' Addresses

   Jim Mozley
   Infoblox, Inc.
   Email: jmozley@infoblox.com


   Nic Williams
   Infoblox, Inc.
   Email: nic@infoblox.com


   Behcet Sarikaya
   Unaffiliated
   Email: sarikaya@ieee.org


   Roland Schott
   Deutsche Telecom
   Email: roland.schott@telekom.de





Mozley, et al.            Expires 19 April 2026                [Page 37]


name: draft-rosenberg-aiproto
rev: 00
title: Normalized API for AI Agents Calling Tools (N-ACT)
time: 2025-10-20T01:54:27Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T01:54:27Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Data formats/interop", "Agent discovery/reg"]
tags: []
fetched_at: 2026-02-27T22:56:05.127698+00:00
abstract:
This document defines a protocol that facilitates integration of
   tools into the design and run-time operations of AI Agents.  The
   focus is on enterprise AI agents that need to make use of APIs
   exposed by third party providers.  This protocol, called the
   Normalized API for AI Agents Calling Tools (N-ACT) - pronounced like
   "enact" - defines an OpenAI spec that has two principle features -
   enumeration of tools and invocation of tools.  The enumeration API
   enables a human - the AI Agent designer employed by the enterprise -
   to select and include tools from third-party vendors into operating
   procedures (also known as skills or instructions) which direct the
   behavior of AI Agents, including how and when to invoke those tools.
   The enumeration API can also be used (optionally) at run-time for the
   LLM to obtain tool descriptions.  The second feature of the API -
   invocation - allows the AI Agent executor to perform the inter-domain
   invocation of the tool at run time.  By standardizing these two API
   functions, the time and cost of integration of Internet APIs into AI
   Agents can be reduced.

full_text:
Network Working Group                                       J. Rosenberg
Internet-Draft                                                     Five9
Intended status: Informational                                  P. White
Expires: 22 April 2026                                           Bitwave
                                                         19 October 2025


           Normalized API for AI Agents Calling Tools (N-ACT)
                       draft-rosenberg-aiproto-00

Abstract

   This document defines a protocol that facilitates integration of
   tools into the design and run-time operations of AI Agents.  The
   focus is on enterprise AI agents that need to make use of APIs
   exposed by third party providers.  This protocol, called the
   Normalized API for AI Agents Calling Tools (N-ACT) - pronounced like
   "enact" - defines an OpenAI spec that has two principle features -
   enumeration of tools and invocation of tools.  The enumeration API
   enables a human - the AI Agent designer employed by the enterprise -
   to select and include tools from third-party vendors into operating
   procedures (also known as skills or instructions) which direct the
   behavior of AI Agents, including how and when to invoke those tools.
   The enumeration API can also be used (optionally) at run-time for the
   LLM to obtain tool descriptions.  The second feature of the API -
   invocation - allows the AI Agent executor to perform the inter-domain
   invocation of the tool at run time.  By standardizing these two API
   functions, the time and cost of integration of Internet APIs into AI
   Agents can be reduced.

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 22 April 2026.





Rosenberg & White         Expires 22 April 2026                 [Page 1]

Internet-Draft                    N-ACT                     October 2025


Copyright Notice

   Copyright (c) 2025 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.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   9
     3.1.  Tool Curation . . . . . . . . . . . . . . . . . . . . . .   9
       3.1.1.  Tool Sculpting  . . . . . . . . . . . . . . . . . . .   9
   4.  The N-ACT Protocol Goals  . . . . . . . . . . . . . . . . . .  11
   5.  Overview of Operation . . . . . . . . . . . . . . . . . . . .  12
     5.1.  Tool Signatures . . . . . . . . . . . . . . . . . . . . .  12
     5.2.  Enumeration Endpoint  . . . . . . . . . . . . . . . . . .  13
     5.3.  Invocation Endpoint . . . . . . . . . . . . . . . . . . .  14
     5.4.  Versioning  . . . . . . . . . . . . . . . . . . . . . . .  15
   6.  Protocol Details  . . . . . . . . . . . . . . . . . . . . . .  15
     6.1.  Enumeration API . . . . . . . . . . . . . . . . . . . . .  15
     6.2.  Details for a Specific tool . . . . . . . . . . . . . . .  19
     6.3.  Tool Version Retrieval  . . . . . . . . . . . . . . . . .  19
     6.4.  Pagination  . . . . . . . . . . . . . . . . . . . . . . .  19
   7.  Invocation API  . . . . . . . . . . . . . . . . . . . . . . .  20
     7.1.  OpenAPI Specification . . . . . . . . . . . . . . . . . .  21
   8.  Relationship to MCP . . . . . . . . . . . . . . . . . . . . .  21
     8.1.  Similarities  . . . . . . . . . . . . . . . . . . . . . .  21
     8.2.  Differences . . . . . . . . . . . . . . . . . . . . . . .  21
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Background

   AI Agents are applications built using Large Language Models (LLMs).
   AI Agents typically operate on behalf of some human or organization,
   and are capable of taking actions through the invocation of
   functions, also known as tools.  [I-D.rosenberg-ai-protocols]
   provides an overview of protocols and use cases for AI Agents.




Rosenberg & White         Expires 22 April 2026                 [Page 2]

Internet-Draft                    N-ACT                     October 2025


   In enterprise applications of AI Agents - including customer support
   uses cases - it is very common for the AI Agent to invoke tools
   provided by other organizations.  As an example, consider an
   enterprise that is a healthcare provider.  They have an AI Agent that
   needs to facilitate appointment scheduling, appointment cancellation,
   prescription refills, store location and hours lookup, and vaccine
   scheduling.  The actions are all supported by tools which are exposed
   to the AI Agent through its instructions.  The tools, in this case,
   could be implemented by servers within the enterprise domain - built
   by their IT department for example.  Or, they might be implemented by
   B2B SaaS providers that offer these capabilities to the entperrise.
   For example, in the healthcare space, Epic, Cerner, and Meditech are
   a few of the B2B SaaS providers that are often used by retail
   healthcare providers.

   It is very common for enterprises to have dozens, if not hundreds, of
   different systems providing APIs that might need to be accessed by an
   AI Agent.  This high cardinality is not new.  Prior to the advent of
   large language model technologies, voice and chat bots - and even
   classic "press 1 for sales, and 2 for support" Interactive Voice
   Response Systems (IVR) - needed to access large numbers of APIs to
   provide customer support for end users.  Integration of these APIs
   into IVRs, voice bots and chat bots often represented the most
   expensive and complex part of deploying those systems - not the
   training and optimization of the AI model which invokes them.

   The advent of AI Agents - if anything - only increases the likely
   cardinality of the number of distinct API sysems that need to be
   integrated.  This is due to increased capabilities of LLMs compared
   to prior generation AI models.  Whereas, in the past, certain use
   cases where just too difficult to automate (for example, multi-room
   booking for hotels - is difficult to do on websites, and almost never
   attempted by voice or chat bots) - now, these may be within reach for
   automation using AI Agent technology.  As a result, we will see more
   use cases, and therefore even more APIs that need to be integrated.

   For an AI agent to be effective, it needs more direction than just
   the enumeration of tools with names and descriptions.  Particularly
   in enterprise and customer support use cases, detailed instructions
   are required which direct when, how, if and why those tools should be
   invoked.  These instructions guide the AI agent on how to converse
   with the customer, what kind of information to collect, how to use it
   to invoke the tools, how to handle the differing responses, and what
   to do with the data that is returned.  We use the term operating
   procedure to describe an instruction that provides this detail to an
   AI Agent.  An operating procedure is typically specific to a
   particular task (for example, booking an appointment for a healthcare
   visit).  An operating procedure at the end of the day is a document,



Rosenberg & White         Expires 22 April 2026                 [Page 3]

Internet-Draft                    N-ACT                     October 2025


   containing natural language text with references to tools, tool
   inputs, and tool outputs.  Others have referred to these as skills
   (see the recent Anthropic blog post here:
   https://www.anthropic.com/engineering/equipping-agents-for-the-real-
   world-with-agent-skills (https://www.anthropic.com/engineering/
   equipping-agents-for-the-real-world-with-agent-skills)), instructions
   or even prompts.

   Here is an abbreviated example of an operating procedure for
   prescription refill that illustrates this:

   ##Goal

   Your goal is to help the user with prescription refill inquiries.

   ## Prescription Refill Status
   Follow this flow if the user: 
   - is asking about the status of a prescription
    refill request they've made;
   - is asking when their prescription refill(s)
     will be ready. For example:
   - What's the status of my prescription request?
   - I just want an update regarding my prescriptions.
   - When will my prescription refill be ready?
   ### Prescription Lookup
   - Use look_up_prescriptions() to look up the user's
     active prescriptions. You must have previously
     authenticated the user and have their account ID.
     If you don't have their accountID yet, perform the
     authentication flow.
   ### Present Status
   - Find the prescriptions which have a status other
     than null and present them to the user along with
     their status.
   ### Sending Confirmation
   - Ask the user if they want to receive a confirmation
     when the refill has been sent to the pharmacy.
   - If you have the user's preferred contact method
    (which the you would have gotten earlier from
     look_up_ani_user_by_ani(), use that information
     and send them the confirmation of the appointment
     status along with the appointment details.

                   Figure 1: Example Operating Procedure

   As you can see from the example, the operating procedure is a
   detailed recipe-book - a training manual of sorts - for the AI Agent.
   It describes API sequencing (for example, that the lookup of



Rosenberg & White         Expires 22 April 2026                 [Page 4]

Internet-Draft                    N-ACT                     October 2025


   prescriptions can only be done after authentication), usage of
   parameters (that accountID must be included from prior
   authentication), handling of results (show the list to the user), and
   so on.

   Operating procedures are analagous to training manuals for human
   agents, which similarly instruct them in the sequencing and handling
   of a call.  Instead of invoking tools, humans use web applications to
   do a similar job.  In traditional contact centers, entire teams of
   people are accountable for creating and maintaining these training
   manuals.  They are essential for ensuring quality of customer
   support.

   At the end of the day - operating procedures are what make the AI
   Agent work.  While their generation may be assisted by an AI to
   facilitate authoring, operating procedures are crafted by human
   beings using traditional software.  The person whose role is to
   create the operating procedure is called the AI Agent designer - or
   just designer for short.  The software used by the designer to create
   an AI Agent, including the authoring of the operating procedure, is
   called the AI Agent platform.  To properly create an operating
   procedure, the designer must be a domain expert - familiar with the
   appropriate process for performing the task the AI Agent is to
   perform.

   Part of task of creating an AI Agent is the selection of the tools to
   be used.  Typically, this selection happens through the authoring of
   the operating procedure, which makes explicit reference to the tool
   as in the example above.  It is also possible for the designer to
   select a tool for usage by the AI Agent but not provide any guidance
   on its usage in the operating procedure (most of the current APIs for
   AI Agents separate the tool list from the instruction, thus making
   this possible).  While technically this can work, it often results in
   higher rates of hallucinated tool usage.

   The choice by a designer on the set of tools that are shown to the
   LLM (we use the verb show as a synonym for inclusion of information
   into the model's context window) is referred to as tool selection.
   The process of tool selection and authorship of the operating
   procedures happen ahead of the deployment and actual usage of the AI
   Agent.  We refer to this as design time, whereas the usage of the AI
   Agent by end users is called run time.

   At run time, a user will begin a session with an AI Agent.  At the
   beginning of the session, the AI Agent is shown the operating
   procedure and tools, and begins operation.





Rosenberg & White         Expires 22 April 2026                 [Page 5]

Internet-Draft                    N-ACT                     October 2025


   It is becoming increasingly common for AI Agent design systems to
   make use of multiple distinct AI Agents (called sub-agents) which are
   each equipped to handle specific tasks.  These are called multi-agent
   systems.  Once again using our health care example, one sub-agent
   might handle prescription refills, while another handles appointment
   scheduling and cancellation.  Each sub-agent would have its own
   distinct set of operating procedures and tools, appropriate for those
   tasks.  This further reduces the size of the context window at any
   point in time, reducing hallucination rates.  There are various
   techniques for how these sub-agents are strung together.  At the end
   of the day, it is often done through tool calling, asking the LLM to
   invoke a tool that transfers the session to a different AI Agent.
   This is (interestingly) analagous to live human agents in contact
   centers, which typically have human agents with differing skills.
   When a customer asks for something which is outside of the expertise
   for the human agent they are talking to, the human agent transfers
   the call to a different human agent with the right skill.  In essence
   - that is what is happening in these multi-agent systems.

   The usage of a designer to select only those tools needed for an
   agent, and the usage of multi-agent systems, provides progressive
   tool disclosure.  Progressive tool disclosure is a concept wherein an
   AI Agent is only shown just the set of tools it needs at a given
   time, and as the conversation flows, more tools are shown.

   The tools selected by the designer, and incorporated into the
   operating procedure, are often implemented by the executor through
   the invocation of APIs on some server.  The server exposing those
   APIs is called an API Server.

2.  Terminology

   Terminology is becoming foundationally important in this emerging AI
   Agent field.  This section summarizes the key terminology and
   concepts from above.

   *  AI Agent: A software application that makes use of an LLM to
      perform tasks that require interaction with software systems.
      With an AI Agent, the LLM can output both text for the user, but
      it can also request the invocation of tools, which are an
      interface the LLM can use to access those software systems.  AI
      Agents are composed of two elements: an LLM and an executor.  The
      executor is built using traditional software (e.g., Java, node.js,
      python, etc) and interfaces with the LLM.

   *  Tool: An interface representing a software system.  A tool has a
      name, a description, inputs and outputs.  In AI Agent system, the
      LLM is responsible for collecting the inputs and requesting the



Rosenberg & White         Expires 22 April 2026                 [Page 6]

Internet-Draft                    N-ACT                     October 2025


      invocation of the tool.  The executor actually executes the tool,
      often through the invocation of APIs, and feeds the results back
      to the LLM.  By convention, tool names use underscores and have a
      terminating curly bracket, even though they may also take
      parameters.  For example, when we say "the LLM invokes
      schedule_appointment()" this means that the LLM has made a
      decision to invoke the tool name schedule_appointment and has
      synthesized the needed input parameters to the tool

   *  Executor: Also called the orchestrator or orchestration engine.
      It represents the traditional software component of an AI Agent.
      The executor funnels messages to and from the end user into the
      LLM.  It receives the outputs of the LLM, and if that output is a
      request to perform a tool call, the executor runs the tool and
      provides its output back to the LLM.

   *  Show: The process wherein the executor provides input to the LLM,
      inclusive of tool call results, by adding it to the context window
      of the LLM.  For example, we say, "the tool call result is shown
      to the LLM'.

   *  Operating Procedure: A document authored by a human, and shown to
      an LLM during run-time operation, which instructs the AI Agent on
      the sequence of tools to invoke, how to interact with the user to
      collect the data needed for tool invocation, what to do with the
      results of the tool call, how to handle different conditions based
      on the output of the tools, and how to handle exceptional
      conditions.  Operating procedures reference tools and their inputs
      by name.

   *  AI Agent Designer: Synonymous with designer

   *  Designer: A human being whose job is to create operating
      procedures and perform tool selection during the design phase of
      the AI Agent.

   *  Tool Selection: The process of selection of the right set of tools
      to show to an AI Agent for a particular task.  By selecting only
      those tools which are needed for a task, the likelihood of tool
      hallucination is reduced.  Tool selection in the N-ACT framework
      happens at design time (though the protocol allows this to happen
      at run time in an interoperable fashion, should that mode be
      selected by the AI Agent platform vendor).

   *  Design Time: A point in time during which the designer is
      interacting with the AI Agent platform in the producion of an
      operating procedure and selection of tools.




Rosenberg & White         Expires 22 April 2026                 [Page 7]

Internet-Draft                    N-ACT                     October 2025


   *  Enterprise: The administrative entity on whose behalf an AI Agent
      operates.  Typically the designer is an employee of the
      enterprise, though this can be outsourced to consulting firms or
      the AI Agent Platform vendor.

   *  Run Time: A point in time during which an end user is interacting
      with an AI Agent.

   *  Multi-Agent Systems: An AI Agent wherein its job is broken down
      into a smaller set of discrete tasks, each handled by a sub-agent
      that is equipped (via its operating procedure and tool list) to
      perform that specific task

   *  Sub-Agent: An AI Agent that performs a narrow set of tasks.
      Multiple Sub-Agents are woven together to form the AI Agent in a
      Multi-Agent System.

   *  Progressive Tool Disclosure: A technique for reduction of
      hallucination wherein, as an AI Agent session unfolds, the set of
      tools shown to the LLM evolves, offering it only the tools it
      needs to do its job at any point in time.

   *  API Server: A server that exposes APIs which can be invoked via a
      tool call by the AI Agent

   *  API Provider: The administrative entity that is offering APIs that
      are of interest to an AI Agent.  Typically, the API Provider is
      different from the enterprise, and is also different in turn from
      the AI Agent Platorm vendor.

   *  AI Agent Session: A period of time from when an AI agent begins -
      by having the executor show the LLM the initial operating
      procedure and tool selection - estabishing initial context - and
      interacting with the end user - until the end user interaction
      completes.

   *  AI Agent Platform: A piece of software which includes a design
      time experience for designers, and a run-time capability for
      handling AI Agent sessions.  Typically built as a cloud service by
      the AI Agent Platform vendor.  Though the AI Agent Platform can be
      provided by the vendor of the LLM itself, these can be distinct
      vendors.

   *  AI Agent Platgorm Vendor: The administrative entity that has
      developed the AI Agent Platform, and made it available for usage
      by enterprises to author and execute AI Agents.





Rosenberg & White         Expires 22 April 2026                 [Page 8]

Internet-Draft                    N-ACT                     October 2025


3.  Problem Statement

   There are multiple problems that are addressed by N-ACT, covering
   design time and run-time challenges.

3.1.  Tool Curation

   At design time, the AI Agent platform needs to enable the designer to
   author the operating procedure and, as a result, select the tools
   that will be made available to the AI Agent (or the sub-agent).  To
   do this, the designer needs to know what the available tools are,
   from which they can select.  In essence, the designer is performing a
   curation task, choosing amongst a large inventory of tools available
   from many possible API servers.  Most often, the enterprise deploying
   the AI Agent, is different from the vendor of the AI Agent platform,
   which is different still from the vendors of the API servers.

   As a result, the designer needs to know the API surface area of the
   various vendors of API servers, and know which API to select and use.
   Sometimes, API Servers offer OpenAPI specifications for their APIs,
   but these are tailored for usage with software developers, not
   consumption by AI Agent designers, and certainly not by LLMs.
   Consequently, they lack the required natural language descriptions to
   aid in the curation process by the designer.  Designers need to spend
   time researching and studying APIs, learning what they do, and
   determining whether the right APIs exist, and if so, what they are.
   They have to determine whether the API can be used as is, or whether
   changes are needed to make the API more easily (and reliably)
   consumeable for the automation.  This process is historically long
   and tedious, and is exacerbated by the fact that the APIs are spread
   across dozens of API servers from the many vendors used by a
   particular enterprise.

   The lengthy time required for API integration is one of the most
   significant parts of the time required to build automation solutions
   (including AI Agents) within enterprises.

3.1.1.  Tool Sculpting

   Oftentimes existing APIs on API servers - usually REST these days -
   are complex and (clearly) not optimized for usage by an LLM.  They
   have been designed to be consumed by traditional software authored by
   software developers.  Traditional REST API signatures have complex
   inputs - URI parameters, header parameters, and JSON bodies.  They
   also tend to mix programmatic elements and semantic elements.
   Programmatic elements are those parts of the API parameters that are
   meaningful only to the software which is invoking those APIs.  These
   include resource identifiers like UUIDs, trace IDs, URLs, timestamps,



Rosenberg & White         Expires 22 April 2026                 [Page 9]

Internet-Draft                    N-ACT                     October 2025


   meta-data and so on.  Semantic elements are those which are
   ultimately the input from the end user which drove the execution of
   the API.  As an example, when doing something as simple as looking up
   the weather, the city and the date (today or the future) are the
   semantic elements.  But the lookup API might need to provide
   programmatic elements like a weather station ID, which is not
   meaningful to the user request.

   It is also the case that a particular end user request (e.g., give me
   the weather tomorrow in Manhattan), doesn't map to a single API call.
   Instead, a sequence of API calls need to be orhcestrated together to
   actually provide this simple ask.  As an example, the APIs at the US
   National Weather service provide weather forecasting based on grids
   of 2.5km to 2.5km.  Consequently, to provide the weather for
   Manhattan, the location must be first mapped to a coordinate, and
   then the coordinates fed into the forecast API.

   There are two ways these problems are solved today.

   A simple way to solve these problems is to just let the LLM figure it
   out.  A naive implementation would - in essence, use the existing
   OpenAPI specs for an API as a tool, and request the LLM to synthesize
   inputs, process outputs, and chain API calls together.  While this is
   possible - and indeed works for simple use cases - it introduces
   hallucination risk.  It also complicates the design process,
   requiring the designer to understand the details of these APIs.  The
   designer must - via the operating procedure - direct the AI Agent on
   how to use the APIs and navigate them.

   This approach has many problems.  First, it increases the time
   required to author the operating procedure, since it must now include
   the manually generated instructions on how to use the APIs.  Second -
   and most importantly - it increases hallucination risk.  The larger
   the gap between how the API works, and what the semantically
   meaningful operation is - the larger the surface area for mistakes by
   the LLM.

   The lesson is - never ask an LLM to do what a normal piece of
   software can do better.

   And thus, the second way this is solved today is through the
   development of automation ontop of existing APIs.  Again using the US
   National weather service example, a piece of traditional software can
   be written which exposes an API called lookup_weather_by_city.  This
   API would, under the hood, first convert the city to geo-coordinates,
   and then lookup the weather for those coordinates.  The resulting
   simplified API can then be shown to the LLM as a tool.




Rosenberg & White         Expires 22 April 2026                [Page 10]

Internet-Draft                    N-ACT                     October 2025


   The process of adding a layer of traditional software ontop of
   existing APIs in order to produce ones that more directly map to user
   input, in order to reduce tool call hallucination risk, we call as
   tool sculpting.

   Specifically, tool sculpting is the process of crafting an API which:
   1.  Minimizes the inputs for each tool to only those which are
   semantically meaningful and must be synthesized by an AI Agent 2.
   Minimizes the outputs for each tool to only those which would be
   relevant to an AI Agent 3.  Orchestrates multi-step backend API calls
   so that the AI Agent doesn't need to do it

4.  The N-ACT Protocol Goals

   The N-ACT protocol (N-ACT is pronounced like the word enact)
   addresses the underlying problems of tool curation and tool
   minimization.

   It has, at its core, the following goals:

   *  Reduce the time and costs for designers to create operating
      procedures and perform tool selection by simplifying the process
      of curation

   *  Enable development of AI Agents for enterprises which need access
      to tools across dozens or hundreds of API servers, typically sold
      to the enterprise by third party B2B SaaS vendors, by
      consolidating decision logic on tool selection in the hands of the
      designer

   *  Simplify adoption by tool vendors by building ontop of the
      existing API platforms and APIs they already have.  The closer the
      current API surface area is to the ideal tool set for an AI Agent,
      the less effort is required to implement

   *  Standardize an API signature for tool calling

   *  Tools are just APIs that are optimized for an LLM, but can also be
      used by traditional software applications too

   *  Authentication and Auhtorization use the existing techniques used
      for REST APIs offered by the API Vendor

   *  Reduce hallucination risk through tool sculpting

   *  Separation of responsibility - API vendors perform tool sculpting,
      and the AI Agent designer crafts the operating procedure which
      instructs the AI Agent on how to use the many tools (across



Rosenberg & White         Expires 22 April 2026                [Page 11]

Internet-Draft                    N-ACT                     October 2025


      vendors even) that it can use.  In other words - one vendor makes
      tools which independent of the agent, and the other vendor makes
      agents which make use of those tools.

5.  Overview of Operation

   N-ACT is a web API that defines a pair of REST endpoints - one for
   enumerating tools available on the server, and the other for invoking
   a tool on the server.  Both of these make use of a tool signature,
   which is a standardized interface for what a tool looks like - how to
   describe a tool, and how to invoke it.  The API client is implemented
   by the AI Agent platform, and the rest endpoints are implemented by
   vendor wishing to expose their APIs as N-ACT tools.  It is envisioned
   that these just end up being new REST APIs added to the existing API
   surface area of the API Provider.

5.1.  Tool Signatures

   N-ACT standardizes the signature for tool calling.  A tool can be
   thought of as a Java interface, and the implementation of the tool
   happens over the wire by having the executor take the tool call from
   the LLM and send it to the API server.

   Every tool in N-ACT is comprised of the following descriptive
   signature:

   *  The tool ID
   *  The name of the tool
   *  The description of the tool
   *  The set of input parameters.  For each input parameter:
      -  The name of the input parameter, and whether it is required or
         optional
      -  The type of the input parameter - one of a small set (string,
         int, enum)
      -  The description of the input parameter
      -  Any constraints on the input types
         o  Strings: max length
         o  Int: min and max values
         o  Enum: list of enumerated values that are permitted, along
            with a description of each value.
   *  The output, of which there can be one or more.  Each output is:
      -  The name of the output
      -  A description of the output
      -  The type of the output (string, int, enum, json)

   Invoking a tool requires the following to be provided:

   *  the name of the tool



Rosenberg & White         Expires 22 April 2026                [Page 12]

Internet-Draft                    N-ACT                     October 2025


   *  an input parameter list, which is an array of name/value pairs

   Consequently, the N-ACT protocol defines two JSON objects - the
   signature, and the invocation.  The N-ACT protocol carries these in
   its body.

   The signature ensures that the executor can take the output of the
   LLM, validate it against the signature, and execute it by sending the
   invocation over the wire.  For example, if the LLM synthesizes a tool
   call request with a missing parameter, or with an enum value that is
   not amongst the allowed values, the executor can reject it and ask
   the LLM to try again, or take other error handling logic.

5.2.  Enumeration Endpoint

   The enumeration endpoint - as the name implies - returns a list of
   tools available.  This API endpoint returns an array, each element in
   the array is a signature as noted above.  The API supports tagging
   and versioning, with filtering on those parameters, to facilitate
   design time interactions between the AI Agent platform and the API
   server.

   This API facilitates the following design-time workflow:

   1.  The designer identifies the set of API vendors for which the AI
       Agent should be allowed to operate
   2.  For each such API vendor, the designer configures the AI Agent
       platform with the URI for the N-ACT tool enumeration endpoint.
       This specification suggests a common naming practice of using the
       root API endpoint followed by "tools" (e.g.,
       https://api.weather.gov/tools (https://api.weather.gov/tools)) to
       simplify this when possible.
   3.  The administrator configures the appropriate credentials needed
       for AuthN and AUthZ (typically an OAuth grant flow) - this is not
       any different from any other endpoint from the API provider
   4.  The designer accesses the AI Agent platform, and the platform
       invokes the enumeration API and retrieves the tool signatures for
       all of the tools exposed on the API server for all of the
       configured API providers.  This provides a list of tools to the
       platform.  This list can be viewed, searched, filtering and
       sorted by the designer.  The UI of the design time experience can
       help the designer find and select tools for placement into the
       operating procedure.

   The above steps can be done just once, and then apply to all AI
   Agents subsequently built on the platform.  Alternatively, the
   enumeration APIs can be explored by the AI Agent platform at design
   time, as the designer works.



Rosenberg & White         Expires 22 April 2026                [Page 13]

Internet-Draft                    N-ACT                     October 2025


   Once the designer has selected the tool, the tool signature can be
   retrieved by the AI Agent platform, stored, and then provided to the
   LLM at run-time.  With N-ACT, it is also possible to use the
   enumeration API retrieve a fresh tool signature at run-time, rather
   than use the version retrieved and cached at design time.  There are
   pros and cons to both approaches.  Retrieving and caching the
   signature at design time ensures consistency.  Designers seeking
   greater consistency - wherein testing of the agent performed before
   launch, matches run-time behavior, will prefer to cache the
   descriptions.  Indeed, the usage of caching allows the designer to
   tune and tweak the natural language text in the signature to improve
   accuracy, without dependng on the API vendor to do so.  This
   facilitates the separation of concerns built into the N-ACT protocol
   - that the AI agent designer can control all aspects of the behavior
   of the AI Agent, including the authorship of all natural language
   provided to the AI Agent.  The API vendor provides the tool - which
   is purely programmatic.

   Alternatively, if the AI Agent platform fetches the tool signature
   each time at run time, the latest-and-greatest can be used.  N-ACT
   does not technically prohibit this, allowing this mode to be
   implemented in an interoperable fashion.

   The key to efficacy of tool usage is the tool sculpting, a
   responsibility which sits with the API vendor in the N-ACT protocol.
   The API server must distill down its APIs into a set of tools, each
   of which do targeted, focused tasks.  Tool sculpting has a double
   benefit.  First, it reduces the surface area of information that the
   LLM needs to synthesize to invoke the tool, and reduces the amount it
   needs to comprehend to process its outputs.  Second, it simplifies
   the job of the designer in selection of the tool, and in crafting the
   operating procedure to instruct the LLM on when and how to invoke it.

   N-ACT also provides an API, part of the enumeration endpoint, for
   retrieving the signature for a specific tool.  This is useful for the
   run-time fetching of the signature.

5.3.  Invocation Endpoint

   The invocation endpoint is used by the executor at run-time.

   When the LLM creates a tool request, it provides the tool name and
   input values.  Using the signature, the executor can validate the
   tool call request as being valid for the tool, and then use the wire
   protocol to invoke the tool on the API server.  When the response
   comes, it can then be shown to the LLM.





Rosenberg & White         Expires 22 April 2026                [Page 14]

Internet-Draft                    N-ACT                     October 2025


   The N-ACT invocation endpoint allows versioning, so that a specific
   version of the tool can be used.

5.4.  Versioning

   A common problem historically in the development of voice and chat
   bots - the precursor to modern AI Agents - is that API vendors
   sometimes change APIs, breaking operation of the bot.  This problem
   remains with AI Agents, and N-ACT addresses it by natively adding
   version support.

   The N-ACT protocol requires versioning for tools.  It mandates that
   each version of a tool is backwards compatible.  A new version of a
   tool can only add new optional input parameters, or add new output
   parameters.  To ensure consistent behavior, N-ACT requires API
   servers to allow invocation of a tool against a specific version,
   allowing AI Agent designers to select when to upgrade when new
   versions become available.

6.  Protocol Details

   The following provides a detailed specification of the protocol.

6.1.  Enumeration API

   N-ACT servers MUST implement the enumeration API, which is structured
   as follows:

   GET {platform-root}/tools

   It is RECOMMENDED that {platform-root} be the same as the API root
   endpoint that the API vendor already provides.

   The body returned in the result, which supports pagination (described
   below), includes an element called items, a JSON array that contains
   the array of signatures.  Each element of the array is a JSON object
   of type ToolSignature.  An example of a valid JSON object of this
   type is:













Rosenberg & White         Expires 22 April 2026                [Page 15]

Internet-Draft                    N-ACT                     October 2025


   {
     "toolId" : "0479a45d-ad0a-49d4-94db-75edf00d2ca4",
     "name" : "Lookup Weather",
     "description" : "Invoke this tool to lookup the
                       weather for a given city.",
     "img" : "{optional URL for the tool}",
     "version" : "{versionNum},
     "currentVersion": "{versionNum}",
     "tags" : ["system", "retrievals"]
     "input_parameters" :
     [
       {
       "id" : "city"
       "name" : "City",
       "type" : "string",
       "description" : "The city for the weather
          lookup. For example, Boston or Los Angeles.",
       "required" : true
       }
     ]
     "output_parameters" :
     [
       {
         "id" : "temp-fh"
         "name" : "Temperature in Fahrenheit",
         "type" : "int",
         "description" : "The current temperature
            in the named city."
       }
     ]
   }

                   Figure 2: ToolSignature Object Example

   The toolID is always a UUID, ensuring tool uniqueness on the server.
   The name MUST be less than 255 characters, and MUST be unique across
   all other tools on the API server.  Names SHOULD use snake case, and
   be sufficiently long to be usefully descriptive without the
   description.  The longer names also reduce the likelhihood of tool
   name collisisons across API servers, in cases where an AI Agent is
   being shown tools from different API servers.  However, it is
   ultimately the responsibility of the AI Agent platform to make sure
   tool names shown to the LLM are unique.

   An example of a good tool name is:

   lookup_weather_by_city




Rosenberg & White         Expires 22 April 2026                [Page 16]

Internet-Draft                    N-ACT                     October 2025


   The tool description MUST be less than 2000 characters.  Tool names
   and description MUST be in English.  Names and descriptions are
   consumed by both the designer (a human) and the LLM.  Localization is
   only needed for the human, and is the responsibility of the AI Agent
   platform.

   For a particular version of the tool, the signature is completely
   locked.  Meaning, the API server MUST NOT change any part of the
   signature (with the notable exception of the value of currentVersion)
   without changing the version.  The version number of a tool MUST be a
   positive integer, and MUST increase monotonically, starting at 1.
   The value of currentVersion reflects the most current version of the
   tool.

   The version returned at the top level tool enumeration endpoint MUST
   be the latest version of the tool, in which case the values of
   version and currentVersion are always identical.

   Input parameters are typed.  The type value is optional to include in
   the JSON.  If omitted, it is "string" by default.  The other valid
   values are "int", "boolean" and "enum".  More complex input types are
   not supported.  This is to constrain the complexity of objects that
   the LLM is asked to synthesize.  [OPEN ISSUE: lists maybe??].  If the
   type is "int", the optional "max" parameter can be included, which
   represents the maximum value for the integer.  The default is 65535.
   If the type is enum, the input parameter must include the attribute
   "allowed-values", which contains an array of name-description pairs.
   As an example:























Rosenberg & White         Expires 22 April 2026                [Page 17]

Internet-Draft                    N-ACT                     October 2025


       {
       "id" : "flight_class"
       "name" : "Flight Class",
       "type" : "enum",
       "description" : "The cabin class for the flight reservation",
       "allowed-values" : {
           [
               {
                   "name" : "ECONOMY",
                   "description" : "Economy class, the least
                   expensive cabin class. Also known as coach."
               },
               {
                   "name" : "PREMIUM_ECONOMY",
                   "description" : "Premium economy class, the
                   second seat tier. More legroom."
               },
               {
                   "name" : "BUSINESS",
                   "description" : "Business class, the next to top
                   seat tier. Offers lie-down seating."
               },
               {
                   "name" : "FIRST",
                   "description" : "The top tier. Lie down seating,
                   luxury meal service, lounge access."
               },

           ]
       }
       "required" : true
       }

           Figure 3: ToolSignature Input Parameters Enum Support

   For enumerated strings, names MUST be snake case but capitalized,
   with a maximum length of 255 characters.  Descriptions have a maximum
   length of 2000 characters.

   Input parameters have IDs and names.  The IDs are meant to provide
   uniqueness across version, facilitating design time software
   processing of version changes.  The IDs need only be unique within
   the tool.

   Input parameter names must also be unique within the tool.  The LLM
   is asked to synthesize the name, not the ID.  Consequently, there is
   no reason to show the parameter ID to the LLM at run time.




Rosenberg & White         Expires 22 April 2026                [Page 18]

Internet-Draft                    N-ACT                     October 2025


   Output parameters include the additional type of JSON.  This is used
   for cases where a more complex structure is returned, and the
   expectation is that the LLM can parse the structure for
   comprehension.  There is an explicit assumption in the signatures
   that it is more important to reduce hallucination on input synthesis,
   than it is to risk mis-comprehension of tool output.  This is why the
   protocol is asymmetric - allowing JSON output, but not input.

   For input parameters, the "required" field is optional; if absent,
   the default is "true".  Optional inputs should be used sparingly.  It
   is better to have more tools with fewer inputs, than a single tool
   with many optional inputs.  This reduces the likelihood of the LLM
   hallucinating tool usage.

6.2.  Details for a Specific tool

   The API allows for a signature to be retrieved for a specific tool
   via:

   GET {platform-root}/tools/{toolID}

   The server MUST return the current version of the specific tool.

6.3.  Tool Version Retrieval

   The API allows all versions of a tool to be retrieved via:

   GET {platform-root}/tools/{toolID}/versions

   The result is paginated, and includes the full signature for each
   version.  These MUST be sorted from most recent to oldest.

   An individual version can then be retrieved via:

   GET {platform-root}/tools/{toolID}/versions/{versionNum}

6.4.  Pagination

   Pagination is supported on the enumeration APIs (any of the above
   endpoints).  All of the APIs support a pageCursor and pageLimit URI
   parameter.  The page limit specifies the maximum number of pages to
   return.









Rosenberg & White         Expires 22 April 2026                [Page 19]

Internet-Draft                    N-ACT                     October 2025


   The array holding the enumeration is included in the JSON body using
   an attribute called items which contains the array.  A peer element,
   called paging, holds the result of the query.  It contains two values
   - pageLimit - containing the actual page limit the server is
   offering, and next.  The next parameter contains the value of the
   cursor query parameter that the client should provide as a URI
   parameter to retrieve the next page.

7.  Invocation API

   At run-time, a tool is invoked with the invocation API:

   POST {platform-root}/tools/{toolID}:invoke

   The body of this takes the invocation object, an example of which is:

   {
     "name" : "lookup_weather_by_city",
     "input_parameters" :
     [
       {
       "name" : "City",
       "value" : "Omaha, Nebraska"
       }
     ]

   The response should contain the result of the invocation, an example
   of which looks like this:

   {
     "output_parameters" :
     [
       {
       "name" : "Temperature in Fahrenheit",
       "value" : 80
       }
     ]

   The output MUST include the name which matches to the output name in
   the signature.

   It is also possible to request invocation of a specific version of
   the tool:

   POST {platform-root}/tools/{toolID}/versions/{versionId}:invoke






Rosenberg & White         Expires 22 April 2026                [Page 20]

Internet-Draft                    N-ACT                     October 2025


   Traditional HTTP response codes apply to the response, including 5xx
   for temporary failures and 4xx if the request is formatted correctly.
   Note that, a 4xx should never happen if the client follows the
   specification defined here.

   If the request generates a 5xx, the executor SHOULD retry, rather
   than show the error to the LLM.  However, this is up to the
   discretion of the AI Agent designer on how long to wait before
   showing it the error and asking it what to do.

7.1.  OpenAPI Specification

   To be added when spec is closer to complete.

8.  Relationship to MCP

   N-ACT is similar in many ways to the Model Context Protocol (MCP)
   (https://modelcontextprotocol.io/introduction
   (https://modelcontextprotocol.io/introduction)) which is being driven
   by Anthropic, but different in others.  This section covers both
   similarities and differences.  On the whole, the two protocols tackle
   a similar problem (facilitating tool calling and serving tool context
   to LLMs), but differ in their approach (MCP better suited for use
   cases where less designer control is appropriate, and N-ACT for cases
   where more designer control is appropriate).

8.1.  Similarities

   Both MCP and N-ACT support APIs for enumerating tools and invoking
   tools.

   Both MCP and N-ACT can be used to feed context to the LLM at run-
   time.

8.2.  Differences

   The biggest difference is the assumption in control.  N-ACT is very
   much targeted at use cases where there is a designer persona crafting
   an operating procedure.  Consequently, the tool enumeration API is
   consumed by traditional software in N-ACT, enabling the designer to
   perform the process of tool selection and design of the operating
   procedure, both at design time.  In MCP, the tool enumeration API is
   primarily consumed by the AI Agent at run-time.  For this reason, MCP
   has the idea of progressive tool disclosure that happens on the
   server side, in order to reduce model context.  N-ACT, on the other
   hand, assumes progressive tool disclosure happens as a consequnce of
   a design time operation, and thus, in simple terms, is client side.




Rosenberg & White         Expires 22 April 2026                [Page 21]

Internet-Draft                    N-ACT                     October 2025


   In MCP, the logic for progressive tool disclosure is distributed in
   cases where there are multiple MCP servers, with each server
   executing its own, non-standardized logic for progressive tool
   disclosure (though the protocol does not require this behavior, it is
   purportedly one of the main reasons for the session oriented aspect
   of the protocol).  In N-ACT, the logic for progressive tool
   disclosure lives in the AI Agent, with the logic being crafted at
   design-time by the designer.  In this way, N-ACT is more compatible
   with Anthropic's skills concept, than it is with its MCP protocol.
   Indeed, N-ACT could be viewed as the offspring of skills and MCP, by
   adding over-the-wire tool calling to skills.

   These foundational differences have consequences in the other parts
   of the protocols.

   MCP is session oriented.  A session oriented protocol is required
   when the server is responsible for progressive tool disclosure.
   N-ACT is stateless, because it is not performing server side
   progressive tool disclosure.

   MCP uses JSON-RPC and runs over either stdio (for local usage on a
   PC) or streamable HTTP for network connections.  N-ACT is a normal
   REST API and uses traditional HTTPS and OpenAPI specifications.

   MCP typically requires a dedicated server that provides its
   functionality (termination of the persistent connection, session
   handling, and gateway to existing APIs).  N-ACT is designed to be
   added to existing API servers as just another API - albeit ones
   optimized for LLMs.

   MCP APIs are not easily consumeable by non-LLM applications.  N-ACT
   APIs are just APIs and can be consumed by both traditional software
   and AI Agents.

9.  Informative References

   [I-D.rosenberg-ai-protocols]
              Rosenberg, J. and C. F. Jennings, "Framework, Use Cases
              and Requirements for AI Agent Protocols", Work in
              Progress, Internet-Draft, draft-rosenberg-ai-protocols-00,
              5 May 2025, <https://datatracker.ietf.org/doc/html/draft-
              rosenberg-ai-protocols-00>.

Authors' Addresses

   Jonathan Rosenberg
   Five9
   Email: jdrosen@jdrosen.net



Rosenberg & White         Expires 22 April 2026                [Page 22]

Internet-Draft                    N-ACT                     October 2025


   Pat White
   Bitwave
   Email: pat.white@traego.com
















































Rosenberg & White         Expires 22 April 2026                [Page 23]


name: draft-rosenberg-aiproto-nact
rev: 00
title: Normalized API for AI Agents Calling Tools (N-ACT)
time: 2025-10-20T01:59:42Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T01:59:42Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Data formats/interop", "Agent discovery/reg"]
tags: []
fetched_at: 2026-02-27T22:56:05.127701+00:00
abstract:
This document defines a protocol that facilitates integration of
   tools into the design and run-time operations of AI Agents.  The
   focus is on enterprise AI agents that need to make use of APIs
   exposed by third party providers.  This protocol, called the
   Normalized API for AI Agents Calling Tools (N-ACT) - pronounced like
   "enact" - defines an OpenAI spec that has two principle features -
   enumeration of tools and invocation of tools.  The enumeration API
   enables a human - the AI Agent designer employed by the enterprise -
   to select and include tools from third-party vendors into operating
   procedures (also known as skills or instructions) which direct the
   behavior of AI Agents, including how and when to invoke those tools.
   The enumeration API can also be used (optionally) at run-time for the
   LLM to obtain tool descriptions.  The second feature of the API -
   invocation - allows the AI Agent executor to perform the inter-domain
   invocation of the tool at run time.  By standardizing these two API
   functions, the time and cost of integration of Internet APIs into AI
   Agents can be reduced.

full_text:
Network Working Group                                       J. Rosenberg
Internet-Draft                                                     Five9
Intended status: Informational                                  P. White
Expires: 22 April 2026                                           Bitwave
                                                         19 October 2025


           Normalized API for AI Agents Calling Tools (N-ACT)
                    draft-rosenberg-aiproto-nact-00

Abstract

   This document defines a protocol that facilitates integration of
   tools into the design and run-time operations of AI Agents.  The
   focus is on enterprise AI agents that need to make use of APIs
   exposed by third party providers.  This protocol, called the
   Normalized API for AI Agents Calling Tools (N-ACT) - pronounced like
   "enact" - defines an OpenAI spec that has two principle features -
   enumeration of tools and invocation of tools.  The enumeration API
   enables a human - the AI Agent designer employed by the enterprise -
   to select and include tools from third-party vendors into operating
   procedures (also known as skills or instructions) which direct the
   behavior of AI Agents, including how and when to invoke those tools.
   The enumeration API can also be used (optionally) at run-time for the
   LLM to obtain tool descriptions.  The second feature of the API -
   invocation - allows the AI Agent executor to perform the inter-domain
   invocation of the tool at run time.  By standardizing these two API
   functions, the time and cost of integration of Internet APIs into AI
   Agents can be reduced.

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 22 April 2026.





Rosenberg & White         Expires 22 April 2026                 [Page 1]

Internet-Draft                    N-ACT                     October 2025


Copyright Notice

   Copyright (c) 2025 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.  Background  . . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   6
   3.  Problem Statement . . . . . . . . . . . . . . . . . . . . . .   9
     3.1.  Tool Curation . . . . . . . . . . . . . . . . . . . . . .   9
       3.1.1.  Tool Sculpting  . . . . . . . . . . . . . . . . . . .   9
   4.  The N-ACT Protocol Goals  . . . . . . . . . . . . . . . . . .  11
   5.  Overview of Operation . . . . . . . . . . . . . . . . . . . .  12
     5.1.  Tool Signatures . . . . . . . . . . . . . . . . . . . . .  12
     5.2.  Enumeration Endpoint  . . . . . . . . . . . . . . . . . .  13
     5.3.  Invocation Endpoint . . . . . . . . . . . . . . . . . . .  14
     5.4.  Versioning  . . . . . . . . . . . . . . . . . . . . . . .  15
   6.  Protocol Details  . . . . . . . . . . . . . . . . . . . . . .  15
     6.1.  Enumeration API . . . . . . . . . . . . . . . . . . . . .  15
     6.2.  Details for a Specific tool . . . . . . . . . . . . . . .  19
     6.3.  Tool Version Retrieval  . . . . . . . . . . . . . . . . .  19
     6.4.  Pagination  . . . . . . . . . . . . . . . . . . . . . . .  19
   7.  Invocation API  . . . . . . . . . . . . . . . . . . . . . . .  20
     7.1.  OpenAPI Specification . . . . . . . . . . . . . . . . . .  21
   8.  Relationship to MCP . . . . . . . . . . . . . . . . . . . . .  21
     8.1.  Similarities  . . . . . . . . . . . . . . . . . . . . . .  21
     8.2.  Differences . . . . . . . . . . . . . . . . . . . . . . .  21
   9.  Informative References  . . . . . . . . . . . . . . . . . . .  22
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  22

1.  Background

   AI Agents are applications built using Large Language Models (LLMs).
   AI Agents typically operate on behalf of some human or organization,
   and are capable of taking actions through the invocation of
   functions, also known as tools.  [I-D.rosenberg-ai-protocols]
   provides an overview of protocols and use cases for AI Agents.




Rosenberg & White         Expires 22 April 2026                 [Page 2]

Internet-Draft                    N-ACT                     October 2025


   In enterprise applications of AI Agents - including customer support
   uses cases - it is very common for the AI Agent to invoke tools
   provided by other organizations.  As an example, consider an
   enterprise that is a healthcare provider.  They have an AI Agent that
   needs to facilitate appointment scheduling, appointment cancellation,
   prescription refills, store location and hours lookup, and vaccine
   scheduling.  The actions are all supported by tools which are exposed
   to the AI Agent through its instructions.  The tools, in this case,
   could be implemented by servers within the enterprise domain - built
   by their IT department for example.  Or, they might be implemented by
   B2B SaaS providers that offer these capabilities to the entperrise.
   For example, in the healthcare space, Epic, Cerner, and Meditech are
   a few of the B2B SaaS providers that are often used by retail
   healthcare providers.

   It is very common for enterprises to have dozens, if not hundreds, of
   different systems providing APIs that might need to be accessed by an
   AI Agent.  This high cardinality is not new.  Prior to the advent of
   large language model technologies, voice and chat bots - and even
   classic "press 1 for sales, and 2 for support" Interactive Voice
   Response Systems (IVR) - needed to access large numbers of APIs to
   provide customer support for end users.  Integration of these APIs
   into IVRs, voice bots and chat bots often represented the most
   expensive and complex part of deploying those systems - not the
   training and optimization of the AI model which invokes them.

   The advent of AI Agents - if anything - only increases the likely
   cardinality of the number of distinct API sysems that need to be
   integrated.  This is due to increased capabilities of LLMs compared
   to prior generation AI models.  Whereas, in the past, certain use
   cases where just too difficult to automate (for example, multi-room
   booking for hotels - is difficult to do on websites, and almost never
   attempted by voice or chat bots) - now, these may be within reach for
   automation using AI Agent technology.  As a result, we will see more
   use cases, and therefore even more APIs that need to be integrated.

   For an AI agent to be effective, it needs more direction than just
   the enumeration of tools with names and descriptions.  Particularly
   in enterprise and customer support use cases, detailed instructions
   are required which direct when, how, if and why those tools should be
   invoked.  These instructions guide the AI agent on how to converse
   with the customer, what kind of information to collect, how to use it
   to invoke the tools, how to handle the differing responses, and what
   to do with the data that is returned.  We use the term operating
   procedure to describe an instruction that provides this detail to an
   AI Agent.  An operating procedure is typically specific to a
   particular task (for example, booking an appointment for a healthcare
   visit).  An operating procedure at the end of the day is a document,



Rosenberg & White         Expires 22 April 2026                 [Page 3]

Internet-Draft                    N-ACT                     October 2025


   containing natural language text with references to tools, tool
   inputs, and tool outputs.  Others have referred to these as skills
   (see the recent Anthropic blog post here:
   https://www.anthropic.com/engineering/equipping-agents-for-the-real-
   world-with-agent-skills (https://www.anthropic.com/engineering/
   equipping-agents-for-the-real-world-with-agent-skills)), instructions
   or even prompts.

   Here is an abbreviated example of an operating procedure for
   prescription refill that illustrates this:

   ##Goal

   Your goal is to help the user with prescription refill inquiries.

   ## Prescription Refill Status
   Follow this flow if the user: 
   - is asking about the status of a prescription
    refill request they've made;
   - is asking when their prescription refill(s)
     will be ready. For example:
   - What's the status of my prescription request?
   - I just want an update regarding my prescriptions.
   - When will my prescription refill be ready?
   ### Prescription Lookup
   - Use look_up_prescriptions() to look up the user's
     active prescriptions. You must have previously
     authenticated the user and have their account ID.
     If you don't have their accountID yet, perform the
     authentication flow.
   ### Present Status
   - Find the prescriptions which have a status other
     than null and present them to the user along with
     their status.
   ### Sending Confirmation
   - Ask the user if they want to receive a confirmation
     when the refill has been sent to the pharmacy.
   - If you have the user's preferred contact method
    (which the you would have gotten earlier from
     look_up_ani_user_by_ani(), use that information
     and send them the confirmation of the appointment
     status along with the appointment details.

                   Figure 1: Example Operating Procedure

   As you can see from the example, the operating procedure is a
   detailed recipe-book - a training manual of sorts - for the AI Agent.
   It describes API sequencing (for example, that the lookup of



Rosenberg & White         Expires 22 April 2026                 [Page 4]

Internet-Draft                    N-ACT                     October 2025


   prescriptions can only be done after authentication), usage of
   parameters (that accountID must be included from prior
   authentication), handling of results (show the list to the user), and
   so on.

   Operating procedures are analagous to training manuals for human
   agents, which similarly instruct them in the sequencing and handling
   of a call.  Instead of invoking tools, humans use web applications to
   do a similar job.  In traditional contact centers, entire teams of
   people are accountable for creating and maintaining these training
   manuals.  They are essential for ensuring quality of customer
   support.

   At the end of the day - operating procedures are what make the AI
   Agent work.  While their generation may be assisted by an AI to
   facilitate authoring, operating procedures are crafted by human
   beings using traditional software.  The person whose role is to
   create the operating procedure is called the AI Agent designer - or
   just designer for short.  The software used by the designer to create
   an AI Agent, including the authoring of the operating procedure, is
   called the AI Agent platform.  To properly create an operating
   procedure, the designer must be a domain expert - familiar with the
   appropriate process for performing the task the AI Agent is to
   perform.

   Part of task of creating an AI Agent is the selection of the tools to
   be used.  Typically, this selection happens through the authoring of
   the operating procedure, which makes explicit reference to the tool
   as in the example above.  It is also possible for the designer to
   select a tool for usage by the AI Agent but not provide any guidance
   on its usage in the operating procedure (most of the current APIs for
   AI Agents separate the tool list from the instruction, thus making
   this possible).  While technically this can work, it often results in
   higher rates of hallucinated tool usage.

   The choice by a designer on the set of tools that are shown to the
   LLM (we use the verb show as a synonym for inclusion of information
   into the model's context window) is referred to as tool selection.
   The process of tool selection and authorship of the operating
   procedures happen ahead of the deployment and actual usage of the AI
   Agent.  We refer to this as design time, whereas the usage of the AI
   Agent by end users is called run time.

   At run time, a user will begin a session with an AI Agent.  At the
   beginning of the session, the AI Agent is shown the operating
   procedure and tools, and begins operation.





Rosenberg & White         Expires 22 April 2026                 [Page 5]

Internet-Draft                    N-ACT                     October 2025


   It is becoming increasingly common for AI Agent design systems to
   make use of multiple distinct AI Agents (called sub-agents) which are
   each equipped to handle specific tasks.  These are called multi-agent
   systems.  Once again using our health care example, one sub-agent
   might handle prescription refills, while another handles appointment
   scheduling and cancellation.  Each sub-agent would have its own
   distinct set of operating procedures and tools, appropriate for those
   tasks.  This further reduces the size of the context window at any
   point in time, reducing hallucination rates.  There are various
   techniques for how these sub-agents are strung together.  At the end
   of the day, it is often done through tool calling, asking the LLM to
   invoke a tool that transfers the session to a different AI Agent.
   This is (interestingly) analagous to live human agents in contact
   centers, which typically have human agents with differing skills.
   When a customer asks for something which is outside of the expertise
   for the human agent they are talking to, the human agent transfers
   the call to a different human agent with the right skill.  In essence
   - that is what is happening in these multi-agent systems.

   The usage of a designer to select only those tools needed for an
   agent, and the usage of multi-agent systems, provides progressive
   tool disclosure.  Progressive tool disclosure is a concept wherein an
   AI Agent is only shown just the set of tools it needs at a given
   time, and as the conversation flows, more tools are shown.

   The tools selected by the designer, and incorporated into the
   operating procedure, are often implemented by the executor through
   the invocation of APIs on some server.  The server exposing those
   APIs is called an API Server.

2.  Terminology

   Terminology is becoming foundationally important in this emerging AI
   Agent field.  This section summarizes the key terminology and
   concepts from above.

   *  AI Agent: A software application that makes use of an LLM to
      perform tasks that require interaction with software systems.
      With an AI Agent, the LLM can output both text for the user, but
      it can also request the invocation of tools, which are an
      interface the LLM can use to access those software systems.  AI
      Agents are composed of two elements: an LLM and an executor.  The
      executor is built using traditional software (e.g., Java, node.js,
      python, etc) and interfaces with the LLM.

   *  Tool: An interface representing a software system.  A tool has a
      name, a description, inputs and outputs.  In AI Agent system, the
      LLM is responsible for collecting the inputs and requesting the



Rosenberg & White         Expires 22 April 2026                 [Page 6]

Internet-Draft                    N-ACT                     October 2025


      invocation of the tool.  The executor actually executes the tool,
      often through the invocation of APIs, and feeds the results back
      to the LLM.  By convention, tool names use underscores and have a
      terminating curly bracket, even though they may also take
      parameters.  For example, when we say "the LLM invokes
      schedule_appointment()" this means that the LLM has made a
      decision to invoke the tool name schedule_appointment and has
      synthesized the needed input parameters to the tool

   *  Executor: Also called the orchestrator or orchestration engine.
      It represents the traditional software component of an AI Agent.
      The executor funnels messages to and from the end user into the
      LLM.  It receives the outputs of the LLM, and if that output is a
      request to perform a tool call, the executor runs the tool and
      provides its output back to the LLM.

   *  Show: The process wherein the executor provides input to the LLM,
      inclusive of tool call results, by adding it to the context window
      of the LLM.  For example, we say, "the tool call result is shown
      to the LLM'.

   *  Operating Procedure: A document authored by a human, and shown to
      an LLM during run-time operation, which instructs the AI Agent on
      the sequence of tools to invoke, how to interact with the user to
      collect the data needed for tool invocation, what to do with the
      results of the tool call, how to handle different conditions based
      on the output of the tools, and how to handle exceptional
      conditions.  Operating procedures reference tools and their inputs
      by name.

   *  AI Agent Designer: Synonymous with designer

   *  Designer: A human being whose job is to create operating
      procedures and perform tool selection during the design phase of
      the AI Agent.

   *  Tool Selection: The process of selection of the right set of tools
      to show to an AI Agent for a particular task.  By selecting only
      those tools which are needed for a task, the likelihood of tool
      hallucination is reduced.  Tool selection in the N-ACT framework
      happens at design time (though the protocol allows this to happen
      at run time in an interoperable fashion, should that mode be
      selected by the AI Agent platform vendor).

   *  Design Time: A point in time during which the designer is
      interacting with the AI Agent platform in the producion of an
      operating procedure and selection of tools.




Rosenberg & White         Expires 22 April 2026                 [Page 7]

Internet-Draft                    N-ACT                     October 2025


   *  Enterprise: The administrative entity on whose behalf an AI Agent
      operates.  Typically the designer is an employee of the
      enterprise, though this can be outsourced to consulting firms or
      the AI Agent Platform vendor.

   *  Run Time: A point in time during which an end user is interacting
      with an AI Agent.

   *  Multi-Agent Systems: An AI Agent wherein its job is broken down
      into a smaller set of discrete tasks, each handled by a sub-agent
      that is equipped (via its operating procedure and tool list) to
      perform that specific task

   *  Sub-Agent: An AI Agent that performs a narrow set of tasks.
      Multiple Sub-Agents are woven together to form the AI Agent in a
      Multi-Agent System.

   *  Progressive Tool Disclosure: A technique for reduction of
      hallucination wherein, as an AI Agent session unfolds, the set of
      tools shown to the LLM evolves, offering it only the tools it
      needs to do its job at any point in time.

   *  API Server: A server that exposes APIs which can be invoked via a
      tool call by the AI Agent

   *  API Provider: The administrative entity that is offering APIs that
      are of interest to an AI Agent.  Typically, the API Provider is
      different from the enterprise, and is also different in turn from
      the AI Agent Platorm vendor.

   *  AI Agent Session: A period of time from when an AI agent begins -
      by having the executor show the LLM the initial operating
      procedure and tool selection - estabishing initial context - and
      interacting with the end user - until the end user interaction
      completes.

   *  AI Agent Platform: A piece of software which includes a design
      time experience for designers, and a run-time capability for
      handling AI Agent sessions.  Typically built as a cloud service by
      the AI Agent Platform vendor.  Though the AI Agent Platform can be
      provided by the vendor of the LLM itself, these can be distinct
      vendors.

   *  AI Agent Platgorm Vendor: The administrative entity that has
      developed the AI Agent Platform, and made it available for usage
      by enterprises to author and execute AI Agents.





Rosenberg & White         Expires 22 April 2026                 [Page 8]

Internet-Draft                    N-ACT                     October 2025


3.  Problem Statement

   There are multiple problems that are addressed by N-ACT, covering
   design time and run-time challenges.

3.1.  Tool Curation

   At design time, the AI Agent platform needs to enable the designer to
   author the operating procedure and, as a result, select the tools
   that will be made available to the AI Agent (or the sub-agent).  To
   do this, the designer needs to know what the available tools are,
   from which they can select.  In essence, the designer is performing a
   curation task, choosing amongst a large inventory of tools available
   from many possible API servers.  Most often, the enterprise deploying
   the AI Agent, is different from the vendor of the AI Agent platform,
   which is different still from the vendors of the API servers.

   As a result, the designer needs to know the API surface area of the
   various vendors of API servers, and know which API to select and use.
   Sometimes, API Servers offer OpenAPI specifications for their APIs,
   but these are tailored for usage with software developers, not
   consumption by AI Agent designers, and certainly not by LLMs.
   Consequently, they lack the required natural language descriptions to
   aid in the curation process by the designer.  Designers need to spend
   time researching and studying APIs, learning what they do, and
   determining whether the right APIs exist, and if so, what they are.
   They have to determine whether the API can be used as is, or whether
   changes are needed to make the API more easily (and reliably)
   consumeable for the automation.  This process is historically long
   and tedious, and is exacerbated by the fact that the APIs are spread
   across dozens of API servers from the many vendors used by a
   particular enterprise.

   The lengthy time required for API integration is one of the most
   significant parts of the time required to build automation solutions
   (including AI Agents) within enterprises.

3.1.1.  Tool Sculpting

   Oftentimes existing APIs on API servers - usually REST these days -
   are complex and (clearly) not optimized for usage by an LLM.  They
   have been designed to be consumed by traditional software authored by
   software developers.  Traditional REST API signatures have complex
   inputs - URI parameters, header parameters, and JSON bodies.  They
   also tend to mix programmatic elements and semantic elements.
   Programmatic elements are those parts of the API parameters that are
   meaningful only to the software which is invoking those APIs.  These
   include resource identifiers like UUIDs, trace IDs, URLs, timestamps,



Rosenberg & White         Expires 22 April 2026                 [Page 9]

Internet-Draft                    N-ACT                     October 2025


   meta-data and so on.  Semantic elements are those which are
   ultimately the input from the end user which drove the execution of
   the API.  As an example, when doing something as simple as looking up
   the weather, the city and the date (today or the future) are the
   semantic elements.  But the lookup API might need to provide
   programmatic elements like a weather station ID, which is not
   meaningful to the user request.

   It is also the case that a particular end user request (e.g., give me
   the weather tomorrow in Manhattan), doesn't map to a single API call.
   Instead, a sequence of API calls need to be orhcestrated together to
   actually provide this simple ask.  As an example, the APIs at the US
   National Weather service provide weather forecasting based on grids
   of 2.5km to 2.5km.  Consequently, to provide the weather for
   Manhattan, the location must be first mapped to a coordinate, and
   then the coordinates fed into the forecast API.

   There are two ways these problems are solved today.

   A simple way to solve these problems is to just let the LLM figure it
   out.  A naive implementation would - in essence, use the existing
   OpenAPI specs for an API as a tool, and request the LLM to synthesize
   inputs, process outputs, and chain API calls together.  While this is
   possible - and indeed works for simple use cases - it introduces
   hallucination risk.  It also complicates the design process,
   requiring the designer to understand the details of these APIs.  The
   designer must - via the operating procedure - direct the AI Agent on
   how to use the APIs and navigate them.

   This approach has many problems.  First, it increases the time
   required to author the operating procedure, since it must now include
   the manually generated instructions on how to use the APIs.  Second -
   and most importantly - it increases hallucination risk.  The larger
   the gap between how the API works, and what the semantically
   meaningful operation is - the larger the surface area for mistakes by
   the LLM.

   The lesson is - never ask an LLM to do what a normal piece of
   software can do better.

   And thus, the second way this is solved today is through the
   development of automation ontop of existing APIs.  Again using the US
   National weather service example, a piece of traditional software can
   be written which exposes an API called lookup_weather_by_city.  This
   API would, under the hood, first convert the city to geo-coordinates,
   and then lookup the weather for those coordinates.  The resulting
   simplified API can then be shown to the LLM as a tool.




Rosenberg & White         Expires 22 April 2026                [Page 10]

Internet-Draft                    N-ACT                     October 2025


   The process of adding a layer of traditional software ontop of
   existing APIs in order to produce ones that more directly map to user
   input, in order to reduce tool call hallucination risk, we call as
   tool sculpting.

   Specifically, tool sculpting is the process of crafting an API which:
   1.  Minimizes the inputs for each tool to only those which are
   semantically meaningful and must be synthesized by an AI Agent 2.
   Minimizes the outputs for each tool to only those which would be
   relevant to an AI Agent 3.  Orchestrates multi-step backend API calls
   so that the AI Agent doesn't need to do it

4.  The N-ACT Protocol Goals

   The N-ACT protocol (N-ACT is pronounced like the word enact)
   addresses the underlying problems of tool curation and tool
   minimization.

   It has, at its core, the following goals:

   *  Reduce the time and costs for designers to create operating
      procedures and perform tool selection by simplifying the process
      of curation

   *  Enable development of AI Agents for enterprises which need access
      to tools across dozens or hundreds of API servers, typically sold
      to the enterprise by third party B2B SaaS vendors, by
      consolidating decision logic on tool selection in the hands of the
      designer

   *  Simplify adoption by tool vendors by building ontop of the
      existing API platforms and APIs they already have.  The closer the
      current API surface area is to the ideal tool set for an AI Agent,
      the less effort is required to implement

   *  Standardize an API signature for tool calling

   *  Tools are just APIs that are optimized for an LLM, but can also be
      used by traditional software applications too

   *  Authentication and Auhtorization use the existing techniques used
      for REST APIs offered by the API Vendor

   *  Reduce hallucination risk through tool sculpting

   *  Separation of responsibility - API vendors perform tool sculpting,
      and the AI Agent designer crafts the operating procedure which
      instructs the AI Agent on how to use the many tools (across



Rosenberg & White         Expires 22 April 2026                [Page 11]

Internet-Draft                    N-ACT                     October 2025


      vendors even) that it can use.  In other words - one vendor makes
      tools which independent of the agent, and the other vendor makes
      agents which make use of those tools.

5.  Overview of Operation

   N-ACT is a web API that defines a pair of REST endpoints - one for
   enumerating tools available on the server, and the other for invoking
   a tool on the server.  Both of these make use of a tool signature,
   which is a standardized interface for what a tool looks like - how to
   describe a tool, and how to invoke it.  The API client is implemented
   by the AI Agent platform, and the rest endpoints are implemented by
   vendor wishing to expose their APIs as N-ACT tools.  It is envisioned
   that these just end up being new REST APIs added to the existing API
   surface area of the API Provider.

5.1.  Tool Signatures

   N-ACT standardizes the signature for tool calling.  A tool can be
   thought of as a Java interface, and the implementation of the tool
   happens over the wire by having the executor take the tool call from
   the LLM and send it to the API server.

   Every tool in N-ACT is comprised of the following descriptive
   signature:

   *  The tool ID
   *  The name of the tool
   *  The description of the tool
   *  The set of input parameters.  For each input parameter:
      -  The name of the input parameter, and whether it is required or
         optional
      -  The type of the input parameter - one of a small set (string,
         int, enum)
      -  The description of the input parameter
      -  Any constraints on the input types
         o  Strings: max length
         o  Int: min and max values
         o  Enum: list of enumerated values that are permitted, along
            with a description of each value.
   *  The output, of which there can be one or more.  Each output is:
      -  The name of the output
      -  A description of the output
      -  The type of the output (string, int, enum, json)

   Invoking a tool requires the following to be provided:

   *  the name of the tool



Rosenberg & White         Expires 22 April 2026                [Page 12]

Internet-Draft                    N-ACT                     October 2025


   *  an input parameter list, which is an array of name/value pairs

   Consequently, the N-ACT protocol defines two JSON objects - the
   signature, and the invocation.  The N-ACT protocol carries these in
   its body.

   The signature ensures that the executor can take the output of the
   LLM, validate it against the signature, and execute it by sending the
   invocation over the wire.  For example, if the LLM synthesizes a tool
   call request with a missing parameter, or with an enum value that is
   not amongst the allowed values, the executor can reject it and ask
   the LLM to try again, or take other error handling logic.

5.2.  Enumeration Endpoint

   The enumeration endpoint - as the name implies - returns a list of
   tools available.  This API endpoint returns an array, each element in
   the array is a signature as noted above.  The API supports tagging
   and versioning, with filtering on those parameters, to facilitate
   design time interactions between the AI Agent platform and the API
   server.

   This API facilitates the following design-time workflow:

   1.  The designer identifies the set of API vendors for which the AI
       Agent should be allowed to operate
   2.  For each such API vendor, the designer configures the AI Agent
       platform with the URI for the N-ACT tool enumeration endpoint.
       This specification suggests a common naming practice of using the
       root API endpoint followed by "tools" (e.g.,
       https://api.weather.gov/tools (https://api.weather.gov/tools)) to
       simplify this when possible.
   3.  The administrator configures the appropriate credentials needed
       for AuthN and AUthZ (typically an OAuth grant flow) - this is not
       any different from any other endpoint from the API provider
   4.  The designer accesses the AI Agent platform, and the platform
       invokes the enumeration API and retrieves the tool signatures for
       all of the tools exposed on the API server for all of the
       configured API providers.  This provides a list of tools to the
       platform.  This list can be viewed, searched, filtering and
       sorted by the designer.  The UI of the design time experience can
       help the designer find and select tools for placement into the
       operating procedure.

   The above steps can be done just once, and then apply to all AI
   Agents subsequently built on the platform.  Alternatively, the
   enumeration APIs can be explored by the AI Agent platform at design
   time, as the designer works.



Rosenberg & White         Expires 22 April 2026                [Page 13]

Internet-Draft                    N-ACT                     October 2025


   Once the designer has selected the tool, the tool signature can be
   retrieved by the AI Agent platform, stored, and then provided to the
   LLM at run-time.  With N-ACT, it is also possible to use the
   enumeration API retrieve a fresh tool signature at run-time, rather
   than use the version retrieved and cached at design time.  There are
   pros and cons to both approaches.  Retrieving and caching the
   signature at design time ensures consistency.  Designers seeking
   greater consistency - wherein testing of the agent performed before
   launch, matches run-time behavior, will prefer to cache the
   descriptions.  Indeed, the usage of caching allows the designer to
   tune and tweak the natural language text in the signature to improve
   accuracy, without dependng on the API vendor to do so.  This
   facilitates the separation of concerns built into the N-ACT protocol
   - that the AI agent designer can control all aspects of the behavior
   of the AI Agent, including the authorship of all natural language
   provided to the AI Agent.  The API vendor provides the tool - which
   is purely programmatic.

   Alternatively, if the AI Agent platform fetches the tool signature
   each time at run time, the latest-and-greatest can be used.  N-ACT
   does not technically prohibit this, allowing this mode to be
   implemented in an interoperable fashion.

   The key to efficacy of tool usage is the tool sculpting, a
   responsibility which sits with the API vendor in the N-ACT protocol.
   The API server must distill down its APIs into a set of tools, each
   of which do targeted, focused tasks.  Tool sculpting has a double
   benefit.  First, it reduces the surface area of information that the
   LLM needs to synthesize to invoke the tool, and reduces the amount it
   needs to comprehend to process its outputs.  Second, it simplifies
   the job of the designer in selection of the tool, and in crafting the
   operating procedure to instruct the LLM on when and how to invoke it.

   N-ACT also provides an API, part of the enumeration endpoint, for
   retrieving the signature for a specific tool.  This is useful for the
   run-time fetching of the signature.

5.3.  Invocation Endpoint

   The invocation endpoint is used by the executor at run-time.

   When the LLM creates a tool request, it provides the tool name and
   input values.  Using the signature, the executor can validate the
   tool call request as being valid for the tool, and then use the wire
   protocol to invoke the tool on the API server.  When the response
   comes, it can then be shown to the LLM.





Rosenberg & White         Expires 22 April 2026                [Page 14]

Internet-Draft                    N-ACT                     October 2025


   The N-ACT invocation endpoint allows versioning, so that a specific
   version of the tool can be used.

5.4.  Versioning

   A common problem historically in the development of voice and chat
   bots - the precursor to modern AI Agents - is that API vendors
   sometimes change APIs, breaking operation of the bot.  This problem
   remains with AI Agents, and N-ACT addresses it by natively adding
   version support.

   The N-ACT protocol requires versioning for tools.  It mandates that
   each version of a tool is backwards compatible.  A new version of a
   tool can only add new optional input parameters, or add new output
   parameters.  To ensure consistent behavior, N-ACT requires API
   servers to allow invocation of a tool against a specific version,
   allowing AI Agent designers to select when to upgrade when new
   versions become available.

6.  Protocol Details

   The following provides a detailed specification of the protocol.

6.1.  Enumeration API

   N-ACT servers MUST implement the enumeration API, which is structured
   as follows:

   GET {platform-root}/tools

   It is RECOMMENDED that {platform-root} be the same as the API root
   endpoint that the API vendor already provides.

   The body returned in the result, which supports pagination (described
   below), includes an element called items, a JSON array that contains
   the array of signatures.  Each element of the array is a JSON object
   of type ToolSignature.  An example of a valid JSON object of this
   type is:













Rosenberg & White         Expires 22 April 2026                [Page 15]

Internet-Draft                    N-ACT                     October 2025


   {
     "toolId" : "0479a45d-ad0a-49d4-94db-75edf00d2ca4",
     "name" : "Lookup Weather",
     "description" : "Invoke this tool to lookup the
                       weather for a given city.",
     "img" : "{optional URL for the tool}",
     "version" : "{versionNum},
     "currentVersion": "{versionNum}",
     "tags" : ["system", "retrievals"]
     "input_parameters" :
     [
       {
       "id" : "city"
       "name" : "City",
       "type" : "string",
       "description" : "The city for the weather
          lookup. For example, Boston or Los Angeles.",
       "required" : true
       }
     ]
     "output_parameters" :
     [
       {
         "id" : "temp-fh"
         "name" : "Temperature in Fahrenheit",
         "type" : "int",
         "description" : "The current temperature
            in the named city."
       }
     ]
   }

                   Figure 2: ToolSignature Object Example

   The toolID is always a UUID, ensuring tool uniqueness on the server.
   The name MUST be less than 255 characters, and MUST be unique across
   all other tools on the API server.  Names SHOULD use snake case, and
   be sufficiently long to be usefully descriptive without the
   description.  The longer names also reduce the likelhihood of tool
   name collisisons across API servers, in cases where an AI Agent is
   being shown tools from different API servers.  However, it is
   ultimately the responsibility of the AI Agent platform to make sure
   tool names shown to the LLM are unique.

   An example of a good tool name is:

   lookup_weather_by_city




Rosenberg & White         Expires 22 April 2026                [Page 16]

Internet-Draft                    N-ACT                     October 2025


   The tool description MUST be less than 2000 characters.  Tool names
   and description MUST be in English.  Names and descriptions are
   consumed by both the designer (a human) and the LLM.  Localization is
   only needed for the human, and is the responsibility of the AI Agent
   platform.

   For a particular version of the tool, the signature is completely
   locked.  Meaning, the API server MUST NOT change any part of the
   signature (with the notable exception of the value of currentVersion)
   without changing the version.  The version number of a tool MUST be a
   positive integer, and MUST increase monotonically, starting at 1.
   The value of currentVersion reflects the most current version of the
   tool.

   The version returned at the top level tool enumeration endpoint MUST
   be the latest version of the tool, in which case the values of
   version and currentVersion are always identical.

   Input parameters are typed.  The type value is optional to include in
   the JSON.  If omitted, it is "string" by default.  The other valid
   values are "int", "boolean" and "enum".  More complex input types are
   not supported.  This is to constrain the complexity of objects that
   the LLM is asked to synthesize.  [OPEN ISSUE: lists maybe??].  If the
   type is "int", the optional "max" parameter can be included, which
   represents the maximum value for the integer.  The default is 65535.
   If the type is enum, the input parameter must include the attribute
   "allowed-values", which contains an array of name-description pairs.
   As an example:























Rosenberg & White         Expires 22 April 2026                [Page 17]

Internet-Draft                    N-ACT                     October 2025


       {
       "id" : "flight_class"
       "name" : "Flight Class",
       "type" : "enum",
       "description" : "The cabin class for the flight reservation",
       "allowed-values" : {
           [
               {
                   "name" : "ECONOMY",
                   "description" : "Economy class, the least
                   expensive cabin class. Also known as coach."
               },
               {
                   "name" : "PREMIUM_ECONOMY",
                   "description" : "Premium economy class, the
                   second seat tier. More legroom."
               },
               {
                   "name" : "BUSINESS",
                   "description" : "Business class, the next to top
                   seat tier. Offers lie-down seating."
               },
               {
                   "name" : "FIRST",
                   "description" : "The top tier. Lie down seating,
                   luxury meal service, lounge access."
               },

           ]
       }
       "required" : true
       }

           Figure 3: ToolSignature Input Parameters Enum Support

   For enumerated strings, names MUST be snake case but capitalized,
   with a maximum length of 255 characters.  Descriptions have a maximum
   length of 2000 characters.

   Input parameters have IDs and names.  The IDs are meant to provide
   uniqueness across version, facilitating design time software
   processing of version changes.  The IDs need only be unique within
   the tool.

   Input parameter names must also be unique within the tool.  The LLM
   is asked to synthesize the name, not the ID.  Consequently, there is
   no reason to show the parameter ID to the LLM at run time.




Rosenberg & White         Expires 22 April 2026                [Page 18]

Internet-Draft                    N-ACT                     October 2025


   Output parameters include the additional type of JSON.  This is used
   for cases where a more complex structure is returned, and the
   expectation is that the LLM can parse the structure for
   comprehension.  There is an explicit assumption in the signatures
   that it is more important to reduce hallucination on input synthesis,
   than it is to risk mis-comprehension of tool output.  This is why the
   protocol is asymmetric - allowing JSON output, but not input.

   For input parameters, the "required" field is optional; if absent,
   the default is "true".  Optional inputs should be used sparingly.  It
   is better to have more tools with fewer inputs, than a single tool
   with many optional inputs.  This reduces the likelihood of the LLM
   hallucinating tool usage.

6.2.  Details for a Specific tool

   The API allows for a signature to be retrieved for a specific tool
   via:

   GET {platform-root}/tools/{toolID}

   The server MUST return the current version of the specific tool.

6.3.  Tool Version Retrieval

   The API allows all versions of a tool to be retrieved via:

   GET {platform-root}/tools/{toolID}/versions

   The result is paginated, and includes the full signature for each
   version.  These MUST be sorted from most recent to oldest.

   An individual version can then be retrieved via:

   GET {platform-root}/tools/{toolID}/versions/{versionNum}

6.4.  Pagination

   Pagination is supported on the enumeration APIs (any of the above
   endpoints).  All of the APIs support a pageCursor and pageLimit URI
   parameter.  The page limit specifies the maximum number of pages to
   return.









Rosenberg & White         Expires 22 April 2026                [Page 19]

Internet-Draft                    N-ACT                     October 2025


   The array holding the enumeration is included in the JSON body using
   an attribute called items which contains the array.  A peer element,
   called paging, holds the result of the query.  It contains two values
   - pageLimit - containing the actual page limit the server is
   offering, and next.  The next parameter contains the value of the
   cursor query parameter that the client should provide as a URI
   parameter to retrieve the next page.

7.  Invocation API

   At run-time, a tool is invoked with the invocation API:

   POST {platform-root}/tools/{toolID}:invoke

   The body of this takes the invocation object, an example of which is:

   {
     "name" : "lookup_weather_by_city",
     "input_parameters" :
     [
       {
       "name" : "City",
       "value" : "Omaha, Nebraska"
       }
     ]

   The response should contain the result of the invocation, an example
   of which looks like this:

   {
     "output_parameters" :
     [
       {
       "name" : "Temperature in Fahrenheit",
       "value" : 80
       }
     ]

   The output MUST include the name which matches to the output name in
   the signature.

   It is also possible to request invocation of a specific version of
   the tool:

   POST {platform-root}/tools/{toolID}/versions/{versionId}:invoke






Rosenberg & White         Expires 22 April 2026                [Page 20]

Internet-Draft                    N-ACT                     October 2025


   Traditional HTTP response codes apply to the response, including 5xx
   for temporary failures and 4xx if the request is formatted correctly.
   Note that, a 4xx should never happen if the client follows the
   specification defined here.

   If the request generates a 5xx, the executor SHOULD retry, rather
   than show the error to the LLM.  However, this is up to the
   discretion of the AI Agent designer on how long to wait before
   showing it the error and asking it what to do.

7.1.  OpenAPI Specification

   To be added when spec is closer to complete.

8.  Relationship to MCP

   N-ACT is similar in many ways to the Model Context Protocol (MCP)
   (https://modelcontextprotocol.io/introduction
   (https://modelcontextprotocol.io/introduction)) which is being driven
   by Anthropic, but different in others.  This section covers both
   similarities and differences.  On the whole, the two protocols tackle
   a similar problem (facilitating tool calling and serving tool context
   to LLMs), but differ in their approach (MCP better suited for use
   cases where less designer control is appropriate, and N-ACT for cases
   where more designer control is appropriate).

8.1.  Similarities

   Both MCP and N-ACT support APIs for enumerating tools and invoking
   tools.

   Both MCP and N-ACT can be used to feed context to the LLM at run-
   time.

8.2.  Differences

   The biggest difference is the assumption in control.  N-ACT is very
   much targeted at use cases where there is a designer persona crafting
   an operating procedure.  Consequently, the tool enumeration API is
   consumed by traditional software in N-ACT, enabling the designer to
   perform the process of tool selection and design of the operating
   procedure, both at design time.  In MCP, the tool enumeration API is
   primarily consumed by the AI Agent at run-time.  For this reason, MCP
   has the idea of progressive tool disclosure that happens on the
   server side, in order to reduce model context.  N-ACT, on the other
   hand, assumes progressive tool disclosure happens as a consequnce of
   a design time operation, and thus, in simple terms, is client side.




Rosenberg & White         Expires 22 April 2026                [Page 21]

Internet-Draft                    N-ACT                     October 2025


   In MCP, the logic for progressive tool disclosure is distributed in
   cases where there are multiple MCP servers, with each server
   executing its own, non-standardized logic for progressive tool
   disclosure (though the protocol does not require this behavior, it is
   purportedly one of the main reasons for the session oriented aspect
   of the protocol).  In N-ACT, the logic for progressive tool
   disclosure lives in the AI Agent, with the logic being crafted at
   design-time by the designer.  In this way, N-ACT is more compatible
   with Anthropic's skills concept, than it is with its MCP protocol.
   Indeed, N-ACT could be viewed as the offspring of skills and MCP, by
   adding over-the-wire tool calling to skills.

   These foundational differences have consequences in the other parts
   of the protocols.

   MCP is session oriented.  A session oriented protocol is required
   when the server is responsible for progressive tool disclosure.
   N-ACT is stateless, because it is not performing server side
   progressive tool disclosure.

   MCP uses JSON-RPC and runs over either stdio (for local usage on a
   PC) or streamable HTTP for network connections.  N-ACT is a normal
   REST API and uses traditional HTTPS and OpenAPI specifications.

   MCP typically requires a dedicated server that provides its
   functionality (termination of the persistent connection, session
   handling, and gateway to existing APIs).  N-ACT is designed to be
   added to existing API servers as just another API - albeit ones
   optimized for LLMs.

   MCP APIs are not easily consumeable by non-LLM applications.  N-ACT
   APIs are just APIs and can be consumed by both traditional software
   and AI Agents.

9.  Informative References

   [I-D.rosenberg-ai-protocols]
              Rosenberg, J. and C. F. Jennings, "Framework, Use Cases
              and Requirements for AI Agent Protocols", Work in
              Progress, Internet-Draft, draft-rosenberg-ai-protocols-00,
              5 May 2025, <https://datatracker.ietf.org/doc/html/draft-
              rosenberg-ai-protocols-00>.

Authors' Addresses

   Jonathan Rosenberg
   Five9
   Email: jdrosen@jdrosen.net



Rosenberg & White         Expires 22 April 2026                [Page 22]

Internet-Draft                    N-ACT                     October 2025


   Pat White
   Bitwave
   Email: pat.white@traego.com
















































Rosenberg & White         Expires 22 April 2026                [Page 23]


name: draft-rosenberg-aiproto-framework
rev: 00
title: Framework, Use Cases and Requirements for AI Agent Protocols
time: 2025-10-20T02:25:23Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T02:25:23Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "Policy/governance", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:05.127705+00:00
abstract:
AI Agents are software applications that utilize Large Language
   Models (LLM)s to interact with humans (or other AI Agents) for
   purposes of performing tasks.  AI Agents can make use of resources -
   including APIs and documents - to perform those tasks, and are
   capable of reasoning about which resources to use.  To facilitate AI
   agent operation, AI agents need to communicate with users, and then
   interact with other resources over the Internet, including APIs and
   other AI agents.  This document describes a framework for AI Agent
   communications on the Internet, identifying the various protocols
   that come into play.  It introduces use cases that motivate features
   and functions that need to be present in those protocols.  It also
   provides a brief survey of existing work in standardizing AI agent
   protocols, including the Model Context Protocol (MCP), the Agent to
   Agent Protocol (A2A) and the Agntcy Framework, and describes how
   those works fit into this framework.  The primary objective of this
   document is to set the stage for possible standards activity at the
   IETF in this space.

full_text:
Network Working Group                                       J. Rosenberg
Internet-Draft                                                     Five9
Intended status: Informational                               C. Jennings
Expires: 22 April 2026                                             Cisco
                                                         19 October 2025


      Framework, Use Cases and Requirements for AI Agent Protocols
                  draft-rosenberg-aiproto-framework-00

Abstract

   AI Agents are software applications that utilize Large Language
   Models (LLM)s to interact with humans (or other AI Agents) for
   purposes of performing tasks.  AI Agents can make use of resources -
   including APIs and documents - to perform those tasks, and are
   capable of reasoning about which resources to use.  To facilitate AI
   agent operation, AI agents need to communicate with users, and then
   interact with other resources over the Internet, including APIs and
   other AI agents.  This document describes a framework for AI Agent
   communications on the Internet, identifying the various protocols
   that come into play.  It introduces use cases that motivate features
   and functions that need to be present in those protocols.  It also
   provides a brief survey of existing work in standardizing AI agent
   protocols, including the Model Context Protocol (MCP), the Agent to
   Agent Protocol (A2A) and the Agntcy Framework, and describes how
   those works fit into this framework.  The primary objective of this
   document is to set the stage for possible standards activity at the
   IETF in this space.

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 22 April 2026.





Rosenberg & Jennings      Expires 22 April 2026                 [Page 1]

Internet-Draft                AI Protocols                  October 2025


Copyright Notice

   Copyright (c) 2025 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  The Framework . . . . . . . . . . . . . . . . . . . . . . . .   5
     2.1.  AI Agent to User  . . . . . . . . . . . . . . . . . . . .   6
       2.1.1.  User Initiated  . . . . . . . . . . . . . . . . . . .   6
       2.1.2.  AI Agent Initiated  . . . . . . . . . . . . . . . . .   7
     2.2.  AI Agent to API . . . . . . . . . . . . . . . . . . . . .   7
     2.3.  AI Agent to AI Agent  . . . . . . . . . . . . . . . . . .   8
   3.  Protocol Requirements and Considerations  . . . . . . . . . .  11
     3.1.  User to AI Agent  . . . . . . . . . . . . . . . . . . . .  11
       3.1.1.  Authentication  . . . . . . . . . . . . . . . . . . .  11
     3.2.  AI Agent to API . . . . . . . . . . . . . . . . . . . . .  12
       3.2.1.  Discovery . . . . . . . . . . . . . . . . . . . . . .  12
       3.2.2.  AuthN and AuthZ on APIs . . . . . . . . . . . . . . .  12
       3.2.3.  User Confirmation . . . . . . . . . . . . . . . . . .  15
       3.2.4.  API Customization for AI Agents . . . . . . . . . . .  16
     3.3.  AI Agent to AI Agent  . . . . . . . . . . . . . . . . . .  16
       3.3.1.  Discovery . . . . . . . . . . . . . . . . . . . . . .  17
       3.3.2.  Routing and Connection  . . . . . . . . . . . . . . .  17
       3.3.3.  Lifecycle Management  . . . . . . . . . . . . . . . .  18
       3.3.4.  Data Transferrance  . . . . . . . . . . . . . . . . .  20
       3.3.5.  Authentication and Authorization  . . . . . . . . . .  22
       3.3.6.  User Confirmation . . . . . . . . . . . . . . . . . .  23
       3.3.7.  Prompt Injection Attacks  . . . . . . . . . . . . . .  23
   4.  Analysis of Existing Protocols  . . . . . . . . . . . . . . .  23
     4.1.  MCP . . . . . . . . . . . . . . . . . . . . . . . . . . .  24
     4.2.  A2A . . . . . . . . . . . . . . . . . . . . . . . . . . .  24
     4.3.  Agntcy  . . . . . . . . . . . . . . . . . . . . . . . . .  25
   5.  Conclusions . . . . . . . . . . . . . . . . . . . . . . . . .  25
   6.  Informative References  . . . . . . . . . . . . . . . . . . .  26
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  26





Rosenberg & Jennings      Expires 22 April 2026                 [Page 2]

Internet-Draft                AI Protocols                  October 2025


1.  Introduction

   AI Agents have recently generated a significant amount of industry
   interest.  They are software applications that utilize Large Language
   Models (LLM)s to interact with humans (or other AI Agents) for
   purposes of performing tasks.  Just a few examples of AI Agents are:

   *  A travel AI Agent which can help users search for travel
      destinations based on preferences, compare flight and hotel costs,
      make bookings, and adjust plans

   *  A loan handling agent that can help users take out a loan.  The AI
      Agent can access a users salary information, credit history and
      then interact with the user to identify the right loan for the
      target use case the customer has in mind

   *  A shopping agent for clothing, that can listen to user preferences
      and interests, look at prior purchases, and show users different
      options, ultimately helping a user find the right sports coat for
      an event

   Technically, AI agents are built using Large Language Models (LLMs)
   such as GPT4o-mini, Gemini, Anthropic, and so on.  These models are
   given prompts, to which they can reply with completions.  To creates
   an AI agent, complex prompts are constructed that contain relevant
   documentation, descriptions of tools they can use (such as APIs to
   read or write information), grounding rules and guidelines, along
   with input from the user.  The AI Agent then makes decisions about
   whether to interact further with the user for more information,
   whether to invoke an API to retrieve information, or to perform an
   action that might require human confirmation (such as booking a
   flight).

   AI Agents are often built to be task specific.  In the examples
   above, each AI agent was uniquely tuned (primarily through its prompt
   structure, though perhaps also with fine-tuned models) to the
   specific task at hand.  This introduces a problem.  A user
   interacting with one agent might require the agent to do something
   which it is not tuned to do, requiring the agent to interact with a
   different agent that has the appropriate skills.  This is called
   agent federation or Agent-to-Agent communication.

   The result of this is a system which has many different software
   elements communicating over the Internet.  This introduces the
   potential need for additional areas of protocol standardization to
   facilitate deployment of these AI Agent systems.  This need has been
   broadly recognized already in the industry, resulting in a rapid
   stream of open source and protocol efforts.  Examples include the



Rosenberg & Jennings      Expires 22 April 2026                 [Page 3]

Internet-Draft                AI Protocols                  October 2025


   Model Context Protocol (MCP) (https://modelcontextprotocol.io/
   introduction (https://modelcontextprotocol.io/introduction)) which is
   being driven by Anthropic, the Agent2Agent (A2A) Protocol, driven by
   Google (https://google.github.io/A2A/#/documentation?id=agent2agent-
   protocol-a2a (https://google.github.io/
   A2A/#/documentation?id=agent2agent-protocol-a2a)) and the Agntcy
   framework, driven by Cisco (https://agntcy.org/
   (https://agntcy.org/)).  There are certainly others.  These efforts
   cover parts of the standardization spectrum, partially overlapping in
   scope in some cases.

   With the potential for significant adoption of AI Agents across the
   Internet, these protocols may become the foundation for the next wave
   of Internet communication technologies, especially between domains.
   Indeed, we can think of inter-domain protocol stack as being composed
   of IP [RFC791], UDP [RFC768], TCP [RFC9293], and QUIC [RFC9000] as
   the foundation for communicating between hosts.  The next layer -
   HTTP [RFC9114], SIP [RFC3261] and RTP [RFC3550] are the main inter-
   domain protocols at the application layer.  If AI Agents are the new
   way in which users interact with applications, then the protocols
   between them could represent the next layer of this stack.

   +-----------------+    we are now here  +-----------------+
   |     AI Agent    |<------------------->|     AI Agent    |
   +-----------------+                     +-----------------+

   +-----------------+   HTTP, SIP, RTP    +-----------------+
   |    Application  |<------------------->|    Application  |
   +-----------------+                     +-----------------+

   +-----------------+  IP, TCP, UDP, QUIC +-----------------+
   |      Host       |<------------------->|      Host       |
   +-----------------+                     +-----------------+

         Figure 1: Are AI Protocols the next layer of the modern IP
                              Protocol Stack?

   This means they must be designed with care, and deeply consider the
   necessary security, privacy, and extensibility requirements needed
   for broad adoption.  Most importantly, they must consider the needs
   of the humans who ultimately use these systems, and be designed to
   manage the harms that may be introduced through inaccuracy and
   hallucination that are an unavoidable consequence of using LLMs.

   This document provides a framework to aid in standardization efforts
   in this area.  It identifies the different protocols which come into
   play, and considers different variations in their use cases.  It
   discusses requirements for these protocols, covering functionality



Rosenberg & Jennings      Expires 22 April 2026                 [Page 4]

Internet-Draft                AI Protocols                  October 2025


   along with considerations for privacy, security and hallucination
   management.  The document also includes a brief overview of some of
   the existing protocols and open source efforts, and maps them into
   the framework provided here.

2.  The Framework

   The overall architecture is shown in Figure 2.

             Domain A                   Domain B
   ..............................    ................
   .                            .    .              .
   .                            .    .              .
   .                +---------+ .    . +---------+  .
   .                |         | .    . |         |  .
   .                |         | .    . |         |  .
   .                | A APIs  | .  +-.-+ B APIs  |  .
   .                |         | .  | . |         |  .
   .                |         | .  | . |         |  .
   .                +----+----+ .  | . +----+----+  .
   .                     |      .  | .      |       .
   .                     |      .  | .      |       .
   . +---------+    +----+----+ .  | . +----+----+  .
   . |         |    |         | .  | . |         |  .
   . |         |    |         +-.--+ . |         |  .
   . | User A  +----+AI Agent +-.----.-+AI Agent |  .
   . |         |    |    A    | .    . |    B    |  .
   . |         |    |         +-.-+  . |         |  .
   . +---------+    +-+--+----+ . |  . +----+----+  .
   .                  |  |      . |  .      |       .
   .      +-----------+  |      . |  .      |       .
   .      |              |      . |  .      |       .
   . +----+----+    +----+----+ . |  . +----+----+  .
   . |         |    |         | . |  . |         |  .
   . |         |    |         | . |  . |         |  .
   . | User S  |    | AI Agent| . +--.-+  User B |  .
   . |         |    |    Z    | .    . |         |  .
   . |         |    |         | .    . |         |  .
   . +---------+    +---------+ .    . +---------+  .
   .                            .    .              .
   .                            .    .              .
   ..............................    ................

                   Figure 2: AI Agent Protocol Framework

   The framework focuses on the AI agent in domain A - "AI Agent A".
   This AI agent is providing services to a user, User A.  To do that,
   User A communicates with AI agent A over voice, chat or other



Rosenberg & Jennings      Expires 22 April 2026                 [Page 5]

Internet-Draft                AI Protocols                  October 2025


   channels.  AI Agent A supports this user by invoking APIs - either in
   its own domain, or in another.  AI Agent A might also communicate
   with other users - ones in domain A, or outside of it.  Consequently,
   there are broadly speaking three classes of protocols in play: (1)
   Protocols for human to AI Agent, (2) Protocols for AI agents to
   invoke APIs, and (3) Protocols for AI agents to talk to each other.

2.1.  AI Agent to User

   We refer to this protocol as the "User to Agent Communications
   Protocol".  These communications can be initiated by the user, or
   initiated by the agent.

2.1.1.  User Initiated

   The process generally starts when the user initiates communications
   with its AI Agent.

   User A communicates to AI agent 1 over some kind of communications
   technology.  It could be a via a phone call, or via voice chat via a
   widget on a web page or inside a mobile or desktop app.  It could be
   via chat, using a chat widget in a webpage, or via SMS, RCS or
   applications like WhatsApp or Facebook Messenger.  These chat apps
   provide a variety of content types, including text, images,
   carousels, links, videos, and interactive html cards.  The
   interaction could be via video as well.  Often video communications
   are one way, from the user to the AI agent, to facilitate "see what I
   see" interactions.  Or, it can be two way, in which case the user
   might see an avatar of the AI agent.

   The communications could also be multi-modal.  User A1 could be
   talking to AI Agent 1 using voice, while at the same time, receiving
   texts from the AI Agent with information or links.  User A1 could be
   using voice and video concurrently.  User A could be using a web
   widget for chat and multimedia content, while using a phone call to
   communicate with the same agent.

   In all of these cases, User A has a relationship with AI Agent 1
   (typically by being a user of the domain or site in which it
   resides).  This is why the user is shown within the domain boundary
   in the picture.

   The protocols and technologies used for this communication are well
   established today, and it is not apparent that there is any
   additional standards work required to support AI agents.  Indeed,
   users are already able to communicate with AI agents over these
   channels today.




Rosenberg & Jennings      Expires 22 April 2026                 [Page 6]

Internet-Draft                AI Protocols                  October 2025


2.1.2.  AI Agent Initiated

   In some cases, AI agent 1 may find that - in order to do its job - it
   needs to communicate with another human user.

   As one example, User A may be interacting with an AI agent providing
   loans.  The user might have a request for a lowered loan rate based
   on their holdings with the bank.  The AI agent could be programmed to
   always reach out to a human in order to approve reduced load rates.
   When the conversation between User A and the loan AI agent reaches
   this point, the AI agent needs to communicate with the human
   supervisor to gain this approval.  This is User S in the diagram
   above.

   In the most common use cases, the human user would be in the same
   domain as the AI agent.  This is the case for our loan example above.
   In these cases, the AI agent could use email, voice, chat or other
   communications techniques which are known to be used by User B.
   Often, User B would be a contact center agent connected to the same
   platform facilitating operation of the agent.  In other cases, they
   are on separate communications systems.  The administrators of domain
   A would be required to configure the systems to communicate with each
   other using standard protocols ala SIP or SMTP.  It may also be the
   case that the communications system user by User S exposes APIs that
   enable sending of messages, in which case the interface actually
   looks like one between an AI agent and an API.

   It could be the case that the human user is in another administrative
   domain entirely.  In this case, AI agent may only have an email
   address or phone number for the user to contact, and not have further
   information about their capabilities.  This is the case for AI Agent
   A communicating with User B.

2.2.  AI Agent to API

   For AI Agent A to do its job, it will require access to APIs.  Those
   APIs can provide read-only information - for example a product
   catalog or list of hotel properties.  The API could take actions, for
   example an API to book a flight, create a case, or start a product
   return.  These APIs could be intra-domain or inter-domain.

   In the intra-domain case, the APIs are administered by the same
   organizational entity that is providing the agent.  For example, a
   travel booking site might run an AI agent for such bookings.  The
   site has microservices which have APIs for retrieving travel
   destinations and airports, booking flights, or creating trip records.
   In these cases, the APIs are intradomain.




Rosenberg & Jennings      Expires 22 April 2026                 [Page 7]

Internet-Draft                AI Protocols                  October 2025


   Alternatively, the APIs could reside outside of domain A.  Once
   again, using the travel booking example, the travel booking site
   might invoke APIs offered by partner airlines to book the flights.
   In the case of inter-domain APIs, there are two sub-cases.  In one
   case, it is domain A which has the relationship with domain B, and
   the APIs are invoked using service accounts that are not specific to
   User A.  That said, they could be operating on behalf of user A and
   thus be limited or constrained based on User A's data and
   permissions.  In the second sub-case, the AI Agent is operating
   directly on behalf of User A, using a token granted to the AI agent
   by an OAuth flow performed by user A.  This could happen in cases
   where there is not necessarily a business relationship between domain
   A and domain B, but instead a relationship between user A and domain
   B.  Again using the travel booking agent as an example, User A might
   have accounts with United Airlines and Delta Airlines, both of which
   expose APIs for booking flights, obtaining flight information, and
   accessing frequent flier information.  User A could authorize AI
   Agent A to access both United and Delta on his behalf.  The AI Agent
   could then retrieve information from both, compare flight options and
   costs, and then execute flight bookings.  In this case, the AI agent
   has no advanced knowledge of the APIs offered by United or Delta, and
   needs to learn what they are and have enough information to know how
   to use them appropriately.

2.3.  AI Agent to AI Agent

   The final piece of the framework is AI agent to AI Agent.  This is
   perhaps the most interesting of these communications protocols.  As
   with most of the other protocols, they can be intra-domain or inter-
   domain.

   For an intra-domain example, consider a bank with several lines of
   business.  They have a loan department, a wealth management
   department, a private equity investment department, and a personal
   banking department.  A particular user - perhaps a customer of the
   personal banking department - has an account with the bank.  While
   chatting with the personal banking agent, the user inquires about
   loans.  In this case, the banking agent recognizes that it does not
   have the required expertise, and connects the user with the loan AI
   agent (agent Z in the diagram above).

   In a similar use case, User A is communicating with the personal
   banking agent, and requests to close out all of their accounts and
   have a check issued to them.  The bank has employed a different AI
   agent - the "closure agent" which runs through a complex workflow
   required to close down a customer account.  This agent might invoke
   several APIs to close accounts, update databases, and send out emails
   and texts to the user.  In this case, User A doesn't actually chat



Rosenberg & Jennings      Expires 22 April 2026                 [Page 8]

Internet-Draft                AI Protocols                  October 2025


   with the closure agent.  The closure agent instead executes a complex
   task which involves reasoning, API invocation and possible
   communications with humans.

   Both of these are intra-domain cases.  Inter-domain cases are
   similar.  If we once again consider the travel AI Agent A, that AI
   agent might assist the user in selecting travel destinations and pick
   dates.  To actually book flights, the travel AI Agent A might connect
   the user to the flight AI Agent B within the airline.  Like the API
   case, there are two distinct relationships that are possible.  Domain
   A might have the relationship with domain B, in which case the
   authorization tokens used between them are service accounts and not
   specific to User A.  Alternatively, it is user A which might have the
   relationship with domain B and its AI Agent.  In that case, User A
   would need to grant domain A access to the AI Agent in domain B,
   giving it permissions to communicate and take certain actions.

   So far, we've been vague about the notion of how user A - having
   started is communications with AI Agent A - is connected to AI Agents
   Z or B.  We can envision a finite set of techniques, which mirror how
   this would work when transferred a user between human agents in a
   contact center:

   1.  Blind Transfer: In this case, User A is literally redirected from
       AI Agent A to the receiving agent, AI Agent Z.  In a blind
       transfer, AI Agent A is not a participant in, and has no access
       to, the communications with AI Agent Z after the transfer.
       However, there could be contextual information transferred from
       AI Agent A to AI Agent Z.  This could be transcript history, API
       requests and resulting data, and any other context which had
       previously been known to AI Agent A.

   2.  Supervised Transfer: In this case, User A is told by AI Agent A
       that they will be connected to AI Agent Z.  TO do that, AI agent
       A "conferences" in AI Agent Z, so that now all three are together
       in a group conversation.  AI Agent A would communicate with agent
       Z - in a format comprehensible to user A - that a transfer is
       taking place.  This aspect of the supervised transfer is for the
       benefit of the end user, giving them comfort that a transfer is
       happening and making sure they know that the receiving AI Agent
       has context.  Of course, there may additionally be transfer of
       programmatic information in the same way described for the blind
       transfer case.  Once the introduction has completed, AI Agent A
       drops and now the user is talking solely to agent Z.

   3.  Sidebar: In this case, AI agent A "talks" to AI Agent Z, but none
       of that communications is shown to User A.  Instead, it is purely
       to provide AI agent A information it requires in order to



Rosenberg & Jennings      Expires 22 April 2026                 [Page 9]

Internet-Draft                AI Protocols                  October 2025


       continue handling user A.  As an example, we return to our travel
       booking AI agent.  User A asks it, "What are the most popular
       travel destinations for a spring beach vacation?".  AI Agent may
       not have the context to answer this question.  So, it instead
       connects to a travel blog AI Agent, and - in this case - makes
       the same inquiry to it, adding however additional context about
       User A.  It asks the travel blog agent, "For people living in New
       York, what are the most popular travel destinations for a spring
       beach vacation?  Please format your response in JSON."  When the
       results come back - here in structured data format - AI Agent A
       (the travel booking agent) might lookup each city in a database
       to retrieve a photo, and then render a photo carousel to the user
       with the three top cities.  In this example, the sidebar is a
       single back and forth.  There can be more complex cases where
       multiple back and forths are required to provide AI Agent A the
       information it needs.

   4.  Conference: In this case, AI agent A has AI agent Z join a group
       conversation, which then involves User A, AI Agent A and AI Agent
       Z.  The three of them converse together.  Both AI agent A and AI
       Agent Z are able to see all messages.  The agents would need to
       be programmed (via their prompting) to try and determine whether
       each user utterance is directed at them, or the other AI agent.
       Similarly, it would need to know whether it is required to
       respond to, or just add to its context, utterances sent by the
       other AI Agent.

   5.  Passthrough: In this case, User A connects to AI Agent A, which
       then realizes it wants to connect the user to AI Agent Z.  To do
       that, it acts as a proxy, relaying content from AI Agent Z to
       User A, and relaying content from User A to AI Agent Z.  The AI
       Agent doesn't take action on the content, but it might store it
       for contextual history.  In SIP terminology, this can be
       considered a "B2BUA".

   It is worth noting that these variations are all also possible in the
   case where it is User S is being added to the conversation, and not
   AI Agent Z.  This has implications on the AI agent to Ai agent
   protocols, as noted in the discussions below.

   We refer to the AI agent which makes the decision to involve a second
   AI Agent as the invoking AI agent.  The AI agent which is then
   brought into the conversation using one of the topologies above, is
   called the invoked AI Agent.







Rosenberg & Jennings      Expires 22 April 2026                [Page 10]

Internet-Draft                AI Protocols                  October 2025


3.  Protocol Requirements and Considerations

   Each of these three areas of protocol - user to AI agent, AI Agent to
   API and AI Agent to AI Agent, have considerations and requirements
   that are important for standardization.

3.1.  User to AI Agent

   As noted above, for the most part, this aspect of communication is
   well covered by industry standards, and is often done via proprietary
   means when the user and AI agent are within the same administrative
   domain.

3.1.1.  Authentication

   One area of particular interest is user authentication.  For many use
   cases, the AI Agent will need to know who the user is.  For a web
   chat bot on a web page, the identity is easily known if the user has
   already logged into the web page.  However, there are many other
   communications channels where the user identity is not so easily
   known.  For example, if the user initiates communications over SMS,
   the AI agent has only the phone number of the originator.  Similarly,
   if it is via a voice call on the PSTN, there is nothing but the
   caller ID.  Even for web chat, the hosting web site might not support
   authentication.  A great example of this are websites for services
   like plumbing or home repair.  Users might be customers of these
   providers, but the website doesn't have traditional authentication
   techniques.

   In all of these cases, authentication needs to take place through the
   communications channel, often with proof of knowledge demonstrations
   by the end user.  This is how it is done when the agent is an actual
   human and not an AI.  When a user calls their plumber, the user
   provides their account number, or even just their name and address.
   For other services, such as a bank or healthcare provider, more
   complex authentication is required.  Usually, multiple pieces of
   personally identifying information are required.  When calling a
   doctor, the patient's zip code, name, and date of birth may all be
   required.

   These forms of authentication introduce additional complexity for the
   AI agent to API and AI agent to AI Agent communications.  This
   authenticated identity needs to be communicated.  This is noted in
   sections below.







Rosenberg & Jennings      Expires 22 April 2026                [Page 11]

Internet-Draft                AI Protocols                  October 2025


3.2.  AI Agent to API

   The first question everyone asks when considering this area is - do
   we need new standards at all?

   After all, there are already standards for APIs, primarily using
   REST.  Standards exist for describing REST APIs, and indeed they
   contain descriptive information which can be consumed by an LLM to
   determine how to invoke the API.  Indeed, early versions of AI agents
   have been built by just pointing them at (or uploading) OpenAPI yaml
   specifications, resulting in functional AI Agents.  However, when the
   fuller scope of use cases are considered, several additional
   considerations come to light.

3.2.1.  Discovery

   Initial versions of AI agents required manual upload of OpenAPI
   specifications.  This can be improved through discovery techniques
   which allow AI agents to quickly find and utilize such
   specifications.

   Discovery can happen for intra-domain cases - where it is simpler -
   or for inter-domain cases.  For inter-domain cases, a primary
   consideration is one of authentication and access.  An AI agent won't
   in general just be allowed to invoke any public API it discovers on
   the Internet.  This might be the case for general public read-only
   services, such as weather or maps.  However, in general, APIs will
   require authentication and authorization, and thus require some pre-
   established relationship.  This means discovery for most APIs is more
   of an issue of well-known locations for openAPI specifications.

3.2.2.  AuthN and AuthZ on APIs

   A significant security consideration is around user authentication
   and authorization.  There are many use cases.

3.2.2.1.  Intra-Domain Service to Service

   In this use case, AI Agent A performs the authentication of the user
   somehow.  As noted above, this may even involve exchange of proof-of-
   knowledge information over a communications channel, in which case
   there is no traditional access or bearer token generated for the end
   user.








Rosenberg & Jennings      Expires 22 April 2026                [Page 12]

Internet-Draft                AI Protocols                  October 2025


   AI Agent A, once it has determined the identity of user A, invokes
   APIs within its own domain.  It invokes these APIs using a service
   account, representing itself as the AI Agent.  The APIs allow the AI
   agent to take action on behalf of any end user within the domain.
   The APIs themselves would need to just contain user identifiers
   embedded with the API operations.

   This use case - which is largely how AI agents work today - requires
   no specific protocol standardization beyond what is possible today.

3.2.2.2.  Intra-Domain OBO

   A significant drawback of the technique in the previous section is
   that it requires the AI agent to have very high privilege access to
   APIs within the domain.  This is perhaps not a major concern for
   prior generates of AI agents whose behaviours were programmed, and
   therefore the risk of malicious users or inaccurate AI was much less.

   But, with AI agents, there are real risks that users could
   maliciously (through prompt injection attacks for example) direct an
   AI agent to invoke APIs affecting other users.  Or, it could
   manipulate the APIs being invoked to do something different than what
   is expected.  Even without malicious intent, an AI agent might make a
   mistake and invoke the wrong API, causing damage to the enterprise.

   A way to address these is to have the AI Agent operate using a lower
   privilege access token - one specifically scoped to the user which
   has been authenticated.  This would prevent against many
   hallucination or prompt injection cases.  In essence, we want to have
   the AI Agent obtain a bearer token which lets them operate on-behalf-
   of (OBO) the end user it is serving.

   This is relatively straightforward when the user has performed normal
   authentication on a web chat bot, and is anyway passing a user token
   to the AI Agent.  The AI Agent can just use that same token for
   invoking downstream APIs, or else use that token to obtain other,
   scope limited tokens from a central authentication service.  However,
   things are more complicated when the user was authenticated using
   proof-of-knowledge via communication channels.  In this case, there
   was never a user token to begin with!











Rosenberg & Jennings      Expires 22 April 2026                [Page 13]

Internet-Draft                AI Protocols                  October 2025


   To support such cases, it is necessary for the AI Agent to obtain a
   token for the user.  To do so, it would ideally communicate with some
   kind of central identity service, providing the information offered
   by the end user (the date of birth, address, and name in the example
   above), and then obtain a token representing that user.  The
   resulting tokens would ideally contain programmatic representations
   of the techniques by which the user was authenticated.  This would
   allow APIs which accept these tokens to perhaps decide that
   additional levels of authentication are required.

   This is common today when dealing with human agents.  A user calling
   their bank to check on open hours may not require any authentication
   at all.  Once the user asks for an account balance, the human agent
   will perform an authentication step by requesting identification
   information from the user.  Account status can then be provided.
   Finally, if the user then asks for a wire transfer, the human agent
   may ask for further authentication, including perhaps having the end
   user receive a text at their mobile number and real a one-time code.

   To support equivalent security, this needs to manifest within
   protocols.  If an AI Agent attempts to invoke an API for which the
   token has insufficient strength of authentication, the API request
   needs to be rejected, and then the AI agent needs to communicate with
   the user to obtain further identification information, and obtain a
   new token with higher privilege.

   Additionally, the meta-data describing the APIs would specify the
   required level of identity verification required to invoke them, so
   that the AI agent can request the information from the user and
   obtain a new token, rather than trying and failing on the prior,
   lower privilege token.

   Could these tokens also be used for inter-domain use cases?  Perhaps.

3.2.2.3.  Inter-Domain OAuth

   Consider User A talking to AI Agent A which is accessing APIs in
   domain B.  In the case where User A has the relationship with domain
   B, the user will grant permissions to AI Agent A with a given scope.
   That scope will restrict the set of APIs which the AI agent is
   allowed to use.  For the AI Agent to operate effectively, it will
   need to know which APIs are accessible for a given scope.  This needs
   to be via both natural language, and likely programmatic
   descriptions.  This would allow the AI Agent behaviour to adjust
   based on what access the user has.






Rosenberg & Jennings      Expires 22 April 2026                [Page 14]

Internet-Draft                AI Protocols                  October 2025


   To give a concrete example, consider again the travel booking AI
   agent.  User A has executed an OAuth grant flow, and granted the AI
   Agent access to look up trips and frequent flier status, but not to
   book trips or modify reservations.  The user might ask the AI Agent,
   "can I change my reservation?" and we want the AI Agent A to be able
   to respond, "I'm sorry, I dont have sufficient permission to perform
   that operation.  I can initiate a flow by which you'll log into the
   airline and grant me that permission.  Would you like me to do that?"
   And then the user response, "what exactly would granting this
   permission do?" and we want the AI to be able to respond along the
   lines of, "The permission I will request - change reservations -
   grants me the ability to modify your reservations on your behalf."
   The user might ask, "are you also allowed to delete them?" and it
   would respond, "Yes, the scope I would request grants me permission
   to delete your reservations.".  The user could even respond, "I don't
   want that.  I want to make sure you cannot delete my reservations".
   If the airline offered a scope which excluded deletions, it could
   respond with, "OK, I'll request permissions only to modify and not
   delete.  Are you ready to grant me those permissions?".  At that
   point, the user would get an OAuth popup asking for modification
   permissions.

   Once those permissions are granted, the AI Agent would need to then
   know the specific APIs available to it at the granted scope.  Indeed,
   as a matter of privacy, domain B might not want AI Agent A to know
   ALL of the APIs it has, it may want to restrict it to just those
   associated with the scopes that its users have granted.  This
   reduction in the amount of detail offered to the AI Agent can also
   help improve AI accuracy, by reducing the amount of extraneous
   information it has access to.

   For this to work as described, we need additional standardization
   allowing natural language descriptions of API scopes to be produced
   by one domain, read by the AI agent in another, and then allow API
   specifications to be conveyed based on granted scopes.

3.2.3.  User Confirmation

   When APIs are for read only, there is low risk of the AI doing the
   wrong thing.  If a user requests information about their flight to
   New York and the AI instead returns the flight to York, this is
   frustrating for the user but not dangerous.  This is not the case for
   APIs that have side effects, including creation, update and delete
   operations on RESTful objects.  For these operations, there is a real
   risk that the AI Agent invokes the wrong API, or invokes it with the
   wrong data.  To reduce this risk, it is important that the user
   provides confirmation, and that this confirmation happen
   programatically, outside of the LLM prompt inference.



Rosenberg & Jennings      Expires 22 April 2026                [Page 15]

Internet-Draft                AI Protocols                  October 2025


   To do that, it will be necessary for the AI Agent system to know
   which APIs require user confirmation, and which do not.  This is a
   decision which can only be made by the API owner.  Consequently,
   there is a need to annotate the APIs with ones that require
   confirmation.  But, it goes beyond this.  Users cannot be expected to
   view a JSON object and confirm its accuracy.  Consequently, for each
   operation that has side effects, the API needs to be adorned with
   user visible names and descriptions of attributes which require
   confirmation, and then a mapping of those into the JSON payloads.
   This would allow the AI model to know that it needs to collect a set
   of data, and then once collected, the AI agent - not the LLM, but
   something programmatic - can render this information to the user, get
   their confirmation, map it into the API, invoke the API and then feed
   the results into the LLM.  This provides 100% guarantee that the
   system is doing what the user wants, and not something else.  All of
   this requires additional protocol machinery to convey this
   information and mappings, and is not covered today by typical API
   specifications.

3.2.4.  API Customization for AI Agents

   REST APIs today are crafted by humans, meant to be understood by
   humans and then implemented by humans into code that exercises them.
   Consequently, they are often highly complex, with many parameters and
   variations.  Using those APIs - and their corresponding
   specifications - introduces a problem.  While AIs can understand
   them, they may contain more information than is strictly needed,
   increasing the risk of inaccuracy or hallucination.  An alternative
   model is to have simplified APIs - ones better aligned to the
   information that the AI Agent needs to collect from the humans in the
   conversation.

   These specifications will also require descriptions that are consumed
   by the LLM to understand how to use them.  Typically, content and
   prompts are ideally tuned to a specific model for optimal outcomes.
   One could imagine that API provider B might have several variations
   of the API specifications and descriptions optimized for different
   models.  Consequently, the protocol for retrieving them would need to
   communicate the LLM models used by domain A to retrieve the optimal
   descriptions.

   It is not entirely clear this level of customization is needed, but
   it is worth calling out as something unique for AI Agents.

3.3.  AI Agent to AI Agent

   There are many considerations for standardization in this area.




Rosenberg & Jennings      Expires 22 April 2026                [Page 16]

Internet-Draft                AI Protocols                  October 2025


3.3.1.  Discovery

   One possible area for standardization is discovery - how do agents
   discover the availability of other agents.  Discovery is often not
   needed however.  For intra-domain cases, most of the agents are well
   known to administrators, and they can be configured into the system.
   For inter-domain cases, discovery is more interesting.  However, as
   with AI Agent to API discovery, it is usually constrained by the
   requirements for authentication and access control.  AI Agent A
   cannot communicate with other agents without a prior established
   security relationship, in which case discovery is less of a
   consideration.

   Indeed, a high level of trust is required for one AI agent to talk to
   another one.  A malicious AI agent that is discovered and used, could
   perform prompt injection attacks, possibly granting it access to the
   APIs that the other agent has access to.  It could inject malicious
   or unwanted content that is passed on to the end user.

3.3.2.  Routing and Connection

   For one AI Agent to communicate with another one, it needs to know
   when to route communications to that agent.  This requires
   information to be communicated from the agent being invoked, to the
   invoking agent.  This information needs to be sufficient for
   ingestion by a LLM to make a routing decision, and likely requires
   text in natural language format to be communicated.  This also raises
   considerations around languages.  One can imagine that AI Agent A
   operates in Spanish, and would prefer to receive information to
   facilitate routing in Spanish as well.

   Capabilities are also relevant for routing.  One important area of
   capability discovery is channel capability.  If AI Agent A is
   communicating with a user using voice from a web page, and AI Agent A
   wishes to engage AI Agent B using passthrough mode, or even transfer,
   it will need to know whether or not possible agents support voice.
   As with other areas of capabilities, there is a possibility for
   negotiation.  For example, AI Agent A might currently be serving user
   A using voice chat on a web page, but it can also support web chat.
   If AI Agent Z supports only web chat, it can be utilized and the
   communications session downgraded to web chat.










Rosenberg & Jennings      Expires 22 April 2026                [Page 17]

Internet-Draft                AI Protocols                  October 2025


   Each of these channels will come with their own parameters defining
   capabilities which need to be considered when both selecting the
   agent, and connecting to it.  If User A is connecting to AI Agent A
   using web chat, the web chat widget might support images, carousels
   and links, but might not support embedded videos.  When AI Agent Z is
   connected, it needs to know that it cannot send embedded videos.
   Furthermore, that agent cannot process images uploaded by users, that
   feature needs to be disabled from the UI used by the agent.

3.3.3.  Lifecycle Management

   A key functional component of the inter-agent protocol is agent
   lifecycle.  The connection with AI Agent A will go through states,
   initiated when the connection is first made, and then eventually
   terminate once the task for which it was engaged has been completed.
   There may be intermediate states as well.  For example, if the
   downstream agent needs to perform tasks which have asynchronous
   components, the agent may need to go into a suspended mode while it
   waits for a response.  This needs to be passed upstream to the
   invoking agent, so that it can take the appropriate action.  It may
   elect to suspend itself as well, or may choose to retake control and
   engage with the user in other conversations while the other AI Agent
   works to complete its tasks.

   There will need to be functionality in the protocol allowing the
   invoking agent to terminate communications with the target agent,
   either at the behest of the end user or under its own control.

   Different agents may also support different types of lifecycles,
   which needs to be communicated.  For example, AI agents can have
   different properties:

   1.  Transactional vs. Conversational: A transactional AI agent
       receives an instruction in natural language format that requests
       a task to be performed.  Once it performs it, the response comes
       back.  There is no back-and-forth with the requester of the task.
       As an example, an AI agent may provide transactional capabilities
       for image creation, sending a request along the lines of "Create
       an image of a solar system with three green planets orbiting a
       red sun, taken from above".  The response that comes back is the
       requested image.  An AI Agent might support transactional
       interactions, allowing back and forth with the end user.  This is
       possible with the image generation example, where the user could
       receive the resulting image and then request modifications.

   2.  Synchronous vs. Asynchronous: A Synchronous AI agent executes
       communications sessions with a discrete begin and end,
       interacting back and forth with the invoker.  There may be



Rosenberg & Jennings      Expires 22 April 2026                [Page 18]

Internet-Draft                AI Protocols                  October 2025


       timeouts if there is inactivity.  For these type of agents, all
       of the work performed by the AI Agent occurs in real-time and can
       happen during the lifetime of the session.  The image generation
       agent is a good example of it.  An AI Agent that is asynchronous
       needs to perform actions which have a lengthy or even potentially
       unbounded amount of time to complete.  This can happen when tasks
       take significant computation (for example, a research AI Agent
       which analyzes documents and prepares a summary, which can take
       several hours).  This can also happen when an AI Agent needs to
       engage with a human.  Using our loan example, AI Agent Z may be a
       loan approval AI Agent, and depending on the requested loan, may
       require approval from a human.  If the request is made off-hours,
       a human may not be available until the next morning to service
       the request.

   These two properties are orthogonal.  An AI Agent can be
   transactional and synchronous - our AI image generation example
   above.  But it can also be transactional and asynchronous.  A good
   example of such an AI agent is an HR AI Agent used to approve a hire.
   This AI Agent would take a simple transactional request - "Obtain
   approval or disapproval to extend an offer to candidate Bharathi
   Ramachandran".  This requires the AI Agent to gather data by invoking
   APIs and may require human approval from the head of HR.  This can
   take potentially an unbounded amount of time.

   For inter AI agents to work, these characteristics need to be
   transferred programatically from one agent to another, which then
   guides its operation.

   Support for asynchronous AI Agents in particular requires additional
   protocol machinery.  There is a need for some kind of callback, in
   which AI Agent Z can reconnect to AI Agent A.  The end user may have
   also disconnected, requiring a reconnection.  Whether such
   reconnection is possible or not depends on the communications
   channels and user configuration.  For example, if User A was
   communicating with AI Agent A - an internal IT bot supporting a wide
   range of employee needs - using SMS, and user A asks AI Agent A to
   approve the hire, this might trigger AI Agent A to reach out to the
   HR AI Agent noted above.  Once approval is obtain, AI Agent Z needs
   to re-initiate messaging backwards towards AI Agent A.  AI Agent A
   then needs to send an SMS back to the end user.  If, on the other
   hand, user A was connected to AI Agent A using web chat, reconnection
   to user A may not be possible.  This could perhaps mean that the HR
   agent cannot be invoked at all, and an error needs to be returned to
   the user.  Or, the HR AI Agent may support a modality wherein it
   emails the employee with the approval decision.  These constraints
   and possibilities must be negotiated between agents to drive
   appropriate behavior.



Rosenberg & Jennings      Expires 22 April 2026                [Page 19]

Internet-Draft                AI Protocols                  October 2025


   Asynchronous agents might also support polling for state updates,
   wherein the end user can request updates on progress.  This will
   require protocol machinery.  Polling for updates could happen several
   different ways.  During an active synchronous session between user A
   and AI Agent A, the user can request an operation that triggers a
   transactional async task to be sent to AI Agent Z (again the HR
   approval agent in our use case).  The end user might continue its
   dialog with AI Agent A (the IT AI Agent) inquiring about an open
   ticket for a computer problem.  During that chat, the user might ask
   for an update.  For example, "Has the HR approval been completed yet
   by the way?".  AI Agent A needs to then poll for an update from AI
   Agent Z so it can return the result.  In this case, the interaction
   between AI Agent A and Z is more like an API.  AI Agent A may not
   even remember (due to a failure or reconnection) that it has
   outstanding tasks with AI Agent Z.  This requires API support for
   enumeration of pending tasks on downstream agents.

3.3.4.  Data Transferrance

   During the lifetime of the interconnection between agents,
   information will need to be transferred back and forth.  The protocol
   will need to allow for this.

   One dimension of protocol requirements are related to capabilities,
   already noted in the section above.

3.3.4.1.  Context Transfer

   Another aspect of data transferrance is context transfer.  When AI
   Agent A first connects to AI Agent Z, it will likely want to transfer
   context about the user, about the conversation, about itself, and
   about the task that was requested by the end user.  This information
   will be necessary for the invoked agent to be effective.  Coming back
   to our travel use case, when the travel AI Agent invokes the flight
   booking agent, the flight booking agent will need to know:

   1.  The name and other contact information for the end user (see
       discussion below on authentication and authorization),

   2.  The name and description of the invoking AI agent, so that the
       flight booking agent can greet appropriately.  For example, "Hi
       Alice, I'm the United Airlines agent.  I understand that you've
       been booking a trip with Expedia and need a flight?"

   3.  The transcript of the conversation to date.  For example, if the
       user had been debating a few options for departure cities and
       finally settled on New York to LA (instead of Philadelphia to LA)
       this could be relevant for the booking agent to convey additional



Rosenberg & Jennings      Expires 22 April 2026                [Page 20]

Internet-Draft                AI Protocols                  October 2025


       information not known to the travel agent.  For example, "Hi
       Alice, I can help book your flight from New York to LA.  However,
       you may not have been aware that flight costs departing from New
       York are higher in the summer, and you'd probably be better off
       traveling from Philadelphia on that day."

   To facilitate context transfer, the receiving AI Agent may want to
   convey, programmatically, to the invoking AI Agent, the set of
   contextual information it is prepared to process.  It might want to
   only see the conversation transcript.  Or, it might want user
   background.  There may be syntactic constraints, such as context
   length and character sets.  Context transfer also introduces security
   considerations, as noted below.

3.3.4.2.  Mid-Session Data Transfer

   For conversational sessions, messages will be sent back and forth
   amongst the participants (user A, AI Agent A and AI Agent Z).  The
   end user will originate new text messages, images or other user
   provided content, which are in essence targeted at the invoked AI
   agent, Agent Z.  The invoked AI Agent will similarly wish to transfer
   messages back to the end user.  In the case where AI Agent A is in a
   conference with AI Agent Z and the end user - or when it is operating
   in passthrough mode - these messages need to be tagged as being sent
   by the user, or targeted to the user, so that they do not trigger
   responses from AI Agent A.  However, there will be meta-data that
   needs to be communicated as well.  AI Agent Z, when it completes its
   task, needs to convey this information back towards AI Agent A.  This
   is meta-data and not meant to be rendered to the end user.
   Similarly, if AI Agent Z is asked to perform a task whose output is
   programmatic and meant to be consumed by AI Agent A, then it needs to
   be tagged in this way.  As an example, when the flight booking AI
   Agent has completed its flight booking, it needs to pass information
   back to the travel AI Agent containing the flight number, origin and
   destination airport, booking code, and so on.  This information might
   need to be stored or processed in a programmatic fashion by AI Agent
   A.  AI Agent A may then take this information and turn it into a
   piece of rendered web content which can be shown to the user.  In
   this case, the result of the flight booking is meta-data, and needs
   to be sent by AI Agent Z, targeted towards AI Agent A.

   These use cases require protocol machinery to facilitate data typing,
   data source and destination identification, and up front negotiation
   on what is permitted and what is not.







Rosenberg & Jennings      Expires 22 April 2026                [Page 21]

Internet-Draft                AI Protocols                  October 2025


3.3.5.  Authentication and Authorization

   AuthN and AuthZ are significant considerations for inter-agent
   communications.

   In many cases, the behaviours taken by the invoked AI Agent depend on
   the identity of the user that connected to the invoking agent.  How
   does the invoked agent determine this identity reliably?  There are,
   broadly speaking, two approaches:

   1.  Conveyed Identity: The invoking AI agent authenticates the end
       user, and passes this identity in a secure fashion to the invoked
       AI Agent

   2.  Re-Authentication: The invoked AI Agent separately authenticates
       the end user

   In the case of conveyed identity, standards are needed for how the
   identity is communicated to the invoked AI agent.  This undoubtedly
   involves the transferrance of the token.  That transferrance itself
   needs to be secured.  This is of particular concern in inter-domain
   use cases, to be sure that the token is only accessible by the AI
   Agent to which it is destined.  Invoked AI Agents may have
   requirements about the strength of the authentication that has been
   performed.  For example, if the invoking AI Agent authenticated the
   user via proof of knowledge techniques as discussed in Section XX, an
   invoked AI Agent may require stronger authentication of the user
   before proceeding.

   In the case of re-authentication, standards are also required that
   allow for such authentication to occur.  In the simplest case, the
   user has credentials with domain B, and meta-data needs to be pushed
   to the user to trigger an authentication flow, ideally with a web
   popup.  Things are even more complicated when the user doesn't hold
   credentials with domain B, and authentication is done via proof-of-
   knowledge of PII over the communications channel.  If AI Agent A is
   party to these communications, it could reveal PII to AI Agent A
   which it should no be privy to.  In such cases, there would need to
   be a way for the communication to be encrypted e2e between AI Agent B
   and the user, or else a way for the authentication to happen out of
   band without the involvement of AI Agent A.

   Authorization is similarly complex.  The core objective is that the
   end user have the ability to control - with certainty (not subject to
   hallucination error), the actions that the invoked AI Agent can take.
   This is similar to the core requirement given an AI agent permission
   to access APIs, where the authorization can be controlled via
   traditional OAuth grant flows, as described in Section XX.  This is



Rosenberg & Jennings      Expires 22 April 2026                [Page 22]

Internet-Draft                AI Protocols                  October 2025


   more complex in he case of AI Agents.  The whole idea of an AI Agent
   is that it can perform a wide range of tasks - many of which are not
   predetermined.  How then can a user grant permissions to an AI Agent
   to limit what tasks it can perform, when those tasks are not simply
   an enumerated set of APIs within a specific scope?  This would need
   to be sorted out.

3.3.6.  User Confirmation

   The same requirements for user confirmation as discussed in
   Section XX for AI agent to API actions, apply to AI agent to AI Agent
   communication to.  When the invoked AI Agent is about to perform an
   action by invoking APIs with side effect, a confirmation must be
   generated by the invoked AI Agent, passed back to the invoking AI
   Agent and then communicated to the end user.  The user confirmation
   is then passed back to the invoked AI Agent.  The inter-agent aspect
   of this confirmation raises additional security considerations.  How
   can the invoked AI agent trust that the confirmation actually came
   from the end user, and is not instead a hallucination generated by
   the invoking AI Agent?  This will also require protocol machinery to
   provider cryptographic assurances.

3.3.7.  Prompt Injection Attacks

   The communications between AI agents introduces additional concerns
   around prompt injection attacks.  Specifically, it introduces a new
   threat vector.  A malicious user A, while communicating with AI Agent
   A, can request services of a third AI Agent, AI Agent Z (the invoked
   AI Agent).  User A can then send malicious messages, which are
   conveyed through AI Agent A to AI Agent Z, in an attempt to cause it
   to perform unanticipated actions with the APIs it has access to.  The
   cascading of AI Agents also introduces another possibility - that
   user A induces a prompt injection attack against AI Agent A, in an
   attempt to get it to generate malicious content towards AI Agent Z.

   Prompt injection attacks are notoriously difficult to prevent.  But,
   the protocol needs to consider these cases and introduce techniques
   to aid in diagnoses, logging and attribution.

4.  Analysis of Existing Protocols

   This section briefly introduces the Model Context Protocol (MCP), the
   Agent-to-Agent Protocol (A2A) and the Agntcy Framework, and maps them
   into the framework described in this document.







Rosenberg & Jennings      Expires 22 April 2026                [Page 23]

Internet-Draft                AI Protocols                  October 2025


4.1.  MCP

   The Model Context Protocol (ref) enables operations between a client
   - typically an AI Agent acting on the user's behalf - to access
   services provided by servers running on the same local host as the
   client.  MCP defines three distinct services that servers can offer,
   which are:

   1.  Resources: These are files, DB records, log files, and other
       forms of static content.

   2.  Prompts: These are AI prompts, which can perform a transactional
       operation, taking input and returning an output

   3.  Tools: There are APIs, which provide programmatic functions on a
       set of given inputs, providing a specified output.  An example is
       a shell command on a terminal.

   MCP provides a way for clients to enumerate these services, obtain
   descriptions of them, and then access them.

   Though MCP is targeted for operation within a single host and not
   over the Internet, we can extrapolate its usage over the Internet and
   map it into the framework here.  In this framework, MCP covers AI
   Agent to API communications.  Because it is meant for intra-host
   communication, it does not address many of the use cases around
   intra-domain and inter-domain security discussed in this framework.

4.2.  A2A

   The Agent-to-Agent (A2A) protocol focuses on - as the name implies -
   communications between agents.  It specifies an "agent card" which is
   a programmatic definition of an AI agent which can be discovered by
   other AI Agents.  It provides a protocol offer JSON-RPC for one AI
   Agent to invoke a task on another agent.  If offers protocol
   machinery for lifecycle management of the task, including completing
   it and passing back artifacts.  It facilitates messages between users
   and the invoked AI agent.  It provides for synchronous and
   asynchronous invocations.












Rosenberg & Jennings      Expires 22 April 2026                [Page 24]

Internet-Draft                AI Protocols                  October 2025


   As the name implies, A2A fits within this framework as an agent to
   agent protocol.  It provides for some of the functional requirements
   outlined in this framework, most notably lifecycle management, data
   and meta-data passing.  It also offers discovery.  It does not
   address the channel capability use cases discussed in Section XX.  It
   does offer authentication and authorization, largely off-the-shelf
   OAuth using OpenAPI's authentication flows.  It does not cover the
   use cases identified in Section XX.  It doesn't provide the user
   confirmation functionality described in Section XX.

4.3.  Agntcy

   Agntcy is a framework, not a protocol per se.  Like A2A, if focuses
   on agent to agent communications.  It discusses discovery,
   hypothesizing the use of a DHT for discovery of agents.  It makes use
   of the Open Agentic Schema Framework (OASF) to provide a standardized
   way for agents to declare their skills and be discoverable based on
   searches for those skills.  It enables the transferrance of an agent
   manifest which describes the agent and how to connect to it.  It
   considers cases where the agent is downloaded and run as a docker
   image or langchain library, in addition to being access over the
   Internet.  It discusses an Agent Connect Protocol (ACP) which is
   similar in concept to Googles A2A protocol, enabling agents to talk
   to each other.  Each agent declares, through meta-data, the
   configuration and invocation techniques it supports, including sync
   and async techniques.

   Agntcy is similar to Google A2A and fits into this framework as an AI
   Agent to AI Agent Protocol.  It covers discovery, which is a heavy
   focus of the framework.  Its manifests meet some of the requirements
   around routing, focusing on skills.  It does not address the
   capability considerations discussed in Section XX.  The ACP protocol
   provides basic invocations but does not address the full scope of
   lifecycle management discussed here.  It facilitates data
   transferrance but doesn't address the full set of use cases described
   in Section YY.  It doesn't address AuthN or AuthZ and doesn't have
   any explicit support for user confirmations.

5.  Conclusions

   In conclusion, the framework described in this document covers a
   range of use cases and requirements for AI Agent interconnection.
   Many of the use cases and requirements cannot be satisfied with
   existing protocols and standards, leaving ample room for additional
   standards activity to be undertaken.  Existing standards work, done
   outside of the IETF, covers some but not all of the use cases and
   requirements defined in this framework.




Rosenberg & Jennings      Expires 22 April 2026                [Page 25]

Internet-Draft                AI Protocols                  October 2025


6.  Informative References

   [RFC3261]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
              A., Peterson, J., Sparks, R., Handley, M., and E.
              Schooler, "SIP: Session Initiation Protocol", RFC 3261,
              DOI 10.17487/RFC3261, June 2002,
              <https://www.rfc-editor.org/info/rfc3261>.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, DOI 10.17487/RFC3550,
              July 2003, <https://www.rfc-editor.org/info/rfc3550>.

   [RFC768]   Postel, J., "User Datagram Protocol", STD 6, RFC 768,
              DOI 10.17487/RFC0768, August 1980,
              <https://www.rfc-editor.org/info/rfc768>.

   [RFC791]   Postel, J., "Internet Protocol", STD 5, RFC 791,
              DOI 10.17487/RFC0791, September 1981,
              <https://www.rfc-editor.org/info/rfc791>.

   [RFC9000]  Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based
              Multiplexed and Secure Transport", RFC 9000,
              DOI 10.17487/RFC9000, May 2021,
              <https://www.rfc-editor.org/info/rfc9000>.

   [RFC9114]  Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114,
              June 2022, <https://www.rfc-editor.org/info/rfc9114>.

   [RFC9293]  Eddy, W., Ed., "Transmission Control Protocol (TCP)",
              STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
              <https://www.rfc-editor.org/info/rfc9293>.

Authors' Addresses

   Jonathan Rosenberg
   Five9
   Email: jdrosen@jdrosen.net


   Cullen Jennings
   Cisco
   Email: fluffy@cisco.com








Rosenberg & Jennings      Expires 22 April 2026                [Page 26]


name: draft-zeng-mcp-troubleshooting
rev: 00
title: Using the Model Context Protocol (MCP) for Intent-Based Network Troubleshooting Automation
time: 2025-10-20T08:23:56Z
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T08:23:56Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "Data formats/interop", "Human-agent interaction"]
tags: []
fetched_at: 2026-02-27T22:56:05.127708+00:00
abstract:
The Model Context Protocol (MCP) is an open standard that enables
   Large Language Model (LLM) applications to seamlessly integrate with
   external data sources and tools by exposing Resources, Prompts and
   Tools in a JSON-RPC 2.0 transport.  This document describes a mapping
   of MCP roles, primitives and security model to the network management
   domain so that network devices act as MCP servers and network
   controllers act as MCP clients.  The goal is to provide an intent-
   based, conversational and secure approach for automated network
   troubleshooting, configuration validation, and closed-loop
   remediation without inventing new protocols or device agents.

full_text:
Network Working Group                                            G. Zeng
Internet-Draft                                                    J. Mao
Intended status: Informational                                    Huawei
Expires: 23 April 2026                                   20 October 2025


    Using the Model Context Protocol (MCP) for Intent-Based Network
                       Troubleshooting Automation
                   draft-zeng-mcp-troubleshooting-00

Abstract

   The Model Context Protocol (MCP) is an open standard that enables
   Large Language Model (LLM) applications to seamlessly integrate with
   external data sources and tools by exposing Resources, Prompts and
   Tools in a JSON-RPC 2.0 transport.  This document describes a mapping
   of MCP roles, primitives and security model to the network management
   domain so that network devices act as MCP servers and network
   controllers act as MCP clients.  The goal is to provide an intent-
   based, conversational and secure approach for automated network
   troubleshooting, configuration validation, and closed-loop
   remediation without inventing new protocols or device agents.

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 23 April 2026.

Copyright Notice

   Copyright (c) 2025 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.



Zeng & Mao                Expires 23 April 2026                 [Page 1]

Internet-Draft              MCP for Networks                October 2025


   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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Architecture  . . . . . . . . . . . . . . . . . . . . . . . .   3
     3.1.  Role Allocation . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Capability Negotiation  . . . . . . . . . . . . . . . . .   4
   4.  Mapping of MCP Primitives to Network Management . . . . . . .   4
     4.1.  Resources . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Tools . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.3.  Prompts . . . . . . . . . . . . . . . . . . . . . . . . .   5
     4.4.  Sampling (Optional) . . . . . . . . . . . . . . . . . . .   6
   5.  Example Use Cases . . . . . . . . . . . . . . . . . . . . . .   6
     5.1.  Intent: "Verify reachability between Site-A and
           Site-B" . . . . . . . . . . . . . . . . . . . . . . . . .   6
     5.2.  Intent: "Diagnose why BGP neighbor 1.1.1.1 is down" . . .   6
   6.  Transport & Encoding Considerations . . . . . . . . . . . . .   6
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   7
     7.1.  User Consent and Authorization  . . . . . . . . . . . . .   7
     7.2.  Least-Privilege Capability Tokens . . . . . . . . . . . .   7
     7.3.  LLM Isolation . . . . . . . . . . . . . . . . . . . . . .   7
     7.4.  Audit and Post-Mortem . . . . . . . . . . . . . . . . . .   7
     7.5.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . .   8
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
   10. Informative References  . . . . . . . . . . . . . . . . . . .   9
   Appendix A.  JSON-RPC Examples  . . . . . . . . . . . . . . . . .   9
     A.1.  Client Call: ping . . . . . . . . . . . . . . . . . . . .   9
     A.2.  Server Resource Subscription  . . . . . . . . . . . . . .   9
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10

1.  Introduction

   Network operators today face two converging demands: (1) reduce Mean
   Time to Repair (MTTR) while managing ever larger infrastructures, and
   (2) adopt intent-based interfaces that allow engineers to express
   high-level goals such as "verify reachability between Site-A and
   Site-B" instead of typing low-level CLI commands.

   Simultaneously, Large Language Models (LLMs) have demonstrated
   utility in reasoning about semi-structured data such as device logs,
   configurations, and command outputs.  However, safely exposing



Zeng & Mao                Expires 23 April 2026                 [Page 2]

Internet-Draft              MCP for Networks                October 2025


   device-level actions and data to an LLM in real time remains an open
   problem.  The Model Context Protocol (MCP), developed by Anthropic
   and published at https://modelcontextprotocol.io, provides a
   lightweight, capability-oriented RPC layer that already addresses
   this problem for general LLM applications.

   This document specifies a deterministic mapping of MCP roles,
   primitives, and security workflows onto the network management plane
   so that:

   *  A network element (router, switch, firewall, etc.) becomes an "MCP
      server" that exposes management data and actions as MCP Resources,
      Prompts and Tools.

   *  A controller, orchestrator or chat-based assistant becomes an "MCP
      client" that consumes these primitives.

   *  Human operators interact with the controller using natural
      language; the controller translates the intent into a sequence of
      MCP calls, optionally consulting an LLM for reasoning.

   *  All interactions are subject to explicit user consent, audit, and
      capability-based access control, as mandated by MCP.

   The result is an intent-based, conversational and secure automation
   framework that re-uses existing agents (NETCONF/RESTCONF/YANG, SNMP,
   CLI, gNMI, etc.) already present on devices instead of requiring new
   firmware.

2.  Terminology

   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.

   MCP terms such as "Tool", "Resource", "Prompt", "Client", "Server",
   "Host", and "Capability" are used as defined in the MCP specification
   dated 2025-06-18.

   Intent: A high-level, declarative statement of desired network
   behaviour, expressed in natural language or structured YAML/JSON,
   that the controller must translate into concrete device actions.

3.  Architecture





Zeng & Mao                Expires 23 April 2026                 [Page 3]

Internet-Draft              MCP for Networks                October 2025


      +----------------------------------+
      |  Human Operator (Chat UI, Web)   |
      +-----------------+----------------+
                        | Intent (natural lang.)
                        v
      +----------------------------------+
      |  Controller / Orchestrator       |
      |  (MCP Client + LLM Host)         |
      +-----------------+----------------+
                        | JSON-RPC 2.0 over TLS
                        v
      +----------------------------------+
      |  Network Device                  |
      |  (MCP Server)                    |
      +----------------------------------+

                        Figure 1: Reference Topology

3.1.  Role Allocation

   MCP Server: Runs on or proxied in front of the network element.
   Exposes:

   *  Resources: Read-only YANG datastores, syslog, tech-support

   *  Tools: Idempotent actions, e.g., "ping", "traceroute", "clear
      counters", "rollback config"

   *  Prompts: Re-usable prompt templates, e.g., "Diagnose BGP session
      down"

   MCP Client: Runs inside the controller.  Maintains a persistent JSON-
   RPC 2.0 connection to each server.  Optionally hosts an LLM that
   reasons about the data returned by servers.

3.2.  Capability Negotiation

   On connection establishment, the client and server exchange
   capability objects as defined in MCP.  Servers list their supported
   YANG modules [RFC8525], CLI command sets, and Tool schemas encoded in
   OpenAPI 3.0.  Clients list optional features such as "sampling" (LLM
   recursion) or "roots" (URI scoping).

4.  Mapping of MCP Primitives to Network Management







Zeng & Mao                Expires 23 April 2026                 [Page 4]

Internet-Draft              MCP for Networks                October 2025


4.1.  Resources

   Resources are exposed under the URI scheme mcp://<device>/<yang-
   module>:<path>.  Reading a resource returns YANG JSON-encoded data
   per [RFC7951].  Examples:

   *  mcp://router1/ietf-interfaces:interfaces/interface=eth0

   *  mcp://router1/openconfig-bgp:bgp/neighbors/neighbor=1.1.1.1

   Servers SHOULD support the "content-id" header to enable E-tags for
   caching.

4.2.  Tools

   Tools are mapped to well-known RPC operations already exposed by
   devices via NETCONF/RESTCONF/YANG, gNMI, or CLI.  A Tool is described
   by an OpenAPI 3.0 Operation Object and MUST be idempotent when
   possible.

   Example Tool schema (ping):

   {
     "name": "ping",
     "description": "Execute ICMP echo probe",
     "inputSchema": {
       "type": "object",
       "properties": {
         "destination": { "type": "string" },
         "count":       { "type": "integer", "default": 5 },
         "source":      { "type": "string" }
       },
       "required": ["destination"]
     }
   }

                       Figure 2: Tool Schema Example

4.3.  Prompts

   Prompts are reusable prompt templates stored on the device.  They
   allow vendors or operators to encode golden troubleshooting workflows
   in natural language.  A prompt MAY contain variable placeholders such
   as "{{interface}}" that the client fills in before sending to an LLM.







Zeng & Mao                Expires 23 April 2026                 [Page 5]

Internet-Draft              MCP for Networks                October 2025


4.4.  Sampling (Optional)

   If the client advertises the "sampling" capability, the server MAY
   request LLM inference on behalf of the device.  This is useful for
   recursive troubleshooting where the device needs to ask clarifying
   questions.  All sampling requests MUST be approved by the human
   operator via explicit consent UI.

5.  Example Use Cases

5.1.  Intent: "Verify reachability between Site-A and Site-B"

   The following steps illustrate the flow:

   1.  Operator enters intent in chat UI.

   2.  Controller's LLM deduces required Tools: − ping (Tool) from
       router1 to 10.2.2.2
       − show interfaces (Resource) on router2

   3.  Controller issues MCP calls.

   4.  Devices return results.

   5.  LLM summarizes: "Packet loss 0%; MTU mismatch detected on router2
       ge-0/0/0.  Recommend 'set interfaces ge-0/0/0 mtu 1500'."

5.2.  Intent: "Diagnose why BGP neighbor 1.1.1.1 is down"

   1.  Controller retrieves: -/openconfig-
       bgp:bgp/neighbors/neighbor=1.1.1.1/state -/ietf-
       interfaces:interfaces/interface=loopback0

   2.  Controller calls Tool "tcpdump" filtered on port 179.

   3.  LLM correlates: "No TCP SYN received; ACL foo on interface
       loopback0 denies port 179."

   4.  Controller offers one-click remediation: remove ACL entry.

6.  Transport & Encoding Considerations

   JSON-RPC 2.0 is carried over TLS 1.3 [RFC8446] with TCP/443 or QUIC
   [RFC9000] as the underlying transport.  Servers present X.509 device
   certificates; clients use mutual TLS with short-lived SPAKE2
   [RFC9383] tokens to achieve zero-touch onboarding.





Zeng & Mao                Expires 23 April 2026                 [Page 6]

Internet-Draft              MCP for Networks                October 2025


   YANG data is encoded in JSON [RFC7951] unless the client explicitly
   requests XML.

   Large tech-support files MAY be streamed via HTTP/2 chunked transfer
   and are integrity-protected by SHA-256 hashes delivered in the JSON-
   RPC result.

   Servers MAY support the MCP "progress" notification to report
   percentage completion for long-running Tools such as "tracepath".

7.  Security Considerations

   This section extends the security model defined in MCP with network-
   specific requirements.

7.1.  User Consent and Authorization

   All Tool invocations that change device state MUST be confirmed by an
   authenticated user via an out-of-band consent channel (e.g., click-
   through UI or signed JWT).  The consent object includes:

   *  Tool name and parameter values

   *  Estimated impact window (rollback timer)

   *  User identity and role

   *  Signed timestamp

7.2.  Least-Privilege Capability Tokens

   Servers issue short-lived OAuth 2.0 [RFC6749] access tokens scoped to
   individual YANG subtrees or Tools.  Tokens are bound to the mutual
   TLS channel to prevent replay.

7.3.  LLM Isolation

   When the controller hosts an LLM, the LLM is placed in a sandbox with
   no direct layer-3 reachability to devices.  All interactions MUST
   traverse the MCP client to mitigate prompt-injection attacks.

7.4.  Audit and Post-Mortem

   Every JSON-RPC request and response is appended to an immutable audit
   trail (e.g., syslog [RFC5424] or IETF syslog over TLS).  Servers
   include a "session-id" field to allow cross-device correlation.





Zeng & Mao                Expires 23 April 2026                 [Page 7]

Internet-Draft              MCP for Networks                October 2025


7.5.  Privacy

   Resources containing customer data (e.g., DPI logs) are redacted by
   default.  Servers expose a "privacy-level" capability; clients
   request explicit user consent before retrieving level-3 data.

8.  IANA Considerations

   This document requests IANA to register the following well-known URI:

   *  URI suffix: mcp

   *  Description: Model Context Protocol over TLS

   *  Reference: This document

   Additionally, the YANG module "ietf-mcp" is requested to be added to
   the IETF YANG module registry with namespace
   "urn:ietf:params:xml:ns:yang:ietf-mcp".

9.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7951]  Lhotka, L., "JSON Encoding of Data Modeled with YANG",
              RFC 7951, 2016, <https://www.rfc-editor.org/info/rfc7951>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC9000]  Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
              and Secure Transport", RFC 9000, 2021,
              <https://www.rfc-editor.org/info/rfc9000>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, 2017,
              <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8525]  Bierman, A., Bjorklund, M., and K. Watsen, "YANG Library",
              RFC 8525, 2019, <https://www.rfc-editor.org/info/rfc8525>.

   [RFC5424]  Gerhards, R., "The Syslog Protocol", RFC 5424, 2009,
              <https://www.rfc-editor.org/info/rfc5424>.





Zeng & Mao                Expires 23 April 2026                 [Page 8]

Internet-Draft              MCP for Networks                October 2025


   [RFC6749]  Hardt, D., "The OAuth 2.0 Authorization Framework",
              RFC 6749, 2012, <https://www.rfc-editor.org/info/rfc6749>.

   [RFC9383]  Sethi, M. and R. Struik, "SPAKE2+, an Augmented Password-
              Authenticated Key Exchange (PAKE) Protocol", RFC 9383,
              2023, <https://www.rfc-editor.org/info/rfc9383>.

10.  Informative References

   [MCP-SPEC] Anthropic, "Model Context Protocol Specification
              2025-06-18", URL https://modelcontextprotocol.io/
              specification/2025-06-18/basic, 2025.

Appendix A.  JSON-RPC Examples

A.1.  Client Call: ping

   --> {
         "jsonrpc": "2.0",
         "id": 1,
         "method": "tools/call",
         "params": {
           "name": "ping",
           "arguments": {
             "destination": "10.2.2.2",
             "count": 5,
             "source": "192.0.2.1"
           }
         }
       }

   <-- {
         "jsonrpc": "2.0",
         "id": 1,
         "result": {
           "loss": 0,
           "rtt": { "min": 2.1, "max": 2.3, "avg": 2.2 }
         }
       }

                    Figure 3: ping Request and Response

A.2.  Server Resource Subscription








Zeng & Mao                Expires 23 April 2026                 [Page 9]

Internet-Draft              MCP for Networks                October 2025


--> {
      "jsonrpc": "2.0",
      "id": 2,
      "method": "resources/subscribe",
      "params": {
        "uri": "mcp://router1/ietf-interfaces:interfaces/interface=eth0",
        "content-id": "etag-1234"
      }
    }

<-- {
      "jsonrpc": "2.0",
      "id": 2,
      "result": {
        "subscription-id": "sub-42",
        "initial": { "admin-status": "up", "oper-status": "up" }
      }
    }

                 Figure 4: Resource Subscribe Example

Authors' Addresses

   Guanming Zeng
   Huawei
   Email: zengguanming@huawei.com


   Jianwei Mao
   Huawei
   Email: maojianwei@huawei.com




















Zeng & Mao                Expires 23 April 2026                [Page 10]


name: draft-zm-rtgwg-mcp-troubleshooting
rev: 01
title: Using the Model Context Protocol (MCP) for Intent-Based Network Troubleshooting Automation
time: 2025-11-02T12:08:09Z
group_uri: /api/v1/group/group/1027/
expires: 2026-05-06T12:08:09Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["Autonomous netops", "Human-agent interaction", "Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:05.127724+00:00
abstract:
The Model Context Protocol (MCP) is an open standard that enables
   Large Language Model (LLM) applications to seamlessly integrate with
   external data sources and tools by exposing Resources, Prompts and
   Tools in a JSON-RPC 2.0 transport.  This document describes a mapping
   of MCP roles, primitives and security model to the network management
   domain so that network devices act as MCP servers and network
   controllers act as MCP clients.  This document also extends the model
   to Device-to-Device (D2D) collaboration, allowing network elements to
   perform distributed fault correlation when the controller is
   unreachable or when real-time cross-device data is required.  The
   goal is to provide an intent-based, conversational and secure
   approach for automated network troubleshooting, configuration
   validation, and closed-loop remediation without inventing new
   protocols or device agents.

full_text:
Network Working Group                                            G. Zeng
Internet-Draft                                                    J. Mao
Intended status: Informational                                    B. Liu
Expires: 6 May 2026                                              N. Geng
                                                                X. Shang
                                                                  Q. Gao
                                                                   Z. Li
                                                                  Huawei
                                                         2 November 2025


    Using the Model Context Protocol (MCP) for Intent-Based Network
                       Troubleshooting Automation
                 draft-zm-rtgwg-mcp-troubleshooting-01

Abstract

   The Model Context Protocol (MCP) is an open standard that enables
   Large Language Model (LLM) applications to seamlessly integrate with
   external data sources and tools by exposing Resources, Prompts and
   Tools in a JSON-RPC 2.0 transport.  This document describes a mapping
   of MCP roles, primitives and security model to the network management
   domain so that network devices act as MCP servers and network
   controllers act as MCP clients.  This document also extends the model
   to Device-to-Device (D2D) collaboration, allowing network elements to
   perform distributed fault correlation when the controller is
   unreachable or when real-time cross-device data is required.  The
   goal is to provide an intent-based, conversational and secure
   approach for automated network troubleshooting, configuration
   validation, and closed-loop remediation without inventing new
   protocols or device agents.

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 6 May 2026.



Zeng, et al.               Expires 6 May 2026                   [Page 1]

Internet-Draft              MCP for Networks               November 2025


Copyright Notice

   Copyright (c) 2025 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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   4
   3.  Mapping of MCP Primitives to Network Management . . . . . . .   4
     3.1.  Resources . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.2.  Tools . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.3.  Prompts . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.4.  Sampling (Optional) . . . . . . . . . . . . . . . . . . .   5
   4.  Controller-to-Device Troubleshooting  . . . . . . . . . . . .   5
     4.1.  Architecture  . . . . . . . . . . . . . . . . . . . . . .   5
     4.2.  Role Allocation . . . . . . . . . . . . . . . . . . . . .   6
     4.3.  Capability Negotiation  . . . . . . . . . . . . . . . . .   6
     4.4.  Example Use Cases . . . . . . . . . . . . . . . . . . . .   7
       4.4.1.  Intent: "Verify reachability between Site-A and
               Site-B" . . . . . . . . . . . . . . . . . . . . . . .   7
       4.4.2.  Intent: "Diagnose why BGP neighbor 1.1.1.1 is
               down" . . . . . . . . . . . . . . . . . . . . . . . .   7
   5.  Device-to-Device Troubleshooting Collaboration  . . . . . . .   7
     5.1.  Architecture  . . . . . . . . . . . . . . . . . . . . . .   7
     5.2.  Role Allocation . . . . . . . . . . . . . . . . . . . . .   8
     5.3.  Example Use Cases . . . . . . . . . . . . . . . . . . . .   8
       5.3.1.  Intent: Verify packet loss on the SRv6 path from PE-1
               to PE-3 via P-2 . . . . . . . . . . . . . . . . . . .   8
   6.  Transport & Encoding Considerations . . . . . . . . . . . . .  10
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  11
     7.1.  User Consent and Authorization  . . . . . . . . . . . . .  11
     7.2.  Least-Privilege Capability Tokens . . . . . . . . . . . .  11
     7.3.  LLM Isolation . . . . . . . . . . . . . . . . . . . . . .  11
     7.4.  Audit and Post-Mortem . . . . . . . . . . . . . . . . . .  11
     7.5.  Privacy . . . . . . . . . . . . . . . . . . . . . . . . .  12
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  12
   10. Informative References  . . . . . . . . . . . . . . . . . . .  13



Zeng, et al.               Expires 6 May 2026                   [Page 2]

Internet-Draft              MCP for Networks               November 2025


   Appendix A.  JSON-RPC Examples  . . . . . . . . . . . . . . . . .  13
     A.1.  Client Call: ping . . . . . . . . . . . . . . . . . . . .  13
     A.2.  Server Resource Subscription  . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   Network operators today face two converging demands: (1) reduce Mean
   Time to Repair (MTTR) while managing ever larger infrastructures, and
   (2) adopt intent-based interfaces that allow engineers to express
   high-level goals such as "verify reachability between Site-A and
   Site-B" instead of typing low-level CLI commands.

   Simultaneously, Large Language Models (LLMs) have demonstrated
   utility in reasoning about semi-structured data such as device logs,
   configurations, and command outputs.  However, safely exposing
   device-level actions and data to an LLM in real time remains an open
   problem.  The Model Context Protocol (MCP), developed by Anthropic
   and published at https://modelcontextprotocol.io, provides a
   lightweight, capability-oriented RPC layer that already addresses
   this problem for general LLM applications.

   This document specifies a deterministic mapping of MCP roles,
   primitives, and security workflows onto the network management plane
   so that:

   *  A network element (router, switch, firewall, etc.) becomes an "MCP
      server" that exposes management data and actions as MCP Resources,
      Prompts and Tools.

   *  A controller, orchestrator or chat-based assistant becomes an "MCP
      client" that consumes these primitives.

   *  Human operators interact with the controller using natural
      language; the controller translates the intent into a sequence of
      MCP calls, optionally consulting an LLM for reasoning.

   *  All interactions are subject to explicit user consent, audit, and
      capability-based access control, as mandated by MCP.












Zeng, et al.               Expires 6 May 2026                   [Page 3]

Internet-Draft              MCP for Networks               November 2025


   While the star-shaped Controller-to-Device model covers most brown-
   field deployments, some faults are visible only when two or more
   devices compare live data in real time.  To address this we extend
   MCP to support Device-to-Device (D2D) troubleshooting collaboration.
   In this mode network elements autonomously form a transient
   "collaboration domain", exchange YANG/JSON-RPC calls, correlate
   results with an on-box LLM, and produce a signed report that can be
   retrieved by the controller once connectivity is restored.  Security
   is maintained through mutual TLS, short-lived device certificates,
   and a white-list of neighbour-callable capabilities.

   The result is an intent-based, conversational and secure automation
   framework that re-uses existing agents (NETCONF/RESTCONF/YANG, SNMP,
   CLI, gNMI, etc.) already present on devices instead of requiring new
   firmware.

2.  Terminology

   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.

   MCP terms such as "Tool", "Resource", "Prompt", "Client", "Server",
   "Host", and "Capability" are used as defined in the MCP specification
   dated 2025-06-18.

   Intent: A high-level, declarative statement of desired network
   behaviour, expressed in natural language or structured YAML/JSON,
   that the controller must translate into concrete device actions.

3.  Mapping of MCP Primitives to Network Management

3.1.  Resources

   Resources are exposed under the URI scheme mcp://<device>/<yang-
   module>:<path>.  Reading a resource returns YANG JSON-encoded data
   per [RFC7951].  Examples:

   *  mcp://router1/ietf-interfaces:interfaces/interface=eth0

   *  mcp://router1/openconfig-bgp:bgp/neighbors/neighbor=1.1.1.1

   Servers SHOULD support the "content-id" header to enable E-tags for
   caching.





Zeng, et al.               Expires 6 May 2026                   [Page 4]

Internet-Draft              MCP for Networks               November 2025


3.2.  Tools

   Tools are mapped to well-known RPC operations already exposed by
   devices via NETCONF/RESTCONF/YANG, gNMI, or CLI.  A Tool is described
   by an OpenAPI 3.0 Operation Object and MUST be idempotent when
   possible.

   Example Tool schema (ping):

   {
     "name": "ping",
     "description": "Execute ICMP echo probe",
     "inputSchema": {
       "type": "object",
       "properties": {
         "destination": { "type": "string" },
         "count":       { "type": "integer", "default": 5 },
         "source":      { "type": "string" }
       },
       "required": ["destination"]
     }
   }

                       Figure 1: Tool Schema Example

3.3.  Prompts

   Prompts are reusable prompt templates stored on the device.  They
   allow vendors or operators to encode golden troubleshooting workflows
   in natural language.  A prompt MAY contain variable placeholders such
   as "{{interface}}" that the client fills in before sending to an LLM.

3.4.  Sampling (Optional)

   If the client advertises the "sampling" capability, the server MAY
   request LLM inference on behalf of the device.  This is useful for
   recursive troubleshooting where the device needs to ask clarifying
   questions.  All sampling requests MUST be approved by the human
   operator via explicit consent UI.

4.  Controller-to-Device Troubleshooting

4.1.  Architecture








Zeng, et al.               Expires 6 May 2026                   [Page 5]

Internet-Draft              MCP for Networks               November 2025


      +----------------------------------+
      |  Human Operator (Chat UI, Web)   |
      +-----------------+----------------+
                        | Intent (natural lang.)
                        v
      +----------------------------------+
      |  Controller / Orchestrator       |
      |  (MCP Client + LLM Host)         |
      +-----------------+----------------+
                        | JSON-RPC 2.0 over TLS
                        v
      +----------------------------------+
      |  Network Device                  |
      |  (MCP Server)                    |
      +----------------------------------+

                    Figure 2: Controller-to-Device model

4.2.  Role Allocation

   MCP Server: Runs on or proxied in front of the network element.
   Exposes:

   *  Resources: Read-only YANG datastores, syslog, tech-support

   *  Tools: Idempotent actions, e.g., "ping", "traceroute", "clear
      counters", "rollback config"

   *  Prompts: Re-usable prompt templates, e.g., "Diagnose BGP session
      down"

   MCP Client: Runs inside the controller.  Maintains a persistent JSON-
   RPC 2.0 connection to each server.  Optionally hosts an LLM that
   reasons about the data returned by servers.

4.3.  Capability Negotiation

   On connection establishment, the client and server exchange
   capability objects as defined in MCP.  Servers list their supported
   YANG modules [RFC8525], CLI command sets, and Tool schemas encoded in
   OpenAPI 3.0.  Clients list optional features such as "sampling" (LLM
   recursion) or "roots" (URI scoping).









Zeng, et al.               Expires 6 May 2026                   [Page 6]

Internet-Draft              MCP for Networks               November 2025


4.4.  Example Use Cases

4.4.1.  Intent: "Verify reachability between Site-A and Site-B"

   The following steps illustrate the flow:

   1.  Operator enters intent in chat UI.

   2.  Controller's LLM deduces required Tools: − ping (Tool) from
       router1 to 10.2.2.2
       − show interfaces (Resource) on router2

   3.  Controller issues MCP calls.

   4.  Devices return results.

   5.  LLM summarizes: "Packet loss 0%; MTU mismatch detected on router2
       ge-0/0/0.  Recommend 'set interfaces ge-0/0/0 mtu 1500'."

4.4.2.  Intent: "Diagnose why BGP neighbor 1.1.1.1 is down"

   1.  Controller retrieves: -/openconfig-
       bgp:bgp/neighbors/neighbor=1.1.1.1/state -/ietf-
       interfaces:interfaces/interface=loopback0

   2.  Controller calls Tool "tcpdump" filtered on port 179.

   3.  LLM correlates: "No TCP SYN received; ACL foo on interface
       loopback0 denies port 179."

   4.  Controller offers one-click remediation: remove ACL entry.

5.  Device-to-Device Troubleshooting Collaboration

   Some root causes are scattered across several nodes (e.g.,
   unidirectional fiber, one-way ACL, single-sided BFD Down, localized
   SRv6 SID failure).  Although the controller can collect data
   centrally, the north-bound link may be impaired, time-synchronisation
   is costly, and uploading bulk data is expensive.  Allowing nearby
   devices to form a transient "trusted collaboration domain" and
   exchange data, correlate and infer root causes locally can
   significantly shorten MTTR.

5.1.  Architecture







Zeng, et al.               Expires 6 May 2026                   [Page 7]

Internet-Draft              MCP for Networks               November 2025


         +-------------+       +-------------+       +-------------+
         |   Device A  |       |   Device B  |       |   Device C  |
         | MCP Client  |       | MCP Client  |       | MCP Client  |
         |  + Server   |<----->|  + Server   |<----->|  + Server   |
         +-------------+       +-------------+       +-------------+
               |                       |                       |
               |  MCP/JSON-RPC 2.0     |  MCP/JSON-RPC 2.0     |
               |  over mutual-TLS      |  over mutual-TLS      |
               |                       |                       |

               Figure 3: Device-to-Device Collaboration Model

5.2.  Role Allocation

   *  MCP-Server, MCP-Client: moved into a "Collaboration Agent" (CA)
      running on the device.  Every CA is both client and server; the
      MCP message layer MUST support mutual TLS and capability
      negotiation.

   *  The user (human or controller) only needs to inject an Intent on
      any one device in the domain; the CA will then perform the chained
      calls autonomously and roll-up the final report.

5.3.  Example Use Cases

5.3.1.  Intent: Verify packet loss on the SRv6 path from PE-1 to PE-3
        via P-2

   The following steps illustrate SRv6 packet-loss localization between
   three routers: PE-1 (head-end), P-2 (mid-point), and PE-3 (tail-end).
   The same pattern can be applied to any multi-box fault domain.

   *Step-0: Intent Injection*

   An operator types the following natural-language goal in the chat
   window that is served by PE-1:

 Intent: "Verify packet loss on the SRv6 path from PE-1 to PE-3 via P-2"

   PE-1 Collaboration Agent (CA) parses the Intent, extracts the SID
   list {PE-1, P-2, PE-3}, and starts the D2D workflow.

   *Step-1: Collaboration Domain Discovery*

   PE-1 CA sends an LLDP/IS-IS Extended TLV that contains:






Zeng, et al.               Expires 6 May 2026                   [Page 8]

Internet-Draft              MCP for Networks               November 2025


    + mcp-d2d-port = 9514
    + supported-capabilities = [ietf-srv6-ping, ietf-interface-counters]
    + cert-thumbprint = <SHA-256 of device certificate>

   P-2 and PE-3 reply with their own TLV.  All three nodes are now aware
   of each other's MCP endpoint and capabilities.

   *Step-2: Mutual TLS & Capability Negotiation*

   PE-1 opens a TLS 1.3 connection to P-2 and PE-3 on port 9514.  Both
   sides send their X.509 device certificates and the MCP initialize
   message:

   { "jsonrpc": "2.0",
     "method": "mcp/initialize",
     "params": {
         "protocolVersion": "2025-12",
         "capabilities": [ "ietf-srv6-ping", "ietf-interface-counters" ]
     },
     "id": 1 }

   The responder echoes its own capability list.  If the intersection is
   non-empty the session is marked authorised for those capabilities.

   *Step-3: Parallel Resource & Tool Calls*

   PE-1 CA schedules three operations in parallel:

   Local call (no network RPC)

     Tool: "ietf-srv6-ping"
     Params: { Head=PE-1, Tail=PE-3, SID-List=[P-2, PE-3], Count=100 }

   RPC toward P-2

     POST https://[P-2]:9514/mcp/tool/call
     Body: { tool: "ietf-srv6-ping",
             arguments: { Local=P-2, Tail=PE-3, Count=100 } }

   RPC toward PE-3

  POST https://[PE-3]:9514/mcp/resource/read
  Body: { uri: "urn:ietf:params:xml:ns:yang:ietf-interfaces/interfaces/interface=SID-Endpoint/statistics" }

   Each callee returns a JSON-RPC result plus an ed25519 signature
   covering the result body and a monotonic nonce.  The nonce prevents
   replay if the controller later fetches the audit-log.




Zeng, et al.               Expires 6 May 2026                   [Page 9]

Internet-Draft              MCP for Networks               November 2025


   *Step-4: Local Correlation & Inference*

   PE-1 CA feeds the three data sets into its on-box LLM with the
   prompt:

    "Compare loss % from PE-1 vs P-2; if PE-1>0 and P-2=0, root cause is
     in {PE-1→P-2 link, upstream ACL}; output a single sentence."

   Model output:

     "Loss 3.2 % observed only on PE-1→P-2 direction; P-2→PE-1 0 %;
      suggest checking PE-1 egress ACL 2001."

   The deterministic part of the reply (ACL 2001) is extracted as a
   structured fault hypothesis and stored in the candidate list.

   *Step-5: Roll-up Report & User Consent*

   PE-1 CA assembles the signed results, inference, and raw packets into
   an MCP resource:

  URI:  urn:ietf:params:xml:ns:yang:ietf-mcp/report/74e8
  Body: { "creator": "PE-1",
          "created": "2025-10-30T14:23:42Z",
          "hypothesis": "PE-1 egress ACL 2001",
          "evidence": [ <base64 encoded PCAP>, ... ],
          "signatures": { "PE-1": <sig1>, "P-2": <sig2>, "PE-3": <sig3> } }

   If the operator is still on-line the CA presents the hypothesis and
   asks for explicit approval before any mitigating action (e.g., edit
   ACL) is executed.  If the controller is reachable the report is
   pushed through the conventional star channel; otherwise it remains
   on-box until the next controller sync.

   *Failure Handling*

   If any D2D call times out or returns an authentication error, PE-1 CA
   marks that node "untrusted" and falls back to controller-based
   polling if available.  All intermediate temporary states (e.g.,
   cleared counters) are rolled back immediately to preserve atomicity.

6.  Transport & Encoding Considerations

   JSON-RPC 2.0 is carried over TLS 1.3 [RFC8446] with TCP/443 or QUIC
   [RFC9000] as the underlying transport.  Servers present X.509 device
   certificates; clients use mutual TLS with short-lived SPAKE2
   [RFC9383] tokens to achieve zero-touch onboarding.




Zeng, et al.               Expires 6 May 2026                  [Page 10]

Internet-Draft              MCP for Networks               November 2025


   YANG data is encoded in JSON [RFC7951] unless the client explicitly
   requests XML.

   Large tech-support files MAY be streamed via HTTP/2 chunked transfer
   and are integrity-protected by SHA-256 hashes delivered in the JSON-
   RPC result.

   Servers MAY support the MCP "progress" notification to report
   percentage completion for long-running Tools such as "tracepath".

7.  Security Considerations

   This section extends the security model defined in MCP with network-
   specific requirements.

7.1.  User Consent and Authorization

   All Tool invocations that change device state MUST be confirmed by an
   authenticated user via an out-of-band consent channel (e.g., click-
   through UI or signed JWT).  The consent object includes:

   *  Tool name and parameter values

   *  Estimated impact window (rollback timer)

   *  User identity and role

   *  Signed timestamp

7.2.  Least-Privilege Capability Tokens

   Servers issue short-lived OAuth 2.0 [RFC6749] access tokens scoped to
   individual YANG subtrees or Tools.  Tokens are bound to the mutual
   TLS channel to prevent replay.

7.3.  LLM Isolation

   When the controller hosts an LLM, the LLM is placed in a sandbox with
   no direct layer-3 reachability to devices.  All interactions MUST
   traverse the MCP client to mitigate prompt-injection attacks.

7.4.  Audit and Post-Mortem

   Every JSON-RPC request and response is appended to an immutable audit
   trail (e.g., syslog [RFC5424] or IETF syslog over TLS).  Servers
   include a "session-id" field to allow cross-device correlation.





Zeng, et al.               Expires 6 May 2026                  [Page 11]

Internet-Draft              MCP for Networks               November 2025


7.5.  Privacy

   Resources containing customer data (e.g., DPI logs) are redacted by
   default.  Servers expose a "privacy-level" capability; clients
   request explicit user consent before retrieving level-3 data.

8.  IANA Considerations

   This document requests IANA to register the following well-known URI:

   *  URI suffix: mcp

   *  Description: Model Context Protocol over TLS

   *  Reference: This document

   Additionally, the YANG module "ietf-mcp" is requested to be added to
   the IETF YANG module registry with namespace
   "urn:ietf:params:xml:ns:yang:ietf-mcp".

9.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC7951]  Lhotka, L., "JSON Encoding of Data Modeled with YANG",
              RFC 7951, 2016, <https://www.rfc-editor.org/info/rfc7951>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC9000]  Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
              and Secure Transport", RFC 9000, 2021,
              <https://www.rfc-editor.org/info/rfc9000>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, 2017,
              <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8525]  Bierman, A., Bjorklund, M., and K. Watsen, "YANG Library",
              RFC 8525, 2019, <https://www.rfc-editor.org/info/rfc8525>.

   [RFC5424]  Gerhards, R., "The Syslog Protocol", RFC 5424, 2009,
              <https://www.rfc-editor.org/info/rfc5424>.





Zeng, et al.               Expires 6 May 2026                  [Page 12]

Internet-Draft              MCP for Networks               November 2025


   [RFC6749]  Hardt, D., "The OAuth 2.0 Authorization Framework",
              RFC 6749, 2012, <https://www.rfc-editor.org/info/rfc6749>.

   [RFC9383]  Sethi, M. and R. Struik, "SPAKE2+, an Augmented Password-
              Authenticated Key Exchange (PAKE) Protocol", RFC 9383,
              2023, <https://www.rfc-editor.org/info/rfc9383>.

10.  Informative References

   [MCP-SPEC] Anthropic, "Model Context Protocol Specification
              2025-06-18", URL https://modelcontextprotocol.io/
              specification/2025-06-18/basic, 2025.

Appendix A.  JSON-RPC Examples

A.1.  Client Call: ping

   --> {
         "jsonrpc": "2.0",
         "id": 1,
         "method": "tools/call",
         "params": {
           "name": "ping",
           "arguments": {
             "destination": "10.2.2.2",
             "count": 5,
             "source": "192.0.2.1"
           }
         }
       }

   <-- {
         "jsonrpc": "2.0",
         "id": 1,
         "result": {
           "loss": 0,
           "rtt": { "min": 2.1, "max": 2.3, "avg": 2.2 }
         }
       }

                    Figure 4: ping Request and Response

A.2.  Server Resource Subscription








Zeng, et al.               Expires 6 May 2026                  [Page 13]

Internet-Draft              MCP for Networks               November 2025


--> {
      "jsonrpc": "2.0",
      "id": 2,
      "method": "resources/subscribe",
      "params": {
        "uri": "mcp://router1/ietf-interfaces:interfaces/interface=eth0",
        "content-id": "etag-1234"
      }
    }

<-- {
      "jsonrpc": "2.0",
      "id": 2,
      "result": {
        "subscription-id": "sub-42",
        "initial": { "admin-status": "up", "oper-status": "up" }
      }
    }

                 Figure 5: Resource Subscribe Example

Authors' Addresses

   Guanming Zeng
   Huawei
   Email: zengguanming@huawei.com


   Jianwei Mao
   Huawei
   Email: maojianwei@huawei.com


   Bing Liu
   Huawei
   Email: leo.liubing@huawei.com


   Nan Geng
   Huawei
   Email: gengnan@huawei.com


   Xiaotong Shang
   Huawei
   Email: shangxiaotong@huawei.com





Zeng, et al.               Expires 6 May 2026                  [Page 14]

Internet-Draft              MCP for Networks               November 2025


   Qiangzhou Gao
   Huawei
   Email: gaoqiangzhou@huawei.com


   Zhenbin Li
   Huawei
   Email: robinli314@163.com











































Zeng, et al.               Expires 6 May 2026                  [Page 15]


name: draft-an-nmrg-i2icf-cits
rev: 01
title: Interface to In-Network Computing Functions for Cooperative Intelligent Transportation Systems
time: 2026-02-06T00:16:19Z
group_uri: /api/v1/group/group/1027/
expires: 2026-08-10T00:16:19Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: ["A2A protocols", "ML traffic mgmt", "Agent discovery/reg", "Other AI/agent"]
tags: []
fetched_at: 2026-02-27T22:56:05.127727+00:00
abstract:
This document specifies a structured framework for orchestrating,
   managing, and monitoring In-Network Computing Functions (ICFs) in
   Cooperative Intelligent Transportation Systems (C-ITS).  For example,
   in the context of Vehicle-to-Everything (V2X) communications,
   efficient management of Vehicle-to-Vehicle (V2V) communications and
   their integration with C-ITS can greatly benefit from in-network
   computing.  By leveraging ICFs, it becomes possible to optimize real-
   time communication, streamline traffic management, and enhance data
   processing and security services at the network edge.  Moreover, by
   incorporating the Agent-to-Agent (A2A) communication paradigm,
   intelligent agents within vehicles, Roadside Units (RSUs), and
   network domains can directly collaborate to negotiate resources,
   exchange contextual information, and coordinate computing tasks,
   enabling adaptive and scalable orchestration across multi-domain
   C-ITS environments.

full_text:
Internet Research Task Force                                  A. An, Ed.
Internet-Draft                    Korea Electronics Technology Institute
Intended status: Informational                             J. Jeong, Ed.
Expires: 9 August 2026                           Sungkyunkwan University
                                                                 B. Park
                                                                 S. Jang
                                  Korea Electronics Technology Institute
                                                         5 February 2026


Interface to In-Network Computing Functions for Cooperative Intelligent
                         Transportation Systems
                      draft-an-nmrg-i2icf-cits-01

Abstract

   This document specifies a structured framework for orchestrating,
   managing, and monitoring In-Network Computing Functions (ICFs) in
   Cooperative Intelligent Transportation Systems (C-ITS).  For example,
   in the context of Vehicle-to-Everything (V2X) communications,
   efficient management of Vehicle-to-Vehicle (V2V) communications and
   their integration with C-ITS can greatly benefit from in-network
   computing.  By leveraging ICFs, it becomes possible to optimize real-
   time communication, streamline traffic management, and enhance data
   processing and security services at the network edge.  Moreover, by
   incorporating the Agent-to-Agent (A2A) communication paradigm,
   intelligent agents within vehicles, Roadside Units (RSUs), and
   network domains can directly collaborate to negotiate resources,
   exchange contextual information, and coordinate computing tasks,
   enabling adaptive and scalable orchestration across multi-domain
   C-ITS environments.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

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




An, et al.                Expires 9 August 2026                 [Page 1]

Internet-Draft               I2ICF for C-ITS               February 2026


   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 9 August 2026.

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  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  Framework and Interfaces  . . . . . . . . . . . . . . . . . .   4
     2.1.  I2ICF Framework for C-ITS and MNO Networking  . . . . . .   4
     2.2.  I2ICF Interfaces  . . . . . . . . . . . . . . . . . . . .   8
   3.  Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . .  10
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   5.  A2A Use Cases for SDV and C-ITS Integration . . . . . . . . .  12
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  13
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction

   In-network computing has recently gained significant attention and
   has been extensively explored as a promising research area.  This
   growing interest stems from the increasing accessibility of data
   plane programmability, which has opened new opportunities for both
   application developers and network operators to optimize network
   operations and application performance.  Over the years, rigorous
   research and numerous trials have validated the effectiveness of
   certain in-network computing capabilities, collectively referred to
   as In-Network Computing Functions (ICFs).  These functions have



An, et al.                Expires 9 August 2026                 [Page 2]

Internet-Draft               I2ICF for C-ITS               February 2026


   proven to be highly beneficial in various domains, such as machine
   learning, real-time data processing, and large-scale distributed
   systems.  For instance, in-network aggregation techniques have been
   shown to accelerate collective communication operations like
   Allreduce and Broadcast, which are critical in training machine
   learning models.  These advancements have led to the gradual
   commercialization of many in-network computing capabilities.  Several
   other works, such as [I-D.jeong-nmrg-i2icf-problem-statement][I-D.yao
   -tsvwg-cco-problem-statement-and-usecases][I-D.irtf-coinrg-use-cases]
   also provide additional use cases and scenarios for in-network
   computing applications.

   Despite these promising developments, a critical challenge remains:
   the absence of a unified framework and standardized interfaces to
   effectively register, configure, manage, and monitor ICFs.  The
   framework for Interface to Network Security Functions (I2NSF) defined
   in [RFC8329] provides a solid foundation for managing and
   orchestrating Network Security Functions (NSFs).  However, these
   frameworks fall short when it comes to supporting the unique
   requirements of ICFs.  Unlike NSFs, ICFs often require seamless
   coordination between endpoint computing capabilities and in-network
   nodes, such as Programmable Network Devices (PNDs), to accelerate
   application performance collaboratively.  This highlights the need
   for a new framework that can integrate endpoint and in-network
   functionalities while leveraging and adapting existing frameworks,
   such as I2NSF, to define interfaces for ICFs effectively.

   This document rigorously examines the applicability of ICFs within
   constrained environments, particularly in data center networks, and
   introduces a structured framework for their registration,
   configuration, management, and monitoring.  Additionally, it
   evaluates extended use cases, including Vehicle-to-Everything (V2X)
   communication, wherein ICFs facilitate the efficient orchestration of
   vehicle-to-vehicle (V2V) networks, seamless integration with
   Cooperative Intelligent Transport Systems (C-ITS), and
   interoperability with Mobile Network Operators (MNOs).  By leveraging
   ICFs, these architectures can achieve enhanced communication
   efficiency, improved traffic control, and secure data exchange.
   Furthermore, this document underscores the pivotal role of ICFs in
   strengthening cybersecurity measures for both private and public data
   within such interconnected ecosystems, addressing the increasing
   demand for resilient security mechanisms in contemporary networked
   infrastructures.

   In C-ITS, distributed agents across vehicles, Road-Side Units (RSUs),
   and traffic management backends increasingly need to collaborate
   directly in an _Agent-to-Agent (A2A)_ manner for capability
   advertisement, peer discovery, task delegation, and state exchange.



An, et al.                Expires 9 August 2026                 [Page 3]

Internet-Draft               I2ICF for C-ITS               February 2026


   Emerging IETF work on Artificial Intelligence (AI) agent protocols
   formalizes such A2A interactions (e.g., messaging, capability
   schemas, and discovery) [I-D.rosenberg-ai-protocols], while the IRTF
   NMRG explores applicability of A2A to multi-domain network management
   and automation [I-D.yang-nmrg-a2a-nm].  This approach provides a
   standards-based application/control-plane overlay for ICFs: vehicle,
   infrastructure, and cloud agents can discover and configure ICFs on
   programmable network devices, coordinate V2V/V2I compute placement,
   and exchange low-latency signals for admission control, safety
   services, and analytics, thereby reducing end-to-end delay and
   network overhead while improving interoperability and manageability
   in C-ITS deployments.

2.  Framework and Interfaces

   This section presents the detailed design of I2ICF framework and
   interfaces for C-ITS and MNO Networking.

2.1.  I2ICF Framework for C-ITS and MNO Networking

   Figure 1 shows the I2ICF framework of C-ITS and MNO networking.  In
   this framework, there are several major components and relative
   interfaces.

   * Central Cloud: A system that comprehensively controls the entire
   C-ITS (Cooperative Intelligent Transport Systems) environment.  It
   manages information from various C-ITS centers, including regional
   centers and highway centers, and facilitates and oversees the
   connection between C-ITS data from the Government Public Center and
   end users.  Additionally, it provides security functions through an
   integrated cybersecurity system.

   * C-ITS Center: The C-ITS Center is a comprehensive term that
   encompasses both the Region Center and the Highway Center.  It serves
   as the central hub for managing and coordinating intelligent
   transportation systems across various environments, including urban
   regions and highways.  By integrating data from Region Centers and
   Highway Centers, the C-ITS Center ensures efficient traffic
   management, real-time data processing, and seamless communication
   between infrastructure and connected or autonomous vehicles.

   * Region Center: The Region Center refers to local centers
   established at key locations.  These regional centers are connected
   to Roadside Units (RSUs) and function as one of the C-ITS Centers.
   Each regional C-ITS center collaborates with the Government Public
   Center to share collected data, ensuring seamless integration and
   data exchange between local infrastructure and centralized management
   systems.



An, et al.                Expires 9 August 2026                 [Page 4]

Internet-Draft               I2ICF for C-ITS               February 2026


   * Highway Center: The Highway Center operates similarly to the Region
   Center but is managed separately due to the unique characteristics of
   highways, which span multiple regions rather than being confined to a
   single city.  Given the higher traffic volume on highways compared to
   regular roads, there is a significant increase in data generation,
   necessitating dedicated network management for highway environments.
   Highways are equipped with a greater number of RSUs than general
   roads, enabling the delivery of critical information to autonomous
   vehicles.  As a result, the Highway Center focuses on managing areas
   that require more real-time processing to support safe and efficient
   autonomous driving.

   * Government Public Center: The Government Public Center is a C-ITS
   information provision system managed by the government.  Due to the
   nature of road traffic infrastructure, it is challenging for private
   companies to manage this data effectively, and concerns over
   reliability make it difficult for users to utilize privately managed
   data.  The Government Public Center ensures the delivery of highly
   reliable, government-provided data to users, enabling them to
   effectively utilize infrastructure-based information.  It oversees
   the provision and management of trustworthy data essential for safe
   and efficient transportation systems.

   * C-ITS Data Linkage System: The C-ITS Data Linkage System is a
   platform designed to provide C-ITS data to external users.  By
   offering data through methods such as Open APIs, this system connects
   C-ITS infrastructure information with users, enabling seamless access
   to real-time traffic and transportation data.  It facilitates the
   integration of C-ITS data into various applications and services,
   supporting the development of innovative mobility solutions and
   enhancing the overall efficiency and safety of transportation
   systems.

   * Cyber Security System: The Cyber Security System is responsible for
   managing the security of communications between Software-Defined
   Vehicles (SDV), Vulnerable Road Users (VRU), RSU, Mobile Network
   Operators (MNO), and C-ITS infrastructure.  Security technologies are
   fundamentally integrated into all communications to ensure encrypted
   data transmission.  Outgoing data is encrypted using a public key,
   while receiving devices decrypt the data using a private key to
   securely access the information.  The Cyber Security System oversees
   the protection of both private and public keys across all modules,
   ensuring robust security against potential exposure and safeguarding
   the integrity and confidentiality of transmitted data.

   * C-ITS Infra: The C-ITS Infrastructure is a system designed to
   collect and provide various types of information, including traffic
   signal data, roadside environment information, VRU data, and RSU



An, et al.                Expires 9 August 2026                 [Page 5]

Internet-Draft               I2ICF for C-ITS               February 2026


   data.  The specific C-ITS information available may vary depending on
   the devices and equipments installed on the road.  This
   infrastructure enables real-time data exchange between the
   transportation system and connected or autonomous vehicles,
   supporting safer and more efficient traffic management.

   * RSU: The RSU is a device that connects the C-ITS Infrastructure
   with SDVs.  Through the RSU, SDVs can transmit and receive data
   between vehicles via V2V and between vehicles and infrastructure via
   V2I.  RSUs play a critical role in enabling real-time communication,
   providing essential information such as traffic signals, road
   conditions, and safety alerts, thereby enhancing the safety and
   efficiency of autonomous and connected vehicle operations.

   * SDV1 and SDV2: SDV1 and SDV2 are examples depicted in the diagram,
   but in real-world scenarios, there can be an arbitrary number of
   vehicles.  An SDV (Software-Defined Vehicle) consists of two main
   communication interfaces (External Communication Interface : Enables
   communication with external systems such as RSUs (Roadside Units),
   other vehicles (V2V), and infrastructure (V2I/V2N), supporting
   seamless interaction within the C-ITS ecosystem.  Internal Vehicle
   Network (IVN) Interface : Manages internal communication within the
   vehicle, connecting various onboard systems and components to ensure
   smooth operation and integration of vehicle functionalities) This
   dual-interface structure allows SDVs to efficiently exchange data
   both externally with the C-ITS infrastructure and internally for
   optimized vehicle control.

   * IVN-Network1 and IVN-Network2: IVN-Network1 and IVN-Network2 are
   examples, but in practice, the internal communication system of a
   vehicle can consist of N different networks.  These networks are part
   of the In-Vehicle Network (IVN), which facilitates communication
   within the vehicle.  In an SDV (Software-Defined Vehicles), the IVN
   is designed based on a Zonal Architecture, where communication
   interfaces connect various devices and components within specific
   zones of the vehicle.  This architecture improves data transmission
   efficiency, reduces wiring complexity, and enhances the integration
   of advanced systems for autonomous driving and vehicle control.
   Through this zonal design, SDVs can effectively manage high-speed
   data exchange between sensors, controllers, and actuators, supporting
   real-time processing and safer driving operations.

   * VRU: A VRU refers to users who can communicate either with an MNO
   or directly with SDVs.  VRUs typically include pedestrians, cyclists,
   and motorcyclists who are more susceptible to traffic accidents due
   to their limited protection.  By connecting with MNO networks, VRUs
   can receive real-time safety alerts and traffic information.
   Additionally, direct communication with SDVs enables VRUs to exchange



An, et al.                Expires 9 August 2026                 [Page 6]

Internet-Draft               I2ICF for C-ITS               February 2026


   critical safety data, such as location and movement intentions, which
   helps autonomous and connected vehicles detect and respond to nearby
   vulnerable users, ultimately enhancing road safety.

   * MNO: An MNO is a service provider that owns and manages wireless
   communication infrastructure, including network towers, core
   networks, and data centers.  In the context of C-ITS, MNOs play a
   critical role in enabling real-time communication between vehicles,
   infrastructure, and VRUs by providing seamless connectivity through
   cellular networks (e.g., LTE, and 5G).  MNOs facilitate the
   transmission of safety messages, traffic updates, and vehicle data,
   ensuring low-latency, high-reliability communication essential for
   autonomous driving and connected vehicle ecosystems.  Additionally,
   MNOs collaborate with C-ITS infrastructure to enhance data security
   and manage network resources for efficient traffic management and
   mobility services.



































An, et al.                Expires 9 August 2026                 [Page 7]

Internet-Draft               I2ICF for C-ITS               February 2026


                                   Central Cloud
          ****************************************************************
        *                                                                 *
      *     +------------------+            +---------------------------+  *
      *     | C-ITS Center     |<---------->| Government Public Center  |   *
      *     |------------------|     I1     |-------------------------- |   *
      *     | Region Center    |            | C-ITS Data Linkage System |   *
      *     |------------------|            |---------------------------|   *
      *     | Highway Center   |            | Cyber Security System     |   *
      *     +------------------+            +---------------------------+  *
        *             ^ I2                                ^ I3            *
          ************|***********************************|***************
                      |                                   |
                      v                                   v
            +------------------+            +-------------------------------+
    +------>|  C-ITS Infra     |<..........>| MNO (Mobile Network Operator) |
    |  I7   +------------------+     I4     +-------------------------------+
+---v---+           ^                             ^             ^
|  RSU  |           : I5                          : I6          : I6
+-------+           :                             :             :
    ^               v                             v             v
    :       +----------------+                 +-------+     +-------+
    +......>|  SDV1          |<...............>|  VRU  |     |  VRU  |
        I8  |  IVN-Network1  |       I9        +-------+     +-------+
            +----------------+
                  ^
                  : I10
                  :
                  v
            +----------------+
            |  SDV2          |
            |  IVN-Network2  |
            +----------------+

  <---> Wired Link   <...> Wireless Link

               Figure 1: I2ICF Framework and Interfaces

2.2.  I2ICF Interfaces

   According to the framework described in the previous section, there
   are major interfaces that I2ICF of C-ITS and MNO networking should
   define.

   Interface 1 (I1): This is the registration interface between the
   C-ITS Center and the Government Public Center.  It facilitates the
   exchange of C-ITS infrastructure data, such as traffic information
   and real-time road conditions, ensuring the Government Public Center



An, et al.                Expires 9 August 2026                 [Page 8]

Internet-Draft               I2ICF for C-ITS               February 2026


   can provide accurate and trustworthy data to external users.  This
   interface also supports secure data sharing through standardized
   protocols and encryption.

   Interface 2 (I2): This interface connects the C-ITS Center with the
   C-ITS Infra.  It is responsible for distributing infrastructure data,
   such as traffic signal information, road environment data, and RSU
   status, from the C-ITS Center to the C-ITS Infra for real-time
   processing and delivery to connected vehicles.  It ensures continuous
   data flow for effective traffic and infrastructure management.

   Interface 3 (I3): This is the data exchange interface between the
   Government Public Center and the MNO (Mobile Network Operator).  It
   enables the secure transmission of C-ITS data to MNOs, allowing
   mobile networks to deliver critical traffic and safety information to
   VRUs and vehicles.  This interface must ensure data integrity and
   security during transmission.

   Interface 4 (I4): This interface connects the C-ITS Infra with the
   MNO.  It supports the sharing of network resources and real-time
   communication between infrastructure components and mobile networks.
   This connection allows for efficient distribution of data, such as
   traffic alerts and safety notifications, to mobile users and
   vehicles.

   Interface 5 (I5): This is the communication interface between the
   C-ITS Infra and SDVs.  It enables bidirectional data exchange,
   allowing SDVs to receive real-time infrastructure information (e.g.,
   traffic signals, road hazards) and transmit vehicle status data back
   to the infrastructure.  This interface is critical for supporting V2I
   communications.

   Interface 6 (I6): This interface connects the MNO with both VRUs and
   SDVs.  It is used to deliver real-time safety messages, navigation
   updates, and other critical data.  It also allows VRUs and SDVs to
   send status or emergency signals back to the network.  This interface
   must ensure low-latency and secure data transmission to prevent
   accidents and improve traffic efficiency

   Interface 7 (I7): This is the management interface between the RSU
   and the C-ITS Infra.  It facilitates the configuration, monitoring,
   and management of RSUs to ensure stable communication between
   roadside infrastructure and vehicles.  It also handles firmware
   updates and diagnostics for RSUs.

   Interface 8 (I8): This interface supports V2I communication between
   SDVs through the RSU.  It allows SDVs to exchange critical
   information such as speed, direction, and emergency signals, enabling



An, et al.                Expires 9 August 2026                 [Page 9]

Internet-Draft               I2ICF for C-ITS               February 2026


   collision avoidance and cooperative driving.  This interface must
   provide real-time and reliable data exchange in dynamic traffic
   environments.

   Interface 9 (I9): This is the communication interface between SDVs
   and VRUs.  It ensures that vulnerable road users receive immediate
   safety notifications from nearby vehicles and infrastructure.  For
   example, SDVs can warn pedestrians of approaching vehicles or detect
   VRU movements in blind spots, enhancing road safety.

   Interface 10 (I10): This is the external and internal communication
   interface between multiple SDVs It enables secure and efficient
   communication within the vehicle's zonal architecture, facilitating
   seamless data exchange between various internal systems (e.g.,
   sensors, controllers) and supporting autonomous driving functions.

3.  Use Cases

   This section introduces practical use cases of the I2ICF framework
   within the context of C-ITS and MNO networking.  These use cases
   focus on emerging technologies such as SDVs, End-to-End (E2E)
   communication, and Cybersecurity, highlighting how the I2ICF
   framework can improve network efficiency, safety, and security in
   intelligent transportation environments.

   * Real-Time Data Processing for SDV: The I2ICF framework enables
   seamless communication between SDVs and C-ITS infrastructure through
   interfaces such as I5 (C-ITS Infra <-> SDV) and I8 (V2V Communication
   via RSU).  Real-time data such as traffic signals, road conditions,
   and obstacle detection are transmitted to SDVs for immediate
   processing.  By offloading certain data processing tasks to network
   devices (e.g., RSUs), SDVs can reduce internal computational load,
   allowing faster decision-making for functions like emergency braking
   or lane changes.  This distributed data processing model improves the
   overall safety and efficiency of autonomous driving.

   * E2E Communication for Cooperative Driving: The integration of MNO
   networks with C-ITS through interfaces like I4 (C-ITS Infra <-> MNO)
   and I6 (MNO <-> VRU/SDV) allows for reliable and low-latency E2E
   communication.  This connectivity is essential for cooperative
   driving scenarios, where multiple SDVs coordinate lane changes,
   merging, or platooning in real time.  The I2ICF framework ensures
   that the network can dynamically manage traffic loads and prioritize
   safety-critical data transmission, enabling vehicles to share and act
   on real-time information seamlessly.






An, et al.                Expires 9 August 2026                [Page 10]

Internet-Draft               I2ICF for C-ITS               February 2026


   * Enhanced Cybersecurity for C-ITS and MNO Integration: Given the
   extensive data exchange between vehicles, infrastructure, and network
   operators, cybersecurity is a critical component.  The Cyber Security
   System within the I2ICF framework, managed through interfaces like I3
   (Government Public Center <-> MNO) and I10 (Internal SDV
   Communication), provides E2E encryption and secure key management.
   Private keys are stored securely in the cloud and can be updated via
   Over-The-Air (OTA) mechanisms if compromised.  If a critical security
   breach occurs, the system can initiate a global reset to reissue
   encryption keys, ensuring system-wide security integrity.  This
   proactive approach minimizes the risk of cyberattacks on connected
   vehicles and infrastructure.

   * Dynamic Resource Allocation for High-Density Traffic Environments:
   In high-traffic conditions such as highways or urban intersections,
   efficient data management is crucial.  The I2ICF framework, through
   I7 (RSU <-> C-ITS Infra) and I9 (SDV <-> VRU), enables dynamic
   resource allocation.  For example, RSUs can prioritize data
   transmission for emergency vehicles or redirect network resources to
   manage traffic congestion.  This adaptive data flow management
   reduces latency and prevents network bottlenecks, ensuring that all
   vehicles and infrastructure components receive critical information
   in real time.

   * Edge Computing for Latency-Sensitive Applications: Edge computing
   capabilities are integrated into the I2ICF framework using RSUs and
   Programmable Network Devices (PNDs) to handle latency-sensitive
   tasks.  Interfaces like I1 (C-ITS Center <-> Government Public
   Center) and I8 (SDV <-> SDV via RSU) allow certain computational
   tasks such as object detection or predictive path planning to be
   processed at the network edge rather than relying on centralized
   cloud servers.  This significantly reduces response time for
   autonomous driving actions and enhances road safety by enabling
   faster vehicle reactions.

   * These use cases demonstrate how the I2ICF framework can enhance the
   performance, security, and reliability of intelligent transportation
   systems by integrating C-ITS infrastructure with MNO networks.  By
   supporting real-time data processing, secure communication, and
   dynamic resource management, the framework addresses the complex
   demands of modern SDVs and connected mobility solutions.










An, et al.                Expires 9 August 2026                [Page 11]

Internet-Draft               I2ICF for C-ITS               February 2026


4.  Security Considerations

   The I2ICF framework for C-ITS and MNO Networking offers numerous
   advantages for various applications.  However, due to the framework's
   extensive connectivity between diverse vehicles, devices, centers,
   clouds, and VRUs, a vast amount of information and functionalities
   are exposed during network configuration, leading to potential
   security risks.  To ensure the overall security of the entire system,
   the following measures are recommended: First, the application
   development system should be controlled by the same service providers
   (e.g., cloud service providers or network operators) that own the
   network and computing infrastructure.  Second, devices within the
   cloud center should be pre-configured with security zones to isolate
   traffic, preventing it from affecting other network traffic.  Third,
   encryption keys for each device should be centrally managed by the
   cloud center.  In the event of key exposure, the system should
   support Over-The-Air (OTA) updates to promptly replace compromised
   keys.  Fourth, if a security breach occurs within the centralized
   management system, exposing encryption keys, the entire system should
   undergo a reset to perform a security initialization.  This process
   will generate and distribute new encryption keys to ensure the
   continued protection of sensitive data.

5.  A2A Use Cases for SDV and C-ITS Integration

   In emerging SDV ecosystems, seamless coordination among vehicle
   agents, C-ITS infrastructure agents, and MNO agents becomes essential
   for achieving real-time awareness and adaptive network optimization.
   The _A2A_ communication paradigm enables direct interaction among
   these heterogeneous entities without relying solely on centralized
   control mechanisms.  For instance, SDV agents can dynamically
   negotiate data offloading, perform network slicing, or compute
   resource scheduling with MNO agents in response to vehicular mobility
   and network conditions, while roadside infrastructure agents exchange
   situational context such as congestion level, edge compute
   availability, or safety alerts with SDV agents to support cooperative
   perception and hazard prediction.  These A2A interactions facilitate
   distributed decision-making across application and network layers,
   forming the basis for intelligent coordination and resilient service
   continuity in connected mobility.

   When integrated with the proposed I2ICF framework, such A2A-based
   orchestration allows SDVs, RSUs, and MNO backends to jointly manage
   ICFs, thereby ensuring low-latency, secure, and reliable service
   delivery across multi-domain C-ITS environments.  This approach
   follows recognized architectures and standards used in C-ITS and V2X
   systems, including frameworks for security management and network
   data analytics.  Leveraging these industry standards, A2A



An, et al.                Expires 9 August 2026                [Page 12]

Internet-Draft               I2ICF for C-ITS               February 2026


   coordination can extend beyond individual domains to enable intent-
   driven, cross-layer management of communication, computation, and
   data analytics among SDV, C-ITS, and MNO ecosystems.

6.  IANA Considerations

   TBD.

7.  References

7.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC8329]  Lopez, D., Lopez, E., Dunbar, L., Strassner, J., and R.
              Kumar, "Framework for Interface to Network Security
              Functions", RFC 8329, DOI 10.17487/RFC8329, February 2018,
              <https://www.rfc-editor.org/info/rfc8329>.

   [RFC8799]  Carpenter, B. and B. Liu, "Limited Domains and Internet
              Protocols", RFC 8799, DOI 10.17487/RFC8799, July 2020,
              <https://www.rfc-editor.org/info/rfc8799>.

7.2.  Informative References

   [I-D.irtf-coinrg-use-cases]
              Kunze, I., Wehrle, K., Trossen, D., Montpetit, M., de Foy,
              X., Griffin, D., and M. Rio, "Use Cases for In-Network
              Computing", Work in Progress, Internet-Draft, draft-irtf-
              coinrg-use-cases-07, 4 December 2024,
              <https://datatracker.ietf.org/doc/html/draft-irtf-coinrg-
              use-cases-07>.

   [I-D.jeong-nmrg-i2icf-problem-statement]
              Jeong, J. P., Shen, Y. C., Ahn, Y., Kim, Y., Duarte, E.
              P., and K. Yao, "Interface to In-Network Computing
              Functions (I2ICF): Problem Statement", Work in Progress,
              Internet-Draft, draft-jeong-nmrg-i2icf-problem-statement-
              00, 20 October 2025,
              <https://datatracker.ietf.org/doc/html/draft-jeong-nmrg-
              i2icf-problem-statement-00>.

   [I-D.rosenberg-ai-protocols]
              Rosenberg, J. and C. F. Jennings, "Framework, Use Cases
              and Requirements for AI Agent Protocols", Work in



An, et al.                Expires 9 August 2026                [Page 13]

Internet-Draft               I2ICF for C-ITS               February 2026


              Progress, Internet-Draft, draft-rosenberg-ai-protocols-00,
              5 May 2025, <https://datatracker.ietf.org/doc/html/draft-
              rosenberg-ai-protocols-00>.

   [I-D.yang-nmrg-a2a-nm]
              YUANYUANYANG, Wu, Q., Lopez, D., Moreno, N. R.,
              Tailhardat, L., and D. H. CHIHI, "Applicability of A2A to
              the Network Management", Work in Progress, Internet-Draft,
              draft-yang-nmrg-a2a-nm-00, 6 July 2025,
              <https://datatracker.ietf.org/doc/html/draft-yang-nmrg-
              a2a-nm-00>.

   [I-D.yao-tsvwg-cco-problem-statement-and-usecases]
              Yao, K., Shiping, X., Li, Y., Huang, H., and D. KUTSCHER,
              "Collective Communication Optimization: Problem Statement
              and Use cases", Work in Progress, Internet-Draft, draft-
              yao-tsvwg-cco-problem-statement-and-usecases-00, 23
              October 2023, <https://datatracker.ietf.org/doc/html/
              draft-yao-tsvwg-cco-problem-statement-and-usecases-00>.

Acknowledgments

   This work was supported by Institute of Information & Communications
   Technology Planning & Evaluation (IITP) grant funded by the Korea
   Ministry of Science and ICT (MSIT) (No.RS-2024-00397615, Development
   of an automotive software platform for Software-Defined-Vehicle (SDV)
   integrated with an AI framework required for intelligent vehicles).

   This work was in part supported by Institute of Information &
   Communications Technology Planning & Evaluation (IITP) grant funded
   by the Korea Ministry of Science and ICT (MSIT) (No.  RS-
   2024-00398199 and RS-2022-II221015).

Authors' Addresses

   Byoungman Robert An (editor)
   Intelligent Information R and D Division Mobility Platform Research Center
   Global R and D Center 6th floor
   #22, Daewangpangyo-ro 712beon-gil
   Seongnam
   Gyeonggi-Do
   13488
   Republic of Korea
   Phone: +82 31 739 7463
   Email: bman@keti.re.kr
   URI:   https://www.keti.re.kr/eng/main/main.php





An, et al.                Expires 9 August 2026                [Page 14]

Internet-Draft               I2ICF for C-ITS               February 2026


   Jaehoon Paul Jeong (editor)
   Department of Computer Science & Engineering
   Sungkyunkwan University
   2066 Seobu-Ro, Jangan-Gu
   Suwon
   Gyeonggi-Do
   16419
   Republic of Korea
   Phone: +82 31 299 4957
   Email: pauljeong@skku.edu
   URI:   http://iotlab.skku.edu/people-jaehoon-jeong.php


   Pusik Park
   Intelligent Information R and D Division Mobility Platform Research Center
   Global R and D Center 6th floor
   #22, Daewangpangyo-ro 712beon-gil
   Seongnam
   Gyeonggi-Do
   13488
   Republic of Korea
   Phone: +82-31-739-7507
   Email: pusik.park@keti.re.kr
   URI:   https://www.keti.re.kr/eng/main/main.php


   Soohyun Jang
   Intelligent Information R and D Division Mobility Platform Research Center
   Global R and D Center 6th floor
   #22, Daewangpangyo-ro 712beon-gil
   Seongnam
   Gyeonggi-Do
   13488
   Republic of Korea
   Phone: +82-31-739-7436
   Email: shjang@keti.re.kr
   URI:   https://www.keti.re.kr/eng/main/main.php














An, et al.                Expires 9 August 2026                [Page 15]


name: draft-ietf-mailmaint-pacc
rev: 02
title: Automatic Configuration of Email, Calendar, and Contact Server Settings
time: 2026-02-27T17:19:25Z
group_uri: /api/v1/group/group/2418/
expires: 2026-08-31T17:19:25Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: ["Data formats/interop"]
tags: []
fetched_at: 2026-02-27T22:56:05.127731+00:00
abstract:
This document specifies an automatic configuration mechanism for
   email, calendar, and contact user agent applications.  Service
   providers publish standardized configuration information that user
   agent applications retrieve and use to simplify server setup
   procedures.

full_text:
mailmaint                                                      D. Eggert
Internet-Draft                                                 Apple Inc
Intended status: Standards Track                              B. Bucksch
Expires: 31 August 2026                                           Beonex
                                                            M. Diephouse
                                                               Apple Inc
                                                        27 February 2026


Automatic Configuration of Email, Calendar, and Contact Server Settings
                      draft-ietf-mailmaint-pacc-02

Abstract

   This document specifies an automatic configuration mechanism for
   email, calendar, and contact user agent applications.  Service
   providers publish standardized configuration information that user
   agent applications retrieve and use to simplify server setup
   procedures.

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 31 August 2026.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.










Eggert, et al.           Expires 31 August 2026                 [Page 1]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


   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  . . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Document Conventions  . . . . . . . . . . . . . . . . . . . .   3
   3.  Overview  . . . . . . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  Server Requirements Summary . . . . . . . . . . . . . . .   5
     3.2.  Client Requirements Summary . . . . . . . . . . . . . . .   5
   4.  JSON Configuration  . . . . . . . . . . . . . . . . . . . . .   5
     4.1.  Example . . . . . . . . . . . . . . . . . . . . . . . . .   6
     4.2.  Protocols . . . . . . . . . . . . . . . . . . . . . . . .   7
     4.3.  Authentication  . . . . . . . . . . . . . . . . . . . . .   8
     4.4.  Informational . . . . . . . . . . . . . . . . . . . . . .   8
       4.4.1.  Provider Information  . . . . . . . . . . . . . . . .   9
       4.4.2.  Help  . . . . . . . . . . . . . . . . . . . . . . . .  10
   5.  Flow  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  10
     5.1.  Email Address . . . . . . . . . . . . . . . . . . . . . .  10
     5.2.  Configuration Source  . . . . . . . . . . . . . . . . . .  11
       5.2.1.  Well-Known Uniform Resource Identifier  . . . . . . .  11
       5.2.2.  DNS-Based Digest Validation . . . . . . . . . . . . .  12
     5.3.  Configuration JSON Validation . . . . . . . . . . . . . .  17
     5.4.  Selecting Protocols and Authentication  . . . . . . . . .  18
       5.4.1.  OAuth . . . . . . . . . . . . . . . . . . . . . . . .  19
       5.4.2.  HTTP Authentication Mechanisms  . . . . . . . . . . .  19
       5.4.3.  Other Protocols Authentication Mechanisms . . . . . .  20
     5.5.  Confirming Server Names . . . . . . . . . . . . . . . . .  23
     5.6.  Username  . . . . . . . . . . . . . . . . . . . . . . . .  24
     5.7.  Configuring OAuth . . . . . . . . . . . . . . . . . . . .  25
     5.8.  Configuring Password-Based Authentication . . . . . . . .  25
   6.  Configuration Validation  . . . . . . . . . . . . . . . . . .  25
     6.1.  User Approval . . . . . . . . . . . . . . . . . . . . . .  25
     6.2.  OAuth2 requirements . . . . . . . . . . . . . . . . . . .  26
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .  26
     7.1.  Mistyped Domain Names . . . . . . . . . . . . . . . . . .  26
     7.2.  Attacker Controlled JSON Configuration  . . . . . . . . .  27
     7.3.  DNS . . . . . . . . . . . . . . . . . . . . . . . . . . .  27
     7.4.  Transport Security Validation . . . . . . . . . . . . . .  28
     7.5.  Updating the Configuration  . . . . . . . . . . . . . . .  28
     7.6.  Provider Information  . . . . . . . . . . . . . . . . . .  29
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  29



Eggert, et al.           Expires 31 August 2026                 [Page 2]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


     8.1.  The User-Agent Auto-Configuration Protocol Registry . . .  29
       8.1.1.  Registration Template . . . . . . . . . . . . . . . .  29
       8.1.2.  Initial Registrations . . . . . . . . . . . . . . . .  30
     8.2.  Registration  . . . . . . . . . . . . . . . . . . . . . .  31
       8.2.1.  Registration of Well-Known URI
               user-agent-configuration  . . . . . . . . . . . . . .  31
       8.2.2.  Registration of DNS Underscore Label
               _ua-auto-config . . . . . . . . . . . . . . . . . . .  31
   9.  Normative References  . . . . . . . . . . . . . . . . . . . .  31
   Appendix A.  Configuration JSON Schema  . . . . . . . . . . . . .  35
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  38
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  38

1.  Introduction

   Manual configuration of email, calendar, and contact user agent
   applications requires users to correctly specify numerous technical
   parameters including server hostnames, port numbers, and
   authentication protocols.  This manual process frequently results in
   configuration errors and setup failures, even among technically
   skilled users.

   This document defines a mechanism that significantly simplifies this
   configuration process.  Service providers can publish standardized
   configuration data that user agents can automatically retrieve and
   use.  In most cases, users need only provide their email address and
   account password to complete the setup.

   For service providers that support the OAuth Profile for Open Public
   Clients [OAuthPublic], this mechanism also enables automatic OAuth
   configuration.  The user agent automatically determines all necessary
   details to set up OAuth authentication for the associated account.

2.  Document Conventions

   In protocol examples, this document uses a prefix of "C: " to denote
   lines sent by the user agent to the server, and "S: " for lines sent
   by the server to the user agent.  Lines prefixed with "// " are
   comments explaining the previous protocol line.  These prefixes and
   comments are not part of the protocol.  Lines without any of these
   prefixes are continuations of the previous line, and no line break is
   present in the protocol unless specifically mentioned.

   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.



Eggert, et al.           Expires 31 August 2026                 [Page 3]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


3.  Overview

   The automatic configuration process begins when a user wants to set
   up their user agent application.  The user agent requests the user's
   email address and then uses the domain portion of that address to
   retrieve configuration data for the account.

   Configuration retrieval uses the Well-Known URIs mechanism defined in
   [RFC8615].  The specific suffix for this configuration is user-agent-
   configuration.  Section 5.2 provides detailed information about the
   retrieval process.

   The configuration is provided as a JSON document (detailed in
   Section 4) that informs the user agent about:

   *  Human-readable information about the service provider

   *  Supported protocols for this domain

   *  Server endpoints for each protocol

   *  OAuth Profile for Open Public Clients support availability

   The user agent uses this configuration to determine whether the
   provider supports protocols that the user agent can also use, helping
   decide whether to continue with the setup process.  For example, an
   email user agent might check for support of JMAP, IMAP, POP3, and
   SMTP protocols.

   Next, the user agent typically connects to the relevant services to
   verify which authentication methods they support and whether the user
   agent can use those methods.  For instance, if the user agent needs
   both IMAP and SMTP, it will connect to both servers to check their
   capabilities and confirm compatibility with the user agent's
   supported authentication mechanisms.

   Based on the available options, the user agent then proceeds with one
   of two approaches:

   1.  Continue configuration using OAuth Profile for Open Public
       Clients, or

   2.  Request the user's password for traditional authentication

   Finally, the user agent uses the obtained credentials (OAuth tokens
   or password) to connect to the servers specified in the configuration
   document and validates that the credentials work correctly with the
   desired protocols.



Eggert, et al.           Expires 31 August 2026                 [Page 4]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


3.1.  Server Requirements Summary

   The following is a non-normative, high-level summary of what a server
   operator needs to implement.

   *  Publish a JSON configuration document at a well-known HTTPS URI,
      listing the domain's supported protocols and their server
      endpoints.

   *  Publish DNS TXT records containing a digest of that configuration
      document, so clients can verify its integrity.

   *  Accept the user's full email address as the username on all
      servers listed in the configuration.

   *  Optionally, support the OAuth Profile for Open Public Clients to
      enable OAuth-based authentication.

3.2.  Client Requirements Summary

   The following is a non-normative, high-level summary of what a client
   needs to implement.

   *  Ability to construct the well-known URI from a user's email
      address and retrieve the JSON configuration document over HTTPS.

   *  Ability to validate the configuration document's integrity by
      comparing its digest against a DNS TXT record.

   *  Ability to connect to each server listed in the configuration and
      retrieve its supported authentication mechanisms.

   *  User interface to present the server hostnames for the user to
      confirm before any credentials are entered.

   *  Support for OAuth Profile for Open Public Clients and/or password-
      based authentication, to complete account setup.

4.  JSON Configuration

   The configuration document describes which services are available and
   their corresponding endpoints for a specific domain.

   The configuration file MUST conform to the JSON schema specification
   provided in Appendix A.






Eggert, et al.           Expires 31 August 2026                 [Page 5]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


   The configuration uses the media type application/json.  The HTTP
   server MUST set the corresponding Content-Type header as specified in
   [RFC9110].

4.1.  Example

   The following example demonstrates a typical JSON configuration:

   ========== NOTE: '\' line wrapping per RFC 8792 ===========

   {
       "protocols": {
           "jmap": {
               "url": "https://jmap.example.com/session"
           },
           "imap": {
               "host": "imap.example.com"
           },
           "pop3": {
               "host": "pop3.example.com"
           },
           "smtp": {
               "host": "smtp.example.com"
           },
           "caldav": {
               "url": "https://sync.example.com/calendar/"
           },
           "carddav": {
               "url": "https://sync.example.com/contacts/"
           }
       },
       "authentication": {
           "oauth-public": {
               "issuer": "https://auth.example.com/"
           },
           "password": true
       },
       "info": {
           "provider": {
               "name": "Example Provider Name",
               "shortName": "Example",
               "logo": [
                   {
                       "url": "https://www.example.net/logo.svg",
                       "content-type": "image/svg+xml"
                   }
               ]
           },



Eggert, et al.           Expires 31 August 2026                 [Page 6]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


           "help": {
               "documentation": "https://help.example.net/howto/\
                   set-up-your-mail-app.html",
               "developer": "https://developer.example.net/\
                   client-apps/",
               "contact": ["mailto:it@team.example.net"]
           }
       }
   }

4.2.  Protocols

   The protocols object specifies all protocols that the domain supports
   and identifies the server endpoint for each protocol.

   For the following HTTP-based protocols:

   *  JMAP defined in [RFC8620],

   *  CalDAV defined in [RFC4791], and

   *  CardDAV defined in [RFC6352]

   *  WebDAV defined in [RFC4918]

   each protocol entry MUST include a url value containing a URL with
   the https scheme.  This URL MUST specify an endpoint that serves the
   corresponding protocol.  The server MUST use the default port 443 for
   HTTPS, and the URL MUST NOT include an explicit port number.

   Hostnames in URLs MUST support Internationalized Domain Names (IDNs)
   as defined in [RFC5890] and [RFC5891].  Service providers MAY use
   either Unicode labels (u-labels) or ASCII Compatible Encoding labels
   (a-labels) in their configuration.  User agents MUST support both
   forms and handle the conversion between them as specified in
   [RFC5891].

   Example:

   "jmap": {
       "url": "https://jmap.example.com/session"
   }

   For the following text-based protocols:

   *  IMAP defined in [RFC9051],

   *  SMTP defined in [RFC5321], and



Eggert, et al.           Expires 31 August 2026                 [Page 7]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


   *  POP3 defined in [RFC1939]

   *  ManageSieve defined in [RFC5804]

   each protocol entry MUST include a host value specifying the hostname
   of the server that provides the corresponding protocol.  The server
   MUST use the default port number for that protocol, with connections
   secured using TLS.  Section 5.4.3 goes into details about TLS and
   which ports to use.

   Hostnames MUST support Internationalized Domain Names (IDNs) as
   defined in [RFC5890] and [RFC5891].  Service providers MAY use either
   Unicode labels (u-labels) or ASCII Compatible Encoding labels
   (a-labels) in their configuration.  User agents MUST support both
   forms and handle the conversion between them as specified in
   [RFC5891].

   Example:

   "imap": {
       "host": "imap.mail.example.com"
   }

4.3.  Authentication

   The authentication object specifies which authentication mechanisms
   the provider supports.

   The nested password value indicates whether the provider supports
   username and password authentication.

   The nested oauth-public object contains a single issuer value that
   specifies the authorization server's issuer identifier as defined in
   [RFC8414].  This value is a URL that uses the https scheme and has no
   query or fragment components.  User agents can use this identifier
   for authentication via [OAuthPublic].  The presence of the oauth-
   public object indicates that the provider supports OAuth.

4.4.  Informational

   The info object contains information that user agents can present to
   users.  The only required field is info/provider/name, which SHOULD
   clearly identify the provider to the user.  The optional
   info/provider/shortName provides a shorter version of name.

   The info/provider/logo array can contain one or more entries pointing
   to the provider's logo images.  User agents can use these to display
   the provider's logo to users.



Eggert, et al.           Expires 31 August 2026                 [Page 8]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


   The info/help/documentation field provides a URL that can be
   presented to users for additional information about the provider.
   The info/help/developer field contains a URL with information
   specifically for user agent developers.  The info/help/contact array
   lists URLs that users can use to contact the provider, such as mailto
   URLs.

   A minimal info example:

   "info": {
       "provider": {
           "name": "Example Provider Name"
       }
   }

4.4.1.  Provider Information

   provider object can have name, shortName, and logo properties.

   The name and shortName values are intended for display to the user.

   The name property specifies the provider's display name, such as the
   name used in the provider's marketing materials.  It SHOULD be no
   longer than 30 characters, but MUST be no longer than 60 characters.

   The shortName property is optional.  It specifies a brief version of
   the provider's name, as commonly recognized by users.  It SHOULD be
   no longer than 12 characters, and it MUST NOT be longer than 20
   characters.

   Both name and shortName MUST NOT include any Control-characters and
   SHOULD NOT include any excessive white space.

   The logo property contains an array of provider logo variants.  User
   agents select the variant that best matches their UI requirements and
   technical constraints.

   Each object in the array contains the following properties:

   *  url - Location where the logo can be retrieved.  User agents MAY
      download the logo file during configuration and store it locally.

   *  content-type - Media type of the logo image.  This follows
      [RFC2045] media type format, specifying the main type and subtype
      without parameters.  The main media type MUST be image.

   *  width - Image width in pixels.  Optional.  Omitted for SVG files.




Eggert, et al.           Expires 31 August 2026                 [Page 9]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


   *  height - Image height in pixels.  Optional.  Omitted for SVG
      files.

   The logos SHOULD at least include one of each

   *  image/svg+xml

   *  image/png with size 128 by 128

   *  image/png with size 512 by 512

   If the server provides images in the SVG format, these images MUST
   use the SVG Tiny PS Profile specified in [I-D.svg-tiny-ps-abrotman].

4.4.2.  Help

   These fields are intended to allow a service provider to provide
   additional information about configuring user agents.

   The documentation property should link to a document intended for
   users.  It can provide additional information to users about how to
   configure their user agent.  A user agent MAY choose to display a
   link to this URL.  User agent SHOULD NOT display links with a URL
   scheme other than https.

   The developer property should link to a document intended for user
   agent developers.  The document this URL links to can provide
   additional information to the developer.

   The contact property should provide a way for user agent developers
   to contact the service providers.  It is _not_ intended as a way for
   users to contact the service provider.  User agents MUST NOT display
   this link in their user interface.  This URL would typically be a
   mailto URL or a URL linking to a contact form for developers to use.

5.  Flow

   Section 3 provides a high-level overview of the automatic
   configuration process.  This section details the individual steps
   involved in this process.

5.1.  Email Address

   During the initial configuration process, the user agent requests the
   user's email address.  User agents SHOULD accept any valid mailbox
   format as specified in Section 3.4 of [RFC5322].





Eggert, et al.           Expires 31 August 2026                [Page 10]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


5.2.  Configuration Source

   After the user provides their email address, the user agent extracts
   the domain part of the user's email address according to
   Section 3.4.1 of [RFC5322].  For example:

           +================================+=================+
           | Text Entered by User           | domain          |
           +================================+=================+
           | jdoe@foo.example.com           | foo.example.com |
           +--------------------------------+-----------------+
           | "J Doe" <jdoe@foo.example.com> | foo.example.com |
           +--------------------------------+-----------------+
           | <jdoe@foo.example.com>         | foo.example.com |
           +--------------------------------+-----------------+

                    Table 1: Domain from email address

   This domain is then used to retrieve the JSON configuration resource
   using well-known URIs with DNS-based digest validation.

5.2.1.  Well-Known Uniform Resource Identifier

   The user agent retrieves configuration data over HTTP using the
   format described in Section 4.

   Configuration retrieval uses [RFC8615] Well-Known URIs.  The user
   agent constructs the URI using the _domain_ from the user's email
   address and the _configuration name_ user-agent-configuration.  The
   detailed URI construction process is specified in [RFC8615].

   The domain name MUST support Internationalized Domain Names (IDNs) as
   defined in [RFC5890] and [RFC5891].  User agents MUST handle both
   Unicode labels (u-labels) and ASCII Compatible Encoding labels
   (a-labels) when processing domain names from email addresses, and
   convert them appropriately for URI construction as specified in
   [RFC5891].

   The URI follows this template:

   ========== NOTE: '\' line wrapping per RFC 8792 ===========

   https://ua-auto-config.{domain}/\
     .well-known/user-agent-configuration.json

   If the user's email address' domain is foo.example.com, the user
   agent constructs the following URI:




Eggert, et al.           Expires 31 August 2026                [Page 11]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


   ========== NOTE: '\' line wrapping per RFC 8792 ===========

   https://ua-auto-config.foo.example.com/\
     .well-known/user-agent-configuration.json

   This URI always uses the https scheme.  User agents MUST retrieve the
   configuration file only via https (HTTP over TLS).

   The user agent MUST validate that the connection is secured by TLS.
   See Section 7.4 for details about TLS with respect to retrieving the
   configuration.

   The media type of the configuration is application/json, and the HTTP
   server MUST set a corresponding Content-Type type header.  See
   [RFC9110].  The user agent MUST validate that the content-type of the
   returned resource is application/json.

   The HTTP server that serves the JSON configuration MUST NOT require
   any form of HTTP authentication to return the configuration.

   For example:

   C: GET /.well-known/user-agent-configuration.json HTTP/2
   C: Host: foo.example.com
   C: user-agent: curl/8.4.0
   C: accept: application/json
   C:

   S: HTTP/2 200
   S: server: nginx/1.25.3
   S: date: Mon, 23 Oct 2025 10:30:00 GMT
   S: content-type: application/json
   S: content-length: 1184
   S:
   S: {
   S:     "protocols": {
   S:         "jmap": {
   S: ...

5.2.2.  DNS-Based Digest Validation

   After retrieving the auto-configuration resource from the well-known
   URI as described in Section 5.2.1, the user agent MUST validate its
   integrity before use.  This validation is performed by comparing a
   locally computed digest of the resource against a digest published in
   a DNS TXT resource record (RR).





Eggert, et al.           Expires 31 August 2026                [Page 12]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


   If the validation fails, the user agent MUST ignore the auto-
   configuration resource.

5.2.2.1.  Validation Procedure

   The user agent MUST perform the following steps to validate the auto-
   configuration resource:

   1.  Let the "decoded message content" be the payload body of the HTTP
       response after all Transfer-Encoding (e.g., "chunked") and
       Content-Encoding (e.g., "gzip", "br") transformations have been
       reversed.  This is the final, decompressed representation of the
       resource.  See Section 6.1 of [RFC9112] and Section 8.4 of
       [RFC9110] for details on these encodings.

   2.  Construct a DNS query QNAME using the template _ua-auto-
       config.{domain}, where {domain} is the domain part of the user's
       identifier (e.g., "foo.example.com" for "jdoe@foo.example.com").

   3.  Perform a DNS query for the TXT RR type at the constructed QNAME.
       The response may contain multiple TXT RRs.

   4.  For each TXT RR returned in the DNS response:

       a.  Parse the record according to the syntax in Section 5.2.2.2.
           If the record is malformed or is missing any of the mandatory
           tags (v, a, d), discard this RR and proceed to the next one.

       b.  Let the "remote algorithm" be the value of the a tag.  If the
           user agent does not support this algorithm, discard this RR
           and proceed to the next one.

       c.  Let the "remote digest" be the Base64-decoded value of the d
           tag.  If decoding fails, discard this RR and proceed to the
           next one.

       d.  Using the "remote algorithm", compute a "local digest" of the
           "decoded message content" obtained in step 1.

       e.  Perform a byte-for-byte comparison of the "local digest" and
           the "remote digest".  If they are identical, the validation
           is successful.  The user agent MUST immediately stop
           processing further TXT RRs and MAY use the auto-configuration
           resource.







Eggert, et al.           Expires 31 August 2026                [Page 13]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


   5.  If, after checking all valid and supported TXT RRs, no match is
       found, the validation has failed.  The user agent MUST discard
       the "decoded message content" and behave as if no auto-
       configuration resource was found.

   Note: A compliant HTTP client library will typically handle the
   decoding of Transfer-Encoding and Content-Encoding transparently.
   The requirement in this document is to ensure that the digest is
   computed on the final data, not on an intermediate, encoded
   representation.

5.2.2.2.  DNS Resource Record for Auto-Configuration

   Configuration information for a given domain is published as a DNS
   TXT resource record (RR) at a special name, _ua-auto-config,
   prepended to the domain name.  For example, for the domain
   example.com, the lookup would be for a TXT record at _ua-auto-
   config.example.com.

5.2.2.2.1.  Record Syntax

   The content of the TXT RR is a string of tag=value pairs separated by
   semicolons (;).  Tags are short ASCII strings that identify a
   particular parameter.  Values are ASCII strings whose format depends
   on the tag.

   The formal syntax of the record is described using ABNF [RFC5234] as
   follows:























Eggert, et al.           Expires 31 August 2026                [Page 14]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


   config-record   = tag-value *( *WSP ";" *WSP tag-value ) *WSP [";"]

   tag-value       = version-tag / alg-tag / digest-tag / future-tag

   version-tag     = "v" *WSP "=" *WSP "UAAC1"
   alg-tag         = "a" *WSP "=" *WSP digest-algorithm
   digest-algorithm = "sha256"
   digest-tag      = "d" *WSP "=" *WSP 1*base64-char

   future-tag      = 1*tag-name *WSP "=" *WSP 1*tag-value-char

   tag-name        = ALPHA / DIGIT
   tag-value-char  = %x21-3A / %x3C-7E ; Any visible ASCII char
                                 ; except semicolon

   base64-char     = ALPHA / DIGIT / "+" / "/" / "="
   ; As defined in Section 4 of RFC 4648

   WSP             = " " / HTAB
   ; As defined in Appendix B.1 of RFC 5234

5.2.2.2.2.  Tags

   The following tags are defined.  Tag names are case-sensitive and
   MUST be processed as lowercase.

   +-----+------------------------------------------------+-----------+
   | Tag | Description                                    | Status    |
   +-----+------------------------------------------------+-----------+
   | v   | Version.  The value MUST be "UAAC1" for        | Mandatory |
   |     | records compliant with this specification.     |           |
   +-----+------------------------------------------------+-----------+
   | a   | Digest Algorithm.  The value MUST be "sha256". | Mandatory |
   |     | This identifies the algorithm used to create   |           |
   |     | the digest in the 'd' tag.                     |           |
   +-----+------------------------------------------------+-----------+
   | d   | Digest.  The Base64-encoded digest of the JSON | Mandatory |
   |     | resource described in Section 5.2.1.  The      |           |
   |     | encoding MUST follow Section 4 of [RFC4648].   |           |
   +-----+------------------------------------------------+-----------+

                          Table 2: Defined Tags

5.2.2.2.3.  Digest Algorithm

   SHA-256 ("sha256") as defined in [RFC6234] is the supported digest
   algorithm.




Eggert, et al.           Expires 31 August 2026                [Page 15]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


   The digest is computed over the raw bytes of the JSON resource
   retrieved from the well-known URI, after any HTTP transfer or content
   encoding has been decoded.

   Servers MUST publish a DNS record using the SHA-256 algorithm.

5.2.2.2.4.  Parsing Rules

   A client parsing the record MUST adhere to the following rules:

   *  The record MUST contain the v, a, and d tags.  If any of these
      tags are missing, the record is invalid and MUST be ignored.

   *  The order of the tags is not significant.

   *  Whitespace (WSP) is permitted on either side of the = and ;
      separators and MUST be ignored.

   *  If a tag is encountered that is not defined in this document
      (e.g., a tag from a future version), the parser MUST ignore that
      entire tag=value pair.  This allows for future extensions.

   *  If any of the mandatory tags (v, a) have values other than those
      specified in this document, the record is invalid and MUST be
      ignored.

5.2.2.3.  Example

   This example demonstrates the configuration retrieval process for a
   user with email address user@example.com.

   The user agent performs the following steps:

   1.  Constructs the well-known URI from the email domain:

      ========== NOTE: '\' line wrapping per RFC 8792 ===========

      https://ua-auto-config.example.com/\
        .well-known/user-agent-configuration.json

   2.  Retrieves the JSON configuration over HTTPS and receives:










Eggert, et al.           Expires 31 August 2026                [Page 16]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


      {
          "protocols": {
              "jmap": {
                  "url": "https://jmap.example.com/session"
              },
              "imap": {
                  "host": "imap.example.com"
              },
              "smtp": {
                  "host": "smtp.example.com"
              }
          },
          "authentication": {
              "oauth-public": {
                  "issuer": "https://auth.example.com/"
              },
              "password": true
          },
          "info": {
              "provider": {
                  "name": "Example Provider"
              }
          }
      }

   3.  Queries DNS for TXT record at _ua-auto-config.example.com and
       receives:

      ========== NOTE: '\' line wrapping per RFC 8792 ===========

      _ua-auto-config.example.com.    TXT    "v=UAAC1; a=sha256; \
        d=K7gNU3sdo+OL0wNhqoVWhr3g6s1xYv72ol/pe/Unols="

   4.  Computes the SHA-256 digest of the retrieved JSON configuration
       and verifies it matches the digest in the DNS TXT record.

   5.  Since validation succeeds, the user agent may proceed to use this
       configuration for account setup.

5.3.  Configuration JSON Validation

   After successfully retrieving a configuration resource, user agents
   MUST validate that the configuration contains valid JSON syntax
   according to RFC 8259.  Additionally, user agents MUST validate the
   retrieved configuration against the JSON schema specification
   provided in Appendix A.  If the JSON syntax is invalid, user agents
   MUST ignore the configuration entirely and not use any portion of it.




Eggert, et al.           Expires 31 August 2026                [Page 17]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


   User agents MUST process only the properties that they support and
   MUST ignore properties not specified in the schema.  This requirement
   enables future extensions of the format without breaking existing
   user agent implementations.

5.4.  Selecting Protocols and Authentication

   After successfully retrieving and validating the configuration JSON,
   the user agent needs to determine:

   *  Which protocols to use

   *  Which authentication mechanism to employ

   Both user agents and servers support multiple protocols.  The user
   agent needs to decide which protocols to use and determine whether
   the protocols specified in the configuration are sufficient to
   proceed.  This document does not provide recommendations regarding
   protocol preferences or minimum protocol requirements, as these
   decisions depend on the specific needs and implementation details of
   individual user agents.

   The automatic configuration flow supports two distinct authentication
   types:

   *  Username and password-based authentication

   *  OAuth-based authentication

   User agents can support one or both authentication methods.
   Similarly, servers for each protocol can support one or both methods.
   Additionally, the specific implementation details of authentication
   can vary between protocols.

   User agents SHOULD probe each protocol and server of interest to
   determine compatible authentication methods.  This probing process
   can influence the user agent's protocol selection and allows the user
   agent to verify server availability.

   This document does not provide recommendations regarding protocol
   preferences.  The user agent MUST make these decisions based on its
   needs.

   If the user agent determines that it can use either password-based
   authentication or OAuth authentication, the user agent SHOULD prefer
   OAuth-based authentication.





Eggert, et al.           Expires 31 August 2026                [Page 18]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


5.4.1.  OAuth

   The JSON configuration includes an oauth-public entry when the
   provider supports OAuth.  The issuer value specifies the
   authorization server's issuer identifier.  According to Section 2.2
   of [OAuthPublic], the OAuth Authorization Server Metadata is served
   at a URL constructed using this issuer value with the template

   {issuer}/.well-known/oauth-authorization-server

   For example, if the JSON configuration contains this entry:

   "oauth-public" : {
       "issuer" : "https://auth.example.com"
   },

   the OAuth Authorization Server Metadata would be at the URL
   https://auth.example.com/.well-known/oauth-authorization-server

   Note that as defined in [RFC8414], the authorization server's issuer
   identifier MUST be a URL that uses the https scheme without any query
   or fragment components.  Clients MUST verify that the issuer value is
   valid according to [RFC8414].

   Before the user agent chooses to use OAuth for any protocols, it
   SHOULD make sure that it can retrieve the OAuth Authorization Server
   Metadata from the corresponding URI.

   The user agent SHOULD connect to each protocol that it might be
   interested in to detect which authentication mechanism it supports.
   The user agent MUST NOT perform any authentication at this point, but
   it SHOULD record which mechanism(s) the server for each protocol of
   interest supports.

   The user agent SHOULD still probe each server as described in the
   next sections 5.4.2 and 5.4.3 to check that the servers it is
   interested in have OAuth support.

5.4.2.  HTTP Authentication Mechanisms

   To check which HTTP authentication schemes a particular HTTP server
   supports, the user agent SHOULD send a request to the server's
   endpoint without any Authorization header.  For example:

   GET /jmap/session HTTP/1.1
   host: api.example.com
   accept: application/json




Eggert, et al.           Expires 31 August 2026                [Page 19]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


   As detailed in [RFC9110] the server SHOULD respond to this with a 401
   Unauthorized status code and a www-authenticate response header
   indicating which authentication scheme(s) are supported.

   The user agent SHOULD include an accept header with the content type
   it would expect for the given protocol.  For JMAP, for example, the
   user agent SHOULD include accept: application/json as a header in
   this request.

   If the server supports OAuth, the www-authenticate response header
   would include Bearer.  [RFC6749] describes this in more detail.
   [RFC6750] and [RFC7616] describe username + password authentication
   using the so-called 'Basic' HTTP authentication scheme and the HTTP
   digest access authentication respectively.  Other password based
   authentication mechanisms exist for HTTP, but their discussion is
   outside the scope of this document.

   For example, a response header

   HTTP/1.1 401 Unauthorized
   www-authenticate: Bearer realm="api.example.com"

   would indicate that the server supports OAuth.

   Alternatively, a response such as

   ========== NOTE: '\' line wrapping per RFC 8792 ===========

   HTTP/1.1 401 Unauthorized
   www-authenticate: Digest realm="api.example.com", qop="auth", \
   algorithm=SHA-256, nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", \
   opaque="5ccc069c403ebaf9f0171e9517f40e41"

   would indicate that the server supports digest access authentication.

   Details of HTTP authentication are described in [RFC9110] but it is
   worth noting that a server supporting multiple authentication methods
   can return either multiple www-authenticate header fields in its
   response or a single www-authenticate header field with multiple
   authentication methods.

5.4.3.  Other Protocols Authentication Mechanisms

   For text-based protocols (IMAP, POP3, and SMTP) the user agent SHOULD
   connect to the server to check that:

   *  the user agent can reach the server,




Eggert, et al.           Expires 31 August 2026                [Page 20]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


   *  the server implements the expected protocol, and

   *  which authentication mechanisms the server supports.

   The user agent MUST attempt to connect to the server on the default
   ports:

   *  port 993 for IMAP

   *  port 995 for POP3

   *  port 465 for SMTP

   using TLS.  See [RFC2595] and [RFC3207] for details about using TLS
   with these protocols.

   The user agent SHOULD NOT attempt to connect to an IMAP, POP3, or
   SMTP server on their cleartext ports.

   The user agent MUST NOT allow for configuration with a cleartext
   protocol that is not protected by TLS.

   The user agent MUST validate that the connection is secured by TLS,
   and that the server certificate is valid and matches the expected
   domain name.  See Section 7.4 for details on transport security
   validation.

   If the server announces the OAUTHBEARER SASL authentication method,
   the user agent can assume that this server supports using
   [OAuthPublic].  For IMAP for example, if the server's CAPABILITY
   contains AUTH=OAUTHBEARER this would indicate this support.

   Servers SHOULD NOT announce support for the OAUTHBEARER SASL
   mechanism if they do not support [OAuthPublic].  Servers MUST
   announce support for the OAUTHBEARER SASL mechanism if they support
   OAuth Profile for Open Public Clients.  Servers SHOULD NOT use the
   XOAUTH2 SASL mechanism.

   There are various SASL authentication mechanisms for password-based
   authentication, and additionally IMAP and POP3 also support password-
   based authentication through LOGIN and APOP respectively.  The user
   agent needs to probe each server to determine which authentication
   methods are supported by both the user agent and the server.








Eggert, et al.           Expires 31 August 2026                [Page 21]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


5.4.3.1.  IMAP

   The IMAP protocol provides various other authentication mechanisms.
   There are various SASL mechanisms for username + password
   authentication.  [RFC4959] describes how to use SASL with IMAP.

   Unless the server sends the LOGINDISABLED capability, clients know
   that they can use the LOGIN command for username + password
   authentication.

   For IMAP, a sample session might look like this:

   ========== NOTE: '\' line wrapping per RFC 8792 ===========

   S: * OK [CAPABILITY IMAP4 IMAP4rev1 SASL-IR AUTH=PLAIN \
   AUTH=OAUTHBEARER] IMAP Server
   C: A1 LOGOUT
   S: * BYE
   S: A1 OK

   In this case the server returned its IMAP capabilities as part of the
   so-called greeting messages.  The support for the OAUTHBEARER SASL
   authentication mechanism indicates to the client that the server
   supports OAuth.  Similarly the PLAIN SASL authentication mechanism
   indicates that the server supports username + password
   authentication.  The absence of the LOGINDISABLED also indicates
   support for username and password authentication.

   If the server doesn't include its capabilities in the server
   greeting, the client SHOULD send a CAPABILITY command as outlined in
   Section 6.1.1 of [RFC9051].  The client SHOULD send a LOGOUT command
   as outlined in Section 6.1.3 of [RFC9051] and check that the server
   sends an untagged BYE response.

5.4.3.2.  SMTP

   SMTP similarly announces which authentication mechanisms is supports.
   [RFC4954] describes how to use SASL with SMTP.

   For SMTP, the client would use the EHLO command to retrieve the SMTP
   server's supported authentication mechanisms.  For example:










Eggert, et al.           Expires 31 August 2026                [Page 22]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


   S: 220 smtp.example.com ESMTP service ready
   C: EHLO client.example.com
   S: 250-smtp.example.com
   S: 250-PIPELINING
   S: 250-SIZE 10240000
   S: 250-AUTH PLAIN LOGIN OAUTHBEARER
   S: 250-ENHANCEDSTATUSCODES
   S: 250 8BITMIME
   C: QUIT
   S: 221 Bye

   Section 3.2 of [RFC5321] describe this client initiation of the SMTP
   protocol.  [RFC4954] describes SMTP authentication in detail.  In the
   above example PLAIN and LOGIN indicate that the server supports
   username + password based authentication, and OAUTHBEARER indicates
   that the server supports OAuth.

   The client SHOULD send a QUIT command and check for the server's 221
   Bye response.

5.4.3.3.  POP3

   For POP3 [RFC5034] describes how to use SASL.  POP3 additionally
   supports password based authentication using its USER and PASS
   commands, or through the optional APOP command.  The client can check
   which SASL authentication methods the server supports using the CAPA
   command.

   For example:

   S: +OK pop.example.com POP3 server ready
   C: CAPA
   S: +OK List of capabilities follows
   S: SASL PLAIN OAUTHBEARER
   S: IMPLEMENTATION BlurdyBlurp POP3 server
   S: .
   C: QUIT
   S: +OK POP3 server signing off (maildrop empty)

   The client SHOULD send a QUIT command and check for the server's +OK
   response.

5.5.  Confirming Server Names

   The client SHOULD display to the user the hostnames of all servers
   that it intends to authenticate with.  This list of server hostnames
   gives the user a chance to validate if they want to move ahead.




Eggert, et al.           Expires 31 August 2026                [Page 23]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


   The client MAY choose to limit the hostnames to their second-level
   domain names when displaying this list.  Instead of displaying
   mail.example.com the client would display example.com if it chooses
   to do so.  Limiting the hostnames to their second-level domain names
   helps users identify if this is the domain they intend to connect to
   or not.

   The client MUST NOT cut off parts of long second-level domains, to
   avoid spoofing.  At least 63 characters of the second-level domain
   names MUST be displayed.

   If the user mistyped their email address in Section 5.1, letting the
   user confirm the server hostnames gives the user a chance to notice
   this.

   Clients can enhance the user experience by using the info section of
   the configuration (described in Section 4.4) to display the
   provider's name and logo during this configuration step.

   Section 7.1 list security considerations related to the user
   confirming these hostnames.

5.6.  Username

   For password-based authentication, the full addr-spec part of the
   email address MUST be used as the username.  For example:

             +============================+==================+
             | Text Entered by User       | username         |
             +============================+==================+
             | jdoe@example.com           | jdoe@example.com |
             +----------------------------+------------------+
             | "J Doe" <jdoe@example.com> | jdoe@example.com |
             +----------------------------+------------------+
             | <jdoe@example.com>         | jdoe@example.com |
             +----------------------------+------------------+

                    Table 3: Username from email address

   For OAuth Profile for Open Public Clients, the client MUST send this
   username as the login_hint in the authorization request URL.

   The provider MUST ensure that any valid email address that the user
   might enter during setup is a valid username for all servers given in
   this configuration.  This will require a mapping on the server level
   from email address to internal username.  This mapping happens
   internally in the server and the client is not involved in this
   mapping.



Eggert, et al.           Expires 31 August 2026                [Page 24]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


5.7.  Configuring OAuth

   If the client and the provider both support OAuth Profile for Open
   Public Clients, and if the servers that the client wants to use
   support OAuth, the client can configure OAuth.

   The authentication section in the JSON configuration described in
   Section 4.3 will let the client create a URL to retrieve the OAuth
   Authorization Server Metadata as described in section Section 5.4.1.
   With this metadata, the client can then use [OAuthPublic] to
   configure OAuth.

   Part of this will require opening the authorization request URL in an
   external user-agent, which is typically the default browser.  The
   client SHOULD make it very apparent to the user which hostname is
   being used for the authorization request URL.  The client SHOULD make
   the user confirm least the second-level domain name(s) of the
   hostname of this URL.  This is to minimize the risk of the user
   exposing their credentials to a third party.

   As described in Section 5.5, the client SHOULD also confirm the
   server hostnames with the user.  For OAuth authentication, the client
   SHOULD include the hostname of the authorization request URL in this
   list of hostnames.

5.8.  Configuring Password-Based Authentication

   If the client and provider both support password-based
   authentication, and if the servers that the client wants to use
   support password-based authentication, the client can configure
   itself to use these servers.

   The client SHOULD at this point ask the user for the password for
   their account with the provider.

   Once the user has entered their password, the client SHOULD validate
   that it is able to authenticate using the entered password with all
   servers that it is interested in.  Only then would it save the new
   configuration.

6.  Configuration Validation

6.1.  User Approval

   Regardless of the mechanism used to obtain the configuration, clients
   SHOULD display the configuration details to users and request
   explicit confirmation before use.  During this confirmation process:




Eggert, et al.           Expires 31 August 2026                [Page 25]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


   *  At least the second-level domain names of all involved hostnames
      MUST be displayed clearly and prominently.

   *  Clients MUST NOT truncate long second-level domain names to
      prevent spoofing attacks.  At least 63 characters MUST be
      displayed.

6.2.  OAuth2 requirements

   If OAuth2 is used, the OAuth2 server MUST adhere to [OAuthPublic].

   Notably, the Dynamic Client Registration MUST be implemented and
   return a working Client ID in response HTTP calls defined by the
   specification.

   The OAuth2 scopes defined in [OAuthPublic] MUST be included and MUST
   give access to the servers returned in the JSON configuration
   described in Section 4.

   A single token MUST work for all servers in the JSON configuration,
   such that a single user login is sufficient for all services.  For
   that purpose, the client will include all relevant scopes in the
   authentication requests.

7.  Security Considerations

   While the mechanism described in this document makes it easier for
   users to correctly configure their user agent, there's an associated
   risk with making it easier for users to expose their credentials to a
   third party.

   User agents using the mechanism described in this document need to
   design their user interface and user experience such that this risk
   is minimized.  Actual affordances depend on implementation details of
   the user interface and are outside the scope of this document.

7.1.  Mistyped Domain Names

   As part of the first step of the mechanism described in this
   document, the user enters their email address.  If the user mistyped
   the domain part of their email address, and if the mistyped domain
   exists and supports the mechanism described in this document, the
   user could expose their credentials to the owner of that domain.  An
   attacker could use this in an attempt to gain knowledge of the user's
   credentials.






Eggert, et al.           Expires 31 August 2026                [Page 26]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


   As a result, user agents need to carefully design their user
   interface and user experience as to let the user know which domain is
   being used.  It would make sense to display this very clearly to the
   user, before they enter any credentials.

   The user agent would want to display a list of all second-level
   domains (SLDs) for all the servers that it intends to use.  The user
   can then confirm these.

   When the mechanism described in this document uses OAuth, it would
   make sense to ask the user to confirm the domains of the servers that
   will be used and additionally confirm the domains of

   *  the URL to retrieve the OAuth Authorization Server Metadata and/or

   *  the authorization request URL.

   When asking the user to confirm these domains, it would make sense to
   only display the second-level domain (SLD) of those domains.  This
   would make it more difficult for an attacker to do URL obfuscation
   and use subdomain phishing.

   When using a browser for OAuth, the user agent would want to display
   the second-level domain (SLD) that the browser is currently
   displaying, and update this when redirects happen or new pages are
   loaded.

7.2.  Attacker Controlled JSON Configuration

   If an attacker can direct the user agent to use an attacker-
   controlled JSON configuration, the attacker would be able to direct
   the user to servers of the attacker's choosing.

   In Section 7.1 some mechanisms to limit this attack vector are
   described.

   However, the user agent needs to combine this with a conservative
   trust policy for its TLS when retrieving the JSON configuration.

7.3.  DNS

   If the user agent uses the DNS mechanisms described in Section 5.2.2,
   care needs to be taken to make sure that an attacker hasn't altered
   the DNS response.  Using DNSSEC is one method of improving the
   security aspects of this approach.  Alternatively, user agents MAY
   choose not use the DNS based mechanisms described in Section 5.2.2 at
   all.




Eggert, et al.           Expires 31 August 2026                [Page 27]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


7.4.  Transport Security Validation

   Whenever secure transport is used (including TLS for HTTPS
   connections and QUIC's TLS-based security layer for HTTP/3), user
   agents MUST check the certificates presented by the server.  This
   certificate MUST be within its validity period (prior to its
   expiration date) and MUST chain to a root CA that is trusted by the
   user agent.  The certificate MUST have a subject alternative name
   (SAN) ([RFC5280]) with a DNS-ID ([RFC9525]) matching the hostname,
   per the rules given in [RFC9525].  The certificate MAY also be
   checked for revocation via OCSP ([RFC6960]), CRLs ([RFC6818]), or
   some other mechanism.  The general TLS usage guidance in [RFC9525]
   SHOULD be followed.

   If these checks fail or the server certificate is otherwise invalid,
   the user agent MUST disconnect and MUST NOT use any configuration
   retrieved from that URI.

   Certificate validation failures represent significant security risks,
   as they may indicate attempts to redirect users' credentials to an
   attacker.  User agents SHOULD NOT allow users to override certificate
   validation checks.

   User agents MAY implement more restrictive transport security
   policies for configuration retrieval than those typically required
   for web browsing, in order to provide stronger security guarantees.
   For TLS connections, user agents MAY want to limit the allowed
   protocol version(s) to recent versions, and MAY similarly want to
   restrict the allowed cipher suites.  For QUIC connections, user
   agents MAY apply similar restrictions to the underlying TLS handshake
   parameters.

   The HTTP server serving the Well-Known resource described in
   Section 5.2.1 MUST have support for TLS 1.3 ([RFC8446]) or higher.

7.5.  Updating the Configuration

   The mechanism described in this document can be used to upgrade a
   user's configuration.  The user agent could check for configurations
   even when it has a working configuration for an account.  If the user
   agent finds a configuration that is better (in some way) than the
   already existing configuration, it could then upgrade the existing
   configuration.








Eggert, et al.           Expires 31 August 2026                [Page 28]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


   But in doing so, the user agent would increase the attack window that
   a potential attacker has.  Instead of only giving an attacker the
   opportunity when the user configures their user agent for the first
   time, the attacker would now have an opportunity each time the user
   agent checks for a better configuration.  That could be undesirable.

7.6.  Provider Information

   Image parsers are a common attack vector, and clients MUST NOT
   display the logo images described in Section 4.4.1 unless they can do
   so in a way that doesn't expose the client to such attacks.

8.  IANA Considerations

8.1.  The User-Agent Auto-Configuration Protocol Registry

   This document establishes the user-agent auto-configuration protocol
   registry.

   User-agent auto-configuration protocols are registered on the advice
   of one or more Designated Experts (appointed by the IESG or their
   delegate), with a Specification Required (using terminology from
   [RFC8126]).  However, to allow for the allocation of values prior to
   publication, the Designated Expert(s) may approve registration once
   they are satisfied that such a specification will be published.

   Registration requests are sent to the ____@ietf.org mailing list for
   review and comment, with an appropriate subject (e.g., "Request for
   well-known URI: example").

   Before a period of 14 days has passed, the Designated Expert(s) will
   either approve or deny the registration request, communicating this
   decision both to the review list and to IANA.  Denials should include
   an explanation and, if applicable, suggestions as to how to make the
   request successful.  Registration requests that are undetermined for
   a period longer than 21 days can be brought to the IESG's attention
   (using the iesg@iesg.org mailing list) for resolution.

   Registry Name:
      User-Agent Auto-Configuration Protocols

   Registration Procedure:
      Specification Required (per [RFC8126])

8.1.1.  Registration Template

   Name
      The commonly used name of the protocol



Eggert, et al.           Expires 31 August 2026                [Page 29]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


   Protocol Key:
      The JSON key using in the protocols object in the JSON
      configuration described in Section 4

   URL Scheme:
      (Optional) The URL scheme to be used for this protocol.  HTTP
      based protocols specify https.  If left empty, the protocols entry
      in the JSON configuration will only specify a hostname using host.
      If a URL scheme is specified, the JSON configuration entry will
      instead use url with a URL using this URL scheme.

   Specification
      Which RFC(s) or document(s) specify the protocol

   Additional Properties:
      Which additional property values are present in the protocol's
      JSON object.

8.1.2.  Initial Registrations

   +=============+=============+========+================+============+
   | Name        | Protocol    | URL    | Specification  | Additional |
   |             | Key         | scheme |                | Properties |
   +=============+=============+========+================+============+
   | JMAP        | jmap        | https  | RFC 8620, RFC  |            |
   |             |             |        | 8621, RFC      |            |
   |             |             |        | 8887, RFC 9610 |            |
   +-------------+-------------+--------+----------------+------------+
   | IMAP        | imap        |        | RFC 9051       |            |
   +-------------+-------------+--------+----------------+------------+
   | POP3        | pop3        |        | RFC 1939, RFC  |            |
   |             |             |        | 5034           |            |
   +-------------+-------------+--------+----------------+------------+
   | SMTP        | smtp        |        | RFC 5321, RFC  |            |
   |             |             |        | 2822           |            |
   +-------------+-------------+--------+----------------+------------+
   | CalDAV      | caldav      | https  | RFC 4791       |            |
   +-------------+-------------+--------+----------------+------------+
   | CardDAV     | carddav     | https  | RFC 6352       |            |
   +-------------+-------------+--------+----------------+------------+
   | WebDAV      | webdav      | https  | RFC 4918       |            |
   +-------------+-------------+--------+----------------+------------+
   | ManageSieve | managesieve |        | RFC 5804, RFC  |            |
   |             |             |        | 5228           |            |
   +-------------+-------------+--------+----------------+------------+

          Table 4: Initial registrations to the User-Agent Auto-
                     Configuration Protocol Registry



Eggert, et al.           Expires 31 August 2026                [Page 30]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


   The _Additional Properties_ field is empty in all of the initial
   values.

8.2.  Registration

8.2.1.  Registration of Well-Known URI user-agent-configuration

   This registers the user-agent-configuration name from Section 5.2.1
   in the "Well-Known URIs" registry as specified in [RFC8615].

    +==========================+==========+===============+===========+
    | URI suffix               |Change    | Specification |Related    |
    |                          |controller| document(s)   |information|
    +==========================+==========+===============+===========+
    | user-agent-configuration |IETF      | This document |/          |
    +--------------------------+----------+---------------+-----------+

             Table 5: Registration in Well-Known URIs Registry

8.2.2.  Registration of DNS Underscore Label _ua-auto-config

   This registers the DNS underscore label _ua-auto-config used in
   Section 5.2.2 in the "Underscored and Globally Scoped DNS Node Names"
   registry as specified in [RFC8552].

               +=========+=================+===============+
               | RR Type | _NODE NAME      | Reference     |
               +=========+=================+===============+
               | TXT     | _ua-auto-config | This document |
               +---------+-----------------+---------------+

                  Table 6: Registration in Underscored and
                  Globally Scoped DNS Node Names Registry

9.  Normative References

   [RFC1939]  Myers, J. and M. Rose, "Post Office Protocol - Version 3",
              STD 53, RFC 1939, DOI 10.17487/RFC1939, May 1996,
              <https://www.rfc-editor.org/info/rfc1939>.

   [RFC2045]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
              Extensions (MIME) Part One: Format of Internet Message
              Bodies", RFC 2045, DOI 10.17487/RFC2045, November 1996,
              <https://www.rfc-editor.org/info/rfc2045>.







Eggert, et al.           Expires 31 August 2026                [Page 31]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2595]  Newman, C., "Using TLS with IMAP, POP3 and ACAP",
              RFC 2595, DOI 10.17487/RFC2595, June 1999,
              <https://www.rfc-editor.org/info/rfc2595>.

   [RFC3207]  Hoffman, P., "SMTP Service Extension for Secure SMTP over
              Transport Layer Security", RFC 3207, DOI 10.17487/RFC3207,
              February 2002, <https://www.rfc-editor.org/info/rfc3207>.

   [RFC4648]  Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
              <https://www.rfc-editor.org/info/rfc4648>.

   [RFC4791]  Daboo, C., Desruisseaux, B., and L. Dusseault,
              "Calendaring Extensions to WebDAV (CalDAV)", RFC 4791,
              DOI 10.17487/RFC4791, March 2007,
              <https://www.rfc-editor.org/info/rfc4791>.

   [RFC4918]  Dusseault, L., Ed., "HTTP Extensions for Web Distributed
              Authoring and Versioning (WebDAV)", RFC 4918,
              DOI 10.17487/RFC4918, June 2007,
              <https://www.rfc-editor.org/info/rfc4918>.

   [RFC4954]  Siemborski, R., Ed. and A. Melnikov, Ed., "SMTP Service
              Extension for Authentication", RFC 4954,
              DOI 10.17487/RFC4954, July 2007,
              <https://www.rfc-editor.org/info/rfc4954>.

   [RFC4959]  Siemborski, R. and A. Gulbrandsen, "IMAP Extension for
              Simple Authentication and Security Layer (SASL) Initial
              Client Response", RFC 4959, DOI 10.17487/RFC4959,
              September 2007, <https://www.rfc-editor.org/info/rfc4959>.

   [RFC5034]  Siemborski, R. and A. Menon-Sen, "The Post Office Protocol
              (POP3) Simple Authentication and Security Layer (SASL)
              Authentication Mechanism", RFC 5034, DOI 10.17487/RFC5034,
              July 2007, <https://www.rfc-editor.org/info/rfc5034>.

   [RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", STD 68, RFC 5234,
              DOI 10.17487/RFC5234, January 2008,
              <https://www.rfc-editor.org/info/rfc5234>.





Eggert, et al.           Expires 31 August 2026                [Page 32]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


   [RFC5280]  Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
              Housley, R., and W. Polk, "Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
              <https://www.rfc-editor.org/info/rfc5280>.

   [RFC5321]  Klensin, J., "Simple Mail Transfer Protocol", RFC 5321,
              DOI 10.17487/RFC5321, October 2008,
              <https://www.rfc-editor.org/info/rfc5321>.

   [RFC5322]  Resnick, P., Ed., "Internet Message Format", RFC 5322,
              DOI 10.17487/RFC5322, October 2008,
              <https://www.rfc-editor.org/info/rfc5322>.

   [RFC5804]  Melnikov, A., Ed. and T. Martin, "A Protocol for Remotely
              Managing Sieve Scripts", RFC 5804, DOI 10.17487/RFC5804,
              July 2010, <https://www.rfc-editor.org/info/rfc5804>.

   [RFC5890]  Klensin, J., "Internationalized Domain Names for
              Applications (IDNA): Definitions and Document Framework",
              RFC 5890, DOI 10.17487/RFC5890, August 2010,
              <https://www.rfc-editor.org/info/rfc5890>.

   [RFC5891]  Klensin, J., "Internationalized Domain Names in
              Applications (IDNA): Protocol", RFC 5891,
              DOI 10.17487/RFC5891, August 2010,
              <https://www.rfc-editor.org/info/rfc5891>.

   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
              DOI 10.17487/RFC6234, May 2011,
              <https://www.rfc-editor.org/info/rfc6234>.

   [RFC6352]  Daboo, C., "CardDAV: vCard Extensions to Web Distributed
              Authoring and Versioning (WebDAV)", RFC 6352,
              DOI 10.17487/RFC6352, August 2011,
              <https://www.rfc-editor.org/info/rfc6352>.

   [RFC6749]  Hardt, D., Ed., "The OAuth 2.0 Authorization Framework",
              RFC 6749, DOI 10.17487/RFC6749, October 2012,
              <https://www.rfc-editor.org/info/rfc6749>.

   [RFC6750]  Jones, M. and D. Hardt, "The OAuth 2.0 Authorization
              Framework: Bearer Token Usage", RFC 6750,
              DOI 10.17487/RFC6750, October 2012,
              <https://www.rfc-editor.org/info/rfc6750>.





Eggert, et al.           Expires 31 August 2026                [Page 33]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


   [RFC6818]  Yee, P., "Updates to the Internet X.509 Public Key
              Infrastructure Certificate and Certificate Revocation List
              (CRL) Profile", RFC 6818, DOI 10.17487/RFC6818, January
              2013, <https://www.rfc-editor.org/info/rfc6818>.

   [RFC6960]  Santesson, S., Myers, M., Ankney, R., Malpani, A.,
              Galperin, S., and C. Adams, "X.509 Internet Public Key
              Infrastructure Online Certificate Status Protocol - OCSP",
              RFC 6960, DOI 10.17487/RFC6960, June 2013,
              <https://www.rfc-editor.org/info/rfc6960>.

   [RFC7616]  Shekh-Yusef, R., Ed., Ahrens, D., and S. Bremer, "HTTP
              Digest Access Authentication", RFC 7616,
              DOI 10.17487/RFC7616, September 2015,
              <https://www.rfc-editor.org/info/rfc7616>.

   [RFC8126]  Cotton, M., Leiba, B., and T. Narten, "Guidelines for
              Writing an IANA Considerations Section in RFCs", BCP 26,
              RFC 8126, DOI 10.17487/RFC8126, June 2017,
              <https://www.rfc-editor.org/info/rfc8126>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC8414]  Jones, M., Sakimura, N., and J. Bradley, "OAuth 2.0
              Authorization Server Metadata", RFC 8414,
              DOI 10.17487/RFC8414, June 2018,
              <https://www.rfc-editor.org/info/rfc8414>.

   [RFC8446]  Rescorla, E., "The Transport Layer Security (TLS) Protocol
              Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
              <https://www.rfc-editor.org/info/rfc8446>.

   [RFC8552]  Crocker, D., "Scoped Interpretation of DNS Resource
              Records through "Underscored" Naming of Attribute Leaves",
              BCP 222, RFC 8552, DOI 10.17487/RFC8552, March 2019,
              <https://www.rfc-editor.org/info/rfc8552>.

   [RFC8615]  Nottingham, M., "Well-Known Uniform Resource Identifiers
              (URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
              <https://www.rfc-editor.org/info/rfc8615>.

   [RFC8620]  Jenkins, N. and C. Newman, "The JSON Meta Application
              Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, July
              2019, <https://www.rfc-editor.org/info/rfc8620>.





Eggert, et al.           Expires 31 August 2026                [Page 34]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


   [RFC9051]  Melnikov, A., Ed. and B. Leiba, Ed., "Internet Message
              Access Protocol (IMAP) - Version 4rev2", RFC 9051,
              DOI 10.17487/RFC9051, August 2021,
              <https://www.rfc-editor.org/info/rfc9051>.

   [RFC9110]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP Semantics", STD 97, RFC 9110,
              DOI 10.17487/RFC9110, June 2022,
              <https://www.rfc-editor.org/info/rfc9110>.

   [RFC9112]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
              Ed., "HTTP/1.1", STD 99, RFC 9112, DOI 10.17487/RFC9112,
              June 2022, <https://www.rfc-editor.org/info/rfc9112>.

   [RFC9525]  Saint-Andre, P. and R. Salz, "Service Identity in TLS",
              RFC 9525, DOI 10.17487/RFC9525, November 2023,
              <https://www.rfc-editor.org/info/rfc9525>.

   [I-D.svg-tiny-ps-abrotman]
              Brotman, A. and J. T. Adams, "SVG Tiny Portable/Secure",
              Work in Progress, Internet-Draft, draft-svg-tiny-ps-
              abrotman-11, 3 November 2025,
              <https://datatracker.ietf.org/doc/html/draft-svg-tiny-ps-
              abrotman-11>.

   [OAuthPublic]
              Jenkins, N. and B. Bucksch, "OAuth Profile for Open Public
              Clients", Work in Progress, Internet-Draft, draft-ietf-
              mailmaint-oauth-public,
              <https://datatracker.ietf.org/doc/html/draft-ietf-
              mailmaint-oauth-public>.

Appendix A.  Configuration JSON Schema

   The following JSON schema defines the format of the JSON
   configuration in Section 4

   ========== NOTE: '\' line wrapping per RFC 8792 ===========

   {
       "$schema": "https://json-schema.org/draft/2020-12/schema",
       "$id": "ua-auto-conf",
       "title": "User-Agent Automatic Configuration",
       "description": "Automatic Configuration of Email, Calendar, \
           and Contact Server Settings",
       "type": "object",
       "properties": {
           "protocols": {



Eggert, et al.           Expires 31 August 2026                [Page 35]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


               "type": "object",
               "properties": {
                   "caldav": { "$ref": "#/$defs/http-server" },
                   "carddav": { "$ref": "#/$defs/http-server" },
                   "imap": { "$ref": "#/$defs/text-server" },
                   "jmap": { "$ref": "#/$defs/http-server" },
                   "managesieve": { "$ref": "#/$defs/text-server" },
                   "pop3": { "$ref": "#/$defs/text-server" },
                   "smtp": { "$ref": "#/$defs/text-server" },
                   "webdav": { "$ref": "#/$defs/http-server" }
               }
           },
           "authentication": {
               "properties": {
                   "oauth-public": {
                       "properties": {
                           "issuer": {
                               "format": "uri",
                               "type": "string"
                           }
                       },
                       "required": [
                           "issuer"
                       ],
                       "type": "object"
                   },
                   "password": {
                       "type": "boolean"
                   }
               },
               "required": [ "password" ]
           },
           "info": {
               "type": "object",
               "properties": {
                   "provider": {
                       "type": "object",
                       "properties": {
                           "name": { "type": "string", "minLength": 1 },
                           "shortName": { "type": "string", \
                               "minLength": 1 },
                           "logo": {
                               "type": "array",
                               "items": {
                                   "type": "object",
                                   "properties": {
                                       "url": { "type": "string", \
                                           "format": "uri" },



Eggert, et al.           Expires 31 August 2026                [Page 36]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


                                       "content-type": { \
                                           "type": "string", \
                                           "minLength": 1 },
                                       "width": { "type": "integer", \
                                           "minimum": 1 },
                                       "height": { "type": "integer", \
                                           "minimum": 1 }
                                   },
                                   "required": [ "url", "content-type" ]
                               }
                           }
                       },
                       "required": [ "name" ]
                   },
                   "help": {
                       "type": "object",
                       "properties": {
                           "documentation": { "type": "string", \
                               "format": "uri" },
                           "developer": { "type": "string", \
                               "format": "uri" },
                           "contact": {
                               "type": "array",
                               "items": { "type": "string", \
                                   "minLength": 1 }
                           }
                       }
                   }
               },
               "required": [ "provider" ]
           }
       },
       "required": [ "protocols", "info" ],
       "$defs": {
           "http-server": {
               "type": "object",
               "properties": {
                   "url": { "type": "string", "format": "uri" }
               },
               "required": ["url"]
           },
           "text-server": {
               "type": "object",
               "properties": {
                   "host": { "type": "string", "format": "hostname" }
               },
               "required": ["host"]
           }



Eggert, et al.           Expires 31 August 2026                [Page 37]

Internet-Draft    Auto-Config of Email Server Settings     February 2026


       }
   }

Acknowledgements

   This document is based on the work of Ben Bucksch.

Authors' Addresses

   Daniel Eggert
   Apple Inc
   One Apple Park Way
   Cupertino,  CA 95014
   United States of America
   Email: deggert@apple.com
   URI:   https://www.apple.com


   Ben Bucksch
   Beonex
   Email: ben.bucksch@beonex.com


   Matt Diephouse
   Apple Inc
   One Apple Park Way
   Cupertino,  CA 95014
   United States of America
   Email: diephouse@apple.com
   URI:   https://www.apple.com





















Eggert, et al.           Expires 31 August 2026                [Page 38]


