<?xml version="1.0" encoding="UTF-8"?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude"
     ipr="trust200902"
     submissionType="independent"
     category="exp"
     docName="draft-sogomonian-aiip-architecture-02"
     version="3"
     sortRefs="true"
     symRefs="true"
     tocInclude="true"
     tocDepth="4">

  <front>
    <title abbrev="AIIP Architecture">Architecture for the Artificial Intelligence Internet Protocol (AIIP)</title>

    <author fullname="Aram Sogomonian" initials="A." surname="Sogomonian">
      <organization>Artificial Intelligence Internet Foundation (AIIF)</organization>
      <address>
        <postal>
          <country>US</country>
        </postal>
        <email>aiinternetfoundation@icloud.com</email>
      </address>
    </author>

    <date year="2025" month="December" day="13"/>

    <area>Internet</area>
    <workgroup>Independent Submission</workgroup>

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

    <note>
      <name>Note</name>
      <t>Work in Progress.</t>
    </note>
  </front>

  <middle>

    <section anchor="intro" numbered="true">
      <name>Introduction</name>
      <t>
        AIIP provides a uniform address space and invocation model for AI resources with verifiable
        outcomes. The architecture follows a resolve-invoke-receipt pattern.
      </t>
      <t>
        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.
      </t>
      <t>
        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
        <xref target="RFC2119"/> and <xref target="RFC8174"/> when, and only when, they appear in all
        capitals, as shown here.
      </t>
    </section>

    <section anchor="overview" numbered="true">
      <name>Architectural Overview</name>
      <t>
        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.
      </t>

      <figure anchor="fig-arch">
        <name>Native Autonomous Access and Optional HTTPS Gateway</name>
        <artwork><![CDATA[
      Human Operator
      (UI / Dashboard)
              |
          HTTPS Gateway
              |
        ------------------
        |   AIIP Core    |
        ------------------
          |           |
      Native AIIP   Native AIIP
          |           |
       Robot A     Robot B
        ]]></artwork>
      </figure>
    </section>

    <section anchor="native" numbered="true">
      <name>Native Autonomous Access Model</name>
      <t>
        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.
      </t>
      <t>
        Native AIIP invocation does not depend on HTTP semantics, cookies, or browser-originated
        state. Authorization, policy enforcement, and result verification are defined by AIIP.
      </t>
      <t>
        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.
      </t>
    </section>

    <section anchor="resolution" numbered="true">
      <name>Resolution</name>
      <t>
        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.
      </t>

      <figure anchor="fig-resolution">
        <name>Resolution Flow (Illustrative)</name>
        <artwork><![CDATA[
Client            Resolver             Authority
  |  aiip://...      |                     |
  |----------------->|                     |
  |                  | validate delegation |
  |                  |-------------------> |
  |                  |<------------------- |
  |                  | return signed IDesc |
  |<-----------------|                     |
        ]]></artwork>
      </figure>

      <t>
        Clients MUST validate the authenticity and integrity of the IDesc prior to invocation.
      </t>
    </section>

    <section anchor="envelope" numbered="true">
      <name>AIIP Envelope</name>

      <section anchor="envelope-framing" numbered="true">
        <name>Framing and Byte Order</name>
        <t>
          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.
        </t>
        <t>
          An AIIP message is:
        </t>
        <t>
          <tt>AIIP-Message = AIIP-Header || Payload || Signature</tt>
        </t>
        <t>
          Where <tt>||</tt> denotes concatenation.
        </t>
      </section>

      <section anchor="envelope-header" numbered="true">
        <name>Header Layout</name>
        <t>
          The AIIP header is 32 octets. The header is followed by a payload of length <tt>PayloadLen</tt>
          octets and then a signature of length <tt>SigLen</tt> octets.
        </t>

        <t>
          <tt>Wire = Header(32) || Payload(PayloadLen) || Signature(SigLen)</tt>
        </t>

        <figure anchor="fig-header">
          <name>AIIP Header (32 bytes)</name>
          <artwork><![CDATA[
  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
          ]]></artwork>
        </figure>

      </section>

    </section>

    <section anchor="gateway" numbered="true">
      <name>HTTPS Gateway Profile</name>
      <t>
        An HTTPS gateway translates Web-based requests into AIIP invocations and returns results with
        receipts to human-facing clients.
      </t>
      <t>
        The HTTPS gateway is a compatibility layer for human operators and MUST NOT be required for
        autonomous or machine-to-machine AIIP invocation.
      </t>
    </section>

    <section anchor="security" numbered="true">
      <name>Security Considerations</name>
      <t>
        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.
      </t>
    </section>

    <section anchor="privacy" numbered="true">
      <name>Privacy Considerations</name>
      <t>
        Implementations SHOULD minimize retained metadata and avoid correlating invocations beyond
        what is required for verification.
      </t>
    </section>

    <section anchor="iana" numbered="true">
      <name>IANA Considerations</name>
      <t>
        This document makes no IANA requests.
      </t>
    </section>

  </middle>

  <back>

    <references>
      <name>Normative References</name>

      <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119">
        <front>
          <title>Key words for use in RFCs to Indicate Requirement Levels</title>
          <author initials="S." surname="Bradner"/>
          <date year="1997" month="March"/>
        </front>
        <seriesInfo name="RFC" value="2119"/>
      </reference>

      <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174">
        <front>
          <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
          <author initials="B." surname="Leiba"/>
          <date year="2017" month="May"/>
        </front>
        <seriesInfo name="RFC" value="8174"/>
      </reference>

    </references>

    <section numbered="false">
      <name>Author's Address</name>
      <t>
        Aram Sogomonian<br/>
        Artificial Intelligence Internet Foundation (AIIF)<br/>
        United States of America<br/>
        Email:
        <eref target="mailto:aiinternetfoundation@icloud.com">aiinternetfoundation@icloud.com</eref>
      </t>
    </section>

  </back>

</rfc>
