for protocol headers the AMQP bindings spec should use a schema object in the message binding object

[GeraldLoeffler]

AMQP (0.9.1) protocol headers like userId, replyTo, or timestamp are currently defined as fields in the operation binding object.

Firstly, protocol headers are probably better captured in the message binding object than in the operation binding object.

Secondly, every message at runtime can potentially use different values for protocol headers. Therefore fields in the binding object are not the appropriate mechanism to model this. Instead, a schema object should be used: see for example the HTTP message binding object.

[github-actions]

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.

[derberg]

@olvlvl any opinion from your side?

[olvlvl]

Hi everyone,

According to the documentation userId, replyTo, or timestamp are referred as "message properties", not "protocol headers". That being said, I agree with @GeraldLoeffler. Since userId, replyTo, or timestamp are message properties, and as such can be different for each message, it would be correct to have them defined on AsyncAPI message bindings.

[iancooper]

@GeraldLoeffler @derberg @olvlvl

I'll post my suggested conventions in a day or so, but I'd argue that these are not bindings, but form part of the schema for the headers on the message, and can be supported by MessageTraits if you have fixed values.

If you send it over the wire, I don't believe a binding is the place to define it. I believe the binding should be where we define configuration required by the protocol. I don't think this is configuration the protocol requires, it certainly would not be a candidate for a management API used by middleware on the protocol.

Where the way transmit a message is configurable for a protocol, it may be appropriate to use a message binding, otherwise I'm not sure it makes sense to use the binding to describe what will of necessity be in the header's Schema object (or payload for protocols that don't support headers).

[github-actions]

This issue has been automatically marked as stale because it has not had recent activity 😴
It will be closed in 60 days if no further activity occurs. To unstale this issue, add a comment with detailed explanation.
Thank you for your contributions ❤️

[github-actions]

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 ❤️

[derberg]

Hey folks, where are we with this one, anyone driving it further?

[github-actions]

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 ❤️

[github-actions]

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 ❤️