| Internet-Draft | AIIP Architecture | December 2025 |
| Sogomonian | Expires 16 June 2026 | [Page] |
This document defines the architectural model and byte-precise envelope framing for the Artificial Intelligence Internet Protocol (AIIP). AIIP enables stateless, verifiable invocation of autonomous systems using a resolve-invoke-receipt pattern over authenticated transports (mutual TLS, QUIC, or an optional HTTPS gateway). Native AIIP is the default for machine-to-machine operation; HTTPS gateways are optional for human-facing access. Each invocation produces a cryptographically verifiable execution receipt, optionally including attestation evidence.¶
Work in Progress.¶
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 16 June 2026.¶
Copyright (c) 2025 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.¶
AIIP provides a uniform address space and invocation model for AI resources with verifiable outcomes. The architecture follows a resolve-invoke-receipt pattern.¶
Autonomous systems communicate natively using AIIP envelopes over authenticated transports. Human operators and supervisory systems can access AIIP resources via HTTPS gateways for compatibility with Web-based tools.¶
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 [RFC2119] and [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
AIIP separates addressing, invocation, and verification into distinct steps: (1) resolution returns an Invocation Descriptor (IDesc); (2) invocation is carried in an AIIP envelope; (3) the response includes an execution receipt that can be verified independently.¶
Human Operator
(UI / Dashboard)
|
HTTPS Gateway
|
------------------
| AIIP Core |
------------------
| |
Native AIIP Native AIIP
| |
Robot A Robot B
Autonomous systems, including robots, industrial controllers, agents, and embedded devices, use AIIP natively. In native mode, AIIP envelopes are exchanged directly between client and resource over an authenticated transport such as mutual TLS or QUIC.¶
Native AIIP invocation does not depend on HTTP semantics, cookies, or browser-originated state. Authorization, policy enforcement, and result verification are defined by AIIP.¶
Human operators and management interfaces typically interact with AIIP resources through HTTPS gateways. These gateways provide compatibility with Web-based clients but are not required for autonomous operation.¶
Resolution maps an AIIP identifier to an Invocation Descriptor (IDesc). The IDesc provides the endpoint URI, authentication requirements, verification keys (or references), and policy signals.¶
Client Resolver Authority | aiip://... | | |----------------->| | | | validate delegation | | |-------------------> | | |<------------------- | | | return signed IDesc | |<-----------------| |
Clients MUST validate the authenticity and integrity of the IDesc prior to invocation.¶
AIIP messages are framed as a fixed-size header followed by a payload. All multi-octet integer fields are encoded in network byte order (big-endian). Unless otherwise specified, numeric fields are unsigned. Timestamps are milliseconds since the Unix epoch.¶
An AIIP message is:¶
AIIP-Message = AIIP-Header || Payload || Signature¶
Where || denotes concatenation.¶
The AIIP header is 32 octets. The header is followed by a payload of length PayloadLen
octets and then a signature of length SigLen octets.¶
Wire = Header(32) || Payload(PayloadLen) || Signature(SigLen)¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-------------------------------+-------------------------------+
| Magic "AIIP" | VerMaj|VerMin| Flags (16) |
+-------------------------------+-------------------------------+
| PayloadLen (32) | SigLen (16) |
+-------------------------------+-------------------------------+
| Nonce (64) |
+---------------------------------------------------------------+
| TimestampMs (64) |
+---------------------------------------------------------------+
Bytes: 0..3 Magic (0x41 49 49 50)
4 VerMaj
5 VerMin
6..7 Flags
8..11 PayloadLen
12..13 SigLen
14..15 Rsv16 (MUST be 0)
16..23 Nonce
24..31 TimestampMs
An HTTPS gateway translates Web-based requests into AIIP invocations and returns results with receipts to human-facing clients.¶
The HTTPS gateway is a compatibility layer for human operators and MUST NOT be required for autonomous or machine-to-machine AIIP invocation.¶
AIIP implementations MUST authenticate peers via the selected transport binding, prevent replay using nonces and timestamps, and ensure integrity of header and payload via signatures.¶
Implementations SHOULD minimize retained metadata and avoid correlating invocations beyond what is required for verification.¶
This document makes no IANA requests.¶
Aram Sogomonian
Artificial Intelligence Internet Foundation (AIIF)
United States of America
Email:
aiinternetfoundation@icloud.com¶