diff --git a/xep-0369.xml b/xep-0369.xml
index 8ab1655e..cf7e8c40 100644
--- a/xep-0369.xml
+++ b/xep-0369.xml
@@ -35,6 +35,17 @@
MIX-CORE
&ksmithisode;
&skille;
+
+ 0.14.4
+ 2020-03-26
+ egp
+
+ - Add missing disco#info features or identities in disco#info examples.
+ - Fix typo in examples (xlns→xmlns).
+ - Rename urn:xmpp:mix:nodes:information to urn:xmpp:mix:nodes:info in the text.
+ - Add a way to unsubscribe from nodes without leaving a channel.
+
+
0.14.3
2020-03-03
@@ -567,7 +578,7 @@
&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).
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.
- Because MAM is used for history, only those nodes that have a 'current value' need to store any items in them — 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.
+ Because MAM is used for history, only those nodes that have a 'current value' need to store any items in them — 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.
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.
Presence is sent to participants using bare JID, whether or not the user has an online client.
Online clients MAY register presence, which is then shared with participants who have subscribed to presence.
@@ -780,6 +791,7 @@
category='conference'
name='Shakespearean Chat Service'
type='mix'/>
+
@@ -840,6 +852,7 @@
category='conference'
name='A Dark Cave'
type='mix'/>
+
@@ -884,7 +897,7 @@
id='kl2fax27'
to='coven@mix.shakespeare.example'
type='get'>
-
+
@@ -937,7 +950,7 @@
id='kl2fax27'
to='hag66@shakespeare.example/UUID-c8y/1573'
type='result'>
-
+
-
@@ -975,6 +988,10 @@
to='juliet@capulet.example/UUID-e3r/9264'
type='result'>
+
@@ -1074,7 +1091,7 @@
- A user MAY subsequently modify subscription to nodes in a channel by sending a subscription modification request encoded as a <update-subscription/> child element of <iq/> element. The <update-subscription/> element is qualified by the 'urn:xmpp:mix:core:1' namespace. The requested nodes are encoded as <subscribe/> child elements of the <update-subscription/> 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 <update-subscription/> child element of <iq/> element. The <update-subscription/> element is qualified by the 'urn:xmpp:mix:core:1' namespace. The requested nodes are encoded as <subscribe/> and <unsubscribe/> child elements of the <update-subscription/> 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.
+
@@ -1093,11 +1111,12 @@
+
]]>
- 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.
@@ -1299,6 +1318,7 @@
category='conference'
name='Shakespearean Chat Service'
type='mix'/>
+