Sergio Moya

@ekozynin I recently updated https://github.com/asyncapi/spec/issues/654, becoming mostly a similar suggestion on what you did. WDYT about @fmvilas suggestion here: https://github.com/asyncapi/spec/issues/654#issuecomment-1074424027 Do you think it makes sense? I'm happy to move...

@fmvilas @derberg could you please remove the `stale` label? https://github.com/asyncapi/spec/issues/654 might fix this.

You made a really good point here. I agree having in mind breaking changes also at tooling level is important. I like the idea of treating breaking changes in different...

> maybe with @jonaslagoni lists and definitions then wouldn't really matter about the tools, as this kind of change would be breaking anyway. Yeah, that's a really good point. I...

If we finally move forward with https://github.com/asyncapi/parser-js/issues/401, the idea will be that Parser-API will define all the bundling and ref/dereferencing logic Parsers should follow. Meaning the spec documentation will link...

> @smoya I've read the intention driven proposals and the [article](https://www.asyncapi.com/blog/intent-driven-api). IMHO it's completely separate from this issue. It should be clear from specification how to create the implementation, which...

Hi @mgiovann, thanks for your RFC submission! I wonder if, for your use case, you could create two different channels instead and specify a different server on each through the...

Do you agree we can then close this issue @mgiovann ?

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

> Local servers can only use the HTTP or WS protocol. Remote servers can be of any kind. I agree is not a very common use case but what about...