1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 10:12:19 -05:00

Replace contents of section 6.3 (Ensuring Message Delivery) with reference to future XEP;

This commit is contained in:
Steve Kille 2018-05-09 09:37:09 +01:00
parent 180111a7f5
commit b9415be939

View File

@ -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;
Replace contents of section 6.3 (Ensuring Message Delivery) with reference to future XEP;
Add MIX Channels in Roster Section;
Add Proxy JID Architecture Section;
</p></remark>
@ -2068,30 +2068,12 @@ This approach enables flexible support of multiple clients for a MIX channel pa
</section2>
<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.
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.
</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.
To avoid missing messages, use is made of "NEW XEP - TO BE WRITTEN".
</p>
<p>
When there is a long term connection failure, the MIX channel will receive an error from the XMPP server indicating that a message failed to transfer to a recipient. When this happens, the MIX channel MUST take responsibility to ensure that the message is retransmitted and delivered. When the MIX channel detects a failure it will make use of an IQ Marker message to determine when the connection to the peer server is working again. Once the channel has received a response to the marker IQ it will retransmit the pending messages. The marker is encoded as a &lt;marker/&gt; child element of an &lt;iq/&gt; element. The &lt;marker/&gt; element is qualified by the 'urn:xmpp:mix:1' namespace.
</p>
<example caption="Channel Sends Marker Message" ><![CDATA[
<iq from='coven@mix.shakespeare.example'
id='lx09df27'
to='hag66@shakespeare.example'
type='get'>
<marker xmlns='urn:xmpp:mix:1'/>
</iq>
<iq from='hag66@shakespeare.example'
id='lx09df27'
to='coven@mix.shakespeare.example'
type='result'>
<marker xmlns='urn:xmpp:mix:1'/>
</iq>
]]></example>
</section2>
<section2 topic="Use of MAM" anchor="use-mam">