Welcome to AsyncAPI. Thanks a lot for reporting your first issue. Please check out our contributors guide and the instructions about a basic recommended setup useful for opening a pull request.
Keep in mind there are also other channels you can use to interact with AsyncAPI community. For more details check out this issue.

I suggest to provide definition of reply in the Definitions section, maybe as subpart of Message definition.

Wondering if it is not already covered by the description of what an Operation Reply Object means.

Describes the reply part that MAY be applied to an Operation Object. If an operation implements the request/reply pattern, the reply object represents the response message.

For me description of Operation Reply Object and definition of Message are a bit not match.

Message:

Since a message is a generic mechanism, it can support multiple interaction patterns such as event, command, request, or response.

Reply Object:

If an operation implements the request/reply pattern, the reply object represents the response message.

I feel here a gap, like "what exactly is request?", consequently "is it send or receive operation?". (For me now it's clear, but I feel some degree of uncertain, when read Spec first time)

If we have a look of EIP request-reply definition, I would say it a bit more solid

Send a pair of Request-Reply messages, each on its own channel.

Request-Reply has two participants:

Requestor – Sends a request message and waits for a reply message.
Replier – Receives the request message and responds with a reply message.

Defenitely like the idea of adding another definition, as this is what Definitions are for in the spec, to introduce the concept

@Tenischev do you have a suggestion for a good paragraph?

@derberg to be consistent I also provide changes in other part of document related with reply or "response" message.

Message

A message is the mechanism by which information is exchanged via a channel between servers and applications. A message MUST contain a payload and MAY also contain headers. The headers MAY be subdivided into protocol-defined headers and header properties defined by the application which can act as supporting metadata. The payload contains the data, defined by the application, which MUST be serialized into a format (JSON, XML, Avro, binary, etc.). Since a message is a generic mechanism, it can support multiple interaction patterns such as event, command, request, or reply.

Reply message

A reply is a special type of message used in the request-reply interaction pattern and can only be used in combination with a request message. In the request-reply interaction pattern, messages are defined as follows: Sender sends a request message and waits for a reply message, while Receiver receives the request message and responds with a reply message.

Operation Object

Describes a specific operation.

Fixed Fields

Operation Reply Object

Describes the reply part that MAY be applied to an Operation Object. If an operation implements the request-reply interaction pattern, this object represents the reply address/channel and the reply message.

Message Bindings Object

Map describing protocol-specific definitions for a message.

Fixed Fields

@Tenischev can you show it in a draft PR 🙏🏼

@derberg did you have a chance to have a look on draft PR?

This issue has been automatically marked as stale because it has not had recent activity 😴

It will be closed in 120 days if no further activity occurs. To unstale this issue, add a comment with a detailed explanation.

There can be many reasons why some specific issue has no activity. The most probable cause is lack of time, not lack of interest. AsyncAPI Initiative is a Linux Foundation project not owned by a single for-profit company. It is a community-driven initiative ruled under open governance model.

Let us figure out together how to push this issue forward. Connect with us through one of many communication channels we established here.

Thank you for your patience ❤️