xep-0390: gratuitous caps for pre-presence publishing of caps to the server

xep-0390.xml

@@ -21,6 +21,7 @@
   <!ENTITY genent "<em>Generating Entity</em>">
   <!ENTITY genents "<em>Generating Entities</em>">
   <!ENTITY queryintercept "<em>Query Interception</em>">
+  <!ENTITY gratcaps "<em>Gratuitous Capabilities</em>">
   <!ENTITY mlwaqas1 "<note>org.jabber.security Mailing List Archive: '[Security] Trivial preimage attack against the entity capabilities protocol)' from 2009-07-22, &lt;<link url='https://mail.jabber.org/pipermail/security/2009-July/000812.html'>https://mail.jabber.org/pipermail/security/2009-July/000812.html</link>&gt;.</note>">
   <!ENTITY capsdb "<span class='ref'><link url='https://github.com/xnyhps/capsdb/'>capsdb</link></span> <note><link url='https://github.com/xnyhps/capsdb/'>https://github.com/xnyhps/capsdb/</link></note>">
 ]>
@@ -60,6 +61,7 @@
       <ul>
         <li>Clearly specify handling of xml:lang attributes.</li>
         <li>Add Query Interception.</li>
+        <li>Add Gratuitous Caps.</li>
       </ul>
     </remark>
   </revision>
@@ -102,6 +104,7 @@
     <li>The protocol must be able to coexist (but not necessarily exchange information) with &xep0115;.</li>
     <li>No special XML features beyond what is needed to implement <cite>XMPP Core</cite> itself should be required.</li>
     <li>Obsoletion of hash functions should not need a new version of the specification.</li>
+    <li>Support for pushing Entity Capabilities to the clients server without sending presence.</li>
   </ol>
 </section1>
 
@@ -114,6 +117,7 @@
     <di><dt>Generating Entity</dt><dd>An entity which emits a &hashset; to other entities.</dd></di>
     <di><dt>Processing Entity</dt><dd>An entity which receives and processes a &hashset; from a &genent;.</dd></di>
     <di><dt>Query Interception</dt><dd>Server-side processing of disco#info queries directed to a resource based on the &hashsets; published by that resource.</dd></di>
+    <di><dt>Gratuitous Capabilities</dt><dd>The sending of a &hashset; to a server before initial presence has been sent and without being asked by the server.</dd></di>
   </dl>
 </section1>
 
@@ -731,6 +735,44 @@ cDp0aW1lHxw=</code>
 </iq>
 ]]></example>
   </section2>
+  <section2 topic='Gratuitous Capabilities' anchor='usecases-gratuitous'>
+    <p>A server MAY support pushing of &hashes; from clients before sending initial presence. This allows servers to discover capabilities of clients before those have sent initial presence, which may be useful or important for some protocols (such as &xep0369;). This feature is called &gratcaps;.</p>
+    <p>To advertise support, the server publishes the <tt>urn:xmpp:caps:gratuitous</tt> feature:</p>
+    <example caption='Response to a disco#info request if the server supports Gratuitous Capabilities'><![CDATA[
+<iq from='montague.lit'
+    id='disco3'
+    to='romeo@montague.lit/chamber'
+    type='result'>
+  <query xmlns='http://jabber.org/protocol/disco#info'>
+    ...
+    <feature var='urn:xmpp:caps'/>
+    <feature var='urn:xmpp:caps:gratuitous'/>
+    ...
+  </query>
+</iq>
+]]></example>
+    <p>After determining server support, a client can send &hashes; via &gratcaps; before sending initial presence:</p>
+    <example caption='Sending Gratuitous Capabilities'><![CDATA[
+<iq from='romeo@montague.lit/chamber'
+    to='montague.lit'
+    id='grat1'
+    type='set'>
+  <c xmlns="urn:xmpp:caps">
+    <hash xmlns="urn:xmpp:hashes:2" algo="sha-256">u79ZroNJbdSWhdSp311mddz44oHHPsEBntQ5b1jqBSY=</hash>
+    <hash xmlns="urn:xmpp:hashes:2" algo="sha3-256">XpUJzLAc93258sMECZ3FJpebkzuyNXDzRNwQog8eycg=</hash>
+  </c>
+</iq>
+
+<iq from='montague.lit'
+    to='romeo@montague.lit/chamber'
+    id='grat1'
+    type='result'>
+</iq>
+]]></example>
+    <p>The server replies with an empty result on success.</p>
+    <p>The server MUST NOT broadcast the &hashes; submitted via &gratcaps; using presence.</p>
+    <p>Clients SHOULD NOT send &gratcaps; after they have sent initial presence; instead, they SHOULD re-send presence to update the &hashes;. Otherwise, entities subscribed to the presence will not receive the updated &hashes;.</p>
+  </section2>
 </section1>
 
 <section1 topic='Business Rules' anchor='rules'>
@@ -738,7 +780,8 @@ cDp0aW1lHxw=</code>
     <ul>
       <li>Entities MUST respond to disco#info queries for all &hashnodes; of at least the most recent 3 &hashsets; emitted.</li>
       <li>Entities MUST broadcast the &hashset; of the current disco#info it publishes in every non-directed "available" &lt;presence/&gt; they send and SHOULD do so for directed "available" &lt;presence/&gt;.</li>
-      <li>Entities MUST re-broadcast the &hashset; after their disco#info response changes, but MAY limit the rate at which presences are emitted solely for the purpose of sending new &hashsets;.</li>
+      <li>After initial presence has been sent, entities MUST re-broadcast the &hashset; after their disco#info response changes, but MAY limit the rate at which presences are emitted solely for the purpose of sending new &hashsets;.</li>
+      <li>Before initial presence has been sent and if the server supports &gratcaps;, entities SHOULD send &gratcaps; after their disco#info response changes, but MAY limit the rate at which &gratcaps; are sent. (For example, a client may load and enable additional functionality (thus changing its features) based on server support and only send &gratcaps; once all functionality has been set up, not after each individual feature.)</li>
       <li>Entities MAY assume that another entity supports &caps; after receiving a &hashset; from that entity.</li>
       <li>Entities MAY also send &xep0115; capabilities to support legacy entities.</li>
     </ul>