diff --git a/xep-0390.xml b/xep-0390.xml
index ffee4acd..c93d1f2c 100644
--- a/xep-0390.xml
+++ b/xep-0390.xml
@@ -21,6 +21,7 @@
Generating Entity">
Generating Entities">
Query Interception">
+ Gratuitous Capabilities">
org.jabber.security Mailing List Archive: '[Security] Trivial preimage attack against the entity capabilities protocol)' from 2009-07-22, <https://mail.jabber.org/pipermail/security/2009-July/000812.html>.">
capsdb https://github.com/xnyhps/capsdb/">
]>
@@ -60,6 +61,7 @@
Clearly specify handling of xml:lang attributes.
Add Query Interception.
+
Add Gratuitous Caps.
@@ -102,6 +104,7 @@
The protocol must be able to coexist (but not necessarily exchange information) with &xep0115;.
No special XML features beyond what is needed to implement XMPP Core itself should be required.
Obsoletion of hash functions should not need a new version of the specification.
+
Support for pushing Entity Capabilities to the clients server without sending presence.
@@ -114,6 +117,7 @@
Generating Entity
An entity which emits a &hashset; to other entities.
Processing Entity
An entity which receives and processes a &hashset; from a &genent;.
Query Interception
Server-side processing of disco#info queries directed to a resource based on the &hashsets; published by that resource.
+
Gratuitous Capabilities
The sending of a &hashset; to a server before initial presence has been sent and without being asked by the server.
@@ -731,6 +735,44 @@ cDp0aW1lHxw=
]]>
+
+
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;.
+
To advertise support, the server publishes the urn:xmpp:caps:gratuitous feature:
+
+
+ ...
+
+
+ ...
+
+
+]]>
+
After determining server support, a client can send &hashes; via &gratcaps; before sending initial presence:
The server replies with an empty result on success.
+
The server MUST NOT broadcast the &hashes; submitted via &gratcaps; using presence.
+
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;.
+
@@ -738,7 +780,8 @@ cDp0aW1lHxw=
Entities MUST respond to disco#info queries for all &hashnodes; of at least the most recent 3 &hashsets; emitted.
Entities MUST broadcast the &hashset; of the current disco#info it publishes in every non-directed "available" <presence/> they send and SHOULD do so for directed "available" <presence/>.
-
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;.
+
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;.
+
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.)
Entities MAY assume that another entity supports ∩︀ after receiving a &hashset; from that entity.
Entities MAY also send &xep0115; capabilities to support legacy entities.