Merge branch 'premerge' into 'main'

Premerge

See merge request xsf/xeps!27

xep-0292.xml

@@ -10,7 +10,7 @@
   <abstract>This document specifies an XMPP extension for use of the vCard4 XML format in XMPP systems, with the intent of obsoleting the vcard-temp format.</abstract>
   &LEGALNOTICE;
   <number>0292</number>
-  <status>Proposed</status>
+  <status>Deferred</status>
   <lastcall>2019-02-19</lastcall>
   <type>Standards Track</type>
   <sig>Standards</sig>

xep-0308.xml

@@ -21,6 +21,12 @@
   <supersededby/>
   <shortname>message-correct</shortname>
   &ksmith;
+  <revision>
+    <version>1.2.0</version>
+    <date>2020-10-20</date>
+    <initials>gl</initials>
+    <remark><p>Reword note about how to handle LMC in cases where it is not clear that all recipients support it.</p></remark>
+  </revision>
   <revision>
     <version>1.1.0</version>
     <date>2019-05-15</date>
@@ -80,7 +86,7 @@
 ...
   </query>
 </iq>]]></example>
-  <p>It is expected that clients will not send message corrections to clients that do not support them, as non-supporting clients will render these as duplicate (corrected) messages. There may be environments (particularly within a &xep0045; MUC room) where it is unknown whether some or all recipients support this extension, and implementors could choose to allow or disallow sending in such cases, as is appropriate for the intended deployments. It is suggested that when the support of recipients is not known a sending client will make the user aware of the potential for duplicate messages to be interpreted by the recipients.</p>
+  <p>Message corrections sent to clients that do not support them will be rendered as duplicate (corrected) messages. In most Instant Messaging environments (particularly within a &xep0045; room, but also with a recipient having multiple clients using &xep0280; and &xep0313;) it is unknown whether some or all receiving devices support this extension. It is suggested that a client should always allow sending corrections, but may make the user aware of the potential for duplicate messages to be interpreted by the recipients. In restricted environments, implementors could choose to allow or disallow sending in such cases, as is appropriate for the intended deployments.</p>
 </section1>
 <section1 topic='Use Case' anchor='usecase'>
   <p>When a user indicates to the client that he wants to correct the most recently sent message to a contact, the client will resend the corrected message with a new id, and with the replace payload refering to the previous message by id. The receiving client then treats the newly received payloads as completely replacing all payloads of the original message.</p>

xep-0352.xml

@@ -10,7 +10,7 @@
   <abstract>This document defines a way for the client to indicate its active/inactive state.</abstract>
   &LEGALNOTICE;
   <number>0352</number>
-  <status>Proposed</status>
+  <status>Draft</status>
   <lastcall>2020-08-18</lastcall>
   <lastcall>2017-12-21</lastcall>
   <lastcall>2017-11-15</lastcall>
@@ -28,6 +28,12 @@
   <supersededby/>
   <shortname>csi</shortname>
   &mwild;
+  <revision>
+    <version>1.0.0</version>
+    <date>2020-10-14</date>
+    <initials>XEP Editor (jsc)</initials>
+    <remark>Accepted as Draft as per Council vote from 2020-08-26.</remark>
+  </revision>
   <revision>
     <version>0.3.0</version>
     <date>2018-11-08</date>

xep-0353.xml

@@ -10,7 +10,7 @@
   <abstract>This specification provides a way for the initiator of a Jingle session to propose sending an invitation in an XMPP message stanza, thus taking advantage of message delivery semantics instead of sending IQ stanzas to all of the responder's online resources or choosing a particular online resource.</abstract>
   &LEGALNOTICE;
   <number>0353</number>
-  <status>Proposed</status>
+  <status>Deferred</status>
   <lastcall>2019-08-13</lastcall>
   <type>Standards Track</type>
   <sig>Standards</sig>

xep-0411.xml

@@ -10,7 +10,7 @@
   <abstract>This specification describes a method to migrate to PEP based bookmarks without loosing compatibility with client that still use Private XML.</abstract>
   &LEGALNOTICE;
   <number>0411</number>
-  <status>Proposed</status>
+  <status>Draft</status>
   <lastcall>2020-10-14</lastcall>
   <type>Standards Track</type>
   <sig>Standards</sig>
@@ -29,6 +29,12 @@
     <email>daniel@gultsch.de</email>
     <jid>daniel@gultsch.de</jid>
   </author>
+  <revision>
+    <version>1.0.0</version>
+    <date>2020-10-20</date>
+    <initials>XEP Editor (jsc)</initials>
+    <remark>Accepted as Draft by vote of Council on 2020-10-14.</remark>
+  </revision>
   <revision>
     <version>0.2.1</version>
     <date>2020-05-25</date>

xep-0443.xml

@@ -22,7 +22,8 @@
     </abstract>
     &LEGALNOTICE;
     <number>0443</number>
-    <status>Experimental</status>
+    <status>Proposed</status>
+    <lastcall>2020-11-03</lastcall>
     <type>Standards Track</type>
     <sig>Standards</sig>
     <dependencies>
@@ -62,6 +63,12 @@
       <email>georg@op-co.de</email>
       <jid>georg@yax.im</jid>
     </author>
+  <revision>
+    <version>0.2.0</version>
+    <date>2020-10-20</date>
+    <initials>dg</initials>
+    <remark>Added section about A/V calls</remark>
+  </revision>
   <revision>
     <version>0.1.0</version>
     <date>2020-10-06</date>
@@ -114,7 +121,7 @@
     <section2 topic='Changes since 2020' anchor='changes-2020'>
       <p>The following changes were made to the Compliance Suites since &xep0423;:</p>
       <ul>
-	<li>TODO</li>
+        <li>Introduced new category for <strong>A/V Calling</strong>.</li>
       </ul>
     </section2>
     <section2 topic='Changes since 2019' anchor='changes'>
@@ -457,6 +464,62 @@
 	<li>&xep0286;</li>
       </ul>
     </section2>
+    <section2 topic='A/V Calling Compliance Suite' anchor='av'>
+      <p>
+        To be considered XMPP A/V calling compliant, all features from the core
+        compliance category must be met, as well as all features in this suite.
+      </p>
+      <table caption='A/V Calling Compliance Levels'>
+        <tr>
+          <th>Feature</th>
+          <th>Core Server</th>
+          <th>Core Client</th>
+          <th>Advanced Server</th>
+          <th>Advanced Client</th>
+          <th>Providers</th>
+        </tr>
+        <tr>
+          <td><strong>Call Setup</strong></td>
+          <td align='center'>N/A</td>
+          <td align='center'>&yes;</td>
+          <td align='center'>N/A</td>
+          <td align='center'>&yes;</td>
+          <td>&xep0167;, &xep0353;</td>
+        </tr>
+        <tr>
+          <td><strong>Transport</strong></td>
+          <td align='center'>N/A</td>
+          <td align='center'>&yes;</td>
+          <td align='center'>N/A</td>
+          <td align='center'>&yes;</td>
+          <td>&xep0176;</td>
+        </tr>
+        <tr>
+          <td><strong>Encryption</strong></td>
+          <td align='center'>N/A</td>
+          <td align='center'>&yes;</td>
+          <td align='center'>N/A</td>
+          <td align='center'>&yes;</td>
+          <td>&xep0320;</td>
+        </tr>
+        <tr>
+          <td><strong>STUN/TURN server discovery</strong></td>
+          <td align='center'>&yes;</td>
+          <td align='center'>&yes;</td>
+          <td align='center'>&yes;</td>
+          <td align='center'>&yes;</td>
+          <td>&xep0215;</td>
+        </tr>
+        <tr>
+          <td><strong>Quality and Performance improvements</strong></td>
+          <td align='center'>N/A</td>
+          <td align='center'>&no;</td>
+          <td align='center'>N/A</td>
+          <td align='center'>&yes;</td>
+          <td>&xep0293;, &xep0294;, &xep0338;, &xep0339;</td>
+        </tr>
+      </table>
+    </section2>
   </section1>
   <section1 topic='Future Development' anchor='future'>
     <p>This section outlines the protocol specifications that are relevant for