Explicitly support common protocol headers

[GeraldLoeffler]

Most messaging systems conceptually support a common set of protocol headers:

• message ID
• sending timestamp
• expiration time and/or TTL
• correlation ID
• reply-to channel
• ...

Of these, AsyncAPI already supports (only) correlation ID, through the correlationId field of the message object.

To be able to express rich message exchanges in AsyncAPI documents, it is necessary to also support the missing protocol headers.

See #556 for a proposal of how to express the difference between protocol headers and application headers in runtime expressions. For example correlationId is a protocol header in JMS but an application header (such as x-correlation-id) in HTTP.

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

[fmvilas]

I wonder if we should actually get rid of correlationId and move it to each binding supporting correlation IDs. We'd definitely do it in a standard way so the field has the same name across different bindings. What do you think?

PS: I'm now reviewing all the issues that might introduce a breaking change for v3.0.0 so it's a good opportunity.

[damaru-inc]

I haven't paid any attention to headers until now. I understand why one can't specify protocol-specific headers in the message/headers section, but there's no clear way to define them in the bindings, and I agree that there are a few common ones that we should be able to support without bindings.

I could propose adding headers to the JMS binding, but if I'm defining a message and I want to specify
JMSDeliveryMode: 1 how do I do that?

I mean, I know I can write this:

message:
  myJmsMessage:
    bindings:
      jms:
         JMSDeliveryMode: 1

but it's not clear that that is a header.

[jonaslagoni]

Is there any of you who wants to champion this? 🙂 Or can we consider this issue as needs champion? 🤔

[smoya]

Hi @GeraldLoeffler! It has been a while since you created this RFC-0. Do you wanna champion it?

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