Agent Communication Protocols J. Rosenberg Internet-Draft jdrosen.net Intended status: Standards Track 2 November 2026 Expires: 6 May 2027 The Agentic Session Initiation Protocol (A-SIP) draft-rosenberg-agentproto-asip-00 Abstract The Agentic Session Initiation Protocol (A-SIP) is used for the establishment and lifecycle maintenance of agentic dialogs. It also enables and content exchange between a principal and an AI Agent over the Internet. A-SIP can be used between a user agent and AI Agent, between AI Agents, or between an AI Agent and a tool with agentic- like properties. A-SIP is built ontop of HTTP/3, web transport and Media Over Quic Transport (MOQT), leveraging a modern, public-cloud friendly protocol stack. Its usage of MOQT is optional, needed only when real-time media is exchanged. This allows asynchronous agent interactions to be done entirely using HTTP/3, so simple cases remain simple. Despite the name, A-SIP has no technical relationship with SIP (RFC3261). This document is not yet a fully fleshed out protocol, and is meant to solicit feedback on this general direction of work. 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://jdrosen.github.io/draft-rosenberg-agentproto-asip/draft- rosenberg-agentproto-asip.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-rosenberg- agentproto-asip/. Discussion of this document takes place on the Agent Communication Protocols Working Group mailing list (mailto:agentproto@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ agentproto. Subscribe at https://www.ietf.org/mailman/listinfo/ agentproto/. Source for this draft and an issue tracker can be found at https://github.com/jdrosen/draft-rosenberg-agentproto-asip. Rosenberg Expires 6 May 2027 [Page 1] Internet-Draft A-SIP November 2026 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 2027. 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 4 3. Guiding Principles . . . . . . . . . . . . . . . . . . . . . 4 3.1. Media and Signaling Easily Multiplexed . . . . . . . . . 4 3.2. Built on HTTP and OAuth . . . . . . . . . . . . . . . . . 5 3.3. Signaling via Web API . . . . . . . . . . . . . . . . . . 5 3.4. Distributed Inference is Possible . . . . . . . . . . . . 5 3.5. Simple Things, should be Simple . . . . . . . . . . . . . 6 3.6. Can Also be Used for Human to Human Sessions . . . . . . 6 4. Protocol Stack . . . . . . . . . . . . . . . . . . . . . . . 7 5. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 7 5.1. Identifying an Agent . . . . . . . . . . . . . . . . . . 7 5.2. Authenticating and Authorizing the Principal . . . . . . 8 5.3. Retrieving Agent Capabilities . . . . . . . . . . . . . . 8 5.4. Creating an Agentic Dialog . . . . . . . . . . . . . . . 9 Rosenberg Expires 6 May 2027 [Page 2] Internet-Draft A-SIP November 2026 5.5. Establishing the MOQT Session . . . . . . . . . . . . . . 9 5.6. Establishing Subscriptions . . . . . . . . . . . . . . . 10 5.7. Content Exchange . . . . . . . . . . . . . . . . . . . . 10 5.8. The Log . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.9. Pausing, Resuming and Reconnecting . . . . . . . . . . . 11 6. The Agent Resource . . . . . . . . . . . . . . . . . . . . . 12 6.1. Agent Capabilities Resource . . . . . . . . . . . . . . . 12 6.1.1. Voice Capabilities . . . . . . . . . . . . . . . . . 13 6.1.2. Video Capabilities . . . . . . . . . . . . . . . . . 13 6.1.3. Chat Capabilities . . . . . . . . . . . . . . . . . . 14 6.2. Creating an Agentic Dialog . . . . . . . . . . . . . . . 15 7. Dialog Context Resource . . . . . . . . . . . . . . . . . . . 16 8. AI Authorship Disclosures . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 20 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction The widespread usage of AI Agents on the Internet has introduced new forms of networked communications. User agent clients connect to AI agents running elswehere, AI agents communicate with other AI agents, and AI agents communicate with tools. All three of these interaction patterns - and the many use cases therein - require a session-like protocol which handles lifecycle management, including creation, modification, deletion and so on - along with the exchange of input and output. These session-like associations can be extremely long lived - running for hours or even days - and span multiple IP hosts used by the both the principal and by the agent. They can also be highly intermittent with asynchronous responses. All of these mean a new type of protocol is needed. These differ from the type of sessions created by the Session Initiation Protocol (SIP) [RFC3261], which are shorter lived and work between a single IP host for each participant. In [I-D.manyfolks-agentproto-arch], an architecture is presented for AI Agent networked communications. It introduces the concept of an agentic dialog, which is defined as an association between two parties - a principal whose role is to provide input to, and receive output from, an agent - and the agent, which is running a process which has properties which are agentic in nature. The agentic properties that are relevant here are (1) conversational contuity, and (2) driven by natural language in each direction. Rosenberg Expires 6 May 2027 [Page 3] Internet-Draft A-SIP November 2026 This document defines a protocol that can play the role of the Agent Communications Protocol (ACP) which is defined abstractly in that document. The protocol defined here - the Agentic Session Initiation Protocol (A-SIP) - provides for the establishment and lifecycle maintenance of agentic dialogs. It also enables and content exchange between a principal and an agent, over any IP network, including the Internet. A-SIP is built ontop of HTTP/3 [RFC9114] web transport [I-D.ietf-webtrans-http3] and Media Over Quic Transport (MOQT) [I-D.ietf-moq-transport]. This document does not yet provide a fully fleshed out protocol specification. It has sufficient detail to give the general idea of how it works, along with details for basic happy path. This document is meant to solicit input and feedback on this general direction of work. 2. Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Guiding Principles The protocol stack defined in this document is based on a set of guiding principles which are important to understand. 3.1. Media and Signaling Easily Multiplexed The core functionality that A-SIP needs to provide combines traditional signaling (estabishment of an agentic dialog, negotiation of supported modalities, termination of the agentic dialog, and so on) and exchange of media (real-time voice, video, images, and text). This exact problem is solved by SIP [RFC3261]. However, SIP had a separation between the signaling and media. The media was transported using the Real-Time Transport Protocol (RTP) [RFC3550], and ran on a separate UDP connection, using a different IP and port. This design was sensible at the time SIP was conceived, but over time, using a separate connection for media and signaling proved to be incredibly problematic. The biggest problem is that it made it extremely difficult to run SIP in public cloud environments. IP addresses are often transient, unknown to their hosts, and unreachable through public cloud routing and load balancing. It made it difficult to run SIP servers on kubernetes. It complicated network and firewall configuration. Rosenberg Expires 6 May 2027 [Page 4] Internet-Draft A-SIP November 2026 As a result of these lessons, A-SIP is designed to run on a single connection (in this case, a QUIC [RFC9000] connection). This connection multiplexes both the signaling and media over the same connection. Affordances are made for communication that is needed outside of the lifetime of the connection itself - needed only for long-lived agentic dialogs that span hours or days - as an optional protocol feature. 3.2. Built on HTTP and OAuth HTTP and OAuth are the foundation of the modern Internet. If you want to build a new cloud-based application, doing it as an HTTP application is a given. Much of public cloud infrastructure is designed around supporting web-based applications, with significant investments made in scaled load balancers, firewalls, proxies and similar componentry. Developer tools exist in large volume, everything from curl to postman to OpenAPI YAML and so on. By building ontop of HTTP, A-SIP inherits this technology stack, facilitating its ease of development and deployment on the modern Internet. 3.3. Signaling via Web API A natural consequence of the principal of building off of HTTP, is to make use of web APIs. An agentic dialog is an HTTP-based web resource which can be queried by a GET, modified with a POST, and removed with a DELETE. This makes it simple to specify and implement. A web API works for A-SIP because the agentic protocol is foundationally assymetric, as discussed in [I-D.manyfolks-agentproto-arch]. The protocol involves one entity (the principal) requesting the services of another (the agent). The agent takes responsibility for state management - specifically the agentic context defined in that document. This makes a web API a good fit for those aspects of the protocol. The web API can also be used for async content exchange, and (in a pinch) even used for voice and video - but it is insufficient for real-time. 3.4. Distributed Inference is Possible To scale, modern AI Agent providers make use of distributed inference, wherein a particular input from a user may generate inference on one set of compute resources, and then a different set serves the next input. This is all transparent to the user. We would like to make sure that the agent protocol works well in these cases. Rosenberg Expires 6 May 2027 [Page 5] Internet-Draft A-SIP November 2026 The implication on the protocol design is that we want the ability to route user input to different places without requiring the principal to do anything different - invisibly to them. It also means that the output can come from different hosts and be routed to the principal - also invisibly to the principal and its client. This is resolved in A-SIP by allowing the agent to make use of a MOQT relay network, sending the exchanged content through the relay rather than to the server terminating the original HTTP connection from the client. 3.5. Simple Things, should be Simple The use cases for AI Agent communications is large, covering multiple interaction patterns and multiple media modalities. It needs to support text chat, image and video exchange, structured data exchange, voice messaging, and real-time voice and video. It needs to support AI agent sessions which last seconds, but also sessions which last hours or days. In reality, most implementations and AI Agents will only support a subset of these. Indeed, the most common use case is likely to only require asynchronous text-chat, with occasional inclusion of other media types in the async chat, with a duration spanning a few minutes or hours, all from a single host. This is the predominant use case for AI Agents today. There is no real-time voice or video in many of these agents. As a result, our goal is to make the protocol simple to deploy and use for use cases that don't require advanced features, and then make use of harder-to-deploy and harder-to-implement protocol elements for the more advanced features. Two features in particular are advanced in A-SIP - (1) exchange of real-time media, and (2) notifications of agent output that are generated when no connection is active. Both of these make use of MOQT, which ideally suited for both. 3.6. Can Also be Used for Human to Human Sessions A key goal of A-SIP is that - even though it is targeting the communication patterns between a human principal and an AI Agent (or between AI Agents), the protocol applies equally well to establish communications between two humans, allowing them to exchange voice, video or chat. In this regard, this is a spiritual successor of sorts to SIP [RFC3261]. Rosenberg Expires 6 May 2027 [Page 6] Internet-Draft A-SIP November 2026 4. Protocol Stack The A-SIP protocol stack is shown in Figure 1. A-SIP signaling (the web API used to create, query, modify and delete agentic dialogs) and asynchronous content exchange run directly over HTTP/3 [RFC9114]. The advanced features - real-time media (including text) and notifications of agent output generated when no connection is active - are optional, and are carried by MOQT [I-D.ietf-moq-transport] running over WebTransport [I-D.ietf-webtrans-http3], which itself runs over HTTP/3. In all cases, signaling and media are multiplexed over a single QUIC [RFC9000] connection. +-------------------------------------------------------+ | A-SIP | +---------------------------+---------------------------+ | Signaling (Web API) | Real-Time Media and | | and Async Content | Offline Notifications | | Exchange | (optional) | | +---------------------------+ | | MOQT | | +---------------------------+ | | WebTransport | +---------------------------+---------------------------+ | HTTP/3 | +-------------------------------------------------------+ | QUIC | +-------------------------------------------------------+ | UDP | +-------------------------------------------------------+ | IP | +-------------------------------------------------------+ Figure 1: A-SIP Protocol Stack 5. Protocol Overview This section is non-normative and provides an overview of A-SIP. 5.1. Identifying an Agent An AI Agent is named with an HTTPS URI (e.g., https://example.com/agents/booking). A GET against this resource retrieves a capability document, discussed below. A POST creates a new agentic dialog. Rosenberg Expires 6 May 2027 [Page 7] Internet-Draft A-SIP November 2026 5.2. Authenticating and Authorizing the Principal A-SIP relies entirely on OAuth [RFC6749]. If the principal is a human user, it would obtain an access token through any of the OAuth grant flows that the agent provider wishes to support. If the principal is an AI Agent, such as in the Agent- to-Agent to Agent-to-Tool cases, the usage of the newly proposed AAuth grant flow [I-D.rosenberg-oauth-aauth] is suggested. 5.3. Retrieving Agent Capabilities A GET against the AI agent URI resource provides a description of the agent, including its support for A-SIP and its allowed modalities (voice, video, or chat). We call this the agent capabilities document. The document also indicates other capabilities that are optional to support by this specification. Importantly, for each modality declared in the agent capabilities document, the agent can indicate whether or not MOQT is supported for exchange of content for this modality. The capabilities document for each modality also indicates other information needed for establishment of a dialog with that modality. In the case of voice and video, it indicates supported codecs. Standard ones come from the W3C WebCodec registry [W3CRegistry]. In the case of chat, the capabilities include the list of supported MIME types which may be exchanged. In this regard, "chat" really refers to the asynchronous exchange of content, and is not at all restricted to text. All agents are required to support "text/plain". Support can be declared for processing of images - for example - by indicating support for one of the image types (e.g., "image/jpeg" which is required for any agent that can handle images). The capability declaration indicates whether or not the agent can support receiving content of that type, sending content of that type, or both. The capabilities document also indicates whether the agent supports the ability to convey informational elements. These include tool call requests and responses, sub-agent invocations, and so on. Similarly, the capabilities document indicates whether the agent supports the ability to convey progress signaling. The capabilities of the agent - and its corresponding capabilities document - are anticipated to be relatively static, and thus cacheable. Rosenberg Expires 6 May 2027 [Page 8] Internet-Draft A-SIP November 2026 5.4. Creating an Agentic Dialog To create a new agentic dialog, the principal performs a POST against the agent URI. The body contains a JSON object called an agentic dialog creation request. It includes the desired modalities, and for each, the selected capabilities. These must be a subset of the supported capabilities of the agent. A request to create an agentic dialog with features or modalities not supported by the agent is rejected. The agentic dialog creation request also indicates, for each modality, whether or not the client wants to use MOQT for content exchange - assuming it was supported by the server. For chat, the client can elect to skip MOQT and instead use the web API to send (and retrieve) content, using the log API endpoints described below. The agentic dialog creation request also indicates whether the client wants to receive information output or progress signaling. The result that comes back is the dialog context meta-data. It includes the Agentic Dialog Identifier (ADID) in the JSON payload, and further operations happen against its URI (e.g. https://example.com/agents/booking/agentic-dialogs/01a198c7-ab2f- 753f-9a6a-67b204b16994). Importantly, if MOQT is used for the exchange of content for a particular modality, the agentic dialog resource specifies the full track names to be used in each direction. In A-SIP, the full track name is always selected by the server, not the client. In addition, the server can optionally provide a MOQT URI that the client should use for the session. If the client requested receipt of information output and progress signaling, MOQT track names are provided for those in the agentic dialog resource. 5.5. Establishing the MOQT Session For a given modality, A-SIP allows for several supported exchange techniques: 1. No MOQT: Used only for chat. In this mode of A-SIP, content is sent from client to server through web API calls noted below. Content from server back towards the client is received through polling. 2. Connection shared MOQT: The HTTP connection used for the web API is reused for content exchange, using webtransport to multiplex. Rosenberg Expires 6 May 2027 [Page 9] Internet-Draft A-SIP November 2026 3. Relayed MOQT: A separate MOQT over webtransport connection is created, targeting the URI defined in the agentic dialog resource. The case to be used for each modality is indicated in the agentic dialog resource. When relayed MOQT is used, it contains a distinct MOQT URI used for the exchange. Its absence signals using connection shared MOQT. Based on the signaling agentic dialog exchange technology, the client proceeds to set it up. For connection shared MOQT, the client establishes a webtransport session over the HTTP connection, and uses the result for MOQT. Otherwise, it creates a new connection using webTransport towards the URI provided. Note that A-SIP does not support MOQT directly over QUIC, it is always over webTransport. 5.6. Establishing Subscriptions If MOQT (connection shared or relayed) is in use, the client performs a SUBSCRIBE to the track that the server is using to deliver content, enabling it to receive real-time updates. SImilarly, the server SUBSCRIBEs to the track that the client will use to deliver content. Multiple subscriptions are carried over the same MOQT connection whenever possible. In the case where MOQT is not used, no subscriptions are used. 5.7. Content Exchange Voice and video Content is exchanged using MOQs' Low Overhead Media Containers (LOC) [I-D.ietf-moq-loc] which encapsulate WebCodec [WebCodec]. These are published by each side using standard MOQT procedures. For chat, if MOQT is used for the exchange, the MIME type is directly encapsulated into the MOQT payload (OPEN ISSUE - is further encapsulation needed?). When MOQT is not used, the client adds the content by posting to the log, and retrieves it by polling against the log. 5.8. The Log As noted in [I-D.manyfolks-agentproto-arch] - the dialog context includes the log. The log is an append-only record of the input to, and output from, the AI Agent. Each entry in the log has an ID. Rosenberg Expires 6 May 2027 [Page 10] Internet-Draft A-SIP November 2026 The client can retrieve log entries by a GET request against the log: GET example.com/{agentPath}/agentic-dialogs/{adid}/log This resource supports filtering and pagination features against time, allowing the client to catch up against items it missed (OPEN ISSUE - it would be nice if these IDs were the object IDs in MOQT, which have the property that they increase over time. However they are only unique within the group, and we want the above API to retrieve objects across the tracks). The client can append to this log by POSTing against it, which adds to the content of the chat modality. (OPEN ISSUE - allow voice or video too?). The log contains all input and output, including progress signaling and information output. Filters exist so that the client can retrieve only input, only output, or selected types of output (e.g., response output only). Polling to retrieve output is clearly suboptimal. A-SIP specifies rate limiting negotiation, allowing the server to control pacing. If clients want responses faster, they need to make use of the MOQT transport. 5.9. Pausing, Resuming and Reconnecting A-SIP allows an agentic dialog to be paused. A paused agentic dialog means that the agent is no longer running inference, and is awaiting further input which can come at another time, potentially a long time from now. To pause a dialog, there is a pause command ":pause" issued as a POST against the agentic dialog resource: POST https://example.com/agents/booking/agentic-dialogs/01a198c7-ab2f-753f-9a6a-67b204b16994:pause This operation allows any inference in-progress to complete, and the results of it returned over the existing connection. Once done, the state of the dialog context moves to "PAUSED", and this state change is conveyed over the MOQT notification topic. At that point, the client can close the connection entirely, ending the MOQT session and the HTTP connection in which it resides. Rosenberg Expires 6 May 2027 [Page 11] Internet-Draft A-SIP November 2026 If the client abruptly ends the HTTP/3 connection, it has the same effect as an explicit pause operation. The AI Agent will complete inference in progress, and add the results to the log. Without an active connection, the results cannot be communicated to the principal. However, it can retrieve them via the log when it resumes. To resume, the client need only create a new connection by initiating an HTTP POST operation like this: POST https://example.com/agents/booking/agentic-dialogs/01a198c7-ab2f-753f-9a6a-67b204b16994:resume The response contains the current dialog context, which contains the necessary information (e.g., track names) to create a new MOQ connection (assuming muxing is used). Typically the same track names are used across pauses and resumptions - and across reconnections. This means that, using MOQT subscriptions that reference the last group that the client received, it can "catch-up" via MOQT. If MOQT is not used, querying the log with query filters accomplishes the same goal. This works independent of whether the MOQT session is multiplexed over the HTTP connection or accessed via a separate connection. The server will only allow resumption from the same principal identified in th The resume command also works against an active agentic dialog, making this operation idempotent. OPEN ISSUE - there is a subtle distinction between "stop running inference" and "i'm not here anymore to get the results, so stop once you get to the point where you need my input". Do we need to support both modes? And which one is implied by a connection termination? 6. The Agent Resource The agent resource is the root of the resource hierarchy. The URI can be any valid HTTPS URI. The means by which the principal discovers this URI is outside of the scope of this specification. 6.1. Agent Capabilities Resource A GET upon the agent resource returns the agent capabilities resource. This is a JSON document with the following fields: * URI: The URI associated with the agent resource (required) Rosenberg Expires 6 May 2027 [Page 12] Internet-Draft A-SIP November 2026 * version: The version of the agent, expressed as "X.Y" where X and Y are major and minor version numbers, which must each be a positive integer less than 65535. (required) * voice: if real-time voice is supported, the voice capability object is included. If it is not supported, it is omitted. * video: if real-time video is supported, the video capability object is included. If it is not supported, it is omitted. * chat: if chat - which includes a range of media types exchanged in an async, turn-by-turn fashion - is supported, the chat capability object is included. If it is not supported, it is omitted. 6.1.1. Voice Capabilities The voice capabilities object in the JSON includes the following fields: * codecs: An array of strings. This field is required, and MUST be non-empty. Each entry MUST be a valid voice codec string from the W3C WebCodecs registry. All clients and all servers that support voice, MUST support Opus (codec string: "opus"). Other codecs MAY be supported. * moqt: A boolean (optional). If true, it indicates that the agent supports moqt transport for the voice. If absent, the default is "true". (OPEN ISSUE: I'm not so sure about this default or even allowing non-MOQT voice...). * muxed: A boolean (optional). If true, it indicates that the agent supports the ability to multiplex the MOQT session over the same HTTP/3 connection used for the web API. The default is true. 6.1.2. Video Capabilities The video capabilities object in the JSON includes the following fields: * codecs: An array of strings. This field is required, and MUST be non-empty. Each entry MUST be a valid video codec string from the W3C WebCodecs registry. All clients and all servers that support video, MUST support AV1 (codec string: "av01"). Other codecs MAY be supported. Rosenberg Expires 6 May 2027 [Page 13] Internet-Draft A-SIP November 2026 * moqt: A boolean (optional). If true, it indicates that the agent supports moqt transport for the video. If absent, the default is "true". (OPEN ISSUE: I'm not so sure about this default or even allowing non-MOQT video...). * muxed: A boolean (optional). If true, it indicates that the agent supports the ability to multiplex the MOQT session over the same HTTP/3 connection used for the web API. The default is true. OPEN ISSUE - other video codec capabilities we need to signal? 6.1.3. Chat Capabilities The chat capabilities object in the JSON includes the following fields: * principal-to-agent: An array, each entry containing a string that is a valid IETF MIME type. This list MUST be non-empty and MUST include "text/plain". These indicate the types that the AI agent is able to receive. * agent-to-principal: An array, each entry containing a string that is a valid IETF MIME type. This list MUST be non-empty and MUST include "text/plain". These indicate the types that the AI agent is able to send. An agent capable of processing image input would include at least one image MIME type in the principal-to-agent array. If it supports such input, then "image/jpeg" MUST be listed, ensuring a baseline image capability. Note that "text/plain" is a fairly broad type, and depending on the flow of the conversation, the AI agent may actually emit any number of structured outputs, such as code, JSON, or what have you. For this reason, an AI agent doe not need to explicitly declare support for structured data types that are encoded with text. For example, there is no need to declare support for "text/csv". Along similar lines, the chat capabilities document SHOULD NOT list any application MIME types, unless the harness (as opposed to the LLM) has explicit capabilities to recognize and parse them. The assumption is that any text-based format is likely to be understood by the LLM, and will passed transparently to the LLM by the harness. This means that a traditional, text-based LLM that has no multimodal support, only needs to declare support for "text/plain" in both directions. Rosenberg Expires 6 May 2027 [Page 14] Internet-Draft A-SIP November 2026 6.2. Creating an Agentic Dialog To create an agentic dialog, the client performs a POST against the agent resource. The body MUST contain an agentic dialog creation request. The agentic dialog creation request has the following fields: * voice: present if the client is requesting a real-time voice modality. This MUST NOT be present if the agent capabilities didn't indicate support for it. * video: present if the client is requesting a real-time video modality. This MUST NOT be present if the agent capabilities didn't indicate support for it. * chat: present if the client is requesting a real-time video modality. This MUST NOT be present if the agent capabilities didn't indicate support for it. The voice object has the following fields: * codec: This is a single string, defining the codec in use for the real-time voice exchange. It MUST be one of the ones listed in the capabilities. * moqt: Boolean. True means that moqt transport is to be used. MUST be true only if the agent indicated support for moqt. * muxed: Boolean. True means that the moqt transport is to be muxed with the HTTP connection. MUST be true only if the agent indicated support for this. The same fields present in the video object, but refer to video. For the chat object, the fields mirror those in the capabilities object: * principal-to-agent: the MIME types that the principal plans to send. These MUST be a subset of those indicated in the capabilities document. * agent-to-principal: The MIME types that the principal is capable of receiving. These MUST be a subste of those indicated in the capabilities document. Rosenberg Expires 6 May 2027 [Page 15] Internet-Draft A-SIP November 2026 Upon receipt of this API call, the server MUST authorize the request using OAUth2.0 [RFC6749], and validate that the requested agentic dialog is within the capability set supported by the agent. It is worthwhile to note that the negotiation technique defined here differs from the offer/answer mechanism specific for SIP in [RFC3264]. That mechanism proved problematic over time, since it mixed relatively static capability, with run-time configuration, with connection information. In A-SIP, these are cleanly separated. The response from the server contains a dialog context object. This object is defined in the next section. 7. Dialog Context Resource The dialog context resource is addressed by an HTTPS URI, and it represnets the current state of the agentic dialog. Note that this does not include the log per se, but it does include a timestamp which represents the most recent log entry. The dialog context object has the following fields: * adid: The agentic dialog ID. This MUST be a type 7 UUID, and be unique in space and time. * uri: The URI that identifies this agentic dialog * notifications: This is an object that is used to provide notifications of state changes that are server initiated. It is also used to support delivery of notifications through a MOQ relay network, useful for cases where the client is offline for more extended periods of time and is waiting for notification of update. Details are TBD. * voice: Present if the agentic dialog incldues real-time voice. * video: Present if the agentic dialog incldues real-time video. * chat: Present if the agentic dialog incldues chat. * state: The current state of the agentic dialog. It is one of ACTIVE, PAUSED, or COMPLETED. * latest-log: A timestamp representing the most recent entry in the log. The voice and video objects have a similar structure: Rosenberg Expires 6 May 2027 [Page 16] Internet-Draft A-SIP November 2026 * agent-to-principal: This describes the session between the agent and principal * principal-to-agent: This desribes the session between the principal and agent Both of these also have the same structure, as they contain: * codec: The codec in use * moqt: Boolean, indicating whether moqt is in use * muxed: Boolean, indicating whether the moqt session is muxed over the HTTP connection or separate * track: The full name of the track * uri: The MOQT URI to use for the connection; only present if the muxed field is false. An example of a dialog context object for voice might look like this: Rosenberg Expires 6 May 2027 [Page 17] Internet-Draft A-SIP November 2026 { "adid": "01a198c7-ab2f-753f-9a6a-67b204b16994", "uri": "https://example.com/agents/booking/agentic-dialogs/01a198c7-ab2f-753f-9a6a-67b204b16994", "state": "ACTIVE", "latest-log": "2026-11-02T14:23:07.512Z", "notifications": { "uri": "https://relay.example.net/moq", "track": { "namespace": [ "example.com", "booking", "01a198c7-ab2f-753f-9a6a-67b204b16994" ], "name": "notifications" } }, "voice": { "principal-to-agent": { "codec": "opus", "moqt": true, "muxed": true, "track": { "namespace": [ "example.com", "booking", "01a198c7-ab2f-753f-9a6a-67b204b16994" ], "name": "voice-in" } }, "agent-to-principal": { "codec": "opus", "moqt": true, "muxed": true, "track": { "namespace": [ "example.com", "booking", "01a198c7-ab2f-753f-9a6a-67b204b16994" ], "name": "voice-out" } } } } Rosenberg Expires 6 May 2027 [Page 18] Internet-Draft A-SIP November 2026 8. AI Authorship Disclosures This document was written entirely by hand, except for the example JSON document and the protocol stack diagram, which were generated with genAI assistance. 9. Security Considerations TODO Security 10. IANA Considerations This document has no IANA actions. 11. References 11.1. Normative References [I-D.ietf-moq-loc] Zanaty, M., Nandakumar, S., and P. Thatcher, "Low Overhead Media Container", Work in Progress, Internet-Draft, draft- ietf-moq-loc-05, 2 November 2026, . [I-D.ietf-moq-transport] Nandakumar, S., Vasiliev, V., Swett, I., and A. Frindell, "Media over QUIC Transport", Work in Progress, Internet- Draft, draft-ietf-moq-transport-23, 2 November 2026, . [I-D.ietf-webtrans-http3] Frindell, A., Kinnear, E., and V. Vasiliev, "WebTransport over HTTP/3", Work in Progress, Internet-Draft, draft- ietf-webtrans-http3-17, 2 November 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . Rosenberg Expires 6 May 2027 [Page 19] Internet-Draft A-SIP November 2026 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . [RFC9114] Bishop, M., Ed., "HTTP/3", RFC 9114, DOI 10.17487/RFC9114, June 2022, . [W3CRegistry] W3C, "WebCodecs Codec Registry", 2026, . [WebCodec] W3C, "WebCodecs", 2026, . 11.2. Informative References [I-D.manyfolks-agentproto-arch] Rosenberg, J., Sarker, Z., Reddy.K, T., Yao, K., Liu, D., and S. Krishnan, "Architecture for AI Agent Communications on the Internet", Work in Progress, Internet-Draft, draft- manyfolks-agentproto-arch-00, 30 October 2026, . [I-D.rosenberg-oauth-aauth] Rosenberg, J. and P. White, "AAuth - Agentic Authorization OAuth 2.1 Extension", Work in Progress, Internet-Draft, draft-rosenberg-oauth-aauth-02, 1 November 2026, . [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, July 2002, . [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with Session Description Protocol (SDP)", RFC 3264, DOI 10.17487/RFC3264, July 2002, . Rosenberg Expires 6 May 2027 [Page 20] Internet-Draft A-SIP November 2026 [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, . Acknowledgments TODO acknowledge. Author's Address Jonathan Rosenberg jdrosen.net Email: jdrosen@jdrosen.net Rosenberg Expires 6 May 2027 [Page 21]