From e9db783df6a1baf6c980872e29fe29fe944b7d84 Mon Sep 17 00:00:00 2001 From: Giuseppe Lo Presti Date: Thu, 22 Oct 2026 17:58:36 +0200 Subject: [PATCH 1/2] Renamed USER_REMOVED to CONTACT_REMOVED and spelled out the cases --- IETF-OCM.md | 25 +++++++++++++++---------- spec.yaml | 5 +++-- 2 files changed, 18 insertions(+), 12 deletions(-) diff --git a/IETF-OCM.md b/IETF-OCM.md index b046901..74c27a6 100644 --- a/IETF-OCM.md +++ b/IETF-OCM.md @@ -1497,26 +1497,31 @@ such as HTTP 404. A notification MAY be sent to inform a target OCM Server that a share recipient (e.g. a user or group) was removed from the list of trusted users, following a previous successful Invitation, or otherwise left -the system. That recipient may have been previously known to the -target server because of existing shares whose shareType matched it. -The recipient of such notification MAY reciprocally remove that -recipient from the list of trusted users, along with any related -shares. +the realm of the sending OCM Server. That recipient may have been +previously known to the target server because of existing shares whose +shareType matched it. The recipient of such notification SHOULD +reciprocally remove that peer from the list of trusted users, along +with any related shares. For these cases, a notification payload is to be formed such that the `resourceType` MUST be omitted, the `shareType` is set to the affected shareType being removed, such as `user` or `group`, and the `notificationType` MUST be one of: -- "USER_REMOVED", to inform about a single user that was removed or - marked as not trusted. -- "GROUP_REMOVED", to inform about a removed group. +- "CONTACT_REMOVED", to inform that a single user contact was removed + from the list of trusted contacts, either by the peer user or by the + system e.g. in case that user left. +- "GROUP_REMOVED", to inform about a removed group of users. Further, the `notification` object MUST include the following fields: * OPTIONAL message (string) - an optional human-readable message that describes the event. * REQUIRED user or group (object) - an object containing the details of the recipient to be removed. In case of `user`, it MUST include: - * REQUIRED userId (string) - OCM Address of the user to be removed - from the target OCM Server. + * REQUIRED userId (string) - OCM Address of the user that performed + the removal, or that left. + * OPTIONAL localUserId (string) - OCM Address of the user, local at + the target server, that was removed by the above peer contact. + If missing, it is assumed that the user to be removed has left the + realm of the sending OCM Server. Whereas in case of `group`, it MUST include: * REQUIRED groupId (string) - identifier of the group to be removed from the target OCM Server. diff --git a/spec.yaml b/spec.yaml index f6b6501..fa866df 100644 --- a/spec.yaml +++ b/spec.yaml @@ -1129,14 +1129,15 @@ components: message: Recipient accepted the share file: providerId: 7c084226-d9a1-11e6-bf26-cec0c932ce01 - userWasRemoved: - notificationType: USER_REMOVED + contactWasRemoved: + notificationType: CONTACT_REMOVED shareType: user senderDomain: alice.example.org notification: message: User is not a trusted contact any longer user: userId: alice@alice.example.org + localUserId: bob@bob.example.org mlsWelcome: notificationType: MLS_WELCOME shareType: federation From 9bac2b3050d03fa80d2cda0cd0c7633dd5204fc6 Mon Sep 17 00:00:00 2001 From: Giuseppe Lo Presti Date: Fri, 30 Oct 2026 18:02:48 +0100 Subject: [PATCH 2/2] Separate the two scenarios as different notifications We now have both CONTACT_REMOVED and USER_REMOVED, the latter for the case of a user leaving the system. --- IETF-OCM.md | 15 +++++++++------ spec.yaml | 10 +++++++++- 2 files changed, 18 insertions(+), 7 deletions(-) diff --git a/IETF-OCM.md b/IETF-OCM.md index 74c27a6..c408eb7 100644 --- a/IETF-OCM.md +++ b/IETF-OCM.md @@ -1508,8 +1508,10 @@ For these cases, a notification payload is to be formed such that the shareType being removed, such as `user` or `group`, and the `notificationType` MUST be one of: - "CONTACT_REMOVED", to inform that a single user contact was removed - from the list of trusted contacts, either by the peer user or by the - system e.g. in case that user left. + from the list of trusted contacts by the peer user. +- "USER_REMOVED", to inform that a user left or was removed from the + realm of the sending OCM Server, and is therefore no longer reachable + as a contact. - "GROUP_REMOVED", to inform about a removed group of users. Further, the `notification` object MUST include the following fields: * OPTIONAL message (string) - an optional human-readable message that @@ -1518,10 +1520,11 @@ Further, the `notification` object MUST include the following fields: of the recipient to be removed. In case of `user`, it MUST include: * REQUIRED userId (string) - OCM Address of the user that performed the removal, or that left. - * OPTIONAL localUserId (string) - OCM Address of the user, local at - the target server, that was removed by the above peer contact. - If missing, it is assumed that the user to be removed has left the - realm of the sending OCM Server. + * REQUIRED targetUserId (string) - only for "CONTACT_REMOVED": OCM + Address of the user, local at the target server, that was removed + by the above peer contact. It MUST be omitted for "USER_REMOVED", + where all contacts and shares related to `userId` at the target + server are to be removed. Whereas in case of `group`, it MUST include: * REQUIRED groupId (string) - identifier of the group to be removed from the target OCM Server. diff --git a/spec.yaml b/spec.yaml index fa866df..d6a0480 100644 --- a/spec.yaml +++ b/spec.yaml @@ -1137,7 +1137,15 @@ components: message: User is not a trusted contact any longer user: userId: alice@alice.example.org - localUserId: bob@bob.example.org + targetUserId: bob@bob.example.org + userLeft: + notificationType: USER_REMOVED + shareType: user + senderDomain: alice.example.org + notification: + message: User left the system + user: + userId: alice@alice.example.org mlsWelcome: notificationType: MLS_WELCOME shareType: federation