Channel parameter location inconsistency

[jonaslagoni]

The channel object defines parameters as:

A map of the parameters included in the channel name. It SHOULD be present only when using channels with expressions (as defined by RFC 6570 section 2.2).

But the parameter object allows you to define a runtime expression defining the location of the parameter value through location.

A runtime expression that specifies the location of the parameter value. Even when a definition for the target field exists, it MUST NOT be used to validate this parameter but, instead, the schema property MUST be used.

The runtime expression is defined as using the syntax:

      expression = ( "$message" "." source )
      source = ( header-reference | payload-reference )
      header-reference = "header" ["#" fragment]
      payload-reference = "payload" ["#" fragment]
      fragment = a JSON Pointer [RFC 6901](https://tools.ietf.org/html/rfc6901)

Which I assume gives the possibility to define message headers for the channel such as:

asyncapi: 2.5.0
info:
  title: Account Service
  version: 1.0.0
  description: This service is in charge of processing user signups
channels:
  user/signedup:
    parameters: 
      Authorization:
        schema:
          type: string
          const: 'bearer token'
        location: '$message.header#Authorization'
    subscribe:
      message:
        $ref: '#/components/messages/UserSignedUp'
components:
  messages:
    UserSignedUp:
      payload:
        type: object
        properties:
          displayName:
            type: string
            description: Name of the user
          email:
            type: string
            format: email
            description: Email of the user

Or does the definition of what a parameter is A map of the parameters included in the channel name veto that?

Related discussion in spec 3.0 meeting: https://youtu.be/JsalpKiWsP4, the question raised here: https://youtu.be/JsalpKiWsP4?t=2930

Extended discussion afterward:

• If it is allowed to define headers in the channel parameters, I would assume that would remove the need for websockets to define their own headers in the bindings?

[derberg]

it is pretty old feature and I think only @fmvilas is able to answer really

[fmvilas]

The whole thing started here: https://github.com/asyncapi/spec/issues/199. Yeah, I think A map of the parameters included in the channel name vetoes that. We can clarify it more, of course.

[github-actions[bot]]

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

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 :heart: