<abstract>This specification defines an XMPP protocol extension that enables a client to exercise control over the XML stanzas it will receive from the server by instructing the server to intercept and filter inbound stanzas.</abstract>
<remark><p>Made it clear that presence means presence notifications; added support for subscription-related presence stanzas; described payload matching in greater detail; added use case for allowing only core XMPP child elements; increased protocol version number from 1 to 2.</p></remark>
<remark><p>Specified sending of an empty <sift/> element to disable SIFT processing; removed invisibility use case because that is handled by outbound privacy lists, not inbound SIFT.</p></remark>
<remark><p>Initial published version as accepted for publication by the XMPP Council.</p></remark>
</revision>
<revision>
<version>0.0.8</version>
<date>2009-08-14</date>
<initials>psa</initials>
<remark><p>Clarified service and feature discovery processes, error flows, and other small matters in the text.</p></remark>
</revision>
<revision>
<version>0.0.7</version>
<date>2009-08-11</date>
<initials>psa</initials>
<remark><p>Defined IQ-get for retrieving supported SIFT features; added support for sifting based on sender type; removed restriction on matching against only the bare JID of the recipient and defined support for sifting on the bare JID, full JID, or both.</p></remark>
</revision>
<revision>
<version>0.0.6</version>
<date>2009-05-19</date>
<initials>jjh/psa</initials>
<remark><p>Added requirements section; clarified relation to negative presence priorities.</p></remark>
</revision>
<revision>
<version>0.0.5</version>
<date>2009-05-18</date>
<initials>jjh/psa</initials>
<remark><p>More clearly distinguished between interception and filtering usages; clarified business rules.</p></remark>
</revision>
<revision>
<version>0.0.4</version>
<date>2009-05-18</date>
<initials>psa/jjh</initials>
<remark><p>Added information about service discovery; clarified several small matters in the text.</p></remark>
</revision>
<revision>
<version>0.0.3</version>
<date>2009-05-15</date>
<initials>psa/jjh</initials>
<remark><p>Clarified that SIFT applies to interception of message and presence stanzas directed to the bare JID and to filtering of IQ stanzas directed to the full JID; corrected syntax to match those semantics; added use cases; defined XML schema.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2009-05-14</date>
<initials>psa</initials>
<remark><p>Slight clarifications and corrections.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2009-05-14</date>
<initials>jjh/jm/psa</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>In some scenarios a client might want to control the XML stanzas it will receive over its stream with the server. Some potential use cases include:</p>
<ul>
<li>A mobile client might want to receive messages but not presence notifications, since the latter are quite "chatty" and can run down the battery.</li>
<li>A softphone might want to receive IQ stanzas only if the payload is qualified by an XML namespace related to the use of &xep0166; for Internet telephony.</li>
<li>A presence compositor might want to receive presence updates but not message stanzas or IQ stanzas, and only from the user's own resources (i.e., not from other entities).</li>
<p>Although &xmppim; specifies the use of a negative presence priority to block inbound message delivery, it does not enable the client to block inbound presence notifications, filter inbound IQ stanzas, or otherwise exercise fine-grained control over the delivery of inbound stanzas. While it would be possible to define particular values of negative presence priorities for some delivery control methods (e.g., <priority>-2<priority> could be hardcoded to mean "don't send me messages or presence"), that would be an ugly hack and thus inconsistent with &xep0134;. Therefore, this specification defines a stanza interception and filtering technology (a.k.a. "SIFT") that is more consistent with the underlying design of XMPP.</p>
<p>The following taxonomy of client types is not exhaustive but might assist developers in understanding the scenarios in which SIFT might be useful.</p>
<p>* Note: SIFT is not used to control outbound presence, since that use case is already covered by &xep0016;; this table includes information about outbound presence only to motivate various scenarios in which SIFT can be used.</p>
<p>** Note: For purposes of this taxonomy, we refer only to presence notifications (available and unavailable), not also to subscription-related presence stanzas (subscribe, unsubscribe, etc.).</p>
<li>Make it possible for a client to disable receipt of various inbound stanzas (presence notifications, subscription-related presence stanzas, message stanzas, IQ stanzas) while still receiving other kinds of stanzas.</li>
<p>The SIFT protocol is used to <em>intercept</em> or <em>filter</em> inbound stanzas only, not outbound stanzas sent by the client to the server or other entities. By "intercept" is meant that the server will not deliver any such stanza kind (message, presence notification, presence subscription, or IQ) to the client, and by "filter" is meant that the server will apply a rule to determine if the specific stanza will be delivered to the client (e.g., matching against a payload namespace); in general we refer to these actions as "sifting". The SIFT protocol enables the server to support only basic interception (even here to support interception only for particular kinds of stanzas), basic filtering as defined by the rules described in this specification, or advanced filtering using extensions to SIFT defined in other specifications. Each of the features supported by the server can be discovered by the client for maximum interoperability. The features, the process for discovering them, and the process for enabling them are described in the following sections.</p>
<p>SIFT supports the features defined below. Each feature is identified by a separate value for 'var' attribute qualified by the 'http://jabber.org/protocol/disco#info' namespace as specified in &xep0030;.</p>
<p>A server MAY support any combination of sifting IQ stanzas, message stanzas, presence notifications, and presence subscriptions, as advertised by the following service discovery features.</p>
<dd>The server enables the client to sift all &PRESENCE; notifications (i.e., presence stanzas with no 'type' or with a type of "unavailable") or ones that match the specified criteria.</dd>
<dd>The server enables the client to sift all subscription-related &PRESENCE; stanzas (i.e., presence stanzas with a type of "subscribe", "subscribed", "unsubscribe", or "unsubscribed") or ones that match the specified criteria.</dd>
<dd>The server shall sift this kind of stanza only from entities associated with the same local domain as the user itself (not from remote domains).</dd>
<dd>The server shall sift this kind of stanza only from entities associated with remote domains (not from the same local domain as the user itself).</dd>
<p>These values are child elements of the <iq/>, <message/>, <presence/>, and <sub/> elements when the server returns a features discovery result, whereas they are values of the 'sender' attribute when the client enables sift support.</p>
<dd>The server shall sift this kind of stanza if the recipient is the bare JID &LOCALBARE; of the user or the full JID &LOCALFULL; of the particular resource. This is the <strong>default</strong>.</dd>
<p>These values are child elements of the <iq/>, <message/>, <presence/>, and <sub/> elements when the server returns a features discovery result, whereas they are values of the 'recipient' attribute when the client enables sift support.</p>
<p>A server MAY enable the client to sift based on the XML namespace and element name of the payload(s) that the client allows for delivery. If so, the server shall advertise a feature of <strong>urn:xmpp:sift:payloads:qname</strong>.</p>
<p>By "payload" is meant a first-level child element of an &IQ;, &MESSAGE;, or &PRESENCE; stanza. <strong>This includes elements defined in &rfc6120; and &rfc6121;.</strong> As a result, if the server supports payload matching then a client can even sift out elements allowed by the 'jabber:client' namespace, such as message &SUBJECT; and presence &STATUS;.</p>
<p>A server could match based on more complex criteria, e.g. Regular Expressions or XPath Expressions; such functionality is implicitly allowed because the XML schema specifies the <xs:any/> notation, but any such advanced matching shall be defined in separate specifications.</p>
<p>If a server supports the SIFT protocol, it MUST advertise that fact in its responses to "disco#info" requests by returning a feature of "urn:xmpp:sift:2" &VNOTE;. The server MUST also specify which features it supports.</p>
<p>To enable clients to cache information about supported features, a server SHOULD return &xep0115; data via stream features as described in <cite>XEP-0115</cite>.</p>
<p>To enable sifting of stanzas, the client sends an IQ-set to the server containing a <sift/> child element that in turn contains an <iq/> element, a <message/> element, a <presence/> element, or some combination of those elements. Each of these elements MAY include a 'recipient' attribute whose value is "all", "bare", or "full" (defaulting to "all"). Each of these elements MAY also include a 'sender' attribute whose value is "all", "local", "others", "remote", or "self" (defaulting to "all").</p>
<p>Note: The last SIFT request sent from the client to the server overrides all previous SIFT requests; SIFT requests are not cumulative. Therefore, each SIFT request needs to contain all the SIFT rules that the client wishes the server to enforce, not a delta from the previous request.</p>
<examplecaption="Sifting of message and presence stanzas"><