From 067c71b558e1113ce7e863d6a9254c0bfcdf00c6 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Mon, 3 May 2010 22:14:25 +0000 Subject: [PATCH] 0.3 git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@4197 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0273.xml | 52 +++++++++++++++++++++++++--------------------------- 1 file changed, 25 insertions(+), 27 deletions(-) diff --git a/xep-0273.xml b/xep-0273.xml index a36f0205..b6586ca4 100644 --- a/xep-0273.xml +++ b/xep-0273.xml @@ -23,6 +23,12 @@ &hildjj; &metajack; &stpeter; + + 0.3 + 2010-05-03 + psa +

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.

 + 0.2 2010-02-16 @@ -92,11 +98,12 @@
  • 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.
  • 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).
    • +

    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.

    The following taxonomy of client types is not exhaustive but might assist developers in understanding the scenarios in which SIFT might be useful.

    - + @@ -149,7 +156,7 @@
    TypeSends PresenceSends Presence * Receives Presence Receives Messages
    No
    -

    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., <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.

    +

    * 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.

    @@ -311,7 +318,7 @@ ]]> -

    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;.

    +

    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 XEP-0115.

    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.

    + +

    To completely disable all SIFT processing, the client sends an empty <sift/> element.

    + + + + ]]> +     @@ -335,12 +353,12 @@

    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).

    -

    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;.

    +

    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.

    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.

    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).

    -

    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.

    +

    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.

    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.

    @@ -348,28 +366,8 @@     - -

    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.

    - - - - ]]> -

    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.

    -

    If the user wants to "go visible", the client will send initial presence.

    - - ]]> -

    The user can later go invisible again by sending presence of type "unavailable" without modifying the SIFT rules or closing the stream.

    - - ]]> -     -

    RFC 3921 defines the concept of negative values for the presence <priority/> 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.

    +

    XMPP-IM defines the concept of negative values for the presence <priority/> 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.

    -

    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.

    +

    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.