SlimWire Protocol (SWP) Core: Binary Framing and Envelope Substrate

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶

This Internet-Draft will expire on 24 August 2026.¶

Copyright Notice

Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. Introduction

Contemporary LLM systems increasingly behave as distributed systems: they invoke external tools, delegate long-running tasks to other agents, stream intermediate progress, exchange artefacts, and operate across organisational trust boundaries. In practice, these behaviours are implemented via heterogeneous application protocols over transports such as HTTP streaming and stdio.¶

Two application-level protocol efforts have gained traction: the Model Context Protocol (MCP) (https://modelcontextprotocol.io/specification/) and Agent2Agent (A2A) (https://a2a-protocol.org/; overview: https://developers.googleblog.com/en/a2a-a-new-era-of-agent-interoperability/). MCP standardises tool invocation and discovery (commonly JSON-RPC over defined transports), while A2A standardises agent-to-agent delegation and discovery. Both operate at the application layer.¶

As deployments move into federated, cross-boundary settings, integration friction often arises below the application layer: message boundary detection, size limiting, replay policy, correlation, identity surfacing for authorisation and audit, and failure semantics are repeatedly reimplemented at gateways and adapters. SWP addresses this by defining a minimal substrate: a record layer and envelope that carry multiple profiles under a stable dispatch model, with explicit security binding requirements and a machine-verifiable conformance suite.¶

This document specifies SWP Core (framing, envelope, E1 encoding, and profile dispatch), plus the conformance and security binding requirements needed for interoperable deployments. SWP profiles (including mappings for MCP and A2A and additional infrastructure primitives) are referenced but are not fully specified herein unless required for Core interoperability.¶

2. Conventions and 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 when, and only when, they appear in all capitals, as shown here.¶

BCP 14 is specified by RFC 2119 (https://www.rfc-editor.org/rfc/rfc2119) and clarified by RFC 8174 (https://www.rfc-editor.org/rfc/rfc8174).¶

This document uses the following terms:¶

• Frame: A length-delimited unit on a byte stream consisting of a 32-bit big-endian length prefix and an encoded envelope.¶

• Envelope: The Core-level header containing versioning, profile dispatch identifiers, correlation identifiers, and an opaque profile payload.¶

• Profile: A defined semantic layer above Core identified by a numeric profile_id and a profile-defined msg_type. Profiles define payload schemas, processing rules, and conformance vectors.¶

• Binding: A set of requirements that constrain how Core and profiles are carried over a transport (e.g., security binding S1; payload encoding binding P1).¶

3. SWP Core Overview

SWP Core defines (1) message framing on a byte stream, (2) a minimal envelope surface for dispatch, and (3) a mandatory envelope encoding (E1). Profiles define application semantics and payload formats and are carried as opaque bytes in the Core envelope.¶

4. E1 Envelope Encoding

E1 is the mandatory-to-implement envelope encoding for Core version 1. E1 encodes envelope fields in a fixed order using unsigned LEB128 uvarints and length-delimited byte strings. E1 includes a TLV extension block that can be skipped by implementations that do not recognise extension types.¶

5. P1 Payload Encoding Binding

SWP Core treats payload bytes opaquely. To enable independent implementability and deterministic conformance testing for profile payloads, SWP defines a mandatory payload encoding binding P1 for profiles that opt into structured payload encoding.¶

P1 specifies Protocol Buffers (proto3) wire format as mandatory-to-implement for applicable profiles. Protobuf proto3 guidance is documented at https://protobuf.dev/programming-guides/proto3/.¶

Rationale (informative): Protobuf supports compact binary payloads, established forward/backward compatibility discipline (stable field numbers; unknown fields ignored), and byte-level golden vectors.¶

Normative schema annexes: this specification set includes normative .proto files for P1 profile payloads (e.g., SWP RPC, events, artifacts, and A2A-mapped messages). The .proto annexes are distributed with the SWP spec kit and are referenced by profile specifications. Implementations claiming conformance to a profile that uses P1 MUST decode payloads using the corresponding normative .proto schema.¶

Exception: the MCP mapping profile carries MCP JSON-RPC payload bytes opaquely to preserve MCP semantics and avoid semantic drift. MCP specification is available at https://modelcontextprotocol.io/specification/.¶

6. Profile Registry and profile_id Allocation

Core dispatch depends on a stable registry of numeric profile identifiers (profile_id). profile_id values MUST NOT be reused. A profile specification MUST define its profile_id, msg_type space, payload binding (e.g., P1 protobuf or opaque), and conformance vectors.¶

This document defines the following initial allocation guidance:¶

• profile_id 1: MCP mapping profile (opaque JSON-RPC bytes).¶

• profile_id 2: A2A profile (agent task lifecycle and related messages).¶

• profile_id 3-9: reserved for future foundational profiles/bindings.¶

• profile_id 10-19: reserved for extended infrastructure primitive profiles.¶

Allocation policy (informative): new profile_id assignments SHOULD be accompanied by (1) a profile specification, (2) conformance vectors for core behaviours and error paths, and (3) an explicit compatibility statement. Experimental/private-use identifiers should be confined to a clearly segregated range as defined by the profile registry document for the SWP spec kit.¶

7. Conformance Classes and Golden Vectors

SWP defines conformance classes (C0 through C5) to enable scoped implementation claims. Each class corresponds to a set of required vector namespaces. Implementations MUST state which conformance class claims are supported.¶

Wire fixture (.bin):
  [u32_be N] [E1 envelope bytes]

E1 layout (field order):
  version(uvarint)=1
  profile_id(uvarint)=1
  msg_type(uvarint)=1
  flags(uvarint)=0
  ts_unix_ms(uvarint)=0
  msg_id(bytes)=len 16 + 16 octets
  extensions(bytes)=len 0
  payload(bytes)=len 0

Expected (.json):
  {
    "vector_id": "e1_0001_valid_min_envelope",
    "expected": {
      "outcome": "accept",
      "assert": {
        "version": 1,
        "profile_id": 1,
        "msg_type": 1,
        "payload_len": 0
      }
    }
  }

8. Security Considerations

SWP Core is intended for federated deployments and therefore specifies a security binding (S1) that constrains channel properties required before frames are processed.¶

9. Implementation Status

The SWP spec kit is accompanied by an executable proof-of-concept (PoC) implementation used to generate and validate conformance vectors via the spec-vector runner. The PoC is a reference artefact rather than a production deployment, intended to exercise framing, envelope decoding/encoding, profile dispatch, and conformance evaluation end-to-end.¶

Earlier iterations used JSON payload parsing for some profile handlers while specifying P1 protobuf payload binding as normative. This mismatch has been resolved: P1 protobuf payload binding is now both normative for applicable profiles and implemented in the PoC for spec-vector execution. MCP mapping remains byte-preserving and carries JSON-RPC bytes opaquely to avoid semantic drift.¶

10. Evaluation and Reproducibility

SWP evaluation is grounded in machine-verifiable conformance artefacts. The spec-vector runner executes golden vectors and emits a JSON summary with a versioned schema, run provenance, per-vector results, and explicit indication of fallback usage. Strict mode (no-fallback) provides an implementation-only signal.¶

The SWP spec kit recommends publishing a conformance artefact bundle consisting of: (1) runner command lines, (2) runner stdout logs, (3) JSON summaries, and (4) the runner output schema documentation.¶

# Default run (fallback permitted)
make vectors SPEC_VECTOR_ARGS="-pattern 'conformance/vectors/core_*.json' -json-out artifacts/conformance/core.default.json"

# Strict run (implementation-only; fallback disallowed)
make vectors-strict SPEC_VECTOR_ARGS="-pattern 'conformance/vectors/core_*.json' -json-out artifacts/conformance/core.strict.json"

# Optional convenience targets (if provided by the repository)
make conformance-core
make conformance-all

11. Deployment and Interoperability Scenarios

SWP is designed for incremental adoption. Representative scenarios include:¶

• MCP bridging (C1): deploy SWP Core + MCP mapping behind a gateway that translates between MCP transports and SWP framing. MCP payload bytes remain opaque and can be forwarded byte-preservingly.¶

• Federated delegation (C2): two organisations exchange agent tasks using SWP Core + A2A profile over an S1-compliant channel, with stable peer identity surfacing for authorisation and audit.¶

• Unified RPC/events/artefacts (C3/C4/C5): a deployment uses SWP profiles for RPC, events, observability, and artifact transfer to carry task execution, progress, trace correlation, and artefact references on a single secured connection.¶

12. Limitations and Non-Goals

SWP Core is intentionally narrow. The following are explicit non-goals for this document:¶

• Replacing MCP or A2A; SWP is intended to carry and bridge them as profiles.¶

• Defining a new IAM system or full policy language; credential and policy profiles are propagation/signalling surfaces.¶

• Mandating a single transport; SWP runs over any channel meeting S1.¶

• Specifying message-level end-to-end cryptography across relays; S1 is a channel security binding.¶

• Providing Core-level multiplexing; multiplexing is transport- or profile-level.¶

This document is a Core substrate specification. Profile specifications define additional semantics and may impose further requirements for particular deployment environments.¶

13. Conclusion

SWP Core provides a minimal, independently implementable substrate for federated agent/tool communication: a rigorous record layer, a compact envelope with mandatory E1 encoding, explicit profile dispatch, and a conformance model based on classes, golden vectors, and reproducible artefact bundles. By separating a stable substrate from evolving application semantics (profiles), SWP aims to reduce bespoke gateway logic and make interoperability claims verifiable.¶

14. IANA Considerations

This document makes no requests of IANA.¶

Appendix: Implementation and Conformance Notes (Informative)

Implementations that claim SWP conformance should publish: (1) supported conformance classes, (2) artefact bundle outputs from default and strict runs, and (3) any deployment-specific policy parameters (size limits, timestamp freshness policy, peer authentication mode). The SWP spec kit includes runner output schema documentation and conformance claim checklists.¶

Author's Address