moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

Merge branch 'feature/xep-0369'

Browse Source
This commit is contained in:
Jonas Schäfer 2020-03-31 20:29:45 +02:00
commit 3036010232
1 changed files with 25 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

30
xep-0369.xml
View File

@ -35,6 +35,17 @@
<shortname>MIX-CORE</shortname>
&ksmithisode;
&skille;
<revision>
<version>0.14.4</version>
<date>2020-03-26</date>
<initials>egp</initials>
<remark><ul>
<li>Add missing disco#info features or identities in disco#info examples.</li>
<li>Fix typo in examples (xlns→xmlns).</li>
<li>Rename urn:xmpp:mix:nodes:information to urn:xmpp:mix:nodes:info in the text.</li>
<li>Add a way to unsubscribe from nodes without leaving a channel.</li>
</ul></remark>
</revision>
<revision>
<version>0.14.3</version>
<date>2020-03-03</date>
@ -567,7 +578,7 @@
</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 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:information' 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:info' 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 associated user will still be listed as an participant. </li>
<li>Presence is sent to 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>
@ -780,6 +791,7 @@
category='conference'
name='Shakespearean Chat Service'
type='mix'/>
<feature var='http://jabber.org/protocol/disco#info'/>
<feature var='urn:xmpp:mix:core:1'/>
<feature var='urn:xmpp:mix:core:1#searchable'>
</query>
@ -840,6 +852,7 @@
category='conference'
name='A Dark Cave'
type='mix'/>
<feature var='http://jabber.org/protocol/disco#info'/>
<feature var='urn:xmpp:mix:core:1'/>
<feature var='urn:xmpp:mam:2'/>
</query>
@ -884,7 +897,7 @@
id='kl2fax27'
to='coven@mix.shakespeare.example'
type='get'>
<pubsub xlns='http://jabber.org/protocol/pubsub'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:mix:nodes:info'/>
</pubsub>
</iq>
@ -937,7 +950,7 @@
id='kl2fax27'
to='hag66@shakespeare.example/UUID-c8y/1573'
type='result'>
<pubsub xlns='http://jabber.org/protocol/pubsub'>
<pubsub xmlns='http://jabber.org/protocol/pubsub'>
<items node='urn:xmpp:mix:nodes:participants'>
<item id='123456'>
<participant xmlns='urn:xmpp:mix:core:1'>
@ -975,6 +988,10 @@
to='juliet@capulet.example/UUID-e3r/9264'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity
category='client'
name='Swift'
type='pc'/>
<feature var='http://jabber.org/protocol/caps'/>
<feature var='http://jabber.org/protocol/disco#info'/>
<feature var='http://jabber.org/protocol/disco#items'/>
@ -1074,7 +1091,7 @@
</p>
<p>
A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request encoded as a &lt;update-subscription/&gt; child element of &lt;iq/&gt; element. The &lt;update-subscription/&gt; element is qualified by the 'urn:xmpp:mix:core:1' namespace. The requested nodes are encoded as &lt;subscribe/&gt; child elements of the &lt;update-subscription/&gt; element with the node name encoded as a 'node' attribute. This modification goes directly from client to the MIX channel, as this change does not impact the roster and so does not need any local action. The following example shows subscription modification.
A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request encoded as a &lt;update-subscription/&gt; child element of &lt;iq/&gt; element. The &lt;update-subscription/&gt; element is qualified by the 'urn:xmpp:mix:core:1' namespace. The requested nodes are encoded as &lt;subscribe/&gt; and &lt;unsubscribe/&gt; child elements of the &lt;update-subscription/&gt; element with the node name encoded as a 'node' attribute. This modification goes directly from client to the MIX channel, as this change does not impact the roster and so does not need any local action. The following example shows subscription modification.
</p>
<example caption="User Modifies Subscription Request"><![CDATA[
<iq type='set'
@ -1083,6 +1100,7 @@
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<update-subscription xmlns='urn:xmpp:mix:core:1'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
<unsubscribe node='urn:xmpp:mix:nodes:presence'/>
</update-subscription>
</iq>
@ -1093,11 +1111,12 @@
<update-subscription xmlns='urn:xmpp:mix:core:1'
jid='hag66@shakespeare.example'>
<subscribe node='urn:xmpp:mix:nodes:messages'/>
<unsubscribe node='urn:xmpp:mix:nodes:presence'/>
</update-subscription>
</iq>
]]></example>
<p>
A user MAY specify a nick when joining the channel. Channels MAY have mandatory nicks, which is default behavior. Therefore it is will generally be necessary to include a nick when joining an channel. If nick is missing on a channel where nick is mandatory, the join MUST be rejected. Other error cases are dealt with below with the nick management commands. Where a nick is specified, the join will only complete if the nick is accepted. The nick used MUST be reported back in the join result.
A user MAY specify a nick when joining the channel. Channels MAY have mandatory nicks, which is default behavior. Therefore it will generally be necessary to include a nick when joining an channel. If nick is missing on a channel where nick is mandatory, the join MUST be rejected. Other error cases are dealt with below with the nick management commands. Where a nick is specified, the join will only complete if the nick is accepted. The nick used MUST be reported back in the join result.
</p>
</section3>
<section3 topic='Leaving a Channel' anchor='usecase-user-leaving'>
@ -1299,6 +1318,7 @@
category='conference'
name='Shakespearean Chat Service'
type='mix'/>
<feature var='http://jabber.org/protocol/disco#info'/>
<feature var='urn:xmpp:mix:core:1'/>
<feature var='urn:xmpp:mix:core:1#create-channel'>
</query>