From 95500aeef95807ffeed1a8e895ba43fa7a747edd Mon Sep 17 00:00:00 2001 From: Steve Kille Date: Fri, 4 May 2018 09:38:42 +0100 Subject: [PATCH] Flag that section 6.3 (Ensuring Message Delivery) needs review; --- xep-0369.xml | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/xep-0369.xml b/xep-0369.xml index 86cf1353..29a0ecea 100644 --- a/xep-0369.xml +++ b/xep-0369.xml @@ -47,7 +47,7 @@ Clarify configuration Last Change Made By; Clarify Mandatory Presence; Clarification of MIX annotation of roster updates; - + Flag that section 6.3 (Ensuring Message Delivery) needs review;

@@ -1788,7 +1788,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa

- A MIX channel MAY support message retraction, where the sender of a messages or an authorized administrator deletes a message. A MIX channel MAY limit the time frame in which a message is allowed to be retracted, for example to prevent retraction of very old messages. When a messages is retracted the original message MAY be replaced by a tombstone. Message retraction is done by sending a special message that identifies the original message. This mechanism allows the retraction to be distributed on the same path as the original message so that all participating servers and clients MAY honour the retraction. The protocol to request retraction does this by adding to a message a <retract> element qualified by the 'urn:xmpp:mix:1' namespace. A retract messages MUST NOT have a body. The <retract> element MUST include an <id> attribute that holds the MAM-ID of the original message. The message sender will need to look up the MAM-ID. The MAM-ID is the convenient message identification for message recipients. A message and it's retraction shown in the following example. + A MIX channel MAY support message retraction, where the sender of a messages or an authorized administrator deletes a message. A MIX channel MAY limit the time frame in which a message is allowed to be retracted, for example to prevent retraction of very old messages. When a messages is retracted the original message MAY be replaced by a tombstone. Message retraction is done by sending a special message that identifies the original message. This mechanism allows the retraction to be distributed on the same path as the original message so that all participating servers and clients MAY honour the retraction. The protocol to request retraction does this by adding to a message a <retract> element qualified by the 'urn:xmpp:mix:1' namespace. A retract messages MUST NOT have a body. The <retract> element MUST include an 'id' attribute that holds the MAM-ID of the original message. The message sender will need to look up the MAM-ID. The MAM-ID is the convenient message identification for message recipients. A message and it's retraction shown in the following example.

    -
  1. The inviter checks with disco that the invitee supports MIX.
    2. +
  2. The inviter checks using capability discovery that the invitee supports MIX.
  3. The channel inviter sends to the channel requesting an invite for the invitee.
  4. The channel sends an invitation to the inviter.
  5. The inviter sends the invitation to the invitee.
    6. @@ -2028,6 +2028,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa

    +

    + AUTHOR NOTE (SEK): This section has issues and needs detailed review. Author action will be taken. +

    It is important that messages are all transferred from the MIX channel to the server associated with the each channel participant. Transfer between servers will typically happen quickly and &xep0198; will deal with short connection failures between servers. Longer connection failures could lead to message loss. This would lead to online users (who remain connected to their servers) missing messages, and to messages being missed out of the user archive. This section describes how MIX addresses this.