diff --git a/imports-request-reply.md b/imports-request-reply.md
new file mode 100644
index 0000000..be3624e
--- /dev/null
+++ b/imports-request-reply.md
@@ -0,0 +1,216 @@
+<h1><a name="imports_request_reply">World imports-request-reply</a></h1>
+<ul>
+<li>Imports:
+<ul>
+<li>interface <a href="#wasi:messaging_types_0.2.0_draft"><code>wasi:messaging/types@0.2.0-draft</code></a></li>
+<li>interface <a href="#wasi:messaging_request_reply_0.2.0_draft"><code>wasi:messaging/request-reply@0.2.0-draft</code></a></li>
+<li>interface <a href="#wasi:messaging_producer_0.2.0_draft"><code>wasi:messaging/producer@0.2.0-draft</code></a></li>
+<li>interface <a href="#wasi:messaging_consumer_0.2.0_draft"><code>wasi:messaging/consumer@0.2.0-draft</code></a></li>
+</ul>
+</li>
+</ul>
+<h2><a name="wasi:messaging_types_0.2.0_draft"></a>Import interface wasi:messaging/types@0.2.0-draft</h2>
+<hr />
+<h3>Types</h3>
+<h4><a name="client"></a><code>resource client</code></h4>
+<p>A connection to a message-exchange service (e.g., buffer, broker, etc.).</p>
+<h4><a name="error"></a><code>resource error</code></h4>
+<p>TODO(danbugs): This should be eventually extracted as an underlying type for other
+wasi-cloud-core interfaces.</p>
+<h4><a name="channel"></a><code>type channel</code></h4>
+<p><code>string</code></p>
+<p>There are two types of channels:
+- publish-subscribe channel, which is a broadcast channel, and
+- point-to-point channel, which is a unicast channel.
+<p>The interface doesn't highlight this difference in the type itself as that's uniquely a consumer issue.</p>
+<h4><a name="guest_configuration"></a><code>record guest-configuration</code></h4>
+<p>Configuration includes a required list of channels the guest is subscribing to, and an optional list of extensions key-value pairs
+(e.g., partitions/offsets to read from in Kafka/EventHubs, QoS etc.).</p>
+<h5>Record Fields</h5>
+<ul>
+<li><a name="guest_configuration.channels"></a><code>channels</code>: list&lt;<a href="#channel"><a href="#channel"><code>channel</code></a></a>&gt;</li>
+<li><a name="guest_configuration.extensions"></a><code>extensions</code>: option&lt;list&lt;(<code>string</code>, <code>string</code>)&gt;&gt;</li>
+</ul>
+<h4><a name="message"></a><code>record message</code></h4>
+<p>A message with a binary payload and additional information</p>
+<h5>Record Fields</h5>
+<ul>
+<li>
+<p><a name="message.topic"></a><code>topic</code>: <code>string</code></p>
+<p>The topic or subject this message was received or should be sent on
+</li>
+<li>
+<p><a name="message.content_type"></a><code>content-type</code>: <code>string</code></p>
+<p>An optional content-type describing the format of the data in the message. This is
+sometimes described as the "format" type
+</li>
+<li>
+<p><a name="message.reply_to"></a><code>reply-to</code>: option&lt;<code>string</code>&gt;</p>
+<p>An optional topic for use in request/response scenarios. Senders and consumers of
+messages must not assume that this field is set and should handle it in their code
+accordingly.
+</li>
+<li>
+<p><a name="message.data"></a><code>data</code>: list&lt;<code>u8</code>&gt;</p>
+<p>An opaque blob of data
+</li>
+<li>
+<p><a name="message.metadata"></a><code>metadata</code>: option&lt;list&lt;(<code>string</code>, <code>string</code>)&gt;&gt;</p>
+<p>Optional metadata (also called headers or attributes in some systems) attached to the message
+</li>
+</ul>
+<hr />
+<h3>Functions</h3>
+<h4><a name="static_client.connect"></a><code>[static]client.connect: func</code></h4>
+<h5>Params</h5>
+<ul>
+<li><a name="static_client.connect.name"></a><code>name</code>: <code>string</code></li>
+</ul>
+<h5>Return values</h5>
+<ul>
+<li><a name="static_client.connect.0"></a> result&lt;own&lt;<a href="#client"><a href="#client"><code>client</code></a></a>&gt;, own&lt;<a href="#error"><a href="#error"><code>error</code></a></a>&gt;&gt;</li>
+</ul>
+<h4><a name="static_error.trace"></a><code>[static]error.trace: func</code></h4>
+<h5>Return values</h5>
+<ul>
+<li><a name="static_error.trace.0"></a> <code>string</code></li>
+</ul>
+<h2><a name="wasi:messaging_request_reply_0.2.0_draft"></a>Import interface wasi:messaging/request-reply@0.2.0-draft</h2>
+<p>The request-reply interface allows a guest to send a message and await a response. This
+interface is considered optional as not all message services support the concept of
+request/reply. However, request/reply is a very common pattern in messaging and as such, we have
+included it as a core interface.</p>
+<hr />
+<h3>Types</h3>
+<h4><a name="client"></a><code>type client</code></h4>
+<p><a href="#client"><a href="#client"><code>client</code></a></a></p>
+<p>
+#### <a name="message"></a>`type message`
+[`message`](#message)
+<p>
+#### <a name="error"></a>`type error`
+[`error`](#error)
+<p>
+----
+<h3>Functions</h3>
+<h4><a name="request"></a><code>request: func</code></h4>
+<p>Performs a blocking request/reply operation with an optional timeout. If the timeout value
+is not set, then the request/reply operation will block indefinitely.</p>
+<p>Please note that implementations that provide <code>wasi:messaging</code> are responsible for ensuring
+that guests are not allowed to subscribe to channels that they are not configured to
+subscribe to (or have access to). Failure to do so can result in possible breakout or access
+to resources that are not intended to be accessible to the guest. This means implementations
+should validate that the reply-to field is a valid topic the guest should have access to or
+enforce it via the credentials used to connect to the service.</p>
+<h5>Params</h5>
+<ul>
+<li><a name="request.c"></a><code>c</code>: own&lt;<a href="#client"><a href="#client"><code>client</code></a></a>&gt;</li>
+<li><a name="request.msg"></a><code>msg</code>: <a href="#message"><a href="#message"><code>message</code></a></a></li>
+<li><a name="request.timeout_ms"></a><code>timeout-ms</code>: option&lt;<code>u32</code>&gt;</li>
+</ul>
+<h5>Return values</h5>
+<ul>
+<li><a name="request.0"></a> result&lt;option&lt;list&lt;<a href="#message"><a href="#message"><code>message</code></a></a>&gt;&gt;, own&lt;<a href="#error"><a href="#error"><code>error</code></a></a>&gt;&gt;</li>
+</ul>
+<h2><a name="wasi:messaging_producer_0.2.0_draft"></a>Import interface wasi:messaging/producer@0.2.0-draft</h2>
+<p>The producer interface is uesed to send messages to a channel/topic.</p>
+<hr />
+<h3>Types</h3>
+<h4><a name="client"></a><code>type client</code></h4>
+<p><a href="#client"><a href="#client"><code>client</code></a></a></p>
+<p>
+#### <a name="channel"></a>`type channel`
+[`channel`](#channel)
+<p>
+#### <a name="message"></a>`type message`
+[`message`](#message)
+<p>
+#### <a name="error"></a>`type error`
+[`error`](#error)
+<p>
+----
+<h3>Functions</h3>
+<h4><a name="send"></a><code>send: func</code></h4>
+<p>Sends a message to the given channel/topic. This topic can be overridden if a message has a
+non-empty topic field</p>
+<h5>Params</h5>
+<ul>
+<li><a name="send.c"></a><code>c</code>: own&lt;<a href="#client"><a href="#client"><code>client</code></a></a>&gt;</li>
+<li><a name="send.ch"></a><code>ch</code>: <a href="#channel"><a href="#channel"><code>channel</code></a></a></li>
+<li><a name="send.m"></a><code>m</code>: list&lt;<a href="#message"><a href="#message"><code>message</code></a></a>&gt;</li>
+</ul>
+<h5>Return values</h5>
+<ul>
+<li><a name="send.0"></a> result&lt;_, own&lt;<a href="#error"><a href="#error"><code>error</code></a></a>&gt;&gt;</li>
+</ul>
+<h2><a name="wasi:messaging_consumer_0.2.0_draft"></a>Import interface wasi:messaging/consumer@0.2.0-draft</h2>
+<p>The consumer interface allows a guest to dynamically update its subscriptions and configuration
+as well as functionality for completing (acking) or abandoning (nacking) messages.</p>
+<hr />
+<h3>Types</h3>
+<h4><a name="client"></a><code>type client</code></h4>
+<p><a href="#client"><a href="#client"><code>client</code></a></a></p>
+<p>
+#### <a name="message"></a>`type message`
+[`message`](#message)
+<p>
+#### <a name="channel"></a>`type channel`
+[`channel`](#channel)
+<p>
+#### <a name="error"></a>`type error`
+[`error`](#error)
+<p>
+#### <a name="guest_configuration"></a>`type guest-configuration`
+[`guest-configuration`](#guest_configuration)
+<p>
+----
+<h3>Functions</h3>
+<h4><a name="update_guest_configuration"></a><code>update-guest-configuration: func</code></h4>
+<p>'Fit-all' type function for updating a guest's configuration – this could be useful for:</p>
+<ul>
+<li>unsubscribing from a channel,</li>
+<li>checkpointing,</li>
+<li>etc..</li>
+</ul>
+<p>Please note that implementations that provide <code>wasi:messaging</code> are responsible for ensuring
+that guests are not allowed to subscribe to channels that they are not configured to
+subscribe to (or have access to). Failure to do so can result in possible breakout or access
+to resources that are not intended to be accessible to the guest. This means implementations
+should validate that the configured topix are valid topics the guest should have access to or
+enforce it via the credentials used to connect to the service.</p>
+<h5>Params</h5>
+<ul>
+<li><a name="update_guest_configuration.gc"></a><code>gc</code>: <a href="#guest_configuration"><a href="#guest_configuration"><code>guest-configuration</code></a></a></li>
+</ul>
+<h5>Return values</h5>
+<ul>
+<li><a name="update_guest_configuration.0"></a> result&lt;_, own&lt;<a href="#error"><a href="#error"><code>error</code></a></a>&gt;&gt;</li>
+</ul>
+<h4><a name="complete_message"></a><code>complete-message: func</code></h4>
+<p>A message can exist under several statuses:
+(1) available: the message is ready to be read,
+(2) acquired: the message has been sent to a consumer (but still exists in the queue),
+(3) accepted (result of complete-message): the message has been received and ACK-ed by a consumer and can be safely removed from the queue,
+(4) rejected (result of abandon-message): the message has been received and NACK-ed by a consumer, at which point it can be:</p>
+<ul>
+<li>deleted,</li>
+<li>sent to a dead-letter queue, or</li>
+<li>kept in the queue for further processing.</li>
+</ul>
+<h5>Params</h5>
+<ul>
+<li><a name="complete_message.m"></a><code>m</code>: <a href="#message"><a href="#message"><code>message</code></a></a></li>
+</ul>
+<h5>Return values</h5>
+<ul>
+<li><a name="complete_message.0"></a> result&lt;_, own&lt;<a href="#error"><a href="#error"><code>error</code></a></a>&gt;&gt;</li>
+</ul>
+<h4><a name="abandon_message"></a><code>abandon-message: func</code></h4>
+<h5>Params</h5>
+<ul>
+<li><a name="abandon_message.m"></a><code>m</code>: <a href="#message"><a href="#message"><code>message</code></a></a></li>
+</ul>
+<h5>Return values</h5>
+<ul>
+<li><a name="abandon_message.0"></a> result&lt;_, own&lt;<a href="#error"><a href="#error"><code>error</code></a></a>&gt;&gt;</li>
+</ul>
diff --git a/imports.md b/imports.md
index cc4b825..08ea482 100644
--- a/imports.md
+++ b/imports.md
@@ -2,19 +2,20 @@
 <ul>
 <li>Imports:
 <ul>
-<li>interface <a href="#wasi:messaging_messaging_types_0.2.0_draft"><code>wasi:messaging/messaging-types@0.2.0-draft</code></a></li>
+<li>interface <a href="#wasi:messaging_types_0.2.0_draft"><code>wasi:messaging/types@0.2.0-draft</code></a></li>
 <li>interface <a href="#wasi:messaging_producer_0.2.0_draft"><code>wasi:messaging/producer@0.2.0-draft</code></a></li>
 <li>interface <a href="#wasi:messaging_consumer_0.2.0_draft"><code>wasi:messaging/consumer@0.2.0-draft</code></a></li>
 </ul>
 </li>
 </ul>
-<h2><a name="wasi:messaging_messaging_types_0.2.0_draft"></a>Import interface wasi:messaging/messaging-types@0.2.0-draft</h2>
+<h2><a name="wasi:messaging_types_0.2.0_draft"></a>Import interface wasi:messaging/types@0.2.0-draft</h2>
 <hr />
 <h3>Types</h3>
 <h4><a name="client"></a><code>resource client</code></h4>
 <p>A connection to a message-exchange service (e.g., buffer, broker, etc.).</p>
 <h4><a name="error"></a><code>resource error</code></h4>
-<p>TODO(danbugs): This should be eventually extracted as an underlying type for other wasi-cloud-core interfaces.</p>
+<p>TODO(danbugs): This should be eventually extracted as an underlying type for other
+wasi-cloud-core interfaces.</p>
 <h4><a name="channel"></a><code>type channel</code></h4>
 <p><code>string</code></p>
 <p>There are two types of channels:
@@ -29,28 +30,33 @@
 <li><a name="guest_configuration.channels"></a><code>channels</code>: list&lt;<a href="#channel"><a href="#channel"><code>channel</code></a></a>&gt;</li>
 <li><a name="guest_configuration.extensions"></a><code>extensions</code>: option&lt;list&lt;(<code>string</code>, <code>string</code>)&gt;&gt;</li>
 </ul>
-<h4><a name="format_spec"></a><code>enum format-spec</code></h4>
-<p>Format specification for messages</p>
-<ul>
-<li>more info: https://github.com/clemensv/spec/blob/registry-extensions/registry/spec.md#message-formats</li>
-<li>message metadata can further decorate w/ things like format version, and so on.</li>
-</ul>
-<h5>Enum Cases</h5>
-<ul>
-<li><a name="format_spec.cloudevents"></a><code>cloudevents</code></li>
-<li><a name="format_spec.http"></a><code>http</code></li>
-<li><a name="format_spec.amqp"></a><code>amqp</code></li>
-<li><a name="format_spec.mqtt"></a><code>mqtt</code></li>
-<li><a name="format_spec.kafka"></a><code>kafka</code></li>
-<li><a name="format_spec.raw"></a><code>raw</code></li>
-</ul>
 <h4><a name="message"></a><code>record message</code></h4>
-<p>A message with a binary payload, a format specification, and decorative metadata.</p>
+<p>A message with a binary payload and additional information</p>
 <h5>Record Fields</h5>
 <ul>
-<li><a name="message.data"></a><code>data</code>: list&lt;<code>u8</code>&gt;</li>
-<li><a name="message.format"></a><code>format</code>: <a href="#format_spec"><a href="#format_spec"><code>format-spec</code></a></a></li>
-<li><a name="message.metadata"></a><code>metadata</code>: option&lt;list&lt;(<code>string</code>, <code>string</code>)&gt;&gt;</li>
+<li>
+<p><a name="message.topic"></a><code>topic</code>: <code>string</code></p>
+<p>The topic or subject this message was received or should be sent on
+</li>
+<li>
+<p><a name="message.content_type"></a><code>content-type</code>: <code>string</code></p>
+<p>An optional content-type describing the format of the data in the message. This is
+sometimes described as the "format" type
+</li>
+<li>
+<p><a name="message.reply_to"></a><code>reply-to</code>: option&lt;<code>string</code>&gt;</p>
+<p>An optional topic for use in request/response scenarios. Senders and consumers of
+messages must not assume that this field is set and should handle it in their code
+accordingly.
+</li>
+<li>
+<p><a name="message.data"></a><code>data</code>: list&lt;<code>u8</code>&gt;</p>
+<p>An opaque blob of data
+</li>
+<li>
+<p><a name="message.metadata"></a><code>metadata</code>: option&lt;list&lt;(<code>string</code>, <code>string</code>)&gt;&gt;</p>
+<p>Optional metadata (also called headers or attributes in some systems) attached to the message
+</li>
 </ul>
 <hr />
 <h3>Functions</h3>
@@ -69,6 +75,7 @@
 <li><a name="static_error.trace.0"></a> <code>string</code></li>
 </ul>
 <h2><a name="wasi:messaging_producer_0.2.0_draft"></a>Import interface wasi:messaging/producer@0.2.0-draft</h2>
+<p>The producer interface is uesed to send messages to a channel/topic.</p>
 <hr />
 <h3>Types</h3>
 <h4><a name="client"></a><code>type client</code></h4>
@@ -86,6 +93,8 @@
 ----
 <h3>Functions</h3>
 <h4><a name="send"></a><code>send: func</code></h4>
+<p>Sends a message to the given channel/topic. This topic can be overridden if a message has a
+non-empty topic field</p>
 <h5>Params</h5>
 <ul>
 <li><a name="send.c"></a><code>c</code>: own&lt;<a href="#client"><a href="#client"><code>client</code></a></a>&gt;</li>
@@ -97,6 +106,8 @@
 <li><a name="send.0"></a> result&lt;_, own&lt;<a href="#error"><a href="#error"><code>error</code></a></a>&gt;&gt;</li>
 </ul>
 <h2><a name="wasi:messaging_consumer_0.2.0_draft"></a>Import interface wasi:messaging/consumer@0.2.0-draft</h2>
+<p>The consumer interface allows a guest to dynamically update its subscriptions and configuration
+as well as functionality for completing (acking) or abandoning (nacking) messages.</p>
 <hr />
 <h3>Types</h3>
 <h4><a name="client"></a><code>type client</code></h4>
@@ -116,29 +127,6 @@
 <p>
 ----
 <h3>Functions</h3>
-<h4><a name="subscribe_try_receive"></a><code>subscribe-try-receive: func</code></h4>
-<p>Blocking receive for t-milliseconds with ephemeral subscription – if no message is received, returns None</p>
-<h5>Params</h5>
-<ul>
-<li><a name="subscribe_try_receive.c"></a><code>c</code>: own&lt;<a href="#client"><a href="#client"><code>client</code></a></a>&gt;</li>
-<li><a name="subscribe_try_receive.ch"></a><code>ch</code>: <a href="#channel"><a href="#channel"><code>channel</code></a></a></li>
-<li><a name="subscribe_try_receive.t_milliseconds"></a><code>t-milliseconds</code>: <code>u32</code></li>
-</ul>
-<h5>Return values</h5>
-<ul>
-<li><a name="subscribe_try_receive.0"></a> result&lt;option&lt;list&lt;<a href="#message"><a href="#message"><code>message</code></a></a>&gt;&gt;, own&lt;<a href="#error"><a href="#error"><code>error</code></a></a>&gt;&gt;</li>
-</ul>
-<h4><a name="subscribe_receive"></a><code>subscribe-receive: func</code></h4>
-<p>Blocking receive until message with ephemeral subscription</p>
-<h5>Params</h5>
-<ul>
-<li><a name="subscribe_receive.c"></a><code>c</code>: own&lt;<a href="#client"><a href="#client"><code>client</code></a></a>&gt;</li>
-<li><a name="subscribe_receive.ch"></a><code>ch</code>: <a href="#channel"><a href="#channel"><code>channel</code></a></a></li>
-</ul>
-<h5>Return values</h5>
-<ul>
-<li><a name="subscribe_receive.0"></a> result&lt;list&lt;<a href="#message"><a href="#message"><code>message</code></a></a>&gt;, own&lt;<a href="#error"><a href="#error"><code>error</code></a></a>&gt;&gt;</li>
-</ul>
 <h4><a name="update_guest_configuration"></a><code>update-guest-configuration: func</code></h4>
 <p>'Fit-all' type function for updating a guest's configuration – this could be useful for:</p>
 <ul>
@@ -146,6 +134,12 @@
 <li>checkpointing,</li>
 <li>etc..</li>
 </ul>
+<p>Please note that implementations that provide <code>wasi:messaging</code> are responsible for ensuring
+that guests are not allowed to subscribe to channels that they are not configured to
+subscribe to (or have access to). Failure to do so can result in possible breakout or access
+to resources that are not intended to be accessible to the guest. This means implementations
+should validate that the configured topix are valid topics the guest should have access to or
+enforce it via the credentials used to connect to the service.</p>
 <h5>Params</h5>
 <ul>
 <li><a name="update_guest_configuration.gc"></a><code>gc</code>: <a href="#guest_configuration"><a href="#guest_configuration"><code>guest-configuration</code></a></a></li>
diff --git a/messaging.md b/messaging.md
index 3774be8..d1c3869 100644
--- a/messaging.md
+++ b/messaging.md
@@ -2,24 +2,25 @@
 <ul>
 <li>Imports:
 <ul>
-<li>interface <a href="#wasi:messaging_messaging_types_0.2.0_draft"><code>wasi:messaging/messaging-types@0.2.0-draft</code></a></li>
+<li>interface <a href="#wasi:messaging_types_0.2.0_draft"><code>wasi:messaging/types@0.2.0-draft</code></a></li>
 <li>interface <a href="#wasi:messaging_producer_0.2.0_draft"><code>wasi:messaging/producer@0.2.0-draft</code></a></li>
 <li>interface <a href="#wasi:messaging_consumer_0.2.0_draft"><code>wasi:messaging/consumer@0.2.0-draft</code></a></li>
 </ul>
 </li>
 <li>Exports:
 <ul>
-<li>interface <a href="#wasi:messaging_messaging_guest_0.2.0_draft"><code>wasi:messaging/messaging-guest@0.2.0-draft</code></a></li>
+<li>interface <a href="#wasi:messaging_guest_0.2.0_draft"><code>wasi:messaging/guest@0.2.0-draft</code></a></li>
 </ul>
 </li>
 </ul>
-<h2><a name="wasi:messaging_messaging_types_0.2.0_draft"></a>Import interface wasi:messaging/messaging-types@0.2.0-draft</h2>
+<h2><a name="wasi:messaging_types_0.2.0_draft"></a>Import interface wasi:messaging/types@0.2.0-draft</h2>
 <hr />
 <h3>Types</h3>
 <h4><a name="client"></a><code>resource client</code></h4>
 <p>A connection to a message-exchange service (e.g., buffer, broker, etc.).</p>
 <h4><a name="error"></a><code>resource error</code></h4>
-<p>TODO(danbugs): This should be eventually extracted as an underlying type for other wasi-cloud-core interfaces.</p>
+<p>TODO(danbugs): This should be eventually extracted as an underlying type for other
+wasi-cloud-core interfaces.</p>
 <h4><a name="channel"></a><code>type channel</code></h4>
 <p><code>string</code></p>
 <p>There are two types of channels:
@@ -34,28 +35,33 @@
 <li><a name="guest_configuration.channels"></a><code>channels</code>: list&lt;<a href="#channel"><a href="#channel"><code>channel</code></a></a>&gt;</li>
 <li><a name="guest_configuration.extensions"></a><code>extensions</code>: option&lt;list&lt;(<code>string</code>, <code>string</code>)&gt;&gt;</li>
 </ul>
-<h4><a name="format_spec"></a><code>enum format-spec</code></h4>
-<p>Format specification for messages</p>
-<ul>
-<li>more info: https://github.com/clemensv/spec/blob/registry-extensions/registry/spec.md#message-formats</li>
-<li>message metadata can further decorate w/ things like format version, and so on.</li>
-</ul>
-<h5>Enum Cases</h5>
-<ul>
-<li><a name="format_spec.cloudevents"></a><code>cloudevents</code></li>
-<li><a name="format_spec.http"></a><code>http</code></li>
-<li><a name="format_spec.amqp"></a><code>amqp</code></li>
-<li><a name="format_spec.mqtt"></a><code>mqtt</code></li>
-<li><a name="format_spec.kafka"></a><code>kafka</code></li>
-<li><a name="format_spec.raw"></a><code>raw</code></li>
-</ul>
 <h4><a name="message"></a><code>record message</code></h4>
-<p>A message with a binary payload, a format specification, and decorative metadata.</p>
+<p>A message with a binary payload and additional information</p>
 <h5>Record Fields</h5>
 <ul>
-<li><a name="message.data"></a><code>data</code>: list&lt;<code>u8</code>&gt;</li>
-<li><a name="message.format"></a><code>format</code>: <a href="#format_spec"><a href="#format_spec"><code>format-spec</code></a></a></li>
-<li><a name="message.metadata"></a><code>metadata</code>: option&lt;list&lt;(<code>string</code>, <code>string</code>)&gt;&gt;</li>
+<li>
+<p><a name="message.topic"></a><code>topic</code>: <code>string</code></p>
+<p>The topic or subject this message was received or should be sent on
+</li>
+<li>
+<p><a name="message.content_type"></a><code>content-type</code>: <code>string</code></p>
+<p>An optional content-type describing the format of the data in the message. This is
+sometimes described as the "format" type
+</li>
+<li>
+<p><a name="message.reply_to"></a><code>reply-to</code>: option&lt;<code>string</code>&gt;</p>
+<p>An optional topic for use in request/response scenarios. Senders and consumers of
+messages must not assume that this field is set and should handle it in their code
+accordingly.
+</li>
+<li>
+<p><a name="message.data"></a><code>data</code>: list&lt;<code>u8</code>&gt;</p>
+<p>An opaque blob of data
+</li>
+<li>
+<p><a name="message.metadata"></a><code>metadata</code>: option&lt;list&lt;(<code>string</code>, <code>string</code>)&gt;&gt;</p>
+<p>Optional metadata (also called headers or attributes in some systems) attached to the message
+</li>
 </ul>
 <hr />
 <h3>Functions</h3>
@@ -74,6 +80,7 @@
 <li><a name="static_error.trace.0"></a> <code>string</code></li>
 </ul>
 <h2><a name="wasi:messaging_producer_0.2.0_draft"></a>Import interface wasi:messaging/producer@0.2.0-draft</h2>
+<p>The producer interface is uesed to send messages to a channel/topic.</p>
 <hr />
 <h3>Types</h3>
 <h4><a name="client"></a><code>type client</code></h4>
@@ -91,6 +98,8 @@
 ----
 <h3>Functions</h3>
 <h4><a name="send"></a><code>send: func</code></h4>
+<p>Sends a message to the given channel/topic. This topic can be overridden if a message has a
+non-empty topic field</p>
 <h5>Params</h5>
 <ul>
 <li><a name="send.c"></a><code>c</code>: own&lt;<a href="#client"><a href="#client"><code>client</code></a></a>&gt;</li>
@@ -102,6 +111,8 @@
 <li><a name="send.0"></a> result&lt;_, own&lt;<a href="#error"><a href="#error"><code>error</code></a></a>&gt;&gt;</li>
 </ul>
 <h2><a name="wasi:messaging_consumer_0.2.0_draft"></a>Import interface wasi:messaging/consumer@0.2.0-draft</h2>
+<p>The consumer interface allows a guest to dynamically update its subscriptions and configuration
+as well as functionality for completing (acking) or abandoning (nacking) messages.</p>
 <hr />
 <h3>Types</h3>
 <h4><a name="client"></a><code>type client</code></h4>
@@ -121,29 +132,6 @@
 <p>
 ----
 <h3>Functions</h3>
-<h4><a name="subscribe_try_receive"></a><code>subscribe-try-receive: func</code></h4>
-<p>Blocking receive for t-milliseconds with ephemeral subscription – if no message is received, returns None</p>
-<h5>Params</h5>
-<ul>
-<li><a name="subscribe_try_receive.c"></a><code>c</code>: own&lt;<a href="#client"><a href="#client"><code>client</code></a></a>&gt;</li>
-<li><a name="subscribe_try_receive.ch"></a><code>ch</code>: <a href="#channel"><a href="#channel"><code>channel</code></a></a></li>
-<li><a name="subscribe_try_receive.t_milliseconds"></a><code>t-milliseconds</code>: <code>u32</code></li>
-</ul>
-<h5>Return values</h5>
-<ul>
-<li><a name="subscribe_try_receive.0"></a> result&lt;option&lt;list&lt;<a href="#message"><a href="#message"><code>message</code></a></a>&gt;&gt;, own&lt;<a href="#error"><a href="#error"><code>error</code></a></a>&gt;&gt;</li>
-</ul>
-<h4><a name="subscribe_receive"></a><code>subscribe-receive: func</code></h4>
-<p>Blocking receive until message with ephemeral subscription</p>
-<h5>Params</h5>
-<ul>
-<li><a name="subscribe_receive.c"></a><code>c</code>: own&lt;<a href="#client"><a href="#client"><code>client</code></a></a>&gt;</li>
-<li><a name="subscribe_receive.ch"></a><code>ch</code>: <a href="#channel"><a href="#channel"><code>channel</code></a></a></li>
-</ul>
-<h5>Return values</h5>
-<ul>
-<li><a name="subscribe_receive.0"></a> result&lt;list&lt;<a href="#message"><a href="#message"><code>message</code></a></a>&gt;, own&lt;<a href="#error"><a href="#error"><code>error</code></a></a>&gt;&gt;</li>
-</ul>
 <h4><a name="update_guest_configuration"></a><code>update-guest-configuration: func</code></h4>
 <p>'Fit-all' type function for updating a guest's configuration – this could be useful for:</p>
 <ul>
@@ -151,6 +139,12 @@
 <li>checkpointing,</li>
 <li>etc..</li>
 </ul>
+<p>Please note that implementations that provide <code>wasi:messaging</code> are responsible for ensuring
+that guests are not allowed to subscribe to channels that they are not configured to
+subscribe to (or have access to). Failure to do so can result in possible breakout or access
+to resources that are not intended to be accessible to the guest. This means implementations
+should validate that the configured topix are valid topics the guest should have access to or
+enforce it via the credentials used to connect to the service.</p>
 <h5>Params</h5>
 <ul>
 <li><a name="update_guest_configuration.gc"></a><code>gc</code>: <a href="#guest_configuration"><a href="#guest_configuration"><code>guest-configuration</code></a></a></li>
@@ -187,7 +181,7 @@
 <ul>
 <li><a name="abandon_message.0"></a> result&lt;_, own&lt;<a href="#error"><a href="#error"><code>error</code></a></a>&gt;&gt;</li>
 </ul>
-<h2><a name="wasi:messaging_messaging_guest_0.2.0_draft"></a>Export interface wasi:messaging/messaging-guest@0.2.0-draft</h2>
+<h2><a name="wasi:messaging_guest_0.2.0_draft"></a>Export interface wasi:messaging/guest@0.2.0-draft</h2>
 <hr />
 <h3>Types</h3>
 <h4><a name="message"></a><code>type message</code></h4>
@@ -201,15 +195,9 @@
 <p>
 ----
 <h3>Functions</h3>
-<h4><a name="configure"></a><code>configure: func</code></h4>
-<p>Returns the list of channels (and extension metadata within guest-configuration) that
-this component should subscribe to and be handled by the subsequent handler within guest-configuration</p>
-<h5>Return values</h5>
-<ul>
-<li><a name="configure.0"></a> result&lt;<a href="#guest_configuration"><a href="#guest_configuration"><code>guest-configuration</code></a></a>, own&lt;<a href="#error"><a href="#error"><code>error</code></a></a>&gt;&gt;</li>
-</ul>
 <h4><a name="handler"></a><code>handler: func</code></h4>
-<p>Whenever this guest receives a message in one of the subscribed channels, the message is sent to this handler</p>
+<p>Whenever this guest receives a message in one of the subscribed channels, the message is
+sent to this handler</p>
 <h5>Params</h5>
 <ul>
 <li><a name="handler.ms"></a><code>ms</code>: list&lt;<a href="#message"><a href="#message"><code>message</code></a></a>&gt;</li>
diff --git a/wit/consumer.wit b/wit/consumer.wit
index a8f14d5..ce2df01 100644
--- a/wit/consumer.wit
+++ b/wit/consumer.wit
@@ -1,17 +1,19 @@
+/// The consumer interface allows a guest to dynamically update its subscriptions and configuration
+/// as well as functionality for completing (acking) or abandoning (nacking) messages.
 interface consumer {
-    // {client, message, channel, error, guest-configuration}
-    use messaging-types.{client, message, channel, error, guest-configuration};
-
-    /// Blocking receive for t-milliseconds with ephemeral subscription – if no message is received, returns None
-    subscribe-try-receive: func(c: client, ch: channel, t-milliseconds: u32) -> result<option<list<message>>, error>;
-
-    /// Blocking receive until message with ephemeral subscription
-    subscribe-receive: func(c: client, ch: channel) -> result<list<message>, error>;
+    use types.{client, message, channel, error, guest-configuration};
 
     /// 'Fit-all' type function for updating a guest's configuration – this could be useful for:
     ///     - unsubscribing from a channel,
     ///     - checkpointing,
     ///     - etc..
+    /// 
+    /// Please note that implementations that provide `wasi:messaging` are responsible for ensuring
+    /// that guests are not allowed to subscribe to channels that they are not configured to
+    /// subscribe to (or have access to). Failure to do so can result in possible breakout or access
+    /// to resources that are not intended to be accessible to the guest. This means implementations
+    /// should validate that the configured topix are valid topics the guest should have access to or 
+    /// enforce it via the credentials used to connect to the service.
     update-guest-configuration: func(gc: guest-configuration) -> result<_, error>;
 
     /// A message can exist under several statuses:
diff --git a/wit/guest.wit b/wit/guest.wit
index 8e9cb4e..9138149 100644
--- a/wit/guest.wit
+++ b/wit/guest.wit
@@ -1,10 +1,7 @@
-interface messaging-guest {
-    use messaging-types.{message, guest-configuration, error};
+interface guest {
+    use types.{message, guest-configuration, error};
 
-    /// Returns the list of channels (and extension metadata within guest-configuration) that 
-    /// this component should subscribe to and be handled by the subsequent handler within guest-configuration
-    configure: func() -> result<guest-configuration, error>;
-
-    /// Whenever this guest receives a message in one of the subscribed channels, the message is sent to this handler
+    /// Whenever this guest receives a message in one of the subscribed channels, the message is
+    /// sent to this handler
     handler: func(ms: list<message>) -> result<_, error>;
 }
diff --git a/wit/messaging.wit b/wit/messaging.wit
index 26ad817..2d18024 100644
--- a/wit/messaging.wit
+++ b/wit/messaging.wit
@@ -5,7 +5,12 @@ world imports {
 	import consumer;
 }
 
+world imports-request-reply {
+	include imports;
+	import request-reply;
+}
+
 world messaging {
 	include imports;
-	export messaging-guest;
+	export guest;
 }
\ No newline at end of file
diff --git a/wit/producer.wit b/wit/producer.wit
index 8c08156..64caa00 100644
--- a/wit/producer.wit
+++ b/wit/producer.wit
@@ -1,5 +1,6 @@
+/// The producer interface is uesed to send messages to a channel/topic.
 interface producer {
-    use messaging-types.{client, channel, message, error};
+    use types.{client, channel, message, error};
     
     /// Sends a message to the given channel/topic. This topic can be overridden if a message has a
     /// non-empty topic field
diff --git a/wit/request-reply.wit b/wit/request-reply.wit
new file mode 100644
index 0000000..bf08022
--- /dev/null
+++ b/wit/request-reply.wit
@@ -0,0 +1,18 @@
+/// The request-reply interface allows a guest to send a message and await a response. This
+/// interface is considered optional as not all message services support the concept of
+/// request/reply. However, request/reply is a very common pattern in messaging and as such, we have
+/// included it as a core interface.
+interface request-reply {
+    use types.{client, message, error};
+
+    /// Performs a blocking request/reply operation with an optional timeout. If the timeout value
+    /// is not set, then the request/reply operation will block indefinitely.
+    /// 
+    /// Please note that implementations that provide `wasi:messaging` are responsible for ensuring
+    /// that guests are not allowed to subscribe to channels that they are not configured to
+    /// subscribe to (or have access to). Failure to do so can result in possible breakout or access
+    /// to resources that are not intended to be accessible to the guest. This means implementations
+    /// should validate that the reply-to field is a valid topic the guest should have access to or 
+    /// enforce it via the credentials used to connect to the service.
+    request: func(c: client, msg: message, timeout-ms: option<u32>) -> result<option<list<message>>, error>;
+}
\ No newline at end of file
diff --git a/wit/types.wit b/wit/types.wit
index 81e2e29..aacce52 100644
--- a/wit/types.wit
+++ b/wit/types.wit
@@ -1,10 +1,11 @@
-interface messaging-types {
+interface types {
     /// A connection to a message-exchange service (e.g., buffer, broker, etc.).
     resource client {
         connect: static func(name: string) -> result<client, error>;
     }
     
-    /// TODO(danbugs): This should be eventually extracted as an underlying type for other wasi-cloud-core interfaces.
+    // TODO(danbugs): This should be eventually extracted as an underlying type for other 
+    // wasi-cloud-core interfaces.
     resource error {
         trace: static func() -> string;    
     }
@@ -27,7 +28,12 @@ interface messaging-types {
     record message {
         /// The topic or subject this message was received or should be sent on
         topic: string,
-        /// An optional topic for use in request/response scenarios
+        /// An optional content-type describing the format of the data in the message. This is 
+        /// sometimes described as the "format" type
+        content-type: string,
+        /// An optional topic for use in request/response scenarios. Senders and consumers of
+        /// messages must not assume that this field is set and should handle it in their code
+        /// accordingly.
         reply-to: option<string>,
         /// An opaque blob of data
         data: list<u8>,