Gerald Loeffler

(Paraphrasing from https://github.com/asyncapi/spec/issues/390#issuecomment-800422743:) The AsyncAPI document for A1 should use - `applicationSent` when A1 sends messages to a channel (to which A2 might be subscribed) - `applicationReceived` when A1 receives...

i've submitted PR #521 that adds wording to the current spec simply to clarify the current meaning of `publish` and `subscribe`.

i agree it's relevant @magicmatatjahu , but i personally don't have capacity to champion it

Further on the 2 proposed solutions: Solution 1. is simpler but means that the message object can only be used with one specific binding: only in this way `correlationId` (for...

thanks @magicmatatjahu for interpreting my thoughts and discussing them with @derberg ;) : you're right, my concern is that schemas like `httpHeader` from [@derberg 's example](https://github.com/asyncapi/spec/issues/555#issuecomment-860592335) should come from the...

i propose to use sub-schemas in the main binding schema document for this. Specifically, protocol headers belong logically to the message binding object, and should typically be defined in a...

> If we go with tag versioning for bindings - every patch/minor/major version of binding will have separate git tag in repo, then we can still ref to appropriate version...

this proposal would also allow the definition of mixed schemas, such as the one for the `payload` of the `UserSignedUp` message in the following example (which currently is not possible):...

I, too, see an AsyncAPI document as formalizing the (message-based) _contract_ of an **application**, and i think it is wise not to depart from this clear application-centric perspective almost accidentally,...

@reselbob : what you describe is the current meaning of `publish` and `subscribe`: https://github.com/asyncapi/spec/blob/master/spec/asyncapi.md#channelItemObject