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

Version bump to 0.3

Browse Source
This commit is contained in:
Steve Kille 2016-09-05 10:15:47 +01:00
parent e0f8251c75
commit b93e17bd2e
1 changed files with 13 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

15
xep-0369.xml
View File

@ -39,6 +39,14 @@
<jid>Steve.Kille@isode.com</jid> <jid>Steve.Kille@isode.com</jid>
</author> </author>
&stpeter; &stpeter;
<revision>
<version>0.3</version>
<date>2016-09-05</date>
<initials>sek</initials>
<remark><p>Addressing comments from review of 0.2 and expansion/clarification of MUC/MIX dual working</p></remark>
</revision>
<revision> <revision>
<version>0.2.3</version> <version>0.2.3</version>
<date>2016-09-01</date> <date>2016-09-01</date>
@ -131,7 +139,7 @@
<li>&xep0313; (MAM) is used for all history access, with each node being individually addressable for MAM queries. This simplifies implementation compared to MUC (which had a specialized and rather limited history retrieval mechanism).</li> <li>&xep0313; (MAM) is used for all history access, with each node being individually addressable for MAM queries. This simplifies implementation compared to MUC (which had a specialized and rather limited history retrieval mechanism).</li>
<li>A client can achieve a 'quick resync' of a node by requesting just those changes it has not yet received, using standard MAM protocol. This solves the old MUC issue of either receiving duplicate messages when rejoining a room or potentially missing messages.</li> <li>A client can achieve a 'quick resync' of a node by requesting just those changes it has not yet received, using standard MAM protocol. This solves the old MUC issue of either receiving duplicate messages when rejoining a room or potentially missing messages.</li>
<li>Because MAM is used for history, only those nodes that have a 'current value' need to store any items in them &mdash; e.g., 'urn:xmpp:mix:nodes:presence' and 'urn:xmpp:mix:nodes:subject' would store their current values (with older values being queryable through MAM), while 'urn:xmpp:mix:nodes:messages' would store no items.</li> <li>Because MAM is used for history, only those nodes that have a 'current value' need to store any items in them &mdash; e.g., 'urn:xmpp:mix:nodes:presence' and 'urn:xmpp:mix:nodes:subject' would store their current values (with older values being queryable through MAM), while 'urn:xmpp:mix:nodes:messages' would store no items.</li>
<li>A user's participation in a channel outlives their client sessions. A client which is offline will not share presence within the channel, but the associatd user will still be listed as an participant. </li> <li>A user's participation in a channel outlives their client sessions. A client which is offline will not share presence within the channel, but the associated user will still be listed as an participant. </li>
<li>Presence is sent to all participants using bare JID, whether or not the user has an online client. </li> <li>Presence is sent to all participants using bare JID, whether or not the user has an online client. </li>
<li>Online clients MAY register presence, which is then shared with participants who have subscribed to presence.</li> <li>Online clients MAY register presence, which is then shared with participants who have subscribed to presence.</li>
<li>MIX decouples addressing of occupants from their nicknames, so that nickname changes do not affect addressing.</li> <li>MIX decouples addressing of occupants from their nicknames, so that nickname changes do not affect addressing.</li>
@ -678,7 +686,10 @@
</iq> </iq>
]]></example> ]]></example>
<p>On success, the service informs the user of its nick. The nick that is issued might be different from the nick that was requested, for example if the service completes normalization of nicknames for purposes of internationalization.</p> <p>On success, the service informs the user of its nick. The nick that is issued might be different from the nick that was requested, for example if the service completes normalization of nicknames for purposes of internationalization.</p>
<p>MIX services SHOULD apply the "nickname" profile of the PRECIS OpaqueString class, which is defined in draft-ietf-precis-nickname.</p> <p>
MIX services SHOULD apply the "nickname" profile of the PRECIS OpaqueString class, as defined in &rfc7700;.
</p>
<example caption="Service Returns User of Nick"><![CDATA[ <example caption="Service Returns User of Nick"><![CDATA[
<iq type='result' <iq type='result'
to='mix.shakespeare.example' to='mix.shakespeare.example'