Merge branch 'feature/mix' into premerge

xep-0369.xml

@@ -35,6 +35,12 @@
   <shortname>MIX-CORE</shortname>
   &ksmithisode;
   &skille;
+  <revision>
+    <version>0.14.5</version>
+    <date>2020-11-03</date>
+    <initials>gh/@melvo</initials>
+    <remark><p>Fix various typos</p></remark>
+  </revision>
   <revision>
     <version>0.14.4</version>
     <date>2020-03-26</date>
@@ -1007,7 +1013,7 @@
   <section2 topic='Common User Use Cases' anchor='usecases-user'>
     <section3 topic="Model for Join and Leave" anchor="usecase-jl-model">
       <p>
-        MIX Join and Leave communication goes through the clients server.   The full specification of client interaction with the client's server is specified in MIX-PAM.    This specification shows the protocol between the user's server and the MIX server and sets out behaviour of the MIX server.
+        MIX Join and Leave communication goes through the client's server.   The full specification of client interaction with the client's server is specified in MIX-PAM.    This specification shows the protocol between the user's server and the MIX server and sets out behaviour of the MIX server.
       </p>
     </section3>
     <section3 topic='Joining a Channel' anchor='usecase-user-join'>
@@ -1116,11 +1122,11 @@
 </iq>
 ]]></example>
       <p>
-        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.
+        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 a 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'>
-      <p>Users generally remain in a channel for an extended period of time.  In particular the user remains as a participant the channel when the user goes offline.  Note that this is different to  &xep0045;, where the client leaves a room when going offline. So, leaving a MIX channel is a permanent action for a user across all clients.  In order to  leave a channel, the user's server sends a MIX "leave" command to the channel, as specified in MIX-PAM.  The leave command is encoded as a &lt;leave/&gt; child element of &lt;iq/&gt; element.  The &lt;leave/&gt; element is qualified by the 'urn:xmpp:mix:core:1' namespace.  The following example shows a leave request to a MIX channel.  </p>
+      <p>Users generally remain in a channel for an extended period of time.  In particular the user remains as a participant of the channel when the user goes offline.  Note that this is different to  &xep0045;, where the client leaves a room when going offline. So, leaving a MIX channel is a permanent action for a user across all clients.  In order to  leave a channel, the user's server sends a MIX "leave" command to the channel, as specified in MIX-PAM.  The leave command is encoded as a &lt;leave/&gt; child element of &lt;iq/&gt; element.  The &lt;leave/&gt; element is qualified by the 'urn:xmpp:mix:core:1' namespace.  The following example shows a leave request to a MIX channel.  </p>
       <example caption="User's Server sends  Leave Request to  a Channel"><![CDATA[
 <iq type='set'
     from='hag66@shakespeare.example'

xep-0405.xml

@@ -38,6 +38,12 @@
   <shortname>MIX-PAM</shortname>
   &ksmithisode;
   &skille;
+  <revision>
+    <version>0.5.1</version>
+    <date>2020-11-03</date>
+    <initials>gh/@melvo</initials>
+    <remark><p>Fix various typos</p></remark>
+  </revision>
   <revision>
     <version>0.5.0</version>
     <date>2019-09-30</date>
@@ -506,7 +512,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
   </section2>
 
   <section2 topic="MIX Roster Item Capability Sharing" anchor="mix-roster-capability-sharing">
-    <p>It is useful for a MIX client to know which roster members are MIX channels, as this will facilitate convenient presentation of subscribed MIX channels to the user.  A MIX client MAY request that the server return this additional information that annotates roster elements with MIX capability. The server MUST return the additional information. The request is made by extending the standard roster get request by adding a child element &lt;annotate/&gt; to the &lt;query/&gt; element.  The &lt;annotate/&gt; element is qualified by the ‘urn:xmpp:mix:roster:0' namespace.</p>
+    <p>It is useful for a MIX client to know which roster members are MIX channels, as this will facilitate convenient presentation of subscribed MIX channels to the user.  A MIX client MAY request that the server returns this additional information that annotates roster elements with MIX capability. The server MUST return the additional information. The request is made by extending the standard roster get request by adding a child element &lt;annotate/&gt; to the &lt;query/&gt; element.  The &lt;annotate/&gt; element is qualified by the ‘urn:xmpp:mix:roster:0' namespace.</p>
     <example caption="Roster Get Requesting MIX Information"><![CDATA[
 <iq from='juliet@example.com/balcony'
     id='bv1bs71f'

xep-0407.xml

@@ -36,6 +36,12 @@
   <shortname>MIX-MISC</shortname>
   &ksmithisode;
   &skille;
+  <revision>
+    <version>0.1.2</version>
+    <date>2020-11-03</date>
+    <initials>gh/@melvo</initials>
+    <remark><p>Fix various typos</p></remark>
+  </revision>
   <revision>
     <version>0.1.1</version>
     <date>2018-11-03</date>
@@ -230,7 +236,7 @@
         <li>The invitee MAY send a response to the inviter, indicating if the invitation was accepted or declined.</li>
       </ol>
       <p>
-        The first step is for the inviter to request an invitation from the channel.   The invitation contains inviter, invitee and a token.  The channel will evaluate if the inviter has rights to issue the invitation.   This will be because the inviter is a channel administrator or if the inviter is a channel participant and the channel allows invitation by participants.  If the inviter has rights to make the invitation, the channel will return a token.  The token is a string that the channel can subsequently use to validate an invitation.   The format of the token is not specified in this standard.   The encoded token MAY reflect a validity time.  The invitation request is encoded as an &lt;invite/&gt; child element of an &lt;iq/&gt; element. The &lt;invite/&gt; element is qualified by the 'urn:xmpp:mix:misc:0' namespace.  &lt;invite/&gt; contains an &lt;invitation/&gt; child element, which contain &lt;inviter/&gt;, &lt;invitee/&gt;, &lt;channel/&gt; and &lt;token/&gt; child elements.
+        The first step is for the inviter to request an invitation from the channel.   The invitation contains inviter, invitee and a token.  The channel will evaluate if the inviter has rights to issue the invitation.   This will be because the inviter is a channel administrator or if the inviter is a channel participant and the channel allows invitation by participants.  If the inviter has rights to make the invitation, the channel will return a token.  The token is a string that the channel can subsequently use to validate an invitation.   The format of the token is not specified in this standard.   The encoded token MAY reflect a validity time.  The invitation request is encoded as an &lt;invite/&gt; child element of an &lt;iq/&gt; element. The &lt;invite/&gt; element is qualified by the 'urn:xmpp:mix:misc:0' namespace.  &lt;invite/&gt; contains an &lt;invitation/&gt; child element, which contains &lt;inviter/&gt;, &lt;invitee/&gt;, &lt;channel/&gt; and &lt;token/&gt; child elements.
       </p>
       <example caption='Inviter Requests and Receives Invitation'><![CDATA[
 <iq from='hag66@shakespeare.example/UUID-h5z/0253'
@@ -264,14 +270,14 @@
 <message from='hag66@shakespeare.example/UUID-h5z/0253'
     id='f5pp2toz'
     to='cat@shakespeare.example'>
-    <body>Would you like to join the coven?<body>
+    <body>Would you like to join the coven?</body>
     <invitation xmlns='urn:xmpp:mix:misc:0'>
         <inviter>hag66@shakespeare.example</inviter>
         <invitee>cat@shakespeare.example</invitee>
         <channel>coven@mix.shakespeare.example</channel>
         <token>ABCDEF</token>
    </invitation>
-</iq>
+</message>
 ]]></example>
   <p>The invitation can now be used by the invitee to join a channel. The &lt;invitation/&gt; child element is simply added to the standard channel &lt;join/&gt; element, so that the channel can validate the invitation using the token. If the allowed node is present and the invitee is not matched against any item, the channel MUST add the invitee to the allowed node as part of the join.</p>
       <example caption="User Joins a Channel with an Invitation"><![CDATA[