Specify supported AsyncAPI version(s) for `asyncapi` source descriptions (tighten to v3)

Arazzo 1.1.0 added "asyncapi" as a Source Description Object type, together with the Step Object channelPath field and the action field ("send" / "receive"). However, the specification never states which AsyncAPI version(s) are in scope, and the current wording is ambiguous — arguably contradictory — when applied to AsyncAPI v2 documents.

Current wording

Source Description Object, type:

The type of source description. Possible values are "openapi" or "asyncapi" or "arazzo".

Step Object, action:

Describes the message flow intent. Indicates whether the step will send (publish) or receive (subscribe) to a channel in an AsyncAPI document. Only applicable for asyncapi steps. Possible values are "send" or "receive".

No AsyncAPI version number appears anywhere in the document.

Why this is a problem

1. send/receive is AsyncAPI v3 terminology, but the parentheticals imply a v2 mapping, and that mapping is inverted. AsyncAPI v2 operations are written from the application's perspective: a v2 publish operation means clients publish to the application (the application receives), and subscribe means the application sends. This inverted perspective is precisely what AsyncAPI v3 replaced with send/receive. As written, "send (publish)" suggests an Arazzo send step maps to a v2 publish operation, which for a workflow-executing client is arguably the wrong direction. Two conforming implementations can reasonably resolve the same step against the same v2 document to opposite operations.

2. operationId resolution differs structurally between v2 and v3. In v2, operationId lives on publish/subscribe operations nested inline under channels; in v3, operations are first-class objects in a top-level operations map, each carrying its own action. The specification gives no normative resolution rule for either shape.

3. The channelPath JSON Pointer shape differs between versions. A pointer into a v2 document addresses channels containing inline operations; in v3 it addresses channels that operations reference. Without a version statement, workflow authors cannot know what a portable channelPath looks like, and tooling cannot validate one.

4. Interoperability. "Supports Arazzo 1.1" is currently ambiguous with respect to AsyncAPI: an implementation supporting only v3 and one attempting v2 will both claim conformance while accepting disjoint sets of documents and, per point 1, potentially disagreeing on step semantics for the overlap.

Relationship to #270

#270 recorded the intent to "provide support for both versions as feasible, and prioritize v3 only when supporting both becomes impractical." Point 1 above is, I believe, the concrete case where supporting both becomes impractical: a normative v2 mapping would have to legislate the perspective inversion (including v2 documents that describe only one side of a reciprocal interaction), while the shipped send/receive semantics already assume v3's operation model.

Proposal

Tighten the language to state that "asyncapi" source descriptions refer to AsyncAPI v3.x documents:

• In the Source Description Object type description (or a dedicated version-support statement), state the supported AsyncAPI major version, mirroring how the specification scopes itself to particular source description formats.
• In the Step Object action description, drop the "(publish)" / "(subscribe)" parentheticals, so send/receive align 1:1 with the AsyncAPI v3 Operation Object action values.
• State that operationId for asyncapi steps resolves against the v3 top-level operations map, and that channelPath points into a v3 document.

Alternatively, if v2 support is retained, the specification would need a normative mapping table defining how send/receive resolve against v2 publish/subscribe operations (including the perspective question and single-sided documents) — but given v3's adoption trajectory and the above, scoping to v3 seems the cleaner resolution.

Start by locating the Source Description Object type and Step Object action definitions in the specification, then compare their wording with the AsyncAPI v3 Operation Object. Done means the supported AsyncAPI version, operationId resolution, and channelPath scope are stated normatively and the ambiguous publish/subscribe parentheticals are resolved.