# drafts

name: draft-rosenberg-aiproto-nact
rev: 00
title: Normalized API for AI Agents Calling Tools (N-ACT)
time: 2025-10-20T01:59:42Z
group: none
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: []
tags: []
fetched_at: 2026-03-04T00:00:05.287446+00:00
source: ietf
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: none
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: []
tags: []
fetched_at: 2026-03-04T00:00:05.293461+00:00
source: ietf
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: none
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: []
tags: []
fetched_at: 2026-03-04T00:00:05.298160+00:00
source: ietf
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: none
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: []
tags: []
fetched_at: 2026-03-04T00:00:05.301503+00:00
source: ietf
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: none
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: []
tags: []
fetched_at: 2026-03-04T00:00:05.305116+00:00
source: ietf
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: mailmaint
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: []
tags: []
fetched_at: 2026-03-04T00:00:05.309188+00:00
source: ietf
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]


name: draft-a2a-moqt-transport
rev: 00
title: Media over QUIC Transport (MOQT) for Agent-to-Agent Protocol
time: 2025-10-20T19:44:25Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T19:44:25Z
states: ["/api/v1/doc/state/4/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:05.313605+00:00
source: ietf
abstract:
  This document specifies how the Agent-to-Agent (A2A) protocol can be
     transported over Media over QUIC Transport (MOQT).  MOQT provides a
     publish/subscribe model over QUIC that enables efficient real-time
     communication between AI agents, supporting the A2A protocol's
     requirements for discovery, negotiation, and collaboration while
     leveraging MOQT's streaming capabilities and built-in prioritization
     mechanisms.

full_text:
  Media Over QUIC                                            S. Nandakumar
  Internet-Draft                                                     Cisco
  Intended status: Standards Track                             C. Jennings
  Expires: 20 April 2026                                     Cisco Systems
                                                           17 October 2025


        Media over QUIC Transport (MOQT) for Agent-to-Agent Protocol
                        draft-a2a-moqt-transport-00

  Abstract

     This document specifies how the Agent-to-Agent (A2A) protocol can be
     transported over Media over QUIC Transport (MOQT).  MOQT provides a
     publish/subscribe model over QUIC that enables efficient real-time
     communication between AI agents, supporting the A2A protocol's
     requirements for discovery, negotiation, and collaboration while
     leveraging MOQT's streaming capabilities and built-in prioritization
     mechanisms.

  About This Document

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

     The latest revision of this draft can be found at https://ietf-wg-
     moq.github.io/draft-a2a-moqt-transport/draft-a2a-moqt-transport.html.
     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-a2a-moqt-transport/.

     Discussion of this document takes place on the Media Over QUIC
     Working Group mailing list (mailto:moq@ietf.org), which is archived
     at https://mailarchive.ietf.org/arch/browse/moq/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/moq/.

     Source for this draft and an issue tracker can be found at
     https://github.com/ietf-wg-moq/draft-a2a-moqt-transport.

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





  Nandakumar & Jennings     Expires 20 April 2026                 [Page 1]


  Internet-Draft                A2A over MOQT                 October 2025


     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 20 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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.  A2A Transport Requirements  . . . . . . . . . . . . . . . . .   3
     3.  MOQT Transport Mapping  . . . . . . . . . . . . . . . . . . .   4
       3.1.  Connection Establishment  . . . . . . . . . . . . . . . .   4
       3.2.  Track Organization  . . . . . . . . . . . . . . . . . . .   5
       3.3.  Message Serialization . . . . . . . . . . . . . . . . . .   5
       3.4.  Priority and Quality of Service . . . . . . . . . . . . .   6
     4.  Protocol Operations . . . . . . . . . . . . . . . . . . . . .   6
       4.1.  Agent Discovery . . . . . . . . . . . . . . . . . . . . .   6
       4.2.  Request/Response Patterns . . . . . . . . . . . . . . . .   7
       4.3.  Streaming Operations  . . . . . . . . . . . . . . . . . .   8
     5.  Benefits of MOQT for A2A  . . . . . . . . . . . . . . . . . .   9
       5.1.  Real-time Communication Benefits  . . . . . . . . . . . .   9
       5.2.  Scalability Benefits  . . . . . . . . . . . . . . . . . .  10
       5.3.  Reliability and Resilience  . . . . . . . . . . . . . . .  10
     6.  MOQT Relay Infrastructure for A2A . . . . . . . . . . . . . .  10
       6.1.  Relay Network Architecture  . . . . . . . . . . . . . . .  10
       6.2.  Message Caching Benefits  . . . . . . . . . . . . . . . .  11
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
       7.2.  Informative References  . . . . . . . . . . . . . . . . .  12
     Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  12
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12




  Nandakumar & Jennings     Expires 20 April 2026                 [Page 2]


  Internet-Draft                A2A over MOQT                 October 2025


  1.  Introduction

     The Agent-to-Agent (A2A) protocol enables communication between AI
     agents across different platforms and frameworks.  Currently, A2A
     supports three transport protocols: JSON-RPC 2.0 over HTTP(S), gRPC,
     and HTTP+JSON/REST.  This document defines a fourth transport option
     using Media over QUIC Transport (MOQT) to provide enhanced real-time
     streaming capabilities for agent interactions.

     MOQT is designed for media streaming over QUIC and WebTransport,
     providing a publish/subscribe model with hierarchical data
     organization.  While originally intended for media applications,
     MOQT's streaming model and prioritization capabilities make it well-
     suited for real-time agent communication scenarios.

  1.1.  Requirements Language

     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.  A2A Transport Requirements

     According to the A2A specification, all transport protocols MUST
     provide functional equivalence and support the following
     capabilities:

     *  Secure communication over encrypted channels

     *  Request/response messaging patterns

     *  Streaming data delivery capabilities

     *  Error handling and status reporting

     *  Agent discovery and capability negotiation

     *  Support for various data types (text, JSON, files)











  Nandakumar & Jennings     Expires 20 April 2026                 [Page 3]


  Internet-Draft                A2A over MOQT                 October 2025


        A2A Protocol Layer
        ┌─────────────────────────────────────────────────────────────┐
        │  Agent Discovery │ Capability Exchange │ Task Collaboration │
        └─────────────────────────────────────────────────────────────┘
                                      │
        ┌─────────────────────────────────────────────────────────────┐
        │                    MOQT Transport Layer                     │
        │  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐  │
        │  │ PUB/SUB     │  │ Streaming   │  │ Priority/QoS        │  │
        │  │ Model       │  │ Support     │  │ Management          │  │
        │  └─────────────┘  └─────────────┘  └─────────────────────┘  │
        └─────────────────────────────────────────────────────────────┘
                                      │
        ┌─────────────────────────────────────────────────────────────┐
        │                    QUIC/WebTransport                        │
        │        ┌─────────────┐              ┌─────────────┐         │
        │        │ Encryption  │              │ Multiplexing│         │
        │        │ (TLS 1.3)   │              │ & Flow Ctrl │         │
        │        └─────────────┘              └─────────────┘         │
        └─────────────────────────────────────────────────────────────┘

  3.  MOQT Transport Mapping

  3.1.  Connection Establishment

     A2A agents using MOQT transport MUST establish a QUIC or WebTransport
     connection with the ALPN value "moq-00" as defined in the MOQT
     specification.  The connection setup follows this sequence:

     Agent A                                                   Agent B
        |                                                        |
        |──── QUIC Connection (ALPN: "moq-00") ────────────────▶ |
        |◄─── QUIC Connection Established ───────────────────────|
        |                                                        |
        |──── MOQT CLIENT_SETUP ────────────────────────────────▶|
        |◄─── MOQT SERVER_SETUP ─────────────────────────────────|
        |                                                        |
        |──── A2A Agent Registration ───────────────────────────▶|
        |◄─── A2A Capability Exchange ───────────────────────────|
        |                                                        |
        |◄═══ A2A Protocol Exchang ═════════════════════════════▶|

     During the MOQT setup phase, agents MUST negotiate the following A2A-
     specific extensions:

     *  a2a-version: Supported A2A protocol version

     *  a2a-capabilities: Agent capabilities and supported operations



  Nandakumar & Jennings     Expires 20 April 2026                 [Page 4]


  Internet-Draft                A2A over MOQT                 October 2025


     *  a2a-auth: Authentication and authorization tokens

  3.2.  Track Organization

     A2A protocol messages are mapped to MOQT tracks using a hierarchical
     namespace structure.  Each agent creates tracks for different message
     categories: Tracks are organized as follows:

     Request Tracks:  Used for A2A request messages, organized by category
        and action (e.g., discovery/capabilities, tasks/execute).

     Response Tracks:  Used for A2A response messages, organized by
        request ID for correlation.

     Stream Tracks:  Used for long-running streaming operations like task
        execution updates or file transfers.

     Notification Tracks:  Used for asynchronous notifications and events.

  3.3.  Message Serialization

     A2A protocol messages are serialized as JSON and encapsulated within
     MOQT objects.  Each MOQT object contains:

     MOQT Object Structure for A2A:

     ┌─────────────────────────────────────────────────────────┐
     │                 MOQT Object Header                      │
     │  Track ID │ Group ID │ Object ID │ Priority │ ....      │
     └─────────────────────────────────────────────────────────┘
     ┌─────────────────────────────────────────────────────────┐
     │                 A2A Message Payload                     │
     │  ┌─────────────────────────────────────────────────────┐│
     │  │              JSON A2A Message                       ││
     │  │  {                                                  ││
     │  │    "jsonrpc": "2.0",                                ││
     │  │    "method": "category/action",                     ││
     │  │    "params": { ... },                               ││
     │  │    "id": "request-id"                               ││
     │  │  }                                                  ││
     │  └─────────────────────────────────────────────────────┘│
     └─────────────────────────────────────────────────────────┘

     The A2A message format remains unchanged from the JSON-RPC 2.0
     specification, ensuring compatibility with existing A2A
     implementations.





  Nandakumar & Jennings     Expires 20 April 2026                 [Page 5]


  Internet-Draft                A2A over MOQT                 October 2025


  3.4.  Priority and Quality of Service

     MOQT's built-in priority system is mapped to A2A message urgency:

     Priority 1 (Highest):  Emergency and critical error responses

     Priority 2:  Real-time interaction responses and notifications

     Priority 3:  Standard request/response messages

     Priority 4:  Discovery and capability exchange messages

     Priority 5 (Lowest):  Background updates and non-critical
        notifications

  4.  Protocol Operations

  4.1.  Agent Discovery

     Agent discovery over MOQT uses a Subscribe Namespace pattern where
     agents subscribe to the <session_context_id>/discovery namespace
     prefix and publish their agent announcements using the
     <session_context_id>/discovery/agent-{id} pattern to reach all
     subscribers.

     Discovery Flow:

     Agent A                       MOQT Network                    Agent B
        |                              |                             |
        |─ SUBSCRIBE_NAMESPACE────────▶|                             |
        |  (<..>/discovery)            |◄─ SUBSCRIBE_NAMESPACE───────┤
        |                              |   (<..>/discovery)          |
        |                              |                             |
        |─ PUBLISH(/discovery/         |                             |
        |   agent-a) ─────────────────▶|─ PUBLISH(/discovery/        |
        |                              |agent-a) ───────────────────▶|
        |                              |                             |
        |                              |◄─ PUBLISH(/discovery/       |
        |                              |    agent-b) ────────────────┤
        |◄─ PUBLISH(/discovery/        |                             |
        |   agent-b) ──────────────────|                             |
        |                              |                             |
        |                              |                             |
        |◄── Object(Agent B caps) ─────|── Object(Agent A caps) ────▶|







  Nandakumar & Jennings     Expires 20 April 2026                 [Page 6]


  Internet-Draft                A2A over MOQT                 October 2025


  4.2.  Request/Response Patterns

     A2A request/response interactions are implemented using coordinated
     PUBLISH/SUBSCRIBE operations:

     1.  Server agent uses SUBSCRIBE_NAMESPACE to subscribe to
         <..>/server-agent-{id} Namespace prefix

     2.  Client agent sends PUBLISH message on <..>/server-
         agent-{id}/request track

     3.  Client agent subscribes to <..>/server-agent-{id}/response track

     4.  Client agent publishes OBJECT on <..>/server-agent-{id}/request
         track

     5.  Server agent receives OBJECT via its namespace subscription

     6.  Server agent publishes OBJECT on <..>/server-agent-{id}/response
         track

     7.  Client agent receives response OBJECT via its subscription





























  Nandakumar & Jennings     Expires 20 April 2026                 [Page 7]


  Internet-Draft                A2A over MOQT                 October 2025


     Request/Response Flow:

     Client Agent                MOQT                   Server Agent
          |                        |                        |
          |                        |◄(1) SUBSCRIBE_NAMESPACE|
          |                        | (<..>/server-agent-{id})
          |─(2) PUBLISH(           |                        |
          |  /server-agent-{id}/   |                        |
          |  request) ────────────▶|                        |
          |                        |─(2) PUBLISH(           |
          |                        |  /server-agent-{id}/   |
          |                        |  request) ────────────▶|
          |─(3) SUBSCRIBE(         |                        |
          |  /server-agent-{id}/   |                        |
          |  response) ───────────▶|                        |
          |                        |─(3) SUBSCRIBE(         |
          |                        |  /server-agent-{id}/   |
          |                        |  response) ───────────▶|
          |─(4) OBJECT(            |                        |
          |  /server-agent-{id}/   |                        |
          |  request) ────────────▶|───────────────────────▶|
          |                        |                        |
          |                        |◄(5) OBJECT(            |
          |                        |  /server-agent-{id}/   |
          |                        |  response) ────────────|
          |◄(6) OBJECT(            |◄───────────────────────|
          |  /server-agent-{id}/   |                        |
          |  response) ────────────|                        |
          |                        |                        |

  4.3.  Streaming Operations

     Long-running A2A operations like task execution or file transfer
     utilize MOQT's streaming capabilities.  Stream tracks carry
     incremental updates as separate MOQT objects.
















  Nandakumar & Jennings     Expires 20 April 2026                 [Page 8]


  Internet-Draft                A2A over MOQT                 October 2025


     Streaming Task Execution:

     Client                     MOQT Stream                  Server
       |                           |                           |
       |─ SUBSCRIBE(               |                           |
       |  /server-agent-{id}/      |                           |
       |  task_{id}) ─────────────▶|                           |
       |                           |─ SUBSCRIBE(               |
       |                           |  /server-agent-{id}/      |
       |                           |  task_{id}) ─────────────▶|
       |                           |◄─ OBJECT(                 |
       |                           |  /server-agent-{id}/      |
       |                           |  task_{id}, progress-1) ──|
       |◄─ Progress Update 1 ──────|                           |
       |                           |◄─ OBJECT(                 |
       |                           |  /server-agent-{id}/      |
       |                           |  task_{id}, progress-2) ──|
       |◄─ Progress Update 2 ──────|                           |
       |                           |◄─ OBJECT(                 |
       |                           |  /server-agent-{id}/      |
       |                           |  task_{id}, result) ──────|
       |◄─ Final Result ───────────|                           |
       |                           |◄─ OBJECT(                 |
       |                           |  /server-agent-{id}/      |
       |                           |  task_{id}, complete) ────|
       |◄─ Stream Complete ────────|                           |

  5.  Benefits of MOQT for A2A

     MOQT provides significant advantages over traditional A2A transports,
     particularly for real-time agent collaboration and large-scale
     deployments:

  5.1.  Real-time Communication Benefits

     *  Low-latency streaming enables immediate agent response to changing
        conditions

     *  Priority-based message delivery ensures critical communications
        are not delayed

     *  Streaming object delivery allows agents to act on incomplete data
        when appropriate

     *  Built-in flow control prevents agent overload during high-volume
        interactions





  Nandakumar & Jennings     Expires 20 April 2026                 [Page 9]


  Internet-Draft                A2A over MOQT                 October 2025


  5.2.  Scalability Benefits

     MOQT's publish/subscribe model creates powerful network effects for
     multi-agent environments:

     *  One-to-many broadcasts enable efficient agent coordination

     *  Subscription-based interest management reduces unnecessary traffic

     *  Dynamic agent discovery scales to thousands of participants

     *  Relay-based distribution prevents connection explosion in mesh
        networks

  5.3.  Reliability and Resilience

     MOQT provides enhanced reliability features critical for production
     agent deployments:

     *  Connection migration maintains agent sessions during network
        changes

     *  Automatic retry and recovery mechanisms handle transient failures

     *  Graceful degradation allows agents to continue operating with
        reduced capabilities

     *  Quality of Service controls prevent cascade failures in agent
        networks

  6.  MOQT Relay Infrastructure for A2A

     MOQT relays provide critical infrastructure benefits for large-scale
     A2A deployments, enabling efficient message distribution and caching.

  6.1.  Relay Network Architecture

     MOQT relays form a hierarchical distribution network that optimizes
     A2A message delivery across geographic and organizational boundaries:

     This hierarchical structure provides:

     *  Regional optimization with local agent clusters

     *  Global connectivity for cross-region agent collaboration

     *  Load distribution to prevent single points of failure




  Nandakumar & Jennings     Expires 20 April 2026                [Page 10]


  Internet-Draft                A2A over MOQT                 October 2025


     *  Configurable routing policies based on agent requirements

  6.2.  Message Caching Benefits

     MOQT relays can implement intelligent caching strategies optimized
     for A2A communication patterns.

     The most frequently accessed and time-sensitive data with time-to-
     live values are measured in seconds.  This includes real-time agent
     responses, live data streams, and status updates that require
     immediate availability.  These messages are kept in high-speed memory
     to ensure minimal latency for active agent interactions.

     Another layer can serve as an intermediate storage tier with time-to-
     live values measured in minutes.  This layer contains agent
     capability profiles, metadata about agent configurations, and results
     from common queries that are accessed regularly.  The caching layer
     can provide a balance between accessibility and resource utilization.

     Also for archives of historical data with extended retention periods
     measured in hours or days, can employ a different storage strategy.
     Examples data might include historical logs, archived computation
     results, compliance audit data, and debug traces that may be needed
     for analysis or regulatory purposes but are accessed infrequently.

  7.  References

  7.1.  Normative References

     [A2A]      A2A Project, "Agent-to-Agent Protocol Specification",
                2025, <https://a2a-protocol.org/latest/specification/>.

     [MoQ-TRANSPORT]
                Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell,
                "Media over QUIC Transport", Work in Progress, Internet-
                Draft, draft-ietf-moq-transport-14, 2 September 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-moq-
                transport-14>.

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

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




  Nandakumar & Jennings     Expires 20 April 2026                [Page 11]


  Internet-Draft                A2A over MOQT                 October 2025


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

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

  7.2.  Informative References

     [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
                Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
                DOI 10.17487/RFC7540, May 2015,
                <https://www.rfc-editor.org/info/rfc7540>.

     [WebTransport]
                Vasiliev, V., "The WebTransport Protocol Framework",
                RFC 9297, August 2023,
                <https://www.rfc-editor.org/rfc/rfc9297>.

  Appendix A.  Acknowledgments

  Authors' Addresses

     Suhas Nandakumar
     Cisco
     Email: snandaku@cisco.com


     Cullen Jennings
     Cisco Systems
     Email: fluffy@cisco.com


















  Nandakumar & Jennings     Expires 20 April 2026                [Page 12]


name: draft-nandakumar-a2a-moqt-transport
rev: 00
title: Media over QUIC Transport (MOQT) for Agent-to-Agent Protocol
time: 2025-10-20T19:55:13Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-04-23T19:55:13Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:05.317259+00:00
source: ietf
abstract:
  This document specifies how the Agent-to-Agent (A2A) protocol can be
     transported over Media over QUIC Transport (MOQT).  MOQT provides a
     publish/subscribe model over QUIC that enables efficient real-time
     communication between AI agents, supporting the A2A protocol's
     requirements for discovery, negotiation, and collaboration while
     leveraging MOQT's streaming capabilities and built-in prioritization
     mechanisms.

full_text:
  Media Over QUIC                                            S. Nandakumar
  Internet-Draft                                                     Cisco
  Intended status: Standards Track                             C. Jennings
  Expires: 20 April 2026                                     Cisco Systems
                                                           17 October 2025


        Media over QUIC Transport (MOQT) for Agent-to-Agent Protocol
                        draft-nandakumar-a2a-moqt-transport-00

  Abstract

     This document specifies how the Agent-to-Agent (A2A) protocol can be
     transported over Media over QUIC Transport (MOQT).  MOQT provides a
     publish/subscribe model over QUIC that enables efficient real-time
     communication between AI agents, supporting the A2A protocol's
     requirements for discovery, negotiation, and collaboration while
     leveraging MOQT's streaming capabilities and built-in prioritization
     mechanisms.

  About This Document

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

     The latest revision of this draft can be found at https://ietf-wg-
     moq.github.io/draft-a2a-moqt-transport/draft-a2a-moqt-transport.html.
     Status information for this document may be found at
     https://datatracker.ietf.org/doc/draft-a2a-moqt-transport/.

     Discussion of this document takes place on the Media Over QUIC
     Working Group mailing list (mailto:moq@ietf.org), which is archived
     at https://mailarchive.ietf.org/arch/browse/moq/.  Subscribe at
     https://www.ietf.org/mailman/listinfo/moq/.

     Source for this draft and an issue tracker can be found at
     https://github.com/ietf-wg-moq/draft-a2a-moqt-transport.

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





  Nandakumar & Jennings     Expires 20 April 2026                 [Page 1]


  Internet-Draft                A2A over MOQT                 October 2025


     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 20 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.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
       1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     2.  A2A Transport Requirements  . . . . . . . . . . . . . . . . .   3
     3.  MOQT Transport Mapping  . . . . . . . . . . . . . . . . . . .   4
       3.1.  Connection Establishment  . . . . . . . . . . . . . . . .   4
       3.2.  Track Organization  . . . . . . . . . . . . . . . . . . .   5
       3.3.  Message Serialization . . . . . . . . . . . . . . . . . .   5
       3.4.  Priority and Quality of Service . . . . . . . . . . . . .   6
     4.  Protocol Operations . . . . . . . . . . . . . . . . . . . . .   6
       4.1.  Agent Discovery . . . . . . . . . . . . . . . . . . . . .   6
       4.2.  Request/Response Patterns . . . . . . . . . . . . . . . .   7
       4.3.  Streaming Operations  . . . . . . . . . . . . . . . . . .   8
     5.  Benefits of MOQT for A2A  . . . . . . . . . . . . . . . . . .   9
       5.1.  Real-time Communication Benefits  . . . . . . . . . . . .   9
       5.2.  Scalability Benefits  . . . . . . . . . . . . . . . . . .  10
       5.3.  Reliability and Resilience  . . . . . . . . . . . . . . .  10
     6.  MOQT Relay Infrastructure for A2A . . . . . . . . . . . . . .  10
       6.1.  Relay Network Architecture  . . . . . . . . . . . . . . .  10
       6.2.  Message Caching Benefits  . . . . . . . . . . . . . . . .  11
     7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  11
       7.1.  Normative References  . . . . . . . . . . . . . . . . . .  11
       7.2.  Informative References  . . . . . . . . . . . . . . . . .  12
     Appendix A.  Acknowledgments  . . . . . . . . . . . . . . . . . .  12
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  12




  Nandakumar & Jennings     Expires 20 April 2026                 [Page 2]


  Internet-Draft                A2A over MOQT                 October 2025


  1.  Introduction

     The Agent-to-Agent (A2A) protocol enables communication between AI
     agents across different platforms and frameworks.  Currently, A2A
     supports three transport protocols: JSON-RPC 2.0 over HTTP(S), gRPC,
     and HTTP+JSON/REST.  This document defines a fourth transport option
     using Media over QUIC Transport (MOQT) to provide enhanced real-time
     streaming capabilities for agent interactions.

     MOQT is designed for media streaming over QUIC and WebTransport,
     providing a publish/subscribe model with hierarchical data
     organization.  While originally intended for media applications,
     MOQT's streaming model and prioritization capabilities make it well-
     suited for real-time agent communication scenarios.

  1.1.  Requirements Language

     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.  A2A Transport Requirements

     According to the A2A specification, all transport protocols MUST
     provide functional equivalence and support the following
     capabilities:

     *  Secure communication over encrypted channels

     *  Request/response messaging patterns

     *  Streaming data delivery capabilities

     *  Error handling and status reporting

     *  Agent discovery and capability negotiation

     *  Support for various data types (text, JSON, files)











  Nandakumar & Jennings     Expires 20 April 2026                 [Page 3]


  Internet-Draft                A2A over MOQT                 October 2025


        A2A Protocol Layer
        ┌─────────────────────────────────────────────────────────────┐
        │  Agent Discovery │ Capability Exchange │ Task Collaboration │
        └─────────────────────────────────────────────────────────────┘
                                      │
        ┌─────────────────────────────────────────────────────────────┐
        │                    MOQT Transport Layer                     │
        │  ┌─────────────┐  ┌─────────────┐  ┌─────────────────────┐  │
        │  │ PUB/SUB     │  │ Streaming   │  │ Priority/QoS        │  │
        │  │ Model       │  │ Support     │  │ Management          │  │
        │  └─────────────┘  └─────────────┘  └─────────────────────┘  │
        └─────────────────────────────────────────────────────────────┘
                                      │
        ┌─────────────────────────────────────────────────────────────┐
        │                    QUIC/WebTransport                        │
        │        ┌─────────────┐              ┌─────────────┐         │
        │        │ Encryption  │              │ Multiplexing│         │
        │        │ (TLS 1.3)   │              │ & Flow Ctrl │         │
        │        └─────────────┘              └─────────────┘         │
        └─────────────────────────────────────────────────────────────┘

  3.  MOQT Transport Mapping

  3.1.  Connection Establishment

     A2A agents using MOQT transport MUST establish a QUIC or WebTransport
     connection with the ALPN value "moq-00" as defined in the MOQT
     specification.  The connection setup follows this sequence:

     Agent A                                                   Agent B
        |                                                        |
        |──── QUIC Connection (ALPN: "moq-00") ────────────────▶ |
        |◄─── QUIC Connection Established ───────────────────────|
        |                                                        |
        |──── MOQT CLIENT_SETUP ────────────────────────────────▶|
        |◄─── MOQT SERVER_SETUP ─────────────────────────────────|
        |                                                        |
        |──── A2A Agent Registration ───────────────────────────▶|
        |◄─── A2A Capability Exchange ───────────────────────────|
        |                                                        |
        |◄═══ A2A Protocol Exchang ═════════════════════════════▶|

     During the MOQT setup phase, agents MUST negotiate the following A2A-
     specific extensions:

     *  a2a-version: Supported A2A protocol version

     *  a2a-capabilities: Agent capabilities and supported operations



  Nandakumar & Jennings     Expires 20 April 2026                 [Page 4]


  Internet-Draft                A2A over MOQT                 October 2025


     *  a2a-auth: Authentication and authorization tokens

  3.2.  Track Organization

     A2A protocol messages are mapped to MOQT tracks using a hierarchical
     namespace structure.  Each agent creates tracks for different message
     categories: Tracks are organized as follows:

     Request Tracks:  Used for A2A request messages, organized by category
        and action (e.g., discovery/capabilities, tasks/execute).

     Response Tracks:  Used for A2A response messages, organized by
        request ID for correlation.

     Stream Tracks:  Used for long-running streaming operations like task
        execution updates or file transfers.

     Notification Tracks:  Used for asynchronous notifications and events.

  3.3.  Message Serialization

     A2A protocol messages are serialized as JSON and encapsulated within
     MOQT objects.  Each MOQT object contains:

     MOQT Object Structure for A2A:

     ┌─────────────────────────────────────────────────────────┐
     │                 MOQT Object Header                      │
     │  Track ID │ Group ID │ Object ID │ Priority │ ....      │
     └─────────────────────────────────────────────────────────┘
     ┌─────────────────────────────────────────────────────────┐
     │                 A2A Message Payload                     │
     │  ┌─────────────────────────────────────────────────────┐│
     │  │              JSON A2A Message                       ││
     │  │  {                                                  ││
     │  │    "jsonrpc": "2.0",                                ││
     │  │    "method": "category/action",                     ││
     │  │    "params": { ... },                               ││
     │  │    "id": "request-id"                               ││
     │  │  }                                                  ││
     │  └─────────────────────────────────────────────────────┘│
     └─────────────────────────────────────────────────────────┘

     The A2A message format remains unchanged from the JSON-RPC 2.0
     specification, ensuring compatibility with existing A2A
     implementations.





  Nandakumar & Jennings     Expires 20 April 2026                 [Page 5]


  Internet-Draft                A2A over MOQT                 October 2025


  3.4.  Priority and Quality of Service

     MOQT's built-in priority system is mapped to A2A message urgency:

     Priority 1 (Highest):  Emergency and critical error responses

     Priority 2:  Real-time interaction responses and notifications

     Priority 3:  Standard request/response messages

     Priority 4:  Discovery and capability exchange messages

     Priority 5 (Lowest):  Background updates and non-critical
        notifications

  4.  Protocol Operations

  4.1.  Agent Discovery

     Agent discovery over MOQT uses a Subscribe Namespace pattern where
     agents subscribe to the <session_context_id>/discovery namespace
     prefix and publish their agent announcements using the
     <session_context_id>/discovery/agent-{id} pattern to reach all
     subscribers.

     Discovery Flow:

     Agent A                       MOQT Network                    Agent B
        |                              |                             |
        |─ SUBSCRIBE_NAMESPACE────────▶|                             |
        |  (<..>/discovery)            |◄─ SUBSCRIBE_NAMESPACE───────┤
        |                              |   (<..>/discovery)          |
        |                              |                             |
        |─ PUBLISH(/discovery/         |                             |
        |   agent-a) ─────────────────▶|─ PUBLISH(/discovery/        |
        |                              |agent-a) ───────────────────▶|
        |                              |                             |
        |                              |◄─ PUBLISH(/discovery/       |
        |                              |    agent-b) ────────────────┤
        |◄─ PUBLISH(/discovery/        |                             |
        |   agent-b) ──────────────────|                             |
        |                              |                             |
        |                              |                             |
        |◄── Object(Agent B caps) ─────|── Object(Agent A caps) ────▶|







  Nandakumar & Jennings     Expires 20 April 2026                 [Page 6]


  Internet-Draft                A2A over MOQT                 October 2025


  4.2.  Request/Response Patterns

     A2A request/response interactions are implemented using coordinated
     PUBLISH/SUBSCRIBE operations:

     1.  Server agent uses SUBSCRIBE_NAMESPACE to subscribe to
         <..>/server-agent-{id} Namespace prefix

     2.  Client agent sends PUBLISH message on <..>/server-
         agent-{id}/request track

     3.  Client agent subscribes to <..>/server-agent-{id}/response track

     4.  Client agent publishes OBJECT on <..>/server-agent-{id}/request
         track

     5.  Server agent receives OBJECT via its namespace subscription

     6.  Server agent publishes OBJECT on <..>/server-agent-{id}/response
         track

     7.  Client agent receives response OBJECT via its subscription





























  Nandakumar & Jennings     Expires 20 April 2026                 [Page 7]


  Internet-Draft                A2A over MOQT                 October 2025


     Request/Response Flow:

     Client Agent                MOQT                   Server Agent
          |                        |                        |
          |                        |◄(1) SUBSCRIBE_NAMESPACE|
          |                        | (<..>/server-agent-{id})
          |─(2) PUBLISH(           |                        |
          |  /server-agent-{id}/   |                        |
          |  request) ────────────▶|                        |
          |                        |─(2) PUBLISH(           |
          |                        |  /server-agent-{id}/   |
          |                        |  request) ────────────▶|
          |─(3) SUBSCRIBE(         |                        |
          |  /server-agent-{id}/   |                        |
          |  response) ───────────▶|                        |
          |                        |─(3) SUBSCRIBE(         |
          |                        |  /server-agent-{id}/   |
          |                        |  response) ───────────▶|
          |─(4) OBJECT(            |                        |
          |  /server-agent-{id}/   |                        |
          |  request) ────────────▶|───────────────────────▶|
          |                        |                        |
          |                        |◄(5) OBJECT(            |
          |                        |  /server-agent-{id}/   |
          |                        |  response) ────────────|
          |◄(6) OBJECT(            |◄───────────────────────|
          |  /server-agent-{id}/   |                        |
          |  response) ────────────|                        |
          |                        |                        |

  4.3.  Streaming Operations

     Long-running A2A operations like task execution or file transfer
     utilize MOQT's streaming capabilities.  Stream tracks carry
     incremental updates as separate MOQT objects.
















  Nandakumar & Jennings     Expires 20 April 2026                 [Page 8]


  Internet-Draft                A2A over MOQT                 October 2025


     Streaming Task Execution:

     Client                     MOQT Stream                  Server
       |                           |                           |
       |─ SUBSCRIBE(               |                           |
       |  /server-agent-{id}/      |                           |
       |  task_{id}) ─────────────▶|                           |
       |                           |─ SUBSCRIBE(               |
       |                           |  /server-agent-{id}/      |
       |                           |  task_{id}) ─────────────▶|
       |                           |◄─ OBJECT(                 |
       |                           |  /server-agent-{id}/      |
       |                           |  task_{id}, progress-1) ──|
       |◄─ Progress Update 1 ──────|                           |
       |                           |◄─ OBJECT(                 |
       |                           |  /server-agent-{id}/      |
       |                           |  task_{id}, progress-2) ──|
       |◄─ Progress Update 2 ──────|                           |
       |                           |◄─ OBJECT(                 |
       |                           |  /server-agent-{id}/      |
       |                           |  task_{id}, result) ──────|
       |◄─ Final Result ───────────|                           |
       |                           |◄─ OBJECT(                 |
       |                           |  /server-agent-{id}/      |
       |                           |  task_{id}, complete) ────|
       |◄─ Stream Complete ────────|                           |

  5.  Benefits of MOQT for A2A

     MOQT provides significant advantages over traditional A2A transports,
     particularly for real-time agent collaboration and large-scale
     deployments:

  5.1.  Real-time Communication Benefits

     *  Low-latency streaming enables immediate agent response to changing
        conditions

     *  Priority-based message delivery ensures critical communications
        are not delayed

     *  Streaming object delivery allows agents to act on incomplete data
        when appropriate

     *  Built-in flow control prevents agent overload during high-volume
        interactions





  Nandakumar & Jennings     Expires 20 April 2026                 [Page 9]


  Internet-Draft                A2A over MOQT                 October 2025


  5.2.  Scalability Benefits

     MOQT's publish/subscribe model creates powerful network effects for
     multi-agent environments:

     *  One-to-many broadcasts enable efficient agent coordination

     *  Subscription-based interest management reduces unnecessary traffic

     *  Dynamic agent discovery scales to thousands of participants

     *  Relay-based distribution prevents connection explosion in mesh
        networks

  5.3.  Reliability and Resilience

     MOQT provides enhanced reliability features critical for production
     agent deployments:

     *  Connection migration maintains agent sessions during network
        changes

     *  Automatic retry and recovery mechanisms handle transient failures

     *  Graceful degradation allows agents to continue operating with
        reduced capabilities

     *  Quality of Service controls prevent cascade failures in agent
        networks

  6.  MOQT Relay Infrastructure for A2A

     MOQT relays provide critical infrastructure benefits for large-scale
     A2A deployments, enabling efficient message distribution and caching.

  6.1.  Relay Network Architecture

     MOQT relays form a hierarchical distribution network that optimizes
     A2A message delivery across geographic and organizational boundaries:

     This hierarchical structure provides:

     *  Regional optimization with local agent clusters

     *  Global connectivity for cross-region agent collaboration

     *  Load distribution to prevent single points of failure




  Nandakumar & Jennings     Expires 20 April 2026                [Page 10]


  Internet-Draft                A2A over MOQT                 October 2025


     *  Configurable routing policies based on agent requirements

  6.2.  Message Caching Benefits

     MOQT relays can implement intelligent caching strategies optimized
     for A2A communication patterns.

     The most frequently accessed and time-sensitive data with time-to-
     live values are measured in seconds.  This includes real-time agent
     responses, live data streams, and status updates that require
     immediate availability.  These messages are kept in high-speed memory
     to ensure minimal latency for active agent interactions.

     Another layer can serve as an intermediate storage tier with time-to-
     live values measured in minutes.  This layer contains agent
     capability profiles, metadata about agent configurations, and results
     from common queries that are accessed regularly.  The caching layer
     can provide a balance between accessibility and resource utilization.

     Also for archives of historical data with extended retention periods
     measured in hours or days, can employ a different storage strategy.
     Examples data might include historical logs, archived computation
     results, compliance audit data, and debug traces that may be needed
     for analysis or regulatory purposes but are accessed infrequently.

  7.  References

  7.1.  Normative References

     [A2A]      A2A Project, "Agent-to-Agent Protocol Specification",
                2025, <https://a2a-protocol.org/latest/specification/>.

     [MoQ-TRANSPORT]
                Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell,
                "Media over QUIC Transport", Work in Progress, Internet-
                Draft, draft-ietf-moq-transport-14, 2 September 2025,
                <https://datatracker.ietf.org/doc/html/draft-ietf-moq-
                transport-14>.

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

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




  Nandakumar & Jennings     Expires 20 April 2026                [Page 11]


  Internet-Draft                A2A over MOQT                 October 2025


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

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

  7.2.  Informative References

     [RFC7540]  Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext
                Transfer Protocol Version 2 (HTTP/2)", RFC 7540,
                DOI 10.17487/RFC7540, May 2015,
                <https://www.rfc-editor.org/info/rfc7540>.

     [WebTransport]
                Vasiliev, V., "The WebTransport Protocol Framework",
                RFC 9297, August 2023,
                <https://www.rfc-editor.org/rfc/rfc9297>.

  Appendix A.  Acknowledgments

  Authors' Addresses

     Suhas Nandakumar
     Cisco
     Email: snandaku@cisco.com


     Cullen Jennings
     Cisco Systems
     Email: fluffy@cisco.com


















  Nandakumar & Jennings     Expires 20 April 2026                [Page 12]


name: draft-ietf-sml-trust
rev: 00
title: Trust and security considerations for Structured Email
time: 2025-10-20T21:12:29Z
group: sml
group_uri: /api/v1/group/group/2380/
expires: 2026-04-23T21:12:29Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/", "/api/v1/doc/state/38/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:05.320686+00:00
source: ietf
abstract:
  This document discusses trust and security considerations for
     structured email and provides recommendations for message user agents
     on how to deal with structured data in email messages.

  Discussion Venues

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

     Discussion of this document takes place on the Structured Email
     Working Group mailing list (sml@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/sml/.

     Source for this draft and an issue tracker can be found at
     https://github.com/arnt/sml-trust.

full_text:
  sml                                                         H.-J. Happel
  Internet-Draft                                                   audriga
  Intended status: Standards Track                          A. Gulbrandsen
  Expires: 23 April 2026                                             ICANN
                                                           20 October 2025


           Trust and security considerations for Structured Email
                          draft-ietf-sml-trust-00

  Abstract

     This document discusses trust and security considerations for
     structured email and provides recommendations for message user agents
     on how to deal with structured data in email messages.

  Discussion Venues

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

     Discussion of this document takes place on the Structured Email
     Working Group mailing list (sml@ietf.org), which is archived at
     https://mailarchive.ietf.org/arch/browse/sml/.

     Source for this draft and an issue tracker can be found at
     https://github.com/arnt/sml-trust.

  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.



  Happel & Gulbrandsen      Expires 23 April 2026                 [Page 1]


  Internet-Draft                  SML Trust                   October 2025


     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.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3
     3.  Types of security concerns  . . . . . . . . . . . . . . . . .   3
       3.1.  Spam/virus filters  . . . . . . . . . . . . . . . . . . .   3
       3.2.  Formal display of data  . . . . . . . . . . . . . . . . .   3
       3.3.  Automated processing  . . . . . . . . . . . . . . . . . .   4
       3.4.  External references . . . . . . . . . . . . . . . . . . .   4
       3.5.  Social engineering  . . . . . . . . . . . . . . . . . . .   4
     4.  Trust mechanisms  . . . . . . . . . . . . . . . . . . . . . .   5
       4.1.  Processing structured data  . . . . . . . . . . . . . . .   5
       4.2.  Inlining data . . . . . . . . . . . . . . . . . . . . . .   6
     5.  Security considerations . . . . . . . . . . . . . . . . . . .   6
     6.  Privacy considerations  . . . . . . . . . . . . . . . . . . .   6
     7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
     8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
       8.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
       8.2.  Informative References  . . . . . . . . . . . . . . . . .   6
     Appendix A.  Acknowledgements . . . . . . . . . . . . . . . . . .   7
     Appendix B.  Note to self . . . . . . . . . . . . . . . . . . . .   7
     Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

  1.  Introduction

     Structured email, as described in [I-D.sml-structured-email], makes
     the content of some email messages machine-readable, such that user
     agents can provide higher-level functions than displaying/replying,
     for example "add this to calendar".

     Naturally, new functions bring new trust and security considerations,
     or bring new urgency to existing issues.  This document recommends
     security and trust mechanisms that should be applied when processing
     machine-readable content in email messages, both by senders and
     receivers.







  Happel & Gulbrandsen      Expires 23 April 2026                 [Page 2]


  Internet-Draft                  SML Trust                   October 2025


  2.  Requirements Language

     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.

  3.  Types of security concerns

     This section gives an overview of the various types of security and
     privacy concerns that arise when email messages contain structured
     data.  The same concerns often arise for other messages, of course.

     This section is informative.  Or even unnecessary.

  3.1.  Spam/virus filters

     Structured email increases the syntactical and semantic complexity of
     email messages.  If a spam/virus filter parses structured email in
     order to block malevolent messages, the filter's parser will
     necessarily differ from that of the MUA that will finally act on the
     structured data, creating a risk of misclassification.

     These risks are elevated when a structured data format has complex
     syntax, syntax that offers several optional or alternative ways to
     express the same substance, and of course by parsers that deviate
     from the specification for better bug compatibiloty.

  3.2.  Formal display of data

     A common example is displaying a received calendar invitation using
     dates/times in the recipient's timezone, in a fixed format.

     Formal display introduces additional possibilities of discrepancy
     between the different representations.  For example, a single message
     might contains a multipart/alternative containing a text/plain
     description of a flight itinerary, a text/html description of the
     same itinerary, and a structured representation.  All three may be
     different, leading to confusion (and in this example, perhaps to
     missing a flight).

     Unintentional discrepancy is a risk for senders; some recipients may
     be misinformed.

     If a message is sent to a group and there is a discrepancy, different
     members of the group may see it differently.




  Happel & Gulbrandsen      Expires 23 April 2026                 [Page 3]


  Internet-Draft                  SML Trust                   October 2025


     If a particular MUA displays the formal representation within the
     message, a malevolent sender could try to mimic the visual
     representation using HTML with CSS, but with misleading content.

  3.3.  Automated processing

     Automated processing covers actions that are taken as soon as the
     message arrives rather than when a human user reads the message.  For
     example, a user might want flight reservations to be automatically
     added to a travel itinerary application and/or a calendar.

     Such automation could be a custom MUA feature or a future extension
     of the Sieve email filtering language ([RFC5228]).  A related example
     for abuse in automated processing is calendar spam ([CalSpam]).

  3.4.  External references

     Email messages with a text/html body part ("HTML email messages") may
     contain image resources that link to web servers.  Such links can be
     used for tracking user interaction with the message.

     Similar concerns apply to structured data types which include image
     references, such as the cover image of a music album or the teaser
     image of a news article.

     RDF structured data can be partial by design and include references
     to additional data.  Using a "follow your nose" approach, tools can
     follow URL references to obtain further structured data concerning a
     resource.  For example, a piece of structured data about an article
     could reference the article's authors only by URL.  For a meaningful
     processing of author information, one might try to obtain further
     data using that URL.

  3.5.  Social engineering

     While the risks of social engineering are hardly new and the human-
     readable text in a message can in principle be used to persuade the
     human reader to do anything, structured data widens the variety of
     actions the human reader can easily perform.  If there are more
     buttons to click, then there's also a greater variety of attacks.

     Put differently: A user who might not be able to follow the
     instructions in a long and involved text-based social engineering
     attack may be able to follow simple instructions such as "click this
     then that".






  Happel & Gulbrandsen      Expires 23 April 2026                 [Page 4]


  Internet-Draft                  SML Trust                   October 2025


  4.  Trust mechanisms

     Several implementations of structured email restrict processing to
     messages that are particularly trusted.  That is to say, an incoming
     message is in one of these three categories:

     1.  Spam.  Structured data is not processed.

     2.  Ordinary.  Structured data is not processed.

     3.  Trusted.  Structured data is processed.

     This section gives an overview of the trust mechanisms used to
     differentiate between 2 and 3.

     It does not attempt to describe whether a trust-based mechanism is
     appopriate in a particular case.

  4.1.  Processing structured data

     MUAs SHOULD consider structured data in incoming email messages only
     if either of these criteria hold:

     *  The sender is trusted (e.g., part of the user's address book) and
        the messsage either contains a valid personal or domain signature.

     *  The message is part of an ongoing thread with a trusted sender.

     *  The message's content indicate a connection with an older, trusted
        message.  For example, if a calendar invitation was accepted, then
        updates or responses for the same event are connected with the
        original.

     If none of these criteria is fulfilled, MUAs should fall back to
     alternative presentations, typically "text/html".

     Open issue 1: It's not clear that all types of structured data
     require checking.  Some may be 100% display-only.  Is additional
     guidance for display-only data worth the complexity?

     Open issue 2: Really SHOULD?  I (Arnt) don't see this guidance as
     clearly right.  It doesn't match existing code all that well, and
     doesn't seem to be where we want to go.

     Open issue 3: This does not distinguish between - automatic
     processing - actions available to a user in e.g. a MUA - formal
     display




  Happel & Gulbrandsen      Expires 23 April 2026                 [Page 5]


  Internet-Draft                  SML Trust                   October 2025


  4.2.  Inlining data

     Structured data included in an email message SHOULD be self-contained
     in order to avoid privacy problems.  This implies that if an MUA is
     able to provide meaningful user interaction (rather than mere
     display), then the data SHOULD be self-contained, such that the
     interaction will not need referenced resources from the web.

  5.  Security considerations

     Security considerations are a core subject of this document.

  6.  Privacy considerations

     Privacy considerations are a core subject of this document.

  7.  IANA Considerations

     This document has no IANA actions at this time.

  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.sml-structured-email]
                "*** BROKEN REFERENCE ***".

     [RFC5228]  Guenther, P., Ed. and T. Showalter, Ed., "Sieve: An Email
                Filtering Language", RFC 5228, DOI 10.17487/RFC5228,
                January 2008, <https://www.rfc-editor.org/rfc/rfc5228>.

     [RFC6132]  George, R. and B. Leiba, "Sieve Notification Using
                Presence Information", RFC 6132, DOI 10.17487/RFC6132,
                July 2011, <https://www.rfc-editor.org/rfc/rfc6132>.






  Happel & Gulbrandsen      Expires 23 April 2026                 [Page 6]


  Internet-Draft                  SML Trust                   October 2025


     [RFC6134]  Melnikov, A. and B. Leiba, "Sieve Extension: Externally
                Stored Lists", RFC 6134, DOI 10.17487/RFC6134, July 2011,
                <https://www.rfc-editor.org/rfc/rfc6134>.

     [RFC7942]  Sheffer, Y. and A. Farrel, "Improving Awareness of Running
                Code: The Implementation Status Section", BCP 205,
                RFC 7942, DOI 10.17487/RFC7942, July 2016,
                <https://www.rfc-editor.org/rfc/rfc7942>.

     [CalSpam]  "Calendar operator practices — Guidelines to protect
                against calendar abuse", n.d.,
                <https://standards.calconnect.org/csd/cc-18003.html>.

     [MachineReadable]
                "NIST IR 7511 Rev 4", n.d.,
                <https://csrc.nist.gov/glossary/term/Machine_Readable>.

  Appendix A.  Acknowledgements

     The authors wish to thank Ben Bucksch, Alexey Melnikov, Phillip Tao,
     Lisa Dusseault and others whose suggestions were made before this
     paragraph was started.

  Appendix B.  Note to self

     RFC Editor: Please remove this section.

     The charter has this to say about what this document should contain:
     "Recommendations for security and trust mechanisms that should be
     applied when processing machine-readable content in email messages"
     and "security and trust recommendations to prevent abuse of
     structured email".  No more, no less.

  Authors' Addresses

     Hans-Joerg Happel
     audriga
     Email: happel@audriga.com
     URI:   https://www.audriga.com


     Arnt Gulbrandsen
     ICANN
     6 Rond Point Schumann, Bd. 1
     1040 Brussels
     Belgium
     Email: arnt@gulbrandsen.priv.no
     URI:   https://icann.org/ua



  Happel & Gulbrandsen      Expires 23 April 2026                 [Page 7]


name: draft-zhang-rvp-problem-statement
rev: 00
time: 2025-10-21T18:40:56Z
group: none
group_uri: /api/v1/group/group/1027/
expires: 2026-04-24T18:40:56Z
states: ["/api/v1/doc/state/1/", "/api/v1/doc/state/150/"]
categories: []
tags: []
fetched_at: 2026-03-04T00:00:05.324311+00:00
source: ietf
title:
  Problem Statements and Requirements of Real-Virtual Agent Protocol (RVP): Communication Protocol for Embodied Intelligence in Physical- Digital Continuum

abstract:
  The Real-Virtual Agent Protocol (RVP) enables seamless coordination
    between physical entities (robots, IoT devices, manufacturing
    systems and agents) and digital agents (AI systems, software agents,
    virtual twins) through unified composite identity management,
    physical/social/production relations graph-based coordination, and
    physical constraint integration. Unlike existing protocols that
    assume peer-to-peer digital relationships (A2A for agents, MCP for
    AI tools, ANP for agent networks), RVP unifies physical and digital
    agents communication and achieves physical data loop for online
    learning for embodied agents considering both hierarchical
    physical/social/production relations and physical world constraints.
    RVP is designed for immediate deployment in modern manufacturing,
    smart cities, autonomous mobility systems, and human-AI
    collaborative environments where non-peer, partially centralized
    relations and coordination is essential for real-world embodied
    intelligence networks.

full_text:
  Workgroup:Network Working Group                                     X.Zhang
  Internet-Draft:                                                    Hicagent
  draft-zhang-rvp-problem-statement-00                                Y.Zhang
  Published:20 October 2025                                           C.Zhang
  Intended status: Informational                                      M.Zhang
  Expires:20 April 2026                                         China Telecom
                                                                         W.Lu
                                                                       SUPCON




      Problem Statements and Requirements of Real-Virtual Agent Protocol
     (RVP): Communication Protocol for Embodied Intelligence in Physical-
                              Digital Continuum





      Status of this Memo

    This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79. This document may not be modified,
    and derivative works of it may not be created, except to publish it
    as an RFC and to translate it into languages other than English.

    This document may contain material from IETF Documents or IETF
    Contributions published or made publicly available before November
    10, 2008. The person(s) controlling the copyright in some of this
    material may not have granted the IETF Trust the right to allow
    modifications of such material outside the IETF Standards Process.
    Without obtaining an adequate license from the person(s) controlling
    the copyright in such materials, this document may not be modified
    outside the IETF Standards Process, and derivative works of it may
    not be created outside the IETF Standards Process, except to format
    it for publication as an RFC or to translate it into languages other
    than English.

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF), its areas, and its working groups.  Note that
    other groups may also distribute working documents as Internet-
    Drafts.

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



      Zhang                  Expires 20,April,2026                 [Page 1]


      Internet-Draft          RVP Problem Statement             October 2025


    The list of current Internet-Drafts can be accessed at
    http://www.ietf.org/ietf/1id-abstracts.txt

    The list of Internet-Draft Shadow Directories can be accessed at
    http://www.ietf.org/shadow.html

    This Internet-Draft will expire on April 20, 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
    (http://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 Simplified BSD License text as described in
    Section 4.e of the Trust Legal Provisions and are provided without
    warranty as described in the Simplified BSD License.

  Abstract

    The Real-Virtual Agent Protocol (RVP) enables seamless coordination
    between physical entities (robots, IoT devices, manufacturing
    systems and agents) and digital agents (AI systems, software agents,
    virtual twins) through unified composite identity management,
    physical/social/production relations graph-based coordination, and
    physical constraint integration. Unlike existing protocols that
    assume peer-to-peer digital relationships (A2A for agents, MCP for
    AI tools, ANP for agent networks), RVP unifies physical and digital
    agents communication and achieves physical data loop for online
    learning for embodied agents considering both hierarchical
    physical/social/production relations and physical world constraints.
    RVP is designed for immediate deployment in modern manufacturing,
    smart cities, autonomous mobility systems, and human-AI
    collaborative environments where non-peer, partially centralized
    relations and coordination is essential for real-world embodied
    intelligence networks.








      zhang                  Expires 20,April,2026                 [Page 2]


      Internet-Draft          RVP Problem Statement             October 2025


      Table of Contents


  1. Introduction...........  .....................................  ...3
      1.1. Background and Current Status of Existing Protocols....   ...3
      1.2. Why RVP is Necessary....................................   ..6
  2. Terminology...  ...............................................  ..7
  3. Problem Statement...  ..........................................  .8
       3.1. Identity Fragmentation Across Domains....................  .8
       3.2. Lack of Physical/Social Relations Mapping among agents...  .8
       3.3. Lack of Physical Constraint Reflection..................  .10
       3.4. Lack of Efficient Registration and Effective Discovery       
       Mechanisms for Agents........................................ . 10
       3.5. Lack of Real-time Data Input to the Embodied Large Model for 
       Training.....................................................  .10
  4. Protocol Requirements Discussion and Design Principles...  ....  .11
       4.1. Design Principles..................................... . ..11
       4.2. Requirements Discussion................................  ..12
       4.3. Protocol Integration Strategy..........................  ..15
  5. RVP Use Cases......  ..........................................  .17
       5.1. Flexible Production Line Coordination in Manufacturing..  .17
       5.2. Disaster Rescue Human-Robot Collaborative Environments..  .18
       5.3. Autonomous Driving Systems in Smart City................  .18
          5.3.1. Multi-Vehicles(Agents) Collaborative Delivery..... .. 18
          5.3.2. Vehicle-to-Everything (V2X) Intersection Management.  19
  6. Security Considerations........................................  .19
       6.1. Identity Verification and Authorization....................19
       6.2. Communication Security.....................................19
       6.3. Safety System Protection...................................20
       6.4. Audit and Monitoring.......................................20
       6.5. Isolation Capabilities.....................................21
  7. IANA Considerations............................................  .21
  8. References.....................................................  .21
       8.1. Normative References.......................................21
       8.2. Informative References.....................................21
  9. Acknowledgments................................................  .22


  1. Introduction
  1.1. Background and Current Status of Existing Protocols

    The convergence of artificial intelligence, robotics, and ubiquitous
    computing is creating unprecedented demand for connectivity and
    coordination between physical systems and digital intelligence.
    However, existing protocols are insufficient to effectively meet
    these demands, facing severe challenges in cross-entity
    collaboration, cross-level management, and cross-architecture


      zhang                  Expires 20,April,2026                 [Page 3]


      Internet-Draft          RVP Problem Statement             October 2025


    communication, primarily manifested in problems such as identity
    fragmentation, protocol incompatibility, and missing physical
    constraint reflection mechanisms.

    With the rapid development of Large Language Models (LLMs), LLM-
    based agents have become very popular in many industries and
    scenarios. Agent and model protocols are gaining widespread
    attention from both industry and academia. Meanwhile physical
    agents(e.g., emobodied robots, autonomous driving cars, UAVs)
    embedded in physical entities are playing a crucial role in modern
    manufacturing[SMART-FACTORY], smart cities[AI-CITY], autonomous
    mobility systems[APPOLO], and human-AI collaborative
    environments[Human-Robot]. The interaction between hetergenous
    physcial agents and digital agents as well as models bridges the
    physical world and digital world into a seamless continuum. Real-
    Virtual Agent Protocol (RVP) is a communication protocol designed
    for reality-virtuality symbiotic, supporting non-peer-to-peer, and
    partially centralized embodied intelligence agent networks. It
    focuses on mapping on physical/social/production relations graphs
    and physical constraint reflection between agents.

    Today's agent communication protocols are designed for homogeneous
    environments. Mainstream agent communication protocols include
    A2A[A2A-SPEC], MCP[MCP-SPEC], ANP[ANP-SPEC], etc.:

    Agent-to-Agent (A2A) Communication Protocol: Supports digital agent
    communication but assumes all participants are software entities
    operating in digital environments in peer-to-peer communication,
    hardly to handle non-peer relationships in physical world, and lacks
    of physical/social/production relations constraints. In practical
    applications, it has fundamental limitations for physical-digital
    coordination, including:

    1) Communication Model Mismatch: A2A protocol uses asynchronous
    message transmission optimized for digital agents that can pause,
    queue, and process messages at variable speeds. Physical systems
    require real-time coordination with hard deadlines-a robot cannot
    "pause" mid-motion to wait for queued messages.

    2) No Physical Constraint Modeling: A2A protocol has no standard way
    to represent physical constraints (workspace boundaries, inertia,
    safety requirements). When a digital agent requests a robot to "move
    to position X immediately," the protocol cannot express that the
    robot needs 3.2 seconds due to physical acceleration limits.





      zhang                  Expires 20,April,2026                 [Page 4]


      Internet-Draft          RVP Problem Statement             October 2025


    3) Safety Integration Gap: A2A protocol has no built-in safety
    mechanisms. There is no standard way to represent that certain agent
    communications could cause physical harm if mishandled.

    MCP: Provides AI systems with tool access but treats physical
    systems as external, and sometimes stateless tools rather than
    intelligent twin participants. It focuses on model context
    management, concentrating on context interaction between agents and
    tools (such as user preferences, environmental states, session and
    task information, etc.). The problems raised by physcial systems
    include:

    1)Stateless Tool Model: MCP treats all tools as stateless functions.
       Physical systems are inherently stateful, i.e., a robot's current
       position affects what next operations are possible. MCP is hard to
       represent that the same tool call may succeed or fail based on
       physical context.

    2)Bidirectional Coordination: MCP is bascially request-response model.
       Physical systems need to provide continuous feedback (sensor data,
       status updates, emergency conditions) that should influence AI
       decision-making in real-time.

    3) MCP basically assumes one single AI system/agent accessing tools,
       which does not involve complex collaboration relationships between
       agents. Physical agents often need to coordinate between multiple
       AI systems (planning AI, safety monitoring AI, quality control AI)
       simultaneously. Moreover, real-time interaction and
       synchronization (e.g., ms magnitude) between physical and digital
       agents is hard to achieve.


    Agent Network Protocol (ANP): Organizes agent networks in multi-
    agent scenarios with peer-to-peer entities, building the underlying
    architecture of the agent internet, known as the "HTTP of P2P
    networks" and supporting decentralized decision-making. It supports
    decentralized discovery but identity management is based on DID,
    unable to handle 1-to-N topology relations from the physical entity
    to virtual entities (for examaple, an automonous driving car
    involves a physcial entitiy and several virtual assistant entities
    to do route optimization and simulation, operate the on-car
    electronic systems and search for the weather forecast,etc.)and
    virtual entity cluster discovery requires multiple queries with low
    efficiency. Its constraints are similar to the A2A communication
    protocol and will not be elaborated further.


      zhang                  Expires 20,April,2026                 [Page 5]


      Internet-Draft          RVP Problem Statement             October 2025


    Additionally, regarding connecting physical and digital entities,
    existing underlying transport protocols have the following issues:

    IoT Protocols (MQTT, CoAP[RFC7252], HTTP) handle device connectivity
    and data exchange but lack semantic understanding of physical-
    digital integration requirements.

    IoT protocols like MQTT and CoAP handle device connectivity but
    cannot support intelligent coordination:

    1) No Coordination Semantics: IoT protocols transport data but have
    no understanding of coordination requirements. Publishing sensor
    data to a topic provides no information about what coordination
    actions are appropriate.

    2) No Identity Coherence: IoT protocols identify devices by topics
    or endpoints but cannot represent that multiple endpoints refer to
    the same logical entity. A robot's position sensor, control
    interface, and status feed are separate MQTT topics with no
    protocol-level connection.

    3) No Intelligence Integration: IoT protocols have no standard way
    to integrate with AI systems beyond basic pub/sub. There is no
    protocol support for AI systems to understand device capabilities or
    coordinate intelligent actions.

    RVP is implemented similarly to existing protocols (such as MCP, A2A,
    ANP) through further encapsulation or modification of underlying
    transport protocols (such as SSE, WebSocket, MQTT) or even direct
    modification of A2A, MCP and ANP.

  1.2. Why RVP is Necessary

    Existing protocols (A2A, MCP, IoT protocols) have fundamental
    limitations in handling unified coordination of physical entities
    and digital entities. Although A2A protocols could theoretically be
    extended to handle physical entities, this would require fundamental
    changes to agent communication semantics to handle physical
    constraints [A2A-FIPA][CPS-DESIGN]and complete redesign of unified
    identity management across domains. Enhancing MCP to effectively
    handle physical and digital agent coordination would require new
    design principles to design stateful coordination and real-time
    communication among different kinds of agents, which is common in
    real world. It's hard to imagine to convert all physical systems
    into stateless tools, thereby losing their needs of intelligent
    coordination. Adding intelligence to IoT protocols would require
    fundamental semantic changes incompatible with existing IoT


      zhang                  Expires 20,April,2026                 [Page 6]


      Internet-Draft          RVP Problem Statement             October 2025


    deployments, still lacking unified identity management and limited
    to device-level rather than system-level coordination.

    Future multi-agent architectures will evolve into hierarchical
    (MCP's C/S architecture can satisfy), distributed (ANP's P2P
    architecture can satisfy), and hybrid frameworks, enabling flexible
    and diverse ways to coordinate large numbers of agents to complete
    various complex tasks under different business scenarios. However,
    the existing architectures cannot fully meet the communication needs
    of reality-virtuality integrated embodied intelligence agent
    networks. For example, one-to-many real-virtual mapping requires
    simultaneous identity authentication of multiple virtual entities
    and simultaneous registration and discovery of these agents.
    Communication between real-virtual agents also requires following
    constraints and rules of production relations graphs in the physical
    world. What's more, the data starvation for model training requires
    real-time physical data input to achieve data-loop for online
    training in embodied intelligence.

    Therefore, RVP is needed that can treat physical and digital as
    expressions of unified entities and create efficient communication
    based on these expressions. Instead of replacing existing protocols,
    the new protocol is designed to integrate with them:

    1) Integration with Existing Protocols: Through adapters or
    middleware layers, enabling the new protocol to work collaboratively
    with existing protocols such as A2A, MCP, IoT, etc.

    2) Introducing New Mechanisms: Particularly physical constraint
    reflection, unified identity management, physical/social/production
    relations graphs, etc. Based on this, a heterogeneous communication
    protocol for reality-virtuality integrated embodied intelligence
    agents is proposed.

  2. Terminology

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

    Composite Agent: A Composite Agent is a super-agent to interact with
    the external physical world on behalf of its associated Real-entity
    Agent, and Virtual-entity Agent. While adhering to the principle of
    permission isolation, it realizes effective utilization and
    comprehensive fusion of information related to both worlds. By
    abstractly layering the capabilities of individual entities in the
    physical world, it achieves efficient coordination from value


      zhang                  Expires 20,April,2026                 [Page 7]


      Internet-Draft          RVP Problem Statement             October 2025


    decision-making to task execution. Composite Agent aims to
    characterize human/unmaned behavior patterns in complex environments,
    ensuring efficiency, flexibility, and stability of task processing.

    Physical Expression: The concrete instance of an object in the
    physical domain, carrying the existence form and interaction
    capabilities of the object in the physical world.

    Digital Expression: The virtualized instance of an object in the
    digital domain, carrying the logical representation and
    computational capabilities of the object in digital space.

    Real-Virtual Agent Protocol (RVP): A standardized communication
    protocol specifically designed for composite agent architecture,
    regulating interactions and coordination among physical and digital
    agents.

    Physical/Social/Production Relations Graph: A semantic network-based
    directed graph describing organizational relationships, business
    processes, and permission constraints among agents.

    Physical Constraint: Standardized description of timing, spatial,
    dynamic, and safety constraints in the physical world, supporting
    automatic verification and real-time reflection.

  3. Problem Statement

  3.1. Identity Fragmentation Across Domains

    Currently, in above mainstream communication protocols, no protocol
    provides unified identity management across physical and digital
    domains. Each protocol treats the same entity as a separate,
    unrelated object. The same logical entity exists as disconnected
    representations in different systems. These representations are
    manually coordinated through custom integration code, leading to
    consistency problems and coordination failures.

    Without unified identity management, the same entity has multiple
    un-associated identity representations in different systems, leading
    to low registration efficiency, data inconsistency, and coordination
    failures. Identity information needs to be manually synchronized,
    increasing system complexity and maintenance costs.

  3.2. Lack of Physical/Social Relations Mapping among agents

    Current mainstream agent protocols (MCP/A2A/ANP) are built on a
    digital-native worldview, ignoring the inherent non-peer nature,


      zhang                  Expires 20,April,2026                 [Page 8]


      Internet-Draft          RVP Problem Statement             October 2025


    hierarchical structures, and business constraints of agents in the
    physical world. In existing agent systems, interactions between
    agents are often based on simple peer-to-peer or client-server
    models, lacking mapping of complex production relationships in the
    real world.

    In real world, an agent may represent the individual person's social
    roles in different scenarios, such as father, employee, friend, etc.;
    it can also represent actual existence in the physical world, such
    as robots, sensors, actuators, and other hardware devices.
    Collaboration in the real world is often non-peer, with hierarchical
    structures, division of labor, and permission constraints. For
    example, in intelligent manufacturing, there are levels such as
    scheduling centers, production line control, and robots; in smart
    cities, there are command centers, departments, and field devices.

    Therefore unlike in digital world, the hierarchical and network-
    based physical/social/production relations graph exists, which
    stores physical world data and capabilities related to specific
    roles.

    Due to the lack of explicit modeling and mapping of these
    relationships, it leads to:

      Difficult Permission Control: Access and operation permissions
    between agents are not constrained based on
    physical/social/production relations, potentially causing
    unauthorized operations.

      Low Collaboration Efficiency: Agents cannot quickly identify
    collaboration partners, requiring complex negotiation and discovery
    mechanisms.

      Unreasonable Resource Allocation: Due to the lack of relations-
    based scheduling, resource allocation may not conform to actual
    business logic, leading to resource waste or bottlenecks.

      Poor System Maintainability: When business relations change,
    manual adjustments to connections and permissions between agents are
    needed, which is error-prone.

    Therefore, we need to introduce a "Phycial/Social/Production
    Relations Graph" in the protocol to explicitly describe these
    relations among agents and implement permission control,
    collaboration scheduling, and resource allocation based on this
    graph.



      zhang                  Expires 20,April,2026                 [Page 9]


      Internet-Draft          RVP Problem Statement             October 2025


  3.3. Lack of Physical Constraint Reflection

    The current agent protocol ecosystem has a fundamental cognitive
    disconnect: intelligent protocols like A2A and MCP can understand
    intelligent coordination but lack physical perception. In a research
    [STI-BENCH] it pointed out While LLMs have been extensively studied
    for visual semantic understanding tasks, their ability to perform
    precise and quantitative spatial-temporal understanding in real-
    world applications is rather week, with top-performing models like
    Gemini-2.5-Pro achieving around 41.4% average accuracy.

    IoT protocols can understand physical devices but lack intelligent
    cognition. This causes agent decisions in the digital world to be
    seriously disconnected from physical world reality rules.

    Physical and digital spaces need to establish a standardized
    description framework for physical constraints to implement real-
    time reflection mechanisms for constraint states, ensuring
    consistency between digital decisions and physical reality.

  3.4. Lack of Efficient Registration and Effective Discovery Mechanisms
     for Agents

    Existing protocols (such as MCP, A2A, ANP) have deficiencies in
    registration and discovery, resulting in agents requiring manual
    configuration and inability to dynamically adapt to network changes.
    Due to the lack of unified, adaptive, semantic registration and
    discovery mechanisms, agent networks become information silos,
    unable to achieve true "plug-and-play" and "dynamic collaboration."
    A unified registration and discovery mechanism needs to be designed
    to support dynamic joining and exiting of agents and automatic
    updating of network topology.

  3.5. Lack of Real-time Data Input to the Embodied Large Model for
     Training

    Back to 2023, just after one year of ChatGPT's release, many studies
    warned that the world could run out of high-quality data to train AI
    soon. The research[DATA-RUNOUT] predicted that the training dataset
    will run out between 2026 and 2032, or even earlier.

    This is even worse for embodied intelligence systems, which has less
    recored knowledge to learn. Online learning from real-time practice
    data attracts more and more attentions to solve this problem.
    Particularly, data automatically generated during agent task
    execution that is not directly explicitly recorded contains deep
    information about environmental dynamics, physical laws, task


      zhang                  Expires 20,April,2026                [Page 10]


      Internet-Draft          RVP Problem Statement             October 2025


    execution context, decision-making processes, and multi-modal
    interactions. For example, in sanitation scenarios, implicit data
    includes interactions between sanitation vehicles and the
    environment (such as the relationship between cleaning force and
    ground material), micro-adjustments during task execution (such as
    trajectory corrections when avoiding pedestrians), and correlations
    between equipment operating status and work effectiveness. These
    real-time data supplement is vital for training the embodied agents.
    Moreover it will help to solve the data-training-decision
    fragmentation at the same time, i.e., when training data is
    historical, static, and disconnected, while agents need to make
    immediate responses in dynamic, real-time, continuous environments.
    This fragmentation prevents models from continuously evolving in the
    real world.

    To the best of our knowledge, current protocols are not available to
    input real-time data for continuous training.

    To summary, there is an urgent need for unified communication
    protocol standards to effectively connect physical entities and
    digital agents.

  4. Protocol Requirements Discussion and Design Principles

  4.1. Design Principles

    Constraint Priority Principle: Physical constraints are not
    afterthought limitations but prerequisites for system design and
    operation.

      Perform physical feasibility verification before all decisions
    and executions

      Establish automatic propagation and consistency maintenance of
    constraints in task chains

      Deeply integrate safety constraints into coordination semantics

    Unified Semantics Principle: Establish a unified semantic framework
    across all protocols and domains, eliminating ambiguity in concept
    mapping.

      Ensure consistent interpretation of the same concepts across
    different protocols and domains

      Semantic interpretation considering current physical environment
    and business context


      zhang                  Expires 20,April,2026                [Page 11]


      Internet-Draft          RVP Problem Statement             October 2025


      Support runtime semantic adjustment and optimization

  4.2. Requirements Discussion

    This section is intended to stimulate the open discussion for the
    RVP requirements, so that the design team can consolidate the
    requirements of the RVP protocol.

    RVP.REQ-1: Unified Entity Identity Management

    Addressing the identity fragmentation problem in existing protocol
    ecosystems, where the same entity has different identity marking
    systems in physical, digital, and hybrid domains, leading to
    semantic inconsistency, life cycle disconnection, and accumulated
    security risks. The protocol MUST support unified entity
    registration, containing physical capabilities, digital intelligence,
    and hybrid manifestations within a single identity model.

    The requirements include:

      Support automatic association and verification of physical and
    digital identities

      Establish a globally unique entity identifier system

      Identity registration MUST contain complete composite identity
    description.

      Identity verification SHOULD support cross-domain identity
    consistency checks.

      Identity updates MUST ensure synchronization of identity
    information in all domains

    RVP.REQ-2: Dynamic Registration and Discovery Mechanisms

    Existing systems rely on manual configuration and hard-coded
    connections, unable to adapt to dynamic network topology changes,
    resulting in poor system scalability. The protocol MUST provide
    efficient agent registration and service discovery mechanisms.

    The requirements include:

      New nodes MUST be able to automatically discover the network and
    complete registration




      zhang                  Expires 20,April,2026                [Page 12]


      Internet-Draft          RVP Problem Statement             October 2025


      Node capability changes MUST be updated to the registry in real-
    time

      Provide real-time node health status monitoring

      Support external interface for natural language semantic service
    discovery

      Service discovery MUST consider current context and environmental
    state

      Provide intelligent service selection based on multi-dimensional
    matching

    RVP.REQ-3: Physical/Social/Production Relations Graph Management

    Existing protocols lack of expressive capability for real-world
    organizational structures, unable to express business relations such
    as command, collaboration, and affiliation, resulting in low
    coordination efficiency and coarse-grained permission control. The
    protocol MUST provide standard mechanisms to define, maintain, and
    query organizational structures among entities based on production
    relationships.

    The Graph Model Requirements include:

      Define standardized physcial/social/production relations
    classifications

      Support runtime creation, update, and deletion of relations

      Implement automatic derivation of permissions based on relations
    graphs

    The Operational Requirements include:

      Node registration MUST automatically derive initial
    physical/social/production relations

      Relations changes SHOULD trigger impact analysis and system
    adjustments

      Routing decisions MUST consider physical/social/production
    relations constraints

    RVP.REQ-4: Physical Constraint Integration



      zhang                  Expires 20,April,2026                [Page 13]


      Internet-Draft          RVP Problem Statement             October 2025


    Existing protocols lack systematic description and verification
    mechanisms for timing, spatial, dynamic, and other constraints,
    causing digital decisions to be disconnected from physical reality.
    The protocol MUST provide standard mechanisms to represent and
    enforce physical constraints in coordination decisions.

    The requirements include:

      Define machine-readable physical constraint description format,
    forming a standardized constraint language

      Establish complete constraint classification

      Constraint description MUST support automatic verification

      Decision verification MUST perform physical constraint checks
    before execution

      Constraint violations SHOULD trigger standardized emergency
    responses

      Constraint propagation MUST maintain consistency during task
    decomposition

    RVP.REQ-5: Safety-Aware Coordination Semantics

    Safety mechanisms considerations are required to be added as built-
    in features to meet real-time requirements. The protocol MUST
    integrate physical safety constraints, timing requirements, and
    emergency response mechanisms into coordination communications.

    The requirements include:

      Built-in safety semantics, with safety constraints as core
    components of coordination semantics

      Safety decisions consider physical state and business context

      Operation execution SHOULD perform real-time safety boundary
    checks

      Emergency response MUST be automatically triggered when safety
    threats are detected

    RVP.REQ-6: Real-time Data Sharing




      zhang                  Expires 20,April,2026                [Page 14]


      Internet-Draft          RVP Problem Statement             October 2025


    Real-time data sharing involve injecting real-time data of the
    physical agents into models and sharing direct and local sense,
    observation or other kind of data between agents.

    The requirements include:

         Extremely Low latency reliable data transmission

         Streamed training data provision to training procedure

         Training and reasoning mode switch dynamically

         Model update and versioned distribution

         Standard gradient/parameter aggregation interface

         Direct sense and information sharing between agents

  4.3. Protocol Integration Strategy

    RVP is designed as a meta-protocol that does not replace existing
    protocols (such as A2A, MCP, IoT protocols) but inherits, extends,
    or enhances them, providing core capabilities such as unified entity
    identity, physical/social/production relations graphs, and physical
    constraint integration. A2A is the most suitable starting-point when
    designing RVP.

    A2A Protocol Enhancement: Introduce RVP's core concepts into the A2A
    protocol to support physical-digital unified coordination.

      Extend Agent Card: Add composite identity description, dynamic
    capability discovery, and physical/social/production relations graph
    information to A2A's Agent Card to support intelligent routing.

      Unified Identity Mapping: Extend agent identity in A2A to unified
    entity identity (including Real-entity agent and  Virtual-entity
    agent), achieving cross-domain identity consistency.

      Real-time Coordination Semantics: Define new message types and
    interaction patterns for time-sensitive operations, supporting
    deadlines and real-time guarantees.

      Physical Constraint Representation: Add physical constraint
    fields to A2A messages, allowing agents to consider physical
    limitations (such as location, capabilities, time, etc.) during
    negotiation.



      zhang                  Expires 20,April,2026                [Page 15]


      Internet-Draft          RVP Problem Statement             October 2025


      Safety-aware Communication: Integrate safety context into A2A
    communication, including permission verification based on production
    relationships and physical safety constraints.

    Besides A2P, MCP and IoT protocols can also integrate with RVP, but
    this is not mandatory in the 1st phase:

    MCP Integration Enhancement: Enable MCP to support stateful, real-
    time coordination of physical agents.

    Hardware Tool Extension: Extend MCP tools from predominantly
    software digital domain to hardware physical domain, supporting
    embodied intelligence agent communication for hardware device
    queries, instructions, and interactions.

      Stateful Tool Representation: Encapsulate physical agents as
    stateful MCP tools, allowing tools to maintain state (such as device
    status, task progress).

      Timing Constraint Specification: Add timing constraints (such as
    start time, deadline, execution duration, etc.) in MCP tool calls.

      Multi-AI Coordination Support: Through RVP's
    physical/social/production relations graph, coordinate multiple AI
    model operations on the same physical system.

    IoT Protocol Bridge: Seamlessly integrate IoT devices into the RVP
    ecosystem, achieving both semantics of device data and intelligent
    coordination of device capabilities.

      Semantic Mapping: Map device data (such as sensor readings) to
    coordination context (such as events, states) and attach physical
    constraints.

      Unified Entity Identity: Assign unified entity identity to each
    IoT device and associate it with the corresponding Real-entity
    agents.

      Device Capability Representation: Describe device capabilities as
    standardized services, including functions, constraints, and states.

      Message Delivery Guarantees: Provide reliability guarantees (such
    as at-least-once delivery, acknowledgment mechanisms) for
    coordination messages among IoT devices.





      zhang                  Expires 20,April,2026                [Page 16]


      Internet-Draft          RVP Problem Statement             October 2025


  5. RVP Use Cases

    This section is not a to-do list for the protocol. To make RVP well
    understood, it provides several scenarios on how RVP could be used
    in practice.

  5.1. Flexible Production Line Coordination in Manufacturing

    A flexible manufacturing line produces customized products with
    different kinds of agents among robots, CNC machines, AGVs
    (Automated Guided Vehicles), and quality inspection stations, along
    with their digital twins [DIGITAL-TWINS] agents.

    A robot arm Composite Agent is composed of the controller, Real-
    entity robot arm Agent and its digital twins (Virtual-entity Agent).
    When the composite robot arm agent is registered via RVP, the
    associated real-entity robot and virtual-entity agents are
    automatically registered as well, reducing the complexity of
    registration several times.

    The Physical/Social/Production Relations Graph with hierarchical
    structure is created and registered which may look like: Production
    Line Manager Work Cell Controller Individual Robots. Permission
    constraints ensure only authorized controllers can issue commands to
    specific robots.

    Physical Constraints are transferred via RVP with spatial
    constraints such as robot workspace boundaries, collision avoidance
    zones; temporal constraints such as task completion deadlines and
    synchronization requirements; and dynamic constraints such as
    Maximum acceleration, payload capacity, energy consumption, etc....

    When the order is received, the production line manager agent
    decomposes tasks based on Physical/Social/Production Relations Graph
    and message routing is based on the relations graph, supporting
    explicit routing paths and automatic path calculation. The tasks in
    associated agents are linked based on the relations graph
    constraints supporting synchronous and asynchronous communication.
    The real-entity agents execute the appointed tasks with real-time
    monitoring and the virtual-entity agents simulate execution
    feasibility with physical constraints. The physical verification
    ensures digital instructions comply with physical system limitations
    after the tasks are completed. Constraint violation triggers
    automatic redo. The feedback as well as the process data in
    different agents can be integrated to the owner for decision-making
    and model training. Problematic nodes request assistance via
    relations graph queries using RVP.


      zhang                  Expires 20,April,2026                [Page 17]


      Internet-Draft          RVP Problem Statement             October 2025


  5.2. Disaster Rescue Human-Robot Collaborative Environments

    Consider a search and rescue operation with human rescuers, rescue
    robots, drones, and command center.

    Robots and humans form ad-hoc coordination network in
    infrastructure-degraded environment. Flexible social relations graph
    adapting to situation is created via RVP to establish command
    structure including incident commander, who provides overall
    coordination; team leaders who coordinate local resources and
    Individual robots/humans, who have autonomy for immediate safety
    decisions. The social relations graph will dynamically change to add
    emergency relations (e.g., fire truck and ambulance).

    The robot Composite Agents register their capabilities via RVP and
    the search area is decomposed based on the robot capabilities, human
    responsibility and environmental constraints to create several
    search teams(including humans and robots). The physical constraint
    is monitored for structural integrity or hazardous conditions. The
    virtual-entity agents simulate evacuation routes with physical
    constraint verification. Once the constraint violation is detected,
    the digital twin agent changes its simulation and automatic
    evacuation action is executed via the social relations graph.
    Dynamic re-planning and re-verification is executed as new
    constraints are discovered (e.g., aftershock occurs or blocked route)
    for the real and virtual agents. Real-time data from operation feeds
    embodied disaster response model.

  5.3. Autonomous Driving Systems in Smart City

  5.3.1. Multi-Vehicles(Agents) Collaborative Delivery

    The fleet of autonomous delivery robots and drones across urban
    environment with dynamic obstacle avoidance and resource sharing is
    a multi-agents coordination. Each delivery vehicle is a Composite
    Agent including: high-level mission planner, the physical vehicle
    with sensors/actuators and virtual-entity agent for route
    optimization and simulation. The production Relations graph is like:
    Fleet management center coordinating individual vehicles peer
    relations between vehicles for resource negotiation hierarchical
    override for emergency situations.

    The virtual-entity agent simulates route with physical feasibility
    check. The production relations graph queries nearby vehicles for
    resource sharing opportunities and coordination sessions are
    established. The real-entity agent executes with continuous
    constraint monitoring and trigger dynamic re-planning when when the


      zhang                  Expires 20,April,2026                [Page 18]


      Internet-Draft          RVP Problem Statement             October 2025


    constraint violates (e.g., unexpected obstacle, battery drain,
    etc...). The execution data (actual vs. predicted energy consumption,
    obstacle patterns) feeds the autonomous driving model via RVP.

   5.3.2. Vehicle-to-Everything (V2X) Intersection Management

    Consider an intelligent intersection with autonomous V2X vehicles,
    human-driven V2X vehicles, cyclists, and pedestrians without
    traditional traffic signals.

    Once the vehicle approaches intersection, it registers it vehicle
    capabilities (e.g., size, braking distance, speed range and V2X
    information) and discovers intersection controller via RVP. The
    intersection controller establishes coordination sessions based on
    the physical relations graph among the vehicles. The virtual-entity
    agents simulate safe crossing sequences with physical constraint
    verification where physical safety constraints are the primary
    protocol feature to be checked, not afterthought. The Safety
    constraints like minimum time gaps, line-of-sight requirements,
    pedestrian priority are checked. The V2X vehicle, cyclist,
    pedestrian with smartphone receive crossing permissions with timing
    constraints via RVP. Continuous safety monitoring is executed and
    constraint violations trigger RVP protocols usage.

  6. Security Considerations

  6.1. Identity Verification and Authorization

    Composite Identity Verification Not only verify digital identity but
    also verify physical identity, ensuring authenticity of unified
    identity.

      Digital Identity: OAuth 2.0 tokens, API keys

      Physical Identity: Device fingerprinting, TPM attestation, secure
    elements

      Composite Binding: Cryptographic binding between physical and
    digital credentials

    Multi-factor Authentication for critical operations, require multi-
    factor authentication, including physical tokens or biometrics
    tokens:

      Level 1 (routine operations): Single factor (token/certificate)

      Level 2 (sensitive operations): Two factors (token + OTP)


      zhang                  Expires 20,April,2026                [Page 19]


      Internet-Draft          RVP Problem Statement             October 2025


      Level 3 (critical operations): Three factors (certificate +
    biometric + physical token)

    Authorization Based on Relations Graph

     Utilize physical/social/production relations graph for dynamic
     permission calculation, considering relations type, path length,
     time validity, etc.

  6.2. Communication Security

    End-to-End Encryption

    Use TLS 1.3 or higher for transport encryption, and apply
    application-layer end-to-end encryption for sensitive data.

    Message Integrity

    Use digital signatures to ensure message integrity and prevent
    tampering.

  6.3. Safety System Protection

    Independent Safety Channels

    Physical safety systems (such as emergency stop) use communication
    channels independent of coordination protocols.

    Physical-Digital Boundary Protection

    Deploy safety gateways between physical and digital domains for
    protocol filtering and deep inspection.

    Gateway functions include:

      Message content inspection and validation

      Rate limiting and anomaly detection

      Whitelist-based operation filtering

      Constraint verification before physical execution

  6.4. Audit and Monitoring

    Comprehensive Logging Record: Detailed logs of all coordination
    sessions, including message content, participants, timestamps, etc.


      zhang                  Expires 20,April,2026                [Page 20]


      Internet-Draft          RVP Problem Statement             October 2025


  6.5. Isolation Capabilities

    Dynamic Isolation: Based on security events, dynamically isolate
    affected entities or coordination domains.

  7. IANA Considerations

    This document requests IANA to establish new registries for RVP
    protocol parameters. More details are in further versions.

  8. References

  8.1. Normative References

    [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

  8.2. Informative References

    [A2A-SPEC] https://a2a-protocol.org/dev/specification/

    [A2A-FIPA] Foundation for Intelligent Physical Agents, "FIPA Agent
                Communication Language Specifications", 2002.

    [MCP-SPEC] Anthropic, "Model Context Protocol Specification", 2024.

    [ANP-SPEC] "Agent Network Protocol Technical White Paper",
                https://arxiv.org/pdf/2508.00007, 2025.

    [RFC7252] Shelby, Z., Hartke, K., and C. Bormann, "The Constrained
              Application Protocol (CoAP)", RFC 7252, June 2014.

    [SMART-FACTORY] https://www.globaltrademag.com/smart-factories-how-
                     technology-is-revolutionizing-manufacturing/.

    [AI-CITY] https://www.deloitte.com/content/dam/assets-
              shared/docs/industries/government-public-services/2025/ai-
              powered-cities-of-the-future.pdf.

    [APOLLO]  https://www.apollo.auto/en/apollo-self-driving.

    [Human-Robot] Dong, W., "Toward Embodied Intelligence-Enabled Human-
              Robot Symbiotic Manufacturing: A Large Language Model-
              Based Perspective",Journal of Computing and Information
              Science in Engineering, May 2025.




      zhang                  Expires 20,April,2026                [Page 21]


      Internet-Draft          RVP Problem Statement             October 2025


    [DIGITAL-TWINS] Grieves, M., "Digital Twin: Manufacturing Excellence
              through Virtual Factory Replication", Digital
              Manufacturing, 2014.

    [CPS-DESIGN] Lee, E., "Cyber Physical Systems: Design Challenges",
              University of California, Berkeley Technical Report, 2008.

    [STI-BENCH] Li, Y., "STI-Bench:Are MLLMs Ready for Precise Spatial-
              Temporal World Understanding?", ICCV 2025.

    [DATA-RUNOUT] Villalobos,P.,Will we run out of data? Limits of LLM
              scaling based on human-generated data,
              https://arxiv.org/pdf/2211.04325.



  9. Acknowledgments

    The authors thank Dirk Dressler who provided valuable feedback
    during the development of this specification.




























      zhang                  Expires 20,April,2026                [Page 22]


      Internet-Draft          RVP Problem Statement             October 2025


      Authors' Addresses


    Xiaoxun Zhang
    Hicagent
    No.57 Boxia Road, Pudong Software Park,Shanghai, P.R.China
    zhangxiaoxun@hicagent.com

    Yunfei Zhang(Editor)
    China Telecom
    No.31 Jinrong Street, Xicheng District,Beijing, P.R.China
    Zhangyf80@chinatelecom.cn

    Chi Zhang
    China Telecom
    No.31 Jinrong Street, Xicheng District,Beijing, P.R.China
    Zhangc120@chinatelecom.cn

    Min Zhang
    China Telecom
    No.31 Jinrong Street, Xicheng District,Beijing, P.R.China
    Zhangmin3@chinatelecom.cn


    Weijun Lu
    SUPCON  TECHNOLOGY  CO., LTD.
    No.309 Liuhe Road, BinJiang District, Hangzhou,Zhejiang, P.R.China
    luwj@supcon.com




















      zhang                  Expires 20,April,2026                [Page 23]



