Use of Natural Language for Agent Communication
draft-verma-dmsc-nlip-notes-00

DMSC Working Group                                              D. Verma
Internet-Draft                                                       IBM
Intended status: Informational                                E. Bertino
Expires: 14 August 2026                                Purdue University
                                                          A. Ratnaparkhi
                                                               eBay Inc.
                                                               S. Hughes
                                                             Service Now
                                                                 L. Xing
                                                                   Z. Li
                                                                 X. Liao
                                                                  J. Cui
                              University of Illinois at Urbana-Champaign
                                                            R. Topaloglu
                                                       Marist University
                                                              M. Rahouti
                                                      Fordham University
                                                        10 February 2026

            Use of Natural Language for Agent Communication
                     draft-verma-dmsc-nlip-notes-00

Abstract

   In current communication protocol designs, the prevalent practice is
   to define a strict Application Programming Interface (API) for
   different types of interactions among software entities.  There is an
   explosion of APIs which makes interoperability hard, and the
   standards for interoperability fragile.  Specifically for agent to
   agent communications, defining strict APIs for interactions such as
   registration, discovery, telemetry and debugging creates significant
   operational challenges.  In this draft, we argue that a flexible
   design option -- where generative AI is used to create a flexible
   communication protocol for APIs, can lead to a common and flexible
   way for a single uniform API to be used between agents, and enables a
   better communication paradigm.

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

Verma, et al.            Expires 14 August 2026                 [Page 1]
Internet-Draft             BGP-LS-Inter-AS-Ext             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 14 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.  Conventions used in this document . . . . . . . . . . . . . .   2
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   2
   3.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Other Modalities  . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Existing Standard . . . . . . . . . . . . . . . . . . . . . .   5
   6.  New Conventions . . . . . . . . . . . . . . . . . . . . . . .   5
   7.  Security Considerations . . . . . . . . . . . . . . . . . . .   6
   8.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   9.  Acknowledgement . . . . . . . . . . . . . . . . . . . . . . .   6
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     10.1.  Normative References . . . . . . . . . . . . . . . . . .   6
     10.2.  Informative References . . . . . . . . . . . . . . . . .   7
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   7

1.  Conventions used in this document

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

2.  Terminology

   The following terms are defined in this document:

   *  NLIP: Natural Language Interaction Protocol

Verma, et al.            Expires 14 August 2026                 [Page 2]
Internet-Draft             BGP-LS-Inter-AS-Ext             February 2026

   *  ntohs: Network to Host Short

   *  htons: Host to Network Short

3.  Introduction

   Contemporary application-level protocols and Application Programming
   Interface (API) are designed by specifying a function name (or URI)
   and a data structure.  All communicating endpoints are required to
   use the same data structure, and this data structure is transferred
   between them using a structured representation such as JSON.  This
   design approach causes significant interoperability issues when the
   version upgrade of any software causes a change in the data structure
   that needs to be exchanged.

   A more flexible communication paradigm can be obtained by leveraging
   the ability of large language models to translate between
   unstructured natural language and a structured representation such as
   JSON or the internal structure of a programming language effectively.
   The communicating parties can transmit a natural language
   representation among each other, and each endpoint can maintain its
   own internal representation for the structure being maintained for
   its tasks.

   In this draft, we argue that this flexible exchange offers various
   benefits in agent to agent communications.

   The natural language text exchanged between communicating parties has
   the same semantics as the structures maintained at various
   communication endpoints, but the format is natural language.  A LLM
   at each end point can translate the wire format into the local
   structure format.  This allows for the internal representation of
   structures at endpoints to be independent of each other.  This
   independence allows for improved interoperability and the freedom for
   each end-point to upgrade its internal structures as needed.

   As an example, let us consider the simple but illustrative case where
   one of the endpoints is an agent that is sending its communication
   endpoint information to the other endpoint which is a registrar
   providing registration services for agents.  The registrar maintains
   information about each endpoint as a URL, while the agent maintains
   its internal information as a local host and port.  The agent can
   register itself to the registrar using plain text - "I am running on
   host hostname on port 1430" or an equivalent natural language text
   representation.  The registrar can use a local LLM to translate this
   text to an internal URL representation.

Verma, et al.            Expires 14 August 2026                 [Page 3]
Internet-Draft             BGP-LS-Inter-AS-Ext             February 2026

   Using natural language provides two key advantages.  It provides
   resilience against upgrades of the endpoints.  Suppose the registrar
   is upgraded to a new version in which it supports each agent
   information as a structure consisting of a port, a protocol and a
   host address instead of the URL.  This upgrade can be made without
   any impact to any of the agents.  On the other hand, if the
   traditional approach of defining a fixed structure on the wire were
   to be used, the upgrade of the registrar would require changes in
   each of the agents interacting with it.

   The second advantage is the simplification in the versioning of
   protocols.  During any definition of a standard protocol, some key
   features or functions may be missed due to a variety of reasons.  If
   a new protocol version is defined, the protocol needs to be defined
   to support a version number and a careful handling of mismatches in
   the structural differences across versions.  By breaking the linkage
   between the internal representation of endpoint structures and the
   wire structure, natural language simplifies version management
   significantly.

   The separation of the wire format from the internal structures can be
   viewed as a modern take on the concept of ntohs and htons - concepts
   developed during the early stages of computer communications
   development to promote interoperability between computer systems.
   When big-endian machines needed to talk to little- endian machines,
   these two macros translated between network and host structure
   formats.  NLIP is providing the same functionality at the application
   level, leveraging the ability of LLMs to translate between
   unstructured natural text and structured representations.

   It is recommended that two communicating parties exchange information
   about their internal representation with each other.  When an agent
   registers with the registrar in the above example, the registrar can
   send a natural text representation of the internal information to the
   agent to validate that it has translated the text correctly to an
   internal representation and then translated it back.  The agent can
   do its own internal translation and validate that the information is
   consistent with its internal representation.  The same exchange also
   helps to validate if a field is missing or not incorporated properly.

4.  Other Modalities

   Natural language is not the only modality which is needed for general
   communication among software entities.  Some agents may require other
   modality such as images, video or audio/speech as part of their
   operation.  Nevertheless, the same principle of separating the wire
   format from the internal structures and capabilities of the software
   application can be used.

Verma, et al.            Expires 14 August 2026                 [Page 4]
Internet-Draft             BGP-LS-Inter-AS-Ext             February 2026

   For each modality, the wire exchange format can specify the modality
   of the exchange.  However, it can leave the task of interpreting the
   contents and internal structure of the exchanged information to the
   local AI model.  The agent can use its local AI model to interpret
   the format and process it.

   This is an analogue of the way humans communicate using the different
   senses.  Our eyes process light/visual modality, our ears process the
   sound/speech modality etc.  Our internal intelligence processes these
   signals without relying on the strict adherence to internal
   structures.  We can simply identify the information modality and let
   the agent process the information.

5.  Existing Standard

   There is an existing standard which is designed based on this
   principle of using natural language for exchange among agents.  This
   standard - Natural Language Interaction Protocol (NLIP) [ECMA430]--
   defines a way for exchanged information to simply define the modality
   , and let interacting agents interpret the exchanged content without
   requiring a strict structure on the wire.

   Experiences implementing NLIP based services and the standard have
   shown that the approach is viable, has good performance and is
   secure.  For development and debugging, the NLIP protocol allowed for
   a single interface for trouble-shooting, and our performance
   evaluation showed that the protocol added little to no overhead, and
   in many cases out-performed registration functions using a more
   traditional API.

   As the IETF community works towards defining conventions for agent to
   agent communications, we want to bring this design approach to their
   attention, since leveraging a protocol like NLIP will provide
   tremendous flexibility and operational simplicity to software
   implementing the functions of agents.

6.  New Conventions

   With the presence of existing standard of NLIP, the task of defining
   common functions for any agent to agent communications becomes that
   of defining the semantics of the information that should be
   transferred, as opposed to defining a rigid structure for the
   interaction.  When agents need to communicate with each other, they
   need to perform functions such as discover other agents, register
   themselves with a registrar, or obtain the governing policies for
   security or data management from other agents.  While NLIP provides
   the basic envelop for transfer of the information, new conventions or
   standards would need to be developed for each of these functions.

Verma, et al.            Expires 14 August 2026                 [Page 5]
Internet-Draft             BGP-LS-Inter-AS-Ext             February 2026

   The key difference from traditional approach is that one does not
   define a rigid structure (e.g. a JSON schema or a XML structure) for
   interaction but only the semantic content of the information to be
   exchanged.

   We would consider it a task of the IETF to define the exact
   semantics.  As an example for the task of registration, the semantic
   specification may define that the port number and server host name of
   the agent should be identified, along with the identity of the owning
   organization and the provider of security certificate.  This
   information can be expressed in natural language and converted into
   the local structured representation.

   Similarly, for the task of discovery, the agent looking for specific
   type of remote agent can describe their requirements in natural
   language, instead of defining a rigid schema for discovery of remote
   agents.  Each agent can convert the requirements to their local
   structure to decide whether or not they match the requirements.  IETF
   needs to define the semantic content for discovery requests -- e.g.
   specify that agents must define the type of capabilities they are
   looking for - such as image analysis, speech to text conversion,
   security requirements, performance constraints, or billing limits
   etc.  There is no need to define a specific structure for the task.

   By following this convention, the standardization process can be made
   more streamlined and agents implementing the protocol interoperate
   better with other agents.

7.  Security Considerations

   This document should not affect the security of the Internet.

8.  IANA Considerations

   This document includes no request to IANA.

9.  Acknowledgement

   This template uses extracts from templates written by Pekka Savola,
   Elwyn Davies and Henrik Levkowetz.

10.  References

10.1.  Normative References

   [ECMA430]  Ecma International, "Natural Language Interaction
              Protocol", Standard ECMA-430, Edition 1, December 2025,
              <https://www.ecma-international.org>.

Verma, et al.            Expires 14 August 2026                 [Page 6]
Internet-Draft             BGP-LS-Inter-AS-Ext             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>.

10.2.  Informative References

Authors' Addresses

   Dinesh Verma
   IBM
   P.O. Box 218, Yorktown Heights
   New York,  10598
   United States of America
   Email: dverma@us.ibm.com

   Elisa Bertino
   Purdue University
   CS Department
   West Lafayette , IN 47907
   United States of America
   Email: bertino@purdue.edu

   Abhay Ratnaparkhi
   eBay Inc.
   7700 West Parmer Lane
   Austin,  78729
   United States of America
   Email: abratnaparkhi@ebay.com

   Sean Hughes
   Service Now
   2225 Lawson Lane
   Santa Clara , CA 95054
   United States of America
   Email: sean.hughes@servicenow.com

   Luyi Xing
   University of Illinois at Urbana-Champaign
   201 N Goodwin Ave
   Urbana , IL 61801
   United States of America
   Email: lxing2@illinois.edu

Verma, et al.            Expires 14 August 2026                 [Page 7]
Internet-Draft             BGP-LS-Inter-AS-Ext             February 2026

   Zichuan Li
   University of Illinois at Urbana-Champaign
   201 N Goodwin Ave
   Urbana , IL 61801
   United States of America
   Email: zichuan7@illinois.edu

   Xiaojing Liao
   University of Illinois at Urbana-Champaign
   201 N Goodwin Ave
   Urbana , IL 61801
   United States of America
   Email: xjliao@illinois.edu

   Jian Cui
   University of Illinois at Urbana-Champaign
   201 N Goodwin Ave
   Urbana , IL 61801
   United States of America
   Email: jiancui3@illinois.edu

   Rasit Topaloglu
   Marist University
   3399 North Road
   Poughkeepsie , NY 12601
   United States of America
   Email: rasit.topaloglu@marist.edu

   Mohamed Rahouti
   Fordham University
   113 W 60th Street
   New York , NY 10023
   United States of America
   Email: mohamed@fordham.edu

Verma, et al.            Expires 14 August 2026                 [Page 8]