Independent Submission E. P. Nagulapalli Internet-Draft Servesys Labs Intended status: Standards Track 24 November 2025 Expires: 28 May 2026 AI-Native Network Protocol (AINP) for Semantic Agent Communication draft-ainp-protocol-00 Abstract This document specifies the AI-Native Network Protocol (AINP) version 0.1, a semantic communication protocol designed for intent exchange between AI agents. AINP replaces location-based routing with semantic routing, byte-stream delivery with intent delivery, and simple handshakes with multi-round negotiation. AINP enables agents to discover each other by capability rather than network location, negotiate terms autonomously, and exchange structured intents with cryptographic security. 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 28 May 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Nagulapalli Expires 28 May 2026 [Page 1] Internet-Draft AINP Protocol November 2025 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 . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 1.1.1. Definitions . . . . . . . . . . . . . . . . . . . . . 4 2. Architecture Overview . . . . . . . . . . . . . . . . . . . . 4 3. Wire Format . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 4 3.2. Message Envelope . . . . . . . . . . . . . . . . . . . . 5 3.2.1. Envelope Fields . . . . . . . . . . . . . . . . . . . 5 3.3. Message Types . . . . . . . . . . . . . . . . . . . . . . 5 3.4. Quality of Service Parameters . . . . . . . . . . . . . . 5 3.5. Capability Query . . . . . . . . . . . . . . . . . . . . 6 3.6. Signature Format . . . . . . . . . . . . . . . . . . . . 6 4. Semantic Addresses . . . . . . . . . . . . . . . . . . . . . 6 4.1. Decentralized Identifiers (DIDs) . . . . . . . . . . . . 6 4.2. Semantic Address Structure . . . . . . . . . . . . . . . 7 5. Intent Schemas . . . . . . . . . . . . . . . . . . . . . . . 7 5.1. REQUEST_MEETING Intent . . . . . . . . . . . . . . . . . 7 5.2. APPROVAL_REQUEST Intent . . . . . . . . . . . . . . . . . 7 5.3. SUBMIT_INFO Intent . . . . . . . . . . . . . . . . . . . 8 5.4. INVOICE Intent . . . . . . . . . . . . . . . . . . . . . 8 5.5. FREEFORM_NOTE Intent . . . . . . . . . . . . . . . . . . 8 5.6. REQUEST_SERVICE Intent . . . . . . . . . . . . . . . . . 9 6. Negotiation Protocol . . . . . . . . . . . . . . . . . . . . 9 6.1. Negotiation Flow . . . . . . . . . . . . . . . . . . . . 9 6.2. Negotiation Message Structure . . . . . . . . . . . . . . 9 6.3. Negotiation Convergence . . . . . . . . . . . . . . . . . 9 6.4. Timeout Behavior . . . . . . . . . . . . . . . . . . . . 10 6.5. Multi-Party Negotiation . . . . . . . . . . . . . . . . . 10 7. Protocol Handshake Sequence . . . . . . . . . . . . . . . . . 10 7.1. Five-Step Handshake . . . . . . . . . . . . . . . . . . . 10 7.2. ADVERTISE Phase . . . . . . . . . . . . . . . . . . . . . 10 7.3. DISCOVER Phase . . . . . . . . . . . . . . . . . . . . . 11 7.4. ERROR Phase . . . . . . . . . . . . . . . . . . . . . . . 11 7.5. Offline Intent Queueing . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8.1. Authentication . . . . . . . . . . . . . . . . . . . . . 12 8.2. Identity . . . . . . . . . . . . . . . . . . . . . . . . 12 Nagulapalli Expires 28 May 2026 [Page 2] Internet-Draft AINP Protocol November 2025 8.3. Rate Limiting . . . . . . . . . . . . . . . . . . . . . . 12 8.4. Replay Protection . . . . . . . . . . . . . . . . . . . . 12 8.5. DoS Protection . . . . . . . . . . . . . . . . . . . . . 13 8.6. Replay Protection and Delivery Semantics . . . . . . . . 13 8.7. Capability Attestations . . . . . . . . . . . . . . . . . 13 8.8. Timeouts . . . . . . . . . . . . . . . . . . . . . . . . 13 8.9. Outlier Detection . . . . . . . . . . . . . . . . . . . . 13 8.10. Discovery Scalability . . . . . . . . . . . . . . . . . . 13 8.11. Lite Mode for Resource-Constrained Agents . . . . . . . . 14 9. CBOR Encoding (Optional) . . . . . . . . . . . . . . . . . . 15 10. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 15 10.1. Custom Intent Types . . . . . . . . . . . . . . . . . . 15 10.2. Custom Negotiation Terms . . . . . . . . . . . . . . . . 15 10.3. Versioning . . . . . . . . . . . . . . . . . . . . . . . 15 10.4. Lite Profile (Trusted Networks) . . . . . . . . . . . . 15 11. Success Metrics . . . . . . . . . . . . . . . . . . . . . . . 16 11.1. Route Success Rate . . . . . . . . . . . . . . . . . . . 16 11.2. Latency (p95) . . . . . . . . . . . . . . . . . . . . . 16 11.3. Negotiation Completion Rate . . . . . . . . . . . . . . 16 11.4. False Route Rate . . . . . . . . . . . . . . . . . . . . 16 11.5. Abuse Resilience . . . . . . . . . . . . . . . . . . . . 16 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 13.2. Informative References . . . . . . . . . . . . . . . . . 17 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 1. Introduction Traditional network protocols (TCP/IP, HTTP, SMTP) were designed for reliable byte stream delivery between machines. AINP represents a paradigm shift: it is designed for semantic intent delivery between AI agents, with built-in understanding, negotiation, and adaptation. AINP Phase 0.1 provides: - Wire format specification (JSON-LD + CBOR) - Message envelope structure with cryptographic signatures - Intent schemas for common agent interactions - Semantic address format with Decentralized Identifiers (DIDs) - Negotiation protocol for multi- agent consensus - Discovery and routing mechanisms 1.1. Terminology 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]. Nagulapalli Expires 28 May 2026 [Page 3] Internet-Draft AINP Protocol November 2025 1.1.1. Definitions *Agent*: An autonomous software entity capable of semantic understanding and intent exchange *Intent*: A semantic representation of an agent's goal, including embeddings and structured semantics *Semantic Address*: An identity-based address using DIDs and capability descriptors *Negotiation*: Multi-round protocol for establishing consensus on resources, terms, and capabilities *Capability*: A semantic description of what an agent can do, including natural language and embeddings *Trust Vector*: Multi-dimensional reputation score tracking reliability, honesty, competence, and timeliness 2. Architecture Overview AINP consists of four layers: +-----------------------------+ | Intent Layer | Semantic exchange (intents) +-----------------------------+ | Negotiation Layer | Multi-agent consensus +-----------------------------+ | Routing Layer | Semantic routing +-----------------------------+ | Substrate Layer | Physical transport (TCP/IP, etc.) +-----------------------------+ Phase 0.1 runs as an overlay network on TCP/IP with WebSocket or HTTP/3 transport. 3. Wire Format 3.1. Encoding AINP messages MUST support both: - *JSON-LD*: Human-readable, linked data format with @context for semantic interoperability - *CBOR*: Binary encoding ([RFC8949]) for efficient transmission Implementations SHOULD negotiate encoding during handshake. JSON-LD is the default for Phase 0.1. Nagulapalli Expires 28 May 2026 [Page 4] Internet-Draft AINP Protocol November 2025 3.2. Message Envelope All AINP messages MUST be wrapped in an envelope structure: json { "version": "0.1.0", "msg_type": "INTENT", "id": "550e8400- e29b-41d4-a716-446655440000", "timestamp": 1728259400000, "ttl": 30000, "trace_id": "trace-abc123", "from_did": "did:key:z6Mk...", "to_did": "did:key:z6Mk...", "schema": "https://ainp.dev/schemas/intents/request-meeting/v1", "qos": { "urgency": 0.7, "importance": 0.8, "novelty": 0.1, "ethicalWeight": 0.5, "bid": 5 }, "payload": { ... }, "sig": "base64signature..." } 3.2.1. Envelope Fields * version (string, REQUIRED): Protocol version, MUST be "0.1.0" * msg_type (string, REQUIRED): Message type (see Section 3.3) * id (string, REQUIRED): UUID v4 for message identification * timestamp (number, REQUIRED): Unix epoch milliseconds * ttl (number, REQUIRED): Time-to-live in milliseconds * trace_id (string, REQUIRED): Distributed tracing UUID for thread tracking * from_did (string, REQUIRED): Sender DID ([W3C.DID]) * to_did (string, OPTIONAL): Recipient DID (for direct addressing) * to_query (object, OPTIONAL): Semantic query (alternative to to_did, see Section 3.5) * schema (string, REQUIRED): JSON-LD context URI * qos (object, REQUIRED): Quality of Service parameters (see Section 3.4) * payload (object, OPTIONAL): Application payload (intent, negotiation, etc.) * sig (string, REQUIRED): Ed25519 signature in base64 encoding 3.3. Message Types AINP defines the following message types: * ADVERTISE: Publish capabilities to discovery index * DISCOVER: Query for agents by capability * DISCOVER_RESULT: Discovery results * NEGOTIATE: Multi-round negotiation * INTENT: Send intent payload * RESULT: Response with optional proof * ERROR: Error response 3.4. Quality of Service Parameters QoS parameters enable priority-based routing and resource allocation: Nagulapalli Expires 28 May 2026 [Page 5] Internet-Draft AINP Protocol November 2025 json { "urgency": 0.7, // 0-1, time sensitivity "importance": 0.8, // 0-1, impact magnitude "novelty": 0.1, // 0-1, information gain "ethicalWeight": 0.5, // 0-1, moral importance "bid": 5 // Token amount or credits (non-negative) } *Priority Calculation*: Implementations SHOULD calculate message priority as: priority = (urgency * w_urgency) + (importance * w_importance) + (novelty * w_novelty) + (ethicalWeight * w_ethical) adjusted_priority = priority + 0.5 * tanh(bid / bid_scale) Where bid_scale is node-configurable (RECOMMENDED default: 10 credits). *Default Weights*: - w_urgency = 0.3 - w_importance = 0.3 - w_novelty = 0.2 - w_ethical = 0.2 3.5. Capability Query For semantic discovery, agents use capability queries: json { "description": "Find agents who can schedule meetings", "embedding": "base64-encoded Float32Array[1536]", "tags": ["scheduling", "calendar"], "min_trust": 0.7, "max_latency_ms": 5000, "max_cost": 10 } 3.6. Signature Format Messages MUST be signed using Ed25519 ([Ed25519]) with detached signatures in base64 encoding. *Signing Process*: 1. Serialize envelope fields (excluding sig) to canonical JSON ([RFC8785]) 2. Compute SHA-256 hash of canonical JSON 3. Sign hash with Ed25519 private key 4. Encode signature as base64 5. Add sig field to envelope *Verification Process*: 1. Extract sig field 2. Remove sig from envelope 3. Serialize remaining fields to canonical JSON ([RFC8785]) 4. Compute SHA-256 hash 5. Verify signature using Ed25519 public key from from_did 4. Semantic Addresses 4.1. Decentralized Identifiers (DIDs) Agents MUST have a DID conforming to [W3C.DID]. Nagulapalli Expires 28 May 2026 [Page 6] Internet-Draft AINP Protocol November 2025 *Supported DID Methods* (Phase 0.1): - did:key: - Self-certified cryptographic keys - did:web: - Web-based identifiers 4.2. Semantic Address Structure json { "did": "did:key:z6Mk...", "capabilities": [ { "description": "Schedule meetings with calendar integration", "embedding": { "b64": "base64-encoded float32 array", "dim": 1536, "dtype": "f32", "model": "openai:text-embedding-3-small" }, "tags": ["scheduling", "calendar"], "version": "1.0.0", "evidence": "https://credentials.example.com/vc/scheduling" } ], "trust": { "score": 0.85, "dimensions": { "reliability": 0.9, "honesty": 0.85, "competence": 0.8, "timeliness": 0.85 }, "decay_rate": 0.977, "last_updated": 1728259200000 }, "credentials": ["https://credentials.example.com/vc/scheduling"] } 5. Intent Schemas AINP defines six core intent types for Phase 0.1. All intents MUST include: - JSON-LD @context for semantic interoperability - Embedding (Embedding object; base64 Float32Array inside b64) - Budget constraints - Semantic payload 5.1. REQUEST_MEETING Intent *Schema URI*: https://ainp.dev/schemas/intents/request-meeting/v1 json { "@context": "https://ainp.dev/contexts/meeting/v1", "@type": "RequestMeeting", "version": "1.0.0", "embedding": { "b64": "base64-encoded Float32Array", "dim": 1536, "dtype": "f32", "model": "openai:text-embedding-3-small" }, "semantics": { "participants": ["did:key:..."], "duration_minutes": 30, "preferred_times": ["2025-10-07T14:00:00Z"], "location": "virtual", "constraints": { "timezone": "America/Los_Angeles", "max_latency_ms": 5000, "min_notice_hours": 24 } }, "budget": { "max_credits": 10, "max_rounds": 5, "timeout_ms": 30000 } } 5.2. APPROVAL_REQUEST Intent *Schema URI*: https://ainp.dev/schemas/intents/approval-request/v1 Nagulapalli Expires 28 May 2026 [Page 7] Internet-Draft AINP Protocol November 2025 json { "@context": "https://ainp.dev/contexts/approval/v1", "@type": "ApprovalRequest", "version": "1.0.0", "embedding": { "b64": "...", "dim": 1536, "dtype": "f32" }, "semantics": { "request_type": "purchase", "description": "Purchase office supplies", "amount": 500, "currency": "USD", "justification": "Quarterly restock", "deadline": "2025-10-10T00:00:00Z", "approvers": ["did:key:..."], "threshold": 1, "constraints": { "requires_attestation": true, "max_latency_ms": 5000 } }, "budget": { "max_credits": 10, "max_rounds": 5, "timeout_ms": 30000 } } 5.3. SUBMIT_INFO Intent *Schema URI*: https://ainp.dev/schemas/intents/submit-info/v1 json { "@context": "https://ainp.dev/contexts/submit-info/v1", "@type": "SubmitInfo", "version": "1.0.0", "embedding": { "b64": "...", "dim": 1536, "dtype": "f32" }, "semantics": { "data_type": "form", "payload": { "field1": "value1" }, "schema_ref": "https://example.com/schema.json", "privacy_level": "encrypted", "retention_policy": { "duration_days": 90, "delete_after": true }, "constraints": { "requires_acknowledgment": true, "max_latency_ms": 5000 } }, "budget": { "max_credits": 5, "max_rounds": 3, "timeout_ms": 15000 } } 5.4. INVOICE Intent *Schema URI*: https://ainp.dev/schemas/intents/invoice/v1 json { "@context": "https://ainp.dev/contexts/invoice/v1", "@type": "Invoice", "version": "1.0.0", "embedding": { "b64": "...", "dim": 1536, "dtype": "f32" }, "semantics": { "invoice_id": "INV-2025-001", "from": "did:key:...", "to": "did:key:...", "amount": "1000.00", "currency": "USD", "line_items": [ { "description": "Service fee", "quantity": 1, "unit_price": "1000.00", "total": "1000.00" } ], "due_date": "2025-11-01T00:00:00Z", "payment_methods": ["crypto", "wire"], "constraints": { "requires_escrow": true, "max_latency_ms": 10000 } }, "budget": { "max_credits": 5, "max_rounds": 3, "timeout_ms": 30000 } } 5.5. FREEFORM_NOTE Intent *Schema URI*: https://ainp.dev/schemas/intents/freeform-note/v1 json { "@context": "https://ainp.dev/contexts/freeform/v1", "@type": "FreeformNote", "version": "1.0.0", "embedding": { "b64": "...", "dim": 1536, "dtype": "f32" }, "semantics": { "subject": "Meeting notes", "body": "Discussion summary...", "format": "markdown", "attachments": [ { "url": "https://example.com/doc.pdf", "mime_type": Nagulapalli Expires 28 May 2026 [Page 8] Internet-Draft AINP Protocol November 2025 "application/pdf", "size_bytes": 102400, "hash": "sha256:abc123..." } ], "thread_id": "thread-123", "in_reply_to": "msg-456", "constraints": { "max_latency_ms": 5000 } }, "budget": { "max_credits": 1, "max_rounds": 1, "timeout_ms": 10000 } } 5.6. REQUEST_SERVICE Intent *Schema URI*: https://ainp.dev/schemas/intents/request-service/v1 json { "@context": "https://ainp.dev/contexts/service/v1", "@type": "RequestService", "version": "1.0.0", "embedding": { "b64": "...", "dim": 1536, "dtype": "f32" }, "semantics": { "service_type": "plumbing.leak.fix", "geo": { "lat": 37.7749, "lon": -122.4194, "radiusKm": 10, "zip": "94102" }, "time_window": { "earliest": "2025-10-08T09:00:00Z", "latest": "2025-10-08T17:00:00Z" }, "constraints": { "eco": true, "access_notes": "Ring doorbell", "evidence_required": ["photo_before_after"] }, "details": { "urgency": "high", "description": "Kitchen sink leak" } }, "budget": { "max_credits": 20, "max_total": 200, "escrow_required": true, "max_rounds": 10, "timeout_ms": 60000 } } 6. Negotiation Protocol 6.1. Negotiation Flow Negotiation MUST follow this state machine: START -> OFFER -> COUNTER <-> COUNTER -> ACCEPT | | ABORT TIMEOUT | | REJECT REJECT 6.2. Negotiation Message Structure json { "negotiation_id": "uuid", "round": 1, "phase": "OFFER", "proposal": { "price": 100, "latency_ms": 500, "confidence": 0.9, "privacy": "encrypted", "terms": {} }, "constraints": { "max_rounds": 10, "timeout_per_round_ms": 5000, "convergence_threshold": 0.9 } } *Negotiation Phases*: - OFFER: Initial offer - COUNTER: Counter-offer - ACCEPT: Accept proposal - REJECT: Reject and end - ABORT: Abort negotiation - TIMEOUT: Timeout occurred 6.3. Negotiation Convergence Implementations MAY auto-accept proposals when convergence threshold is met: ``` convergence_score = 1 - (abs(offer.price - counter.price) / max(offer.price, counter.price)) Nagulapalli Expires 28 May 2026 [Page 9] Internet-Draft AINP Protocol November 2025 if convergence_score >= convergence_threshold: auto_accept() ``` 6.4. Timeout Behavior * *Per-round timeout*: If no response within timeout_per_round_ms, sender MAY send TIMEOUT message * *Overall timeout*: If negotiation exceeds max_rounds * timeout_per_round_ms, MUST terminate with TIMEOUT 6.5. Multi-Party Negotiation For intents involving multiple agents (e.g., scheduling a meeting with 5 participants, multi-signature approvals), negotiation MUST support group consensus mechanisms. *Group Proposal Structure*: json { "negotiation_id": "multi-abc123", "phase": "OFFER", "proposal": { "participants": ["did:key:agent-a", "did:key:agent-b", "did:key:agent-c"], "voting_mechanism": "majority", "convergence_threshold": 0.75, "terms": { "preferred_times": ["2025-10-07T14:00:00Z", "2025-10-07T15:00:00Z"], "duration_minutes": 30 } } } *Voting Mechanisms*: 1. *Unanimous*: All agents must ACCEPT (default for high-stakes) 2. *Majority*: More than 50% must ACCEPT 3. *Weighted*: Votes weighted by trust scores *Multi-Party Flow*: 1. Fan-out: Send NEGOTIATE(OFFER) to all participants 2. Collection: Each agent responds with individual proposal 3. Aggregation: Broker aggregates and computes consensus score 4. Convergence Check: Compare score to threshold 5. Auto- accept if converged, else synthesize counter-proposal and repeat 6. Termination: ABORT after max_rounds or timeout if no consensus 7. Protocol Handshake Sequence 7.1. Five-Step Handshake 1. *ADVERTISE*: Agent publishes capabilities to discovery index 2. *DISCOVER*: Agent queries for matching capabilities 3. *NEGOTIATE*: Agents negotiate terms (OFFER → COUNTER → ACCEPT) 4. *INTENT*: Agent sends intent after successful negotiation 5. *RESULT*: Recipient responds with result 7.2. ADVERTISE Phase Agent publishes capabilities to discovery index: Nagulapalli Expires 28 May 2026 [Page 10] Internet-Draft AINP Protocol November 2025 json { "version": "0.1.0", "msg_type": "ADVERTISE", "id": "550e8400- e29b-41d4-a716-446655440000", "timestamp": 1728259200000, "ttl": 86400000, "trace_id": "trace-abc123", "from_did": "did:key:z6Mk...", "schema": "https://ainp.dev/schemas/advertise/v1", "qos": { "urgency": 0.1, "importance": 0.5, "novelty": 0.3, "ethicalWeight": 0.5, "bid": 0 }, "sig": "base64signature...", "payload": { "capabilities": [ { "description": "Schedule meetings with calendar integration", "embedding": { "b64": "...", "dim": 1536, "dtype": "f32" }, "tags": ["scheduling", "calendar"], "version": "1.0.0", "evidence": "https://credentials.example.com/vc/scheduling" } ], "trust": { "score": 0.85, "dimensions": { "reliability": 0.9, "honesty": 0.85, "competence": 0.8, "timeliness": 0.85 }, "decay_rate": 0.977, "last_updated": 1728259200000 }, "credentials": ["https://credentials.example.com/vc/scheduling"] } } 7.3. DISCOVER Phase Agent queries for capabilities: json { "version": "0.1.0", "msg_type": "DISCOVER", "id": "660e8400- e29b-41d4-a716-446655440001", "timestamp": 1728259300000, "ttl": 10000, "trace_id": "trace-def456", "from_did": "did:key:z6Mk...", "to_query": { "description": "Find agents who can schedule meetings", "embedding": "base64...", "tags": ["scheduling", "calendar"], "min_trust": 0.7, "max_latency_ms": 5000, "max_cost": 10 }, "schema": "https://ainp.dev/schemas/discover/v1", "qos": { "urgency": 0.5, "importance": 0.7, "novelty": 0.2, "ethicalWeight": 0.5, "bid": 1 }, "sig": "base64signature..." } Discovery index responds with DISCOVER_RESULT containing matching agents with similarity scores, trust ratings, and estimated latency. 7.4. ERROR Phase On error, agent MUST respond with ERROR message: json { "msg_type": "ERROR", "error_code": "TIMEOUT", "error_message": "Negotiation timed out", "intent_id": "770e8400-e29b- 41d4-a716-446655440002", "retry_after_ms": 5000 } *Standard Error Codes*: - INVALID_SIGNATURE - UNAUTHORIZED - UNSUPPORTED_SCHEMA - TIMEOUT - RATE_LIMIT_EXCEEDED - INSUFFICIENT_CREDITS - NEGOTIATION_FAILED - ESCROW_REQUIRED - EVIDENCE_INSUFFICIENT - DUPLICATE_INTENT - AGENT_OFFLINE - INTERNAL_ERROR Nagulapalli Expires 28 May 2026 [Page 11] Internet-Draft AINP Protocol November 2025 7.5. Offline Intent Queueing When recipient agent is offline or unreachable, broker MAY queue intents for later delivery instead of immediately failing. *Queue Behavior*: - TTL enforcement: Intent expires after ttl milliseconds from original timestamp - Broker SHOULD send ERROR to sender immediately: error_code: "AGENT_OFFLINE" - ERROR response SHOULD include retry_after_ms field - Broker MUST NOT queue intents indefinitely (maximum queue time = ttl) *Queue Delivery Protocol*: 1. Agent Offline Detection: Broker detects agent offline 2. Queue Intent: Insert into queue with expires_at = timestamp + ttl 3. Send ERROR: Notify sender with AGENT_OFFLINE and retry_after_ms 4. Agent Reconnect: When agent comes online, broker delivers queued intents in priority order 5. Delivery Ordering: Process queue as FIFO within each priority level 6. Retry Logic: If delivery fails, increment retry_count and retry after exponential backoff 7. Expiration Cleanup: Periodically purge expired intents 8. Security Considerations 8.1. Authentication * All messages MUST be signed with Ed25519 * Signatures MUST be verifiable using public key from from_did * Unsigned messages MUST be rejected 8.2. Identity * Agents MUST have a valid [W3C.DID] * DIDs MUST be resolvable to DID documents containing public keys 8.3. Rate Limiting Implementations MUST enforce rate limits: - Default: 100 intents per minute per agent - Burst: Up to 200 intents in 10-second window - Discovery queries: 10 per minute per agent 8.4. Replay Protection Recipients MUST reject duplicate messages with the same (from_did, id) seen within ttl + 60000ms. Nagulapalli Expires 28 May 2026 [Page 12] Internet-Draft AINP Protocol November 2025 8.5. DoS Protection Implementations MUST: - Validate message signatures before processing - Enforce TTL (drop expired messages) - Limit negotiation rounds (max 10) - Reject messages exceeding 1MB payload size - Require attachments by reference (URLs) rather than inlining large binaries 8.6. Replay Protection and Delivery Semantics * Recipients MUST reject duplicate messages with the same (from_did, id) seen within ttl + 60000ms * Implementations MUST allow a clock skew of +/-60000ms when validating timestamp * At-least-once delivery is RECOMMENDED; senders MUST use UUID v4 ids and recipients MUST make intent handling idempotent with respect to id 8.7. Capability Attestations * Agents advertising capabilities SHOULD provide Verifiable Credentials (VCs) * VCs MUST conform to [W3C.VC] * Discovery indices MAY reject advertisements without VCs 8.8. Timeouts * *Intent delivery*: 60 seconds default TTL * *Negotiation per round*: 5 seconds default * *Overall negotiation*: 30 seconds default * *Discovery query*: 10 seconds default 8.9. Outlier Detection Discovery indices SHOULD flag agents with: - Trust score < 0.3 - Capability embeddings >3 standard deviations from cluster mean (potential false advertising) - Success rate < 50% over last 100 intents 8.10. Discovery Scalability *Phase 0.1 Architecture*: Centralized discovery index using PostgreSQL with pgvector extension for semantic search. *Vector Indexing*: Discovery indices SHOULD use Approximate Nearest Neighbor (ANN) indexing for efficient semantic search at scale. Nagulapalli Expires 28 May 2026 [Page 13] Internet-Draft AINP Protocol November 2025 *Recommended Algorithm*: HNSW (Hierarchical Navigable Small World) - *Structure*: Multi-layer graph with hierarchical routing - *Parameters*: m = 16, ef_construction = 64, ef_search = 40 - *Distance Metric*: Cosine similarity - *Performance*: ~10ms search latency for 1M agents, ~99% recall *Scaling Strategies*: 1. *Vertical Scaling*: Increase HNSW parameters, use NVMe SSDs, scale PostgreSQL memory 2. *Horizontal Scaling*: Read replicas, connection pooling (PgBouncer), Redis caching 3. *Partitioning*: Capability sharding, tag-based routing, geographic partitioning 4. *Query Optimization*: Pre-filtering, batch queries, approximate search *Performance Benchmarks* (Phase 0.1 targets): +=============+============+============+===============+===========+ | Agent Count | Index Size | Build | Query Latency | Recall@10 | | | | Time | (p95) | | +=============+============+============+===============+===========+ | 1K | 2 MB | 5s | 2ms | 99.5% | +-------------+------------+------------+---------------+-----------+ | 10K | 20 MB | 45s | 5ms | 99.2% | +-------------+------------+------------+---------------+-----------+ | 100K | 200 MB | 8 min | 12ms | 98.8% | +-------------+------------+------------+---------------+-----------+ | 1M | 2 GB | 90 | 25ms | 98.0% | | | | min | | | +-------------+------------+------------+---------------+-----------+ Table 1 8.11. Lite Mode for Resource-Constrained Agents For lightweight agents (e.g., IoT devices, mobile, embedded systems), implementations MAY use a minimal envelope to reduce payload size and processing overhead. *Required Fields*: version, msg_type, id, timestamp, from_did, to_did, sig *Optional Fields* (MAY be omitted): - ttl (default: 60000ms) - trace_id (no distributed tracing) - to_query (explicit addressing only) - capabilities_ref (no VC attestations) - attestations (trust by DID only) - qos (default: all 0.5, bid 0) Nagulapalli Expires 28 May 2026 [Page 14] Internet-Draft AINP Protocol November 2025 *Lite Mode Constraints*: - Lite mode SHOULD NOT be used for high- stakes intents - Agents using lite mode MUST still provide valid Ed25519 signatures - Discovery indices MAY reject lite mode advertisements - Brokers MAY apply lower trust scores to lite mode agents by default 9. CBOR Encoding (Optional) For efficiency, implementations MAY use CBOR ([RFC8949]) encoding: *Key Map (v0.1)*: - 1: version - 2: msg_type - 3: id - 4: timestamp - 5: ttl - 6: trace_id - 7: from_did - 8: to_did - 9: to_query - 10: schema - 11: qos - 12: capabilities_ref - 13: attestations - 14: payload - 15: sig CBOR encoding SHOULD be negotiated during ADVERTISE or DISCOVER phase. 10. Extensibility 10.1. Custom Intent Types Agents MAY define custom intent types beyond the core set. Custom intents MUST: - Include @context with unique URI - Include version field - Include embedding field - Include budget constraints - Register schema URI in public registry (future) 10.2. Custom Negotiation Terms Proposal.terms field allows extensible negotiation parameters. Common extensions: - privacy_guarantees: ZK proof requirements - sla_guarantees: Service level agreements - data_retention: Data retention policies 10.3. Versioning AINP uses semantic versioning. Breaking changes MUST increment major version. Phase 0.1 is backwards-compatible within 0.x series. 10.4. Lite Profile (Trusted Networks) In trusted or closed-network deployments, the following simplifications are PERMITTED: - Omit capabilities_ref and attestations if peers are pre-authorized - Prefer JSON-LD for small payloads; negotiate CBOR for payloads > 4KB - Allow to_query-only routing within a single administrative domain Nagulapalli Expires 28 May 2026 [Page 15] Internet-Draft AINP Protocol November 2025 Nodes MUST still sign messages, enforce TTLs, and implement replay protection. 11. Success Metrics 11.1. Route Success Rate route_success_rate = (intents_delivered_correctly / total_intents_sent) × 100% *Target (Phase 0.1)*: >=95% 11.2. Latency (p95) 95th percentile time from INTENT sent to RESULT received. *Target (Phase 0.1)*: <=2000ms 11.3. Negotiation Completion Rate negotiation_completion_rate = (negotiations_accepted / total_negotiations) * 100 *Target (Phase 0.1)*: >=80% 11.4. False Route Rate false_route_rate = (intents_misrouted / total_intents_sent) * 100 *Target (Phase 0.1)*: <=5% 11.5. Abuse Resilience Detection rate of: - DoS attacks (>1000 requests/min from single agent) - Sybil attacks (multiple DIDs from same source) - False capability advertising (capability mismatch >0.5 cosine distance) *Target (Phase 0.1)*: >=90% detection rate 12. IANA Considerations This document has no IANA actions. 13. References 13.1. Normative References Nagulapalli Expires 28 May 2026 [Page 16] Internet-Draft AINP Protocol November 2025 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, . [W3C.DID] W3C, "Decentralized Identifiers (DIDs) v1.0", 19 July 2022, . [W3C.VC] W3C, "Verifiable Credentials Data Model v1.1", 3 March 2022, . 13.2. Informative References [Ed25519] Bernstein, D. J., Duif, N., Lange, T., Schwabe, P., and B. Yang, "High-speed high-security signatures", 26 September 2011, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, . Author's Address Eswara Prasad Nagulapalli Servesys Labs Email: contact@servsys.com Nagulapalli Expires 28 May 2026 [Page 17]