Support for content-type and metadata/headers across different message queues and services is not uniform. For example, RabbitMQ has built-in support for content-type, but NATS.io does not.

What's the correct behavior on the host's part when content-type and/or metadata is set in the guest message, but not supported by the underlying implementation?

In scenario where a message is received by the guest via incoming-handler#handle, the resource is associated with the concrete implementation of a message queue it originated from, therefore we can make assumptions on which properties are supported and which are not (like is done in #29)

In cases, where the guest constructs a message, it will only be associated with a concrete message queue once it's passed as a parameter to e.g. producer#send. What is the expected behavior for the host in case e.g. a guest message with content-type set is passed to a types.client, which is associated with NATS.io, which does not support content-type?

One potential solution I see here is:

• Exposing supports-metadata: func() -> bool and supports-content-type: func() -> bool on types.client
• Removing

  wasi-messaging/wit/request-reply.wit

  Line 46 in 4ee59bb

  reply: func(reply-to: borrow<message>, message: message) -> result<_, error>;

• Exposing reply as a getter on the message, therefore enforcing that replies are sent using a specific types.client via producer#send
• Adding remove-content-type to message

With this functionality, I think we can enforce that, e.g. passing a message carrying content-type to producer#send using a client, which does not support it, results in a hard error.

Another potential improvement here is removing the message constructor altogether and instead, exposing a new_message method on the client.

It looks like there also should be some way to derive a client from an incoming message