From de05dedab52a8c724725be7353ac3ffaaa78ea02 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Wed, 3 Sep 2008 17:34:12 +0000 Subject: [PATCH] removed restriction on not sending to resources with negative priority git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2181 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0163.xml | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/xep-0163.xml b/xep-0163.xml index 1645ccc2..fb79e999 100644 --- a/xep-0163.xml +++ b/xep-0163.xml @@ -6,7 +6,7 @@
- Personal Eventing via Pubsub + Personal Eventing Protocol This specification defines semantics for using the XMPP publish-subscribe protocol to broadcast state change events associated with an instant messaging and presence account. This profile of pubsub therefore enables a standard XMPP user account to function as a virtual pubsub service, easing the discovery of syndicated data and event notifications associated with such an account. &LEGALNOTICE; 0163 @@ -145,7 +145,7 @@

Personal eventing provides a way for a Jabber/XMPP user to send updates or "events" to other users, who are typically contacts in the user's roster. An event can be anything that a user wants to make known to other people, such as those described in &xep0080;, &xep0107;, &xep0108;, and &xep0118;. While the XMPP &xep0060; extension ("pubsub") can be used to broadcast such events associated, the full pubsub protocol is often thought of as complicated and therefore has not been widely implemented. - Instead, many "extended presence" formats are currently sent using the &PRESENCE; stanza type; unfortunately, this overloads presence, results in unnecessary presence traffic, and does not provide fine-grained control over access. The use of publish-subscribe rather than presence is therefore preferable. To make publish-subscribe functionality more accessible (especially to instant messaging and presence applications that conform to &xmppim;), this document defines a simplified subset of pubsub that can be followed by instant messaging client and server developers to more easily deploy personal eventing services across the Jabber/XMPP network. We label this subset "Personal Eventing via Pubsub" or PEP.

+ Instead, many "extended presence" formats are currently sent using the &PRESENCE; stanza type; unfortunately, this overloads presence, results in unnecessary presence traffic, and does not provide fine-grained control over access. The use of publish-subscribe rather than presence is therefore preferable. To make publish-subscribe functionality more accessible (especially to instant messaging and presence applications that conform to &xmppim;), this document defines a simplified subset of pubsub that can be followed by instant messaging client and server developers to more easily deploy personal eventing services across the Jabber/XMPP network. We label this subset "Personal Eventing Protocol" or PEP.

Note: Any use cases not described herein are described in XEP-0060. Also, this document does not show error flows related to the generic publish-subscribe use cases referenced herein, since they are exhaustively defined in XEP-0060. The reader is referred to XEP-0060 for all relevant protocol details related to the XMPP publish-subscribe extension. This document merely defines a "subset" or "profile" of XMPP publish-subscribe.

 @@ -383,14 +383,14 @@

  1. If an entity subscribed using a full JID &FULLJID; or a bare domain identifier &DOMAINBARE;, a PEP service MUST send one notification only, addressed to the subscribed JID.

    2. -

  2. If a subscriber subscribed using a bare JID &LOCALBARE; and a PEP service does not have appropriate presence information about the subscriber, a PEP service MUST send at most one notification, addressed to the bare JID &LOCALBARE; of the subscriber, and MAY choose not to send any notification. (By "appropriate presence information" is meant an available presence stanza with non-negative priority and XEP-0115 data that indicates interest in the relevant data format.)

    3. -

  3. If a subscriber subscribed using a bare JID &LOCALBARE; and a PEP service has appropriate presence information about the subscriber, the PEP service MUST send one notification to the full JID &FULLJID; of each of the subscriber's available resources that have specified non-negative presence priority and included XEP-0115 information that indicates an interest in the data format.

    4. +

  4. If a subscriber subscribed using a bare JID &LOCALBARE; and a PEP service does not have appropriate presence information about the subscriber, a PEP service MUST send at most one notification, addressed to the bare JID &LOCALBARE; of the subscriber, and MAY choose not to send any notification. (By "appropriate presence information" is meant an available presence stanza with XEP-0115 data that indicates interest in the relevant data format.)

    5. +

  5. If a subscriber subscribed using a bare JID &LOCALBARE; and a PEP service has appropriate presence information about the subscriber, the PEP service MUST send one notification to the full JID &FULLJID; of each of the subscriber's available resources that have included XEP-0115 information indicating an interest in the data format.

  1. When an account owner publishes an item to a node, a PEP service MUST generate a notification and send it to all appropriate subscribers (where the number of notifications is determined by the foregoing rules).

    2. -

  2. When a PEP service receives initial presence information from a subscriber's resource with a non-negative priority and including XEP-0115 information that indicates an interest in the data format, it MUST generate a notification containing the last published item for that node and send it to the newly-available resource.

    3. +

  3. When a PEP service receives initial presence information from a subscriber's resource including XEP-0115 information that indicates an interest in the data format, it MUST generate a notification containing the last published item for that node and send it to the newly-available resource.

  4. As an exception to the foregoing MUST rules, a PEP service MUST NOT send notifications to a subscriber if the user has blocked the subscriber from receiving all or any kinds of stanza (presence, message, IQ, or any combination thereof) using communications blocking as specified in &xep0016; or &xep0191;.

 @@ -534,7 +534,7 @@ -

Because Personal Eventing via Pubsub simply reuses the protocol specified in XEP-0060, a separate schema is not needed.

+

Because PEP simply reuses the protocol specified in XEP-0060, a separate schema is not needed.