docs: add constraint about channel address to not use query params and…

[derberg]

in v3 address is what in v2 we know as channel key/name

in v2 we had clear info about not using query params and fragments: https://github.com/asyncapi/spec/blob/master/spec/asyncapi.md#user-content-channels-object

during works on v3 this was lost

Confirmed in Slack it was lost by mistake, not intentionally, thus bringing it back

Lukasz Gornicki: 
  in spec v2 channel name was both, name and address and documentation specified: Query parameters and fragments SHALL NOT be used, instead use bindings to define them.
  in spec v3 channel name is something different, and we have dedicated address property, and it’s description no longer says that query params should not be used.

  cc Fran Méndez. Do you remember if it was intentionally removed or lost in translation? I don’t remember what was the reason in v2 to not allow query params in the name :thinking_face: was it purely technical reason, to not have weird names? :thinking_face:


Fran Méndez:
  I think it was lost in translation. The reason for not having query params in channel addresses is that query params are purely an HTTP thing and that's why it was separated.

[fmvilas]

What about this instead?

Suggested change

<a name="channelObjectAddress"></a>address | `string` \| `null` | An optional string representation of this channel's address. The address is typically the "topic name", "routing key", "event type", or "path". When `null` or absent, it MUST be interpreted as unknown. This is useful when the address is generated dynamically at runtime or can't be known upfront. It MAY contain [Channel Address Expressions](#channelAddressExpressions). Query parameters and fragments SHALL NOT be used, instead use [bindings](#channelBindingsObject) to define them.

<a name="channelObjectAddress"></a>address | `string` \| `null` | An optional string representation of this channel's address. The address is typically the "topic name", "routing key", "event type", or "path". When `null` or absent, it MUST be interpreted as unknown. This is useful when the address is generated dynamically at runtime or can't be known upfront. It MAY contain [Channel Address Expressions](#channelAddressExpressions). HTTP query parameters and fragments SHALL NOT be used, instead use the [HTTP binding](https://github.com/asyncapi/bindings/tree/master/http#operation-binding-object) in the operations to define them.

[derberg]

I copied the same sentence with had in v2
thing is that it is not only about HTTP, Websocket also have query params, and you never know what else might pop up in future, so I don't think we should be that specific as you propose

[fmvilas]

WebSocket doesn't have query params. It's the HTTP endpoint you have to reach for protocol upgrade. That's why I'm being specific.

[derberg]

you establish connection over HTTP, yes, but in AsyncAPI document you do not define separate server with HTTP protocol and binding. You specify server with websocket protocol and websocket binding https://github.com/asyncapi/bindings/tree/next-major-spec/websockets#channel-binding-object

[fmvilas]

You're right 👍 Ok, so let's not be that specific then. Even though, WS binding properties are about HTTP but that's fine.

[derberg]

@jonaslagoni fyi, I don't think it is changing anything from any tooling perspective, release date or stuff like that. Also nothing for release notes and migration guide

[jonaslagoni]

@jonaslagoni fyi, I don't think it is changing anything from any tooling perspective, release date or stuff like that. Also nothing for release notes and migration guide

Yep, agree 👍

[char0n]

LGTM

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[derberg]

/rtm

[asyncapi-bot]

🎉 This PR is included in version 3.0.0-next-major-spec.17 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀