Apply suggestions from code review

Co-authored-by: Catherine Bundy <[email protected]>

Author: Y-Sindo

articles/azure-web-pubsub/reference-cloud-events-amqp.md

@@ -10,15 +10,17 @@ ms.date: 09/30/2022
 
 # CloudEvents extension for Azure Web PubSub event listener with AMQP protocol
 
-Web PubSub Service describes client events as [CloudEvents](https://github.com/cloudevents/spec/tree/v1.0.2). CloudEvents is a specification for describing event data in common formats to provide interoperability across services, platforms and systems. As for event listener with [Advanced Message Queueing Protocol](http://docs.oasis-open.org/amqp/core/v1.0/amqp-core-overview-v1.0.html)(abbreviated as AMQP), such as Event Hubs, Web PubSub service uses [CloudEvents AMQP protocol binding](https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/bindings/amqp-protocol-binding.md) to map CloudEvents to AMQP messages.
+The Azure Web PubSub Service describes client events as [CloudEvents](https://github.com/cloudevents/spec/tree/v1.0.2). CloudEvents is a specification for describing event data in common formats to provide interoperability across services, platforms and systems. 
 
-The data sending from service to server is always in CloudEvents `binary` format.
+The Web PubSub service uses  [CloudEvents AMQP protocol binding](https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/bindings/amqp-protocol-binding.md) as an event listener to map CloudEvents to AMQP messages ([Advanced Message Queueing Protocol](http://docs.oasis-open.org/amqp/core/v1.0/amqp-core-overview-v1.0.html)).  
+
+The data sent from service to server is always in CloudEvents `binary` format.
 
 ## Web PubSub CloudEvents attribute extension
 
 <a name="extension"></a>
 
-This extension defines attributes used by Web PubSub for every event it produces.
+This extension defines the attributes used by Web PubSub for each event it produces.
 
 The following table contains attributes mapping to the  [standard properties](http://docs.oasis-open.org/amqp/core/v1.0/os/amqp-core-messaging-v1.0-os.html#type-properties) section of an AMQP message.
 
@@ -49,7 +51,7 @@ The "\*" following the attribute name indicates the attribute is present only wh
 ## Events
 <a name="events"></a>
 
-This chapter shows the AMQP message body and the attribute values that depend on the client event type. Attributes whose values don't depend on client event type are omitted here.
+This section shows the AMQP message body with the attribute values that depend on a specific client event type. Attribute values that don't depend on a client event type are omitted.
 
 - System `connect` event: Not supported by event listeners.
 - [System `connected` event](#connected)
@@ -79,7 +81,7 @@ The message body is always empty JSON.
 - `cloudEvents:type`: `azure.webpubsub.sys.disconnected`
 - `cloudEvents:eventname`: `disconnected`
 
-The message body contains the reason why the client disconnects.
+The message body contains the reason the client disconnected.
 
 ```json
 {"reason":"{Reason}"}

articles/azure-web-pubsub/reference-cloud-events.md

@@ -10,9 +10,9 @@ ms.date: 11/08/2021
 
 #  CloudEvents extension for Azure Web PubSub event handler with HTTP protocol
 
-Service delivers client events to the upstream webhook using the [CloudEvents HTTP protocol binding](https://github.com/cloudevents/spec/blob/v1.0.1/http-protocol-binding.md).
+The Web PubSub service delivers client events to the upstream webhook using the [CloudEvents HTTP protocol binding](https://github.com/cloudevents/spec/blob/v1.0.1/http-protocol-binding.md).
 
-The data sending from service to server is always in CloudEvents `binary` format.
+The data sent from the Web PubSub service to the server is always in CloudEvents `binary` format.
 
 - [Webhook Validation](#protection)
 - [Web PubSub CloudEvents Attribute Extension](#extension)
@@ -114,7 +114,7 @@ ce-eventName: connect
 * Status code:
     * `204`: Success, with no content.
     * `200`: Success, the content SHOULD be a JSON format, with following properties allowed:
-* Header `ce-connectionState`: If this header exists, the connection state of this connection will be updated to the value of the header. Please note that only *blocking* events can update the connection state. The below sample uses base64 encoded JSON string to store complex state for the connection.
+* Header `ce-connectionState`: If this header exists, the connection state of this connection will be updated to the value of the header. Please note that only *blocking* events can update the connection state. The below sample uses base64 encoded JSON string to store the complex state for the connection.
 *
 ```HTTP
 HTTP/1.1 200 OK
@@ -137,7 +137,7 @@ ce-connectionState: eyJrZXkiOiJhIn0=
 
 * `userId`: `{auth-ed user ID}`
 
-    As the service allows anonymous connections, it's the `connect` event's responsibility to tell the service the user ID of the client connection. The Service will read the user ID from the response payload `userId` if it exists. The connection will be dropped if user ID cannot be read from the request claims nor the `connect` event's response payload.
+    As the service allows anonymous connections, it's the `connect` event's responsibility to tell the service the user ID of the client connection. The service will read the user ID from the response payload `userId` if it exists. The connection will be dropped if the user ID cannot be read from the request claims nor the `connect` event's response payload.
 
 <a name="connect_response_header_group"></a>
 
@@ -147,7 +147,7 @@ ce-connectionState: eyJrZXkiOiJhIn0=
 
 * `roles`: `{roles the client has}`
 
-    The property provides a way for the upstream to authorize the client. Different roles define different initial permissions the client has, it can be useful when the client is a PubSub WebSocket client. Details about the permissions are described in [Client permissions](./concept-client-protocols.md#permissions).
+    The property provides a way for the upstream Webhook to authorize the client.   There are different roles to grant initial permissions for PubSub WebSocket clients. Details about the permissions are described in [Client permissions](./concept-client-protocols.md#permissions).
 
 #### Error response format:
 
@@ -434,7 +434,7 @@ UserResponsePayload
 * Status code
     * `204`: Success, with no content.
     * `200`: Success, data sending to the PubSub WebSocket client depends on the `Content-Type`;
-* Header `ce-connectionState`: If this header exists, the connection state of this connection will be updated to the value of the header. Please note that only *blocking* events can update the connection state. The below sample uses base64 encoded JSON string to store complex state for the connection.
+* Header `ce-connectionState`: If this header exists, the connection state of this connection will be updated to the value of the header. Please note that only *blocking* events can update the connection state. The below sample uses base64 encoded JSON string to store the complex state for the connection.
 * When Header `Content-Type` is `application/octet-stream`, the service sends `UserResponsePayload` back to the client using `dataType` as `binary` with payload base64 encoded. A sample response:
     ```json
     {