Independent Submission J. Hwang Internet-Draft Shanghai Maritime University Intended status: Informational 18 July 2026 Expires: 19 January 2027 Semantic Interlingua Layer Protocol (SILP): A Payload Codec for Cross- Model Agent Communication draft-hwang-silp-protocol-00 Abstract This document specifies the Semantic Interlingua Layer Protocol (SILP), a black-box, text-interface payload codec designed for cross- model agent-to-agent communication. SILP defines a coarse-grained action-slot intermediate representation (IR) as the canonical semantic layer and compiles it into multiple pluggable surface frontends -- code-like function-call syntax, pure JSON, natural language, and ML-compressed text. SILP is designed as a payload- layer option within existing agent transport protocols such as the Model Context Protocol (MCP) and Agent-to-Agent (A2A) protocol, which define transport envelopes and capability discovery but leave payload encoding unspecified. SILP provides compile/decode round-trip guarantees for lossless frontends, dynamic frontend negotiation via probe messages, session management with heartbeat renewal, and a verb whitelist verified across six production tokenizers for cross-model token-level stability. This document is a product of independent research and is not an IETF standard. It is published as an Informational document to establish a stable reference for implementers. 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." Hwang Expires 19 January 2027 [Page 1] Internet-Draft SILP Protocol July 2026 This Internet-Draft will expire on 19 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Design Principles . . . . . . . . . . . . . . . . . . . . 5 2. Protocol Architecture . . . . . . . . . . . . . . . . . . . . 5 3. Layer 1: Application Layer (Semantic IR) . . . . . . . . . . 6 3.1. Root IR Object . . . . . . . . . . . . . . . . . . . . . 6 3.2. Entity Object . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Constraint Object . . . . . . . . . . . . . . . . . . . . 8 3.4. Alternative Object . . . . . . . . . . . . . . . . . . . 9 3.5. Meta Object . . . . . . . . . . . . . . . . . . . . . . . 9 3.6. Request ID (req_id) Collision Requirements . . . . . . . 10 3.7. Action Code Format . . . . . . . . . . . . . . . . . . . 11 3.8. Verb Whitelist . . . . . . . . . . . . . . . . . . . . . 11 3.9. JSON Schema Representation . . . . . . . . . . . . . . . 13 4. Layer 2: Surface Layer (Pluggable Frontends) . . . . . . . . 16 4.1. Code Frontend . . . . . . . . . . . . . . . . . . . . . . 17 4.2. JSON Frontend . . . . . . . . . . . . . . . . . . . . . . 19 4.3. Natural Language Frontend . . . . . . . . . . . . . . . . 20 4.4. NL+JSON Frontend . . . . . . . . . . . . . . . . . . . . 20 4.5. LLMLingua-2 Frontend . . . . . . . . . . . . . . . . . . 20 4.6. Lossless Round-Trip Guarantee . . . . . . . . . . . . . . 21 5. Layer 3: Meta-Protocol Layer . . . . . . . . . . . . . . . . 21 5.1. Error Codes . . . . . . . . . . . . . . . . . . . . . . . 21 5.2. Session Management . . . . . . . . . . . . . . . . . . . 22 5.3. Frontend Negotiation . . . . . . . . . . . . . . . . . . 22 6. Layers 4 and 5: Optimization and Migration (Future Work) . . 23 6.1. Layer 4: Optimization Layer . . . . . . . . . . . . . . . 23 6.2. Layer 5: Migration Layer . . . . . . . . . . . . . . . . 23 7. Relationship to Existing Agent Protocols . . . . . . . . . . 23 7.1. AIDIP Integration . . . . . . . . . . . . . . . . . . . . 24 7.2. MCP Integration . . . . . . . . . . . . . . . . . . . . . 24 7.3. A2A Integration . . . . . . . . . . . . . . . . . . . . . 24 Hwang Expires 19 January 2027 [Page 2] Internet-Draft SILP Protocol July 2026 8. Security Considerations . . . . . . . . . . . . . . . . . . . 24 8.1. Zero-Width and Homoglyph Attacks . . . . . . . . . . . . 25 8.2. Payload Injection . . . . . . . . . . . . . . . . . . . . 25 8.3. Request ID Collision . . . . . . . . . . . . . . . . . . 25 8.4. Model Identity . . . . . . . . . . . . . . . . . . . . . 25 8.5. Lossy Compression Risks . . . . . . . . . . . . . . . . . 25 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 10. Normative References . . . . . . . . . . . . . . . . . . . . 26 11. Informative References . . . . . . . . . . . . . . . . . . . 26 Appendix A. IR Examples . . . . . . . . . . . . . . . . . . . . 27 A.1. Example 1: Negation Logic with Alternative . . . . . . . 27 A.2. Example 2: Multi-Constraint with Secondary Action . . . . 28 A.3. Example 3: Keyword Arguments (Detail Preservation) . . . 29 A.4. Example 4: Nested Constraints . . . . . . . . . . . . . . 30 A.5. Example 5: Parallel Actions with Sequencing . . . . . . . 30 Appendix B. Structural Token Verification . . . . . . . . . . . 30 Appendix C. Acknowledgements . . . . . . . . . . . . . . . . . . 31 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31 1. Introduction The rise of agentic AI systems has created a new communication paradigm: large language models (LLMs) conversing not with humans, but with other LLMs through structured text protocols. Frameworks such as the Model Context Protocol (MCP) [MCP] and Agent-to-Agent (A2A) protocol [A2A] define transport envelopes and capability discovery, but leave a critical gap: how should the semantic payload itself be encoded? Current practice defaults to uncompressed natural language, which is token-inefficient, tokenizer-dependent, and semantically ambiguous -- particularly for negation logic, multi-step action chains, and conditional branching. SILP addresses this gap by defining a protocol layer that compiles a canonical intermediate representation (IR) into multiple surface encodings, each designed to exploit the shared training priors of contemporary LLMs. The concept of an interlingua -- an intermediate representation that mediates between input and output languages -- has a long history in machine translation; Abstract Meaning Representation (AMR) [AMR] is a notable graph-semantic example. SILP adapts this concept to the LLM-agent domain: the IR is the interlingua, and frontends are the surface encodings compiled from it. Recent IETF discussions have begun addressing the agent protocol ecosystem at multiple layers. The AI Agent Discovery and Invocation Protocol (AIDIP) defines how agents are discovered and invoked (agent metadata, registration, search, and a RESTful invocation interface). The Agent-to-Agent (A2A) protocol defines task lifecycle, message Hwang Expires 19 January 2027 [Page 3] Internet-Draft SILP Protocol July 2026 transport, and artifact exchange between agents. The Model Context Protocol (MCP) defines how agents invoke external tools. However, these protocols all leave the encoding of semantic payload content to the implementer. SILP fills this gap: it is not a competing transport or discovery protocol, but a payload-layer codec that can be embedded within the message fields of A2A, MCP, or AIDIP-based systems to ensure cross-model semantic consistency. 1.1. Scope SILP is a payload-layer codec. It does not replace transport protocols, lifecycle management, or capability discovery. SILP payloads are designed to be carried inside MCP's params field or A2A's task/message/artifact fields without modifying their semantics. SILP operates through a pure text interface. It does not access or manipulate model-internal latent representations. All encodings produced by lossless frontends are auditable and decodable back to the canonical IR. 1.2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. IR (Intermediate Representation): The canonical semantic payload defined in Section 3. All frontends compile from and decode to this representation. Frontend: A specific surface encoding of the IR (e.g., code-like syntax, JSON, natural language). See Section 4. Compile: The process of converting an IR to a surface string via a frontend. Decode: The process of recovering an IR from a surface string via a frontend. Lossless frontend: A frontend where decode(compile(ir)) produces an IR semantically equivalent to the original for all valid IRs. Hwang Expires 19 January 2027 [Page 4] Internet-Draft SILP Protocol July 2026 Action code: An IR primitive following the format ! + UPPERCASE_VERB (e.g., !CANCEL). Session: A stateful conversation context between two or more agents, identified by a session ID. Heartbeat: A session renewal mechanism that resets accumulated context every N turns. 1.3. Design Principles 1. *Protocol, not compression:* SILP is a protocol layer with lossless round-trip guarantees. Compression is a side effect of compact encoding, not the primary goal. 2. *Black-box text interface:* SILP does not require model-internal access, fine-tuning, or latent representation manipulation. It operates purely through text that LLMs process during inference. 3. *Tokenizer-aware vocabulary:* The verb whitelist is verified to be single-token and UNK-free across six production tokenizers, ensuring cross-model token-level stability. 4. *Auditability:* All lossless frontend encodings can be decoded back to the canonical IR. The compile.lock mechanism provides tamper-evident first-pass freezing. 5. *Extensibility:* The IR root is strict (extra="forbid") while sub-models allow extra fields. Receivers MUST silently ignore unknown fields in extensible sub-models. 2. Protocol Architecture SILP is a five-layer protocol stack. Layers 1 and 2 are fully specified in this document. Layer 3 is partially specified. Layers 4 and 5 are design-level and reserved for future work. Hwang Expires 19 January 2027 [Page 5] Internet-Draft SILP Protocol July 2026 +=====+=============+==================+==================+=========+ |Layer|Name | Module | Description |Status | +=====+=============+==================+==================+=========+ |1 |Application | silp.ir | Semantic IR |Specified| | | | | (action-slot | | | | | | structure) | | +-----+-------------+------------------+------------------+---------+ |2 |Surface | silp.frontend | Pluggable |Specified| | | | | frontends | | | | | | (code, JSON, | | | | | | natural, | | | | | | nl_json, | | | | | | llmlingua2) | | +-----+-------------+------------------+------------------+---------+ |3 |Meta-protocol| silp.negotiation | Frontend |Partially| | | | | negotiation, |specified| | | | | session | | | | | | management, | | | | | | error codes | | +-----+-------------+------------------+------------------+---------+ |4 |Optimization | silp.bench | Multi-objective |Future | | | | | fitness |work | | | | | function + | | | | | | genetic | | | | | | algorithm | | +-----+-------------+------------------+------------------+---------+ |5 |Migration | silp.bench | Small-model |Future | | | | | screening proxy |work | | | | | for frontend | | | | | | evaluation | | +-----+-------------+------------------+------------------+---------+ Table 1: SILP Five-Layer Stack 3. Layer 1: Application Layer (Semantic IR) The canonical intermediate representation is a JSON-serialized action-slot structure. It is the single source of semantic truth: all frontends compile from this IR and decode back to it. The IR is defined as a JSON Schema with strict validation at the root level and extensible sub-models. 3.1. Root IR Object The root IR object (SilpIR) MUST contain the following fields. Unknown fields at the root level are forbidden (extra="forbid"). Hwang Expires 19 January 2027 [Page 6] Internet-Draft SILP Protocol July 2026 +==============+=============+========+=========+===================+ | Field | Type |Required|Default | Description | +==============+=============+========+=========+===================+ | silp | string |No |"v1" | Protocol | | | | | | version. MUST | | | | | | match ^v\d+$. | +--------------+-------------+--------+---------+-------------------+ | version | string |No |"ir-v0.1"| IR schema | | | | | | version. | +--------------+-------------+--------+---------+-------------------+ | intent | string |Yes |-- | Main action | | | | | | code. MUST | | | | | | match | | | | | | ^![A-Z][A-Z_]*$. | +--------------+-------------+--------+---------+-------------------+ | entities | array of |No |[] | Argument slots | | | Entity | | | and secondary | | | | | | actions. | +--------------+-------------+--------+---------+-------------------+ | constraints | array of |No |[] | Conditions on | | | Constraint | | | the task. | +--------------+-------------+--------+---------+-------------------+ | alternatives | array of |No |[] | Fallback actions | | | Alternative | | | (else-branch). | +--------------+-------------+--------+---------+-------------------+ | meta | Meta object |Yes |-- | Protocol-level | | | | | | metadata. | +--------------+-------------+--------+---------+-------------------+ Table 2: Root IR Fields 3.2. Entity Object An entity represents an argument slot. If the action field matches the root intent, the entity is an argument to the primary action. If action differs from intent, it is a secondary action (e.g., email(zhangsan) alongside cancel(flight)). The Entity object allows extra fields (extra="allow"). Receivers MUST silently ignore unknown Entity fields. Hwang Expires 19 January 2027 [Page 7] Internet-Draft SILP Protocol July 2026 +========+============+==========+=========+=====================+ | Field | Type | Required | Default | Description | +========+============+==========+=========+=====================+ | id | string | Yes | -- | Slot identifier. | | | | | | "act" indicates a | | | | | | positional | | | | | | argument. | +--------+------------+----------+---------+---------------------+ | value | string | Yes | -- | The slot value. | +--------+------------+----------+---------+---------------------+ | action | string | No | null | Action code if this | | | (optional) | | | entity belongs to a | | | | | | secondary action. | | | | | | MUST match | | | | | | ^![A-Z][A-Z_]*$. | +--------+------------+----------+---------+---------------------+ Table 3: Entity Fields 3.3. Constraint Object A constraint represents a condition on the task. Convention for negation: prefix the type field with ! (e.g., "!rain") to produce !rain(t+1) in the code frontend. The Constraint object allows extra fields (extra="allow"). Common extra fields include subject (first positional argument in function- call constraints) and operator (infix operator such as >, <=). Receivers MUST silently ignore unknown Constraint fields. +=======+============+==========+=========+========================+ | Field | Type | Required | Default | Description | +=======+============+==========+=========+========================+ | type | string | Yes | -- | Constraint type. | | | | | | Prefix ! for negation. | +-------+------------+----------+---------+------------------------+ | value | string | Yes | -- | Constraint value. | +-------+------------+----------+---------+------------------------+ | time | string | No | null | Temporal reference, | | | (optional) | | | e.g., "t+1", "t+1am". | +-------+------------+----------+---------+------------------------+ Table 4: Constraint Fields Hwang Expires 19 January 2027 [Page 8] Internet-Draft SILP Protocol July 2026 3.4. Alternative Object An alternative represents a fallback action (else-branch) executed when constraints are not met. The Alternative object allows extra fields (extra="allow"). +==========+============+==========+=========+==================+ | Field | Type | Required | Default | Description | +==========+============+==========+=========+==================+ | action | string | Yes | -- | Action code. | | | | | | MUST match | | | | | | ^![A-Z][A-Z_]*$. | +----------+------------+----------+---------+------------------+ | target | string | No | null | Target entity of | | | (optional) | | | the fallback | | | | | | action. | +----------+------------+----------+---------+------------------+ | location | string | No | null | Location | | | (optional) | | | qualifier for | | | | | | the fallback. | +----------+------------+----------+---------+------------------+ Table 5: Alternative Fields 3.5. Meta Object The Meta object carries protocol-level metadata. It allows extra fields (extra="allow") for forward compatibility. Receivers MUST silently ignore unknown Meta fields. Hwang Expires 19 January 2027 [Page 9] Internet-Draft SILP Protocol July 2026 +============+============+========+===========+===================+ | Field | Type |Required| Default | Description | +============+============+========+===========+===================+ | req_id | string |Yes | -- | Request | | | | | | identifier. MUST | | | | | | match | | | | | | ^[a-f0-9]{4,8}$. | | | | | | Default length: 8 | | | | | | hex chars (32 | | | | | | bits). 4 hex | | | | | | chars permitted | | | | | | only in scope- | | | | | | limited sessions. | +------------+------------+--------+-----------+-------------------+ | session_id | string |No | null | 2-character | | | (optional) | | | session | | | | | | identifier for | | | | | | stateful mode. | +------------+------------+--------+-----------+-------------------+ | priority | integer |No | 0 | Priority level. | +------------+------------+--------+-----------+-------------------+ | confidence | float |No | 1.0 | Confidence score | | | | | | in range [0.0, | | | | | | 1.0]. | +------------+------------+--------+-----------+-------------------+ | seq | array of |No | [] | Sequence of | | | string | | | action codes for | | | | | | multi-step tasks. | +------------+------------+--------+-----------+-------------------+ | out | string |No | "natural" | Output format | | | | | | hint for the | | | | | | receiver. | +------------+------------+--------+-----------+-------------------+ | next_agent | string |No | null | Routing hint for | | | (optional) | | | the next agent. | +------------+------------+--------+-----------+-------------------+ Table 6: Meta Fields 3.6. Request ID (req_id) Collision Requirements The req_id field is a hexadecimal hash used for request correlation. Based on collision testing (n=1,000 simulated IDs per condition): * 4 hex chars (16 bits): 995 unique IDs, 5 collisions, 0.5% duplicate fraction. Permitted ONLY for short-lived, scope-limited sessions. Hwang Expires 19 January 2027 [Page 10] Internet-Draft SILP Protocol July 2026 * 6 hex chars (24 bits): 1,000 unique IDs, 0 collisions, 0.0% duplicate fraction. Not recommended as default due to birthday- bound collision probability at scale. * 8 hex chars (32 bits): 1,000 unique IDs, 0 collisions, 0.0% duplicate fraction. This is the PRODUCTION DEFAULT. Implementations MUST use 8 hex characters as the default req_id length. Implementations MAY use 4 hex characters only when the session is scope-limited and the total number of concurrent requests is known to be small. Note: duplicate fraction is not the same as the probability of at least one collision. In 16-bit space, the birthday-bound collision probability for n=1,000 is approximately 99.9%. 3.7. Action Code Format Action codes follow the format: ! followed by UPPERCASE_VERB where the verb consists of uppercase ASCII letters and underscores. The formal grammar in ABNF [RFC5234] is: file "action-code-abnf" action-code = "!" 1*UPPER-LETTER *( "_" 1*UPPER-LETTER ) UPPER-LETTER = %x41-5A ; A-Z Lowercase function names in the code frontend are derived by removing the ! prefix and converting to lowercase: !CANCEL -> cancel. 3.8. Verb Whitelist The following 13 verbs are approved as IR action code primitives. Each verb has been verified to be single-token (exactly 1 token) across six production tokenizers: gpt-4o (o200k_base), gpt-3.5 (cl100k_base), llama-2, qwen2.5, claude, and gemini. The complete census data is available in the reference implementation [SILP-CODE]. Hwang Expires 19 January 2027 [Page 11] Internet-Draft SILP Protocol July 2026 +=============+===============+======================+==========+ | Action Code | Function Name | Single-Token (all 6) | UNK-Free | | | | | (all 6) | +=============+===============+======================+==========+ | !CANCEL | cancel | Yes | Yes | +-------------+---------------+----------------------+----------+ | !START | start | Yes | Yes | +-------------+---------------+----------------------+----------+ | !EMAIL | email | Yes | Yes | +-------------+---------------+----------------------+----------+ | !FETCH | fetch | Yes | Yes | +-------------+---------------+----------------------+----------+ | !PROCESS | process | Yes | Yes | +-------------+---------------+----------------------+----------+ | !TRANSLATE | translate | Yes | Yes | +-------------+---------------+----------------------+----------+ | !BOOK | book | Yes | Yes | +-------------+---------------+----------------------+----------+ | !ROUTE | route | Yes | Yes | +-------------+---------------+----------------------+----------+ | !SEARCH | search | Yes | Yes | +-------------+---------------+----------------------+----------+ | !UPDATE | update | Yes | Yes | +-------------+---------------+----------------------+----------+ | !SUGGEST | suggest | Yes | Yes | +-------------+---------------+----------------------+----------+ | !SWITCH | switch | Yes | Yes | +-------------+---------------+----------------------+----------+ | !NOTIFY | notify | Yes | Yes | +-------------+---------------+----------------------+----------+ Table 7: Approved Verb Whitelist (13 Verbs, All Single-Token Across 6 Tokenizers) The following verbs are EXCLUDED from the whitelist and MUST NOT be used as IR action codes: Hwang Expires 19 January 2027 [Page 12] Internet-Draft SILP Protocol July 2026 +==============+=============+====================+==============+ | Verb | Token | Reason | Suggested | | | Counts | | Replacement | | | Across 6 | | | | | Tokenizers | | | +==============+=============+====================+==============+ | !SWITCH_TOOL | gpt-4o: 2, | Multi-token (2-3 | !SWITCH | | | gpt-3.5: 2, | tokens). Never | | | | llama-2: 3, | single-token on | | | | qwen2.5: 2, | any tested | | | | claude: 3, | tokenizer. | | | | gemini: 3 | | | +--------------+-------------+--------------------+--------------+ | !ESCALATE | gpt-4o: 3, | Multi-token (2-3 | Use a | | | gpt-3.5: 2, | tokens). Sub-word | single-token | | | llama-2: 3, | fragment "ate" has | alternative | | | qwen2.5: 2, | spurious meaning | | | | claude: 3, | (English verb | | | | gemini: 2 | "ate"). | | +--------------+-------------+--------------------+--------------+ Table 8: Excluded Verbs 3.9. JSON Schema Representation The complete IR schema is represented below as a JSON Schema (Draft 2020-12). This is the normative representation of the IR structure. Implementations MUST validate IR objects against this schema before processing. file "silp-ir-schema.json" { "$schema": "https://json-schema.org/draft/2020-12/schema", "$id": "https://github.com/Juwan-Hwang/polyglotir", "title": "SILP IR", "type": "object", "additionalProperties": false, "required": ["intent", "meta"], "properties": { "silp": { "type": "string", Hwang Expires 19 January 2027 [Page 13] Internet-Draft SILP Protocol July 2026 "pattern": "^v\\d+$", "default": "v1" }, "version": { "type": "string", "default": "ir-v0.1" }, "intent": { "type": "string", "pattern": "^![A-Z][A-Z_]*$" }, "entities": { "type": "array", "items": { "type": "object", "additionalProperties": true, "required": ["id", "value"], "properties": { "id": { "type": "string" }, "value": { "type": "string" }, "action": { "type": "string", "pattern": "^![A-Z][A-Z_]*$" } } } }, "constraints": { "type": "array", "items": { "type": "object", "additionalProperties": true, "required": ["type", "value"], Hwang Expires 19 January 2027 [Page 14] Internet-Draft SILP Protocol July 2026 "properties": { "type": { "type": "string" }, "value": { "type": "string" }, "time": { "type": "string" } } } }, "alternatives": { "type": "array", "items": { "type": "object", "additionalProperties": true, "required": ["action"], "properties": { "action": { "type": "string", "pattern": "^![A-Z][A-Z_]*$" }, "target": { "type": "string" }, "location": { "type": "string" } } } }, "meta": { "type": "object", "additionalProperties": true, Hwang Expires 19 January 2027 [Page 15] Internet-Draft SILP Protocol July 2026 "required": ["req_id"], "properties": { "req_id": { "type": "string", "pattern": "^[a-f0-9]{4,8}$" }, "session_id": { "type": "string" }, "priority": { "type": "integer", "default": 0 }, "confidence": { "type": "number", "minimum": 0, "maximum": 1, "default": 1.0 }, "seq": { "type": "array", "items": { "type": "string" } }, "out": { "type": "string", "default": "natural" }, "next_agent": { "type": "string" } } } } } 4. Layer 2: Surface Layer (Pluggable Frontends) Five frontends compile IR to surface string. Two frontends (code and json) are lossless codecs satisfying decode(compile(ir)) == ir. Three frontends (natural, nl_json, llmlingua2) are control baselines that do not support decode. Hwang Expires 19 January 2027 [Page 16] Internet-Draft SILP Protocol July 2026 +============+==================================+================+ | Frontend | Description | Round-trip | +============+==================================+================+ | code | Function-call syntax | Yes (lossless) | +------------+----------------------------------+----------------+ | json | Flat JSON slots | Yes (lossless) | +------------+----------------------------------+----------------+ | natural | Unstructured prose | No (control) | +------------+----------------------------------+----------------+ | nl_json | Natural language wrapped in JSON | No (control) | +------------+----------------------------------+----------------+ | llmlingua2 | LLMLingua-2 compressed natural | No (lossy) | | | language | | +------------+----------------------------------+----------------+ Table 9: Surface Frontends 4.1. Code Frontend The code frontend maps IR action codes to lowercase function calls (!CANCEL -> cancel()), compiles constraints as boolean conditions, entities as positional or keyword arguments, and alternatives as else: branches. The general compilation form in ABNF [RFC5234] is: Hwang Expires 19 January 2027 [Page 17] Internet-Draft SILP Protocol July 2026 file "code-frontend-abnf" code-frontend = [ "if " condition ": " ] actions [ " else: " alt-actions ] condition = constraint *( " and " constraint ) constraint = negation / operator-form / func-call negation = "!" verb [ "(" time ")" ] operator-form = verb operator value [ ", " time ] func-call = verb "(" [ subject "," ] value [ "," time ] ")" actions = primary-call *( "; " secondary-call ) primary-call = fn-name "(" [ args ] ")" secondary-call = fn-name "(" [ positional-args ] ")" alt-actions = alt-call *( "; " alt-call ) alt-call = fn-name "(" [ target [ "@" location ] / "loc=" location ] ")" args = arg *( "," arg ) arg = positional-arg / kw-arg positional-arg = value kw-arg = id "=" value fn-name = 1*LOWER-LETTER *( "_" 1*LOWER-LETTER ) verb = 1*UPPER-LETTER *( "_" 1*UPPER-LETTER ) LOWER-LETTER = %x61-7A ; a-z UPPER-LETTER = %x41-5A ; A-Z Examples: Hwang Expires 19 January 2027 [Page 18] Internet-Draft SILP Protocol July 2026 # Negation logic if !rain(t+1): start(hike) else start(cards@indoor) # Multi-constraint with secondary action if loc(me,Beijing,t+1am): cancel(flight,t+1pm); email(zhangsan) # Keyword arguments translate(src=fr_rev_bold, tgt=shakespeare_en, style=archaic_heavy) # Operator condition with tool switching if weather>rain then switch(indoor_activity) # Nested constraints if budget<=500 and rating>=4.0: book(hotel,downtown,t+5) 4.2. JSON Frontend The JSON frontend renders the IR as a flat JSON object [RFC8259] with only semantic slots -- no code syntax. This isolates "format contribution" (structured JSON) from "code vocabulary prior" (function-call syntax). Entities matching the root intent are flattened to top-level slots. Secondary actions (entities whose action differs from intent) are grouped under keys prefixed with action_. Hwang Expires 19 January 2027 [Page 19] Internet-Draft SILP Protocol July 2026 file "json-frontend-example" { "intent": "!CANCEL", "act": "flight", "action_email": ["zhangsan"], "constraints": [ {"type": "loc", "value": "Beijing", "time": "t+1am", "subject": "me"} ] } 4.3. Natural Language Frontend The natural frontend renders the IR as unstructured English prose. It is a control baseline and does NOT support decode. Example output: "If not rain at t+1, start hike otherwise start cards at indoor." 4.4. NL+JSON Frontend The nl_json frontend wraps the exact same prose produced by the natural frontend inside a JSON task_description field. It is a control baseline isolating the JSON-container effect and does NOT support decode. file "nl-json-example" {"task_description": "If not rain at t+1, start hike otherwise start cards at indoor."} 4.5. LLMLingua-2 Frontend The llmlingua2 frontend compresses the natural frontend's output using LLMLingua-2 (XLM-RoBERTa-large, rate=0.5) [LLMLingua2]. LLMLingua-2 is the successor to LLMLingua [LLMLingua], which uses perplexity-based compression. It is a lossy compression baseline and does NOT support decode. The compression rate (default: 0.5) is configurable. Hwang Expires 19 January 2027 [Page 20] Internet-Draft SILP Protocol July 2026 4.6. Lossless Round-Trip Guarantee For the code and json frontends, the following invariant MUST hold for all valid IRs: file "round-trip-invariant" decode(compile(ir)) is semantically equivalent to ir "Semantically equivalent" means the decoded IR preserves intent, entities, constraints, and alternatives. The meta.req_id of the decoded IR is regenerated from the compiled text via SHA-256 hash truncation, so it may differ from the original if the original was not generated by compile. All other fields MUST be preserved. 5. Layer 3: Meta-Protocol Layer The meta-protocol layer handles dynamic frontend negotiation, session management, error codes, and degradation chains. This section specifies the error code registry and session management parameters. Frontend negotiation via //ping probes is partially specified. 5.1. Error Codes SILP defines the following payload-decode error codes. These exist ONLY in the payload-decode sub-layer and do NOT replace the outer MCP/A2A JSON-RPC error mechanism. Hwang Expires 19 January 2027 [Page 21] Internet-Draft SILP Protocol July 2026 +======================+==========================================+ | Code | Description | +======================+==========================================+ | invalid_syntax | The payload does not conform to the | | | expected frontend syntax. | +----------------------+------------------------------------------+ | unsupported_version | The silp version field indicates a | | | version not supported by the receiver. | +----------------------+------------------------------------------+ | unsupported_frontend | The requested frontend is not | | | implemented by the receiver. | +----------------------+------------------------------------------+ | decode_failed | The receiver attempted to decode the | | | payload but the decoding process failed. | +----------------------+------------------------------------------+ | timeout | The session or request exceeded its time | | | limit. | +----------------------+------------------------------------------+ | session_expired | The session ID is no longer valid. | +----------------------+------------------------------------------+ Table 10: SILP Error Codes 5.2. Session Management In stateful mode, SILP sessions are identified by 2-character session IDs. The N parameter controls heartbeat renewal frequency: every N turns, the session context is reset. The following N values are defined: * N=1: Stateless (context resets every turn). * N=5: Heartbeat every 5 turns. * N=10: Heartbeat every 10 turns. * N=15: Heartbeat every 15 turns. * N=20: Heartbeat every 20 turns. * N=9999: No heartbeat (maximum context accumulation, stateful throughout). 5.3. Frontend Negotiation SILP supports dynamic frontend negotiation via a //ping probe. A sender sends a //ping message listing its supported frontends. The receiver responds with its supported frontends and a preferred frontend. Both parties then use the highest-priority mutually supported frontend. The negotiation protocol is partially specified. The degradation chain defines a fallback order when a negotiated frontend fails: Hwang Expires 19 January 2027 [Page 22] Internet-Draft SILP Protocol July 2026 code -> math -> JSON -> natural language 6. Layers 4 and 5: Optimization and Migration (Future Work) 6.1. Layer 4: Optimization Layer Layer 4 defines a multi-objective fitness function for frontend selection and IR optimization. The fitness function is: file "fitness-function" Fitness = alpha * task_success + alpha_prime * cross_model_fidelity + beta * compression - gamma * human_unreadability - delta * PPL - epsilon * tokenizer_variance - zeta * cross_model_ambiguity Constrained by alpha + alpha_prime >= 0.6 and a hard fidelity floor. This layer is design-only and not yet experimentally validated. 6.2. Layer 5: Migration Layer Layer 5 is a proposed migration screening layer intended to test ranking preservation: if small models and API-reported endpoints rank frontends similarly (high Spearman rho), small models could serve as proxies for frontend evaluation. This layer is not yet validated. 7. Relationship to Existing Agent Protocols SILP is designed as a payload-layer codec that complements existing agent protocols. It does not define its own transport mechanism, discovery protocol, or tool-calling interface. Instead, SILP-encoded strings can be embedded within the payload fields of multiple existing protocols without modifying their semantics. The following table summarizes the relationship: Hwang Expires 19 January 2027 [Page 23] Internet-Draft SILP Protocol July 2026 +==========+=========================+=======================+ | Protocol | Problem Solved | Relationship to SILP | +==========+=========================+=======================+ | AIDIP | Agent discovery and | Complementary: SILP | | | invocation (metadata, | can encode the inputs | | | search, RESTful invoke) | and outputs fields of | | | | AIDIP invocations | +----------+-------------------------+-----------------------+ | A2A | Agent-to-agent task | Complementary: SILP | | | lifecycle, message | can be embedded in | | | transport, artifact | A2A task, message, or | | | exchange | artifact fields | +----------+-------------------------+-----------------------+ | MCP | Agent-to-tool | Complementary: SILP | | | invocation protocol | can encode the params | | | | field of MCP JSON-RPC | | | | requests | +----------+-------------------------+-----------------------+ Table 11: SILP Relationship to Existing Agent Protocols 7.1. AIDIP Integration The AI Agent Discovery and Invocation Protocol (AIDIP), as discussed in recent IETF work, defines a RESTful interface for agent discovery (POST /agents/search) and invocation (POST /agents/{id}/invoke). AIDIP's invocation interface accepts an inputs field containing the task description. A SILP-encoded string can replace the natural- language inputs content, providing cross-model semantic consistency without modifying AIDIP's discovery or invocation semantics. 7.2. MCP Integration In MCP [MCP], a SILP payload is carried inside the params field of a JSON-RPC request. The SILP-encoded string replaces the natural- language instruction text that would normally appear in params. 7.3. A2A Integration In A2A [A2A], a SILP payload is carried inside task, message, or artifact fields. SILP does not replace A2A's lifecycle management. 8. Security Considerations Hwang Expires 19 January 2027 [Page 24] Internet-Draft SILP Protocol July 2026 8.1. Zero-Width and Homoglyph Attacks SILP payloads are text-based and therefore susceptible to zero-width character injection and homoglyph substitution attacks. Testing across six tokenizers (gpt-4o, gpt-3.5, llama-2, qwen2.5, claude, gemini) confirmed that 4 types of zero-width characters (ZWSP, ZWNJ, ZWJ, BOM) and Latin-to-Cyrillic homoglyph substitutions alter tokenization in all 144 probes conducted (5 probe verbs for zero- width injection, 2 probe verbs for homoglyph substitution, 6 tokenizers). Implementations SHOULD sanitize input by stripping zero-width characters (U+200B, U+200C, U+200D, U+FEFF) and normalizing homoglyphs before processing SILP payloads. However, this does not constitute a complete security guarantee -- visual invisibility, preprocessing normalization, and downstream parser behavior are separate concerns. 8.2. Payload Injection SILP payloads carry task instructions. Implementations MUST NOT allow SILP payloads to carry content that bypasses safety filters. The verb whitelist (see Section 3.8) restricts the action space to legitimate task verbs, reducing (but not eliminating) injection risk. 8.3. Request ID Collision The req_id field uses 4-8 hex characters. With 4 hex characters (16 bits), the birthday-bound collision probability for n=1,000 requests is approximately 99.9%. Implementations MUST use 8 hex characters (32 bits) as the production default to minimize collision risk. 8.4. Model Identity SILP operates through a black-box text interface and does not verify the identity of the receiving model. If a proxy misroutes requests (e.g., serving a different model for one provider), the cross-model comparison would be compromised. This is a known limitation of the black-box approach. 8.5. Lossy Compression Risks The llmlingua2 frontend uses lossy ML-based compression that may remove or obscure negation markers and entity boundaries. Implementations MUST NOT use llmlingua2 for payloads where semantic precision is critical, particularly for negation logic. The code and json frontends are RECOMMENDED for all production use. Hwang Expires 19 January 2027 [Page 25] Internet-Draft SILP Protocol July 2026 9. IANA Considerations This document has no IANA actions. Future versions of this specification may request registration of: * A SILP frontend name registry (e.g., code, json, natural, nl_json, llmlingua2). * A SILP error code registry (see Table 10). * A SILP verb whitelist registry (see Table 7). 10. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC5234] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . [RFC8259] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, December 2017, . 11. Informative References [A2A] Google, "Agent2Agent (A2A) Protocol", 2024, . [AMR] Banarescu, L., "Abstract Meaning Representation for Sembanking", Proceedings of the 7th Linguistic Annotation Workshop, pages 178-186, 2013, . [LLMLingua] Jiang, H., Wu, Q., Lin, C-Y., Yang, Y., and L. Qiu, "LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models", EMNLP 2023, pages 13358-13376, December 2023, . Hwang Expires 19 January 2027 [Page 26] Internet-Draft SILP Protocol July 2026 [LLMLingua2] Pan, Z., Wu, Q., and H. Jiang, "LLMLingua-2: Data Distillation for Efficient and Faithful Task-Agnostic Prompt Compression", Findings of ACL 2024. arXiv:2403.12968, 2024, . [MCP] Anthropic, "Model Context Protocol (MCP)", 2024, . [SILP-CODE] Hwang, J., "SILP Reference Implementation", GitHub repository: Juwan-Hwang/polyglotir, 2026, . [SILP-PAPER] Hwang, J., "SILP: A Semantic Interlingua Layer Protocol for Cross-Model Agent Communication", Zenodo. DOI: 10.5281/zenodo.21396849, 2026, . Appendix A. IR Examples This appendix provides examples of SILP IR objects and their compilation under each frontend. All examples are drawn from the 27-case test suite described in the accompanying research paper [SILP-PAPER]. A.1. Example 1: Negation Logic with Alternative Hwang Expires 19 January 2027 [Page 27] Internet-Draft SILP Protocol July 2026 file "example1-ir" { "silp": "v1", "intent": "!START", "entities": [ {"id": "act", "value": "hike", "action": "!START"} ], "constraints": [ {"type": "!rain", "value": "true", "time": "t+1"} ], "alternatives": [ {"action": "!START", "target": "cards", "location": "indoor"} ], "meta": {"req_id": "a1b2c3d4", "out": "code"} } Code frontend output: if !rain(t+1): start(hike) else start(cards@indoor) JSON frontend output: {"intent":"!START", "act":"hike", "constraints":[{"type":"!rain","value":"true","time":"t+1"}], "alternatives":[{"action":"!START","target":"cards", "location":"indoor"}]} Natural frontend output: If not rain at t+1, start hike otherwise start cards at indoor. A.2. Example 2: Multi-Constraint with Secondary Action Hwang Expires 19 January 2027 [Page 28] Internet-Draft SILP Protocol July 2026 file "example2-ir" { "silp": "v1", "intent": "!CANCEL", "entities": [ {"id": "act", "value": "flight", "action": "!CANCEL"}, {"id": "time", "value": "t+1pm", "action": "!CANCEL"}, {"id": "act", "value": "zhangsan", "action": "!EMAIL"} ], "constraints": [ {"type": "loc", "value": "Beijing", "time": "t+1am", "subject": "me"} ], "alternatives": [], "meta": {"req_id": "e5f6g7h8", "out": "code"} } Code frontend output: if loc(me,Beijing,t+1am): cancel(flight,t+1pm); email(zhangsan) A.3. Example 3: Keyword Arguments (Detail Preservation) Hwang Expires 19 January 2027 [Page 29] Internet-Draft SILP Protocol July 2026 file "example3-ir" { "silp": "v1", "intent": "!TRANSLATE", "entities": [ {"id": "src", "value": "fr_rev_bold", "action": "!TRANSLATE"}, {"id": "tgt", "value": "shakespeare_en", "action": "!TRANSLATE"}, {"id": "style", "value": "archaic_heavy", "action": "!TRANSLATE"} ], "constraints": [], "alternatives": [], "meta": {"req_id": "1a2b3c4d", "out": "code"} } Code frontend output: translate(src=fr_rev_bold, tgt=shakespeare_en, style=archaic_heavy) A.4. Example 4: Nested Constraints if budget<=500 and rating>=4.0: book(hotel,downtown,t+5) A.5. Example 5: Parallel Actions with Sequencing fetch(data) -> process -> email(result) with timeout Appendix B. Structural Token Verification The following 12 structural tokens are verified to be single-token on all 6 production tokenizers (gpt-4o, gpt-3.5, llama-2, qwen2.5, claude, gemini) with zero UNK occurrences. The complete census data is available in the reference implementation [SILP-CODE]. Hwang Expires 19 January 2027 [Page 30] Internet-Draft SILP Protocol July 2026 +=======+====================+ | Token | Category | +=======+====================+ | if | Conditional | +-------+--------------------+ | else | Conditional | +-------+--------------------+ | and | Logical | +-------+--------------------+ | not | Logical | +-------+--------------------+ | ( | Delimiter | +-------+--------------------+ | ) | Delimiter | +-------+--------------------+ | , | Delimiter | +-------+--------------------+ | ; | Delimiter | +-------+--------------------+ | : | Delimiter | +-------+--------------------+ | ! | Negation prefix | +-------+--------------------+ | @ | Location qualifier | +-------+--------------------+ | -> | Sequencing | +-------+--------------------+ Table 12: Structural Tokens (All Single-Token, Zero UNK, Across 6 Tokenizers) Appendix C. Acknowledgements The SILP protocol design was informed by empirical research documented in the accompanying research paper [SILP-PAPER]. The reference implementation is available as open source [SILP-CODE]. Author's Address Juwan Hwang Shanghai Maritime University 1550 Haigang Av. Shanghai 201306 China Email: huangzhiwen@stu.shmtu.edu.cn Hwang Expires 19 January 2027 [Page 31] Internet-Draft SILP Protocol July 2026 URI: https://github.com/Juwan-Hwang Hwang Expires 19 January 2027 [Page 32]