moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-24 18:22:24 -05:00
Code Issues Releases Wiki Activity

0.4

Browse Source
This commit is contained in:
stpeter 2011-06-27 15:17:49 -06:00
parent 08bb6556cc
commit 9aaf67f874
1 changed files with 80 additions and 34 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

114
xep-0273.xml
View File

@ -6,7 +6,7 @@
<?xml-stylesheet type='text/xsl' href='xep.xsl'?> <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep> <xep>
<header> <header>
<title>Stanza Interception and Filtering Technology</title> <title>Stanza Interception and Filtering Technology (SIFT)</title>
<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> <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>
&LEGALNOTICE; &LEGALNOTICE;
<number>0273</number> <number>0273</number>
@ -23,6 +23,12 @@
&hildjj; &hildjj;
&metajack; &metajack;
&stpeter; &stpeter;
<revision>
<version>0.4</version>
<date>2011-06-27</date>
<initials>psa</initials>
<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>
</revision>
<revision> <revision>
<version>0.3</version> <version>0.3</version>
<date>2010-05-03</date> <date>2010-05-03</date>
@ -100,11 +106,11 @@
</ul> </ul>
<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., &lt;priority&gt;-2&lt;priority&gt; 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>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., &lt;priority&gt;-2&lt;priority&gt; 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>The following taxonomy of client types is not exhaustive but might assist developers in understanding the scenarios in which SIFT might be useful.</p>
<table caption='Client Types Categorized by Sending Presence, Receiving Presence, and Receiving Messages'> <table caption='Client Types Categorized by Sending Presence Notifications, Receiving Presence Notifications, and Receiving Messages'>
<tr> <tr>
<th>Type</th> <th>Type</th>
<th>Sends Presence *</th> <th>Sends Presence *</th>
<th>Receives Presence</th> <th>Receives Presence **</th>
<th>Receives Messages</th> <th>Receives Messages</th>
</tr> </tr>
<tr> <tr>
@ -157,15 +163,13 @@
</tr> </tr>
</table> </table>
<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: 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>
</section1> </section1>
<section1 topic='Requirements' anchor='reqs'> <section1 topic='Requirements' anchor='reqs'>
<p>The SIFT protocol is designed to meet the following requirements.</p> <p>The SIFT protocol is designed to meet the following requirements.</p>
<ol start='1'> <ol start='1'>
<li>Make it possible for a client to disable receipt of all inbound presence notifications while still receiving message and IQ stanzas if desired.</li> <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>
<li>Make it possible for a client to disable receipt of all inbound message stanzas while still receiving presence and IQ stanzas if desired.</li>
<li>Make it possible for a client to disable receipt of all inbound IQ stanzas while still receiving presence and message stanzas if desired.</li>
<li>Make it possible for a client to receive only inbound presence, message, or IQ stanzas that contain a payload matching a particular element name and XML namespace.</li>
<li>Make it possible for a client to "sift" based on all senders, local vs. remote senders, or other senders vs. oneself.</li> <li>Make it possible for a client to "sift" based on all senders, local vs. remote senders, or other senders vs. oneself.</li>
<li>Make it possible for a client to "sift" based on whether the recipient is the user's bare JID or the particular client's full JID.</li> <li>Make it possible for a client to "sift" based on whether the recipient is the user's bare JID or the particular client's full JID.</li>
<li>Enable future extensibility based on regular expressions, XPath expressions, etc.</li> <li>Enable future extensibility based on regular expressions, XPath expressions, etc.</li>
@ -173,11 +177,11 @@
</section1> </section1>
<section1 topic='Protocol' anchor='protocol'> <section1 topic='Protocol' anchor='protocol'>
<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, 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>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>
<section2 topic='Features' anchor='features'> <section2 topic='Features' anchor='features'>
<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>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>
<section3 topic='Stanza Kinds' anchor='features-stanzas'> <section3 topic='Stanza Kinds' anchor='features-stanzas'>
<p>A server MAY support any combination of sifting IQ, message, or presence stanzas, as advertised by the following service discovery features.</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>
<dl> <dl>
<di> <di>
<dt>urn:xmpp:sift:stanzas:iq</dt> <dt>urn:xmpp:sift:stanzas:iq</dt>
@ -185,7 +189,9 @@
<dt>urn:xmpp:sift:stanzas:message</dt> <dt>urn:xmpp:sift:stanzas:message</dt>
<dd>The server enables the client to sift all &MESSAGE; stanzas or ones that match the specified criteria.</dd> <dd>The server enables the client to sift all &MESSAGE; stanzas or ones that match the specified criteria.</dd>
<dt>urn:xmpp:sift:stanzas:presence</dt> <dt>urn:xmpp:sift:stanzas:presence</dt>
<dd>The server enables the client to sift all &PRESENCE; stanzas or ones that match the specified criteria.</dd> <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>
<dt>urn:xmpp:sift:stanzas:sub</dt>
<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>
</di> </di>
</dl> </dl>
</section3> </section3>
@ -205,7 +211,7 @@
<dd>The server shall sift this kind of stanza only from the user itself (not from other entities).</dd> <dd>The server shall sift this kind of stanza only from the user itself (not from other entities).</dd>
</di> </di>
</dl> </dl>
<p>These values are child elements of the &lt;iq-sift/&gt;, &lt;message-sift/&gt;, and &lt;presence-sift/&gt; elements when the server returns a features discovery result, whereas they are values of the 'sender' attribute when the client enables sift support.</p> <p>These values are child elements of the &lt;iq/&gt;, &lt;message/&gt;, &lt;presence/&gt;, and &lt;sub/&gt; elements when the server returns a features discovery result, whereas they are values of the 'sender' attribute when the client enables sift support.</p>
</section3> </section3>
<section3 topic='Recipient' anchor='features-recipient'> <section3 topic='Recipient' anchor='features-recipient'>
<p>A server MAY enable the client to filter based on recipient. The following features are supported.</p> <p>A server MAY enable the client to filter based on recipient. The following features are supported.</p>
@ -219,10 +225,11 @@
<dd>The server shall sift this kind of stanza only if the recipient is the full JID &LOCALFULL; of the particular resource.</dd> <dd>The server shall sift this kind of stanza only if the recipient is the full JID &LOCALFULL; of the particular resource.</dd>
</di> </di>
</dl> </dl>
<p>These values are child elements of the &lt;iq-sift/&gt;, &lt;message-sift/&gt;, and &lt;presence-sift/&gt; 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>These values are child elements of the &lt;iq/&gt;, &lt;message/&gt;, &lt;presence/&gt;, and &lt;sub/&gt; elements when the server returns a features discovery result, whereas they are values of the 'recipient' attribute when the client enables sift support.</p>
</section3> </section3>
<section3 topic='Payload' anchor='features-payload'> <section3 topic='Payload' anchor='features-payload'>
<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>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>
</section3> </section3>
<section3 topic='Advanced Matching' anchor='features-advanced'> <section3 topic='Advanced Matching' anchor='features-advanced'>
<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 &lt;xs:any/&gt; notation, but any such advanced matching shall be defined in separate specifications.</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 &lt;xs:any/&gt; notation, but any such advanced matching shall be defined in separate specifications.</p>
@ -238,7 +245,7 @@
<query xmlns='http://jabber.org/protocol/disco#info'/> <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq> </iq>
]]></example> ]]></example>
<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:1" &VNOTE;. The server MUST also specify which features it supports.</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>In the following reply, the server indicates that it supports a minimal subset of SIFT features merely for the sake of presence blocking.</p> <p>In the following reply, the server indicates that it supports a minimal subset of SIFT features merely for the sake of presence blocking.</p>
<example caption='Minimal server support'><![CDATA[ <example caption='Minimal server support'><![CDATA[
<iq type='result' <iq type='result'
@ -246,7 +253,7 @@
to='romeo@montague.lit/pda' to='romeo@montague.lit/pda'
id='bf4vb167'> id='bf4vb167'>
<query xmlns='http://jabber.org/protocol/disco#info'> <query xmlns='http://jabber.org/protocol/disco#info'>
<feature var='urn:xmpp:sift:1'/> <feature var='urn:xmpp:sift:2'/>
<feature var='urn:xmpp:sift:stanzas:presence'/> <feature var='urn:xmpp:sift:stanzas:presence'/>
</query> </query>
</iq> </iq>
@ -258,13 +265,14 @@
to='romeo@montague.lit/pda' to='romeo@montague.lit/pda'
id='bf4vb167'> id='bf4vb167'>
<query xmlns='http://jabber.org/protocol/disco#info'> <query xmlns='http://jabber.org/protocol/disco#info'>
<feature var='urn:xmpp:sift:1'/> <feature var='urn:xmpp:sift:2'/>
<feature var='urn:xmpp:sift:recipients:all'/> <feature var='urn:xmpp:sift:recipients:all'/>
<feature var='urn:xmpp:sift:senders:all'/> <feature var='urn:xmpp:sift:senders:all'/>
<feature var='urn:xmpp:sift:senders:others'/> <feature var='urn:xmpp:sift:senders:others'/>
<feature var='urn:xmpp:sift:stanzas:iq'/> <feature var='urn:xmpp:sift:stanzas:iq'/>
<feature var='urn:xmpp:sift:stanzas:message'/> <feature var='urn:xmpp:sift:stanzas:message'/>
<feature var='urn:xmpp:sift:stanzas:presence'/> <feature var='urn:xmpp:sift:stanzas:presence'/>
<feature var='urn:xmpp:sift:stanzas:sub'/>
</query> </query>
</iq> </iq>
]]></example> ]]></example>
@ -278,20 +286,20 @@
id='rv491g37' id='rv491g37'
to='romeo@montague.lit' to='romeo@montague.lit'
type='set'> type='set'>
<sift xmlns='urn:xmpp:sift:1'> <sift xmlns='urn:xmpp:sift:2'>
<message sender='others'/> <message sender='others'/>
<presence/> <presence/>
</sift> </sift>
</iq> </iq>
]]></example> ]]></example>
<p>The foregoing IQ-set means "sift messages from others and presence from all senders, no matter if the recipient is my bare JID or my full JID".</p> <p>The foregoing IQ-set means "sift messages from others and presence from all senders, no matter if the recipient is my bare JID or my full JID".</p>
<p>Each of the child elements &IQ;, &MESSAGE;, and &PRESENCE; MAY also contain one or more &lt;allow/&gt; children whose 'name' attribute specifies the element name and whose 'ns' attribute specifies the XML namespace of stanza payloads the client would like to allow. If no &lt;allow/&gt; elements are included, then sifting of that kind of stanza is completed without reference to the payload.</p> <p>Each of the child elements &IQ;, &MESSAGE;, &PRESENCE;, and &lt;sub/&gt; MAY also contain one or more &lt;allow/&gt; children whose 'name' attribute specifies the element name and whose 'ns' attribute specifies the XML namespace of stanza payloads the client would like to allow. If no &lt;allow/&gt; elements are included, then sifting of that kind of stanza is completed without reference to the payload.</p>
<example caption="Sifting for particular IQ payloads"><![CDATA[ <example caption="Sifting for particular IQ payloads"><![CDATA[
<iq from='romeo@montague.lit/pda' <iq from='romeo@montague.lit/pda'
id='bs01jg75' id='bs01jg75'
to='romeo@montague.lit' to='romeo@montague.lit'
type='set'> type='set'>
<sift xmlns='urn:xmpp:sift:1'> <sift xmlns='urn:xmpp:sift:2'>
<iq> <iq>
<allow name='jingle' ns='urn:xmpp:jingle:1'/> <allow name='jingle' ns='urn:xmpp:jingle:1'/>
<allow name='query' ns='http://jabber.org/protocol/disco#info'/> <allow name='query' ns='http://jabber.org/protocol/disco#info'/>
@ -308,7 +316,7 @@
id='cid143n9' id='cid143n9'
to='romeo@montague.lit' to='romeo@montague.lit'
type='set'> type='set'>
<sift xmlns='urn:xmpp:sift:1'> <sift xmlns='urn:xmpp:sift:2'>
<iq> <iq>
<allow name='Envelope' ns='http://www.w3.org/2003/05/soap-envelope'/> <allow name='Envelope' ns='http://www.w3.org/2003/05/soap-envelope'/>
</iq> </iq>
@ -324,11 +332,24 @@
id='zl2f36d8' id='zl2f36d8'
to='romeo@montague.lit' to='romeo@montague.lit'
type='set'> type='set'>
<sift xmlns='urn:xmpp:sift:1'> <sift xmlns='urn:xmpp:sift:2'>
<presence> <presence>
<allow name='c' ns='http://jabber.org/protocol/caps'/> <allow name='c' ns='http://jabber.org/protocol/caps'/>
</presence> </presence>
</sift> </sift>
</iq>
]]></example>
<p>An even more strict example is filtering out all children of the XMPP &MESSAGE; stanza except &BODY;.</p>
<example caption="Sifting Out All But Message Bodies"><![CDATA[
<iq from='romeo@montague.lit/pda'
id='b8dv163d'
to='romeo@montague.lit'
type='set'>
<sift xmlns='urn:xmpp:sift:2'>
<message>
<allow name='body' ns='jabber:client'/>
</message>
</sift>
</iq> </iq>
]]></example> ]]></example>
<p>Naturally, the server could return the typical XMPP error conditions, such as &unavailable; if the server does not support the SIFT protocol or the version specified by the client, &feature; if the server does not support a particular feature (e.g., &IQ; sifting) requested by the client, &badrequest; if the request is malformed, &internalserver; if the server experiences a malfunction while attempting to process the request, and so on.</p> <p>Naturally, the server could return the typical XMPP error conditions, such as &unavailable; if the server does not support the SIFT protocol or the version specified by the client, &feature; if the server does not support a particular feature (e.g., &IQ; sifting) requested by the client, &badrequest; if the request is malformed, &internalserver; if the server experiences a malfunction while attempting to process the request, and so on.</p>
@ -340,25 +361,29 @@
id='mxi371g9' id='mxi371g9'
to='romeo@montague.lit' to='romeo@montague.lit'
type='set'> type='set'>
<sift xmlns='urn:xmpp:sift:1'/> <sift xmlns='urn:xmpp:sift:2'/>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
</section1> </section1>
<section1 topic='Business Rules' anchor='rules'> <section1 topic='Business Rules' anchor='rules'>
<section2 topic='Handling Presence Stanzas' anchor='rules-presence'> <section2 topic='Handling IQ Stanzas' anchor='rules-iq'>
<p>When the client indicates that it wishes to receive inbound presence notifications, the server SHOULD send outbound presence probes on the client's behalf. Responses to these presence probes are addressed to the bare JID of the account and then broadcasted to all of the resources that have expressed interest in receiving inbound presence notifications.</p> <p>If the client does not request filtering of inbound IQ stanzas, the server MUST pass through to the client all IQ stanzas that are addressed to the full JID of the client (subject to appropriate security controls as defined in the relevant RFCs and XEPs).</p>
<p>If the client subsequently indicates that it wants the server to intercept inbound presence notifications, the server MUST NOT deliver to the client presence notifications that are addressed to the bare JID or full JID as defined by the 'recipient' attribute.</p> <p>If the client requests filtering of inbound IQ stanzas, for unfiltered payload name+namespace combinations the server MUST pass through to the client all IQ stanzas that are addressed to the full JID of the client (subject to appropriate security controls as defined in the relevant RFCs and XEPs), whereas for filtered payload name+namespace combinations the server MUST respond to all IQ stanzas in a way consistent with the specification for the given payload namespace (if defined) or as specified in XMPP-CORE and XMPP-IM for IQs where no full JID &LOCALFULL; matches; typically that means returning a &unavailable; error.</p>
<p>If the client then indicates again that it wishes to receive inbound presence notifications, the server shall resynchronize the client regarding the presence states of its contacts (how it does so is implementation-specific, e.g. whether it queues received presence notifications or re-probes the user's contacts).</p>
</section2> </section2>
<section2 topic='Handling Message Stanzas' anchor='rules-message'> <section2 topic='Handling Message Stanzas' anchor='rules-message'>
<p>When a client indicates that it wishes to receive messages, the server SHOULD deliver to the client all messages in the offline message queue and MUST deliver to the client any subsequent messages that would normally be delivered to the client in accordance with the rules defined in &xmppcore; and XMPP-IM.</p> <p>When a client indicates that it wishes to receive messages, the server SHOULD deliver to the client all messages in the offline message queue and MUST deliver to the client any subsequent messages that would normally be delivered to the client in accordance with the rules defined in &xmppcore; and XMPP-IM.</p>
<p>If the client subsequently indicates that it wants the server to intercept inbound messages (and there are no other connected or available resources that have expressed interest in receiving inbound messages), the server SHOULD treat messages as if there were no connected or available resources (e.g., storing them offline for later delivery); if the client then indicates again that it wishes to receive inbound messages, the server SHOULD send those queued messages to the client so that it can get back in sync regarding messages received from its contacts.</p> <p>If the client subsequently indicates that it wants the server to intercept inbound messages (and there are no other connected or available resources that have expressed interest in receiving inbound messages), the server SHOULD treat messages as if there were no connected or available resources (e.g., storing them offline for later delivery); if the client then indicates again that it wishes to receive inbound messages, the server SHOULD send those queued messages to the client so that it can get back in sync regarding messages received from its contacts.</p>
</section2> </section2>
<section2 topic='Handling IQ Stanzas' anchor='rules-iq'> <section2 topic='Handling Presence Notifications' anchor='rules-presence'>
<p>If the client does not request filtering of inbound IQ stanzas, the server MUST pass through to the client all IQ stanzas that are addressed to the full JID of the client (subject to appropriate security controls as defined in the relevant RFCs and XEPs).</p> <p>When the client indicates that it wishes to receive inbound presence notifications, the server SHOULD send outbound presence probes on the client's behalf. Responses to these presence probes are addressed to the bare JID of the account and then broadcasted to all of the resources that have expressed interest in receiving inbound presence notifications.</p>
<p>If the client requests filtering of inbound IQ stanzas, for unfiltered payload name+namespace combinations the server MUST pass through to the client all IQ stanzas that are addressed to the full JID of the client (subject to appropriate security controls as defined in the relevant RFCs and XEPs), whereas for filtered payload name+namespace combinations the server MUST respond to all IQ stanzas in a way consistent with the specification for the given payload namespace (if defined) or as specified in XMPP-CORE and XMPP-IM for IQs where no full JID &LOCALFULL; matches; typically that means returning a &unavailable; error.</p> <p>If the client subsequently indicates that it wants the server to intercept inbound presence notifications, the server MUST NOT deliver to the client presence notifications that are addressed to the bare JID or full JID as defined by the 'recipient' attribute.</p>
<p>If the client then indicates again that it wishes to receive inbound presence notifications, the server shall resynchronize the client regarding the presence states of its contacts (how it does so is implementation-specific, e.g. whether it queues received presence notifications or re-probes the user's contacts).</p>
</section2>
<section2 topic='Handling Subscriptions' anchor='rules-sub'>
<p>When the client indicates that it wishes to receive inbound subscription-related presence stanzas, it MUST deliver presence stanzas of type "subscribe", "subscribed", "unsubscribe", and "unsubscribed" to the client in accordane with the rules in &xmppim;.</p>
<p>If the client subsequently indicates that it wants the server to intercept inbound subscription-related presence stanzas, the server MUST NOT deliver to the client such stanzas that are addressed to the bare JID or full JID as defined by the 'recipient' attribute.</p>
</section2> </section2>
<section2 topic='Lack of Sifting' anchor='rules-none'> <section2 topic='Lack of Sifting' anchor='rules-none'>
<p>Naturally, if the server advertises support for the SIFT protocol but the client does not send any IQ-set stanzas containing SIFT payloads, the server MUST proceed as it normally would in accordance with the core XMPP specifications.</p> <p>Naturally, if the server advertises support for the SIFT protocol but the client does not send any IQ-set stanzas containing SIFT payloads, the server MUST proceed as it normally would in accordance with the core XMPP specifications.</p>
@ -373,7 +398,7 @@
id='zkd71d37' id='zkd71d37'
to='romeo@montague.lit' to='romeo@montague.lit'
type='set'> type='set'>
<sift xmlns='urn:xmpp:sift:1'> <sift xmlns='urn:xmpp:sift:2'>
<message recipient='bare'/> <message recipient='bare'/>
</sift> </sift>
</iq> </iq>
@ -387,9 +412,26 @@
id='uh2s64g9' id='uh2s64g9'
to='romeo@montague.lit' to='romeo@montague.lit'
type='set'> type='set'>
<sift xmlns='urn:xmpp:sift:1'> <sift xmlns='urn:xmpp:sift:2'>
<presence/> <presence/>
</sift> </sift>
</iq>
]]></example>
</section2>
<section2 topic='Removing Extraneous Message Extensions' anchor='basicmessage'>
<p>Some XMPP-based services include a large number of extensions in messages (e.g., microblogging extensions). A client might want to filter out those extensions and allow only the bare minimum elements allowed by the base XMPP specifications. It can do so by specifying that the only payloads it wants to receive are the &BODY;, &SUBJECT;, and &THREAD; elements qualified by the 'jabber:client' namespace.</p>
<example caption="Removing extraneous message extensions"><![CDATA[
<iq from='romeo@montague.lit/pda'
id='nj3fac27'
to='romeo@montague.lit'
type='set'>
<sift xmlns='urn:xmpp:sift:2'>
<message>
<allow name='body' ns='jabber:client'/>
<allow name='subject' ns='jabber:client'/>
<allow name='thread' ns='jabber:client'/>
</message>
</sift>
</iq> </iq>
]]></example> ]]></example>
</section2> </section2>
@ -407,7 +449,7 @@
<section2 topic='Protocol Namespaces' anchor='registrar-ns'> <section2 topic='Protocol Namespaces' anchor='registrar-ns'>
<p>This specification defines the following XML namespace:</p> <p>This specification defines the following XML namespace:</p>
<ul> <ul>
<li>urn:xmpp:sift:1</li> <li>urn:xmpp:sift:2</li>
</ul> </ul>
<p>Upon advancement of this specification from a status of Experimental to a status of Draft, the &REGISTRAR; shall add the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.</p> <p>Upon advancement of this specification from a status of Experimental to a status of Draft, the &REGISTRAR; shall add the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.</p>
</section2> </section2>
@ -422,8 +464,8 @@
<xs:schema <xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema' xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:xmpp:sift:1' targetNamespace='urn:xmpp:sift:2'
xmlns='urn:xmpp:sift:1' xmlns='urn:xmpp:sift:2'
elementFormDefault='qualified'> elementFormDefault='qualified'>
<xs:element name='sift'> <xs:element name='sift'>
@ -441,6 +483,10 @@
type='siftElementType' type='siftElementType'
minOccurs='0' minOccurs='0'
maxOccurs='1'/> maxOccurs='1'/>
<xs:element name='sub'
type='siftElementType'
minOccurs='0'
maxOccurs='1'/>
</xs:sequence> </xs:sequence>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
@ -494,7 +540,7 @@
</section1> </section1>
<section1 topic='Acknowledgements' anchor='acks'> <section1 topic='Acknowledgements' anchor='acks'>
<p>The authors wish to acknowledge feedback received from Dave Cridland, Jack Erwin, Fabio Forno, Waqas Hussein, Craig Kaes, Dirk Meyer, Chris Newton, Christopher Orr, Robert Quattlebaum, Travis Shirk, Mike Taylor, Matthew Wild, and Jiří Zárevúcký, as well as from participants at XMPP Summit #7 in July 2009 and XMPP Summit #8 in February 2010.</p> <p>The authors wish to acknowledge feedback received from Dave Cridland, Jack Erwin, Fabio Forno, Waqas Hussain, Craig Kaes, Dirk Meyer, Chris Newton, Christopher Orr, Robert Quattlebaum, Travis Shirk, Mike Taylor, Matthew Wild, and Jiří Zárevúcký, as well as from participants at XMPP Summit #7 in July 2009 and XMPP Summit #8 in February 2010.</p>
</section1> </section1>
</xep> </xep>