From 7c81d9918d82106614ab5156d3af182673f40381 Mon Sep 17 00:00:00 2001 From: Mahdi Baghbani Date: Tue, 10 Nov 2026 09:00:00 +0000 Subject: [PATCH 1/5] docs(ocm): define notification success responses Signed-off-by: Mahdi Baghbani --- IETF-OCM.md | 15 +++++++++++++++ spec.yaml | 7 ++++--- 2 files changed, 19 insertions(+), 3 deletions(-) diff --git a/IETF-OCM.md b/IETF-OCM.md index e8697ed..bdfe649 100644 --- a/IETF-OCM.md +++ b/IETF-OCM.md @@ -1449,6 +1449,21 @@ payload and identity bindings. * A receiver MAY return HTTP 501 for a known, valid notification type whose operation it does not implement. +## Response + +A Receiving Server that accepts a notification MUST respond with HTTP +201 (Created). The response has no body, and a Sending Server MUST +ignore any body that a Receiving Server nevertheless returns. A +Sending Server SHOULD treat any 2xx response as a successful delivery. +This also applies to a notification whose type the Receiving Server +does not know, and accepts and ignores as described in [Receiver +Processing](#receiver-processing). + +A successful response only confirms that the Receiving Server +received the notification and, for a type it knows, that the payload +was valid. It does not imply that the Receiving Server acted upon the +notification, changed any state, or informed any of its users. + ## Share Acceptance and Updating A notification MAY be sent by a recipient to let the provider know that diff --git a/spec.yaml b/spec.yaml index 967f0b9..4e4af84 100644 --- a/spec.yaml +++ b/spec.yaml @@ -214,9 +214,10 @@ paths: responses: "201": description: > - Receiver succesfully received the notification. The response body - MAY contain a JSON object with response data, depending on - the actual notification. + Receiver successfully received the notification. The response has + no body, including for unknown types that are accepted and ignored. + A receipt does not imply any Share mutation, remote user choice, + physical cleanup or global completion. "400": description: > Invalid notification envelope or malformed payload for a known From f2cccd433b6f1b3e8166df2ae81f0ff4dec63575 Mon Sep 17 00:00:00 2001 From: Mahdi Baghbani Date: Tue, 10 Nov 2026 16:00:00 +0000 Subject: [PATCH 2/5] docs(ocm): qualify contact denial receipts Signed-off-by: Mahdi Baghbani --- IETF-OCM.md | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git a/IETF-OCM.md b/IETF-OCM.md index bdfe649..81ef549 100644 --- a/IETF-OCM.md +++ b/IETF-OCM.md @@ -1459,10 +1459,15 @@ This also applies to a notification whose type the Receiving Server does not know, and accepts and ignores as described in [Receiver Processing](#receiver-processing). -A successful response only confirms that the Receiving Server -received the notification and, for a type it knows, that the payload -was valid. It does not imply that the Receiving Server acted upon the -notification, changed any state, or informed any of its users. +A successful response confirms receipt and, for a known type, payload +validity. Except for the CONTACT_REMOVED acceptance precondition, it +need not imply action, mutation or user notification. A capable server +MUST accept an authorized, correctly bound affected CONTACT_REMOVED +only after durable local denial of its exact pair grants, as specified +in [Contact Removal](#contact-removal). Identity or enforcement failure +before that commit requires a retryable server error, never HTTP 201. +An authoritative no-op may receive HTTP 201 without mutation. Neither +receipt nor local denial proves physical cleanup or global completion. ## Share Acceptance and Updating From dce958fd666383a035a3748efb134f7e86c6272a Mon Sep 17 00:00:00 2001 From: Mahdi Baghbani Date: Wed, 11 Nov 2026 12:00:00 +0000 Subject: [PATCH 3/5] docs(ocm): drop contact receipt exception Signed-off-by: Mahdi Baghbani --- IETF-OCM.md | 14 ++++++-------- 1 file changed, 6 insertions(+), 8 deletions(-) diff --git a/IETF-OCM.md b/IETF-OCM.md index 81ef549..1d0db2a 100644 --- a/IETF-OCM.md +++ b/IETF-OCM.md @@ -1460,14 +1460,12 @@ does not know, and accepts and ignores as described in [Receiver Processing](#receiver-processing). A successful response confirms receipt and, for a known type, payload -validity. Except for the CONTACT_REMOVED acceptance precondition, it -need not imply action, mutation or user notification. A capable server -MUST accept an authorized, correctly bound affected CONTACT_REMOVED -only after durable local denial of its exact pair grants, as specified -in [Contact Removal](#contact-removal). Identity or enforcement failure -before that commit requires a retryable server error, never HTTP 201. -An authoritative no-op may receive HTTP 201 without mutation. Neither -receipt nor local denial proves physical cleanup or global completion. +validity. It need not imply action, mutation or user notification. +An accepted "CONTACT_REMOVED" confirms the contact event only; local +contact operation errors MUST be reported as errors rather than a +false success, as described in [Contact Removal](#contact-removal). +Neither receipt nor a peer being offline proves physical cleanup, +remote user choice or global completion. ## Share Acceptance and Updating From 4c62940ae6b02534aee35c925b3efb6e9bff0738 Mon Sep 17 00:00:00 2001 From: Mahdi Baghbani Date: Thu, 12 Nov 2026 09:00:00 +0000 Subject: [PATCH 4/5] docs(ocm): clarify notification responses Signed-off-by: Mahdi Baghbani --- IETF-OCM.md | 23 ++++++++--------------- spec.yaml | 6 ++---- 2 files changed, 10 insertions(+), 19 deletions(-) diff --git a/IETF-OCM.md b/IETF-OCM.md index 1d0db2a..418675f 100644 --- a/IETF-OCM.md +++ b/IETF-OCM.md @@ -1451,21 +1451,14 @@ payload and identity bindings. ## Response -A Receiving Server that accepts a notification MUST respond with HTTP -201 (Created). The response has no body, and a Sending Server MUST -ignore any body that a Receiving Server nevertheless returns. A -Sending Server SHOULD treat any 2xx response as a successful delivery. -This also applies to a notification whose type the Receiving Server -does not know, and accepts and ignores as described in [Receiver -Processing](#receiver-processing). - -A successful response confirms receipt and, for a known type, payload -validity. It need not imply action, mutation or user notification. -An accepted "CONTACT_REMOVED" confirms the contact event only; local -contact operation errors MUST be reported as errors rather than a -false success, as described in [Contact Removal](#contact-removal). -Neither receipt nor a peer being offline proves physical cleanup, -remote user choice or global completion. +A receiver that accepts a notification MUST respond with HTTP 201 and +no body. A sender MUST ignore any response body and SHOULD treat any +2xx response as successful delivery. This includes valid unknown types +accepted and ignored under [Receiver Processing](#receiver-processing). + +Success confirms receipt and, for a known type, payload validity. It +does not guarantee a state change or distributed completion. A failed +local operation MUST NOT be reported as a successful operation. ## Share Acceptance and Updating diff --git a/spec.yaml b/spec.yaml index 4e4af84..dfdfd16 100644 --- a/spec.yaml +++ b/spec.yaml @@ -214,10 +214,8 @@ paths: responses: "201": description: > - Receiver successfully received the notification. The response has - no body, including for unknown types that are accepted and ignored. - A receipt does not imply any Share mutation, remote user choice, - physical cleanup or global completion. + Notification accepted. The response has no body. Receipt does + not guarantee a state change or distributed completion. "400": description: > Invalid notification envelope or malformed payload for a known From 7de5af599c5563596c6cdf3c9c92bf19c6db0916 Mon Sep 17 00:00:00 2001 From: Mahdi Baghbani Date: Thu, 12 Nov 2026 10:00:00 +0000 Subject: [PATCH 5/5] docs(ocm): scope notification response handling Signed-off-by: Mahdi Baghbani --- IETF-OCM.md | 10 +++------- 1 file changed, 3 insertions(+), 7 deletions(-) diff --git a/IETF-OCM.md b/IETF-OCM.md index 418675f..51df5d5 100644 --- a/IETF-OCM.md +++ b/IETF-OCM.md @@ -1452,13 +1452,9 @@ payload and identity bindings. ## Response A receiver that accepts a notification MUST respond with HTTP 201 and -no body. A sender MUST ignore any response body and SHOULD treat any -2xx response as successful delivery. This includes valid unknown types -accepted and ignored under [Receiver Processing](#receiver-processing). - -Success confirms receipt and, for a known type, payload validity. It -does not guarantee a state change or distributed completion. A failed -local operation MUST NOT be reported as a successful operation. +no body. Senders SHOULD treat any 2xx response as confirmation of +receipt and MUST ignore its body. Receipt does not confirm completion +of the requested action. ## Share Acceptance and Updating