virtio-msg: Switch error signaling to normative

Signed-off-by: Bertrand Marquis <bertrand.marquis@arm.com>

Author: bertrand-marquis

transport-msg.tex

@@ -314,31 +314,33 @@ \subsubsection{Feature Negotiation Blocks}
 \subsubsection{Error Signaling}
 \label{sec:Virtio Transport Options / Virtio Over Messages / Basic Concepts / ErrorSignaling}
 
-Errors MAY arise from: (a) malformed or unsupported transport messages, (b)
-transmission or routing issues within a bus implementation, or (c) device-side
-failures while processing a valid request. Local detection and recovery are
-preferred, but a virtio-msg bus MAY report transmission errors to the
-virtio-msg transport when it cannot deliver a request or obtain a response
-within a bounded policy.
-
-The following rules apply:
+Transport errors can arise from malformed messages, routing failures inside a
+bus implementation, or device-side faults while processing a valid request.
+Implementations should handle such faults locally where possible, but a bus may
+surface an error to the virtio-msg transport if it cannot deliver a request or
+obtain a response within its policy.
+
+\busnormative{\paragraph}{Error Handling (Bus)}{Virtio Transport Options / Virtio Over Messages / Basic Concepts / ErrorSignaling / Bus}
+\begin{itemize}
+  \item A bus implementation MAY report a transport-visible failure (for example, after exhausting
+        a bounded retry policy) when it cannot deliver a request or obtain a response.
+  \item A bus implementation MUST treat malformed headers or unsupported \field{msg_id} values as
+        invalid, MUST discard them without generating additional protocol traffic, and MAY log the
+        condition for diagnostics.
+  \item A bus implementation MUST NOT generate error responses to event (one-way) messages.
+\end{itemize}
+
+\devicenormative{\paragraph}{Error Handling (Device)}{Virtio Transport Options / Virtio Over Messages / Basic Concepts / ErrorSignaling / Device}
 \begin{itemize}
-  \item A bus implementation MAY surface a transport-visible failure
-    (implementation-defined) after exhausting any bounded retry policy for
-    a transmission error.
-  \item Malformed headers or unsupported \field{msg_id} values SHOULD
-    be discarded; the receiver MAY log them and SHOULD NOT
-    generate further protocol traffic in response.
-  \item Event (one-way) messages MUST NOT elicit an error response.
-  \item Recovery actions (retry, selective reset, device removal) are
-    environment-specific but MUST comply with any normative reset
-    or status handling semantics described in
-    \ref{sec:Virtio Transport Options / Virtio Over Messages / Device Operation}.
+  \item A device receiving a malformed or unsupported transport message MUST discard it without
+        producing further protocol traffic.
+  \item Recovery actions taken in response to an error (such as retries, selective resets, or device
+        removal) MUST follow the normative reset and status semantics defined in
+        \ref{sec:Virtio Transport Options / Virtio Over Messages / Device Operation}.
 \end{itemize}
 
-This specification does not mandate a specific error reporting message for
-transmission failures; it only permits a virtio-msg bus to surface such
-failures to the virtio-msg transport when silent recovery is not feasible.
+This specification does not define a dedicated error-reporting message; it only permits implementations
+to surface failures when silent recovery is not feasible.
 
 \subsubsection{Endianness}
 \label{sec:Virtio Transport Options / Virtio Over Messages / Basic Concepts / Endianness}