Merge pull request #2094 from reubenmiller/docs-mqtt-api-minor-correc…

…tions

docs(mqtt-spec): minor corrections and additional context

docs/src/references/mqtt-api.md

@@ -351,6 +351,12 @@ tedge mqtt pub -r 'te/device/child01/service/nodered' '{
 }'
 ```
 
+:::info
+A service is always owned by a device. The `@parent` property in the registration message is used to declare the service's owner. The lifecycle of the service is tied to the device's lifecycle.
+
+For example, a linux service runs on a device as it relies on physical hardware to run. A service can have its own telemetry data (e.g. tracking RAM usage of single process), however when the device ceases to exist, then so does the service.
+:::
+
 #### Register a service of a nested child device
 
 ```sh te2mqtt
@@ -510,7 +516,7 @@ The metadata fields supported by each data type will be defined in detail later.
 
 ## Commands
 
-The topic scheme for commands can be visualized using the diagram below. The **identifier** is used as the command 
+The topic scheme for commands can be visualized using the diagram below.
 
 <p align="center">
 
@@ -646,8 +652,7 @@ tedge mqtt pub -r te/device/main///cmd/health/check '{}'
 
 On receipt of the above command, all services on that device should respond with their health status.
 
-The services are also expected to register a `down` status Last Will and Testament (LWT) message with the broker
-as follows so that the broker updates the health status when that service stops or crashes unexpectedly:
+The services are also expected to register an MQTT Last Will and Testament (LWT) message with the broker to publish a `down` status message in the event that the service stops or crashes unexpectedly. The Last Will and Testament message ensures that the down status is published even if the service is not operational. The following example details such a message:
 
 ```sh te2mqtt
 tedge mqtt pub -r te/device/main/service/tedge-agent/status/health '{