Scope and versions
Status: draft-01. Working review draft; not a released interoperability contract.
Start with the protocol capabilities for a combined view of the core, live delivery, encryption, authority, and clients. Use this section to implement the contract. For an explanation with messages, start with Follow a command.
Scope and authority
The capability-discovery contract, model, envelope, message definitions, recovery rules, profile and binding requirements, extension requirements, and security/version rules are normative for this draft. Capability discovery applies only when its exact setup contract and binding mapping are selected. The live-delivery and optional encryption and authority requirements apply when their contracts are selected. A selected extension is mandatory in its scope. Saved session protection requirements continue across connections. The designated JSON Schema defines structural constraints. Prose defines behavior and cross-message rules. Both must agree; a conflict is a specification defect.
Guides, diagrams, examples, and design questions are informative. A proposal does not add a core operation. Tests provide evidence only for the cases they execute; they cannot override a requirement.
The core requires no chat interface, actor runtime, storage engine, or programming language. Profiles provide application meaning. Bindings provide transport behavior. No production binding, profile, host, or DASP client is released.
Conventions
Uppercase requirement terms, including MUST, MUST NOT, SHOULD, and MAY, use the meanings in BCP 14, RFC 2119 and RFC 8174. Lowercase words have their ordinary meanings.
Each normative section has a stable requirement or requirement-group ID. A group identifies all constraints in that section, including its field tables. The coverage index links those IDs to executed artifact checks and planned runtime cases. An ID alone does not imply that a runtime test exists.
Layers
| Layer | Responsibility |
|---|---|
| CloudEvents 1.0 | Event identity, source, type, and metadata |
| Capability-discovery setup subprotocol | Reveals one actor profile and a bounded advertised command view before profile confirmation |
| DASP core | Sessions, commands, admission, updates, outcomes, views, and recovery |
| Application profile | Inputs, outputs, state, completion, concurrency, and domain rules |
| Transport binding | Selection, authentication, connection, routing, and delivery |
| DASP extension | Additional selected behavior, dependencies, protection, and recovery requirements |
| Implementation | Runtime, storage, scheduling, and execution |
DASP uses CloudEvents 1.0.2 and its JSON event format. The wire value of specversion is "1.0". CloudEvents does not supply DASP's retry, ordering, or durability rules.
Read the contract
- Capability discovery
- Model and lifecycle
- CloudEvents envelope
- Message shapes
- Admission and recovery
- Profiles and bindings
- Extension contracts
- Security and versions
Capability discovery occurs after selection and authentication of its exact binding mapping. Normal core and extension selection, actor profile confirmation, and session.open occur after discovery. A client with exact configured actor-profile knowledge can omit discovery only under its explicit local policy.
Then inspect the counter example and conformance coverage. Use the source commit with draft-01 when citing this evolving draft. See release preparation for fixed-artifact packaging.
First WebSocket delivery contract
WebSocket live delivery defines subscriptions through session open, fixed-boundary replay, resync, and connection-close stop. It adds no core operation or field. The minimum binding uses a configured secure endpoint, trusted host identity, and one exact contract selection. Normal operation needs no periodic history polling. The minimum binding has no capability-discovery mapping. A later exact mapping can add that optional setup contract without changing the core. A complete production binding still needs exact authenticated setup, shared limit fields and values, health checks and deadlines, and runtime conformance evidence.
Optional binding rules
Encrypted CloudEvent delivery defines optional carrier, key, and recovery rules within the unreleased draft. Issue #5 tracks the work needed for a complete binding. These rules do not change the core message set. Its accepted design scope permits the executing host to read payloads, requires recovery history or attachment refusal, accepts the static reader-key compromise limit, and uses configured trusted keys and the defined setup phases. Exact setup, shared limits, health checks, and independent security evidence remain incomplete. The requirement index records artifact evidence and unexecuted runtime cases without claiming a complete interoperable binding.
Proof of authority defines reusable standing grants carried in a required, selected CloudEvents extension. It keeps profile input, core shapes, semantic retry equality, and encrypted carrier shapes unchanged. Each new admission records its grant use and optional budget charge. Equal authorized retries remain recovery of saved intent. The signed artifacts and recorded decisions do not establish a secure complete binding or a durable host.
Conformance
Read what is tested, run the checks, and inspect the runtime test cases. Passing the artifact suite alone does not establish host conformance.