moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 18:22:24 -05:00
Code Issues Releases Wiki Activity

Flag that section 6.3 (Ensuring Message Delivery) needs review;

Browse Source
This commit is contained in:
Steve Kille 2018-05-04 09:38:42 +01:00
parent 658ae8500a
commit 95500aeef9
1 changed files with 6 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

9
xep-0369.xml
View File

@ -47,7 +47,7 @@
Clarify configuration Last Change Made By; Clarify configuration Last Change Made By;
Clarify Mandatory Presence; Clarify Mandatory Presence;
Clarification of MIX annotation of roster updates; Clarification of MIX annotation of roster updates;
Flag that section 6.3 (Ensuring Message Delivery) needs review;
</p></remark> </p></remark>
</revision> </revision>
@ -1788,7 +1788,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
<section3 topic="Retracting a Message" anchor="usecase-retract"> <section3 topic="Retracting a Message" anchor="usecase-retract">
<p> <p>
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 &lt;retract&gt; element qualified by the 'urn:xmpp:mix:1' namespace. A retract messages MUST NOT have a body. The &lt;retract&gt; element MUST include an &lt;id&gt; 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 &lt;retract&gt; element qualified by the 'urn:xmpp:mix:1' namespace. A retract messages MUST NOT have a body. The &lt;retract&gt; 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.
</p> </p>
<example caption="User Retracts a Message"><![CDATA[ <example caption="User Retracts a Message"><![CDATA[
@ -1844,7 +1844,7 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</p> </p>
<ol> <ol>
<li>The inviter checks with disco that the invitee supports MIX.</li> <li>The inviter checks using capability discovery that the invitee supports MIX.</li>
<li>The channel inviter sends to the channel requesting an invite for the invitee.</li> <li>The channel inviter sends to the channel requesting an invite for the invitee.</li>
<li>The channel sends an invitation to the inviter.</li> <li>The channel sends an invitation to the inviter.</li>
<li>The inviter sends the invitation to the invitee.</li> <li>The inviter sends the invitation to the invitee.</li>
@ -2028,6 +2028,9 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</p> </p>
</section2> </section2>
<section2 topic="Ensuring Message Delivery" anchor="use-ensure-delivery"> <section2 topic="Ensuring Message Delivery" anchor="use-ensure-delivery">
<p>
AUTHOR NOTE (SEK): This section has issues and needs detailed review. Author action will be taken.
</p>
<p> <p>
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. 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.
</p> </p>