Fixed all blocking feedback

Author: spelluru

articles/event-grid/authenticate-with-namespaces-using-webhook-authentication.md

@@ -201,7 +201,7 @@ Content-Type: application/json
 | expiration                | Expiration date in Unix time format. (Optional when Decision is set to allow) |
 | errorReason               | Error message if decision is set to deny. This error is logged. (Optional when Decision is set to deny) |
 
-### Examples of supported attribute types: 
+### Examples of supported attribute types 
 
 ```json
 "num_attr_pos": 1, 

articles/event-grid/includes/limits.md

@@ -53,7 +53,7 @@ The following limits apply to MQTT in Azure Event Grid namespace resource.
 | Inbound HTTP publishing requests per session              | 500 messages per second        |
 | Inbound HTTP bandwidth per session                        | 512 KB per second              |
 | Inbound in-flight HTTP messages*                          | 500 messages                   |
-| Maximum Retain Message Size                               | 64 KB                          |
+| Maximum Retain Message Size**                               | 64 KB                          |
 | Maximum Retain Messages per Throughput Unit (TU)          | 10,000 messages or 640 MB (whichever is reached first) |
 | Total Retain Storage per TU                               | 640 MB                         |
 | Retain Message Expiry (MQTT 3.1.1)                        | 365 days (default)             |
@@ -89,8 +89,10 @@ The following limits apply to MQTT in Azure Event Grid namespace resource.
 | Topic templates                              | 10 per topic space                                                                |
 | Permission bindings                          | 100                                                                               |
 
+
 \* For MQTTv5, learn more about [flow control support](../mqtt-support.md#flow-control).
-\* Retain messages count against the total MQTT storage quota for the namespace. When the quota is reached, publishing new retain messages will fail until existing messages are expired or deleted (e.g., via empty payload publish).
+
+\** Retain messages count against the total MQTT storage quota for the namespace. When the quota is reached, publishing new retain messages will fail until existing messages are expired or deleted (e.g., via empty payload publish).
 
 ## Events limits in Event Grid namespace
 

articles/event-grid/mqtt-how-to-http-publish.md

@@ -23,7 +23,7 @@ Azure Event Grid now supports publishing MQTT messages via HTTP, enabling backen
 
 This article explains how to publish MQTT messages via HTTP with Azure Event Grid. 
 
-## Get Your Connection Details
+## Get your connection details
 
 - Namespace fully qualified domain name (FQDN). Example: `contoso.westus3-1.ts.eventgrid.azure.net`.
 - Topic. Example: `devices/CXa-23112/prompt`.
@@ -40,7 +40,7 @@ Save this token to use in the `Authorization: Bearer <TOKEN>` header.
 
 ## Publish messages using HTTP
 
-### [cURL](#tab/curl)
+### [Curl](#tab/curl)
 
 Here’s an example cURL command to simulate the HTTP Publish. 
 
@@ -64,7 +64,7 @@ In this sample command:
 
 ### [Bruno](#tab/brno)
 
-## Import to Bruno
+### Import to Bruno
 1. Open Bruno.
 1. Select **Import Collection**, and then select `EventGrid_HTTP_Publish_Postman_Collection.json`. Here's the content for the JSON file:
 
@@ -164,12 +164,12 @@ In this sample command:
 Use MQTTX or any MQTT library (like paho-mqtt Python) to subscribe to the same topic to confirm delivery. 
 
 1. Create a new connection in MQTTX:
-    1. `Host: contoso.westus3-1.ts.eventgrid.azure.net`
-    1. `Port: 8883 (TLS)`
-    1. `Client ID: same as your Entra Object ID` 
-    1. `Username/Password: N/A — use certificate or token auth if configured`   
-- Subscribe to the topic you used in the HTTP POST command.
-- Run the **HTTP Publish** and watch for the message in MQTTX. You should see your payload appear.
+    - `Host: contoso.westus3-1.ts.eventgrid.azure.net`
+    - `Port: 8883 (TLS)`
+    - `Client ID: same as your Entra Object ID` 
+    - `Username/Password: N/A — use certificate or token auth if configured`   
+1. Subscribe to the topic you used in the HTTP POST command.
+1. Run the **HTTP Publish** and watch for the message in MQTTX. You should see your payload appear.
 
 If the publish **succeeds**, you see: 
 

articles/event-grid/mqtt-http-publish.md

@@ -42,7 +42,7 @@ Consider HTTP Publish when:
 1. Event Grid maps HTTP request parts to standard MQTT PUBLISH packet properties.
 1. Messages flow through the Event Grid routing and enrichment pipeline, ensuring delivery guarantees and applying any enrichment or transformation.
 
-## Example: MQTT PUBLISH Equivalent
+## Example: MQTT publish equivalent
 
 ```http
 PUBLISH Topic Name: devices/CXa-23112/prompt  
@@ -55,7 +55,7 @@ User Property: RequestId = 55f4a7ee-b0b4-4d7f-8eb5-2edba2ced5d7
 Payload: Please accept terms of licensing and agreement
 ```
 
-## Example: HTTP Publish Request
+## Example: HTTP publish request
 
 ```http
 POST /mqtt/messages?topic=devices%2FCXa-23112%2Fprompt&api-version=2025-02-15-preview HTTP/1.1  
@@ -75,7 +75,7 @@ Please accept terms of licensing and agreement
 
 
 
-## Request Parameters
+## Request parameters
 
 This table describes how HTTP request parts map to MQTT PUBLISH packet properties. Refer to the original documentation for full details.
 
@@ -108,14 +108,14 @@ This table describes how HTTP request parts map to MQTT PUBLISH packet propertie
 - Step 6: Send the request.
 - Step 7: Confirm delivery via logs and metrics in the Event Grid portal.
 
-## Authentication & Authorization
+## Authentication & authorization
 
 - HTTP Publish uses Microsoft Entra ID for authentication.
 - Add a Bearer token to the Authorization header.
 - The Microsoft Entra Object ID becomes the MQTT clientId.
 - The AuthN/AuthZ model aligns with standard MQTT connections.
 
-## Routing and Observability
+## Routing and observability
 
 - Metrics and logs include:
   - Protocol: http-publish
@@ -124,7 +124,7 @@ This table describes how HTTP request parts map to MQTT PUBLISH packet propertie
   - Source IP
   - Auth principal
 
-## Best Practices
+## Best practices
 
 - Use lowercase header keys where possible. HTTP/2 header keys are case-insensitive.
 - Monitor throughput — HTTP messages tend to be larger than direct MQTT messages.

articles/event-grid/mqtt-overview.md

@@ -48,7 +48,7 @@ MQTT is a publish-subscribe messaging transport protocol that was designed for c
 	- **Persistent sessions** ensure reliability by preserving the client's subscription information and messages when a client disconnects.
 	- **QoS 0 and 1** provide your clients with control over the efficiency and reliability of the communication.
 	- [MQTT Retain](mqtt-retain.md) ensures that the last published message on a topic is stored by the broker and automatically delivered to any new subscribers. This allows devices to instantly receive the latest known state without waiting for the next update, enabling faster and more reliable state synchronization across IoT systems. 
--  MQTT broker is adding more MQTT v5 and MQTT v3.1.1  features in the future to align more with the MQTT specifications. The following items detail the current differences between features supported by MQTT broker and the MQTT v5 specifications: QoS 2 isn't supported.  
+-  The following items detail the current differences between features supported by MQTT broker and the MQTT v5 specifications: QoS 2 isn't supported.  
 
 [Learn more about the MQTT broker and current limitations.](mqtt-support.md) 
 
@@ -121,7 +121,7 @@ Custom domain names support allows users to assign their own domain names to Eve
 An MQTT retain message is used to store the last known good value of a topic on the broker, ensuring that new subscribers immediately receive the most recent message without waiting for the next publish. This is especially useful in scenarios like device state reporting, control signals, or configuration data where the latest message must always be available to clients on connect. For more information, see [MQTT retain support in Azure Event Grid](mqtt-retain.md).
 
 
-### HTTP Publish(preview) 
+### HTTP Publish (preview) 
 
 HTTP Publish enables applications to publish MQTT messages to Azure Event Grid MQTT Broker over a simple HTTPS POST request, without maintaining an active MQTT session. It’s best suited for scenarios where MQTT clients are not feasible or necessary—such as serverless functions, cloud services, or backend applications—allowing event-driven architectures to inject MQTT messages reliably and securely. Common use cases include publishing device commands, alerts, or control signals from Azure Functions, Logic Apps, or API integrations. For more information, see [HTTP Publish of MQTT messages in Azure Event Grid](mqtt-http-publish.md).
 

articles/event-grid/mqtt-retain.md

@@ -22,7 +22,7 @@ This article provides an overview of how the MQTT Retain feature works, its bill
 ## Billing
 Each retained publish counts as two MQTT operations—one for processing the message, and one for storing it.
 
-## Storage limits: 
+## Storage limits 
 
 - Up to 640 MB or 10,000 retain messages per Throughput Unit (TU). 
 - Maximum size per retain message: 64 KB. 
@@ -31,8 +31,8 @@ For larger needs, contact Azure Support.
 
 ## Message deletion 
 
-**MQTT 3.1.1**: Publish an empty payload to the topic. 
-**MQTT 5.0**: Set expiry or send an empty message to remove it. 
+- **MQTT 3.1.1**: Publish an empty payload to the topic.
+- **MQTT 5.0**: Set expiry or send an empty message to remove it. 
 
 ## Retain management 
 

articles/event-grid/mqtt-support.md

@@ -134,7 +134,7 @@ MQTT v5 ensures in-order message delivery within per topic and per client when u
 
 However, it doesn't guarantee ordering across different topics or when messages are sent with varying QoS levels. To learn more, contact us [[email protected]](mailto:[email protected]).
 
-### Assigned Client Identifiers 
+### Assigned client identifiers 
 MQTT v5 introduces support for assigned client identifiers, allowing the broker to generate and return a unique client ID when one isn't provided by the client. MQTT broker supports this feature, ensuring seamless client onboarding and reducing the need for clients to manage their own identifiers. It's especially useful in scenarios where client provisioning is dynamic or when devices have no preconfigured identity. Assigned client IDs can be retrieved from the CONNACK response and reused for future sessions to maintain consistent identification. 
 
 #### Managing client identifier and session limits in MQTT 
@@ -165,7 +165,7 @@ MQTT v5 currently differs from the [MQTT v5 Specification](https://docs.oasis-op
 ### MQTTv3.1.1 current limitations
 
 MQTT v5 currently differs from the [MQTT v3.1.1 Specification](http://docs.oasis-open.org/mqtt/mqtt/v3.1.1/os/mqtt-v3.1.1-os.html) in the following ways:
-- QoS2 isn't supported yet. A publish request with a retain flag or with a QoS2 fails and closes the connection.
+- QoS2 isn't supported. A publish request with a retain flag or with a QoS2 fails and closes the connection.
 - Keep Alive Maximum is 1,160 seconds.
 
 ## Code samples