Transport profiles define how ACE envelopes are delivered over various protocols and formats. This repository contains normative specifications for each supported transport mechanism.
Profiles: HTTP Push (draft), iCal Bridge (draft)
The core ACE Specification defines the envelope format, signature scheme, and event semantics. Transport profiles define:
- Protocol-specific delivery mechanisms (HTTP, WebSockets, MQTT, etc.)
- Format conversions (e.g., ACE → iCalendar)
- Discovery and endpoint negotiation
- Retry policies and error handling
- Transport-specific headers and metadata
- HTTP Push (Draft v0.1) — POST-based delivery of ACE envelopes with idempotency and signature verification
- iCal Bridge (Draft v0.1) — HTTP endpoints serving iCalendar (.ics) files derived from ACE envelopes
- HTTP Feed (Planned) — Polling-based feed endpoint returning arrays of ACE envelopes
- Pub/Sub — Event-driven delivery via pub/sub systems (e.g., Google Cloud Pub/Sub, AWS SNS)
- MQTT — Lightweight messaging protocol for IoT and constrained environments
- Server-Sent Events (SSE) — Streaming updates via HTTP EventSource API
Transport profiles are versioned independently from the ACE core specification. Each profile document indicates its version status (e.g., "Draft v0.1", "Stable v1.0").
Compatibility: Profiles aim to remain compatible with ACE Spec v0.1 unless explicitly stated otherwise. Breaking changes to the core spec will require profile updates.
Publishers SHOULD implement discovery via /.well-known/ace.json to advertise supported transports and endpoints.
- OpenAPI 3.1 Spec — Machine-readable API definition for HTTP Push transport
- HTTP Push Conformance Checklist — Requirements checklist for receivers and publishers
See examples/ for:
- ACE envelope samples (
envelopes/) - HTTP request/response examples (
http/) - iCalendar bridge examples (
ical/)
Contributions are welcome. Please see the ACE Project Contributing Guidelines for details.
- Create a new markdown file in
profiles/following the existing profile structure - Include normative MUST/SHOULD/MAY statements
- Provide complete request/response examples
- Update this README with a link and status badge
- Add conformance checklist if applicable
MIT License — see LICENSE for details.