Merge branches 'feature/xep-0184', 'feature/xep-0380', 'feature/xep-0371', 'feature/xep-0410' and 'feature/xep-0128'

xep-0128.xml

@@ -23,6 +23,12 @@
   <supersededby/>
   <shortname>N/A</shortname>
   &stpeter;
+  <revision>
+    <version>1.0.1</version>
+    <date>2019-07-30</date>
+    <initials>gdk</initials>
+    <remark>Remove now-incorrect informational statement about the likelihood of multiple forms in a single disco#info reply.</remark>
+  </revision>
   <revision>
     <version>1.0</version>
     <date>2004-10-20</date>
@@ -156,7 +162,7 @@
   </section2>
 </section1>
 <section1 topic='Implementation Notes' anchor='impl'>
-  <p>In general, the XMPP Standards Foundation may choose to define at most one FORM_TYPE for each service discovery identity (category+type) registered with the XMPP Registrar. In addition, particular applications may define application-specific FORM_TYPEs as well, and one entity may have multiple service discovery identities (e.g., an XMPP server might also function as a publish-subscribe service). Therefore, it is possible (and allowed) for a single service discovery result to contain multiple service discovery extension elements (potentially up to two elements for each identity). However, in practice it is unlikely that any given service discovery result will contain more than one service discovery extension element.</p>
+  <p>In general, the XMPP Standards Foundation may choose to define at most one FORM_TYPE for each service discovery identity (category+type) registered with the XMPP Registrar. In addition, particular applications may define application-specific FORM_TYPEs as well, and one entity may have multiple service discovery identities (e.g., an XMPP server might also function as a publish-subscribe service). Therefore, it is possible (and allowed) for a single service discovery result to contain multiple service discovery extension elements (potentially up to two elements for each identity).</p>
 </section1>
 <section1 topic='Security Considerations' anchor='security'>
   <p>Applications SHOULD ensure that information disclosed in a disco extension is appropriate for discovery by any entity on the network.</p>

xep-0184.xml

@@ -27,6 +27,12 @@
   </schemaloc>
   &stpeter;
   &hildjj;
+  <revision>
+    <version>1.4.0</version>
+    <date>2018-08-02</date>
+    <initials>egp</initials>
+    <remark><p>Make the 'id' attribute required, this extension makes no sense otherwise.</p></remark>
+  </revision>
   <revision>
     <version>1.3.0</version>
     <date>2019-05-15</date>
@@ -209,7 +215,7 @@
   <received xmlns='urn:xmpp:receipts' id='richard2-4.1.247'/>
 </message>
 ]]></example>
-  <p>When the recipient sends an ack message, it SHOULD ensure that the message stanza contains only one child element, namely the &lt;received/&gt; element qualified by the 'urn:xmpp:receipts' namespace. In addition, it SHOULD include an 'id' attribute that echoes the 'id' attribute of the content message. Naturally, intermediate entities might add other extension elements to the message when routing or delivering the receipt message, e.g., a &lt;delay/&gt; element as specified in &xep0203;.</p>
+  <p>When the recipient sends an ack message, it SHOULD ensure that the message stanza contains only one child element, namely the &lt;received/&gt; element qualified by the 'urn:xmpp:receipts' namespace, which MUST include an 'id' attribute that echoes the 'id' attribute of the content message. Naturally, intermediate entities might add other extension elements to the message when routing or delivering the receipt message, e.g., a &lt;delay/&gt; element as specified in &xep0203;.</p>
   <p class='box'>Note: It is a good practice to use the same message type as the message that requested the receipt, however a client SHOULD also accept receipts with a different message type. When sending a Receipt for a type='groupchat' message (which is NOT RECOMMENDED), the Receipt must be sent to the bare JID of the room and not to the full JID of the sender.</p>
 </section1>
 
@@ -248,7 +254,7 @@
     <xs:complexType>
       <xs:simpleContent>
         <xs:extension base='empty'>
-          <xs:attribute name='id' type='xs:string' use='optional'/>
+          <xs:attribute name='id' type='xs:string' use='required'/>
         </xs:extension>
       </xs:simpleContent>
     </xs:complexType>

xep-0371.xml

@@ -27,6 +27,12 @@
   <supersededby/>
   <shortname>jingle-ice</shortname>
   &stpeter;
+  <revision>
+    <version>0.2.1</version>
+    <date>2019-07-30</date>
+    <initials>fippo</initials>
+    <remark>Fix reference to gathering-complete element in text.</remark>
+  </revision>
   <revision>
     <version>0.2</version>
     <date>2017-09-11</date>
@@ -715,7 +721,7 @@ Romeo                    Gateway                    Juliet
 
 <section1 topic='Informational Messages' anchor='info'>
   <p>Informational messages can be sent by either party within the context of Jingle to communicate the status of a Jingle ICE "session".  The informational message MUST be an IQ-set containing a &JINGLE; element of type "transport-info", where the informational message is a payload element qualified by the 'urn:xmpp:jingle:transports:ice:info:0' namespace.</p>
-  <p>The only payload element defined so far is the &lt;ice-gathering-complete/&gt; element. This element is used only to signal that gathering of ICE candidates has been completed (i.e., to send an "end-of-candidates indication"), as in the following example.</p>
+  <p>The only payload element defined so far is the &lt;gathering-complete/&gt; element. This element is used only to signal that gathering of ICE candidates has been completed (i.e., to send an "end-of-candidates indication"), as in the following example.</p>
   <example caption="Responder sends end-of-candidates indication"><![CDATA[
 <iq from='juliet@capulet.example/yn0cl4bnw0yr3vym'
     id='xv39z423'

xep-0380.xml

@@ -11,7 +11,7 @@
     recipient can discover how to decrypt it.</abstract>
   &LEGALNOTICE;
   <number>0380</number>
-  <status>Deferred</status>
+  <status>Experimental</status>
   <type>Standards Track</type>
   <sig>Standards</sig>
   <approver>Council</approver>
@@ -24,6 +24,15 @@
   <supersededby/>
   <shortname>EME</shortname>
   &linkmauve;
+  <revision>
+    <version>0.3.0</version>
+    <date>2019-04-28</date>
+    <initials>lnj</initials>
+    <remark>
+      <p>Added OMEMO encryption namespace.</p>
+      <p>Made XEP experimental again.</p>
+    </remark>
+  </revision>
   <revision>
     <version>0.2.0</version>
     <date>2018-01-25</date>
@@ -168,11 +177,11 @@
       <td>urn:xmpp:openpgp:0</td>
       <td>&xep0373;</td>
     </tr>
-    <!--<tr>
+    <tr>
       <td>OMEMO</td>
-      <td>urn:xmpp:omemo:0</td>
-      <td>https://conversations.im/xeps/multi-end.html</td>
-    </tr>-->
+      <td>eu.siacs.conversations.axolotl</td>
+      <td>&xep0384;</td>
+    </tr>
   </table>
 </section2>
 

xep-0410.xml

@@ -29,6 +29,12 @@
     <email>georg@op-co.de</email>
     <jid>georg@yax.im</jid>
   </author>
+  <revision>
+    <version>1.0.1</version>
+    <date>2019-07-30</date>
+    <initials>fs</initials>
+    <remark>Make feature string reference more clear</remark>
+  </revision>
   <revision>
     <version>1.0.0</version>
     <date>2019-06-27</date>
@@ -199,7 +205,7 @@
       to a occupant's Ping request to the occupant's own nickname, as
       opposed to routing it to any of the occupant's clients. A service
       implementing this optimization needs to advertise the
-      <tt>self-ping-optimization</tt> feature in the &xep0030; response on
+      <tt>http://jabber.org/protocol/muc#self-ping-optimization</tt> feature in the &xep0030; disco#info response on
       the individual MUC room JIDs, and it MUST respond to a self-ping request
       as follows:</p>
     <ul>