moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

0.3 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@4197 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2010-05-03 22:14:25 +00:00
parent 1337f455c9
commit 067c71b558
1 changed files with 25 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

52
xep-0273.xml
View File

@ -23,6 +23,12 @@
&hildjj;
&metajack;
&stpeter;
<revision>
<version>0.3</version>
<date>2010-05-03</date>
<initials>psa</initials>
<remark><p>Specified sending of an empty &lt;sift/&gt; element to disable SIFT processing; removed invisibility use case because that is handled by outbound privacy lists, not inbound SIFT.</p></remark>
</revision>
<revision>
<version>0.2</version>
<date>2010-02-16</date>
@ -92,11 +98,12 @@
<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>
</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>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'>
<tr>
<th>Type</th>
<th>Sends Presence</th>
<th>Sends Presence *</th>
<th>Receives Presence</th>
<th>Receives Messages</th>
</tr>
@ -149,7 +156,7 @@
<td align='center'>No</td>
</tr>
</table>
<p>Note: Although &rfc3921; 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>* 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>
</section1>
<section1 topic='Requirements' anchor='reqs'>
@ -311,7 +318,7 @@
</sift>
</iq>
]]></example>
<p>Similarly, the following example shows how a client would filter inbound presence notifications to only receive notifications that contain entity capabilities data as specified in &xep0115;.</p>
<p>Similarly, the following example shows how a client would filter inbound presence notifications to only receive notifications that contain entity capabilities data as specified in <cite>XEP-0115</cite>.</p>
<example caption="Sifting for entity capabilities"><![CDATA[
<iq from='romeo@montague.lit/pda'
id='zl2f36d8'
@ -326,6 +333,17 @@
]]></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>
</section2>
<section2 topic='Disabling SIFT' anchor='disable'>
<p>To completely disable all SIFT processing, the client sends an empty &lt;sift/&gt; element.</p>
<example caption="Disabling all SIFT processing"><![CDATA[
<iq from='romeo@montague.lit/pda'
id='mxi371g9'
to='romeo@montague.lit'
type='set'>
<sift xmlns='urn:xmpp:sift:1'/>
</iq>
]]></example>
</section2>
</section1>
<section1 topic='Business Rules' anchor='rules'>
@ -335,12 +353,12 @@
<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 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 &xmppim;.</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>
</section2>
<section2 topic='Handling IQ Stanzas' anchor='rules-iq'>
<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 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 &xmppcore; and &xmppim; for IQs where no full JID &LOCALFULL; matches; typically that means returning a &unavailable; error.</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>
</section2>
<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>
@ -348,28 +366,8 @@
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic='Invisibility' anchor='invisibility'>
<p>In order to be invisible at the start of a session, a client can register for (i.e., not request interception of) inbound messages and presence notifications without sending initial presence.</p>
<example caption="Staying invisible"><![CDATA[
<iq from='romeo@montague.lit/pda'
id='mxi371g9'
to='romeo@montague.lit'
type='set'>
<sift xmlns='urn:xmpp:sift:1'/>
</iq>
]]></example>
<p>The server would then probe the user's contacts and return the resulting presence notifications to the client, as well as allow inbound message and IQ stanzas.</p>
<p>If the user wants to "go visible", the client will send initial presence.</p>
<example caption="Going visible"><![CDATA[
<presence/>
]]></example>
<p>The user can later go invisible again by sending presence of type "unavailable" without modifying the SIFT rules or closing the stream.</p>
<example caption="Going invisible"><![CDATA[
<presence type='unavailable'/>
]]></example>
</section2>
<section2 topic='Negative Presence Priority' anchor='priority'>
<p>RFC 3921 defines the concept of negative values for the presence &lt;priority/&gt; element, where a negative value instructs the server to not deliver to the client any messages that are directed to the bare JID of the user. This behavior can be emulated using SIFT by asking the server to intercept inbound message stanzas for the bare JID, but not presence notifications or IQ stanzas.</p>
<p>XMPP-IM defines the concept of negative values for the presence &lt;priority/&gt; element, where a negative value instructs the server to not deliver to the client any messages that are directed to the bare JID of the user. This behavior can be emulated using SIFT by asking the server to intercept inbound message stanzas for the bare JID, but not presence notifications or IQ stanzas.</p>
<example caption="Emulating negative presence priority"><![CDATA[
<iq from='romeo@montague.lit/pda'
id='zkd71d37'
@ -496,7 +494,7 @@
</section1>
<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, Christopher Orr, Robert Quattlebaum, 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 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>
</section1>
</xep>