Offline Delivery and Reachability for Agent-to-Agent Messaging

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 2 February 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

[A2A] and similar agent protocols secure the transport hop and authenticate callers, but leave recipient availability underspecified. Roadmaps often name streaming reliability and push notification gaps without a minimal offline profile that a second implementation can falsify.¶

This document specifies that minimal profile:¶

• abstract reachability modes and how they map to live accept versus store-and-forward;¶

• an asleep signal at the HTTP transport layer, with a recommended JSON-RPC error mapping for generic clients;¶

• bounded opaque store-and-forward with validate-on-dequeue;¶

• honest backpressure when queues cannot accept further messages;¶

• security considerations for spam sinks, disk exhaustion, and wake storms.¶

The profile is intentionally narrow. It does not specify push-notification vendor APIs, email bridging, MLS group persistence, or payment authorisation.¶

2. Conventions and Definitions

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.¶

The term Governed Object refers to a signed, purpose-bound, expiring message envelope as described in [GOMLS]. Implementations that do not use Governed Objects MUST still apply equivalent authenticity, expiry, and replay checks before acting on dequeued application payloads.¶

3. Reachability Modes

Implementations MUST document which abstract mode(s) they expose:¶

Informative Atom names: always_on, session, hourly_wake, sleep.¶

4. Asleep Signal

When an implementation refuses live processing because the agent is not currently accepting work (UnavailableStoreForward, or PeriodicallyAvailable outside its window), it MUST signal refusal with a machine-readable error token. This document uses the token agent_asleep.¶

HTTP/1.1 503 Service Unavailable
Content-Type: application/json; charset=utf-8
Retry-After: 840

{"error":"agent_asleep","message":"asleep, try later","queued":true,"retryAfterSec":840}

5. Store-and-Forward

An implementation that queues for offline recipients:¶

• MAY store opaque ciphertext or protocol frames without decrypting them;¶

• MUST bound the queue by maximum message count, maximum total bytes, and maximum pending messages per peer;¶

• MUST apply a time-to-live to each queue record and purge or reject expired records;¶

• MUST authenticate the transport caller before enqueue when the deployment advertises authenticated A2A access, so unauthenticated traffic cannot fill the queue.¶

Recommended reference bounds (informative): 500 messages, 2 MiB total, 50 pending per peer, 7-day default queue TTL. Implementations MUST publish their actual bounds.¶

6. Validate-on-Dequeue

Before an implementation acts on a dequeued Governed Object (or equivalent application payload), it MUST:¶

• verify authenticity and governance constraints (signature, purpose policy, object TTL) using wall-clock time at dequeue — not only enqueue time;¶

• reject replayed object identifiers via a replay cache that survives process restart where the queue itself survives restart;¶

• drain or otherwise discard queue records that fail validation so they do not block later messages indefinitely.¶

Opaque non-application blobs MAY remain deferred until a suitable processor exists; they MUST still respect queue TTL and bounds.¶

Implementations MUST NOT automatically perform consequential side effects (payment capture, secret disclosure, irreversible external mutation) solely because a message was dequeued after wake. Owner or policy confirmation remains out of band to this profile.¶

7. Delivery Semantics

This profile splits two layers:¶

1. Persistence. Queue records that were successfully enqueued MUST survive process restart for their remaining TTL (at-least-once storage).¶

2. Notify after validation. After validate-on-dequeue, implementations that remove the record before durable application accept provide at-most-once notify. Receivers MUST be idempotent on object id via the replay cache.¶

Implementations that retain the queue record until durable accept (true at-least-once notify) MUST document that path. The reference behaviour described here is the split path above.¶

8. Backpressure

When a queue cannot accept a new message because a bound would be exceeded, the implementation MUST signal failure distinctly from agent_asleep.¶

• Error token: asleep_queue_full¶

• HTTP status: 507 for global message or byte caps; 429 for per-peer caps¶

• Response body MUST include error (asleep_queue_full), queued false, and SHOULD include kind (messages, bytes, or peer)¶

The token agent_asleep MUST NOT be returned when enqueue failed. A successful asleep response MUST set queued true only after enqueue succeeds.¶

9. Security Considerations

Offline queues are attractive spam and disk-exhaustion targets. Bounds, transport authentication before enqueue, and per-peer caps mitigate that. Validate-on-dequeue prevents acting on forged, expired, or replayed objects that sat in storage. Distinct queue-full signals prevent senders from treating a refused enqueue as a successful store.¶

Wake windows SHOULD be jittered across agents to reduce thundering herds. Ciphertext queued for an owner MUST remain under owner-volume custody where the deployment model separates control-plane and owner storage.¶

10. IANA Considerations

This document makes no requests of IANA.¶

11. Implementation Status

NOTE: Please remove this section and the reference to [RFC7942] before publication as an RFC.¶

Atom implements this profile in its agent backend asleep-queue and reachability modules. Evidence includes restart persistence, queue bounds, expiry-while-queued, replay rejection on dequeue, sleep 503 with enqueue, hourly wake Retry-After behaviour, and distinct asleep_queue_full responses when enqueue fails.¶

12. References

Appendix A. Acknowledgments

Review comments on companion Governed Object / MLS work informed the validate-on-dequeue and purpose-governance posture referenced here.¶

Author's Address