DMSC H. Yang Internet-Draft AsiaInfo Technologies (China) Inc. Intended status: Informational G. Dong Expires: 1 January 2027 China Telecom L. Zhang Y. Li S. Wang AsiaInfo Technologies (China) Inc. 30 June 2026 Semantic Layer for AI Agent Gateways in Gateway-mediated Collaboration draft-yang-dmsc-gateway-semantic-layer-01 Abstract Cross-domain and policy-controlled agent collaboration can require semantic decisions that are not always suitable for an agent client or an agent server alone. A collaboration request may need to combine business intent, capability meaning, tenant or domain policy, trust evidence, disclosure limits, operational constraints, and handoff context before a concrete interaction mechanism is used. This document identifies such gateway-side semantic decision-making as a distinct interoperability gap in many AI Agent Gateway deployments. It does not claim that every agent collaboration requires a gateway. Rather, it explains why many deployments need a mediation point where intent, capability meaning, policy, trust, and handoff constraints can be evaluated before interaction proceeds. The document describes a Gateway Semantic Layer as a decision layer between application-level intent and concrete agent interaction mechanisms. It focuses on the role, inputs, outputs, and narrow set of interoperable artifacts that may require further work, such as Resolution Results, Handoff Descriptors, Failure Explanations, and related references. 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/. Yang, et al. Expires 1 January 2027 [Page 1] Internet-Draft Gateway Semantic Layer June 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 1 January 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 4. Applicability to AI Agent Gateway Standardization . . . . . . 6 5. 3GPP Service Requirements as Semantic Decision Drivers . . . 7 6. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . . . 9 7. Position in a DMSC Gateway Architecture . . . . . . . . . . . 10 8. Inputs to Gateway Semantic Resolution . . . . . . . . . . . . 11 8.1. Business Intent . . . . . . . . . . . . . . . . . . . . . 12 8.2. Task Context . . . . . . . . . . . . . . . . . . . . . . 12 8.3. Capability Descriptions . . . . . . . . . . . . . . . . . 12 8.4. Policy Constraints . . . . . . . . . . . . . . . . . . . 12 8.5. Trust Evidence . . . . . . . . . . . . . . . . . . . . . 12 9. Gateway Semantic Operations . . . . . . . . . . . . . . . . . 12 10. Outputs of the Gateway Semantic Layer . . . . . . . . . . . . 13 10.1. Resolution Result . . . . . . . . . . . . . . . . . . . 13 10.2. Handoff Descriptor . . . . . . . . . . . . . . . . . . . 13 10.3. Failure Explanation . . . . . . . . . . . . . . . . . . 13 11. Relationship to Existing Mechanisms . . . . . . . . . . . . . 13 11.1. Gateway Deployment Scenarios and Gap Analysis . . . . . 14 11.2. Discovery and Directory Mechanisms . . . . . . . . . . . 14 11.3. Agent Interaction Mechanisms . . . . . . . . . . . . . . 14 11.4. Capability Description Mechanisms . . . . . . . . . . . 15 11.5. Trust, Authorization, and Audit Mechanisms . . . . . . . 15 12. Protocol and Interoperability Considerations . . . . . . . . 15 Yang, et al. Expires 1 January 2027 [Page 2] Internet-Draft Gateway Semantic Layer June 2026 13. Security Considerations . . . . . . . . . . . . . . . . . . . 17 14. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 16. Informative References . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction AI agent deployments are moving from local tool use toward collaboration across domains, platforms, networks, tenants, vendors, operational boundaries, and trust boundaries. In simple deployments, an agent can directly select a tool or endpoint and invoke it using a local protocol. In more complex deployments, a domain may need to decide what capabilities are visible, how business intent is interpreted, which policies constrain the interaction, which trust evidence is acceptable, and what information can be handed off to a subsequent protocol step. These decisions can create a need for a mediation point for semantic decision-making. Although cross-domain and policy-controlled deployments can reuse existing connectivity, discovery, capability description, trust evidence, and syntactic interoperability mechanisms, those mechanisms are not sufficient by themselves. A deployment may be able to find an endpoint, retrieve a machine-readable description, and parse a message while still being unable to decide whether a candidate capability matches the business intent, whether local policy permits disclosure, whether trust evidence is sufficient, or why a task failed. The missing element in such deployments is not another complete communication protocol, but a mediation decision function that connects intent, capability meaning, policy, trust, and handoff constraints. This document positions the Gateway Semantic Layer as that decision function when an AI Agent Gateway is used as the mediation point. It focuses on the semantic information and decision artifacts needed by an AI Agent Gateway to make reliable collaboration decisions and prepare controlled handoff to existing interaction mechanisms. This document provides applicability and gap analysis for gateway- side semantic decision-making and identifies a limited set of candidate interoperable artifacts. It complements gateway deployment scenario and gap analysis work [I-D.dunbar-dmsc-gw-scenarios-gap-analysis], gateway directory and synchronization work [I-D.zhang-dmsc-gateway-directory-sync], semantic interaction work [I-D.zhang-dmsc-ioa-semantic-interaction], and protocol-suite architecture work such as MACP [I-D.li-dmsc-macp]. Scope limitations and non-goals are listed in Section 6. Yang, et al. Expires 1 January 2027 [Page 3] Internet-Draft Gateway Semantic Layer June 2026 2. Terminology The following terms are used in this document: AI Agent Gateway: A gateway or gateway function that mediates agent collaboration across administrative, policy, trust, operational, semantic, or network boundaries. The term denotes a logical role and does not require a single physical node. Gateway Semantic Layer: A logical decision layer in an AI Agent Gateway that uses semantic information to interpret intent, understand capability meaning, apply policy and trust constraints, prepare handoff, and explain decisions or failures. Business Intent: A goal-oriented statement of what a user, application, or upstream agent wants to achieve, without necessarily naming a fixed agent, tool, endpoint, or protocol. Capability Description: A description of an agent, tool, service, or function. It may be derived from an A2A Agent Card, MCP descriptor, ANML or metadata document, local registration payload, or operator- managed source. Gateway-managed Capability View: A validated, normalized, policy- constrained view of capabilities that a gateway uses for decisions. It may be derived from one or more source descriptions. Semantic Resolution: A gateway-side process that uses business intent, task context, capability descriptions, policy constraints, and trust evidence to select, reject, constrain, or hand off candidate capabilities. Resolution Result: The output of semantic resolution, including the selected capability or rejection decision, decision reason, applicable scope, and constraints. Handoff Descriptor: Information prepared by the gateway to enable a subsequent interaction through A2A, MCP, IAIP, HTTP, or another suitable mechanism. Failure Explanation: A structured explanation of why semantic resolution, policy validation, trust validation, or handoff preparation failed. Yang, et al. Expires 1 January 2027 [Page 4] Internet-Draft Gateway Semantic Layer June 2026 3. Problem Statement Cross-domain and policy-controlled agent collaboration introduces semantic decision requirements that cannot always be placed solely at an agent client or an agent server. A collaboration request may involve business intent from an application, candidate capabilities from multiple source descriptions, policies from one or more domains, and trust evidence from security mechanisms. These inputs must be turned into a decision that can be used by a concrete interaction protocol. Some semantic decisions can be made by an agent client or an agent server in simple deployments. A client-side agent may understand the user's goal, and a server-side agent may understand its own capability description. However, in deployments that cross administrative, policy, trust, operational, semantic, or network boundaries, neither side necessarily has the full cross-domain view or the local authority needed to decide which capabilities are visible, which tenant or domain policy applies, which trust evidence is sufficient, what context may be disclosed, how heterogeneous capability descriptions should be normalized, or how a failure should be reported for audit, accounting, troubleshooting, or escalation. Gateway deployment scenarios analyzed in [I-D.dunbar-dmsc-gw-scenarios-gap-analysis] show that gateway functions can provide value in deployments involving multiple tenants, multiple vendors, cross-organization collaboration, policy- controlled capability exposure, operational visibility, mobility, and physical-world action authorization. From the semantic-decision perspective, these scenarios indicate that many deployments need a mediation function when semantic decisions must combine intent, capability meaning, local policy, cross-domain trust evidence, disclosure control, operational visibility, and auditable outcomes. An AI Agent Gateway is one architectural role that can host this function. The gateway semantic layer is applicable when such a mediation point is used to decide how business intent, capability descriptions, policy constraints, trust evidence, and handoff context are interpreted before interaction proceeds. The semantic question is: what semantic information and decision outputs are needed at that mediation point so that those decisions can be expressed and used in an interoperable way? Without a gateway semantic layer, the following interoperability failures can occur: Yang, et al. Expires 1 January 2027 [Page 5] Internet-Draft Gateway Semantic Layer June 2026 - A candidate is reachable but selected incorrectly because capability meaning is ambiguous. - A syntactically valid description is used outside its intended semantic profile, version, or domain context. - Policy constraints and semantic constraints are evaluated separately and produce inconsistent outcomes. - Trust evidence is available but not connected to the capability, delegation, or handoff decision. - A task is handed off without sufficient task meaning, context summary, disclosure limits, or failure semantics. - Failures are reported as opaque errors, making retry, escalation, audit, accounting, and troubleshooting difficult. The semantic layer therefore helps the gateway not only select the right agent or capability, but also understand and explain why a task was not completed. It turns decision and failure causes into structured information that the gateway can use for retry, escalation, audit, accounting, and controlled handoff. 4. Applicability to AI Agent Gateway Standardization This document is intended to support discussion of AI Agent Gateway work by identifying a specific gateway-side function rather than defining a complete gateway architecture. In this document, the relevant function is semantic decision-making: the gateway interprets business intent, capability meaning, policy constraints, trust evidence, and handoff context before a concrete interaction mechanism is used. The function is used when a gateway mediates collaboration across administrative, tenant, vendor, policy, trust, semantic, operational, or network boundaries. In such deployments, the gateway may need to decide which capabilities are visible, whether a discovered or registered capability matches an intent, what context may be disclosed, which evidence is sufficient, and how a selected interaction should be constrained or explained. Existing mechanisms can provide important inputs. Discovery mechanisms can locate candidate agents, tools, services, or capability documents. Description mechanisms can expose machine- readable capabilities and operational metadata. Trust, authorization, attestation, and audit mechanisms can provide evidence. Communication mechanisms can carry the subsequent Yang, et al. Expires 1 January 2027 [Page 6] Internet-Draft Gateway Semantic Layer June 2026 interaction. However, these mechanisms do not by themselves define the gateway-side decision output that connects intent, capability meaning, policy, trust, and handoff constraints. The potential IETF work identified by this document is therefore limited to interoperable gateway decision artifacts and references, such as Resolution Results, Handoff Descriptors, Failure Explanations, semantic profile references, source-description validation status, and policy or trust constraint references. The document does not propose standardizing gateway algorithms, ranking policy, domain ontologies, a new discovery protocol, a new agent communication protocol, or a complete product architecture. This framing allows the gateway semantic layer to be discussed as one candidate component of AI Agent Gateway work: it explains why a gateway is more than a forwarding proxy, while keeping the possible standardization target narrow and compatible with existing discovery, description, security, audit, and communication mechanisms. 5. 3GPP Service Requirements as Semantic Decision Drivers 3GPP TR 22.870 studies 6G use cases and service requirements, including AI-assisted services, AI Agent communication, data exposure, privacy protection, intent-based service operation, and mobility-related service behavior [TR-22-870]. Selected service- requirement themes from TR 22.870 illustrate why gateway-mediated deployments may need a semantic decision layer. +===========================+=====================================+ | 3GPP service-requirement | Semantic decision need in a gateway | | theme | | +===========================+=====================================+ | On-demand networking with | When intent handling is mediated by | | AI Agent (PR 6.21.6-1 and | a gateway, semantic decisions may | | PR 6.21.6-3): translating | be needed to relate the received | | received intent into | intent to service and performance | | service and performance | requirements, identify the intent | | requirements, and | source, associate it with the | | associating an intent | subscriber context, and record the | | source with resulting | actions resulting from the | | actions. | interpreted intent. | +---------------------------+-------------------------------------+ | 6G system assisted AI | When such service invocation or | | Agent service (PR 6.8.6-1 | data exchange is mediated by a | | to PR 6.8.6-3): AI Agent | gateway, semantic decisions may be | | applications invoking | needed to relate the requested task | | selected network | to the appropriate 3GPP service | | services, receiving | capability, interpret exposed QoS | Yang, et al. Expires 1 January 2027 [Page 7] Internet-Draft Gateway Semantic Layer June 2026 | exposed information such | or data-characteristic information, | | as QoS changes, and | apply operator policy and | | exchanging multi-modal | permission constraints, and prepare | | data subject to operator | a constrained handoff to the | | policy and permission. | selected interaction mechanism. | +---------------------------+-------------------------------------+ | Data exposure service (PR | When third-party data access is | | 5.5.5.3-1 and PR | mediated by a gateway, semantic | | 5.5.5.3-2): authorized | decisions may be needed to describe | | third-party access to | accessible data characteristics and | | processed user-equipment- | processing capabilities while | | related data and metadata | preserving operator policy, | | describing accessible | regulatory constraints, subscriber | | data characteristics and | permission, and protection of UE | | processing capabilities. | identities and individual user | | | data. | +---------------------------+-------------------------------------+ | Privacy protection of | When information exposure is | | data exposure (PR | mediated by a gateway, semantic | | 5.5.7.3-1 and PR | decisions may be needed to | | 5.5.7.3-2): protecting | determine disclosure scope and | | user privacy, location | handoff constraints while | | privacy, identity | preserving user privacy, location | | information, and | privacy, identity protection, and | | corresponding exposed | recipient authorization context. | | information. | | +---------------------------+-------------------------------------+ | AI Agents communication | When AI Agent communication is | | (PR 6.7.6-1 to PR | mediated by a gateway, semantic | | 6.7.6-6): trusted access, | decisions may be needed to | | attribute exposure, | interpret exposed agent attributes, | | registration and | relate registered capabilities to a | | discovery of authorized | collaborative task, constrain | | third-party AI Agents, | discovery and service exposure to | | secure communication, | authorized third-party AI Agents, | | service exposure, and | and bind the selected collaborator | | coordination within or | to policy, permission, and trust | | across AI Agent groups. | context. | +---------------------------+-------------------------------------+ | Flexible traffic routing | When traffic-routing decisions are | | and mobility-related | exposed to or consumed by a | | service behavior (PR | gateway-mediated agent workflow, | | 5.9.7.6-1): routing | semantic decisions may be needed to | | decisions may depend on | represent the mobility context and | | UE mobility between | routing outcome so that handoff or | | multiple 6G core networks | failure handling reflects the | | of the same PLMN. | change between 6G core networks. | +---------------------------+-------------------------------------+ Yang, et al. Expires 1 January 2027 [Page 8] Internet-Draft Gateway Semantic Layer June 2026 Table 1: 3GPP Requirement Themes and Gateway Semantic Decisions These requirement themes indicate that a gateway decision is not only an endpoint or protocol selection. It may need to combine intent meaning, capability meaning, policy limits, trust status, exposure constraints, network context, and failure reasons. The gateway semantic layer therefore provides the decision vocabulary and output objects needed to make such decisions reusable across interaction mechanisms and administrative domains. 6. Scope and Non-Goals This document describes the role and interoperability needs of a gateway semantic layer. It identifies candidate inputs, outputs, and gateway-side semantic operations. Out of scope are: - a universal ontology for all AI agents; - a full domain ontology library; - a new agent communication protocol; - a replacement for A2A, MCP, Agent Cards, ANML, ATN, DAWN, OAuth, WIMSE, TLS, DNS, HTTP, or other mechanisms; - a discovery query protocol or global registry; - a task orchestration or session protocol; - an authentication, authorization, attestation, or trust framework; - a complete audit, usage accounting, payment, or settlement system; or - an internal product architecture for gateways. Domain ontologies and business knowledge remain domain-specific. They provide the meaning basis for capability descriptions, task interpretation, policy constraints, and handoff context, while the gateway semantic layer focuses on how gateways reference, constrain, validate, map, and explain semantic information for decisions. Yang, et al. Expires 1 January 2027 [Page 9] Internet-Draft Gateway Semantic Layer June 2026 7. Position in a DMSC Gateway Architecture The Gateway Semantic Layer sits between application-level intent and agent interaction mechanisms. Above it, applications or upstream agents provide business goals, task orchestration needs, or human escalation signals. Below it, interaction mechanisms such as A2A, MCP, IAIP, HTTP APIs, Agent Cards, and metadata documents carry tasks, messages, tools, resources, endpoints, and descriptions. The semantic layer provides two contracts: - an intent-to-decision-input contract, which turns business goals and task context into inputs usable by the gateway decision function; and - a decision-to-interaction-handoff contract, which turns gateway decisions into handoff information for concrete interaction mechanisms. Gateway support functions such as registry and discovery, identity and authorization, directory synchronization, audit, and accounting provide inputs to the semantic layer, but do not replace it. Likewise, transport and security mechanisms provide connectivity, secure channels, integrity protection, and policy enforcement, but do not by themselves define capability meaning, business intent, or handoff semantics. Yang, et al. Expires 1 January 2027 [Page 10] Internet-Draft Gateway Semantic Layer June 2026 +--------------------------------+ +------------------------+ | Application Intent | | Gateway Support | | Business Goal | | Functions | | Task Orchestration | | | | Human Escalation | | Registry / Discovery | +---------------+----------------+ | | | | Identity / Authz | Intent-to-Decision-Input Contract | | | | Sync / Directory | +--------------------------------+ | | | Gateway Semantic Layer |<---| Audit / Accounting | | Intent Normalization | | | | Capability Meaning | | Control / Management | | Policy-aware Validation | | support to semantic | | Trust-aware Selection | | and interaction layers | | Handoff Semantics | | | | Failure Explanation | | | +---------------+----------------+ | | | | | Decision-to-Interaction Handoff | | | | | +--------------------------------+ | | | Agent Interaction Mechanisms |<---| | | A2A Tasks / Messages | | | | MCP Tools / Resources | | | | IAIP / HTTP APIs | | | | Agent Cards / Metadata | | | +---------------+----------------+ | | | | | +--------------------------------+ | | | Transport and Security | | | | Connectivity | | | | Secure Channels | | | | Integrity Protection | | | +--------------------------------+ +------------------------+ Figure 1: Gateway Semantic Layer Position Solid vertical arrows represent the main runtime decision flow. Side arrows represent control and management support from registry, discovery, identity, authorization, synchronization, audit, and accounting functions. The figure is illustrative rather than a required gateway implementation architecture. 8. Inputs to Gateway Semantic Resolution A gateway semantic layer can use the following classes of input. The precise data model may be defined by other drafts or future work. Yang, et al. Expires 1 January 2027 [Page 11] Internet-Draft Gateway Semantic Layer June 2026 8.1. Business Intent Business intent describes the goal of an interaction. It may be provided by an application, user-facing agent, orchestrator, or upstream domain. In gateway-mediated deployments, it often needs to be interpreted together with task context, policy constraints, capability meaning, and trust evidence, rather than treated only as a string or endpoint selector. 8.2. Task Context Task context includes the domain, service scope, time window, data sensitivity, operational state, user or tenant constraints, and other information needed to interpret the intent and constrain handoff. 8.3. Capability Descriptions Capability descriptions may come from A2A Agent Cards, MCP descriptors, ANML or other machine-readable metadata documents, local registration payloads, or gateway-managed directories. A gateway may validate, normalize, and constrain these descriptions before using them for decisions. 8.4. Policy Constraints Policy constraints include authorization scope, data exposure limits, privacy constraints, tenant policy, domain policy, regulatory constraints, and operational limits. A semantic match is not sufficient if policy does not allow use or disclosure. 8.5. Trust Evidence Trust evidence may include identity status, authorization or delegation evidence, provenance, attestation results, receipts, registry validation, or other trust metadata. The gateway semantic layer uses trust evidence as a constraint on selection and handoff. 9. Gateway Semantic Operations The semantic layer performs gateway-side operations that turn inputs into decisions. These operations may be implemented in different ways by different deployments, but their outputs may require interoperable representation. - Normalize meanings: Map heterogeneous descriptions, vocabulary terms, profile references, and versions into a gateway-managed capability view. Yang, et al. Expires 1 January 2027 [Page 12] Internet-Draft Gateway Semantic Layer June 2026 - Match intent to capability: Determine which candidate capabilities can satisfy the business intent and task context. - Apply policy and trust: Filter or constrain candidates according to local policy, authorization, disclosure limits, and trust evidence. - Prepare handoff semantics: Produce task meaning, context summary, disclosure limits, and failure semantics for the next interaction mechanism. - Explain decisions and failures: Produce decision reasons and failure reasons that can support retry, escalation, audit, accounting, and troubleshooting. 10. Outputs of the Gateway Semantic Layer 10.1. Resolution Result A Resolution Result indicates whether a candidate capability, agent, gateway, or service was selected or rejected. It can include the selected capability, decision reason, semantic profile or version references, applicable scope, and policy or trust constraints. 10.2. Handoff Descriptor A Handoff Descriptor carries information needed by the next interaction mechanism. It can include task meaning, context summary, disclosure limits, interaction mechanism, target reference, and failure semantics. It allows a gateway decision to be used by A2A, MCP, IAIP, HTTP, or another suitable mechanism without replacing those mechanisms. 10.3. Failure Explanation A Failure Explanation distinguishes failures such as capability mismatch, intent misunderstanding, parameter semantic mismatch, policy constraint failure, trust insufficiency, stale capability information, unavailable context, and context-version mismatch. These distinctions allow gateways and upstream applications to decide whether to retry, try another candidate, escalate, request more information, or record an auditable event. 11. Relationship to Existing Mechanisms Yang, et al. Expires 1 January 2027 [Page 13] Internet-Draft Gateway Semantic Layer June 2026 11.1. Gateway Deployment Scenarios and Gap Analysis The gateway deployment scenario and gap analysis draft identifies deployment cases in which AI Agent Gateway functions provide operational or interoperability benefits beyond direct agent-to-agent communication [I-D.dunbar-dmsc-gw-scenarios-gap-analysis]. It analyzes single-domain, multi-vendor, multi-tenant, cross- organization, telecom operator, mobility-driven, and physical-world- operation scenarios, and discusses gateway functions such as operational onboarding, capability advertisement and discovery, peer selection and routing, identity and trust establishment, policy enforcement, observability, synchronization, and network-aware reachability. The semantic layer identified here supports those gateway functions. For example, policy-controlled capability exposure requires the gateway to understand capability meaning and disclosure sensitivity; peer selection and routing require intent-to-capability matching; observability and audit require structured decision and failure reasons; and cross-domain handoff requires a constrained description of task meaning, context, policy, and trust evidence. 11.2. Discovery and Directory Mechanisms Discovery mechanisms such as DAWN-related work can locate candidate agents, tools, skills, services, or capability documents. Gateway directory and synchronization work can provide validated and policy- constrained capability views, capability digests, lifecycle state, freshness, and provenance information [I-D.zhang-dmsc-gateway-directory-sync]. The gateway semantic layer does not replace discovery or directory synchronization. It consumes discovery and directory outputs and determines how discovered or registered capabilities relate to business intent, policy constraints, trust evidence, and handoff requirements. In this sense, discovery and directory mechanisms provide candidate inputs, while the gateway semantic layer provides the mediation decision. 11.3. Agent Interaction Mechanisms Agent interaction mechanisms such as A2A, MCP, IAIP, HTTP APIs, or similar protocols can carry tasks, messages, artifacts, tool calls, resources, prompts, context, or interaction state [A2A] [MCP] [I-D.sz-dmsc-iaip]. They remain responsible for the concrete interaction. Yang, et al. Expires 1 January 2027 [Page 14] Internet-Draft Gateway Semantic Layer June 2026 The gateway semantic layer prepares constrained handoff information for such mechanisms. It does not define their message formats, session behavior, transport behavior, or tool invocation procedures. Interaction mechanisms carry the selected interaction, while the gateway semantic layer explains why that interaction is selected, constrained, rejected, or handed off. 11.4. Capability Description Mechanisms Capability descriptions may be provided through Agent Cards, MCP descriptors, ANML or other metadata documents, ACAP-like capability documents, local registration payloads, or gateway-managed directories [I-D.jeskey-anml]. Such descriptions can expose useful information about capability names, interfaces, authentication requirements, transport configuration, semantic profiles, or operational metadata. The gateway semantic layer treats these descriptions as inputs. It may validate, normalize, constrain, and reference them, but it does not define a replacement capability advertisement or metadata format. Capability descriptions state what a capability claims or exposes; the gateway semantic layer decides how those claims can be used in a given policy, trust, and handoff context. 11.5. Trust, Authorization, and Audit Mechanisms Trust, authorization, attestation, and audit mechanisms can provide identity status, delegation evidence, authorization scope, provenance, attestation results, receipts, or audit evidence. Examples include OAuth, WIMSE, RATS, SCITT, ATN, EMILIA-style receipts, DNSSEC, DANE, and domain-specific trust mechanisms [I-D.somoza-atn-agent-trust-negotiation]. The gateway semantic layer consumes such evidence as constraints on selection and handoff. It does not define authentication, authorization, attestation, trust negotiation, receipt, or audit protocols. Trust and authorization mechanisms provide evidence; the gateway semantic layer determines how that evidence constrains capability visibility, selection, disclosure, handoff, and failure reporting. 12. Protocol and Interoperability Considerations Not every gateway semantic function needs to be standardized. Internal matching algorithms, ranking policies, user-interface behavior, ontology management tools, knowledge-base storage, prompt engineering, model selection, and gateway module decomposition are implementation choices. Yang, et al. Expires 1 January 2027 [Page 15] Internet-Draft Gateway Semantic Layer June 2026 Potential protocol or interoperability work is narrower. It concerns the artifacts that cross a gateway boundary, are consumed by another component, or need to be recorded in a stable and comparable form. The following objects are the primary candidates for further analysis: - Resolution Result: a gateway decision artifact that records whether a candidate capability, agent, gateway, service, or interaction target was selected or rejected. It may include the selected target reference, source-description references, semantic profile and version references, applicable scope, policy and trust constraint references, decision reason, and validation status. - Handoff Descriptor: a constrained handoff artifact that carries task meaning, context summary, disclosure limits, interaction mechanism, target reference, policy and trust constraints, and any semantic profile references needed by the next interaction mechanism. It allows a semantic gateway decision to be used by A2A, MCP, IAIP, HTTP, or another suitable mechanism without replacing those mechanisms. - Failure Explanation: a structured failure artifact that distinguishes capability mismatch, intent ambiguity, semantic profile mismatch, policy constraint failure, trust insufficiency, stale capability information, unavailable context, context-version mismatch, and handoff preparation failure. It supports retry, fallback, escalation, audit, accounting, and troubleshooting without exposing unnecessary raw prompts or internal policy details. Additional supporting references may also require interoperable treatment when they are exchanged across domains or retained for audit. These include source description references and validation status, gateway-managed capability view or digest references, semantic profile and version references, policy constraint references, trust evidence references, and decision or failure reason-code registries. Future work should determine which of these artifacts need common data models, which only require reference conventions, and which can remain deployment-specific. Such work should reuse existing discovery, description, security, authorization, attestation, audit, and transport mechanisms rather than defining replacements for them. Yang, et al. Expires 1 January 2027 [Page 16] Internet-Draft Gateway Semantic Layer June 2026 13. Security Considerations The Gateway Semantic Layer influences which agents or capabilities are selected, what context is disclosed, and how tasks are handed off. Incorrect semantic interpretation can cause policy violations, capability misuse, failed handoff, or misleading audit records. Semantic inputs should therefore be protected against tampering, replay, downgrade, stale references, and misleading provenance. Gateways should distinguish self-asserted source descriptions from validated gateway-managed views. Trust evidence and authorization scope should be bound to the capability or handoff decision where possible. Authentication, authorization, attestation, transport security, and trust negotiation should reuse existing mechanisms such as TLS, OAuth, WIMSE, RATS, SCITT, ATN, DNSSEC, DANE, or domain-specific trust mechanisms where appropriate. 14. Privacy Considerations Business intent, task context, capability descriptions, semantic profiles, and failure explanations can reveal sensitive information about users, business processes, network operations, internal tools, operational policy, or data access patterns. Gateway semantic decisions should use minimal disclosure. Handoff descriptors should carry only the task meaning, context summary, and disclosure limits needed for the next interaction. Failure explanations should be useful for retry and troubleshooting without exposing unnecessary raw prompts, personal data, confidential business information, or internal policy details. 15. IANA Considerations This document makes no request for IANA action. 16. Informative References [A2A] Google Developers Blog, "Agent2Agent Protocol: A New Era of Agent Interoperability", 9 April 2025, . Yang, et al. Expires 1 January 2027 [Page 17] Internet-Draft Gateway Semantic Layer June 2026 [I-D.dunbar-dmsc-gw-scenarios-gap-analysis] Dunbar, L. and Y. Wang, "Deployment Scenarios and Gap Analysis for AI Agent Gateway", Work in Progress, Internet-Draft, draft-dunbar-dmsc-gw-scenarios-gap- analysis, 2026, . [I-D.jeskey-anml] Jeskey, A., "Agentic Notation Markup Language", Work in Progress, Internet-Draft, draft-jeskey-anml, 2026, . [I-D.li-dmsc-macp] Li, Z., "Multi-Agent Collaboration Protocol for Internet of Agents", Work in Progress, Internet-Draft, draft-li- dmsc-macp, 2026, . [I-D.somoza-atn-agent-trust-negotiation] Somoza, E., "Agent Trust Negotiation: Capability, Delegation, and Provenance Binding for AI Agents", Work in Progress, Internet-Draft, draft-somoza-atn-agent-trust- negotiation, 2026, . [I-D.sz-dmsc-iaip] Sun, S., "Intent-based Agent Interconnection Protocol at Agent Gateway", Work in Progress, Internet-Draft, draft- sz-dmsc-iaip, 2026, . [I-D.zhang-dmsc-gateway-directory-sync] Zhang, L., "Gateway Capability Directory and Synchronization for Internet of Agents", Work in Progress, Internet-Draft, draft-zhang-dmsc-gateway-directory-sync, 2026, . [I-D.zhang-dmsc-ioa-semantic-interaction] Zhang, L., "Ontology-based Semantic Interaction for Internet of Agents", Work in Progress, Internet-Draft, draft-zhang-dmsc-ioa-semantic-interaction, 2026, . [MCP] Anthropic, "Introducing the Model Context Protocol", 25 November 2024, . Yang, et al. Expires 1 January 2027 [Page 18] Internet-Draft Gateway Semantic Layer June 2026 [TR-22-870] 3GPP, "Study on 6G Use Cases and Service Requirements", 3GPP TR 22.870, 2026, . Authors' Addresses Huiling Yang AsiaInfo Technologies (China) Inc. Beijing 100000 China Email: yanghl10@asiainfo.com Guozhen Dong China Telecom Beiqijia Town, Changping District Beijing 102209 China Email: donggz@chinatelecom.cn Lianhua Zhang AsiaInfo Technologies (China) Inc. Beijing 100000 China Email: zhanglh2@asiainfo.com Yun Li AsiaInfo Technologies (China) Inc. Beijing 100000 China Email: liyun9@asiainfo.com Shoufeng Wang AsiaInfo Technologies (China) Inc. Beijing 100000 China Email: wangsf11@asiainfo.com Yang, et al. Expires 1 January 2027 [Page 19]