Update cancellation.md

Author: jspahrsummers

docs/specification/basic/utilities/cancellation.md

@@ -29,52 +29,49 @@ When a party wants to cancel an in-progress request, it sends a `notifications/c
 
 ## Behavior Requirements
 
-Both clients and servers MUST follow these requirements when handling cancellation:
-
-1. Cancellation notifications MUST only reference requests that:
+1. Cancellation notifications **MUST** only reference requests that:
    - Were previously issued in the same direction
    - Are believed to still be in-progress
-
-2. The `initialize` request MUST NOT be cancelled by clients
-
-3. Receivers of cancellation notifications SHOULD:
+2. The `initialize` request **MUST NOT** be cancelled by clients
+3. Receivers of cancellation notifications **SHOULD**:
    - Stop processing the cancelled request
    - Free associated resources
    - Not send a response for the cancelled request
-
-4. Receivers MAY ignore cancellation notifications if:
+4. Receivers **MAY** ignore cancellation notifications if:
    - The referenced request is unknown
    - Processing has already completed
    - The request cannot be cancelled
+5. The sender of the cancellation notification **SHOULD** ignore any response to the request that arrives afterward
 
 ## Timing Considerations
 
-Due to network latency, cancellation notifications may arrive after request processing has completed. Both parties MUST handle these race conditions gracefully:
+Due to network latency, cancellation notifications may arrive after request processing has completed, and potentially after a response has already been sent.
+
+Both parties **MUST** handle these race conditions gracefully:
 
 ```mermaid
 sequenceDiagram
-    participant Client
-    participant Server
-
-    Client->>Server: Request (ID: 123)
-    Note over Server: Processing starts
-    Client--)Server: notifications/cancelled (ID: 123)
-    Note over Server: Processing may<br/>complete before<br/>cancellation arrives
-    opt If not completed
-        Note over Server: Stop processing
-    end
+   participant Client
+   participant Server
+
+   Client->>Server: Request (ID: 123)
+   Note over Server: Processing starts
+   Client--)Server: notifications/cancelled (ID: 123)
+   alt 
+      Note over Server: Processing may have<br/>completed before<br/>cancellation arrives
+   else If not completed
+      Note over Server: Stop processing
+   end
 ```
 
 ## Implementation Notes
 
-- Servers SHOULD implement timeouts for long-running operations
-- Clients SHOULD track pending requests that can be cancelled
-- Both parties SHOULD log cancellation reasons for debugging
-- UIs SHOULD provide feedback when cancellation is requested
+- Both parties **SHOULD** log cancellation reasons for debugging
+- Application UIs **SHOULD** indicate when cancellation is requested
 
 ## Error Handling
 
-Invalid cancellation notifications SHOULD be ignored without error responses:
+Invalid cancellation notifications **SHOULD** be ignored:
 
 - Unknown request IDs
 - Already completed requests